יצירת אשכול משתמשים לשימוש עם דומיינים של טופולוגיה

ב-Google Distributed Cloud, עומסי העבודה פועלים באשכול משתמש אחד או יותר. בדף הזה מוסבר איך ליצור אשכול משתמש לשימוש בדומיינים של טופולוגיה ב-Google Distributed Cloud. כדי להשתמש בדומיינים של טופולוגיה, צריך את Google Distributed Cloud בגרסה 1.31 ואילך.

כדי להגדיר דומיין טופולוגיה, צריך להפעיל אשכול מתקדם.

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

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

סקירה כללית של התהליך

אלה השלבים העיקריים ליצירת אשכול משתמש באמצעות gkectl:

  1. מילוי קובץ התצורה של אשכול המשתמשים
    מציינים את פרטי האשכול החדש בקובץ התצורה של אשכול המשתמש.
  2. ממלאים את קובץ חסימת כתובות ה-IP
    מציינים את כתובות ה-IP של השער, מסכת הרשת, צומתי מישור הבקרה, ואם רוצים, גם צומתי העובדים בקובץ בלוקים של כתובות IP.
  3. יצירת אשכול משתמשים
    מריצים את הפקודה gkectl create cluster כדי ליצור אשכול כמו שצוין בקובצי התצורה.
  4. איך מוודאים שאשכול המשתמשים פועל
    משתמשים ב-kubectl כדי להציג את הצמתים באשכול.

בסיום התהליך, יהיה לכם אשכול משתמשים פעיל שבו תוכלו לפרוס את עומסי העבודה.

מילוי קובץ התצורה של אשכול המשתמשים

אם השתמשתם ב-gkeadm כדי ליצור את תחנת העבודה של האדמין, gkeadm יצר תבנית לקובץ התצורה של אשכול המשתמשים בשם user-cluster.yaml. בנוסף, gkeadm מילא בשבילך חלק מהשדות.

אם לא השתמשתם ב-gkeadm כדי ליצור את תחנת העבודה של האדמין, אתם יכולים להשתמש ב-gkectl כדי ליצור תבנית לקובץ התצורה של אשכול המשתמשים.

כדי ליצור תבנית לקובץ התצורה של אשכול המשתמש:

gkectl create-config cluster --config=OUTPUT_FILENAME --gke-on-prem-version=VERSION

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

‫OUTPUT_FILENAME: נתיב לבחירתכם לתבנית שנוצרה. אם לא משתמשים בדגל הזה, gkectl נותן לקובץ את השם user-cluster.yaml וממקם אותו בספרייה הנוכחית.

‫VERSION: מספר הגרסה הרצויה. לדוגמה: gkectl create-config cluster --gke-on-prem-version=1.36.200-gke.118.

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

name

בשדה name נותנים שם לאשכול המשתמש.

gkeOnPremVersion

השדה הזה כבר מלא. הוא מציין את הגרסה של Google Distributed Cloud. לדוגמה, 1.36.200-gke.118.

enableAdvancedCluster

מגדירים את enableAdvancedCluster לערך true.

enableControlplaneV2

צריך להשתמש ב-Controlplane V2 בכל אשכולות המשתמשים מגרסה 1.30 ואילך. מגדירים את enableControlplaneV2 לערך true.

כשהתכונה Controlplane V2 מופעלת, מישור הבקרה של אשכול המשתמש פועל בצמתים באשכול המשתמש עצמו.

enableDataplaneV2

מגדירים את enableDataplaneV2 לערך true.

vCenter

הסרת כל הקטע הזה. במקום זאת, מגדירים את פרטי ה-vCenter בקובץ התצורה של תשתית vSphere לכל דומיין טופולוגיה.

network

  • מסירים את השורות הבאות מקובץ התצורה:

    • כל הקטע network.hostConfig. המידע הזה מוגדר בקובץ התצורה של תשתית vSphere לכל דומיין טופולוגיה.
    • השדה network.vCenter.networkName. השדה הזה מוגדר בקובץ התצורה של תשתית vSphere לכל דומיין טופולוגיה.
    • כל הקטע network.controlPlaneIPBlock. כתובות ה-IP של השער, מסכת הרשת והצמתים של מישור הבקרה מוגדרות בקובץ בלוק IP.

  • מגדירים את network.ipMode.ipBlockFilePath לנתיב של קובץ חסימת ה-IP.

  • מחליטים איך צומתי העובדים יקבלו את כתובות ה-IP שלהם. האפשרויות הן:

    • משרת DHCP שהגדרתם מראש. מגדירים את network.ipMode.type לערך "dhcp".

    • מרשימה של כתובות IP סטטיות שאתם מספקים בקובץ חסימת ה-IP. מגדירים את network.ipMode.type להיות "static".

    הצמתים של מישור הבקרה באשכול המשתמש צריכים לקבל את כתובות ה-IP שלהם מרשימה של כתובות סטטיות שאתם מספקים בקובץ של טווח כתובות ה-IP. זה נכון גם אם צומתי העובדים מקבלים את הכתובות שלהם משרת DHCP.

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

  • הערכים של network.podCIDR ו-network.serviceCIDR מאוכלסים מראש, ואפשר להשאיר אותם ללא שינוי, אלא אם הם מתנגשים עם כתובות שכבר נמצאות בשימוש ברשת. ‫Kubernetes משתמש בטווחים האלה כדי להקצות כתובות IP ל-Pods ולשירותים באשכול.

