‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

עדכון אשכולות

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

התמיכה בכלים תלויה בסוג האשכול ובמשאבים שאתם משנים:

ב-CLI של gcloud וב-Terraform אפשר לעדכן רק אשכולות אדמין ואשכולות משתמשים. כדי לעדכן סוגים אחרים של אשכולות, צריך להשתמש ב-bmctl.
ה-CLI של gcloud ו-Terraform תומכים רק בשינויים במשאבים מסוג Cluster ו-NodePool. כדי לעדכן משאבים מותאמים אישית אחרים שמשפיעים על האשכול, צריך להשתמש ב-kubectl או ב-bmctl.

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

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

באופן כללי, כדי לעדכן אשכול מבצעים את רצף הפעולות הבא:

`bmctl`

משנים את הערכים של השדות הרלוונטיים בקובץ התצורה של האשכול, שכברירת מחדל נמצא כאן:
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
מעדכנים את האשכול באמצעות הפקודה bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם האשכול שרוצים לעדכן.
- ‫KUBECONFIG: באשכולות של אדמין, היברידיים או עצמאיים, מזינים את הנתיב לקובץ kubeconfig של האשכול. באשכול משתמש, מזינים את הנתיב לקובץ kubeconfig של אשכול האדמין.

אל תשתמשו ב-bmctl update וב-kubectl apply -f לסירוגין כשאתם עורכים את קובץ התצורה של האשכול. כשמשתמשים בפקודות האלה לסירוגין, יכול להיות שתוכן שמאוכלס על ידי הכותרת של מפרט האשכול יוסר בטעות. לדוגמה, אתם יכולים להשתמש ב-bmctl update כדי לעדכן את קובץ התצורה של האשכול כדי להגדיר שיקוף של המרשם. לאחר מכן, האשכול מאוכלס ב-spec.nodeConfig.registryMirrors אחרי ההתאמה.

אם תנסו לשנות את האשכול באמצעות הגדרת האשכול עם הפקודה kubectl apply -f, השדה spec.nodeConfig.registryMirrors שמאוכלס על ידי ה-reconciler באשכול יוסר. זה קורה כי ההגדרה לא קיימת במפרט של הגדרת האשכול, אבל היא קיימת באשכול.

‫CLI של gcloud

ציינו רק את הדגלים של ההגדרות שאתם רוצים לשנות.
מריצים את פקודת העדכון הרלוונטית:
- אשכולות אדמין: gcloud container bare-metal admin-clusters update
- אשכולות משתמשים: gcloud container bare-metal clusters update.
- מאגרי צמתים באשכול משתמש: gcloud container bare-metal node-pools update

Terraform

משנים את הערכים של השדות הרלוונטיים בקובץ התצורה של Terraform שבו השתמשתם כדי ליצור את האשכול או את מאגר הצמתים. במאמרי העזרה של Terraform יש תיאורים מפורטים של השדות:
מעדכנים את ההגדרות באמצעות הפקודה terraform apply.

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

הוספה או הסרה של צמתים באשכול

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

ב-Google Distributed Cloud יש שלושה סוגים של מאגרי צמתים: מישור הבקרה, מאזן העומסים ומאגרי צמתים של Worker. בקטעים הבאים מוסבר איך להוסיף או להסיר צמתים מכל סוג של מאגר צמתים.

`bmctl`

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

מאגר צומתי עובד: מוסיפים או מסירים את כתובת ה-IP של הצומת בקטע spec.nodes של המפרט NodePool.
מאגר צומתי מישור הבקרה: מוסיפים או מסירים את כתובת ה-IP של הצומת בקטע spec.controlPlane.nodePoolSpec.nodes במפרט של Cluster.
מאגר צמתים של מאזן עומסים: מוסיפים או מסירים את כתובת ה-IP של הצומת בקטע spec.loadBalancer.nodePoolSpec.nodes במפרט של Cluster.

דוגמה: הסרת צומת עובד

הנה דוגמה לקובץ תצורה של אשכול, שמציג את המפרטים של שני צומתי עובד:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: nodepool1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address: 192.0.2.1
  - address: 192.0.2.2

כדי להסיר צומת:

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

כדי לעקוב אחרי תהליך פינוי הצמתים של צומתי העובדים, אפשר להציג את השדות status.nodesDrained ו-status.nodesDraining במשאב NodePool.
עורכים את קובץ התצורה של האשכול כדי למחוק את רשומת כתובת ה-IP של הצומת.

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

bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

‫CLI של gcloud

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

מאגר צומתי עובד: מריצים את הפקודה gcloud container bare-metal node-pools update ומציינים את כתובת ה-IP בדגל --node-configs 'node-ip=IP_ADDRESS'.
מאגר צמתים של מישור הבקרה באשכול אדמין: מריצים את הפקודה gcloud container bare-metal admin-clusters update ומציינים את כתובת ה-IP בדגל --control-plane-node-configs 'node-ip=IP_ADDRESS'.
מאגר צמתים של מישור הבקרה באשכול משתמש: מריצים את הפקודה gcloud container bare-metal clusters update ומציינים את כתובת ה-IP בדגל --control-plane-node-configs 'node-ip=IP_ADDRESS'.
מאגר צמתים של מאזן עומסים: מריצים את הפקודה gcloud container bare-metal clusters update ומציינים את כתובת ה-IP בדגל --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' או
--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'

הדגל שבו מציינים את כתובת ה-IP מקבל רק node-ip אחד. צריך לכלול את הדגל לכל כתובת IP במאגר הצמתים.

