Diese Seite wurde von der Cloud Translation API übersetzt.

Cluster aktualisieren

Nachdem Sie einen Cluster erstellt haben, können Sie einige Aspekte der Clusterkonfiguration ändern. Sie haben beispielsweise folgende Möglichkeiten:

Knoten hinzufügen, entfernen oder ersetzen
Fügen Sie dem Cluster Anmerkungen hinzu oder entfernen Sie sie.
Ändern Sie die Werte der änderbaren Felder in den Cluster- und Knotenpoolressourcen.
Andere benutzerdefinierte Ressourcen ändern

Sie können bmctl oder die Google Cloud CLI verwenden, um Änderungen an einem Cluster vorzunehmen. Wenn Sie einen Administrator- oder Nutzercluster mit Terraform erstellt haben, können Sie den Cluster mit Terraform aktualisieren. Wichtige Hinweise:

Viele Aspekte der Clusterkonfiguration sind unveränderlich und können nach dem Erstellen des Clusters nicht aktualisiert werden. Eine umfassende Liste der änderbaren und unveränderlichen Felder finden Sie in der Referenz zum Cluster-Konfigurationsfeld. Der Feldverweis ist eine sortierbare Tabelle. Klicken Sie auf die Spaltenüberschriften, um die Sortierreihenfolge zu ändern. Klicken Sie auf einen Feldnamen, um die Beschreibung aufzurufen.
Mit der gcloud CLI und Terraform können nur Administrator- und Nutzercluster aktualisiert werden. Für andere Clustertypen müssen Sie bmctl verwenden.
Die gcloud CLI und Terraform unterstützen nur Änderungen an den Cluster- und Knotenpoolressourcen. Sie müssen kubectl oder bmctl verwenden, um andere benutzerdefinierte Ressourcen zu aktualisieren, die sich auf den Cluster auswirken.

Das Ändern des Namespace eines vorhandenen Clusters in der Clusterkonfigurationsdatei ist not a supported operation und kann zu Clusterinstabilität und potenziellen Fehlern führen. Um diese Probleme zu vermeiden, sollten Sie den Clusternamespace nach der Erstellung nicht ändern.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Cluster aktualisieren

Im Allgemeinen führen Sie die folgenden Aktionen aus, um einen Cluster zu aktualisieren:

`bmctl`

Ändern Sie die Werte der entsprechenden Felder in der Konfigurationsdatei des Clusters, die sich standardmäßig hier befindet:
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
Aktualisieren Sie den Cluster mit dem Befehl bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren möchten.
- KUBECONFIG: Geben Sie für Administrator-, Hybrid- oder eigenständige Cluster den Pfad zur kubeconfig-Datei des Clusters ein. Geben Sie für einen Nutzercluster den Pfad zur kubeconfig-Datei des Administratorclusters ein.

Verwenden Sie bmctl update und kubectl apply -f nicht austauschbar, wenn Sie die Clusterkonfigurationsdatei bearbeiten. Wenn diese Befehle austauschbar verwendet werden, werden möglicherweise Inhalte entfernt, die durch den Header der Clusterspezifikation eingefügt wurden. Sie können beispielsweise bmctl update verwenden, um die Clusterkonfigurationsdatei zu aktualisieren und eine Registry-Spiegelung zu konfigurieren. Nach dem Abgleich hat der Cluster dann spec.nodeConfig.registryMirrors.

Wenn Sie dann versuchen, mit der Clusterkonfiguration und dem Befehl kubectl apply -f Änderungen am Cluster vorzunehmen, wird die vom Abgleich im Cluster befüllte spec.nodeConfig.registryMirrors entfernt. Dieses Verhalten tritt auf, weil die Konfiguration nicht in der Clusterspezifikation, aber im Cluster vorhanden ist.

gcloud-CLI

Geben Sie nur die Flags für die Konfiguration an, die Sie ändern möchten.
Führen Sie den entsprechenden Aktualisierungsbefehl aus:
- Administratorcluster: gcloud container bare-metal admin-clusters update
- Nutzercluster: gcloud container bare-metal clusters update.
- Knotenpools in einem Nutzercluster: gcloud container bare-metal node-pools update

Terraform

Ändern Sie die Werte der entsprechenden Felder in der Terraform-Konfigurationsdatei, die Sie zum Erstellen des Clusters oder Knotenpools verwendet haben. Detaillierte Feldbeschreibungen finden Sie in der Terraform-Referenzdokumentation:
Aktualisieren Sie die Konfiguration mit dem Befehl terraform apply.

In den folgenden Abschnitten werden einige gängige Beispiele zum Aktualisieren eines vorhandenen Clusters beschrieben.

Knoten in einem Cluster hinzufügen oder entfernen

Ein Knotenpool besteht aus einer Gruppe von Knoten in einem Cluster, die dieselbe Konfiguration haben. Ein Knoten gehört immer zu einem Knotenpool. Wenn Sie einem Cluster einen neuen Knoten hinzufügen möchten, müssen Sie ihn einem bestimmten Knotenpool hinzufügen. Wenn Sie einen Knoten aus einem Knotenpool entfernen, wird er vollständig aus dem Cluster entfernt.

Es gibt drei Arten von Knotenpools in Google Distributed Cloud: Steuerungsebene, Load Balancer und Worker-Knotenpools. In den folgenden Abschnitten wird beschrieben, wie Sie Knoten in den einzelnen Arten von Knotenpools hinzufügen oder daraus entfernen.

`bmctl`

Sie fügen einem Knotenpool einen Knoten hinzu oder entfernen ihn, indem Sie die IP-Adresse des Knotens in einem bestimmten Abschnitt der Clusterkonfigurationsdatei hinzufügen oder entfernen. In der folgenden Liste sehen Sie, welcher Abschnitt für einen bestimmten Knotenpool bearbeitet werden muss:

