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 änderbarer Felder in den Cluster- und Knotenpoolressourcen.
• Ändern Sie andere benutzerdefinierte Ressourcen.

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 Feldreferenz 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 Beschreibung aufzurufen.

• Die gcloud CLI und Terraform unterstützen nur die Aktualisierung von Administrator- und Nutzerclustern. Zum Aktualisieren anderer 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.

Cluster aktualisieren

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

bmctl

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

2. 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 admin-Clusters ein.

Verwenden Sie bmctl update und kubectl apply -f beim Bearbeiten der Clusterkonfigurationsdatei nicht synonym. Werden diese Befehle austauschbar verwendet, können Inhalte, die im Header der Clusterspezifikation eingefügt werden, versehentlich entfernt werden. Sie können beispielsweise bmctl update verwenden, um die Clusterkonfigurationsdatei zum Konfigurieren einer Registry-Spiegelung zu aktualisieren. Im Cluster ist dann nach dem Abgleich spec.nodeConfig.registryMirrors ausgefüllt.

Wenn Sie dann versuchen, mithilfe der Clusterkonfiguration und dem Befehl kubectl apply -f Änderungen am Cluster vorzunehmen, wird der vom Abgleich auf dem Cluster ausgefüllte spec.nodeConfig.registryMirrors entfernt. Dieses Verhalten ist darauf zurückzuführen, dass die Konfiguration nicht in der Clusterkonfigurationsspezifikation vorhanden ist, im Cluster jedoch schon.

gcloud-CLI

1. Geben Sie nur die Flags für die Konfiguration an, die Sie ändern möchten.

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

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

   • google_gkeonprem_bare_metal_admin_cluster

   • google_gkeonprem_bare_metal_cluster

   • google_gkeonprem_bare_metal_node_pool

2. Aktualisieren Sie die Konfiguration mit dem Befehl terraform apply.

In den folgenden Abschnitten werden einige gängige Beispiele für die Aktualisierung eines vorhandenen Clusters beschrieben.

Knoten in einem Cluster hinzufügen oder entfernen

Ein Knotenpool ist eine Gruppe von Knoten in einem Cluster, die dieselbe Konfiguration haben. 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. Wenn Sie einen Knoten aus einem Knotenpool entfernen, wird der Knoten auch komplett 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 Knoten zu den einzelnen Arten von Knotenpools hinzugefügt oder daraus entfernt werden.

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, welcher Bereich 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 Cluster-Konfigurationsdatei, die die Spezifikationen von zwei Worker-Knoten enthält:

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

1. (Optional) Wenn der zu entfernende Knoten kritische Pods ausführt, versetzen Sie den Knoten zuerst in den Wartungsmodus.

   Sie können den Knotenausgleich für Worker-Knoten überwachen. Sehen Sie sich dazu die Felder status.nodesDrained und status.nodesDraining in der Ressource NodePool an.

2. Bearbeiten Sie die Clusterkonfigurationsdatei, um den IP-Adresseintrag für den Knoten zu löschen.

3. 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 den Befehl 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, mit dem Sie die IP-Adresse angeben, akzeptiert nur genau ein node-ip. Sie fügen das Flag für jede IP-Adresse im Knotenpool ein.

Die update-Befehle ersetzen alle IP-Adressen durch die von Ihnen angegebenen IP-Adressen. Wenn Sie einen Knoten hinzufügen möchten, nehmen Sie die IP-Adressen der vorhandenen Knoten und die IP-Adresse des neuen Knotens in den Befehl update auf. 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 gezeigt, wie Sie einen Worker-Knoten anhand von Beispieldaten aus einem Knotenpool entfernen. In den folgenden Schritten finden Sie weitere nützliche gcloud-Kommandozeilenbefehle.

1. (Optional) Wenn der zu entfernende Knoten kritische Pods ausführt, versetzen Sie den Knoten zuerst in den Wartungsmodus.

   Sie können den Knotenausgleich für Worker-Knoten überwachen. Sehen Sie sich dazu die Felder status.nodesDrained und status.nodesDraining in der Ressource NodePool an.

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

3. 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 gekürzt:

   annotations:
     ...
     baremetal.cluster.gke.io/version: 1.29
   ...
   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 vollständig qualifizierten Namen des Knotenpools. Wenn Sie den Knotenpoolnamen in einem Befehl angeben, können Sie zusammen mit den Flags --cluster, --project und --location entweder den vollständig qualifizierten Namen oder den Knotenpoolnamen wie node-pool-1 angeben.

   • Der Abschnitt nodeConfigs enthält zwei nodeIp-Felder mit den IP-Adressen der Knoten.