הפקודות update מחליפות את כל כתובות ה-IP בכתובות ה-IP שציינתם. כדי להוסיף צומת, צריך לכלול את כתובות ה-IP של הצמתים הקיימים ואת כתובת ה-IP של הצומת החדש בפקודה update. באופן דומה, כדי להסיר צמתים, צריך לכלול רק את כתובות ה-IP של הצמתים שרוצים לשמור.

דוגמה: הסרת צומת עובד

בקטע הזה מוסבר איך להסיר צומת עובד ממאגר צמתים באמצעות נתונים לדוגמה. בשלבים הבאים מפורטות גם פקודות נוספות של ה-CLI של gcloud שיכולות להיות שימושיות.

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

כדי לעקוב אחרי תהליך פינוי הצמתים של צומתי העובדים, אפשר להציג את השדות status.nodesDrained ו-status.nodesDraining במשאב NodePool.

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

gcloud container bare-metal node-pools list \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1

הפלט אמור להיראות כך:

NAME         LOCATION     STATE
node-pool-1  us-central1  RUNNING
node-pool-2  asia-east1   RUNNING

מריצים את הפקודה describe כדי להציג את כל כתובות ה-IP במאגר הצמתים:
```
gcloud container bare-metal node-pools describe node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1
```
הפלט לדוגמה הבא קוצר כדי שיהיה קל יותר לקרוא אותו:
```
annotations:
  ...
  baremetal.cluster.gke.io/version: 1.36
...
name: projects/example-project-12345/locations/us-central1/bareMetalClusters/abm-user-cluster1/bareMetalNodePools/node-pool-1
nodePoolConfig:
  nodeConfigs:
  - nodeIp: 192.0.2.1
  - nodeIp: 192.0.2.2
  operatingSystem: LINUX
state: RUNNING
...
```
שימו לב לפרטים הבאים בפלט לדוגמה:
- השדה name מכיל את השם המלא של מאגר הצמתים. כשמציינים את שם מאגר הצמתים בפקודה, אפשר לציין את השם המלא או את שם מאגר הצמתים, לדוגמה node-pool-1, יחד עם הדגלים --cluster,‏ --project ו---location.
- הקטע nodeConfigs מכיל שני שדות nodeIp עם כתובות ה-IP של הצמתים.
מריצים את הפקודה הבאה כדי להסיר את הצומת עם כתובת ה-IP‏ 192.0.2.1:
```
gcloud container bare-metal node-pools update node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1 \
    --node-configs='node-ip=192.0.2.2'
```
הפקודה update מחליפה את כל כתובות ה-IP בכתובות ה-IP שציינתם. מכיוון ש-192.0.2.1 לא כלולה, הצומת מוסר.

הפלט של הפקודה אמור להיראות כך:
```
Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9] to complete
```
בפלט לדוגמה, המחרוזת operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 היא ה-OPERATION_ID של הפעולה שרצה לאורך זמן. כדי לבדוק את סטטוס הפעולה, אפשר להריץ את הפקודה הבאה בחלון טרמינל אחר:
```
gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \
    --project= example-project-12345 \
    --location=us-central1
```
אפשר להריץ את הפקודה מדי פעם כדי לבדוק את הסטטוס.

אם הסרת הצומת נכשלת, אפשר לאלץ את ההסרה שלו מהאשכול. לפרטים נוספים, קראו את המאמר איפוס צומת שנכשל ב-Google Distributed Cloud.

החלפת צומתי מישור בקרה של HA

`bmctl`

אפשר להשתמש ב-bmctl כדי להחליף צמתים של מישור הבקרה בזמינות גבוהה (HA) בכל סוגי האשכולות.

כדי להחליף צומת באשכול, מבצעים את הפעולות הבאות:

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

דוגמה: החלפת צומת של מישור בקרה בזמינות גבוהה (HA)

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

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.13

כדי להחליף את הצומת האחרון שמופיע בקטע spec.controlPlane.nodePoolSpec.nodes:

מסירים את הצומת על ידי מחיקת הרשומה של כתובת ה-IP שלו בקובץ התצורה של האשכול. אחרי השינוי, קובץ התצורה של האשכול אמור להיראות כך:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12

