Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

העברה מ-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 ב-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
מפות תצורה (יש פתרון עקיף)
שיטות מותאמות אישית של התאמה אופקית של קבוצות Pod לעומס
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 אין מקבילה ל-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 .
הקונטיינרים צריכים להיות מאוחסנים במאגר קונטיינרים נתמך.
יכול להיות שתצטרכו לשנות את המגבלות של המעבד ושל הזיכרון.
כשמוסיפים הפניה לסוד, משתמשים במאפיין key כדי לתעד את הגרסה ב-Secret Manager, ובמאפיין latest כדי להפנות לגרסה האחרונה של הסוד.
‫serviceAccountName צריך להפנות לחשבון שירות בפרויקט הנוכחי Google Cloud
צריך להחליף הפניות ל-ConfigMaps (configMapKeyRef) בהפניות לסודות (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 קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.