Auf dieser Seite wird beschrieben, wie Sie eine Google Distributed Cloud (GDC)-Appliance mit Air Gap 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 von Generatoren mit Strom versorgt werden kann.
Hinweis
Stoppen Sie alle Arbeitslasten, bevor Sie fortfahren. Google kann nicht garantieren, was passiert, wenn Arbeitslasten während des Herunterfahrens aktiv sind.
Vorbereitung
- Sie können dieses Runbook auf einem Laptop oder einer Workstation ausführen, die mit dem Netzwerk der GDC-Appliance (Google Distributed Cloud) mit Air Gap verbunden ist. Alternativ können Sie einen Laptop oder eine Workstation mit dem Switch verbinden. Folgen Sie dazu der Anleitung unter Gerät verbinden.
- Sie benötigen Zugriff auf die kubeconfig für den Root-Administratorcluster.
- Legen Sie die richtige KUBECONFIG-Umgebungsvariable fest, indem Sie
export KUBECONFIG=PATH_TO_KUBECONFIGausführen. - Achten Sie darauf, dass Sie den SSH-Schlüssel und das Zertifikat haben.
Messer stoppen
Sie können Informationen zu Knoten abrufen, indem Sie
kubectl get nodes -A -o wideausführen.Pausieren Sie die BareMetalHost-Synchronisierung, indem Sie den folgenden Befehl für alle Knoten einzeln ausführen. Ersetzen Sie
NODE_NAMEdurch die im vorherigen Schritt abgerufenen Knotennamen:kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=true" --overwriteDie Ausgabe könnte in etwa so aussehen:
baremetalhost.metal3.io/**-**-bm01 annotated baremetalhost.metal3.io/**-**-bm02 annotated baremetalhost.metal3.io/**-**-bm03 annotatedONTAP Select-Anmeldedaten (OTS) abrufen Sie benötigen diese Anmeldedaten, um OTS-Knoten später herunterzufahren.
Führen Sie den folgenden Befehl aus, um die OTS-Management-IP-Adresse zu ermitteln, die in der Spalte „MGMTIP“ (Management-IP) aufgeführt ist:
export KUBECONFIG=/root/release/root-admin/kube-admin-remote-kubeconfig kubectl get storagecluster -n gpc-systemFühren Sie die folgenden Befehle aus, um das OTS-Administratorpasswort abzurufen:
export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig # Find the secret name SECRET_NAME=$(kubectl get secrets -n gpc-system -o name | grep 'ontap-.*-stge01-credential') # Decode the password from that secret OTS_PASSWORD=$(kubectl get $SECRET_NAME -n gpc-system -o jsonpath='{.data.netapp_password}' | base64 --decode) echo $OTS_PASSWORDSpeichern Sie die OTS-Verwaltungs-IP und das Passwort.
Sperren Sie alle Knoten einzeln:
kubectl cordon NODE_NAMEDie Ausgabe könnte in etwa so aussehen:
node/**-**-bm01 cordoned node/**-**-bm02 cordoned node/**-**-bm03 cordonedONTAP Select-Knoten (OTS) herunterfahren
Stellen Sie mit der Management-IP-Adresse und dem Administratorpasswort, die Sie abgerufen haben, eine SSH-Verbindung zum OTS-Cluster her:
ssh admin@<ots-management-ip>Fahren Sie die OTS-Knoten (VMs) herunter. Hier ein Beispiel:
bn-aa-stge01::> cluster show Node Health Eligibility --------------------- ------- ------------ bn-aa-stge01-01 true true bn-aa-stge01-02 true true bn-aa-stge01::> set diag Warning: These diagnostic commands are for use by NetApp personnel only. Do you want to continue? {y|n}: y bn-aa-stge01::> system node halt -node *Damit der Gatekeeper-Webhook das Entleeren des Knotens nicht blockiert, wenn seine Pods offline gehen, setzen Sie die Fehlerrichtlinie vorübergehend auf
Ignore:kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Ignore"}]}'Führen Sie diesen Schritt für alle Knoten einzeln aus, um den etcd-Leaderknoten und die Follower-Knoten zu ermitteln:
Suchen Sie nach Ziel-IPs für SSH, indem Sie die Werte in der Spalte
INTERNAL-IPder Ausgabe vonkubectl get nodes -A -o widenotieren. Stellen Sie eine SSH-Verbindung her:ssh root@INTERNAL-IPFü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 statusAchten Sie auf das Feld
IS LEADER.Die Ausgabe könnte für den etcd-Leaderknoten 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.
Leeren Sie die Knoten.
Leeren Sie die beiden etcd-Follower-Knoten. Leeren Sie den etcd-Leader-Knoten nicht.
kubectl drain NODE_NAME --delete-emptydir-data --grace-period 900 --ignore-daemonsets --disable-evictionDie 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 . . .Fahren Sie die beiden etcd-Follower-Knoten ordnungsgemäß herunter. Führen Sie den nächsten Schritt einzeln für beide Knoten aus.
NODE_NAMEüber iLO deaktivieren:Rufen Sie den Nutzernamen für iLO ab:
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decodeRufen Sie das Passwort für iLO ab:
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decodeBMC-IP-Adresse fürNODE_NAMEanhand von Werten in der SpalteBMC-IPabrufen:kubectl get servers -ARufen Sie die im vorherigen Schritt erhaltene
BMC-IP-Adresse auf und melden Sie sich mit dem erhaltenen Nutzernamen und Passwort an.Bewegen Sie den Mauszeiger auf die erste Schaltfläche in der oberen Zeile. Es sollte
Power: ONangezeigt werden. Klicken Sie darauf. Ein Drop-down-Menü wird angezeigt. Klicken Sie auf das erste Element mit der BezeichnungMomentary Press. Die Farbe der Schaltfläche ändert sich von Grün zu Orange. Das bedeutet, dass der Knoten heruntergefahren wird. Warten Sie, bis die Taste gelb leuchtet. Das bedeutet, dass das Gerät ausgeschaltet ist. Das kann einige Minuten dauern.
Nachdem beide etcd-Follower-Knoten heruntergefahren wurden, wiederholen Sie den Schritt zum Entleeren des Knotens 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 können Sie die Schritte zum Einschalten und Verbinden des Geräts überspringen und direkt mit dem Schritt zum Entfernen der Cordon-Markierung von jedem Knoten beginnen. Nach einem unerwarteten Stromausfall kann es zu Datenverlust kommen, auch nach dem Neustart.
Aktionsplan
Setzen Sie die YubiKeys in die einzelnen Knoten ein.
Schließen Sie die GDC-Air-Gap-Appliance an die Stromversorgung an und drücken Sie die Ein/Aus-Taste auf Knoten
**-**-bm03, um den OTS-Mediator-Server zu starten.Nachdem der Knoten
**-**-bm03verfügbar ist, prüfen Sie, ob der OTS-Mediatorserver aktiv ist. Dazu sehen Sie sich den Status der SCST-Dienste (SCSI Target Subsystem) an. Dieser Dienst sollteActive: active (running)anzeigen:sudo systemctl status scst.serviceDrücke die Ein/Aus-Taste auf den verbleibenden beiden Knoten in beliebiger Reihenfolge.
Warten Sie nach dem Hochfahren der Knoten einige Minuten, bis die Steuerungsebene eine Verbindung herstellt.
kubectlkann innerhalb von 30 Minuten eine Verbindung zur Steuerungsebene herstellen.Rufen Sie die Namen der Knoten ab, indem Sie
kubectl get nodes -Aausführen.Entfernen Sie die Markierung für jeden Knoten, um die Planung zu aktivieren:
kubectl uncordon NODE_NAMESynchronisierung der Bare-Metal-Hosts für jeden Knoten fortsetzen:
kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwriteSetzen Sie die Gatekeeper-Konfiguration des validierenden Webhooks auf
Failzurück, um die Clustersicherheitsrichtlinien wiederherzustellen:kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Fail"}]}'Prüfen Sie den Status der Knoten mit
kubectl get nodes -A.Nachdem alle Knoten
Readysind, warten Sie zwei Stunden, bis die Abstimmung des Basis-Stacks abgeschlossen ist, bevor Sie mit der Fehlerbehebung beginnen.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.300In diesem Fall sind keine weiteren Maßnahmen erforderlich.
Wenn sich ein oder mehrere Knoten im Status
NotReadybefinden, notieren Sie sich den Namen jedes Knotens, der nicht bereit ist, und führen Sie die folgenden Schritte aus: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.300Stellen Sie eine SSH-Verbindung zum Knoten
NotReadyher. Die Ziel-IP-Adressen für SSH sind die Werte in der SpalteINTERNAL-IPder Ausgabe vonkubectl get nodes -A -o wide:ssh root@INTERNAL-IPStarten Sie die Dienste
containerdundkubeletauf dem KnotenNotReadyneu. Führen Sie die folgenden Befehle auf dem Knoten und nicht auf dem Laptop oder der Workstation aus, die mit der GDC-Air-Gap-Appliance verbunden ist:systemctl stop containerd systemctl daemon-reload systemctl restart containerd systemctl stop kubelet systemctl start kubeletPrüfen Sie den Status der Dienste
containerdundkubelet, indem Sie die folgenden Befehle auf dem KnotenNotReadyausführen:systemctl status kubelet systemctl status containerdDie 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
containerdundkubeletausgeführt werden und alle KnotenReadysind, warten Sie zwei Stunden, bis der Basis-Stack abgeglichen wurde, bevor Sie mit der Fehlerbehebung beginnen.