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 Annotationen hinzu oder entfernen Sie sie.
Ändern Sie die Werte änderbarer Felder in den Cluster- und Knotenpoolressourcen.
Andere benutzerdefinierte Ressourcen ändern.

Sie können bmctl oder die Google Cloud CLI verwenden, um Aktualisierungen 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 mehr aktualisiert werden. Eine umfassende Liste der änderbaren und unveränderlichen Felder finden Sie in der Referenz zum Feld für die Clusterkonfiguration. Der Feldverweis ist eine sortierbare Tabelle. Klicken Sie auf die Spaltenüberschriften, um die Sortierreihenfolge zu ändern. Klicken Sie auf einen Feldnamen, um die zugehörige Beschreibung aufzurufen.
Die gcloud CLI und Terraform unterstützen nur die Aktualisierung von Administrator- und Nutzerclustern. Sie müssen bmctl verwenden, um andere Clustertypen zu aktualisieren.
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 den Cluster betreffen.

Cluster aktualisieren

Im Allgemeinen führen Sie zum Aktualisieren eines Clusters die folgenden Schritte aus:

`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 bei Administrator-, Hybrid- oder eigenständigen Clustern den Pfad zur kubeconfig-Datei des Clusters ein. Geben Sie für einen Nutzercluster den Pfad zur kubeconfig-Datei des admin-Clusters ein.

gcloud-CLI

Geben Sie nur die Flags für die Konfiguration an, die Sie ändern möchten.
Führen Sie den entsprechenden Update-Befehl 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, mit der Sie den Cluster oder Knotenpool erstellt haben. Ausführliche Feldbeschreibungen finden Sie in der Terraform-Referenzdokumentation:
Aktualisieren Sie die Konfiguration mit dem Befehl terraform apply.

In den folgenden Abschnitten finden Sie einige allgemeine Beispiele zum Aktualisieren eines vorhandenen Clusters.

Knoten in einem Cluster hinzufügen oder entfernen

Ein Knotenpool ist eine Gruppe von Knoten in einem Cluster mit derselben Konfiguration. Beachten Sie, dass ein Knoten immer zu einem Knotenpool gehört. Um einem Cluster einen neuen Knoten hinzuzufügen, müssen Sie ihn einem bestimmten Knotenpool hinzufügen. Das Entfernen eines Knotens aus einem Knotenpool bedeutet, dass er vollständig aus dem Cluster entfernt wird.

In GDCV für Bare Metal gibt es drei Arten von Knotenpools: Steuerungsebene, Load-Balancer und Worker-Knotenpools. In den folgenden Abschnitten wird beschrieben, wie Sie den einzelnen Knotenpooltypen Knoten 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. Die folgende Liste zeigt, 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 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 Spezifikation Cluster 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 sehen Sie ein Beispiel für eine Clusterkonfigurationsdatei, die die Spezifikationen von zwei Worker-Knoten zeigt:

---
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 zu entfernenden Knoten kritische Pods ausgeführt werden, setzen Sie den Knoten zuerst in den Wartungsmodus.

Sie können den Knotenausgleich für Worker-Knoten überwachen. Dazu rufen Sie die Felder status.nodesDrained und status.nodesDraining in der Ressource NodePool auf.
Löschen Sie in der Clusterkonfigurationsdatei den IP-Adresseintrag für den Knoten.

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 an--metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' oder
--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'

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

Die update-Befehle ersetzen alle IP-Adressen durch die von Ihnen angegebenen IP-Adressen. 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 können Sie Knoten entfernen, indem Sie nur die IP-Adressen der Knoten angeben, die Sie beibehalten möchten.

Beispiel: Worker-Knoten entfernen

In diesem Abschnitt wird gezeigt, wie Sie anhand von Beispieldaten einen Worker-Knoten aus einem Knotenpool entfernen. In den folgenden Schritten finden Sie weitere nützliche gcloud CLI-Befehle.

(Optional) Wenn auf dem zu entfernenden Knoten kritische Pods ausgeführt werden, setzen Sie den Knoten zuerst in den Wartungsmodus.

Sie können den Knotenausgleich für Worker-Knoten überwachen. Dazu rufen Sie die Felder status.nodesDrained und status.nodesDraining in der Ressource NodePool auf.

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 zur besseren Lesbarkeit abgeschnitten:
```
annotations:
  ...
  baremetal.cluster.gke.io/version: 1.16
