‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

העברה מ-Kubernetes ל-Cloud Run

גם Cloud Run וגם Kubernetes משתמשים בקובצי אימג' סטנדרטיים של קונטיינרים כפריטי מידע שנוצרו בתהליך הפיתוח (artifacts) לפריסה, ושניהם משתמשים במודל API הצהרתי עם משאבים שאפשר לייצג בקובצי YAML עם אותו מבנה סטנדרטי.

מבוא

גרסה 1 של Cloud Run Admin API נועדה למקסם את הניידות עם Kubernetes. לדוגמה, המשאבים של Cloud Run Admin API חולקים את אותן מוסכמות מבנה ושמות מאפיינים כמו המשאבים של Kubernetes. הפניית YAML לשירות Cloud Run

גרסה 1 של Cloud Run Admin API מטמיעה את מפרט Knative Serving API, אבל אתם לא צריכים להשתמש ב-Knative באשכול הקיים של Kubernetes כדי להעביר חלק מעומסי העבודה של Kubernetes ל-Cloud Run.

המשאב הראשי של Cloud Run הוא השירות. אפשר לחשוב על שירות Cloud Run כהפשטה ברמה גבוהה שנראית כמו פריסה של Kubernetes עם התאמה מובנית לעומס (autoscaling) של pod ונקודת קצה ייחודית. "Pod" ב-Kubernetes תואם ל "מכונה" ב-Cloud Run. מומלץ להמיר את פריסות Kubernetes לשירותי Cloud Run, שירות אחד בכל פעם. תוכלו גם למזג חלק מההגדרות של Horizontal Pod Autoscaler ושל שירותי Kubernetes בשירות Cloud Run.

ב-Cloud Run אין מרחב שמות, ובמקום זאת הפרויקט ב-Google Cloud משמש כגבול בידוד בין המשאבים. כשעוברים ל-Cloud Run מ-Kubernetes, מומלץ ליצור פרויקט אחד ב-Google Cloud לכל מרחב שמות. ב-YAML של שירות Cloud Run, הערך של מרחב השמות הוא מספר הפרויקט ב- Google Cloud .

ל-Cloud Run יש יתירות מובנית באזורים, כלומר לא צריך להקצות רפליקה כדי לוודא שהשירות עמיד בפני הפסקות חשמל באזור שנבחר ב- Google Cloud .

מדריך למתחילים

המדריך למתחילים הזה הוא דוגמה להעברה פשוטה.

השוואה פשוטה בין משאבים

השוו בין הפריסה הפשוטה הבאה של Kubernetes, שנקראת my-app, לבין שירות Cloud Run המקביל. שימו לב שקובצי ה-YAML כמעט זהים.

החלקים ב-blue שונים וצריך לשנות אותם. צריך למחוק את החלקים ב-red כי ב-Cloud Run יש התאמה אוטומטית לעומס (autoscaler) מובנית.

פריסת Kubernetes	שירות Cloud Run
apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: default labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world replicas: 3 selector: matchLabels: app: my-app	apiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-app namespace: 'PROJECT_NUMBER' labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world

פריסת Kubernetes

שירות Cloud Run

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world
  replicas: 3
  selector:
    matchLabels:
      app: my-app

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-app
  namespace: 'PROJECT_NUMBER'
  labels:
    app: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world

העברת פריסה פשוטה של Kubernetes ל-Cloud Run

מורידים את קובץ ה-YAML של הפריסה בספרייה הנוכחית באמצעות:
```
kubectl get deployment  my-app -o yaml > my-app.yaml
```
משנים את קובץ ה-YAML כך שיתאים לשירות Cloud Run. מעדכנים את הקובץ my-app.yaml:
- במאפיין "kind": מחליפים את הערך "Deployment" בערך "Service"
- במאפיין "apiVersion": מחליפים את הערך "apps/v1" בערך "serving.knative.dev/v1"
- צריך למחוק את המאפיין metadata.namespace או לשנות את הערך שלו כך שיתאים למספר הפרויקט ב- Google Cloud .
- מחיקת spec.replicas וגם spec.selector
פורסים את הקובץ my-app.yaml ב-Cloud Run באמצעות הפקודה הבאה, ומחליפים את REGION באזור הרצוי ב- Google Cloud , לדוגמה europe-west1:
```
gcloud run services replace my-app.yaml --region REGION
```

