יצירת אשכול משותף להפעלת עומסי עבודה של קונטיינרים

משותפים

במסמך הזה מוסבר איך ליצור אשכול Kubernetes משותף באזור מבודד של Google Distributed Cloud ‏ (GDC). אשכול משותף משתרע על פני כמה פרויקטים, וכולל שירותים מקיפים שמנוהלים על ידי GDC ומציעים הגדרה מקובעת של אשכול Kubernetes, שניתן להגדרה פחות מאשר אשכול רגיל. מידע נוסף על אשכולות רגילים זמין במאמר הגדרות של אשכול Kubernetes.

אשכולות משותפים הם משאבים אזוריים ולא יכולים להתפרס על פני כמה אזורים. כדי להפעיל אשכולות ביקום מרובה אזורים, צריך ליצור אשכולות באופן ידני בכל אזור.

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

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

• כדי לקבל את ההרשאות שדרושות ליצירת אשכול משותף, צריך לבקש מאדמין IAM בארגון להקצות לכם את התפקיד User Cluster Admin ‏(user-cluster-admin). התפקיד הזה לא מקושר למרחב שמות.

• כדי להשתמש ב-API או ב-Terraform כדי ליצור אשכול משותף, צריך ליצור את קובץ ה-kubeconfig של שרת ה-API האזורי כדי לארח את האשכול. מגדירים את משתנה הסביבה MANAGEMENT_API_SERVER לנתיב של kubeconfig. מידע נוסף זמין במאמר בנושא משאבי שרת של API לניהול אזורים.

• כדאי לעיין במגבלות של האשכול כדי להבין את השיקולים לגבי משאבים.

תכנון של חסימת ה-CIDR של ה-pod

כדי להקצות את בלוק ה-CIDR של הפוד בגודל המתאים לעומסי העבודה, צריך לחשב את מספר כתובות ה-IP שנדרשות לאשכול Kubernetes לפני שיוצרים אותו. אי אפשר לשנות את רוב הפרמטרים של הרשת אחרי שיוצרים את האשכול.

כשמקצים כתובות IP, אשכול Kubernetes פועל לפי הלוגיקה הבאה:

• ‫Kubernetes מקצה /24 בלוק CIDR שכולל 256 כתובות לכל אחד מהצמתים. הסכום הזה תואם למקסימום ברירת המחדל של 110 פודים לכל צומת באשכולות Kubernetes.
• הגודל של בלוק ה-CIDR שמוקצה לצומת תלוי בערך המקסימלי של הפודים לכל צומת.
• הבלוק תמיד מכיל לפחות פי שניים כתובות ממספר הפודים המקסימלי לכל צומת.

בדוגמה הבאה מוסבר איך ערך ברירת המחדל של Per node mask size= /24 חושב כדי להתאים ל-110 פודים:

Maximum pods per node = 110
Total number of IP addresses required = 2 * 110 = 220

Per node mask size = /24
Number of IP addresses in a /24 = 2(32 - 24) = 256

קובעים את מסכת ה-CIDR של הפוד שצריך להגדיר עבור אשכול Kubernetes, על סמך מספר הצמתים הנדרש. תכננו מראש את הוספת הצמתים העתידיים לאשכול בזמן הגדרת טווח ה-CIDR:

  Total number of nodes supported = 2(Per node mask size - pod CIDR mask)

בהנחה שיש גודל מסכת ברירת מחדל לכל צומת = ‎ /24 , אפשר לעיין בטבלה הבאה שבה ממופה מסכת ה-CIDR של ה-pod למספר הצמתים הנתמכים.

מסכת CIDR של ה-Pod	חישוב: ‫2^(גודל המסיכה לכל צומת – מסיכת CIDR)	המספר המקסימלי של צמתים שנתמכים, כולל צמתים של מישור הבקרה
/21	‫2^(24 - 21)	8
/20	‫2^(24-20)	16
/19	‫2^(24 - 19)	32
/18	‫2^(24 - 18)	64

אזהרה: אם מספקים מסכת CIDR לא מספיק גדולה, יכול להיות שיצירת האשכול תיתקע בשלב של התאמה, והפודים יציגו את הסטטוס CrashLoopBackOff.

אחרי שמחשבים את בלוק ה-CIDR של הפודים עבור אשכול Kubernetes, מגדירים אותו כחלק מתהליך העבודה ליצירת האשכול בקטע הבא.

יצירת אשכול משותף

כדי ליצור אשכול Kubernetes משותף:

המסוף

1. בתפריט הניווט, בוחרים באפשרות Kubernetes Engine > Clusters.

   חשוב: שימו לב שאי אפשר לבחור פרויקט בכלי לבחירת היקף כשיוצרים אשכול משותף. הסיבה לכך היא שהאשכול מוגבל לארגון. מידע נוסף זמין במאמר בנושא היררכיית המשאבים.

