מעבר מ-Cloud Run ל-Google Kubernetes Engine

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

מבוא

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

‫Cloud Run Admin API v1 מטמיע את מפרט Knative Serving API, אבל לא צריך לבצע מיגרציה ל-Knative כדי להעביר את עומסי העבודה של Cloud Run לאשכול Kubernetes כמו GKE.

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

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

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

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

עם זאת, החלקים ב-blue שונים וצריך לשנות אותם. צריך להוסיף את החלקים בgreen.

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

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

העברת שירות Cloud Run ל-GKE

  1. מורידים את קובץ ה-YAML של השירות לספרייה הנוכחית:

    gcloud run services describe my-app --format export > my-app.yaml

  2. משנים את קובץ ה-YAML כך שיתאים לפריסת Kubernetes:

    • במאפיין 'kind': מחליפים את הערך 'Service' בערך 'Deployment'
    • במאפיין 'apiVersion': מחליפים את הערך 'serving.knative.dev/v1' בערך 'apps/v1'
    • מחליפים את metadata.namespace במרחב השמות של אשכול GKE שרוצים לפרוס בו, לדוגמה default.
    • מוסיפים תווית חדשה מתחת לmetadata ולspec.template.metadata.
    • מגדירים מספר קבוע של מופעים ("עותקים") באמצעות spec.template.spec.replicas ומגדירים בורר תוויות ב-spec.template.spec.selector.

  3. מתקינים את כלי שורת הפקודה kubectl ומשתמשים בו כדי לפרוס את קובץ my-app.yaml באשכול GKE:

    kubectl apply -f ./my-app.yaml

  4. חשיפת הפריסה כשירות:

    kubectl expose deployment my-app --type LoadBalancer --port 80 --target-port 8080

שיקולים כשמעבירים מ-Cloud Run ל-GKE

אשכול:

  • ‫Cloud Run היא פלטפורמה מנוהלת, בעוד ש-GKE דורשת יותר ניהול פלטפורמה. אם עדיין לא יצרתם אשכול GKE, כדאי להשתמש ב-GKE Autopilot.

  • יכולת המדרגיות של עומסי עבודה ב-GKE מוגבלת על ידי גודל האשכול. אם אתם לא משתמשים באשכול Autopilot, כדאי להשתמש בהקצאת צמתים אוטומטית (NAP) ובמידרוג אוטומטי של אשכולות כדי לשנות את גודל האשכול.

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

Pricing

ב-Cloud Run מחויבים על משאבים בשימוש, וב-GKE מחויבים על משאבים שהוקצו.

אבטחה:

  • בניגוד ל-Cloud Run, הפעלה של שירות GKE לא כפופה להרשאת הפעלה ב-IAM.

  • מכיוון ש-GKE לא מספק בידוד חזק בין קונטיינרים, כדאי להשתמש ב-GKE Sandbox אם אתם צריכים להריץ קוד לא ידוע או לא מהימן.

Networking

כדי לגשת למשאבים אחרים ב-VPC, צריך מחבר של חיבור לרשת (VPC) מאפליקציית serverless ב-Cloud Run. עומסי עבודה ב-GKE נמצאים ישירות ב-VPC ולא צריך מחבר.

תכונות שלא נתמכות ב-Google Kubernetes Engine

התכונות הבאות של Cloud Run לא זמינות ב-GKE:

העברת משאבים ב-Cloud Run

בקטעים הבאים מתואר תהליך העברת המשאבים שנעשה בהם שימוש ב-Cloud Run, כמו שירותים, משימות וסודות של Cloud Run.

העברת שירותים של Cloud Run

אתם יכולים להעביר שירות של Cloud Run למשאבים הבאים ב-GKE:

  1. פריסת Kubernetes כדי ליצור מופעים (שנקראים 'pods' ב-Kubernetes).
  2. שירותי Kubernetes כדי לחשוף את הפריסה בנקודת קצה ספציפית.
  3. ‫Kubernetes Horizontal Pod Autoscaler: כדי לשנות את גודל הפריסה באופן אוטומטי.

