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

גם 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 באשכול Kubernetes הקיים כדי להעביר חלק מעומסי העבודה של Kubernetes אל Cloud Run.

המשאב העיקרי של Cloud Run הוא השירות. אפשר לחשוב על שירות Cloud Run כעל הפשטה ברמה גבוהה שנראית כמו פריסה של Kubernetes עם כלי מובנה למידרוג אוטומטי של Pod ונקודת קצה ייחודית. ‫Pod ב-Kubernetes מקביל למופע ב-Cloud Run. מומלץ להפוך את הפריסות של Kubernetes לשירותי Cloud Run, כל שירות בנפרד. תוכלו גם למזג חלק מההגדרות של Horizontal Pod Autoscaler של Kubernetes ושל שירותי 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 יש כלי מובנה להתאמה אוטומטית לעומס.

פריסת 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 (פתרון עקיף הוא להשתמש באותו מספר של מופעי minimum ו-maximum)
מפות תצורה (יש פתרון עקיף)
אסטרטגיות מותאמות אישית של Horizontal Pod Autoscaler
Service Discovery
דיסק מקומי (זמני ומתמשך)

כשמעבירים קובץ 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 אין מקבילה ל-Kubernetes ConfigMaps, אבל מכיוון ש-ConfigMaps יכולים להיחשב כסודות לא מוצפנים, אפשר להמיר את ה-ConfigMaps לסודות ב-Secret Manager. הוראות מפורטות מופיעות בקטע העברת סודות של Kubernetes.

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

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

השינויים העיקריים שנדרשים:

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

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

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

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

העברה של Kubernetes HorizontalPodAutoscaler

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

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

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

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

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

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

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

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