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

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

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

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

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

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

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

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

תכנון בלוק ה-CIDR של ה-Pod

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

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

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

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

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 של ה-Pod שצריך להגדיר לאשכול Kubernetes, על סמך מספר הצמתים הנדרש. כשמגדירים את טווח ה-CIDR, כדאי לתכנן מראש הוספה של צמתים לאשכול בעתיד:

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

‫Per node mask size= /24 הוא ערך ברירת המחדל. בטבלה הבאה מפורט המיפוי של מסכת ה-CIDR של הפוד למספר הצמתים הנתמכים.

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

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

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

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

המסוף

  1. בכלי לבחירת פרויקטים, בוחרים את הארגון.

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

  2. בתפריט הניווט, לוחצים על Kubernetes Engine > Clusters.

  3. לוחצים על Create Cluster.

  4. בשדה Name, נותנים שם לאשכול.

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

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

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

    יוצרים אשכול באמצעות המסוף.

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

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

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

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

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

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

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

  11. כדי ליצור מאגרי צמתים נוספים, לוחצים על Add Node Pool. כשעורכים את מאגר ברירת המחדל של הצמתים או כשמוסיפים מאגר צמתים חדש, אפשר להתאים אותו אישית באמצעות האפשרויות הבאות:

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

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

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

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

  12. לוחצים על 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: ה-taints שיוחלו על הצמתים של מאגר הצמתים הזה. השדה הזה אופציונלי.
    • ‫LABELS: התוויות שיוחלו על הצמתים במאגר הצמתים הזה. הוא מכיל רשימה של צמדי מפתח/ערך. השדה הזה אופציונלי.
    • ‫GPU_PARTITION_SCHEME: סכימת החלוקה למחיצות של ה-GPU, אם אתם מריצים עומסי עבודה ב-GPU. השדה הזה אופציונלי. לדוגמה, mixed-2. אם השדה הזה לא מוגדר, ה-GPU לא מחולק למחיצות. מידע נוסף על פרופילים זמינים של GPU עם כמה מופעים במקביל (MIG) זמין במאמר פרופילים נתמכים של MIG.

    יצירת אשכול משותף יכולה להימשך עד 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: ה-taints שיוחלו על הצמתים של מאגר הצמתים הזה. השדה הזה אופציונלי.
    • ‫LABELS: התוויות שיוחלו על הצמתים במאגר הצמתים הזה. הוא מכיל רשימה של צמדי מפתח/ערך. השדה הזה אופציונלי.
    • ‫GPU_PARTITION_SCHEME: סכימת החלוקה למחיצות של ה-GPU, אם אתם מריצים עומסי עבודה ב-GPU. השדה הזה אופציונלי. לדוגמה, mixed-2. אם השדה הזה לא מוגדר, ה-GPU לא מחולק למחיצות. מידע נוסף על פרופילים זמינים של 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 דקות.

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