loadBalancer

advancedNetworking

אם אתם מתכננים ליצור שער NAT לתעבורת נתונים יוצאת, צריך להגדיר את advancedNetworking לערך true.

multipleNetworkInterfaces

מגדירים את multipleNetworkInterfaces לערך false. אין תמיכה בכמה ממשקי רשת לפודים עם דומיינים של טופולוגיה.

storage

מגדירים את storage.vSphereCSIDisabled לערך true כדי להשבית את הפריסה של רכיבי vSphere CSI.

masterNode

  • אם רוצים לציין את המעבד (CPU) והזיכרון לצומתי מישור הבקרה של אשכול המשתמש, ממלאים את השדות cpus ו-memoryMB בקטע masterNode.

  • יש תמיכה רק באשכולות בזמינות גבוהה (HA). מגדירים את השדה replicas לערך 3 כדי לציין שבאשכול יהיו שלושה צומתי מישור בקרה.

  • כדי לאפשר שינוי גודל אוטומטי של צומתי מישור הבקרה, מגדירים את autoResize.enabled ל-true.

  • מסירים את כל הקטע masterNode.vsphere.

  • בשדה masterNode.topologyDomains ממלאים את השם של דומיין הטופולוגיה שבו רוצים שיהיו צומתי מישור הבקרה.

nodePools

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

לכל מאגר צמתים שאתם מציינים:

  • בשדה nodePools[i].topologyDomains, ממלאים את השם של דומיין הטופולוגיה שבו רוצים שמאגר הצמתים יהיה.

  • מסירים את כל השדות בקטע nodePools[i].vsphere חוץ מהשדה nodePools[i].vsphere.tags. אתם מציינים את המידע הזה בקובץ התצורה של תשתית vSphere לכל דומיין טופולוגיה.

  • מגדירים את nodePools[i].osImageType לערך ubuntu_cgv2.

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

antiAffinityGroups

מגדירים את antiAffinityGroups.enabled לערך false. כללי אנטי-אפיניות של Distributed Resource Scheduler (DRS) לא נתמכים בדומיינים של טופולוגיה.

stackdriver

ממלאים את הקטע stackdriver כדי להפעיל את Cloud Logging ו-Cloud Monitoring באשכול.

שימו לב לדרישות הבאות:

  • המזהה ב-stackdriver.projectID צריך להיות זהה למזהה ב-gkeConnect.projectID וב-cloudAuditLogging.projectID.

  • האזור של Google Cloud שמוגדר ב-stackdriver.clusterLocation צריך להיות זהה לאזור שמוגדר ב-cloudAuditLogging.clusterLocation וב-gkeConnect.location. בנוסף, אם הערך של gkeOnPremAPI.enabled הוא true, צריך להגדיר את אותו אזור ב-gkeOnPremAPI.location.

אם מזהי הפרויקטים והאזורים לא זהים, יצירת האשכול תיכשל.

gkeConnect

אשכול המשתמשים צריך להיות רשום ב- Google Cloud fleet.

ממלאים את הקטע gkeConnect כדי לציין פרויקט מארח של Fleet ואת חשבון השירות שמשויך אליו. המזהה ב-gkeConnect.projectID צריך להיות זהה למזהה שמוגדר ב-stackdriver.projectID וב-cloudAuditLogging.projectID. אם מזהי הפרויקטים לא זהים, יצירת האשכול תיכשל.

אפשר גם לציין אזור שבו פועלים שירותי ה-fleet ו-Connect ב-gkeConnect.location. אם לא כוללים את השדה הזה, האשכול משתמש במכונות הגלובליות של השירותים האלה.

אם אתם כוללים את gkeConnect.location בקובץ התצורה, האזור שאתם מציינים צריך להיות זהה לאזור שהוגדר ב-cloudAuditLogging.clusterLocation, ב-stackdriver.clusterLocation וב-gkeOnPremAPI.location. אם האזורים לא זהים, יצירת האשכול תיכשל.

gkeOnPremAPI

בקטע הזה מוסבר איך רושמים אשכולות ב-GKE On-Prem API.