...
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 voll 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'
```
Der Befehl update ersetzt alle IP-Adressen durch die von Ihnen angegebenen IP-Adressen. 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 noch einmal 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 Entfernen beschädigter Knoten erzwingen.

Knoten der Steuerungsebene mit Hochverfügbarkeit ersetzen

`bmctl`

Sie können bmctl verwenden, um Knoten der Steuerungsebene mit Hochverfügbarkeit in allen Clustertypen zu 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 der gleichen Clusterkonfigurationsdatei die IP-Adresse eines neuen Knotens hinzu.
Aktualisieren Sie den Cluster.

Beispiel: Knoten der Steuerungsebene mit Hochverfügbarkeit ersetzen

Im Folgenden finden Sie 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 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 selbst verwaltender Cluster ist (z. B. Administrator- oder eigenständiger Cluster), ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei des Clusters. Wenn der Cluster wie in diesem Beispiel ein Nutzercluster ist, ersetzen Sie KUBECONFIG durch den Pfad zur kubeconfig-Datei des admin-Clusters.
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 ihren jeweiligen Knotenpools anzeigen. Dazu führen Sie die im Abschnitt Updates prüfen dieses Dokuments beschriebenen Befehle aus. Sobald 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. Fügen Sie dazu die IP-Adresse des neuen Knotens der Steuerungsebene dem Abschnitt spec.controlPlane.nodePoolSpec.nodes der Clusterkonfigurationsdatei hinzu. 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 Steuerungsebene mit Hochverfügbarkeit 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 dem Befehl gcloud container bare-metal operations describe OPERATION_ID.
Fügen Sie die IP-Adresse des neuen Knotens mit dem entsprechenden update-Befehl hinzu.

Beispiel: Knoten der Steuerungsebene mit Hochverfügbarkeit ersetzen

In diesem Abschnitt wird gezeigt, wie Sie anhand von Beispieldaten eine Steuerungsebene aus einem Cluster ersetzen. In den folgenden Schritten finden Sie weitere nützliche gcloud CLI-Befehle.

Führen Sie den Befehl list aus, um alle Nutzercluster in einem Google Cloud-Projekt aufzulisten:

gcloud container bare-metal clusters list \
    --project=example-project-12345 \
    --location=-

Wenn Sie --location=- festlegen, werden alle Cluster in allen Regionen aufgelistet. Wenn Sie die Liste verkleinern müssen, 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.16      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.16      abm-admin-cluster1   RUNNING

Führen Sie den Befehl describe auf dem Cluster aus:
```
gcloud container bare-metal clusters describe abm-user-cluster1  \
    --project=example-project-12345 \
    --location=us-central1
```
Die Beispielausgabe ist zur besseren Lesbarkeit abgeschnitten:
```
...
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 voll qualifizierten Namen des Clusters. Wenn Sie den Clusternamen in einem Befehl angeben, können Sie entweder den voll 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 von Zeit zu Zeit noch einmal 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'

Updates ü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 Abgleich noch läuft. Sie sollten warten, 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 der Ausführung des Befehls update 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. Beispiel:

  ...
  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. Dazu führen Sie den entsprechenden describe-Befehl wie zuvor gezeigt aus.

Weitere Informationen zum Diagnostizieren von Clustern finden Sie unter Snapshots zum Diagnostizieren 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 aus MetalLB und Border Gateway Protocol (BGP). Sie können jederzeit weitere Adresspools für das Load-Balancing hinzufügen, aber keine vorhandenen Adresspools entfernen. Ab GKE on Bare Metal 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 zum Hinzufügen eines Adresspools angeben, 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 Kommas.

