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

  1. 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.
  2. Asegúrate de tener acceso al kubeconfig del clúster de administrador raíz.
  3. Ejecuta export KUBECONFIG=PATH_TO_KUBECONFIG para establecer la variable de entorno KUBECONFIG correcta.
  4. Asegúrate de tener la clave y el certificado SSH.

Cierra las cuchillas

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

  2. 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 1:

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

    El resultado podría verse como este ejemplo:

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

  3. Acordona todos los nodos uno por uno:

    kubectl cordon NODE_NAME

    El resultado podría verse como este ejemplo:

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

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

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

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

  5. Desvía los dos nodos seguidores de etcd. No desvíes el nodo principal de etcd.

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

    El resultado podría verse de la siguiente manera:

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

  6. Cierra de forma ordenada los dos nodos seguidores de etcd. Sigue el siguiente paso uno por uno para ambos nodos.

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

  8. Después de que se hayan apagado ambos nodos de seguimiento de etcd, repite el paso 7 para el nodo líder de etcd.

Cómo quitar las llaves YubiKey para transportarlas

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.

Cómo encender y conectar el dispositivo

Si se interrumpió la alimentación de forma inesperada, por ejemplo, si se apagó el dispositivo de forma abrupta, este se 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

  1. Inserta las YubiKeys en cada nodo.

  2. Enchufa la máquina de la appliance aislada de GDC y presiona el botón de encendido de cada nodo en cualquier orden.

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

  4. Ejecuta kubectl get nodes -A para obtener los nombres de los nodos.

  5. Desacordona cada nodo para habilitar la programación:

    kubectl uncordon `NODE_NAME`

  6. Reanuda la sincronización de los hosts de equipos físicos para cada nodo:

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

  7. 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 de la siguiente manera:

      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 de la siguiente manera:

      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.

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

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

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

    systemctl status kubelet
systemctl status containerd

    El resultado podría verse de la siguiente manera:

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

    Si los servicios containerd y kubelet funcionan correctamente después del reinicio, espera dos horas para que se complete la conciliación.