2. לוחצים על יצירת אשכול.

3. בשדה Name (שם), מציינים שם לאשכול.

4. בוחרים את גרסת Kubernetes לאשכול.

5. בוחרים את האזור שבו רוצים ליצור את האשכול.

6. לוחצים על Attach Project (צירוף פרויקט) ובוחרים פרויקט קיים לצירוף לאשכול. לאחר מכן לוחצים על שמירה. אחרי שיוצרים את האשכול, אפשר לצרף או לנתק פרויקטים מדף פרטי הפרויקט. כדי לפרוס עומסי עבודה של קונטיינרים באשכול, צריך לצרף אליו פרויקט.

   

7. לוחצים על הבא.

8. קובעים את הגדרות הרשת של האשכול. אי אפשר לשנות את הגדרות הרשת האלה אחרי שיוצרים את האשכול. פרוטוקול האינטרנט שנתמך באשכולות Kubernetes כברירת מחדל הוא גרסה 4 של פרוטוקול האינטרנט (IPv4).

   1. אם רוצים ליצור צמתים ייעודיים של מאזן עומסים, מזינים את מספר הצמתים שרוצים ליצור. כברירת מחדל, מקבלים אפס צמתים, והתנועה של איזון העומסים עוברת דרך צמתי הבקרה.

   2. בוחרים את Service CIDR (Classless Inter-Domain Routing) שרוצים להשתמש בו. לשירותים שפרסתם, כמו מאזני עומסים, מוקצות כתובות IP מהטווח הזה.

      חשוב: הטווח יכול להיות כל טווח RFC 1918 שלא מתנגש עם טווחי כתובות IP אחרים במשאבי מאגר הצמתים והאשכול. מידע נוסף זמין ב-RFC 1918.

   3. בוחרים את Pod CIDR שרוצים להשתמש בו. האשכול מקצה כתובות IP מהטווח הזה ל-Pods ולמכונות הווירטואליות.

   4. לוחצים על הבא.

9. בודקים את הפרטים של מאגר הצמתים שנוצר אוטומטית כברירת מחדל עבור האשכול. לוחצים על Edit כדי לשנות את ברירת המחדל של מאגר הצמתים.

   חשוב: אם אתם מתכוונים להריץ באשכול עומסי עבודה של יחידת עיבוד גרפי (GPU), אתם צריכים להקצות סוג מכונה של GPU באשכול. מידע נוסף מופיע במאמר בנושא עומסי עבודה של GPU באשכול Kubernetes.

10. כדי ליצור עוד מאגרי צמתים, לוחצים על הוספת מאגר צמתים. כשעורכים את מאגר הצמתים שמוגדר כברירת מחדל או מוסיפים מאגר צמתים חדש, אפשר להתאים אותו אישית באמצעות האפשרויות הבאות:

    1. נותנים שם למאגר הצמתים. אי אפשר לשנות את השם אחרי שיוצרים את מאגר הצמתים.
    2. מציינים את מספר צמתי העובדים שייווצרו במאגר הצמתים.

    3. בוחרים את סוג המכונה שהכי מתאים לדרישות של עומס העבודה. רשימת ההגדרות הבאות:

       • סוג המכונה
       • CPU
       • זיכרון

    4. לוחצים על Save.

11. לוחצים על Create (יצירה) כדי ליצור את האשכול.

יצירת אשכול משותף יכולה להימשך עד 90 דקות.

API