מעדכנים את האשכול באמצעות הפקודה הבאה:
```
bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG
```
מבצעים את השינויים הבאים:
- מחליפים את CLUSTER_NAME בשם האשכול שרוצים לעדכן.
- אם האשכול הוא אשכול בניהול עצמי (כמו אשכול אדמין או אשכול עצמאי), מחליפים את KUBECONFIG בנתיב לקובץ kubeconfig של האשכול. אם האשכול הוא אשכול משתמש, כמו בדוגמה הזו, מחליפים את KUBECONFIG בנתיב לקובץ kubeconfig של אשכול האדמין.
אחרי שהפקודה bmctl update בוצעה בהצלחה, לוקח קצת זמן להשלים את המשימות machine-preflight ו-machine-init. כדי לראות את הסטטוס של הצמתים ומאגרי הצמתים שלהם, מריצים את הפקודות שמתוארות בקטע אימות העדכונים במסמך הזה. אחרי שמאגר הצמתים והצמתים מוכנים, אפשר להמשיך לשלב הבא.
מוסיפים צומת חדש של מישור הבקרה למאגר הצמתים, על ידי הוספת כתובת ה-IP של הצומת החדש של מישור הבקרה לקטע spec.controlPlane.nodePoolSpec.nodes בקובץ התצורה של האשכול. אחרי השינוי, קובץ התצורה של האשכול אמור להיראות בערך כך:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.14
```
מעדכנים את האשכול באמצעות הפקודה הבאה:
```
bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG
```

‫CLI של gcloud

אתם יכולים להשתמש ב-CLI של gcloud כדי להחליף צומתי מישור בקרה בזמינות גבוהה (HA) באשכולות אדמין ובאשכולות משתמשים.

כדי להחליף צומת באשכול, מבצעים את הפעולות הבאות:

מסירים את כתובת ה-IP של הצומת באמצעות הפקודה הרלוונטית של update:
- אשכול משתמשים: gcloud container bare-metal clusters update
- אשכול אדמין: gcloud container bare-metal admin-clusters update
כדי לבדוק את סטטוס הסרת הצומת באשכול, מריצים את הפקודה gcloud container bare-metal operations describe OPERATION_ID.
מוסיפים את כתובת ה-IP של הצומת החדש על ידי הפעלת הפקודה הרלוונטית של update.

דוגמה: החלפת צומת של מישור בקרה בזמינות גבוהה (HA)

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

מריצים את הפקודה list כדי להציג את כל אשכולות המשתמשים בפרויקטGoogle Cloud :
```
gcloud container bare-metal clusters list \
    --project=example-project-12345 \
    --location=-
```
כשמגדירים את --location=-, המשמעות היא שכל האשכולות בכל האזורים יופיעו ברשימה. אם אתם צריכים לצמצם את הרשימה, הגדירו את --location לאזור ספציפי.

הפלט אמור להיראות כך:
```
NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
abm-user-cluster1a   us-central1   1.36      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.36      abm-admin-cluster1   RUNNING
```
מריצים את הפקודה describe באשכול:
```
gcloud container bare-metal clusters describe abm-user-cluster1  \
    --project=example-project-12345 \
    --location=us-central1
```
הפלט לדוגמה מקוצר כדי שיהיה קל יותר לקרוא אותו:
```
...
controlPlane:
  controlPlaneNodePoolConfig:
    nodePoolConfig:
      nodeConfigs:
      - nodeIp: 192.0.2.11
      - nodeIp: 192.0.2.12
      - nodeIp: 192.0.2.13
      operatingSystem: LINUX