4. 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 die 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 hin und wieder 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 fehlerhafter Knoten erzwingen.

Knoten der Hochverfügbarkeit der Steuerungsebene ersetzen

bmctl

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

So ersetzen Sie einen Knoten in einem Cluster:

1. Entfernen Sie die IP-Adresse des Knotens aus der Clusterkonfigurationsdatei.
2. Aktualisieren Sie den Cluster.
3. Prüfen Sie den Status der Knoten im Cluster.
4. Fügen Sie der selben Clusterkonfigurationsdatei die IP-Adresse eines neuen Knotens hinzu.
5. Aktualisieren Sie den Cluster.

Beispiel: Knoten der Hochverfügbarkeit auf der Steuerungsebene ersetzen

Hier sehen 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:

1. Entfernen Sie den Knoten, indem Sie seinen IP-Adresseintrag in der Clusterkonfigurationsdatei löschen. Nachdem Sie diese Änderung vorgenommen haben, 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
   

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

3. 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 lassen. Führen Sie dazu die Befehle aus, die im Abschnitt Aktualisierungen überprüfen dieses Dokuments beschrieben werden. Sobald der Knotenpool und die Knoten bereit sind, können Sie mit dem nächsten Schritt fortfahren.

4. Sie fügen dem Knotenpool einen neuen Knoten der Steuerungsebene hinzu. Dazu fügen Sie die IP-Adresse des neuen Knotens der Steuerungsebene dem Abschnitt spec.controlPlane.nodePoolSpec.nodes der Clusterkonfigurationsdatei hinzu. Nachdem Sie diese Änderung vorgenommen haben, 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
   

5. 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 (High Availability, HA) in Administrator- und Nutzerclustern zu ersetzen.

So ersetzen Sie einen Knoten in einem Cluster:

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

2. Prüfen Sie den Status der Knotenentfernung aus dem Cluster mit dem Befehl gcloud container bare-metal operations describe OPERATION_ID.

3. Fügen Sie die IP-Adresse des neuen Knotens hinzu, indem Sie den entsprechenden update-Befehl ausführen.

Beispiel: Knoten der Hochverfügbarkeit auf der Steuerungsebene ersetzen

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

1. 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 in der Liste nach unten gehen müssen, legen Sie für --location eine bestimmte Region fest.

   Die Ausgabe sieht in etwa so aus:

   NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
   abm-user-cluster1a   us-central1   1.29      abm-admin-cluster1   RUNNING
   abm-user-cluster1b   europe-west1  1.29      abm-admin-cluster1   RUNNING
   

2. Führen Sie den Befehl describe im Cluster aus:

   gcloud container bare-metal clusters describe abm-user-cluster1  \
       --project=example-project-12345 \
       --location=us-central1
   

   Die Beispielausgabe ist 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 zusammen mit --project und --location flags entweder den vollständig qualifizierten Namen oder den Clusternamen wie abm-user-cluster1a angeben.

   • Der Abschnitt nodeConfigs enthält drei nodeIp-Felder mit den IP-Adressen der Knoten der Steuerungsebene.

3. 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 die 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 hin und wieder ausführen, um den Status zu prüfen.

4. 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 Abgleichsschritt noch läuft. Sie sollten warten, bis sich der Status zu 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 der Ausführung 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, zum 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, mit welchem Tool Sie einen Knotenpool aktualisieren, können Sie den aktuellen Status eines Knotenpools abrufen, indem Sie den entsprechenden describe-Befehl wie zuvor gezeigt ausführen.

Weitere Informationen zum Diagnostizieren Ihrer Cluster finden Sie unter Snapshots zur Clusterdiagnose erstellen.

Load-Balancer-Adresspools

bmctl

Der Abschnitt addressPools enthält Felder zum Angeben von Load-Balancing-Pools für die gebündelten Load-Balancer des MetalLB- und Border Gateway Protocol (BGP). Sie können jederzeit weitere Load-Balancing-Adresspools hinzufügen, vorhandene Adresspools jedoch nicht 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 für die gebündelten Load-Balancer jederzeit weitere Adresspools für das Load-Balancing hinzufügen. Vorhandene Adresspools lassen sich jedoch nicht entfernen. Welches Flag 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 folgendes Format:

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

Der Wert enthält Segmente, die mit den Keywords pool, avoid-buggy-ip, manual-assign und addresses beginnen. Trennen Sie die Segmente durch Kommas.

