Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Cluster aktualisieren

Durch das Ändern vorhandener Clusterkonfigurationen können Sie die Infrastrukturkapazität und die Betriebseinstellungen an die Entwicklung Ihrer Arbeitslasten anpassen. Sie können Knoten hinzufügen, entfernen oder ersetzen, Annotationen aktualisieren und änderbare Einstellungen in Ihrer Umgebung mit bmctl, der Google Cloud CLI oder Terraform ändern. Eine umfassende Liste der unterstützten Felder finden Sie in der Referenz zum Cluster-Konfigurationsfeld.

Die Toolunterstützung hängt vom Clustertyp und den Ressourcen ab, die Sie ändern:

Die gcloud CLI und Terraform unterstützen nur das Aktualisieren von Administrator- und Nutzerclustern. Wenn Sie andere Clustertypen aktualisieren möchten, müssen Sie bmctl verwenden.
Die gcloud CLI und Terraform unterstützen nur Änderungen an Cluster- und NodePool-Ressourcen. Wenn Sie andere benutzerdefinierte Ressourcen aktualisieren möchten, die sich auf den Cluster auswirken, müssen Sie kubectl oder bmctl verwenden.

Cluster aktualisieren

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.

Im Allgemeinen führen Sie die folgende Abfolge von 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 Inhalte, die vom Header der Clusterspezifikation ausgefüllt werden, möglicherweise unbeabsichtigt entfernt. 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 zwar im Cluster, aber nicht in der Clusterkonfigurationsspezifikation 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. Beachten Sie, dass ein Knoten immer zu einem Knotenpool gehört. 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.

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

`bmctl`

Sie können einen Knoten zu einem Knotenpool hinzufügen oder daraus entfernen, indem Sie die IP-Adresse des Knotens in einem bestimmten Abschnitt der Clusterkonfigurationsdatei hinzufügen oder entfernen. In der folgenden Liste sehen Sie, welchen Abschnitt Sie für einen bestimmten Knotenpool bearbeiten müssen:

Worker-Knotenpool: Fügen Sie die IP-Adresse des Knotens im Abschnitt spec.nodes der Spezifikation NodePool 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 Spezifikation Cluster hinzu oder entfernen Sie sie.

Beispiel: Worker-Knoten entfernen

Hier ist ein Beispiel für eine Clusterkonfigurationsdatei, in der die Spezifikationen von zwei Worker-Knoten aufgeführt 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 zum Entleeren von 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

Sie verwenden einen update-Befehl, um Knoten hinzuzufügen oder zu 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 eine 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. Ebenso 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. In den folgenden Schritten sind auch zusätzliche gcloud CLI-Befehle enthalten, die Sie möglicherweise nützlich finden.