...
name: projects/example-project-1234567/locations/us-central1/bareMetalClusters/abm-user-cluster1a
...
```
שימו לב לפרטים הבאים בפלט לדוגמה:
- השדה name מכיל את השם המלא של האשכול. כשמציינים את שם האשכול בפקודה, אפשר לציין את השם המלא או את שם האשכול, למשל abm-user-cluster1a, יחד עם --project ו---location flags.
- הקטע nodeConfigs מכיל שלושה שדות nodeIp עם כתובות ה-IP של הצמתים במישור הבקרה.

מסירים את הצומת עם כתובת ה-IP‏ 192.0.2.13:

gcloud container bare-metal cluster update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --control-plane-node-configs 'node-ip=192.0.2.11'
    --control-plane-node-configs 'node-ip=192.0.2.12'

הפלט של הפקודה אמור להיראות כך:

Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1956154681749-6078d9def4030-76686d6e-9fcb1d7] to complete

בפלט לדוגמה, המחרוזת operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 היא ה-OPERATION_ID של הפעולה שרצה לאורך זמן. כדי לבדוק את סטטוס הפעולה, אפשר להריץ את הפקודה הבאה בחלון טרמינל אחר:

gcloud container bare-metal operations describe operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 \
    --project= example-project-12345 \
    --location=us-central1

אפשר להריץ את הפקודה מדי פעם כדי לבדוק את הסטטוס.

מוסיפים את הצומת החדש עם כתובת ה-IP‏ 192.0.2.14:

gcloud container bare-metal cluster update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --control-plane-node-configs 'node-ip=192.0.2.11'
    --control-plane-node-configs 'node-ip=192.0.2.12'
    --control-plane-node-configs 'node-ip=192.0.2.14'

אימות העדכונים

`kubectl`

אפשר לראות את הסטטוס של הצמתים ומאגרי הצמתים שלהם באמצעות הפקודה kubectl get.

לדוגמה, הפקודה הבאה מציגה את הסטטוס של מאגרי הצמתים במרחב השמות של האשכול cluster-my-cluster:

kubectl -n cluster-my-cluster get nodepools.baremetal.cluster.gke.io

המערכת מחזירה תוצאות שדומות לתוצאות הבאות:

NAME                    READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
cluster-my-cluster      3       0             0         0                  0
cluster-my-cluster-lb   2       0             0         0                  0
np1                     3       0             0         0                  0

Reconciling=1 פירושו ששלב ההתאמה עדיין בתהליך. צריך לחכות עד שהסטטוס ישתנה ל-Reconciling=0.

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

kubectl get nodes --kubeconfig=KUBECONFIG

‫CLI של gcloud

כמו שתיארנו קודם, אחרי שמריצים פקודת update, אפשר לבדוק את סטטוס הפעולה באמצעות gcloud container bare-metal operations describe OPERATIONS_ID. הפלט של הפקודה מציג את הסטטוס של הצמתים, לדוגמה:

  ...
  metrics:
  - intValue: '1'
    metric: NODES_RECONCILING
  - intValue: '2'
    metric: NODES_HEALTHY
  - intValue: '0'
    metric: NODES_FAILED
  - intValue: '0'
    metric: NODES_IN_MAINTENANCE
  - intValue: '3'
    metric: NODES_TOTAL
  stage: HEALTH_CHECK
...

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

למידע נוסף על אבחון אשכולות, ראו יצירת קובצי snapshot לאבחון אשכולות.

מאגרי כתובות של מאזני עומסים

bmctl

הקטע addressPools מכיל שדות להגדרת מאגרי איזון עומסים למאזני העומסים בחבילה של MetalLB ו-Border Gateway Protocol ‏ (BGP). אתם יכולים להוסיף עוד מאגרי כתובות לאיזון עומסים בכל שלב, אבל אתם לא יכולים להסיר מאגרי כתובות קיימים. החל מגרסה 1.16.0 של Google Distributed Cloud, אפשר לשנות את הערכים של addressPools.avoidBuggyIPs ו-addressPools.manualAssign בכל שלב.

addressPools:
- name: pool1
  addresses:
  - 198.51.100.0-198.51.100.4
  - 198.51.100.240/28
- name: pool2
  addresses:
  - 198.51.100.224/28

‫CLI של gcloud

אתם יכולים להוסיף עוד מאגרי כתובות לאיזון עומסים בכל שלב למאזני העומסים הכלולים, אבל אתם לא יכולים להסיר מאגרי כתובות קיימים. הדגל שמציינים ב-gcloud container bare-metal clusters update כדי להוסיף מאגר כתובות תלוי בסוג של מאזן העומסים המצורף:

‫MetalLB (שכבה 2): משתמשים בדגל --metal-lb-address-pools.
‫Border Gateway Protocol ‏ (BGP): משתמשים בדגל --bgp-address-pools.

הערך של הדגלים הוא בפורמט הבא:

'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

הערך מכיל פלחים שמתחילים במילות המפתח pool,‏ avoid-buggy-ip,‏ manual-assign ו-addresses. מפרידים בין הפלחים באמצעות פסיק.

‫pool: שם המאגר שבחרתם.
‫avoid-buggy-ips: אם מגדירים את הערך True, בקר ניהול כתובות ה-IP‏ (IPAM) לא יקצה לשירותים כתובות IP שמסתיימות ב-.0 או ב-.255. כך נמנעת הבעיה של מכשירים צרכניים עם באגים, שעלולים להפיל בטעות תנועה שנשלחת לכתובות ה-IP המיוחדות האלה. אם לא מציינים ערך, ברירת המחדל היא False. החל מגרסה 1.16.0 של Google Distributed Cloud, אפשר לשנות את הערך הזה במאגר כתובות קיים.
‫manual-assign: אם אתם לא רוצים שבקר ה-IPAM יקצה באופן אוטומטי כתובות IP מהמאגר הזה לשירותים, הגדירו את הערך True. לאחר מכן, מפתח יכול ליצור שירות מסוג LoadBalancer ולציין באופן ידני את אחת מהכתובות במאגר. אם לא מציינים ערך, manual-assign מוגדר כ-False. החל מגרסה 1.16.0 של Google Distributed Cloud, אפשר לשנות את הערך הזה במאגר כתובות קיים.
ברשימה של addresses: כל כתובת צריכה להיות טווח בפורמט CIDR או בפורמט של טווח עם מקפים. כדי לציין כתובת IP אחת במאגר (למשל, ל-VIP של הכניסה), משתמשים ב-/32 בסימון CIDR (לדוגמה, 192.0.2.1/32).

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

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

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

--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=False,manual-assign=True,addresses=198.51.100.0/30;198.51.100.64-198.51.100.72'
--metal-lb-address-pools='pool=pool3,avoid-buggy-ips=True,manual-assign=True,addresses=203.0.113.0/28'

מידע נוסף על מאגרי כתובות של מאזני עומסים זמין בקטע loadBalancer.addressPools במאמר "הגדרת איזון עומסים בחבילה".

מניעת מחיקה לא מכוונת של אשכולות

`bmctl`

אם מוסיפים את ההערה baremetal.cluster.gke.io/prevent-deletion: "true" לקובץ התצורה של האשכול, אי אפשר למחוק את האשכול. לדוגמה, הפעלת kubectl delete cluster או bmctl reset cluster גורמת לשגיאה.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ci-10c3c6f4d9c698e
  namespace: cluster-ci-10c3c6f4d9c698e
  annotations:
    baremetal.cluster.gke.io/prevent-deletion: "true"
spec:
  clusterNetwork:

‫CLI של gcloud

אם מציינים את הדגל --add-annotations עם הערך baremetal.cluster.gke.io/prevent-deletion="true", אי אפשר למחוק את האשכול. לדוגמה:

מוסיפים את ההערה כדי למנוע מחיקה מקרית של האשכול:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --add-annotations=baremetal.cluster.gke.io/prevent-deletion="true"

מנסים למחוק את אשכול המשתמש:

gcloud container bare-metal clusters delete abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --force \
    --allow-missing

התגובה מהפקודה אמורה להיראות כך:

ERROR: (gcloud.container.bare-metal.clusters.delete) INVALID_ARGUMENT:
invalid request: admission webhook "vcluster.kb.io" denied the request:
annotations[baremetal.cluster.gke.io/prevent-deletion]: Invalid value:
"true": Annotation "baremetal.cluster.gke.io/prevent-deletion" should be
removed in order to delete this cluster

כדי להסיר את ההערה, מציינים את הערך --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" בפקודה update.

עקיפת בדיקות קדם הפעלה

התכונה הזו זמינה רק עם bmctl update.

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

  apiVersion: baremetal.cluster.gke.io/v1
  kind: Cluster
  metadata:
    name: cluster1
    namespace: cluster-cluster1
    annotations:
      baremetal.cluster.gke.io/private-mode: "true"
  spec:
    bypassPreflightCheck: true

הוספה או הסרה של מנהלי אשכולות

`bmctl`

כדי להוסיף או להסיר משתמש או חשבון שירות כמנהל אשכול של אשכול משתמש, צריך לציין כתובות אימייל בקטע clusterSecurity.authorization.clusterAdmin.gcpAccounts של קובץ התצורה של האשכול. לחשבונות מוקצה התפקיד cluster-admin באשכול, שנותן גישה מלאה לאשכול.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterSecurity:
    authorization:
      clusterAdmin:
        gcpAccounts:
        - alex@example.com
        - hao@example.com
        - my-sa@example-project-12345.

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

‫CLI של gcloud

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

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --admin-users=alex@example.com \
    --admin-users=hao@example.com
    --admin-users=my-sa@example-project-12345.

הפקודה update מחליפה את כל רשימת ההרשאות. ציינו את כל המשתמשים הקיימים והחדשים שאתם רוצים שיהיו מנהלי אשכולות.

הגדרת משתמש להתחברות

אתם יכולים לציין שם משתמש שאינו ברמת הבסיס (root) שבו אתם רוצים להשתמש כדי לקבל גישה ללא סיסמה ליכולת sudo במכונות הצומת באשכול. מפתח ה-SSH,‏ sshPrivateKeyPath, צריך לפעול בשביל המשתמש שצוין. פעולות היצירה והעדכון של האשכול בודקות אם אפשר לגשת למכונות הצומת באמצעות המשתמש ומפתח ה-SSH שצוינו.

`bmctl`

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  nodeAccess:
    loginUser: abm

‫CLI של gcloud

בדגל --login-user מציינים את המשתמש שרוצים להשתמש בו כדי לגשת למכונות הצומת, לדוגמה:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --login-user=abm

כדי לאפשר למשתמש גישה ל-sudo ללא סיסמה, פועלים לפי השלבים הבאים בכל מכונה של צומת באשכול:

משתמשים ב-sudo visudo כדי לפתוח את הקובץ sudoers לעריכה:
```
sudo visudo -f /etc/sudoers
```
הפקודה visudo נועלת את הקובץ sudoers כדי למנוע עריכות בו-זמניות, ומאמתת את התחביר של הקובץ בזמן השמירה.
למשתמש שמחובר, מוסיפים רשומה לקובץ sudoers, כמו בדוגמה הבאה:
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
סוגרים ושומרים את הקובץ.
כדי להריץ פקודות עם הרשאות של המשתמש שהתחבר, מריצים את הפקודה הבאה:
```
su - USERNAME
```
כדי לוודא שלא נדרשת סיסמה למשתמש המחובר כדי להריץ פקודות sudo, מריצים את פקודת ה-sudo הבאה:
```
sudo ip a
```

הגדרות רשת מתקדמות

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

`bmctl`

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

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

‫CLI של gcloud

כשיוצרים את האשכול, צריך לכלול את הדגל --enable-advanced-networking בפקודה gcloud container bare-metal clusters create.

אחרי שיוצרים את האשכול עם רישות מתקדם, אפשר להגדיר את המשאבים בהתאמה אישית שמתוארים בקטע הזה באמצעות kubectl apply.

`NetworkGatewayGroup`

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

apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

איזון עומסים של BGP

אתם מגדירים איזון עומסים של Border Gateway Protocol ‏ (BGP) במשאב האשכול ובמשאבים מותאמים אישית אחרים. הפקודות gcloud container bare-metal clusters create ו-update תומכות בהגדרת BGP במשאב האשכול, אבל לא במשאבים בהתאמה אישית.

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

`BGPLoadBalancer`

apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"

`BGPPeer`

apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

הגדלת טווח הרשת של השירות

כדי ליצור יותר שירותים מהמגבלה הראשונית, אתם יכולים להקטין את מסכת ה-CIDR של שירות IPv4 כדי להגדיל את רשת השירות של האשכול. הקטנת המסכה (הערך שאחרי "/") תגדיל את טווח הרשת. אפשר רק להגדיל את הטווח של ה-CIDR של שירות IPv4. אי אפשר לצמצם את טווח הרשת, כלומר אי אפשר להגדיל את המסכה (הערך שאחרי "/").

`bmctl`

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  clusterNetwork:
    services:
      cidrBlocks:
        - 192.0.2.0/14
  ...

‫CLI של gcloud

כדי להגדיל את טווח ה-CIDR של שירות IPv4 באשכול משתמש, מציינים את הטווח החדש בדגל --island-mode-service-address-cidr-blocks.

gcloud container bare-metal clusters update cluster1 \
    --project=example-project-12345 \
    --location=us-central1 \
    --island-mode-service-address-cidr-blocks=192.0.2.0/14

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

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

The servicecidrs "my-cidr" is invalid: : This resource is managed by cluster
operator and cannot be modified directly by users.

קביעת הגדרות שליפת התמונות של kubelet

ה-kubelet פועל בכל צומת באשכול. ה-kubelet אחראי למעקב אחרי קונטיינרים בצומת ולוודא שהם תקינים. במקרה הצורך, ה-kubelet שולח שאילתות ומושך קובצי אימג' מ-Artifact Registry.

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

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

`bmctl`

השדות הנתמכים הבאים שולטים בפעולות המשיכה של Artifact Registry עבור kubelet:

‫registryBurst (ברירת מחדל: 10)
‫registryPullQPS (ברירת מחדל: 5)
‫serializeImagePulls (ברירת מחדל: true)

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

אפשר לציין את השדות האלה בקטעים של kubeletConfig במפרט של האשכול ובמפרט של NodePool, למאגרים הבאים של צמתים:

מפרט האשכול:
צמתים של מישור הבקרה spec.controlPlane.nodePoolSpec.kubeletConfig
צמתים של מאזן עומסים spec.loadBalancer.nodePoolSpec.kubeletConfig
מפרט של NodePool:
צומתי עובדים spec.kubeletConfig

בדוגמה הבאה מוצגים השדות שנוספו עם ערכי ברירת המחדל שלהם בקובץ התצורה של האשכול. שימו לב שחובה להוסיף את ההערה preview.baremetal.cluster.gke.io/custom-kubelet: "enable".

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/custom-kubelet: "enable"
spec:
  ...
  controlPlane:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
  loadBalancer:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-new
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  ...
  kubeletConfig:
    registryBurst: 10
    registryPullQPS: 5
    serializeImagePulls: true

בכל מקרה, ההגדרה חלה על כל הצמתים במאגר.

‫CLI של gcloud

הדגלים הבאים שולטים בפעולות המשיכה של Artifact Registry עבור kubelet:

אופן השימוש

הנה כמה דברים שכדאי להביא בחשבון כשמגדירים את שליפת התמונות:

כברירת מחדל, שליפת התמונות מתבצעת בסדרות, ולכן שליפת תמונה שנמשכת זמן רב יכולה לעכב את כל שליפות התמונות האחרות שמתוזמנות בצומת. עיכובים בשליפת קובצי אימג' יכולים לחסום את תהליך השדרוג (במיוחד כשצריך לפרוס קובצי אימג' חדשים של Google Distributed Cloud בצומת). אם אתם מושפעים מעיכובים בשליפת תמונות, אתם יכולים להשבית את השליפה הסדרתית של תמונות כדי לאפשר שליפה מקבילה של תמונות.
אם אתם נתקלים בשגיאות של ויסות קצב שליפת התמונות, כמו pull QPS exceeded, יכול להיות שכדאי להגדיל את *-registry-pull-qps ואת *-registry-burst כדי להגדיל את קצב העברת הנתונים של שליפת התמונות. שני השדות האלה משנים את קצב המשיכה ואת גודל התור, ויכולים לעזור לפתור בעיות אחרות שקשורות לוויסות נתונים. אי אפשר להזין ערכים שליליים.

התאמה אישית של Keepalived

החל מגרסה 1.32, ב-Google Distributed Cloud אפשר להתאים אישית את ההגדרות של Keepalived. באיזון עומסים מקובץ, מאזן העומסים של מישור הבקרה משרת את כתובת ה-IP הווירטואלית (VIP) של מישור הבקרה. ב-Google Distributed Cloud,‏ Keepalived ו-HAProxy פועלים כ-Pods סטטיים של Kubernetes בצומתי מאזן העומסים כדי להכריז על ה-VIP של מישור הבקרה. ‫Keepalived משתמש בפרוטוקול Virtual Router Redundancy Protocol‏ (VRRP) בצומתי מאזן העומסים כדי להבטיח זמינות גבוהה.

לאשכולות בגרסה 1.32 ואילך יש את ההתאמות האישיות הבאות של Keepalived:

במישורי בקרה עם זמינות גבוהה, Google Distributed Cloud מגדיר באופן אוטומטי את הגדרת ה-VRRP של Keepalived כדי להפוך את התנהגות יתירות הכשל לדטרמיניסטית, ולמנוע שילוב של תשובות ARP עם כתובות MAC שונות. כדי לעשות את זה, מגדירים לכל מכונה של Keepalived ערך priority שונה.
ב-Google Distributed Cloud אפשר לציין את מספר ההודעות של פרוטוקול ARP ללא בקשה (GARP) שיישלחו בכל פעם אחרי שצומת במישור הבקרה יעבור לתפקיד של השרת הראשי. כדי לשנות את מספר הודעות ה-GARP שיישלחו, מוסיפים את השדה controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat לקובץ התצורה של האשכול, מגדירים אותו לערך החדש ומעדכנים את האשכול. הערך הזה ממפה להגדרה vrrp_garp_master_repeat של Keepalived. ערך ברירת המחדל הוא 5.

בדוגמה הבאה אפשר לראות איך מציינים את keepalivedVRRPGARPMasterRepeat בקובץ התצורה של האשכול:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-ha-lb
  namespace: cluster-hybrid-ha-lb
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.36
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    loadBalancer:
      keepalivedVRRPGARPMasterRepeat: 1
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  ...
```