1. יוצרים את המשאב המותאם אישית Cluster:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: cluster.gdc.goog/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: platform
   spec:
     clusterNetwork:
       podCIDRSize: POD_CIDR
       serviceCIDRSize: SERVICE_CIDR
     initialVersion:
       kubernetesVersion: KUBERNETES_VERSION
     nodePools:
     - machineTypeName: MACHINE_TYPE
       name: NODE_POOL_NAME
       nodeCount: NUMBER_OF_WORKER_NODES
       taints: TAINTS
       labels: LABELS
       acceleratorOptions:
         gpuPartitionScheme: GPU_PARTITION_SCHEME
     releaseChannel:
       channel: UNSPECIFIED
   EOF
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫MANAGEMENT_API_SERVER: הנתיב של קובץ ה-kubeconfig של שרת ה-API האזורי.
   • ‫CLUSTER_NAME: שם האשכול. שם האשכול לא יכול להסתיים ב--system. הסיומת -system שמורה לאשכולות שנוצרו על ידי GDC.
   • ‫POD_CIDR: הגודל של טווחי הרשת שמהם מוקצות כתובות IP וירטואליות של פודים. אם לא מגדירים את המדיניות, המערכת תשתמש בערך ברירת המחדל 21.
   • ‫SERVICE_CIDR: הגודל של טווחי הרשת שמהם מוקצות כתובות IP וירטואליות של שירותים. אם לא מגדירים את המדיניות, המערכת תשתמש בערך ברירת המחדל 23.
   • ‫KUBERNETES_VERSION: גרסת Kubernetes של האשכול, למשל 1.26.5-gke.2100. כדי לראות את רשימת הגרסאות הזמינות של Kubernetes שאפשר להגדיר, אפשר לעיין במאמר רשימת הגרסאות הזמינות של Kubernetes לאשכול.
   • ‫MACHINE_TYPE: סוג המכונה של צמתי העובדים במאגר הצמתים. אפשר לראות את סוגי המכונות הזמינים להגדרה.
   • ‫NODE_POOL_NAME: השם של מאגר הצמתים.
   • ‫NUMBER_OF_WORKER_NODES: מספר צמתי העובדים שיוקצו במאגר הצמתים.
   • ‫TAINTS: ההכתמות שיחולו על הצמתים במאגר הצמתים הזה. השדה הזה אופציונלי.
   • ‫LABELS: התוויות שיוחלו על הצמתים במאגר הצמתים הזה. הוא מכיל רשימה של צמדי מפתח/ערך. זהו שדה אופציונלי.
   • ‫GPU_PARTITION_SCHEME: תוכנית החלוקה של ה-GPU, אם מריצים עומסי עבודה של GPU. השדה הזה אופציונלי. לדוגמה, mixed-2. אם השדה הזה לא מוגדר, ה-GPU לא מחולק למחיצות. מידע נוסף על פרופילי MIG זמינים מופיע במאמר פרופילי MIG נתמכים.
   חשוב: אי אפשר לערוך את ההגדרות של הצומת, כמו חלוקת ה-GPU, אחרי שיוצרים מאגר צמתים של אשכול.

   יצירת אשכול משותף יכולה להימשך עד 90 דקות.

2. יוצרים את המשאב המותאם אישית ProjectBinding:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: resourcemanager.gdc.goog/v1
   kind: ProjectBinding
   metadata:
     name: CLUSTER_NAME-PROJECT_NAME
     namespace: platform
     labels:
       resourcemanager.gdc.goog/projectbinding-for-user-project: "true"
   spec:
     clusterRef:
       name: CLUSTER_NAME
     selector:
       nameSelector:
         matchNames:
         - PROJECT_NAME
   EOF
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫MANAGEMENT_API_SERVER: הנתיב של קובץ ה-kubeconfig של שרת ה-API האזורי.
   • ‫CLUSTER_NAME: שם האשכול.
   • ‫PROJECT_NAME: שם הפרויקט שאליו רוצים לקשר. כל משאב ProjectBinding יכול להיות ממופה רק לאשכול אחד. אם פרויקט דורש גישה לכמה אשכולות, צריך ליצור ProjectBinding ייחודי לכל אשכול.

   כדי שמפתחים יוכלו לפרוס עומסי עבודה של קונטיינרים באשכול, צריך לצרף פרויקט לאשכול.

Terraform

