Gerät herunterfahren und einschalten

Auf dieser Seite wird beschrieben, wie Sie eine Google Distributed Cloud-Appliance (GDC) ohne Internetverbindung herunterfahren und hochfahren. Zum Beispiel, um das Gerät an einen neuen Ort zu verschieben.

Sie können die GDC Air-Gap-Appliance an vorübergehenden Einsatzorten verwenden, an denen das Gerät für den Transport ausgeschaltet werden muss, um es zwischen Standorten zu bewegen. Möglicherweise müssen Sie das Gerät nach einem Stromausfall wiederherstellen, da es in rauen Umgebungen möglicherweise von Generatoren mit Strom versorgt wird.

Hinweise

Stoppen Sie alle Arbeitslasten, bevor Sie fortfahren. Google kann nicht garantieren, was passiert, wenn Arbeitslasten während des Herunterfahrens aktiv sind.

Vorbereitung

1. Sie können dieses Runbook auf einem Laptop oder einer Workstation ausführen, die mit dem Netzwerk der Air-Gap-Appliance von Google Distributed Cloud (GDC) verbunden ist. Alternativ können Sie einen Laptop oder eine Workstation mit dem Switch verbinden. Folgen Sie dazu der Anleitung unter Gerät verbinden.
2. Sie benötigen Zugriff auf die kubeconfig-Datei für den Root-Administratorcluster.
3. Legen Sie die richtige KUBECONFIG-Umgebungsvariable mit dem Befehl export KUBECONFIG=PATH_TO_KUBECONFIG fest.
4. Achten Sie darauf, dass Sie den SSH-Schlüssel und das Zertifikat haben.

Schalte die Klingen aus

1. Mit kubectl get nodes -A -o wide können Sie Informationen zu Knoten abrufen.