pool: Ein Name Ihrer Wahl für den Pool.
avoid-buggy-ips: Wenn Sie hier True festlegen, weist der IPAM-Controller den Diensten keine IP-Adressen zu, die auf .0 oder .255 enden. Dadurch wird das Problem verhindert, dass fehlerhafte Verbrauchergeräte den an diese speziellen IP-Adressen gesendeten Traffic fälschlicherweise abbrechen. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet. Ab GKE on Bare Metal Version 1.16.0 können Sie diesen Wert in einem vorhandenen Adresspool ändern.
manual-assign: Wenn Sie nicht möchten, dass der IPAM-Controller IP-Adressen aus diesem Pool automatisch Diensten zuweist, legen Sie True fest. Anschließend kann ein Entwickler einen Dienst vom Typ LoadBalancer erstellen und manuell eine der Adressen aus dem Pool angeben. Wenn keine Angabe erfolgt, wird manual-assign auf False gesetzt. Ab GKE on Bare Metal Version 1.16.0 können Sie diesen Wert in einem vorhandenen Adresspool ändern.
In der Liste der addresses: Jede Adresse muss ein Bereich im CIDR-Format oder als Bereich mit Bindestrich sein. Wenn Sie eine einzelne IP-Adresse in einem Pool angeben möchten (z. B. für die virtuelle IP-Adresse für eingehenden Traffic), 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 mehr als eine Instanz 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 unter „Gebündeltes Load-Balancing konfigurieren“.

Versehentliches Löschen von Clustern verhindern

`bmctl`

Wenn Sie der Clusterkonfigurationsdatei die Annotation baremetal.cluster.gke.io/prevent-deletion: "true" 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 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. Beispiel:

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 --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" an.

Preflight-Prüfungen umgehen

Diese Funktion ist nur in Verbindung 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 in der Clusterkonfigurationsdatei im Abschnitt clusterSecurity.authorization.clusterAdmin.gcpAccounts E-Mail-Adressen an. Den Konten wird die Rolle „cluster-admin“ für den Cluster gewährt, sodass vollständiger Zugriff auf den Cluster möglich ist.

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 (sowohl vorhandene als auch neue Konten) in die Liste aufnehmen, 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. Geben Sie dazu im Flag --admin-users eine E-Mail-Adresse an. Das Flag akzeptiert nur eine E-Mail-Adresse. Wenn Sie mehrere Nutzer hinzufügen möchten, geben Sie in jedem Flag ein Konto an. Beispiel:

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

Der Befehl update überschreibt die gesamte Erteilungsliste. Geben Sie alle vorhandenen und neuen Nutzer an, die Clusteradministratoren sein sollen.

Angemeldeten Nutzer festlegen

Sie können einen Nicht-Root-Nutzernamen angeben, den Sie für den passwortlosen SUDO-Zugriff auf die Knotenmaschinen in Ihrem Cluster verwenden möchten. Der SSH-Schlüssel sshPrivateKeyPath muss für den angegebenen Nutzer funktionieren. Beim Erstellen und Aktualisieren von Clustern wird geprüft, ob mit dem angegebenen Nutzer und SSH-Schlüssel auf Knotenmaschinen 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

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

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

Erweiterte Netzwerkeinstellungen

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

`bmctl`

Legen Sie clusterNetwork.advancedNetworking in der Clusterkonfiguration 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 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

Das Load-Balancing des Border Gateway Protocol (BGP) wird in der Clusterressource und anderen benutzerdefinierten Ressourcen konfiguriert. Die Befehle gcloud container bare-metal clusters create und update unterstützen die Konfiguration des BGP in der Clusterressource, aber nicht die 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 auf 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

Reichweite des Dienstnetzwerks erhöhen