(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 zum Entleeren von 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 ist aus Gründen der Lesbarkeit gekürzt:
```
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
...
```
Beachten Sie in der Beispielausgabe Folgendes:
- Das Feld name enthält den voll qualifizierten Namen des Knotenpools. Wenn Sie den Namen des Knotenpools in einem Befehl angeben, können Sie entweder den vollständig qualifizierten Namen oder den Namen des Knotenpools angeben, z. B. node-pool-1, zusammen mit den Flags --cluster, --project und --location.
- 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 von Zeit zu Zeit 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.

Knoten der Steuerungsebene mit Hochverfügbarkeit ersetzen

`bmctl`

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

So ersetzen Sie einen Knoten in einem Cluster:

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 eines neuen Knotens derselben Clusterkonfigurationsdatei hinzu.
Aktualisieren Sie den Cluster.

Beispiel: Knoten der Hochverfügbarkeits-Steuerungsebene ersetzen

Hier ist eine Beispiel-Clusterkonfigurationsdatei, die drei Knoten der Steuerungsebene in einem Nutzercluster zeigt:

---
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 im Abschnitt spec.controlPlane.nodePoolSpec.nodes aufgeführten Knoten zu ersetzen:

Entfernen Sie den Knoten, indem Sie seinen IP-Adresseintrag in der Clusterkonfigurationsdatei löschen. Nach dieser Änderung sollte die Clusterkonfigurationsdatei in 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 der Cluster ein selbstverwalteter Cluster ist (z. B. ein Administrator- oder eigenständiger Cluster), ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei des Clusters. Wenn der Cluster ein Nutzercluster ist, 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. Sie können den Status von Knoten und den zugehörigen Knotenpools anzeigen lassen, indem Sie die Befehle ausführen, die im Abschnitt Aktualisierungen prüfen dieses Dokuments beschrieben sind. Wenn der Knotenpool und die Knoten bereit sind, können Sie mit dem nächsten Schritt fortfahren.
Fügen Sie dem Knotenpool einen neuen Knoten der Steuerungsebene hinzu, indem Sie die IP-Adresse des neuen Knotens der Steuerungsebene dem Abschnitt spec.controlPlane.nodePoolSpec.nodes der Clusterkonfigurationsdatei hinzufügen. Nach dieser Änderung sollte die Clusterkonfigurationsdatei in 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 Hochverfügbarkeits-Steuerungsebene in Administrator- und Nutzerclustern zu ersetzen.

So ersetzen Sie einen Knoten in einem Cluster:

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

Beispiel: Knoten der Hochverfügbarkeits-Steuerungsebene ersetzen

In diesem Abschnitt wird anhand von Beispieldaten gezeigt, wie Sie eine Steuerungsebene aus einem Cluster ersetzen. In den folgenden Schritten sind auch zusätzliche gcloud CLI-Befehle enthalten, die Sie möglicherweise nützlich finden.

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.36      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.36      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 ist aus Gründen der 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 angeben, z. B. abm-user-cluster1a, zusammen mit --project und --location flags.
- 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 von Zeit zu Zeit 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 überprüfen

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

Sie können den Status der 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 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 (Ebene 2): Verwenden Sie das Flag --metal-lb-address-pools.
Border Gateway Protocol (BGP): Verwenden Sie das Flag --bgp-address-pools.

Der Wert für die Flags hat 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-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 festgelegt. 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 mehrere Instanzen des Flags 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 im Abschnitt „Gebündeltes Load-Balancing konfigurieren“.

Versehentliches Löschen von Clustern verhindern

`bmctl`

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

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

Wenn Sie die Annotation entfernen möchten, geben Sie im Befehl update den Wert --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" an.

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 ein Nutzer- oder Dienstkonto als Clusteradministrator für einen Nutzercluster hinzufügen oder entfernen. Geben Sie dazu E-Mail-Adressen im Abschnitt clusterSecurity.authorization.clusterAdmin.gcpAccounts der Clusterkonfigurationsdatei an. Den Konten wird die Rolle „cluster-admin“ für den Cluster zugewiesen, wodurch sie vollständigen Zugriff auf den Cluster erhalten.

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.

Wenn Sie einen Nutzercluster aktualisieren, um ein Konto hinzuzufügen, müssen Sie alle Konten in der Liste angeben (sowohl vorhandene 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. Das Flag akzeptiert nur eine E‑Mail-Adresse. Wenn Sie mehrere Nutzer hinzufügen möchten, geben Sie in jedem Flag ein Konto 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.

Mit dem Befehl update wird die gesamte Liste der Gewährungen ü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 passwortlosen sudo-Funktionszugriff auf die Knotenmaschinen in Ihrem Cluster 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

Geben Sie 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 jeder Clusterknotenmaschine:

Ö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 wie den folgenden in die sudoers-Datei ein:
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
Schließen und speichern Sie die Datei.
Führen Sie den folgenden Befehl aus, um Befehle mit den Berechtigungen Ihres angemeldeten Nutzers auszuführen:
```
su - USERNAME
```
Führen Sie den folgenden sudo-Befehl aus, um zu prüfen, ob für den angemeldeten Nutzer kein Passwort erforderlich ist, um sudo-Befehle auszuführen:
```
sudo ip a
```

Erweiterte Netzwerkeinstellungen

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

`bmctl`

Legen Sie in der Clusterkonfiguration clusterNetwork.advancedNetworking auf true fest, wenn Sie den Cluster erstellen:

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 aktivierten erweiterten Netzwerkoptionen 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 Load Balancing über das Border Gateway Protocol (BGP) in der Clusterressource und anderen benutzerdefinierten Ressourcen. Die Befehle gcloud container bare-metal clusters create und update unterstützen die Konfiguration von BGP in der Clusterressource, aber nicht 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

Dienstnetzwerkbereich erhöhen

Wenn Sie mehr Dienste als das ursprüngliche Limit erstellen möchten, können Sie die IPv4-Dienst-CIDR-Maske reduzieren, um das Dienstnetzwerk Ihres Clusters zu vergrößern. Wenn Sie die Maske (den Wert nach „/“) verringern, wird der Netzwerkbereich größer. Sie können den Bereich des IPv4-Dienst-CIDR nur erhöhen. 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 der IPv4-Dienst-CIDR in einem Nutzercluster erhöhen 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

Ab Version 1.34 werden in Ihrem Cluster neue ServiceCIDR-Ressourcen angezeigt. Diese Ressourcen werden von der Kubernetes-Steuerungsebene verwendet, um die IP-Adressbereiche für Ihre Dienste zu verwalten.

Versuchen Sie nicht, ServiceCIDR-Ressourcen manuell zu erstellen oder zu ändern. Sie werden vom Clusteroperator automatisch anhand der Werte in Ihrer benutzerdefinierten Cluster-Ressource verwaltet. Um Netzwerkprobleme zu vermeiden, werden alle direkten manuellen Änderungen blockiert und Sie erhalten eine Fehlermeldung wie die folgende:

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

Kubelet-Image-Pull-Einstellungen konfigurieren

Das Kubelet wird auf jedem Knoten des Clusters ausgeführt. Das Kubelet ist für das Monitoring von Containern auf einem Knoten und für die Sicherstellung ihres fehlerfreien Zustands verantwortlich. Bei Bedarf fragt das Kubelet Images aus der Artifact Registry ab und ruft sie ab.

Das manuelle Aktualisieren Ihrer Kubelet-Konfigurationen und das Synchronisieren über alle Clusterknoten hinweg kann eine Herausforderung sein. Erschwerend kommt hinzu, dass manuelle Änderungen an der kubelet-Konfiguration auf Ihren Knoten verloren gehen, wenn Sie ein Upgrade Ihres Clusters durchführen.

Damit synchronisierte Aktualisierungen einfacher und dauerhaft sind, können Sie in Google Distributed Cloud einige Kubelet-Einstellungen für jeden Ihrer Cluster-Knotenpools festlegen: Knoten der Steuerungsebene, Load-Balancer-Knoten und Worker-Knoten. Die Einstellungen gelten für alle Knoten in einem bestimmten Pool und bleiben auch nach Clusterupgrades erhalten. Die Felder für diese Einstellungen sind änderbar, sodass Sie sie jederzeit aktualisieren können, nicht nur während 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 den kubeletConfig-Abschnitten der Cluster-Spezifikation und der 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

In jedem Fall gilt die Einstellung für alle Knoten im Pool.

gcloud-CLI

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

Verwendung

Hier einige Überlegungen zur Optimierung von Image-Abrufen:

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-Abrufe 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 Image-Abruf betroffen sind, können Sie die Serialisierung von Image-Abrufen deaktivieren, um parallele Image-Abrufe zu ermöglichen.
Wenn Fehler bei der Drosselung des Image-Abrufs auftreten, z. B. pull QPS exceeded, können Sie *-registry-pull-qps und *-registry-burst erhöhen, um den Durchsatz des Image-Abrufs zu erhöhen. Mit diesen beiden Feldern werden die Abrufrate und die Warteschlangengröße angepasst. Sie können auch zur Behebung anderer Probleme im Zusammenhang mit der Drosselung beitragen. 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 die VIP der Steuerungsebene anzukündigen. Keepalived verwendet das Virtual Router Redundancy Protocol (VRRP) auf den Load-Balancer-Knoten zur Hochverfügbarkeit.

Cluster der Version 1.32 und höher haben die folgenden Keepalived-Anpassungen:

Bei Steuerungsebenen mit Hochverfügbarkeit konfiguriert Google Distributed Cloud automatisch die Keepalived-VRRP-Konfiguration, um das Failover-Verhalten deterministisch zu machen und die Verschachtelung von ARP-Antworten mit unterschiedlichen MAC-Adressen zu verhindern. Dazu wird jede Keepalived-Instanz mit einem anderen priority-Wert konfiguriert.
Mit Google Distributed Cloud können Sie die Anzahl der GARP-Nachrichten (Gratuitous ARP) angeben, die gleichzeitig gesendet werden sollen, nachdem ein Knoten der Steuerungsebene die Rolle des Masterservers übernommen hat. Wenn Sie die Anzahl der zu sendenden GARP-Nachrichten ändern möchten, fügen Sie der Clusterkonfigurationsdatei das Feld controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat hinzu, legen Sie den neuen Wert fest und aktualisieren Sie den Cluster. Dieser Wert wird der Einstellung vrrp_garp_master_repeat für Keepalived zugeordnet. 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.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
  ...
```

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 Ihren Cluster-Worker-Knoten erforderlich sind.

Vorbereitung

Bevor Sie den gebündelten NVIDIA-GPU-Operator installieren, müssen Sie prüfen, ob Ihre Umgebung die folgenden Anforderungen erfüllt:

Betriebscluster: Sie haben einen funktionsfähigen Bare-Metal-Cluster, der mit Google Distributed Cloud erstellt wurde.
NVIDIA-GPUs: Die NVIDIA-GPUs sind auf den Worker-Knoten des Clusters installiert. Der folgende Abschnitt zur Installation des NVIDIA-GPU-Operators enthält Schritte, mit denen Sie prüfen können, ob die GPUs ordnungsgemäß installiert und von Ihrem Betriebssystem erkannt wurden.
Kompatible NVIDIA-Treiberversion: Die von Ihnen verwendete NVIDIA-Treiberversion muss mit Ihrer GPU, Ihrem Betriebssystem und der CUDA-Version kompatibel sein, die Ihre Anwendungen verwenden. 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 in der Kurzanleitung zur Installation von NVIDIA-Treibern, 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 gebündelten NVIDIA GPU Operators.

Versionen der Softwarekomponenten

Die Google Distributed Cloud-Release-Version 1.33 enthält die Version 25.3.1 des NVIDIA GPU Operators. In Google Distributed Cloud enthält das Bundle die folgenden Images (wobei CDI standardmäßig aktiviert ist):

NVIDIA Container Toolkit Version 1.17.9
NVIDIA DCGM Exporter v3.3.9-3.6.1
NVIDIA Kubernetes Device Plugin v0.17.1
Node Feature Discovery v0.17.2

Die in Google Distributed Cloud-Release 1.33 enthaltenen Image-Versionen stimmen möglicherweise nicht genau mit den Softwarekomponentenversionen überein, die in den Versionshinweisen zu 25.3.1 aufgeführt sind.

Treiberkompatibilität

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

Gebündelten NVIDIA GPU-Operator aktualisieren

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

Gebündelten Operator installieren

Während sich der gebündelte NVIDIA GPU-Operator in der Vorabversion befindet, 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

Während sich der gebündelte NVIDIA-GPU-Operator in der Vorabversion befindet, 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 generische Ressourcen wie GPUs zwischen Pods und Containern 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 werden die Ressourcennutzung und die Leistung für anspruchsvolle Arbeitslasten verbessert.

Die dynamische Ressourcenzuweisung ist als Vorabversion für Cluster ab Version 1.33 verfügbar. In der folgenden Anleitung wird beschrieben, wie Sie Ihren Cluster für die Verwendung der dynamischen Ressourcenzuweisung konfigurieren. Nach der Aktivierung 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 Clusterkonfigurationsdatei, um die Vorabversionsannotation preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" einzufügen, und fügen Sie DynamicResourceAllocation: true unter featureGates im Abschnitt kubeletConfig 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, wechselt das Feld READY für Ihre Bare-Metal-Maschinen möglicherweise mehrmals zwischen True und False. Warten Sie, bis sich das Feld READY auf True stabilisiert hat, bevor Sie fortfahren.
Wenn Sie das Feature Gate DynamicResourceAllocation in Knotenpools mit Knoten mit GPUs aktivieren möchten, setzen Sie DynamicResourceAllocation im Abschnitt featureGates des Abschnitts kubeletConfig der NodePool-Spezifikation auf true:

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 gebündelten NVIDIA GPU-Operator gelten die folgenden Einschränkungen:

Der gebündelte 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.
In der Vorabversion ist die Konfiguration des NVIDIA-GPU-Operators fest vorgegeben. Wenn Sie versuchen, Einstellungen anzupassen, werden sie auf die ursprünglichen Installationseinstellungen zurückgesetzt.
Der gebündelte NVIDIA-GPU-Operator kann nicht zum Installieren von NVIDIA-GPU-Treibern verwendet werden.
In der Vorabversion wird für dieses Feature die API-Gruppe resource.k8s.io/v1beta1 verwendet, die sich von der Open-Source-Kubernetes-API-Gruppe für dieses Feature (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 für Ihre GPU-Arbeitslasten finden Sie unter GPU-Geräte mit dynamischer Ressourcenzuweisung verwalten.
Weitere Informationen zur dynamischen Ressourcenzuweisung finden Sie in der Kubernetes-Dokumentation unter Dynamische Ressourcenzuweisung.

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

Knoten der Steuerungsebene mit Hochverfügbarkeit ersetzen

bmctl

Beispiel: Knoten der Hochverfügbarkeits-Steuerungsebene ersetzen

gcloud-CLI

Beispiel: Knoten der Hochverfügbarkeits-Steuerungsebene ersetzen

Aktualisierungen überprüfen

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

Dienstnetzwerkbereich erhöhen

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

Treiberkompatibilität

Gebündelten NVIDIA GPU-Operator aktualisieren

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`