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

במאמר הזה מוסבר איך ליצור אשכול 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 לכל צומת.
  • הבלוק תמיד מכיל לפחות פי שניים כתובות ממספר הפודים המקסימלי לכל צומת.

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

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

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

מסכת CIDR של Pod חישוב: ‎2(Per node mask size - CIDR mask)‎ המספר המקסימלי של צמתים נתמכים, כולל צמתים של מישור הבקרה
/21 2(24 - 21) 8
/20 ‫2(24-20) 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 דקות.

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