כלי שורת הפקודה gkectl הוא כלי ניהול מחזור החיים היחיד של אשכולות שמשתמשים בדומיינים של טופולוגיה. למרות שאי אפשר להשתמש במסוף Google Cloud , ב-Google Cloud CLI וב-Terraform באשכולות עם דומיינים של טופולוגיה, אפשר לרשום את האשכול ל-GKE On-Prem API כשיוצרים אותו.

אם GKE On-Prem API מופעל בפרויקט ב-Google Cloud , כל האשכולות בפרויקט רשומים אוטומטית ב-GKE On-Prem API באזור שהוגדר ב-stackdriver.clusterLocation. האזור של gkeOnPremAPI.location חייב להיות זהה לאזור שצוין ב-cloudAuditLogging.clusterLocation, ב-gkeConnect.location וב-stackdriver.clusterLocation.

  • אם אתם רוצים לרשום את כל האשכולות בפרויקט ל-GKE On-Prem API, הקפידו לבצע את השלבים שמפורטים בקטע לפני שמתחילים כדי להפעיל את GKE On-Prem API בפרויקט ולהשתמש בו.

  • אם אתם לא רוצים לרשום את האשכול ב-GKE On-Prem API, צריך לכלול את הקטע הזה ולהגדיר את gkeOnPremAPI.enabled כ-false. אם אתם לא רוצים לרשום אשכולות בפרויקט, השביתו את gkeonprem.googleapis.com (שם השירות של GKE On-Prem API) בפרויקט. הוראות מפורטות זמינות במאמר השבתת שירותים.

cloudAuditLogging

אם אתם רוצים לשלב את יומני הביקורת משרת ה-API של Kubernetes באשכול עם יומני הביקורת של Cloud, מלאו את הקטע cloudAuditLogging.

שימו לב לדרישות הבאות:

# advanced-cluster-change #

מגדירים את cloudAuditLogging.serviceAccountKeyPath לאותו נתיב כמו stackdriver.serviceAccountKeyPath.

  • המזהה ב-cloudAuditLogging.projectID צריך להיות זהה למזהה ב-gkeConnect.projectID וב-stackdriver.projectID.

  • האזור ב-cloudAuditLogging.clusterLocation צריך להיות זהה לאזור שמוגדר ב-gkeConnect.location (אם השדה נכלל בקובץ התצורה) וב-stackdriver.clusterLocation. בנוסף, אם הערך של gkeOnPremAPI.enabled הוא true, צריך להגדיר את אותו אזור ב-gkeOnPremAPI.location.

אם מזהי הפרויקטים והאזורים לא זהים, יצירת האשכול תיכשל.

preparedSecrets

מסירים את השדה preparedSecrets. אי אפשר להשתמש בפרטי כניסה מוכנים מראש כשדומיינים של טופולוגיה מופעלים.

schedulerConfiguration

אם רוצים להגדיר הגדרות נוספות שיועברו אל kube-scheduler, מוסיפים את הקטע schedulerConfiguration לקובץ התצורה.

דוגמה לקובצי תצורה מלאים

דוגמה לקובץ בלוק IP ולקובץ תצורה של אשכול משתמש:

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4
  - netmask: 255.255.255.0
    gateway: 100.115.223.254
    ips:
    - ip: 100.115.222.205
      hostname: cp-1
      isControlPlane: true
    - ip: 100.115.222.206
      hostname: cp-2
      isControlPlane: true
    - ip: 100.115.222.207
      hostname: cp-3
      isControlPlane: true

user-cluster.yaml

cat user-cluster.yaml
apiVersion: v1
kind: UserCluster
name: "my-user-cluster"
gkeOnPremVersion: 1.36.200-gke.118
enableAdvancedCluster: true
enableControlplaneV2: true
enableDataplaneV2: true
network:
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  serviceCIDR: 10.96.0.0/20
  podCIDR: 192.168.0.0/16
loadBalancer:
  vips:
    controlPlaneVIP: "100.115.222.200"
    ingressVIP: "172.16.21.30"
  kind: "ManualLB"
  manualLB:
    ingressHTTPNodePort: 32527
    ingressHTTPSNodePort: 30139
    controlPlaneNodePort: 30968
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool1"
  cpus: 4
  memoryMB: 8192
  replicas: 3
  topologyDomains:
  - "domain1"
antiAffinityGroups:
  enabled: false
gkeConnect:
  projectID: "my-project-123"
  location: "us-central1"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  enableVPC: false
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true