המאפיינים של פריסת Kubernetes הם קבוצת-על של המאפיינים של שירותי Cloud Run. כמו שמוצג במדריך למתחילים, אחרי שמשנים את המאפיינים apiVersion ו-kind למאפיינים apps/v1 ו-Deployment, צריך לשנות גם את הדברים הבאים:

  • מחליפים את namespace במרחב השמות של אשכול GKE שרוצים לפרוס אליו, לדוגמה default.
  • ‫serviceAccountName צריך להפנות לחשבון שירות של Kubernetes, שיכול לשמש גם כחשבון שירות של IAM באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.
  • מוסיפים LABEL ב-metadata.labels וב-spec.template.metadata.labels שישמשו לבחירת הפריסה וה-pods. לדוגמה: app: NAME
  • בקטע spec.template:
    • מוסיפים מאפיין replicas כדי לציין מספר של 'מופעים'.
    • מוסיפים מאפיין selector.matchLabels שבוחר לפי התווית LABEL.
  • אם שירות Cloud Run שלכם מטמיע סודות, כדאי לעיין במאמר בנושא העברת סודות.
  • אם שירות Cloud Run שהועבר ניגש למשאבים בענן וירטואלי פרטי (VPC), לא צריך להשתמש במחבר Serverless VPC Access.

אחרי שיוצרים את הפריסה של Kubernetes, יוצרים שירות Kubernetes כדי לחשוף אותה:

apiVersion: v1
kind: Service
metadata:
  name: NAME
spec:
  selector:
    LABEL
  ports:
    - protocol: TCP
      port: 80
      targetPort: PORT

מחליפים את:

  • ‫NAME: עם השם של השירות.
  • ‫LABEL: עם התווית שמוגדרת בפריסה. לדוגמה app: NAME.
  • ‫PORT: מחליפים בcontainerPort של הקונטיינר שמקבל בקשות בשירות Cloud Run, שערך ברירת המחדל שלו הוא 8080.

אחר כך אפשר ליצור Kubernetes Horizontal Pod Autoscaler כדי לשנות באופן אוטומטי את מספר הפודים. פועלים לפי ההוראות בתיעוד של Kubernetes בנושא Horizontal Pod Autoscaling כדי ליצור HorizontalPodAutoscaler. משתמשים בערכים של minimum instances (autoscaling.knative.dev/minScale) ושל maximum instances (autoscaling.knative.dev/maxScale) בשירות Cloud Run בתור ערכים למאפיינים minReplicas ו-maxReplicas HorizontalPodAutoscaler.

העברה של מאגרי עובדים ב-Cloud Run

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

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

מאגרי עובדים ב-Cloud Runפריסת Kubernetes
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

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

העברת משימות ב-Cloud Run

אפשר להעביר משימה ב-Cloud Run למשימה ב-Kubernetes ב-GKE.

בניגוד למשימות ב-Cloud Run, משימות ב-Kubernetes מבוצעות כשהן נוצרות. כדי להריץ את העבודה שוב, צריך ליצור עבודה חדשה.

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

משימה ב-Cloud Runמשימת Kubernetes
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

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

העברת סודות

אתם יכולים לשמור את הסודות הקיימים ב-Secret Manager או להעביר אותם לסודות של Kubernetes.

אם תבחרו לשמור סודות ב-Secret Manager, תצטרכו לעדכן את אופן השימוש בהם ב-GKE.

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

  • תווים מותרים בשמות:
  • ניהול גרסאות: הסודות מ-Secret Manager הם בעלי גרסאות, בעוד שהסודות של Kubernetes לא.
  • המטען הייעודי (Payload): סודות מ-Secret Manager מכילים []byte אחד, בעוד שסודות Kubernetes מכילים map<string, string>.

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

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