Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Éteindre et rallumer l'appareil

Cette page explique comment éteindre et redémarrer l'appliance Google Distributed Cloud (GDC) isolée. Par exemple, pour déplacer l'appareil vers un nouvel emplacement.

Vous pouvez utiliser l'appliance GDC sous air gap dans des lieux d'opération temporaires, où il est nécessaire d'éteindre l'appareil pour le transporter d'un lieu à 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 un poste de travail connecté au réseau de l'appliance Google Distributed Cloud (GDC) sous air gap. Vous pouvez également connecter un ordinateur portable ou un poste de travail au commutateur en suivant la procédure Connecter l'appareil.
Assurez-vous d'avoir accès au fichier kubeconfig du cluster administrateur racine.
Définissez la variable d'environnement KUBECONFIG appropriée en exécutant export KUBECONFIG=PATH_TO_KUBECONFIG.
Assurez-vous de disposer de la clé SSH et du certificat.

Éteindre les lames

Obtenez des informations sur les nœuds en exécutant kubectl get nodes -A -o wide.

Mettez en pause la synchronisation BareMetalHost en exécutant la commande suivante pour tous les nœuds, un par un. Remplacez NODE_NAME par les noms de nœuds obtenus à l'étape précédente :

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

Le résultat peut ressembler à l'exemple suivant :

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

Obtenez 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-system

Exé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_PASSWORD

Enregistrez l'adresse IP et le mot de passe de gestion de l'OTS.

Confine tous les nœuds un par un :

kubectl cordon NODE_NAME

Le 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-IP du résultat de kubectl get nodes -A -o wide. Établissez une connexion SSH :
```
ssh root@INTERNAL-IP
```

Pour 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 status

Portez une attention particulière au champ IS LEADER.

Le résultat peut ressembler à l'exemple suivant 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.

Videz 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-eviction

Le 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 une par une les étapes suivantes pour les deux nœuds.
Désactiver NODE_NAME à l'aide d'iLO :
1. Récupérez le nom d'utilisateur pour iLO :
```
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decode
```
2. Récupérez le mot de passe pour iLO :
```
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decode
```
3. Récupérez l'adresse BMC-IP pour NODE_NAME à partir des valeurs de la colonne BMC-IP :
```
kubectl get servers -A
```
4. Accédez à l'adresse BMC-IP obtenue à l'étape précédente, puis connectez-vous en saisissant le nom d'utilisateur et le mot de passe obtenus.
5. Pointez sur le premier bouton de la première ligne. Power: ON devrait 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 que les deux nœuds de suivi etcd ont été arrêtés, répétez enfin l'étape pour vider le nœud pour le nœud leader etcd.

Supprimer des YubiKey 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. Veillez à taguer vous-même les clés.

Mettre sous tension et se connecter

Si l'alimentation a été coupée de manière 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éconnecter 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 la machine de l'appliance GDC sous air gap sur une prise électrique, puis appuyez sur le bouton Marche/Arrêt du nœud **-**-bm03 pour démarrer le serveur médiateur OTS.
Une fois le nœud **-**-bm03 disponible, vérifiez que le serveur de médiation OTS est actif en vérifiant l'état des services du sous-système cible SCSI (SCST). Ce service doit afficher Active: active (running) :
```
sudo systemctl status scst.service
```
Appuyez 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. kubectl peut se connecter au plan de contrôle en moins de 30 minutes.
Obtenez les noms des nœuds en exécutant kubectl get nodes -A.
Marquez chaque nœud comme non programmable pour activer la planification :
```
kubectl uncordon `NODE_NAME`
```

Reprenez la synchronisation des hôtes Bare Metal pour chaque nœud :

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

Rétablissez la configuration du webhook de validation Gatekeeper sur Fail pour 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.

Si tous les nœuds sont à l'état Ready, attendez deux heures que le processus de réconciliation se termine. 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.300

Dans ce cas, aucune autre action n'est requise.

Sinon, si un ou plusieurs nœuds sont à l'état "NotReady" (Non prêt), redémarrez certains services pour préparer le cluster. 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   NotReady   control-plane   4d13h   v1.30.6-gke.300

Dans ce cas, notez le nom du nœud qui n'est pas prêt et passez aux étapes suivantes.

Établissez une connexion SSH au nœud NotReady. Les adresses IP cibles de SSH sont les valeurs de la colonne INTERNAL-IP de la sortie de kubectl get nodes -A -o wide :
```
ssh root@INTERNAL-IP
```
Redémarrez les services containerd et kubelet sur le nœud NotReady. Les commandes suivantes doivent être exécutées sur les nœuds, et non sur l'ordinateur portable ou le poste de travail du client connecté à l'appliance Google Distributed Cloud (GDC) isolée :
```
systemctl stop containerd
systemctl daemon-reload
systemctl restart containerd
systemctl stop kubelet
systemctl start kubelet
```

Pour vérifier l'état des services containerd et kubelet, exécutez les commandes suivantes sur le nœud NotReady :

systemctl status kubelet
systemctl status containerd