Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

שינוי מרחב השמות של אשכול קיים בקובץ ההגדרות של האשכול not a supported operation ועלול לגרום לחוסר יציבות באשכול ולכשלים פוטנציאליים. כדי להימנע מהבעיות האלה, אל תנסו לשנות את מרחב השמות של האשכול אחרי שהוא נוצר.

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

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

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

`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 שאוכלס על ידי תהליך הגישור באשכול. ההתנהגות הזו מתרחשת כי ההגדרה לא קיימת במפרט של הגדרת האשכול, אבל היא קיימת באשכול.

‫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: מאגרי צמתים של מישור הבקרה, של איזון העומסים ושל צמתים לעיבוד נתונים. בקטעים הבאים מוסבר איך להוסיף או להסיר צמתים מכל סוג של מאגר צמתים.

`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

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

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

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

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

כדי לעקוב אחרי תהליך ניקוי הצמתים של צמתים מסוג worker, אפשר להציג את השדות 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.34
...
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 של הצומת החדש לאותו קובץ תצורה של האשכול.
מעדכנים את האשכול.

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

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

---
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) באשכולות אדמין ובאשכולות משתמשים.

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

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

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

בקטע הזה נסביר איך להחליף מישור בקרה מאשכול באמצעות נתונים לדוגמה. בשלבים הבאים מפורטות גם פקודות נוספות של ה-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.34      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.34      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 כמו שמוצג למעלה כדי לקבל את הסטטוס הנוכחי של מאגר הצמתים.

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

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

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.iam.gserviceaccount.com

כשמעדכנים אשכול משתמשים כדי להוסיף חשבון, חשוב לכלול ברשימה את כל החשבונות (הקיימים והחדשים), כי הפקודה 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.iam.gserviceaccount.com

הפקודה 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 עבור משתמש, פועלים לפי השלבים הבאים בכל מכונת צומת באשכול:

כדי לפתוח את קובץ sudoers לעריכה, משתמשים ב-sudo visudo:
```
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, איזון העומסים במישור הנתונים משתמש כברירת מחדל באותם עמיתים חיצוניים שצוינו עבור שיוך מישור הבקרה. לחלופין, אפשר להגדיר את איזון העומסים של מישור הנתונים בנפרד, באמצעות המשאב המותאם אישית 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 של מפרט האשכול ומפרט מאגר הצמתים עבור מאגרי הצמתים הבאים:

מפרט האשכול:
צמתים של מישור הבקרה 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 משתמש בפרוטוקול היתירות של נתב וירטואלי (VRRP) בצמתי מאזן העומסים כדי להשיג זמינות גבוהה.

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

במישורי בקרה עם זמינות גבוהה, Google Distributed Cloud מגדיר אוטומטית את התצורה של Keepalived VRRP כדי להפוך את התנהגות המעבר לגיבוי (failover) לדטרמיניסטית ולמנוע שילוב של תשובות ARP עם כתובות MAC שונות:
- כל מופע של Keepalived מוגדר אוטומטית עם ערך priority שונה בנתב VRRP.
- כל מופע של Keepalived מוגדר אוטומטית עם nopreempt כדי למנוע בחירות כשמופעל מחדש מופע שאינו ראשי.
ב-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.34
  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.
יחידות GPU של NVIDIA: יחידות ה-GPU של NVIDIA מותקנות בצמתי העובדים של האשכול. בקטע הבא בנושא התקנת NVIDIA GPU Operator מפורטים שלבים לאימות ההתקנה של המעבדים הגרפיים (GPU) ולווידוא שמערכת ההפעלה מזהה אותם.
גרסת דרייבר NVIDIA תואמת: גרסת הדרייבר של NVIDIA שבה אתם משתמשים צריכה להיות תואמת ל-GPU, למערכת ההפעלה ולגרסת CUDA שבה האפליקציות שלכם משתמשות. מידע נוסף זמין במאמר בנושא פרטי גרסה.

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

פרטי הגרסה

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

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

גרסת הפצה 1.33 של Google Distributed Cloud כוללת את גרסה 25.3.1 של NVIDIA GPU Operator. ב-Google Distributed Cloud, החבילה מכילה את התמונות הבאות:

NVIDIA Container Toolkit גרסה v1.17.8
NVIDIA DCGM Exporter v3.3.9-3.6.1
NVIDIA Kubernetes Device Plugin v0.17.1
Node Feature Discovery v0.17.2

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

תאימות לנהג

מידע על תאימות מנהלי התקנים זמין במאמר Platform Support for version 25.3.1 במרכז המסמכים של NVIDIA.

עדכון של 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 stack מוסרים מהאשכול כשמסירים את ההערה.

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

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

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

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

עורכים את קובץ התצורה של האשכול כדי לכלול את הערת התצוגה המקדימה preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" ומוסיפים את 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 במכונות ה-Bare Metal יעבור בין True לבין False כמה פעמים. צריך להמתין עד שהערך בשדה READY יתייצב על True לפני שממשיכים.
כדי להפעיל את Feature Gate DynamicResourceAllocation במאגרי צמתים שיש בהם צמתים עם GPU, צריך להגדיר את 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

כשהמכונות מסוג Bare Metal יהיו מוכנות, התגובה תיראה דומה לתגובה לדוגמה הבאה:

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 Device Plugin
- ‫NVIDIA MIG Manager for Kubernetes.
במהלך התצוגה המקדימה, ההגדרה של NVIDIA GPU Operator קבועה. אם תנסו להתאים אישית הגדרות כלשהן, הן יוחזרו להגדרות המקוריות של ההתקנה.
אי אפשר להשתמש באופרטור NVIDIA GPU שכלול בחבילה כדי להתקין דרייברים של NVIDIA GPU.
במהלך תקופת הטרום-השקה, התכונה הזו משתמשת ב-resource.k8s.io/v1beta1 API group, ששונה מ-API group של Kubernetes בקוד פתוח עבור התכונה הזו, resource.k8s.io/v1. קבוצת ה-API של v1 קוד פתוח מספקת יותר תכונות ורמת יציבות טובה יותר מקבוצת ה-API של v1beta1.

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

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

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

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

bmctl

‫CLI של gcloud

Terraform

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

bmctl

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

‫CLI של gcloud

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

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

bmctl

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

‫CLI של gcloud

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

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

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`