התקנה או הסרה של NVIDIA GPU Operator המצורף

NVIDIA GPU Operator מאפשר להריץ באשכולות עומסי עבודה שקשורים ל-GPU. החל מגרסה 1.33.0 של Google Distributed Cloud, האשכולות כוללים מחסנית מלאה של NVIDIA GPU Operator כדי לספק פתרון מנוהל לטיפול ברכיבי התוכנה של NVIDIA שנדרשים להקצאת מעבדי GPU בצומתי העובדים של האשכול.

דרישות מוקדמות

לפני שמתקינים את NVIDIA GPU Operator, צריך לוודא שהסביבה עומדת בדרישות הבאות:

אשכול תפעולי: יש לכם אשכול פונקציונלי של שרת פיזי שנוצר באמצעות Google Distributed Cloud.
‫NVIDIA GPUs: מעבדי ה-GPU של NVIDIA מותקנים בצומתי העובדים של האשכול. בקטע הבא, שעוסק בהתקנת NVIDIA GPU Operator, מוסבר איך לוודא שהמעבדים הגרפיים מותקנים כמו שצריך ומזוהים על ידי מערכת ההפעלה.
גרסה תואמת של מנהל ההתקן של NVIDIA: גרסת מנהל ההתקן של NVIDIA שבה אתם משתמשים צריכה להיות תואמת ל-GPU, למערכת ההפעלה ולגרסת ה-CUDA שבה האפליקציות שלכם משתמשות. מידע נוסף זמין במאמר פרטי גרסה.

