En esta página, se describe cómo apagar y encender el dispositivo aislado de Google Distributed Cloud (GDC). Por ejemplo, para trasladar 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 el 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 archivo kubeconfig del clúster de administrador raíz.
- Ejecuta
export KUBECONFIG=PATH_TO_KUBECONFIGpara 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 widepara 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_NAMEpor los nombres de los nodos que obtuviste en el paso anterior:kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=true" --overwriteEl resultado podría ser similar al siguiente ejemplo:
baremetalhost.metal3.io/**-**-bm01 annotated baremetalhost.metal3.io/**-**-bm02 annotated baremetalhost.metal3.io/**-**-bm03 annotatedObté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-systemEjecuta 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_PASSWORDGuarda la IP y la contraseña de administración de la OTS.
Acordona todos los nodos uno por uno:
kubectl cordon NODE_NAMEEl resultado podría ser similar al siguiente ejemplo:
node/**-**-bm01 cordoned node/**-**-bm02 cordoned node/**-**-bm03 cordonedApaga 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 (VMs) de OTS. 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 el vaciado de nodos cuando sus Pods se desconecten, 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, anota los valores de la columna
INTERNAL-IPdel resultado dekubectl get nodes -A -o wide. Establece una conexión SSH:ssh root@INTERNAL-IPPara 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 statusPresta 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.
Vacía los nodos.
Desvía los dos nodos de seguimiento de etcd. No desvíes el nodo líder de etcd
kubectl drain NODE_NAME --delete-emptydir-data --grace-period 900 --ignore-daemonsets --disable-evictionEl 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 . . .Cierra de forma ordenada los dos nodos seguidores de etcd. Sigue el siguiente paso uno por uno para ambos nodos.
Desactiva
NODE_NAMEcon iLO:Recupera el nombre de usuario de iLO:
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decodeRecupera la contraseña de iLO:
kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decodeRecupera la dirección
BMC-IPparaNODE_NAMEa partir de los valores de la columnaBMC-IP:kubectl get servers -AVisita la dirección
BMC-IPque obtuviste en el paso anterior y accede con el nombre de usuario y la contraseña que obtuviste.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 comoMomentary 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 etcd-follower, repite el paso para drenar el nodo del 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.
Enciende y conecta el dispositivo
Si se interrumpió la alimentación de forma inesperada, como en un cierre forzado, el dispositivo se volverá a encender automáticamente. En este caso, puedes omitir los pasos para encender y conectar el dispositivo, y comenzar directamente con el paso para desacordonar cada nodo. 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
**-**-bm03para iniciar el servidor mediador de OTS.Después de que el nodo
**-**-bm03esté 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 mostrarActive: active (running):sudo systemctl status scst.servicePresiona 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.
kubectlpuede conectarse al plano de control en menos de 30 minutos.Para obtener los nombres de los nodos, ejecuta
kubectl get nodes -A.Desacordona cada nodo para habilitar la programación:
kubectl uncordon NODE_NAMEReanuda la sincronización de los hosts de Bare Metal para cada nodo:
kubectl annotate bmhost -n gpc-system NODE_NAME "baremetalhost.metal3.io/paused=false" --overwriteRevierte la configuración del webhook de validación de Gatekeeper a
Failpara restablecer las políticas de seguridad del clúster:kubectl patch validatingwebhookconfiguration gatekeeper-validating-webhook-configuration -p '{"webhooks":[{"name":"validation.gatekeeper.sh","failurePolicy":"Fail"}]}'Verifica el estado de los nodos con
kubectl get nodes -A.Después de que todos los nodos sean
Ready, espera 2 horas para que la pila base termine de conciliarse antes de solucionar problemas.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.300En este caso, no es necesario que realices ninguna otra acción.
Si uno o más nodos están en el estado
NotReady, anota el nombre de cada nodo que no esté listo y completa los siguientes pasos: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.300Establece una conexión SSH al nodo
NotReady. Las direcciones IP de destino para SSH son los valores de la columnaINTERNAL-IPdel resultado dekubectl get nodes -A -o wide:ssh root@INTERNAL-IPReinicia los servicios
containerdykubeleten el nodoNotReady. Ejecuta los siguientes comandos en el nodo, no en la laptop o estación de trabajo conectada al dispositivo aislado de GDC:systemctl stop containerd systemctl daemon-reload systemctl restart containerd systemctl stop kubelet systemctl start kubeletVerifica el estado de los servicios
containerdykubeletejecutando los siguientes comandos en el nodoNotReady:systemctl status kubelet systemctl status containerdEl resultado podría ser similar al siguiente:
# 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 . . .Una vez que los servicios
containerdykubeletestén en funcionamiento y todos los nodos esténReady, espera 2 horas para que la pila base termine de conciliarse antes de solucionar problemas.