Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Apaga y enciende el dispositivo

En esta página, se describe cómo apagar y encender el dispositivo aislado de Google Distributed Cloud (GDC). Por ejemplo, para mover el dispositivo a una ubicación nueva.

Puedes usar el dispositivo aislado de GDC en ubicaciones operativas transitorias, en las que es necesario apagar el dispositivo para transportarlo entre ubicaciones. Es posible que también debas restablecer el dispositivo después de una falla de energía, ya que los generadores pueden alimentarlo en entornos hostiles.

Antes de comenzar

Asegúrate de detener todas las cargas de trabajo antes de continuar. Google no puede garantizar lo que sucederá si las cargas de trabajo están activas durante un apagado.

Requisitos previos

Puedes ejecutar este runbook en una laptop o estación de trabajo conectada a la red del dispositivo aislado de Google Distributed Cloud (GDC). Como alternativa, puedes conectar una laptop o estación de trabajo para cambiarla. Para ello, sigue los pasos que se indican en Conecta el dispositivo.
Asegúrate de tener acceso al kubeconfig del clúster de administrador raíz.
Ejecuta export KUBECONFIG=PATH_TO_KUBECONFIG para configurar la variable de entorno KUBECONFIG correcta.
Asegúrate de tener la clave y el certificado SSH.

Apaga las placas

Ejecuta kubectl get nodes -A -o wide para obtener información de los nodos.

Ejecuta el siguiente comando para todos los nodos uno por uno para pausar la sincronización de BareMetalHost. Reemplaza NODE_NAME por los nombres de los nodos obtenidos en el paso anterior:

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

El resultado podría ser similar al siguiente ejemplo:

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

Obtén las credenciales de ONTAP Select (OTS). Necesitarás estas credenciales para apagar los nodos de OTS más adelante.

Ejecuta el siguiente comando para identificar la dirección IP de administración de OTS que aparece en la columna MGMTIP (IP de administración):

 export KUBECONFIG=/root/release/root-admin/kube-admin-remote-kubeconfig

 kubectl get storagecluster -n gpc-system

Ejecuta los siguientes comandos para recuperar la contraseña de administrador de 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

Guarda la IP y la contraseña de administración de OTS.

Acordona todos los nodos uno por uno:

kubectl cordon NODE_NAME

El resultado podría ser similar al siguiente ejemplo:

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

Apaga los nodos de ONTAP Select (OTS).

Establece una conexión SSH al clúster de OTS con la dirección IP de administración y la contraseña de administrador que recuperaste:

 ssh admin@<ots-management-ip>

Apaga los nodos de OTS (VM). A continuación, se muestra un ejemplo:

 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 *

Para evitar que el webhook de gatekeeper bloquee los desvíos de nodos cuando sus pods se desconectan, establece temporalmente su política de fallas en Ignore:

kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Ignore"}]}'

Para determinar el nodo líder de etcd y los nodos seguidores, ejecuta este paso uno por uno para todos los nodos:

Para encontrar las IPs de destino para SSH, toma nota de los valores en la columna INTERNAL-IP del resultado de kubectl get nodes -A -o wide. Establece una conexión SSH:
```
ssh root@INTERNAL-IP
```

Para determinar si el nodo actual es líder o seguidor de etcd, ejecuta el siguiente comando dentro de la 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

Presta atención al campo IS LEADER.

El resultado podría ser similar al siguiente ejemplo para el nodo líder de 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 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

El resultado podría ser similar al siguiente ejemplo para los dos nodos seguidores de 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 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

Anota el estado de líder de etcd y seguidor de etcd de los nodos.

Desvía los nodos.

Desvía los dos nodos seguidores de etcd. No desvíes el nodo líder de etcd.

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

El resultado podría ser similar al siguiente:

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