Worker-Knotenpool: Fügen Sie die IP-Adresse des Knotens im Abschnitt spec.nodes der NodePool-Spezifikation hinzu oder entfernen Sie sie.
Knotenpool der Steuerungsebene: Fügen Sie die IP-Adresse des Knotens im Abschnitt spec.controlPlane.nodePoolSpec.nodes der Cluster-Spezifikation hinzu oder entfernen Sie sie.
Load-Balancer-Knotenpool: Fügen Sie die IP-Adresse des Knotens im Abschnitt spec.loadBalancer.nodePoolSpec.nodes der Cluster-Spezifikation hinzu oder entfernen Sie sie.

Beispiel: Worker-Knoten entfernen

Hier sehen Sie ein Beispiel für eine Clusterkonfigurationsdatei, in der die Spezifikationen von zwei Worker-Knoten angegeben sind:

---
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

So entfernen Sie einen Knoten:

Optional: Wenn auf dem Knoten, den Sie entfernen, kritische Pods ausgeführt werden, versetzen Sie den Knoten zuerst in den Wartungsmodus.

Sie können den Prozess des Node-Draining für Worker-Knoten überwachen, indem Sie die Felder status.nodesDrained und status.nodesDraining in der Ressource NodePool aufrufen.
Bearbeiten Sie die Clusterkonfigurationsdatei, um den IP-Adresseintrag für den Knoten zu löschen.

Aktualisieren Sie den Cluster:

bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

gcloud-CLI

Mit dem Befehl update können Sie Knoten hinzufügen oder entfernen. Der verwendete update-Befehl und das Flag, in dem Sie die IP-Adresse angeben, hängen vom Typ des Knotenpools ab, den Sie aktualisieren möchten:

Worker-Knotenpool: Führen Sie gcloud container bare-metal node-pools update aus und geben Sie die IP-Adresse im Flag --node-configs 'node-ip=IP_ADDRESS' an.
Knotenpool der Steuerungsebene in einem Administratorcluster: Führen Sie gcloud container bare-metal admin-clusters update aus und geben Sie die IP-Adresse im Flag --control-plane-node-configs 'node-ip=IP_ADDRESS' an.
Knotenpool der Steuerungsebene in einem Nutzercluster: Führen Sie gcloud container bare-metal clusters update aus und geben Sie die IP-Adresse im Flag --control-plane-node-configs 'node-ip=IP_ADDRESS' an.
Load-Balancer-Knotenpool: Führen Sie gcloud container bare-metal clusters update aus und geben Sie die IP-Adresse im Flag --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' oder
--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS' an.

Das Flag, in dem Sie die IP-Adresse angeben, akzeptiert nur ein node-ip. Sie fügen das Flag für jede IP-Adresse im Knotenpool ein.

Mit den update-Befehlen werden alle IP-Adressen durch die von Ihnen angegebenen IP-Adressen ersetzt. Wenn Sie einen Knoten hinzufügen möchten, geben Sie im Befehl update die IP-Adressen der vorhandenen Knoten und die IP-Adresse des neuen Knotens an. Entsprechend entfernen Sie Knoten, indem Sie nur die IP-Adressen der Knoten angeben, die Sie behalten möchten.

Beispiel: Worker-Knoten entfernen

In diesem Abschnitt wird anhand von Beispieldaten gezeigt, wie Sie einen Worker-Knoten aus einem Knotenpool entfernen. Zusätzliche gcloud-Befehlszeilenbefehle, die nützlich sein könnten, sind ebenfalls in den folgenden Schritten enthalten.

Optional: Wenn auf dem Knoten, den Sie entfernen, kritische Pods ausgeführt werden, versetzen Sie den Knoten zuerst in den Wartungsmodus.

Sie können den Prozess des Node-Draining für Worker-Knoten überwachen, indem Sie die Felder status.nodesDrained und status.nodesDraining in der Ressource NodePool aufrufen.

Führen Sie den Befehl list aus, um alle Knotenpools im Cluster aufzulisten:

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

Die Ausgabe sieht in etwa so aus:

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

Führen Sie den Befehl describe aus, um alle IP-Adressen im Knotenpool aufzulisten:
```
gcloud container bare-metal node-pools describe node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1
```
Die folgende Beispielausgabe wurde zur besseren Lesbarkeit gekürzt:
```
annotations:
  ...
  baremetal.cluster.gke.io/version: 1.33
...
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
...
```
Beachten Sie in der Beispielausgabe Folgendes:
- Das Feld name enthält den voll qualifizierten Namen des Knotenpools. Wenn Sie den Knotenpoolnamen in einem Befehl angeben, können Sie entweder den vollständig qualifizierten Namen oder den Knotenpoolnamen, z. B. node-pool-1, zusammen mit den Flags --cluster, --project und --location angeben.
- Der Abschnitt nodeConfigs enthält zwei nodeIp-Felder mit den IP-Adressen der Knoten.
Führen Sie den folgenden Befehl aus, um den Knoten mit der IP-Adresse 192.0.2.1 zu entfernen:
```
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'
```
Mit dem Befehl update werden alle IP-Adressen durch die von Ihnen angegebenen IP-Adressen ersetzt. Da 192.0.2.1 nicht enthalten ist, wird der Knoten entfernt.

Die Ausgabe dieses Befehls sieht in etwa so aus:
```
Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9] to complete
```
In der Beispielausgabe ist der String operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 der OPERATION_ID des Vorgangs mit langer Ausführungszeit. Sie können den Status des Vorgangs ermitteln, indem Sie den folgenden Befehl in einem anderen Terminalfenster ausführen:
```
gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \
    --project= example-project-12345 \
    --location=us-central1
```
Sie können den Befehl regelmäßig ausführen, um den Status zu prüfen.