אלה האפשרויות להתקנת מנהל ההתקן של NVIDIA:
- משתמשים במנהל ההתקן של NVIDIA שמותקן מראש בקובץ האימג' של מערכת ההפעלה.
- כדי להתקין ידנית את מנהל ההתקן של NVIDIA, צריך לפעול לפי ההוראות במדריך למתחילים להתקנת מנהל ההתקן של NVIDIA.
מנהל ההתקן של NVIDIA GPU חייב להיות מותקן ומוכן לפני שמפעילים את NVIDIA GPU Operator המצורף.

פרטי הגרסה

בקטע הזה מפורט מידע על גרסת התוכנה של NVIDIA GPU Operator שכלול בחבילה.

גרסאות של רכיבי תוכנה

גרסת הפצה 1.33 של Google Distributed Cloud כוללת את גרסה 25.3.1 של NVIDIA GPU Operator. ב-Google Distributed Cloud, החבילה מכילה את קובצי האימג' הבאים (עם CDI שמופעל כברירת מחדל):

‫NVIDIA Container Toolkit בגרסה v1.17.9
‫NVIDIA DCGM Exporter בגרסאות 3.3.9 עד 3.6.1
‫NVIDIA Kubernetes Device Plugin גרסה 0.17.1
‫Node Feature Discovery גרסה 0.17.2

