Cette page a été traduite par l'API Cloud Translation.

Éteindre et rallumer l'appareil

Cette page explique comment arrêter 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 isolée 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) isolée. 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 d'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.

Arrête 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_NAME par les noms de nœuds obtenus à l'étape 1 :

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

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

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 de suivi 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.

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 les étapes suivantes une par une 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 les deux nœuds de suivi etcd arrêtés, répétez l'étape 7 pour le nœud leader etcd.

Retirer les 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.

Allumer et 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 devez commencer à l'étape 7, en ignorant les étapes 1 à 6. 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'appareil GDC isolé à une prise électrique, puis appuyez sur le bouton d'alimentation de chaque nœud dans l'ordre de votre choix.
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

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