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

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

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

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

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

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

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

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

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