Cette page explique comment éteindre et redémarrer l'appliance Google Distributed Cloud (GDC) sous air gap. Par exemple, pour déplacer l'appareil vers un nouvel emplacement.
Vous pouvez utiliser l'appliance GDC sous air gap dans des emplacements opérationnels temporaires, où il est nécessaire d'éteindre l'appareil pour le transporter d'un emplacement à un autre. Vous devrez peut-être également restaurer l'appareil en cas de panne de courant, car il peut être alimenté par des groupes électrogènes dans des environnements difficiles.
Avant de commencer
Assurez-vous d'arrêter toutes les charges de travail avant de continuer. Google ne peut pas garantir ce qui se passera si des charges de travail sont actives lors d'un arrêt.
Prérequis
- Vous pouvez exécuter ce runbook sur un ordinateur portable ou une station de travail connecté au réseau de l'appliance Google Distributed Cloud (GDC) sous air gap. Vous pouvez également connecter un ordinateur portable ou une station de travail au commutateur en suivant Connecter l'appareil.
- Assurez-vous d'avoir accès au fichier kubeconfig du cluster administrateur racine.
- Définissez la variable d'environnement KUBECONFIG correcte en exécutant
export KUBECONFIG=PATH_TO_KUBECONFIG. - Assurez-vous de disposer de la clé et du certificat SSH.
Éteindre les lames
Obtenez des informations sur les nœuds en exécutant
kubectl get nodes -A -o wide.Mettez en veille la synchronisation BareMetalHost en exécutant la commande suivante pour tous les nœuds, un par un. Remplacez
NODE_NAMEpar les noms de nœuds obtenus à l'étape précédente :kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=true" --overwriteLe résultat peut ressembler à l'exemple suivant :
baremetalhost.metal3.io/**-**-bm01 annotated baremetalhost.metal3.io/**-**-bm02 annotated baremetalhost.metal3.io/**-**-bm03 annotatedObtenez les identifiants ONTAP Select (OTS). Vous aurez besoin de ces identifiants pour éteindre les nœuds OTS ultérieurement.
Exécutez la commande suivante pour identifier l'adresse IP de gestion OTS listée dans la colonne MGMTIP (adresse IP de gestion) :
export KUBECONFIG=/root/release/root-admin/kube-admin-remote-kubeconfig kubectl get storagecluster -n gpc-systemExécutez les commandes suivantes pour récupérer le mot de passe administrateur OTS :
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_PASSWORDEnregistrez l'adresse IP et le mot de passe de gestion de l'OTS.
Marquez tous les nœuds comme non ordonnançables, un par un :
kubectl cordon NODE_NAMELe résultat peut ressembler à l'exemple suivant :
node/**-**-bm01 cordoned node/**-**-bm02 cordoned node/**-**-bm03 cordonedÉteindre les nœuds ONTAP Select (OTS)
Établissez une connexion SSH au cluster OTS à l'aide de l'adresse IP de gestion et du mot de passe administrateur que vous avez récupérés :
ssh admin@<ots-management-ip>Éteignez les nœuds OTS (VM). En voici un exemple :
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 *Pour empêcher le webhook gatekeeper de bloquer les vidanges de nœuds lorsque ses pods sont hors connexion, définissez temporairement sa stratégie d'échec sur
Ignore:kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Ignore"}]}'Pour déterminer le nœud leader et les nœuds suiveurs etcd, exécutez cette étape un par un pour tous les nœuds :
Recherchez les adresses IP cibles pour SSH en notant les valeurs de la colonne
INTERNAL-IPde la sortie dekubectl get nodes -A -o wide. Établissez une connexion SSH :ssh root@INTERNAL-IPPour déterminer si le nœud actuel est un leader ou un follower etcd, exécutez la commande suivante dans le terminal SSH :
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 statusFaites attention au champ
IS LEADER.Le résultat peut ressembler à cet exemple pour le nœud leader etcd :
[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 | | +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+Le résultat peut ressembler à cet exemple pour les deux nœuds suiveurs etcd :
[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 | | +----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+Notez l'état etcd-leader et etcd-follower des nœuds.
Drainez les nœuds.
Drainez les deux nœuds suiveurs etcd. Ne videz pas le nœud leader etcd.
kubectl drain NODE_NAME --delete-emptydir-data --grace-period 900 --ignore-daemonsets --disable-evictionLe résultat peut ressembler à ceci :
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 . . .Arrêtez progressivement les deux nœuds suiveurs etcd. Suivez les étapes suivantes une par une pour les deux nœuds.
Désactivez
NODE_NAMEà l'aide d'iLO :Récupérez le nom d'utilisateur pour iLO :
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decodeRécupérez le mot de passe pour iLO :
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decodeRécupérez l'adresse
BMC-IPpourNODE_NAMEà partir des valeurs de la colonneBMC-IP:kubectl get servers -AAccédez à l'adresse
BMC-IPobtenue à l'étape précédente, puis connectez-vous en saisissant le nom d'utilisateur et le mot de passe obtenus.Pointez sur le premier bouton de la première ligne.
Power: ONdevrait s'afficher. Cliquez dessus. Un menu déroulant s'affiche. Cliquez sur le premier élément intituléMomentary Press. La couleur du bouton passe du vert à l'orange, ce qui signifie que le nœud est en cours d'arrêt. Attendez que le bouton devienne jaune, ce qui indique que la machine est éteinte. Cela prendra quelques minutes.
Une fois les deux nœuds de suivi etcd arrêtés, répétez enfin l'étape pour vider le nœud du nœud leader etcd.
Supprimer les YubiKeys pour le transport
Si vous devez transporter le système une fois l'installation terminée, retirez les YubiKeys et transportez-les séparément. Assurez-vous de taguer vous-même les clés.
Allumer et connecter
En cas de perte d'alimentation inattendue, par exemple en cas d'arrêt forcé, l'appareil redémarre automatiquement. Dans ce cas, vous pouvez ignorer les étapes d'allumage et de connexion de l'appareil, et commencer directement par l'étape Décordonner chaque nœud. Après une coupure de courant inattendue, vous pouvez perdre des données, même après le redémarrage.
Plan d'action
Insérez les YubiKeys dans chaque nœud.
Branchez l'appliance GDC sous air gap sur une prise électrique, puis appuyez sur le bouton Marche/Arrêt du nœud
**-**-bm03pour démarrer le serveur médiateur OTS.Une fois le nœud
**-**-bm03disponible, vérifiez que le serveur médiateur OTS est actif en vérifiant l'état des services du sous-système cible SCSI (SCST). Ce service doit afficherActive: active (running):sudo systemctl status scst.serviceAppuyez sur le bouton Marche/Arrêt des deux nœuds restants, dans n'importe quel ordre.
Une fois les nœuds mis sous tension, attendez quelques minutes que le plan de contrôle se connecte.
kubectlpeut se connecter au plan de contrôle en moins de 30 minutes.Obtenez les noms des nœuds en exécutant la commande
kubectl get nodes -A.Dissociez chaque nœud pour activer la planification :
kubectl uncordon NODE_NAMEReprenez la synchronisation des hôtes Bare Metal pour chaque nœud :
kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwriteRétablissez la configuration du webhook de validation Gatekeeper sur
Failpour restaurer les règles de sécurité du cluster :kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Fail"}]}'Vérifiez l'état des nœuds à l'aide de
kubectl get nodes -A.Une fois que tous les nœuds sont
Ready, attendez deux heures pour permettre à la pile de base de terminer la réconciliation avant de résoudre les problèmes.Le résultat peut ressembler à ceci :
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.300Dans ce cas, aucune autre action n'est requise.
Si un ou plusieurs nœuds sont à l'état
NotReady, notez le nom de chaque nœud qui n'est pas prêt et suivez les étapes suivantes :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Établissez une connexion SSH au nœud
NotReady. Les adresses IP cibles pour SSH sont les valeurs de la colonneINTERNAL-IPde la sortie dekubectl get nodes -A -o wide:ssh root@INTERNAL-IPRedémarrez les services
containerdetkubeletsur le nœudNotReady. Exécutez les commandes suivantes sur le nœud, pas sur l'ordinateur portable ou le poste de travail connecté à l'appliance GDC isolée :systemctl stop containerd systemctl daemon-reload systemctl restart containerd systemctl stop kubelet systemctl start kubeletVérifiez l'état des services
containerdetkubeleten exécutant les commandes suivantes sur le nœudNotReady:systemctl status kubelet systemctl status containerdLe résultat peut ressembler à ceci :
# 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 . . .Une fois les services
containerdetkubeleten cours d'exécution et tous les nœuds à l'étatReady, attendez deux heures pour permettre à la pile de base de terminer la réconciliation avant de résoudre les problèmes.