• 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) Diensten keine IP-Adressen zu, die auf .0 oder .255 enden. Dadurch wird das Problem vermieden, dass fehlerhafte Nutzergeräte den an diese speziellen IP-Adressen gesendeten Traffic versehentlich unterbrechen. Wenn keine Angabe erfolgt, wird standardmäßig False verwendet. Ab Google Distributed Cloud Version 1.16.0 können Sie diesen Wert in einem vorhandenen Adresspool ändern.

• manual-assign: Wenn der IPAM-Controller nicht automatisch IP-Adressen aus diesem Pool Diensten zuweisen soll, legen Sie True fest. Anschließend kann ein Entwickler einen Service vom Typ LoadBalancer erstellen und manuell eine der Adressen aus dem Pool angeben. Wenn keine Angabe erfolgt, 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 im Format CIDR oder mit Bindestrich sein. Verwenden Sie /32 in CIDR-Notation, um eine einzelne IP-Adresse in einem Pool anzugeben (z. B. für die virtuelle IP-Adresse für eingehenden Traffic), 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 Adresspools für Load-Balancer finden Sie im Artikel „Gebündeltes Load-Balancing konfigurieren“ unter loadBalancer.addressPools.

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. Das Ausführen von kubectl delete cluster oder bmctl reset cluster führt beispielsweise zu einem Fehler.

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:

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

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

Preflight-Prüfungen umgehen

Diese Funktion ist nur für bmctl update verfügbar.

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

  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. 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 und damit vollen 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:
        - [e-mail]
        - [e-mail]
        - [e-mail]

Wenn Sie einem Nutzercluster ein Konto hinzufügen, müssen Sie alle Konten in die Liste aufnehmen (sowohl vorhandene als auch neue Konten), da bmctl update die Liste mit dem überschreibt, was Sie in der Konfigurationsdatei angeben. 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. Dazu geben Sie 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 für jedes Flag ein Konto an. Beispiel:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --admin-users=[e-mail] \
    --admin-users=[e-mail]
    --admin-users=[e-mail]

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

Log-in-Nutzer festlegen

Sie können einen Nicht-Root-Nutzernamen angeben, den Sie für den passwortlosen Zugriff mit sudo-Funktionen auf die Knotenmaschinen in Ihrem Cluster verwenden möchten. Der SSH-Schlüssel sshPrivateKeyPath muss für den angegebenen Nutzer funktionieren. Die Erstellungs- und Aktualisierungsvorgänge des Clusters prüfen, 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, mit dem Sie auf Knotenmaschinen zugreifen 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

Führen Sie auf jedem Clusterknotencomputer die folgenden Schritte aus, um für einen Nutzer den passwortlosen Zugriff auf sudo zu aktivieren:

1. Verwenden Sie sudo visudo, um die sudoers-Datei zum Bearbeiten zu öffnen:

   sudo visudo -f /etc/sudoers
   

   Der Befehl visudo sperrt die sudoers-Datei, um gleichzeitige Bearbeitungen zu verhindern, und validiert die Syntax der Datei beim Speichern.

2. Fügen Sie für den Log-in-Nutzer der sudoers-Datei den folgenden Eintrag hinzu:

   USERNAME ALL=(ALL) NOPASSWD: ALL
   

3. Schließen und speichern Sie die Datei.

4. Führen Sie den folgenden Befehl aus, um Befehle mit den Berechtigungen Ihres angemeldeten Nutzers auszuführen:

   su - USERNAME
   

5. Prüfen Sie mit dem folgenden sudo-Befehl, ob der angemeldete Nutzer zum Ausführen von sudo-Befehlen ein Passwort benötigt:

   sudo ip a
   

Erweiterte Netzwerkeinstellungen

Sie konfigurieren erweiterte Netzwerkfeatures in verschiedenen benutzerdefinierten Ressourcen, nachdem der Cluster erstellt wurde. Damit Sie die benutzerdefinierten Ressourcen und die zugehörigen Netzwerkfeatures verwenden können, müssen Sie beim Erstellen des Clusters das erweiterte Netzwerk 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.

Hinweis: Der Befehl gcloud container bare-metal clusters update unterstützt die Konfiguration dieser benutzerdefinierten Ressourcen nicht.

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

Reichweite des Mobilfunknetzes erhöhen

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

Pull-Einstellungen für Kubelet-Images konfigurieren

