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

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 nueva ubicación.

Es posible que uses 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 cierre.

Requisitos previos

Puedes ejecutar este manual en una laptop o estación de trabajo conectada a la red del dispositivo aislado de Google Distributed Cloud (GDC). También puedes conectar una laptop o una estación de trabajo al conmutador siguiendo los pasos que se indican en Cómo conectar el dispositivo.
Asegúrate de tener acceso al kubeconfig del clúster de administrador raíz.
Ejecuta export KUBECONFIG=PATH_TO_KUBECONFIG para establecer la variable de entorno KUBECONFIG correcta.
Asegúrate de tener la clave y el certificado SSH.

Apaga las cuchillas

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

Para pausar la sincronización de BareMetalHost, ejecuta el siguiente comando para todos los nodos uno por uno. Reemplaza NODE_NAME por los nombres de los nodos que obtuviste 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 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 se indica 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 del 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 la 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 con el clúster de OTS usando 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 (VMs). 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 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, anota los valores de 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 en 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 verse como este 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 verse como este 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 etcd-leader y etcd-follower de 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 verse así:

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

Cierra 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 para NODE_NAME a partir de los valores de la columna BMC-IP:
```
kubectl get servers -A
```
4. Visita la dirección BMC-IP que obtuviste en el paso anterior y accede con el nombre de usuario y la contraseña que obtuviste.
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 hayan apagado ambos nodos seguidores de etcd, repite el paso 7 para el nodo líder de etcd.

Cómo quitar las llaves YubiKey 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 llaves tú mismo.

Carga y conecta el dispositivo

Si se interrumpió la alimentación de forma inesperada, por ejemplo, con un apagado forzado, el dispositivo se volverá a encender automáticamente. En este caso, debes comenzar desde el paso 7 y omitir los pasos del 1 al 6. Después de una pérdida de energía inesperada, es posible que pierdas datos, incluso después de reiniciar el dispositivo.

Plan de acción

Inserta las Yubikeys en cada nodo.
Enchufa la máquina del dispositivo aislado de GDC y presiona el botón de encendido del 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 de 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.
Desacordona cada nodo para habilitar la programación:
```
kubectl uncordon `NODE_NAME`
```

Reanuda la sincronización de los hosts de equipo físico para cada nodo:

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

Verifica 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 reconciliación. El resultado podría verse así:

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 que realices 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 verse así:

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 con el nodo NotReady. Las direcciones IP de destino de SSH son los valores de 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 la estación de trabajo del cliente conectadas 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