מעבר מ-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, שירות Cloud Run צריך מחבר של חיבור לרשת (VPC) מאפליקציית serverless. עומסי עבודה ב-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), לא צריך להשתמש במחבר של חיבור לרשת (VPC) מאפליקציית serverless.

אחרי שיוצרים את הפריסה של 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 כדי לשנות את מספר הפודים באופן אוטומטי. כדי ליצור HorizontalPodAutoscaler, פועלים לפי ההוראות במאמרי העזרה בנושא התאמה אופקית של קבוצות Pod לעומס Horizontal Pod Autoscaling ב-Kubernetes. משתמשים בערכים של מספר המכונות המינימלי (autoscaling.knative.dev/minScale) ומספר המכונות המקסימלי (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).