Wenn Sie mehr Dienste als das anfängliche Limit erstellen möchten, können Sie die CIDR-Maske für IPv4-Dienste verkleinern und so das Dienstnetzwerk Ihres Clusters vergrößern. Das Reduzieren der Maske (der Wert nach „/“) führt zu einem größeren Netzwerkbereich. Sie können den Bereich des IPv4-Dienst-CIDR nur erhöhen. Der Netzwerkbereich kann nicht reduziert werden, was 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 CIDR-Bereich des IPv4-Dienstes 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

Pulllet-Image-Pull-Einstellungen konfigurieren

Das Kubelet wird auf jedem Knoten Ihres Clusters ausgeführt. Kubelet ist dafür verantwortlich, Container auf einem Knoten zu überwachen und zu prüfen, ob sie fehlerfrei sind. Bei Bedarf werden Images von Kubelet aus Container Registry abgefragt und abgerufen.

Es kann eine Herausforderung sein, Kubelet-Konfigurationen manuell zu aktualisieren und über alle Clusterknoten hinweg zu synchronisieren. Außerdem gehen manuelle Kubelet-Konfigurationsänderungen auf Ihren Knoten verloren, wenn Sie Ihren Cluster upgraden.

Damit synchronisierte Aktualisierungen einfacher und dauerhafter werden, können Sie in GKE on Bare Metal 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 über Clusterupgrades erhalten. Die Felder für diese Einstellungen sind änderbar, sodass Sie sie jederzeit und nicht nur während der Clustererstellung aktualisieren können.

`bmctl`

Die folgenden unterstützten Felder steuern Pull-Vorgänge von Container Registry für Kubelet:

registryBurst (Standard: 10)
registryPullQPS (Standard: 5)
serializeImagePulls (Standardeinstellung: wahr)

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

Sie können diese Felder in den kubeletConfig-Abschnitten der Clusterspezifikation und der Knotenpoolspezifikation für die folgenden Knotenpools angeben:

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

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

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 Container Registry-Pull-Vorgänge für Kubelet:

Wie sie eingesetzt wird

Im Folgenden finden Sie einige Überlegungen zur Feinabstimmung von Image-Abrufen:

Da Images standardmäßig in Serie abgerufen werden, kann ein Image-Abruf, der lange dauert, alle anderen auf einem Knoten geplanten Image-Abrufe verzögern. Verzögerte Image-Abrufe können den Upgradeprozess blockieren (insbesondere, wenn neue GKE on Bare Metal-Images auf einem Knoten bereitgestellt werden müssen). Wenn Sie von Image-Abrufverzögerungen betroffen sind, können Sie die Serialisierung von Image-Abrufen deaktivieren, um parallele Image-Abrufe zu ermöglichen.
Wenn bei der Image-Drosselung Fehler wie pull QPS exceeded auftreten, sollten Sie *-registry-pull-qps und *-registry-burst erhöhen, um den Durchsatz des Image-Abrufs zu erhöhen. Diese beiden Felder passen die Pull-Rate und die Warteschlangengröße an und können dabei helfen, andere Probleme mit der Drosselung zu beheben. Negative Werte sind nicht zulässig.

Cluster aktualisieren

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 Steuerungsebene mit Hochverfügbarkeit ersetzen

gcloud-CLI

Beispiel: Knoten der Steuerungsebene mit Hochverfügbarkeit ersetzen

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

Angemeldeten Nutzer festlegen

bmctl

gcloud-CLI

Erweiterte Netzwerkeinstellungen

bmctl

gcloud-CLI

NetworkGatewayGroup

BGP-Load-Balancing

BGPLoadBalancer

BGPPeer

Reichweite des Dienstnetzwerks erhöhen

bmctl

gcloud-CLI

Pulllet-Image-Pull-Einstellungen konfigurieren

bmctl

gcloud-CLI

Wie sie eingesetzt wird

Referenzdokumentation

bmctl

gcloud-CLI

Terraform

`bmctl`

`bmctl`

`bmctl`

`kubectl`

`bmctl`

`bmctl`

`bmctl`

`bmctl`

`NetworkGatewayGroup`

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

`bmctl`