אלה הנקודות החשובות שצריך להבין בדוגמה שלמעלה:

  • השדה nodePools.replicas מוגדר ל-3, כלומר יש שלושה צומתי עובדים ב-"worker-node-pool". כל הצמתים העובדים משתמשים בכתובות IP סטטיות כי network.ipMode.type מוגדר ל-"static".

  • כתובות ה-IP של צומתי מישור הבקרה וצומתי העובדים מצוינות בקובץ בלוק IP. בקובץ בלוק ה-IP יש ארבע כתובות לצומתי עובדים, למרות שיש רק שלושה צומתי עובדים. כתובת ה-IP הנוספת של צומת העובד נדרשת במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול. כתובות ה-IP של צומתי מישור הבקרה כוללות את הדגל isControlPlane: true.

  • אשכולות מתקדמים, Controlplane V2 ו-Dataplane V2 מופעלים.

  • השדה masterNode.replicas מוגדר ל-3, כך שלמישור הבקרה של האשכול תהיה זמינות גבוהה.

  • כתובת ה-VIP של מישור הבקרה נמצאת באותה רשת VLAN כמו הצמתים של מישור הבקרה, וכתובת ה-VIP של Ingress נמצאת באותה רשת VLAN כמו הצמתים של ה-worker.

ממלאים את קובץ חסימת כתובות ה-IP

מעתיקים את התבנית של קובץ בלוק ה-IP לקובץ בספרייה שציינתם בשדה network.ipMode.ipBlockFilePath בקובץ ההגדרות של אשכול המשתמש. יוצרים קובצי בלוקים של כתובות IP נפרדים לאשכול האדמין ולכל אשכול משתמשים.

מוסיפים לקובץ של בלוק ה-IP את כתובות ה-IP של השער, מסכת הרשת והצמתים של מישור הבקרה. לכל כתובת IP של צומת במישור הבקרה, מוסיפים את isControlPlane: true כמו בדוגמה הקודמת. אם רוצים אשכול משתמשים בזמינות גבוהה (HA), צריך לציין שלוש כתובות IP. אחרת, צריך לציין כתובת IP אחת. מספר כתובות ה-IP שאתם מציינים לצומתי מישור הבקרה צריך להתאים למספר בשדה masterNode.replicas בקובץ התצורה של אשכול המשתמשים.

אם הערך של network.ipMode.type הוא "static", צריך להוסיף את כתובות ה-IP של הצמתים העובדים לקובץ של בלוק ה-IP. חשוב לציין כתובת IP אחת נוספת לשימוש במהלך שדרוג, עדכון ותיקון אוטומטי של האשכול.

כל כתובת שער בקובץ בלוק ה-IP צריכה להתאים לכתובת שצוינה בשדה topologyDomains[i].network.gateway בקובץ התצורה של תשתית vSphere. מידע נוסף זמין בדוגמה לדומיינים של טופולוגיה.

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

מריצים את הפקודה הבאה כדי ליצור אשכול משתמש:

gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

איתור קובץ kubeconfig של אשכול המשתמשים

הפקודה gkectl create cluster יוצרת קובץ kubeconfig בשם USER_CLUSTER_NAME-kubeconfig בספרייה הנוכחית. תצטרכו את קובץ ה-kubeconfig הזה בהמשך כדי ליצור אינטראקציה עם אשכול המשתמשים.

קובץ ה-kubeconfig מכיל את השם של אשכול המשתמש. כדי לראות את שם האשכול, אפשר להריץ את הפקודה:

kubectl config get-clusters --kubeconfig USER_CLUSTER_KUBECONFIG

בפלט מוצג שם האשכול. לדוגמה:

NAME
my-user-cluster

אם רוצים, אפשר לשנות את השם והמיקום של קובץ kubeconfig.

איך מוודאים שאשכול המשתמשים פועל

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

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

מחליפים את USER_CLUSTER_KUBECONFIG בנתיב של קובץ ה-kubeconfig של אשכול המשתמש.

הפלט מציג את הצמתים של אשכול המשתמשים. לדוגמה:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

הגדרת PodTemplate

תווית הטופולוגיה מאוכלסת בתוויות של צמתים בדומיין הטופולוגיה. אם לא השתמשתם באילוץ ברירת המחדל "topology.kubernetes.io/zone" כמפתח הטופולוגיה בהגדרת הדומיין של הטופולוגיה, תצטרכו להגדיר את מפתח הטופולוגיה בתבנית ה-Pod של ה-Deployment, ה-StatefulSet או ה-ReplicaSet, לפי הצורך.

לדוגמה, נניח שהגדרתם את המפתח בתווית הטופולוגיה בתור "topology.examplepetstore.com/zone". ב-PodTemplate, מציינים את המפתח כערך של השדה topologySpreadConstraints.topologyKey. כך מתזמן Kubernetes יכול להפיץ Pods בדומיין הטופולוגיה כדי להבטיח זמינות גבוהה ולמנוע ריכוז יתר באזור אחד במקרה של כשל.

פתרון בעיות

פתרון בעיות ביצירה ובשדרוג של אשכולות

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