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

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

היתרונות העיקריים של מעבר ל-Cloud Run:

• מוצר מנוהל באופן מלא ללא שרת שמיישם את מפרט Knative Serving API ועומד בדרישות של חוזה הקונטיינר.

• ‫Admin API v1 של Cloud Run נועד למקסם את הניידות באמצעות Knative serving.

• חוויית המשתמש דומה ב-Cloud Run וב-Knative serving:

  • קבוצת הפקודות gcloud run משמשת בשני המוצרים.
  • פריסה והתנהגות דומות של ממשק המשתמש בקונסולה של Google Cloud .

לפני שמתחילים

התכונות הבאות של Google Kubernetes Engine לא נתמכות ב-Cloud Run, כולל:

• תכונות של אשכולות ו-pods, לדוגמה Startup, Liveness and Readiness probes, and Service Discovery.
• הגדרה:
  • ‫ConfigMaps – אפשר להפוך את ה-ConfigMaps לסודות באמצעות Secret Manager.
  • יחידות GPU של NVIDIA

• אמצעי בקרה על גישה:

  • תפקידי IAM ספציפיים ל-GKE
  • Workload Identity
  • ריבוי דיירים (multitenancy) באשכול

  אתם יכולים להשתמש ב-IAM ב-Cloud Run כדי להשיג את אותה רמת שליטה בגישה למשאבים. כדאי גם לשקול שימוש בזהות בשירות.

שיקולים לגבי מיגרציה

כדי לוודא שתוכלו להעביר את כל התלות והדרישות שלכם, אתם צריכים לעיין בהבדלים בין המוצרים ולהבין אותם.

סודות

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

הבדלים חשובים בין סודות ב-Secret Manager לבין סודות ב-Kubernetes:

תכונה	סודות ב-Secret Manager	סודות ב-Kubernetes
תווים מותרים בשמות	[a-zA-Z0-9_-]{1,255}	[a-z0-9-.]{1,253}
ניהול גרסאות	הסודות הם בגרסה	אין תמיכה
מטען ייעודי סודי (Secret Payload)	סינגל []byte	מפה: <string, string>

איך יוצרים סודות עם ניהול גרסאות עבור מפתחות הסוד של שירותי Knative Serving באמצעות Secret Manager.

Networking

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

נקודות קצה של שירותים

אין תמיכה ב-Cloud Run בנקודות הקצה של Kubernetes של שירותי Knative Serving. מידע נוסף על נקודות הקצה הייחודיות ב-Cloud Run

מיפוי דומיינים

‫

Cloud Run DomainMapping API תואם ל-Knative serving. עם זאת, Cloud Run מציע מיפוי דומיינים בחלק מהמיקומי Cloud Run הזמינים. חלופה מומלצת היא להשתמש במאזן עומסים גלובלי מסוג HTTP(S) עבור הדומיינים המותאמים אישית.

קישוריות ל-VPC

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

אמצעי בקרה על כניסה

אם שירות Knative serving מוגדר לרשת פנימית פרטית ומשתמש במאזן עומסים פנימי (ILB), אפשר להגדיר את שירות Cloud Run כך שיבצע Ingress = Internal. הגדרת השירותים שלכם ל-internal מגבילה את הגישה ל-VPC או לשירותים אחרים של Cloud Run. מידע נוסף על תקשורת בין שירותים

העברת שירות

כדי להעביר שירות, צריך לייצא את שירות Knative serving, לערוך את קובץ ה-YAML המיוצא ואז לפרוס את השירות שהוגדר מחדש ב-Cloud Run.

הערה: אם יש לכם את קובץ התצורה המקורי ב-YAML שיצרתם בהתחלה בשביל Knative serving, אתם יכולים לדלג על שלבי הייצוא והשינוי. בעזרת קובץ התצורה המקורי ב-YAML, אפשר פשוט לפרוס אותו ישירות ב-Cloud Run כדי ליצור את השירותים.

1. מריצים את הפקודה הבאה כדי לייצא את שירות Knative serving לקובץ YAML מקומי:

   gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml
   

   מחליפים את:

   • SERVICE בשם של שירות Knative serving.
   • ‫NAMESPACE מחליפים במרחב השמות שבו השירות שלכם פועל.
   • ‫CLUSTER מחליפים בשם של האשכול שבו השירות פועל.
   • ‫FILENAME בשם קובץ ייחודי לפי בחירתכם.

2. שינוי קובץ FILENAME.yaml שיוצא בשביל Cloud Run:

   • צריך לחפש את מרחב השמות של Kubernetes ולהחליף אותו במזהה שלGoogle Cloud הפרויקט. לדוגמה, צריך להחליף את namespace:default ב-namespace:my-unique-id.
   • צריך לעדכן את כל ההגדרות של התכונות שלא נתמכות.

   • צריך למחוק את המאפיינים הבאים ואת הערכים שלהם:

     • metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
     • metadata.managedFields
     • spec.template.spec.containers.readinessProbes
     • spec.template.spec.enableServiceLinks

     לדוגמה, יכול להיות שתצטרכו להסיר את ההגדרה הבאה מהמאפיינים spec: > template: > spec: > containers::

     ...
      readinessProbe:
        successThreshold: 1
        tcpSocket: {}
     ...
     

3. פורסים את הקובץ .yaml ששיניתם ב-Cloud Run באמצעות הדגל --platform managed. מידע נוסף על פריסה

   שימו לב שאפשר להשתמש באותו Google Cloud פרויקט גם בשביל Cloud Run.

   gcloud run services replace FILENAME.yaml --platform managed --region REGION
   

   מחליפים את:

   • ‫FILENAME בשם של קובץ התצורה המיוצא שיצרתם.
   • ‫REGION במיקום נתמך של Cloud Run. לדוגמה: us-central1

4. הגדרת גישה לשירות Cloud Run:

   • כברירת מחדל, שירות Cloud Run לא נגיש מבחוץ. כדי לחשוף את השירות שלכם לציבור באינטרנט ולאפשר בקשות לא מאומתות, אתם צריכים לאפשר גישה ציבורית (לא מאומתת).

   • כדי להגדיר את השירות הזה לגישה פרטית פנימית בלבד, כמו בין שירותי Cloud Run, אפשר לעיין במאמר בנושא אימות משירות לשירות.

5. במסוף Google Cloud , בדף השירותים, אפשר ללחוץ על הקישור של כתובת ה-URL שמוצגת כדי לפתוח את נקודת הקצה הייחודית והיציבה של השירות שפרסתם.

   כניסה ל-Cloud Run

העברת תנועה לשירות שלכם

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