Wenn das Entfernen des Knotens fehlschlägt, können Sie das Entfernen aus dem Cluster erzwingen. Weitere Informationen finden Sie unter Fehlerhaften Knoten in Google Distributed Cloud zurücksetzen.

HA-Knoten der Steuerungsebene ersetzen

`bmctl`

Mit bmctl können Sie HA-Knoten (Hochverfügbarkeit) der Steuerungsebene in allen Clustertypen ersetzen.

Sie ersetzen einen Knoten in einem Cluster, indem Sie die folgenden Schritte ausführen:

Entfernen Sie die IP-Adresse des Knotens aus der Clusterkonfigurationsdatei.
Aktualisieren Sie den Cluster.
Prüfen Sie den Status der Knoten im Cluster.
Fügen Sie die IP-Adresse des neuen Knotens derselben Clusterkonfigurationsdatei hinzu.
Aktualisieren Sie den Cluster.

Beispiel: HA-Knoten der Steuerungsebene ersetzen

Hier ist ein Beispiel für eine Clusterkonfigurationsdatei mit drei Knoten der Steuerungsebene in einem Nutzercluster:

---
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

Führen Sie die folgenden Schritte aus, um den letzten Knoten im Abschnitt spec.controlPlane.nodePoolSpec.nodes zu ersetzen:

Entfernen Sie den Knoten, indem Sie seinen IP-Adresseintrag in der Clusterkonfigurationsdatei löschen. Nach dieser Änderung sollte die Clusterkonfigurationsdatei etwa so aussehen:

---
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

Aktualisieren Sie den Cluster mit dem folgenden Befehl:
```
bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG
```
Nehmen Sie die folgenden Änderungen vor:
- Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie aktualisieren möchten.
- Wenn es sich bei dem Cluster um einen selbstverwalteten Cluster handelt (z. B. ein Administrator- oder Standalone-Cluster), ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei des Clusters. Wenn es sich bei dem Cluster um einen Nutzercluster handelt, wie in diesem Beispiel, ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei des Administratorclusters.
Nachdem der Befehl bmctl update erfolgreich ausgeführt wurde, dauert es einige Zeit, bis die Jobs machine-preflight und machine-init abgeschlossen sind. Mit den Befehlen, die im Abschnitt Updates überprüfen dieses Dokuments beschrieben sind, können Sie den Status von Knoten und den zugehörigen Knotenpools aufrufen. Wenn sich der Knotenpool und die Knoten im Status „Bereit“ befinden, können Sie mit dem nächsten Schritt fortfahren.
Fügen Sie dem Knotenpool einen neuen Steuerungsebenenknoten hinzu, indem Sie die IP-Adresse des neuen Steuerungsebenenknotens dem Abschnitt spec.controlPlane.nodePoolSpec.nodes der Clusterkonfigurationsdatei hinzufügen. Nach dieser Änderung sollte die Clusterkonfigurationsdatei etwa so aussehen:
```
---
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
```

Aktualisieren Sie den Cluster mit dem folgenden Befehl:

bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG

gcloud-CLI

Sie können die gcloud CLI verwenden, um Knoten der Steuerungsebene mit Hochverfügbarkeit (HA) in Administrator- und Nutzerclustern zu ersetzen.

Sie ersetzen einen Knoten in einem Cluster, indem Sie die folgenden Schritte ausführen:

Entfernen Sie die IP-Adresse des Knotens mit dem entsprechenden update-Befehl:
- Nutzercluster: gcloud container bare-metal clusters update
- Administratorcluster: gcloud container bare-metal admin-clusters update
Prüfen Sie den Status des Knotens, der aus dem Cluster entfernt wurde, indem Sie gcloud container bare-metal operations describe OPERATION_ID ausführen.
Fügen Sie die IP-Adresse des neuen Knotens mit dem entsprechenden update-Befehl hinzu.

Beispiel: HA-Knoten der Steuerungsebene ersetzen

In diesem Abschnitt wird gezeigt, wie Sie die Steuerungsebene eines Clusters anhand von Beispieldaten ersetzen. Zusätzliche gcloud-Befehlszeilenbefehle, die nützlich sein könnten, sind ebenfalls in den folgenden Schritten enthalten.

Führen Sie den Befehl list aus, um alle Nutzercluster in einemGoogle Cloud -Projekt aufzulisten:
```
gcloud container bare-metal clusters list \
    --project=example-project-12345 \
    --location=-
```
Wenn Sie --location=- festlegen, bedeutet dies, dass alle Cluster in allen Regionen aufgelistet werden. Wenn Sie den Bereich in der Liste verkleinern möchten, legen Sie --location auf eine bestimmte Region fest.

Die Ausgabe sieht in etwa so aus:
```
NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
abm-user-cluster1a   us-central1   1.33      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.33      abm-admin-cluster1   RUNNING
```
Führen Sie den Befehl describe für den Cluster aus:
```
gcloud container bare-metal clusters describe abm-user-cluster1  \
    --project=example-project-12345 \
    --location=us-central1
```
Die Beispielausgabe wurde zur besseren Lesbarkeit gekürzt:
```
...
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
...
```
Beachten Sie in der Beispielausgabe Folgendes:
- Das Feld name enthält den vollständig qualifizierten Namen des Clusters. Wenn Sie den Clusternamen in einem Befehl angeben, können Sie entweder den vollständig qualifizierten Namen oder den Clusternamen, z. B. abm-user-cluster1a, zusammen mit --project und --location flags angeben.
- Der Abschnitt nodeConfigs enthält drei nodeIp-Felder mit den IP-Adressen der Knoten der Steuerungsebene.

Entfernen Sie den Knoten mit der IP-Adresse 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'

Die Ausgabe dieses Befehls sieht in etwa so aus:

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

