Apagar y encender el dispositivo

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

Puedes usar el dispositivo air-gapped de GDC en ubicaciones operativas transitorias, donde sea necesario apagar el dispositivo para transportarlo de una ubicación a otra. También es posible que tengas que restaurar el dispositivo tras un fallo de alimentación, ya que los generadores pueden alimentarlo en entornos difíciles.

Antes de empezar

Detén todas las cargas de trabajo antes de continuar. Google no puede garantizar lo que ocurrirá si las cargas de trabajo están activas durante un cierre.

Requisitos previos

  1. Puedes ejecutar este runbook en un portátil o una estación de trabajo conectados a la red del dispositivo aislado de Google Distributed Cloud (GDC). También puedes conectar un portátil o una estación de trabajo para cambiar siguiendo las instrucciones de Conectar el dispositivo.
  2. Asegúrate de que tienes acceso al archivo kubeconfig del clúster root-admin.
  3. Define la variable de entorno KUBECONFIG correcta ejecutando export KUBECONFIG=PATH_TO_KUBECONFIG.
  4. Asegúrate de que tienes la clave y el certificado SSH.

Cerrar las cuchillas

  1. Obtén información sobre los nodos ejecutando kubectl get nodes -A -o wide.

  2. Para pausar la sincronización de BareMetalHost, ejecuta el siguiente comando para todos los nodos uno por uno.Sustituye NODE_NAME por los nombres de los nodos obtenidos en el paso 1:

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

    La salida podría tener este aspecto:

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

  3. Aísla todos los nodos uno a uno:

    kubectl cordon NODE_NAME

    La salida podría tener este aspecto:

    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 en todos los nodos:

    1. Para encontrar las IPs de destino de 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 el líder o un seguidor de etcd, ejecuta el siguiente comando en el 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.

      La salida podría ser similar a este ejemplo del 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 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

      La salida podría ser similar a este ejemplo de 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. Drena los dos nodos seguidores de etcd. No agotes el nodo líder de etcd.

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

    La salida podría tener este aspecto:

    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. Apaga correctamente 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. Obtener la dirección BMC-IP de NODE_NAME a partir de los valores de la columna BMC-IP:

      kubectl get servers -A

    4. Visita la dirección BMC-IP que has obtenido en el paso anterior e inicia sesión introduciendo el nombre de usuario y la contraseña que has obtenido.

    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, 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 ha apagado. Esto tardará unos minutos.

  8. Una vez que se hayan apagado ambos nodos de seguidor de etcd, repite el paso 7 con el nodo líder de etcd.

Quitar las YubiKeys para el transporte

Si necesitas transportar el sistema una vez completada la instalación, quita las YubiKeys y transpórtalas por separado. Asegúrate de etiquetar las teclas tú mismo.

Encender y conectar

Si se ha producido un corte de energía inesperado, como un apagado forzado, el dispositivo se volverá a encender automáticamente. En ese caso, debes empezar por el paso 7 y saltarte los pasos del 1 al 6. Si se produce un corte de suministro eléctrico inesperado, es posible que pierdas datos, incluso después de reiniciar el dispositivo.

Plan de acción

  1. Inserta las YubiKeys en cada nodo.

  2. Conecta a la corriente el dispositivo aislado de GDC y pulsa el botón de encendido de cada nodo en cualquier orden.

  3. Una vez que los nodos estén encendidos, espera unos minutos a que se conecte el plano de control. kubectl puede conectarse al plano de control en menos de 30 minutos.

  4. Para obtener los nombres de los nodos, ejecuta kubectl get nodes -A.

  5. Desactiva la protección de cada nodo para habilitar la programación:

    kubectl uncordon `NODE_NAME`

  6. Reanuda la sincronización de los hosts de hardware desnudo de cada nodo:

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

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

    • Si todos los nodos están en estado Ready, espera dos horas a que se complete el proceso de conciliación. La salida podría tener este aspecto:

      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 hacer nada más.

    • De lo contrario, si uno o varios nodos están en el estado "NotReady", reinicia algunos servicios para que el clúster esté listo. La salida podría tener este aspecto:

      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 sigue los pasos que se indican a continuación.

  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 el portátil o la estación de trabajo del cliente conectados 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

    La salida podría tener este aspecto:

    # 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 de reiniciar, espera dos horas para que se complete la conciliación.