הפעלת שירות Cloud Run מוגנת על ידי הרשאת IAM. אם רוצים לחשוף את שירות Cloud Run החדש באופן ציבורי לאינטרנט ולאפשר גישה ציבורית, מריצים את הפקודה הבאה:

gcloud run services add-iam-policy-binding my-app --member="allUsers" --role="roles/run.invoker" --region REGION

תכונות שלא נתמכות ב-Cloud Run

אפשר להעביר רק עומסי עבודה שמתאימים ל-Cloud Run.

חשוב לציין שהתכונות הבאות של Kubernetes לא נתמכות ב-Cloud Run:

מספר קבוע של replicas (כדי לעקוף את הבעיה, אפשר להשתמש באותו מספר של מכונות מינימליות ומקסימליות
מפות תצורה (יש פתרון עקיף)
שיטות להתאמה אופקית של קבוצות Pod לעומס (HPA) בהתאמה אישית
זיהוי שירותים
דיסק מקומי (זמני וקבוע)

כשמעבירים קובץ YAML מפריסה של Kubernetes לשירות Cloud Run, הפקודה gcloud run services replace מחזירה הודעת שגיאה ברורה לכל מאפיין שלא נתמך ב-Cloud Run. צריך למחוק או לעדכן את המאפיינים האלה, ואז לחזור על הפקודה עד שהיא תצליח.

במסמך העזר של YAML יש רשימה מקיפה של המאפיינים שנתמכים ב-Cloud Run.

העברת משאבים ב-Kubernetes

העברת סודות של Kubernetes

כמו ב-Kubernetes, גם ב-Cloud Run אפשר לטעון סודות כמשתני סביבה או כנפחים, אבל צריך לאחסן את הסודות ב-Secret Manager.

יש כמה הבדלים חשובים בין סודות ב-Secret Manager לבין סודות ב-Kubernetes:

תווים מותרים בשמות:
- סודות של Kubernetes: [a-z0-9-.]{1,253}
- סודות ב-Secret Manager:‏ [a-zA-Z0-9_-]{1,255}
ניהול גרסאות: לסודות מ-Secret Manager יש גרסאות, אבל לסודות מ-Kubernetes אין.
מטען ייעודי (Payload): סודות מ-Secret Manager מכילים []byte יחיד, וסודות מ-Kubernetes מכילים map<string, string>.

פועלים לפי ההוראות במאמרי העזרה של Secret Manager כדי ליצור סוד ולהוסיף גרסת סוד חדשה לכל מפתח סודי שאפליקציית Kubernetes תלויה בו.

העברת ConfigMaps של Kubernetes

ב-Cloud Run אין מקבילה ל-ConfigMaps של Kubernetes, אבל מכיוון שאפשר לראות את ConfigMaps כסודות לא מוצפנים, אתם יכולים להפוך את ConfigMaps לסודות ב-Secret Manager. ההוראות מופיעות בקטע העברת סודות של Kubernetes.

העברת פריסה של Kubernetes

פריסת Kubernetes שנחשפת על ידי שירות היא המשאב שהמיפוי שלו הכי קרוב לשירות Cloud Run. מומלץ להתחיל מקובץ ה-YAML של פריסת Kubernetes ולערוך אותו כדי להפוך אותו לשירות Cloud Run.

השינויים העיקריים שצריך לבצע הם:

צריך להחליף את namespace במספר הפרויקט ב- Google Cloud .
התוויות (metadata.labels ו-spec.template.metadata.labels) חייבות להיות Google Cloud תוויות חוקיות.
הקונטיינרים צריכים להיות מאוחסנים בContainer Registry נתמך.
יכול להיות שתצטרכו לשנות את מגבלות המעבד (CPU) והזיכרון.
כשמפנים לסוד, המאפיין "key" משמש כדי לתעד את הגרסה ב-Secret Manager, והמאפיין "latest" מפנה לגרסה האחרונה של הסוד.
‫serviceAccountName צריך להפנות לחשבון שירות בפרויקט Google Cloud הנוכחי
צריך להחליף את ההפניות ל-ConfigMaps (configMapKeyRef) בהפניות לסודות (secretKeyRef)

אם פריסת Kubernetes ניגשת למשאבים אחרים באשכול Kubernetes או למשאבים ב-VPC, צריך לחבר את שירות Cloud Run ל-VPC המתאים.

העברת שירות Kubernetes

שירותי Cloud Run חושפים באופן אוטומטי נקודת קצה ייחודית שמנתבת תנועה לקונטיינר עם containerPort. אחרי שמעבירים את פריסת Kubernetes לשירות Cloud Run, לא צריך להעביר את שירותי Kubernetes שניתבו את התנועה לפריסה הזו.

העברת HorizontalPodAutoscaler של Kubernetes

לשירותי Cloud Run יש התאמה אוטומטית מובנית לעומס (autoscaler) אופקי: Cloud Run משנה באופן אוטומטי את קנה המידה של pod (שנקראים "מכונות") באמצעות שילוב של גורמים בתוך הגבולות של מספר המכונות המינימלי והמקסימלי שהוגדר.

מעבירים את המאפיינים minReplicas ו-maxReplicas של HorizontalPodAutoscaler להערות autoscaling.knative.dev/minScale ו-autoscaling.knative.dev/maxScale של שירות Cloud Run. למידע נוסף, קראו את המאמרים בנושא הגדרת מספר המכונות המינימלי ומספר המכונות המקסימלי.

העברת פריסת Kubernetes בלי שירות

אם הפריסה של Kubernetes מבצעת משימות ברקע או משימות מתוזמנות, והיא לא חשופה על ידי שירות, אתם יכולים להעביר אותה למאגר של Cloud Run worker.

הדוגמאות הבאות מראות את ההבדל המבני בין פריסת Kubernetes לבין מאגר עובדים של Cloud Run:

פריסת Kubernetes	מאגרי וורקרים ב-Cloud Run
apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: default labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world replicas: 3 selector: matchLabels:	apiVersion: run.googleapis.com/v1 kind: WorkerPool metadata: name: my-app annotations: run.googleapis.com/manualInstanceCount: '1' spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world

פריסת Kubernetes

מאגרי וורקרים ב-Cloud Run

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world
  replicas: 3
  selector:
    matchLabels:

apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
  name: my-app
  annotations:
    run.googleapis.com/manualInstanceCount: '1'
spec:
template:
    metadata:
      labels:
      app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world

העברת משימה ב-Kubernetes

כי משימת Kubernetes דומה להרצת משימה ב-Cloud Run. אתם יכולים לעבור למשימת Cloud Run ולהריץ את המשימה.

הדוגמאות הבאות מראות את ההבדל המבני בין משימת Kubernetes לבין משימת Cloud Run:

משימת Kubernetes	משימה ב-Cloud Run
apiVersion: batch/v1 kind: Job metadata: name: my-job spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job	apiVersion: run.googleapis.com/v1 kind: Job metadata: name: my-job spec: template: spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job

משימת Kubernetes

משימה ב-Cloud Run

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - image: us-docker.pkg.dev/cloudrun/container/job

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      template:
        spec:
          containers:
          - image: us-docker.pkg.dev/cloudrun/container/job

אסטרטגיית העברה

אחרי שיוצרים את המשאבים המקבילים, חשיפת נקודות קצה (endpoint) חיצוניות מאחורי מאזן עומסים של אפליקציות (ALB) גלובלי חיצוני מאפשרת להעביר בהדרגה את התנועה בין Cloud Run לבין Google Kubernetes Engine ‏(GKE).

העברה מ-Kubernetes ל-Cloud Run קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.