In der Beispielausgabe ist der String operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 der OPERATION_ID des Vorgangs mit langer Ausführungszeit. Sie können den Status des Vorgangs ermitteln, indem Sie den folgenden Befehl in einem anderen Terminalfenster ausführen:

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

Sie können den Befehl regelmäßig ausführen, um den Status zu prüfen.

Fügen Sie den neuen Knoten mit der IP-Adresse 192.0.2.14 hinzu:

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'

Aktualisierungen bestätigen

`kubectl`

Mit dem Befehl kubectl get können Sie den Status von Knoten und den zugehörigen Knotenpools anzeigen lassen.

Der folgende Befehl zeigt beispielsweise den Status der Knotenpools im Cluster-Namespace cluster-my-cluster an:

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

Das System gibt Ergebnisse ähnlich der folgenden:

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 bedeutet, dass der Abgleich noch läuft. Warten Sie, bis sich der Status in Reconciling=0 ändert.

Sie können den Status von Knoten in einem Cluster auch mit dem folgenden Befehl prüfen:

kubectl get nodes --kubeconfig=KUBECONFIG

gcloud-CLI

Wie bereits beschrieben, können Sie nach dem Ausführen eines update-Befehls den Status des Vorgangs mit gcloud container bare-metal operations describe OPERATIONS_ID prüfen. Die Ausgabe des Befehls gibt den Status der Knoten an, z. B.:

  ...
  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
...

Unabhängig davon, welches Tool Sie zum Aktualisieren eines Knotenpools verwenden, können Sie den aktuellen Status eines Knotenpools abrufen, indem Sie den entsprechenden describe-Befehl wie oben gezeigt ausführen.

Weitere Informationen zur Diagnose Ihrer Cluster finden Sie unter Snapshots zur Diagnose von Clustern erstellen.

Load-Balancer-Adresspools

bmctl

Der Abschnitt addressPools enthält Felder zum Angeben von Load-Balancing-Pools für die gebündelten Load-Balancer von MetalLB und Border Gateway Protocol (BGP). Sie können jederzeit weitere Load-Balancing-Adresspools hinzufügen, aber keine vorhandenen Adresspools entfernen. Ab Google Distributed Cloud-Version 1.16.0 können Sie die Werte für addressPools.avoidBuggyIPs und addressPools.manualAssign jederzeit ändern.

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

gcloud-CLI

Sie können jederzeit weitere Load-Balancing-Adresspools für die gebündelten Load Balancer hinzufügen, aber keine vorhandenen Adresspools entfernen. Das Flag, das Sie in gcloud container bare-metal clusters update angeben, um einen Adresspool hinzuzufügen, hängt vom Typ des gebündelten Load-Balancers ab:

MetalLB (Layer 2): Verwenden Sie das Flag --metal-lb-address-pools.
Border Gateway Protocol (BGP): Verwenden Sie das Flag --bgp-address-pools.

Die Werte für die Flags haben das folgende Format:

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

Der Wert umfasst Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die einzelnen Segmente durch ein Komma.

pool: Ein Name Ihrer Wahl für den Pool.
avoid-buggy-ips: Wenn Sie diesen Wert auf True setzen, weist der IPAM-Controller (IP address management, IP-Adressverwaltung) den Diensten keine IP-Adressen zu, die mit .0 oder .255 enden. Dadurch wird verhindert, dass fehlerhafte Geräte versehentlich Traffic löschen, der an diese speziellen IP-Adressen gesendet wird. Enthält standardmäßig den Wert False, wenn nichts anderes angegeben ist. Ab Google Distributed Cloud Version 1.16.0 können Sie diesen Wert in einem vorhandenen Adresspool ändern.
manual-assign: Wenn der IPAM-Controller IP-Adressen aus diesem Pool nicht automatisch Diensten zuweisen soll, legen Sie für dieses Feld True fest. Anschließend können Entwickler einen Service vom Typ LoadBalancer erstellen und eine der Adressen manuell aus dem Pool angeben. Wenn nicht angegeben, wird manual-assign auf False gesetzt. Ab Google Distributed Cloud-Version 1.16.0 können Sie diesen Wert in einem vorhandenen Adresspool ändern.
In der Liste der addresses: Jede Adresse muss ein Bereich sein, entweder im Format CIDR oder Bereich mit Bindestrich. Um eine einzelne IP-Adresse in einem Pool (z. B. für die virtuelle IP-Adresse für eingehenden Traffic) anzugeben, verwenden Sie /32 in CIDR-Notation (z. B. 192.0.2.1/32).

Beachten Sie die folgenden Syntaxregeln:

Setzen Sie den gesamten Wert in einfache Anführungszeichen.
Leerzeichen sind nicht zulässig.
Trennen Sie die einzelnen IP-Adressbereiche durch ein Semikolon.

Sie können das Flag mehrmals angeben, wie im folgenden Beispiel gezeigt:

--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'

Weitere Informationen zu Load-Balancer-Adresspools finden Sie unter loadBalancer.addressPools in „Gebündeltes Load-Balancing konfigurieren“.

Versehentliches Löschen von Clustern verhindern

`bmctl`

Wenn Sie die Annotation baremetal.cluster.gke.io/prevent-deletion: "true" in Ihre Clusterkonfigurationsdatei einfügen, können Sie den Cluster nicht löschen. Wenn Sie beispielsweise kubectl delete cluster oder bmctl reset cluster ausführen, wird ein Fehler ausgegeben.

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:

gcloud-CLI

Wenn Sie das Flag --add-annotations mit dem Wert baremetal.cluster.gke.io/prevent-deletion="true" angeben, können Sie den Cluster nicht löschen. Beispiele:

Fügen Sie die Anmerkung hinzu, um ein versehentliches Löschen des Clusters zu verhindern:

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"

Versuchen Sie, den Nutzercluster zu löschen:

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

Die Antwort des Befehls sieht in etwa so aus:

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