Apaga de forma ordenada los dos nodos seguidores de etcd. Sigue el siguiente paso uno por uno para ambos nodos.
Desactiva NODE_NAME con iLO:
1. Recupera el nombre de usuario de iLO:
```
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decode
```
2. Recupera la contraseña de iLO:
```
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decode
```
3. Recupera la dirección BMC-IP de NODE_NAME de los valores de la columna BMC-IP:
```
kubectl get servers -A
```
4. Visita la dirección BMC-IP obtenida en el paso anterior y accede con el nombre de usuario y la contraseña obtenidos.
5. Coloca el cursor sobre el primer botón de la fila superior. Debería mostrar Power: ON. Haz clic en él. Aparecerá un menú desplegable. Haz clic en el primer elemento etiquetado como Momentary Press. El color del botón cambiará de verde a naranja, lo que significa que el nodo se está apagando. Espera a que el botón cambie de color a amarillo, lo que indica que la máquina se apagó. Esto tardará unos minutos.
Después de que se apaguen ambos nodos seguidores de etcd, repite el paso para desviar el nodo del nodo líder de etcd.

Quita las Yubikeys para el transporte

Si necesitas transportar el sistema después de que se complete la instalación, quita las Yubikeys y transpórtalas por separado. Asegúrate de etiquetar las claves tú mismo.

Enciende y conecta

Si se perdió la energía de forma inesperada, como un apagado forzoso, el dispositivo se vuelve a encender automáticamente. En este caso, puedes omitir los pasos para encender y conectar el dispositivo, y comenzar directamente desde el paso para desacoronar cada nodo. Después de una pérdida de energía inesperada, es posible que pierdas datos, incluso después de reiniciar.

Plan de acción

Inserta las Yubikeys en cada nodo.
Conecta la máquina del dispositivo aislado de GDC a la alimentación y presiona el botón de encendido en el nodo **-**-bm03 para iniciar el servidor mediador de OTS.
Después de que el nodo **-**-bm03 esté disponible, verifica que el servidor mediador de OTS esté activo. Para ello, comprueba el estado de los servicios del subsistema de destino SCSI (SCST). Este servicio debería mostrar Active: active (running):
```
sudo systemctl status scst.service
```
Presiona el botón de encendido en los dos nodos restantes en cualquier orden.
Después de que se enciendan los nodos, espera unos minutos para que se conecte el plano de control. kubectl puede conectarse al plano de control en menos de 30 minutos.
Ejecuta kubectl get nodes -A para obtener los nombres de los nodos.
Desacorona cada nodo para habilitar la programación:
```
kubectl uncordon `NODE_NAME`
```

Reanuda la sincronización de los hosts de hardware directo para cada nodo:

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

Revierte la configuración del webhook de validación de gatekeeper a Fail para restablecer las políticas de seguridad del clúster:

kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Fail"}]}'

Comprueba el estado de los nodos con kubectl get nodes -A.

Si todos los nodos están en estado Ready, espera dos horas para que se complete el proceso de conciliación. El resultado podría ser similar al siguiente:

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

En este caso, no es necesario realizar ninguna otra acción.

De lo contrario, si uno o más nodos están en estado "NotReady", reinicia algunos servicios para preparar el clúster. El resultado podría ser similar al siguiente:

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

En este caso, anota el nombre del nodo que no está listo y continúa con los siguientes pasos.

Establece una conexión SSH al nodo NotReady. Las direcciones IP de destino de SSH son valores en la columna INTERNAL-IP del resultado de kubectl get nodes -A -o wide:
```
ssh root@INTERNAL-IP
```
Reinicia los servicios containerd y kubelet en el nodo NotReady. Los siguientes comandos se deben ejecutar en los nodos, no en la laptop o estación de trabajo del cliente conectada al dispositivo aislado de Google Distributed Cloud (GDC):
```
systemctl stop containerd
systemctl daemon-reload
systemctl restart containerd
systemctl stop kubelet
systemctl start kubelet
```

Para verificar el estado de los servicios containerd y kubelet, ejecuta los siguientes comandos en el nodo NotReady:

systemctl status kubelet
systemctl status containerd