2. Pausieren Sie die BareMetalHost-Synchronisierung, indem Sie den folgenden Befehl für alle Knoten einzeln ausführen.Ersetzen Sie NODE_NAME durch die in Schritt 1 abgerufenen Knotennamen:

   kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=true" --overwrite
   

   Die Ausgabe könnte so aussehen:

   baremetalhost.metal3.io/**-**-bm01 annotated
   baremetalhost.metal3.io/**-**-bm02 annotated
   baremetalhost.metal3.io/**-**-bm03 annotated
   

3. Sperren Sie alle Knoten einzeln:

   kubectl cordon NODE_NAME
   

   Die Ausgabe könnte so aussehen:

   node/**-**-bm01 cordoned
   node/**-**-bm02 cordoned
   node/**-**-bm03 cordoned
   

4. Führen Sie diesen Schritt für alle Knoten einzeln aus, um den etcd-Leader-Knoten und die Follower-Knoten zu ermitteln:

   1. Suchen Sie nach Ziel-IPs für SSH, indem Sie die Werte in der Spalte INTERNAL-IP der Ausgabe von kubectl get nodes -A -o wide notieren. Stellen Sie eine SSH-Verbindung her:

      ssh root@INTERNAL-IP
      

   2. Führen Sie den folgenden Befehl im SSH-Terminal aus, um festzustellen, ob der aktuelle Knoten der etcd-Leader oder ein Follower ist:

      ETCDCTL_API=3 etcdctl \
          --cacert /etc/kubernetes/pki/etcd/ca.crt \
          --cert /etc/kubernetes/pki/etcd/server.crt \
          --key /etc/kubernetes/pki/etcd/server.key \
          --write-out=table endpoint status
      

      Achten Sie auf das Feld IS LEADER.

      Die Ausgabe für den etcd-Leaderknoten könnte so aussehen:

      [root@**-**-bm0* ~]# ETCDCTL_API=3 etcdctl \
      >      --cacert /etc/kubernetes/pki/etcd/ca.crt \
      >      --cert /etc/kubernetes/pki/etcd/server.crt \
      >      --key /etc/kubernetes/pki/etcd/server.key \
      >      --write-out=table endpoint status
      +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |    ENDPOINT    |        ID        |   VERSION    | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
      | ************** | **************** | 3.4.30-gke.1 |  162 MB |      true |      false |      3641 |   12957958 |           12957958 |        |
      +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
      

      Die Ausgabe für die beiden etcd-Follower-Knoten könnte so aussehen:

      [root@**-**-bm0* ~]# ETCDCTL_API=3 etcdctl \
      >      --cacert /etc/kubernetes/pki/etcd/ca.crt \
      >      --cert /etc/kubernetes/pki/etcd/server.crt \
      >      --key /etc/kubernetes/pki/etcd/server.key \
      >      --write-out=table endpoint status
      +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |    ENDPOINT    |        ID        |   VERSION    | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
      | ************** | **************** | 3.4.30-gke.1 |  163 MB |     false |      false |      3641 |   12957404 |           12957404 |        |
      +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+
      

      Notieren Sie sich den etcd-Leader- und etcd-Follower-Status der Knoten.

5. Leeren Sie die beiden etcd-Follower-Knoten. Führen Sie keinen Drain-Vorgang für den etcd-Leader-Knoten aus.

   kubectl drain NODE_NAME --delete-emptydir-data --grace-period 900 --ignore-daemonsets --disable-eviction
   

   Die Ausgabe könnte so aussehen:

   node/**-**-bm01 already cordoned
   WARNING: ignoring DaemonSet-managed Pods: kube-system/anetd-krj2z, kube-system/etcd-defrag-xh469, kube-system/ipam-controller-manager-2f4dz, kube-system/istio-cni-node-cgqv4, kube-system/kube-proxy-5mwf2, kube-system/localpv-mn2jh, kube-system/metallb-speaker-6l7sv, mon-system/mon-node-exporter-backend-nd8mp, netapp-trident/netapp-trident-node-linux-rrlmd, obs-system/anthos-audit-logs-forwarder-tpfqv, obs-system/anthos-log-forwarder-npjh4, obs-system/kube-control-plane-metrics-proxy-wp8nh, obs-system/log-failure-detector-crbnv, obs-system/oplogs-forwarder-sqwvj, vm-system/macvtap-v9pgp, vm-system/virt-handler-86khx
   pod/grafana-0 deleted
   pod/capi-kubeadm-bootstrap-controller-manager-1.30.400-gke.136lvgtf deleted
   pod/grafana-0 deleted
   pod/grafana-proxy-server-86d8fc4758-mkc4f deleted
   .
   .
   .
   
   node/**-**-bm02 already cordoned
   WARNING: ignoring DaemonSet-managed Pods: kube-system/anetd-v75jz, kube-system/etcd-defrag-t5jnc, kube-system/ipam-controller-manager-5958m, kube-system/istio-cni-node-ggv4c, kube-system/kube-proxy-r6x46, kube-system/localpv-g56xc, kube-system/metallb-speaker-tmw72, mon-system/mon-node-exporter-backend-9rs7k, netapp-trident/netapp-trident-node-linux-9jmfp, obs-system/anthos-audit-logs-forwarder-bwns9, obs-system/anthos-log-forwarder-lbskj, obs-system/kube-control-plane-metrics-proxy-grthl, obs-system/log-failure-detector-dzh4v, obs-system/oplogs-forwarder-vdn7z, vm-system/macvtap-mjwtc, vm-system/virt-handler-dlqvv
   pod/vai-web-plugin-backend-5dfd6d6597-nxxgn
   pod/vai-web-plugin-frontend-6b5468968b-mrr7g
   pod/grafana-proxy-server-64b759fbf6-b8pl8
   pod/iam-bundledidp-backend-0
   .
   .
   .
   

6. Fahren Sie die beiden etcd-Follower-Knoten ordnungsgemäß herunter. Führen Sie den nächsten Schritt einzeln für beide Knoten aus.

7. So deaktivieren Sie NODE_NAME über iLO:

   1. Rufen Sie den Nutzernamen für iLO ab:

      kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decode
      

   2. Rufen Sie das Passwort für iLO ab:

      kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decode
      

   3. Rufen Sie die BMC-IP-Adresse für NODE_NAME anhand der Werte in der Spalte BMC-IP ab:

      kubectl get servers -A
      

   4. Rufen Sie die im vorherigen Schritt erhaltene BMC-IP-Adresse auf und melden Sie sich mit dem erhaltenen Nutzernamen und Passwort an.

   5. Bewegen Sie den Mauszeiger auf die erste Schaltfläche in der oberen Zeile. Es sollte Power: ON angezeigt werden. Klicken Sie darauf. Ein Drop-down-Menü wird angezeigt. Klicken Sie auf den ersten Eintrag mit der Bezeichnung Momentary Press. Die Farbe der Schaltfläche ändert sich von Grün zu Orange. Das bedeutet, dass der Knoten heruntergefahren wird. Warte, bis die Taste gelb leuchtet. Das kann einige Minuten dauern.

8. Nachdem beide etcd-Follower-Knoten heruntergefahren wurden, wiederholen Sie Schritt 7 für den etcd-Leader-Knoten.

YubiKeys für den Transport entfernen

Wenn Sie das System nach der Installation transportieren müssen, entfernen Sie die Yubikeys und transportieren Sie sie separat. Achten Sie darauf, dass Sie die Schlüssel selbst taggen.

Einschalten und verbinden

Wenn die Stromversorgung unerwartet unterbrochen wurde, z. B. durch ein hartes Herunterfahren, wird das Gerät automatisch wieder hochgefahren. In diesem Fall sollten Sie mit Schritt 7 beginnen und die Schritte 1 bis 6 überspringen. Es kann zu einem Datenverlust kommen, der nach einem unerwarteten Stromausfall nicht bestehen bleibt.

Maßnahmenplan

1. Setzen Sie die YubiKeys in jeden Knoten ein.

2. Schließen Sie das GDC-Air-Gap-Gerät an die Stromversorgung an und drücken Sie die Ein-/Aus-Taste auf jedem Knoten in beliebiger Reihenfolge.

3. Warten Sie nach dem Hochfahren der Knoten einige Minuten, bis die Steuerungsebene eine Verbindung herstellt. kubectl kann innerhalb von 30 Minuten eine Verbindung zur Steuerungsebene herstellen.

4. Sie ermitteln die Namen der Knoten durch Ausführen von kubectl get nodes -A.

5. Heben Sie die Sperrung jedes Knotens auf, um die Planung zu aktivieren:

   kubectl uncordon `NODE_NAME`
   

6. Synchronisierung der Bare-Metal-Hosts für jeden Knoten fortsetzen:

   kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwrite
   

7. Prüfen Sie den Status der Knoten mit kubectl get nodes -A.

   • Wenn alle Knoten den Status Ready haben, warten Sie zwei Stunden, bis der Abgleich abgeschlossen ist. Die Ausgabe könnte so aussehen:

     NAME         STATUS     ROLES           AGE     VERSION
     **-**-bm01   Ready      control-plane   4d13h   v1.30.6-gke.300
     **-**-bm02   Ready      control-plane   4d13h   v1.30.6-gke.300
     **-**-bm03   Ready      control-plane   4d13h   v1.30.6-gke.300
     

     In diesem Fall sind keine weiteren Maßnahmen erforderlich.

   • Wenn ein oder mehrere Knoten den Status „NotReady“ haben, starten Sie einige Dienste neu, um den Cluster vorzubereiten. Die Ausgabe könnte so aussehen:

     NAME         STATUS     ROLES           AGE     VERSION
     **-**-bm01   Ready      control-plane   4d13h   v1.30.6-gke.300
     **-**-bm02   Ready      control-plane   4d13h   v1.30.6-gke.300
     **-**-bm03   NotReady   control-plane   4d13h   v1.30.6-gke.300
     

     Notieren Sie sich in diesem Fall den Namen des Knotens, der nicht bereit ist, und fahren Sie mit den nächsten Schritten fort.

8. Stellen Sie eine SSH-Verbindung zum Knoten NotReady her. Die Ziel-IP-Adressen von SSH sind Werte in der Spalte INTERNAL-IP der Ausgabe von kubectl get nodes -A -o wide:

   ssh root@INTERNAL-IP
   

9. Starten Sie die Dienste containerd und kubelet auf dem Knoten NotReady neu. Die folgenden Befehle müssen auf Knoten und nicht auf dem Laptop oder der Workstation des Kunden ausgeführt werden, die mit der Air-Gap-Appliance von Google Distributed Cloud (GDC) verbunden sind:

   systemctl stop containerd
   systemctl daemon-reload
   systemctl restart containerd
   systemctl stop kubelet
   systemctl start kubelet
   

10. Führen Sie auf dem NotReady-Knoten die folgenden Befehle aus, um den Status der Dienste containerd und kubelet zu prüfen:

    systemctl status kubelet
    systemctl status containerd
    

    Die Ausgabe könnte so aussehen:

    # systemctl status kubelet
    ● kubelet.service - kubelet: The Kubernetes Node Agent
    Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/kubelet.service.d
            └─00-standalone_containerd.conf, 10-kubeadm.conf
    Active: active (running) since Thu 2025-03-27 07:58:27 UTC; 34s ago
    .
    .
    .
    
    # systemctl status containerd
    ● containerd.service - containerd container runtime
    Loaded: loaded (/etc/systemd/system/containerd.service; disabled; vendor preset: disabled)
    Active: active (running) since Thu 2025-03-27 07:58:17 UTC; 52s ago
    .
    .
    .
    

    Wenn die Dienste containerd und kubelet nach dem Neustart ordnungsgemäß ausgeführt werden, warten Sie zwei Stunden, bis der Abgleich abgeschlossen ist.