Geben Sie --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" im Befehl update an, um die Annotation zu entfernen.

Preflight-Prüfungen umgehen

Diese Funktion ist nur mit bmctl update verfügbar.

Der Standardwert des Felds bypassPreflightCheck ist false. Wenn Sie dieses Feld in der Clusterkonfigurationsdatei auf true setzen, werden die internen Preflight-Prüfungen ignoriert, wenn Sie Ressourcen auf vorhandene Cluster anwenden.

  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

Clusteradministratoren hinzufügen oder entfernen

`bmctl`

Sie können einen Nutzer oder ein Dienstkonto als Clusteradministrator für einen Nutzercluster hinzufügen oder entfernen, indem Sie E-Mail-Adressen im Abschnitt clusterSecurity.authorization.clusterAdmin.gcpAccounts der Clusterkonfigurationsdatei angeben. Den Konten wird die Rolle „cluster-admin“ für den Cluster und damit vollständiger Zugriff auf den Cluster gewährt.

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

Wenn Sie einen Nutzercluster aktualisieren, um ein Konto hinzuzufügen, müssen Sie alle Konten in die Liste aufnehmen (sowohl bestehende als auch neue Konten), da bmctl update die Liste mit den Angaben in der Konfigurationsdatei überschreibt. Wenn Sie ein Konto entfernen möchten, entfernen Sie es aus der Clusterkonfigurationsdatei und führen Sie bmctl update aus.

gcloud-CLI

Sie können einen Nutzer oder ein Dienstkonto als Clusteradministrator hinzufügen oder entfernen, indem Sie eine E‑Mail-Adresse im Flag --admin-users angeben. Für das Flag kann nur eine E‑Mail-Adresse angegeben werden. Wenn Sie mehrere Nutzer hinzufügen möchten, geben Sie ein Konto in jedem Flag an, z. B.:

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

Mit dem Befehl update wird die gesamte Liste der Berechtigungen überschrieben. Geben Sie alle vorhandenen und neuen Nutzer an, die Clusteradministratoren sein sollen.

Anmeldenutzer festlegen

Sie können einen Nicht-Root-Nutzernamen angeben, den Sie für den Zugriff auf die Knotenmaschinen in Ihrem Cluster mit der sudo-Funktion ohne Passwort verwenden möchten. Der SSH-Schlüssel sshPrivateKeyPath muss für den angegebenen Nutzer funktionieren. Mit den Vorgängen zum Erstellen und Aktualisieren von Clustern wird geprüft, ob auf Knotencomputer mit dem angegebenen Nutzer und SSH-Schlüssel zugegriffen werden kann.

`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

gcloud-CLI

Sie geben den Nutzer, den Sie für den Zugriff auf Knotenmaschinen verwenden möchten, im Flag --login-user an, z. B.:

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

So aktivieren Sie den passwortlosen sudo-Zugriff für einen Nutzer auf jedem Clusterknoten:

Öffnen Sie die sudoers-Datei mit sudo visudo zur Bearbeitung:
```
sudo visudo -f /etc/sudoers
```
Der Befehl visudo sperrt die sudoers-Datei, um gleichzeitige Änderungen zu verhindern, und validiert die Syntax der Datei beim Speichern.
Fügen Sie für Ihren Anmeldenutzer einen Eintrag in die sudoers-Datei ein, z. B.:
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
Schließen und speichern Sie die Datei.
Führen Sie den folgenden Befehl aus, um Befehle mit den Berechtigungen des angemeldeten Nutzers auszuführen:
```
su - USERNAME
```
Führen Sie den folgenden sudo-Befehl aus, um zu prüfen, ob für den Anmeldenutzer kein Passwort erforderlich ist, um sudo-Befehle auszuführen:
```
sudo ip a
```

Erweiterte Netzwerkeinstellungen

Sie konfigurieren erweiterte Netzwerkfunktionen in verschiedenen benutzerdefinierten Ressourcen, nachdem der Cluster erstellt wurde. Wenn Sie die benutzerdefinierten Ressourcen und zugehörigen Netzwerkfunktionen verwenden möchten, müssen Sie beim Erstellen des Clusters erweiterte Netzwerkfunktionen aktivieren.

`bmctl`

Legen Sie beim Erstellen des Clusters in der Clusterkonfiguration clusterNetwork.advancedNetworking auf true fest:

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

gcloud-CLI

Fügen Sie beim Erstellen des Clusters das Flag --enable-advanced-networking in den Befehl gcloud container bare-metal clusters create ein.

Nachdem der Cluster mit aktiviertem erweiterten Netzwerk erstellt wurde, können Sie die in diesem Abschnitt beschriebenen benutzerdefinierten Ressourcen mit kubectl apply konfigurieren.

`NetworkGatewayGroup`

Die benutzerdefinierte NetworkGatewayGroup-Ressource wird verwendet, um Floating-IP-Adressen für erweiterte Netzwerkfeatures bereitzustellen, z. B. das NAT-Gateway für ausgehenden Traffic oder das gebündelte Load-Balancing Feature mit BGP.

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

BGP-Load-Balancing

Sie konfigurieren das BGP-Load-Balancing (Border Gateway Protocol) in der Clusterressource und anderen benutzerdefinierten Ressourcen. Mit den Befehlen gcloud container bare-metal clusters create und update kann BGP in der Clusterressource konfiguriert werden, nicht jedoch in den benutzerdefinierten Ressourcen.

Wenn Sie gebündelte Load-Balancer mit BGP konfigurieren, verwendet das Load-Balancing der Datenebene standardmäßig dieselben externen Peers, die für das Peering der Steuerungsebene angegeben wurden. Alternativ können Sie das Load-Balancing der Datenebene separat mit der benutzerdefinierten Ressource BGPLoadBalancer und der benutzerdefinierten Ressource BGPPeer konfigurieren. Weitere Informationen finden Sie unter Gebündelte Load-Balancer mit BGP konfigurieren.

`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