Das Kubelet wird auf jedem Knoten des Clusters ausgeführt. Mit dem Kubelet werden Container auf einem Knoten überwacht und geprüft, ob sie fehlerfrei sind. Bei Bedarf fragt das Kubelet Images aus Container Registry ab und ruft sie daraus ab.

Es kann eine Herausforderung sein, die Kubelet-Konfigurationen manuell zu aktualisieren und über alle Clusterknoten hinweg zu synchronisieren. Außerdem gehen manuelle kubelet-Konfigurationsänderungen auf Ihren Knoten beim Upgrade Ihres Clusters verloren.

Um synchronisierte Aktualisierungen einfacher und persistent 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 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 Container Registry-Pull-Vorgänge für Kubelet:

Warnung: Das Festlegen von registryBurst oder registryPullQPS auf einen negativen Wert führt zu Fehlern bei Aktualisierungsjobs für die Kubelet-Konfiguration. Um das Problem zu beheben, aktualisieren Sie diese Felder entweder in positive Werte oder entfernen Sie sie aus der Spezifikation. Wenn der Aktualisierungsjob lange Zeit fehlschlägt, kann er den Speicherplatz auf dem Maschinenlaufwerk mit Sicherungsdateien der Kubelet-Konfiguration auffüllen. Sie finden diese Sicherungsdateien in /var/lib/kubelet/config.yaml.bkup.*. Wenn diese Sicherungsdateien zu viel Speicherplatz belegen, können Sie sie entfernen.

• registryBurst (Standard: 10)
• registryPullQPS (Standard: 5)
• serializeImagePulls (Standardeinstellung: „true“)

Weitere Informationen zu den einzelnen kubelet-Konfigurationsfeldern finden Sie in der Referenz zum Feld für die Clusterkonfiguration.

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

• Knoten der Steuerungsebene

  • --control-plane-registry-burst
  • --control-plane-registry-pull-qps
  • --disable-control-plane-serialize-image-pulls
  • --enable-control-plane-serialize-image-pulls

• Load-Balancer-Knoten

  • --bgp-load-balancer-registry-burst
  • --bgp-load-balancer-registry-pull-qps
  • --disable-bgp-load-balancer-serialize-image-pulls
  • --enable-bgp-load-balancer-serialize-image-pulls
  • --metal-lb-load-balancer-registry-burst
  • --metal-lb-load-balancer-registry-pull-qps
  • --disable-metal-lb-load-balancer-serialize-image-pull
  • --enable-metal-lb-load-balancer-serialize-image-pulls

• Worker-Knoten

  • --registry-burst
  • --registry-pull-qps
  • --disable-serialize-image-pulls
  • --enable-serialize-image-pulls

Warnung: Wenn Sie für die Flags *-registryburst oder *-registry-pull-qps einen negativen Wert festlegen, schlägt die kubelet-Konfiguration Aktualisierungsjobs fehl. Aktualisieren Sie diese Felder in positive Werte, um das Problem zu beheben. Wenn der Aktualisierungsjob über einen längeren Zeitraum fehlschlägt, kann er den Speicherplatz auf der Maschine mit Sicherungsdateien für die Kubelet-Konfiguration auffüllen. Sie finden diese Sicherungsdateien in /var/lib/kubelet/config.yaml.bkup.*. Wenn diese Sicherungsdateien zu viel Speicherplatz belegen, können Sie sie entfernen.

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 langes Abrufen von Images alle anderen Image-Abrufe, die auf einem Knoten geplant sind, verzögern. 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 Image-Abrufverzögerungen betroffen sind, können Sie das Abrufen von serialisierten Images deaktivieren, um parallele Image-Abrufe zu ermöglichen.

• Wenn Fehler bei der Image-Pull-Drosselung auftreten, z. B. pull QPS exceeded, sollten Sie *-registry-pull-qps und *-registry-burst erhöhen, um den Image-Pull-Durchsatz zu erhöhen. Diese beiden Felder passen die Pull-Rate und die Größe der Warteschlange an und können bei anderen Problemen im Zusammenhang mit der Drosselung helfen. Negative Werte sind nicht zulässig.

Referenzdokumentation

bmctl

• bmctl-Befehlsreferenz

• Referenz zum Feld für die Clusterkonfiguration

gcloud-CLI

• gcloud container bare-metal clusters

• gcloud container bare-metal node-pools

• gcloud container bare-metal admin-clusters

Terraform

• google_gkeonprem_bare_metal_cluster

• google_gkeonprem_bare_metal_node_pool

• google_gkeonprem_bare_metal_admin_cluster