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

גם 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 כדי להעביר את עומסי העבודה של 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

אשכול:

Pricing

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

אבטחה:

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

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

רשתות

כדי לגשת למשאבים אחרים ב-VPC, צריך להשתמש ב-Cloud Run עם חיבור לרשת VPC. עומסי העבודה של 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.

אחרי שיוצרים את פריסת 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.

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

העברת מאגרי Worker ב-Cloud Run

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

הדוגמאות הבאות מראות את ההבדל המבני בין מאגר Worker ב-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>.

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

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