Service-Netzwerkbereich erweitern

Wenn Sie mehr Dienste als das ursprüngliche Limit erstellen möchten, können Sie die IPv4-Dienst-CIDR-Maske verkleinern, um das Dienstnetzwerk Ihres Clusters zu vergrößern. Wenn Sie die Maske (den Wert nach „/“) verkleinern, wird ein größerer Netzwerkbereich verwendet. Sie können den Bereich des IPv4-Service-CIDR nur erweitern. Der Netzwerkbereich kann nicht verkleinert werden. Das bedeutet, dass die Maske (der Wert nach „/“) nicht erhöht werden kann.

`bmctl`

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

gcloud-CLI

Wenn Sie den Bereich des IPv4-Dienst-CIDR in einem Nutzercluster vergrößern möchten, geben Sie den neuen Bereich im Flag --island-mode-service-address-cidr-blocks an.

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

Kubelet-Image-Pull-Einstellungen konfigurieren

Das Kubelet wird auf jedem Knoten Ihres Clusters ausgeführt. Das Kubelet ist für die Überwachung von Containern auf einem Knoten und dafür verantwortlich, dass sie fehlerfrei funktionieren. Bei Bedarf fragt das Kubelet Images aus der Artifact Registry ab und ruft sie ab.

Das manuelle Aktualisieren Ihrer kubelet-Konfigurationen und das Synchronisieren dieser Konfigurationen auf allen Clustern kann eine Herausforderung sein. Erschwerend kommt hinzu, dass manuelle Änderungen an der kubelet-Konfiguration auf Ihren Knoten verloren gehen, wenn Sie Ihren Cluster aktualisieren.

Um synchronisierte Updates zu vereinfachen und dauerhaft zu machen, können Sie in Google Distributed Cloud einige Kubelet-Einstellungen für jeden Ihrer Clusterknotenpools angeben: Knoten der Steuerungsebene, Load-Balancer-Knoten und Worker-Knoten. Die Einstellungen gelten für alle Knoten in einem bestimmten Pool und bleiben auch nach Cluster-Upgrades erhalten. Die Felder für diese Einstellungen können geändert werden. Sie können sie also jederzeit aktualisieren, nicht nur bei der Clustererstellung.

`bmctl`

Die folgenden unterstützten Felder steuern Artifact Registry-Pull-Vorgänge für kubelet:

registryBurst (Standardeinstellung: 10)
registryPullQPS (Standardeinstellung: 5)
serializeImagePulls (Standardeinstellung: true)

Weitere Informationen zu den einzelnen kubelet-Konfigurationsfeldern finden Sie in der Referenz zu den Clusterkonfigurationsfeldern.

Sie können diese Felder in kubeletConfig-Abschnitten der Cluster- und NodePool-Spezifikation für die folgenden Knotenpools angeben:

Clusterspezifikation:
Knoten der Steuerungsebene spec.controlPlane.nodePoolSpec.kubeletConfig
Load-Balancer-Knoten spec.loadBalancer.nodePoolSpec.kubeletConfig
NodePool-Spezifikation:
Worker-Knoten spec.kubeletConfig

Das folgende Beispiel zeigt die hinzugefügten Felder mit ihren Standardwerten in der Clusterkonfigurationsdatei. Beachten Sie, dass die Annotation preview.baremetal.cluster.gke.io/custom-kubelet: "enable" erforderlich ist.

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

Die Einstellung gilt jeweils für alle Knoten im Pool.

gcloud-CLI

Die folgenden Flags steuern Artifact Registry-Pull-Vorgänge für kubelet:

Verwendung

Hier einige Überlegungen zum Optimieren von Bild-Pulls:

Da Images standardmäßig nacheinander abgerufen werden, kann ein Image-Abruf, der lange dauert, alle anderen Image-Abrufe verzögern, die auf einem Knoten geplant sind. Verzögerte Image-Pulls können den Upgradeprozess blockieren, insbesondere wenn neue Google Distributed Cloud-Images auf einem Knoten bereitgestellt werden müssen. Wenn Sie von Verzögerungen beim Abrufen von Images betroffen sind, können Sie das Serialisieren von Image-Abrufen deaktivieren, um parallele Image-Abrufe zu ermöglichen.
Wenn Sie Drosselungsfehler beim Abrufen von Bildern erhalten, z. B. pull QPS exceeded, sollten Sie *-registry-pull-qps und *-registry-burst erhöhen, um den Durchsatz beim Abrufen von Bildern zu steigern. Mit diesen beiden Feldern werden die Pull-Rate und die Warteschlangengröße angepasst. Das kann helfen, andere Probleme im Zusammenhang mit der Drosselung zu beheben. Negative Werte sind nicht zulässig.

Keepalived-Anpassung

Ab Version 1.32 bietet Google Distributed Cloud einige Anpassungsmöglichkeiten für die Keepalived-Konfiguration. Beim gebündelten Load-Balancing stellt der Load-Balancer der Steuerungsebene die virtuelle IP-Adresse (VIP) der Steuerungsebene bereit. Google Distributed Cloud führt Keepalived und HAProxy als statische Kubernetes-Pods auf den Load-Balancer-Knoten aus, um den VIP der Steuerungsebene anzukündigen. Keepalived verwendet das Virtual Router Redundancy Protocol (VRRP) auf den Load-Balancer-Knoten zur Hochverfügbarkeit.

Für Cluster der Version 1.32 und höher gelten die folgenden Keepalived-Anpassungen:

Für Steuerungsebenen mit Hochverfügbarkeit konfiguriert Google Distributed Cloud automatisch die Keepalived-VRRP-Konfiguration, um das Failover-Verhalten deterministisch zu machen und das Interleaving von ARP-Antworten mit unterschiedlichen MAC-Adressen zu verhindern:
- Jede Keepalived-Instanz wird automatisch mit einem anderen priority-Wert im VRRP-Router konfiguriert.
- Jede Keepalived-Instanz wird automatisch mit nopreempt konfiguriert, um Wahlen zu vermeiden, wenn eine Nicht-Master-Instanz neu gestartet wird.
Mit Google Distributed Cloud können Sie die Anzahl der Gratuitous ARP-Nachrichten (GARP) angeben, die gleichzeitig gesendet werden sollen, nachdem ein Steuerungsebenenknoten in die Rolle des Masterservers gewechselt ist. Wenn Sie die Anzahl der zu sendenden GARP-Nachrichten ändern möchten, fügen Sie das Feld controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat der Clusterkonfigurationsdatei hinzu, legen Sie es auf den neuen Wert fest und aktualisieren Sie Ihren Cluster. Dieser Wert entspricht der Einstellung vrrp_garp_master_repeat für Keepalived. Der Standardwert ist 5.

Das folgende Beispiel zeigt, wie Sie keepalivedVRRPGARPMasterRepeat in der Clusterkonfigurationsdatei angeben:
```
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.33
  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
  ...
```

Gebündelten NVIDIA GPU-Operator installieren oder deinstallieren

Mit dem NVIDIA GPU Operator können Sie GPU-bezogene Arbeitslasten in Ihren Clustern ausführen. Ab Google Distributed Cloud-Version 1.33.0 werden Cluster mit einem vollständigen NVIDIA GPU-Operator-Stack gebündelt, um eine verwaltete Lösung für die Verarbeitung der NVIDIA-Softwarekomponenten bereitzustellen, die für die Bereitstellung von GPUs auf den Worker-Knoten Ihres Clusters erforderlich sind.

Vorbereitung

Bevor Sie den gebündelten NVIDIA GPU Operator installieren, muss Ihre Umgebung die folgenden Anforderungen erfüllen:

Betriebscluster: Sie haben einen funktionsfähigen Bare Metal-Cluster mit Google Distributed Cloud erstellt.
NVIDIA-GPUs: Die NVIDIA-GPUs sind auf den Worker-Knoten Ihres Clusters installiert. Der folgende Abschnitt zur Installation des NVIDIA GPU-Operators enthält Schritte, mit denen Sie überprüfen können, ob die GPUs richtig installiert sind und von Ihrem Betriebssystem erkannt werden.
Kompatible NVIDIA-Treiberversion: Die von Ihnen verwendete NVIDIA-Treiberversion muss mit Ihrer GPU, Ihrem Betriebssystem und der CUDA-Version kompatibel sein, die von Ihren Anwendungen verwendet wird. Weitere Informationen finden Sie unter Versionsinformationen.

Sie haben die folgenden Optionen für die Installation von NVIDIA-Treibern:
- Verwenden Sie den NVIDIA-Treiber, der in Ihrem Betriebssystem-Image vorinstalliert ist.
- Folgen Sie der Anleitung im NVIDIA Driver Installation Quickstart Guide, um den NVIDIA-Treiber manuell zu installieren.
Der NVIDIA-GPU-Treiber muss installiert und bereit sein, bevor Sie den gebündelten NVIDIA GPU Operator aktivieren.

Versionsinformationen

Dieser Abschnitt enthält Informationen zur Softwareversion des mitgelieferten NVIDIA GPU Operator.

Versionen von Softwarekomponenten

In Google Distributed Cloud-Releaseversion 1.33 ist Version 25.3.1 des NVIDIA GPU-Operators enthalten. In Google Distributed Cloud enthält das Bundle die folgenden Images:

NVIDIA Container Toolkit-Version 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

Die mit Google Distributed Cloud Release 1.33 gebündelten Image-Versionen stimmen möglicherweise nicht genau mit den in den Versionshinweisen zu 25.3.1 aufgeführten Softwarekomponentenversionen überein.

Treiberkompatibilität

Informationen zur Treiberkompatibilität finden Sie im NVIDIA Docs Hub unter Platform Support for version 25.3.1.

Aktualisieren des mitgelieferten NVIDIA GPU-Operators

Wenn Sie den NVIDIA GPU Operator in Ihrem Cluster installiert haben, wird beim Upgrade auf eine neue Nebenversion die neueste gebündelte Version des NVIDIA GPU Operators installiert.

Gebündelten Operator installieren

Da der gebündelte NVIDIA GPU-Operator in der Vorschauphase ist, installieren Sie ihn mit bmctl update, um dem Cluster mit GPU-Knoten die folgende Annotation hinzuzufügen:

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:
  ...

Der NVIDIA GPU-Operator-Stack wird im Cluster installiert, wenn die Annotation angewendet wird.

Gebündelten Operator deinstallieren

Da der gebündelte NVIDIA-GPU-Operator in der Vorabversion ist, deinstallieren Sie ihn mit bmctl update, um die folgende Annotation aus dem Cluster mit GPU-Knoten zu entfernen:

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

Alle Komponenten des NVIDIA GPU Operator-Stacks werden aus dem Cluster entfernt, wenn die Annotation entfernt wird.

Dynamische Ressourcenzuweisung aktivieren

Die dynamische Ressourcenzuweisung ist eine Kubernetes API, mit der Sie allgemeine Ressourcen wie GPUs für Pods und Container anfordern und freigeben können. Diese Ressourcen werden von Drittanbietertreibern verwaltet. Mit dieser Funktion können Sie KI-Arbeitslasten ausführen, indem Sie die GPU-Ressourcen in Ihren Bare-Metal-Clustern dynamisch und präzise zuweisen. So lassen sich Ressourcennutzung und Leistung für anspruchsvolle Arbeitslasten verbessern.