יכול להיות שגרסאות התמונות שכלולות בגרסה 1.33 של Google Distributed Cloud לא תואמות בדיוק לגרסאות של רכיבי התוכנה שמפורטות בנתוני הגרסה של 25.3.1.

תאימות לנהגים

במאמר Platform Support for version 25.3.1 ב-NVIDIA Docs Hub מפורט מידע על תאימות מנהלי ההתקנים.

עדכון ה-NVIDIA GPU Operator המצורף

אם התקנתם את NVIDIA GPU Operator באשכול, כשמשדרגים לגרסה משנית חדשה, מותקנת הגרסה העדכנית ביותר של NVIDIA GPU Operator שכלולה בחבילה.

התקנת האופרטור המצורף

בזמן ש-NVIDIA GPU Operator המצורף נמצא בגרסת טרום-השקה (Preview), אתם מתקינים אותו באמצעות bmctl update כדי להוסיף את ההערה הבאה לאשכול שיש לו צומתי GPU:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/nvidia-gpu-operator: "enable"
spec:
  ...

מחסנית NVIDIA GPU Operator מותקנת באשכול כשההערה מוחלת.

הסרת האופרטור המצורף

בזמן ש-NVIDIA GPU Operator המצורף נמצא בגרסת טרום-השקה (Preview), אתם יכולים להסיר אותו באמצעות bmctl update כדי להסיר את ההערה הבאה מהאשכול שיש לו צומתי GPU:

preview.baremetal.cluster.gke.io/nvidia-gpu-operator: "enable"

כל הרכיבים של מחסנית NVIDIA GPU Operator יוסרו מהאשכול כשההערה תוסר.

הפעלת הקצאת משאבים דינמית

הקצאת משאבים דינמית היא API של Kubernetes שמאפשר לבקש ולשתף משאבים גנריים, כמו מעבדי GPU, בין Pods לקונטיינרים. מנהלי התקנים של צד שלישי מנהלים את המשאבים האלה. היכולת הזו עוזרת להריץ עומסי עבודה של AI על ידי הקצאה דינמית ומדויקת של משאבי ה-GPU באשכולות ה-Bare Metal, וכך לשפר את ניצול המשאבים והביצועים של עומסי עבודה תובעניים.

הקצאת משאבים דינמית זמינה בגרסת טרום-השקה (Preview) לאשכולות בגרסה 1.33 ואילך. בהוראות הבאות מוסבר איך להגדיר את האשכול לשימוש בהקצאת משאבים דינמית. אחרי שמפעילים את התכונה, אפשר להגדיר את עומסי העבודה של ה-GPU כך שישתמשו בהקצאת משאבים דינמית.

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

עורכים את קובץ התצורה של האשכול כדי לכלול את ההערה preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" של גרסת טרום-ההשקה (Preview), ומוסיפים את DynamicResourceAllocation: true בקטע featureGates בקטע kubeletConfig:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: dra
  namespace: cluster-dra
  annotations:
    preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable"
spec:
  controlPlane:
    nodePoolSpec:
      kubeletConfig:
        featureGates:
          DynamicResourceAllocation: true
# ... other cluster configuration