1. בקובץ תצורה של Terraform, מוסיפים את קטע הקוד הבא כדי ליצור את המשאב המותאם אישית Cluster:

   provider "kubernetes" {
     config_path = "MANAGEMENT_API_SERVER"
   }
   
   resource "kubernetes_manifest" "CLUSTER_RESOURCE_NAME" {
     manifest = {
       "apiVersion" = "cluster.gdc.goog/v1"
       "kind" = "Cluster"
       "metadata" = {
         "name" = "CLUSTER_NAME"
         "namespace" = "platform"
       }
       "spec" = {
         "clusterNetwork" = {
           "podCIDRSize" = "POD_CIDR"
           "serviceCIDRSize" = "SERVICE_CIDR"
         }
         "initialVersion" = {
           "kubernetesVersion" = "KUBERNETES_VERSION"
         }
         "nodePools" = [{
           "machineTypeName" = "MACHINE_TYPE"
           "name" = "NODE_POOL_NAME"
           "nodeCount" = "NUMBER_OF_WORKER_NODES"
           "taints" = "TAINTS"
           "labels" = "LABELS"
           "acceleratorOptions" = {
             "gpuPartitionScheme" = "GPU_PARTITION_SCHEME"
           }
         }]
         "releaseChannel" = {
           "channel" = "UNSPECIFIED"
         }
       }
     }
   }
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫MANAGEMENT_API_SERVER: הנתיב של קובץ ה-kubeconfig של שרת ה-API האזורי.
   • ‫CLUSTER_RESOURCE_NAME: השם הייחודי של משאב Terraform באשכול, למשל cluster-1. השם הזה משמש את Terraform לזיהוי האשכול שלכם, ולא משמש את GDC.
   • ‫CLUSTER_NAME: שם האשכול. שם האשכול לא יכול להסתיים ב--system. הסיומת -system שמורה לאשכולות שנוצרו על ידי GDC.
   • ‫POD_CIDR: הגודל של טווחי הרשת שמהם מוקצות כתובות IP וירטואליות של פודים. אם לא מגדירים את המדיניות, המערכת תשתמש בערך ברירת המחדל 21.
   • ‫SERVICE_CIDR: הגודל של טווחי הרשת שמהם מוקצות כתובות IP וירטואליות של שירותים. אם לא מגדירים את המדיניות, המערכת תשתמש בערך ברירת המחדל 23.
   • ‫KUBERNETES_VERSION: גרסת Kubernetes של האשכול, למשל 1.26.5-gke.2100. כדי לראות את רשימת הגרסאות הזמינות של Kubernetes שאפשר להגדיר, אפשר לעיין במאמר רשימת הגרסאות הזמינות של Kubernetes לאשכול.
   • ‫MACHINE_TYPE: סוג המכונה של צמתי העובדים במאגר הצמתים. אפשר לראות את סוגי המכונות הזמינים להגדרה.
   • ‫NODE_POOL_NAME: השם של מאגר הצמתים.
   • ‫NUMBER_OF_WORKER_NODES: מספר צמתי העובדים שיוקצו במאגר הצמתים.
   • ‫TAINTS: ההכתמות שיחולו על הצמתים במאגר הצמתים הזה. השדה הזה אופציונלי.
   • ‫LABELS: התוויות שיוחלו על הצמתים במאגר הצמתים הזה. הוא מכיל רשימה של צמדי מפתח/ערך. זהו שדה אופציונלי.
   • ‫GPU_PARTITION_SCHEME: תוכנית החלוקה של ה-GPU, אם מריצים עומסי עבודה של GPU. השדה הזה אופציונלי. לדוגמה, mixed-2. אם השדה הזה לא מוגדר, ה-GPU לא מחולק למחיצות. מידע נוסף על פרופילי MIG זמינים מופיע במאמר פרופילי MIG נתמכים.

2. בקובץ תצורה של Terraform, מוסיפים את קטע הקוד הבא כדי ליצור את המשאב המותאם אישית ProjectBinding:

   provider "kubernetes" {
     config_path = "MANAGEMENT_API_SERVER"
   }
   
   resource "kubernetes_manifest" "PROJECT_BINDING_RESOURCE_NAME" {
     manifest = {
       "apiVersion" = "resourcemanager.gdc.goog/v1"
       "kind" = "ProjectBinding"
       "metadata" = {
         "name" = "CLUSTER_NAME-PROJECT_NAME"
         "namespace" = "platform"
         "labels" = {
           "resourcemanager.gdc.goog/projectbinding-for-user-project" = "true"
         }
       }
       "spec" = {
         "clusterRef" = {
           "name" = "CLUSTER_NAME"
         }
         "selector" = {
           "nameSelector" = {
             "matchNames" = [
               "PROJECT_NAME",
             ]
           }
         }
       }
     }
   }
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫MANAGEMENT_API_SERVER: הנתיב של קובץ ה-kubeconfig של שרת ה-API האזורי.
   • ‫PROJECT_BINDING_RESOURCE_NAME: שם משאב Terraform של הקישור לפרויקט, למשל project-binding-1. השם הזה משמש את Terraform כדי לזהות את הקישור של הפרויקט, ולא משמש את GDC.
   • ‫CLUSTER_NAME: שם האשכול.
   • ‫PROJECT_NAME: שם הפרויקט שאליו רוצים לקשר. כל משאב ProjectBinding יכול להיות ממופה רק לאשכול אחד. אם פרויקט דורש גישה לכמה אשכולות, צריך ליצור ProjectBinding ייחודי לכל אשכול.

   כדי שמפתחים יוכלו לפרוס עומסי עבודה של קונטיינרים באשכול, צריך לצרף פרויקט לאשכול.

3. מחילים את המשאבים המותאמים אישית החדשים באמצעות Terraform:

   terraform apply
   

יצירת אשכול משותף יכולה להימשך עד 90 דקות.

המאמרים הבאים

• פריסת אפליקציית קונטיינר עם זמינות גבוהה
• עומסי עבודה של קונטיינרים ב-GDC
• היררכיית המשאבים