Die dynamische Ressourcenzuweisung ist für Cluster mit Version 1.33 und höher als Vorschau verfügbar. In der folgenden Anleitung wird beschrieben, wie Sie Ihren Cluster für die Verwendung der dynamischen Ressourcenzuweisung konfigurieren. Nachdem die Funktion aktiviert wurde, können Sie Ihre GPU-Arbeitslasten so konfigurieren, dass sie die dynamische Ressourcenzuweisung verwenden.

Konfigurieren Sie Ihren Cluster, um die dynamische Ressourcenzuweisung zu aktivieren:

Bearbeiten Sie die Konfigurationsdatei des Clusters, um die Preview-Annotation preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" einzufügen, und fügen Sie DynamicResourceAllocation: true im Abschnitt kubeletConfig unter featureGates hinzu:

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

Aktualisieren Sie den Cluster mit dem Befehl bmctl update:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Nutzerclusters, den Sie aktualisieren.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
Nachdem Sie diese Konfiguration angewendet haben, kann das Feld READY für Ihre Bare-Metal-Maschinen mehrmals zwischen True und False wechseln. Warten Sie, bis sich der Wert des Felds READY auf True stabilisiert hat, bevor Sie fortfahren.
Wenn Sie das Feature-Gate DynamicResourceAllocation in Knotenpools mit Knoten mit GPUs aktivieren möchten, legen Sie DynamicResourceAllocation im Abschnitt featureGates des Abschnitts kubeletConfig der NodePool-Spezifikation auf true fest:

Eine Anleitung zum Hinzufügen und Aktualisieren eines Knotenpools finden Sie unter Knotenpools in einem Cluster verwalten.
```
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
```
Nachdem Sie den Knotenpool hinzugefügt oder aktualisiert haben, warten Sie, bis alle Bare-Metal-Maschinen im Knotenpool den Status Ready erreicht haben.

Verwenden Sie den folgenden Befehl, um den Status der Bare-Metal-Maschinen Ihres Clusters zu prüfen:

kubectl get baremetalmachines --kubeconfig ADMIN_KUBECONFIG -A

Wenn die Bare-Metal-Maschinen bereit sind, sollte die Antwort in etwa so aussehen:

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

Beschränkungen

Für den mitgelieferten NVIDIA GPU-Operator gelten die folgenden Einschränkungen:

Der mitgelieferte NVIDIA GPU-Operator unterstützt nur die folgenden NVIDIA-Softwarekomponenten:
- NVIDIA Container Toolkit
- NVIDIA DCGM-Exporter
- NVIDIA Kubernetes Device Plugin
- NVIDIA MIG Manager für Kubernetes.
Während der Vorschau ist die Konfiguration des NVIDIA GPU-Operators festgelegt. Wenn Sie versuchen, Einstellungen anzupassen, werden sie mit den ursprünglichen Installationseinstellungen abgeglichen.
Der mitgelieferte NVIDIA GPU-Operator kann nicht zum Installieren von NVIDIA GPU-Treibern verwendet werden.
Während der Vorschauphase wird für diese Funktion die API-Gruppe resource.k8s.io/v1beta1 verwendet, die sich von der Open-Source-Kubernetes-API-Gruppe für diese Funktion, resource.k8s.io/v1, unterscheidet. Die Open-Source-API-Gruppe v1 bietet mehr Funktionen und eine bessere Stabilität als die API-Gruppe v1beta1.

Nächste Schritte

Informationen zur Verwendung der dynamischen Ressourcenzuweisung mit Ihren GPU-Arbeitslasten finden Sie unter GPU-Geräte mit dynamischer Ressourcenzuweisung verwalten.
Weitere Informationen zur dynamischen Ressourcenzuweisung finden Sie in der Kubernetes-Dokumentation unter Dynamic Resource Allocation.

Cluster aktualisieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Cluster aktualisieren

bmctl

gcloud-CLI

Terraform

Knoten in einem Cluster hinzufügen oder entfernen

bmctl

Beispiel: Worker-Knoten entfernen

gcloud-CLI

Beispiel: Worker-Knoten entfernen

HA-Knoten der Steuerungsebene ersetzen

bmctl

Beispiel: HA-Knoten der Steuerungsebene ersetzen

gcloud-CLI

Beispiel: HA-Knoten der Steuerungsebene ersetzen

Aktualisierungen bestätigen

kubectl

gcloud-CLI

Load-Balancer-Adresspools

bmctl

gcloud-CLI

Versehentliches Löschen von Clustern verhindern

bmctl

gcloud-CLI

Preflight-Prüfungen umgehen

Clusteradministratoren hinzufügen oder entfernen

bmctl

gcloud-CLI

Anmeldenutzer festlegen

bmctl

gcloud-CLI

Erweiterte Netzwerkeinstellungen

bmctl

gcloud-CLI

NetworkGatewayGroup

BGP-Load-Balancing

BGPLoadBalancer

BGPPeer

Service-Netzwerkbereich erweitern

bmctl

gcloud-CLI

Kubelet-Image-Pull-Einstellungen konfigurieren

bmctl

gcloud-CLI

Verwendung

Keepalived-Anpassung

Gebündelten NVIDIA GPU-Operator installieren oder deinstallieren

Vorbereitung

Versionsinformationen

Versionen von Softwarekomponenten

Treiberkompatibilität

Aktualisieren des mitgelieferten NVIDIA GPU-Operators

Gebündelten Operator installieren

Gebündelten Operator deinstallieren

Dynamische Ressourcenzuweisung aktivieren

Beschränkungen

Nächste Schritte

Referenzdokumentation

bmctl

gcloud-CLI

Terraform

Cluster aktualisieren

`bmctl`

`bmctl`

`bmctl`

`kubectl`

`bmctl`

`bmctl`

`bmctl`

`bmctl`

`NetworkGatewayGroup`

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

`bmctl`