מעדכנים את האשכול באמצעות הפקודה bmctl update:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: שם אשכול המשתמש שמעדכנים.
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
אחרי שמחילים את ההגדרה הזו, יכול להיות שהשדה READY של המכונות ללא מערכת הפעלה יעבור בין True ל-False כמה פעמים. לפני שממשיכים, צריך לחכות שהשדה READY יתייצב על True.
כדי להפעיל את ה-Feature Gate‏ DynamicResourceAllocation במאגרי צמתים עם GPUs, מגדירים את DynamicResourceAllocation לערך true בקטע featureGates שבקטע kubeletConfig במפרט של NodePool:

הוראות להוספה ולעדכון של מאגר צמתים מפורטות במאמר ניהול מאגרי צמתים באשכול.
```
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np
  namespace: cluster-dra
spec:
  clusterName: dra
  kubeletConfig:
    featureGates:
      DynamicResourceAllocation: true
  nodes:
# ... other node pool configuration
```
אחרי שמוסיפים או מעדכנים את מאגר הצמתים, מחכים שכל מכונות ה-Bare Metal במאגר הצמתים יגיעו לסטטוס Ready.

כדי לבדוק את הסטטוס של מכונות ה-Bare Metal באשכול, משתמשים בפקודה הבאה:

kubectl get baremetalmachines --kubeconfig ADMIN_KUBECONFIG -A

כשהמכונות ללא מערכת הפעלה מוכנות, התגובה אמורה להיראות דומה לתגובה לדוגמה הבאה:

NAMESPACE          NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION        DESIRED ABM VERSION
cluster-admin      10.200.0.2   dra        true    baremetal://10.200.0.2   10.200.0.2    1.33.0-gke.793   1.33.0-gke.793
cluster-user-dra   10.200.0.6   user-dra   true    baremetal://10.200.0.6   10.200.0.6    1.33.0-gke.793   1.33.0-gke.793
cluster-user-dra   10.200.0.7   user-dra   true    baremetal://10.200.0.7   10.200.0.7    1.33.0-gke.793   1.33.0-gke.793
cluster-user-dra   10.200.0.8   user-dra   true    baremetal://10.200.0.8   10.200.0.8    1.33.0-gke.793   1.33.0-gke.793

מגבלות

ל-NVIDIA GPU Operator המצורף יש את המגבלות הבאות:

ה-NVIDIA GPU Operator שמצורף לחבילה תומך רק ברכיבי התוכנה הבאים של NVIDIA:
- NVIDIA Container Toolkit
- NVIDIA DCGM Exporter
- פלאגין המכשיר של NVIDIA Kubernetes
- NVIDIA MIG Manager for Kubernetes.
במהלך גרסת טרום-השקה (Preview), ההגדרה של NVIDIA GPU Operator קבועה. אם תנסו להתאים אישית הגדרות כלשהן, הן יוחזרו להגדרות ההתקנה המקוריות.
אי אפשר להשתמש ב-NVIDIA GPU Operator המצורף כדי להתקין מנהלי התקנים של NVIDIA GPU.
בגרסת טרום-ההשקה (Preview), התכונה הזו משתמשת בקבוצת ה-API‏ resource.k8s.io/v1beta1, ששונה מקבוצת ה-API של Kubernetes בקוד פתוח לתכונה הזו, resource.k8s.io/v1. קבוצת ה-API בקוד פתוח v1 מספקת יותר תכונות ויציבות טובה יותר מקבוצת ה-API‏ v1beta1.

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

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

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

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

bmctl

‫CLI של gcloud

Terraform

הוספה או הסרה של צמתים באשכול

bmctl

דוגמה: הסרת צומת עובד

‫CLI של gcloud

דוגמה: הסרת צומת עובד

החלפת צומתי מישור בקרה של HA

bmctl

דוגמה: החלפת צומת של מישור בקרה בזמינות גבוהה (HA)

‫CLI של gcloud

דוגמה: החלפת צומת של מישור בקרה בזמינות גבוהה (HA)

אימות העדכונים

kubectl

‫CLI של gcloud

מאגרי כתובות של מאזני עומסים

bmctl

‫CLI של gcloud

מניעת מחיקה לא מכוונת של אשכולות

bmctl

‫CLI של gcloud

עקיפת בדיקות קדם הפעלה

הוספה או הסרה של מנהלי אשכולות

bmctl

‫CLI של gcloud

הגדרת משתמש להתחברות

bmctl

‫CLI של gcloud

הגדרות רשת מתקדמות

bmctl

‫CLI של gcloud

NetworkGatewayGroup

איזון עומסים של BGP

BGPLoadBalancer

BGPPeer

הגדלת טווח הרשת של השירות

bmctl

‫CLI של gcloud

קביעת הגדרות שליפת התמונות של kubelet

bmctl

‫CLI של gcloud

אופן השימוש

התאמה אישית של Keepalived

התקנה או הסרה של NVIDIA GPU Operator המצורף

דרישות מוקדמות

פרטי הגרסה

גרסאות של רכיבי תוכנה

תאימות לנהגים

עדכון ה-NVIDIA GPU Operator המצורף

התקנת האופרטור המצורף

הסרת האופרטור המצורף

הפעלת הקצאת משאבים דינמית

מגבלות

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

מאמרי עזרה

bmctl

‫CLI של gcloud

Terraform

עדכון אשכולות

`bmctl`

`bmctl`

`bmctl`

`kubectl`

`bmctl`

`bmctl`

`bmctl`

`bmctl`

`NetworkGatewayGroup`

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

`bmctl`