Desligue e ligue o dispositivo

Esta página descreve como desligar e ligar o dispositivo isolado do Google Distributed Cloud (GDC). Por exemplo, para mover o dispositivo para um novo local.

Você pode usar o appliance isolado do GDC em locais operacionais temporários, em que é necessário desligar o dispositivo para transporte e movimentação entre locais. Talvez também seja necessário restaurar o dispositivo de uma falha de energia, já que geradores podem alimentá-lo em ambientes hostis.

Antes de começar

Interrompa todas as cargas de trabalho antes de continuar. O Google não garante o que vai acontecer se as cargas de trabalho estiverem ativas durante um desligamento.

Pré-requisitos

  1. É possível executar esse runbook em um laptop ou estação de trabalho conectado à rede do appliance isolado do Google Distributed Cloud (GDC). Como alternativa, conecte um laptop ou uma estação de trabalho ao interruptor seguindo Conectar o dispositivo.
  2. Verifique se você tem acesso ao kubeconfig do cluster root-admin.
  3. Defina a variável de ambiente KUBECONFIG correta executando export KUBECONFIG=PATH_TO_KUBECONFIG.
  4. Verifique se você tem a chave SSH e o certificado.

Desligue as lâminas

  1. Para conferir informações sobre os nós, execute kubectl get nodes -A -o wide.

  2. Pause a sincronização do BareMetalHost executando o seguinte comando para todos os nós um por um.Substitua NODE_NAME pelos nomes dos nós obtidos na etapa 1:

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

    A saída pode ser semelhante a este exemplo:

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

  3. Restrinja todos os nós um por um:

    kubectl cordon NODE_NAME

    A saída pode ser semelhante a este exemplo:

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

  4. Para determinar o nó líder e os nós seguidores do etcd, execute esta etapa em todos os nós:

    1. Encontre os IPs de destino para SSH observando os valores na coluna INTERNAL-IP da saída de kubectl get nodes -A -o wide. Estabeleça uma conexão SSH:

      ssh root@INTERNAL-IP

    2. Para determinar se o nó atual é líder ou seguidor do etcd, execute o seguinte comando no 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

      Preste atenção ao campo IS LEADER.

      A saída pode ser semelhante a este exemplo para o nó líder do 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 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

      A saída pode ser semelhante a este exemplo para os dois nós seguidores do 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 |        |
+----------------+------------------+--------------+---------+-----------+------------+-----------+------------+--------------------+--------+

      Anote o status de líder e seguidor do etcd dos nós.

  5. Drene os dois nós seguidores do etcd. Não drene o nó líder do etcd.

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

    A saída pode ser semelhante a esta:

    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. Desligue normalmente os dois nós seguidores do etcd. Siga a próxima etapa uma por uma para os dois nós.

  7. Desative o NODE_NAME usando o iLO:

    1. Recupere o nome de usuário do iLO:

      kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.username}" | base64 --decode

    2. Recupere a senha do iLO:

      kubectl get secret bmc-credentials-NODE_NAME -n gpc-system -o jsonpath="{.data.password}" | base64 --decode

    3. Recupere o endereço BMC-IP de NODE_NAME com base nos valores da coluna BMC-IP:

      kubectl get servers -A

    4. Acesse o endereço BMC-IP obtido na etapa anterior e faça login inserindo o nome de usuário e a senha.

    5. Passe o cursor sobre o primeiro botão na linha de cima. Ela vai mostrar Power: ON. Clique nele. Um menu suspenso vai aparecer. Clique no primeiro item, chamado Momentary Press. A cor do botão vai mudar de verde para laranja, indicando que o nó está sendo desligado. Aguarde até que o botão mude de cor para amarelo, indicando que a máquina foi desligada. Isso leva alguns minutos.

  8. Depois que os dois nós seguidores do etcd forem desligados, repita a etapa 7 para o nó líder do etcd.

Remover YubiKeys para transporte

Se você precisar transportar o sistema após a conclusão da instalação, remova os YubiKeys e transporte-os separadamente. Marque as chaves por conta própria.

Ligar e conectar

Se a energia foi perdida inesperadamente, como em um desligamento forçado, o dispositivo será reiniciado automaticamente. Nesse caso, comece pela etapa 7, pulando as etapas de 1 a 6. Você pode ter alguma perda de dados que não persiste após uma queda de energia inesperada.

Plano de ação

  1. Insira os yubikeys em cada nó.

  2. Conecte a máquina do appliance isolado por air-gap do GDC à energia e pressione o botão liga/desliga em cada nó em qualquer ordem.

  3. Depois que os nós forem ligados, aguarde alguns minutos para que o plano de controle se conecte. O kubectl pode se conectar ao plano de controle em menos de 30 minutos.

  4. Para conferir os nomes dos nós, execute kubectl get nodes -A.

  5. Remova a restrição de cada nó para ativar o agendamento:

    kubectl uncordon `NODE_NAME`

  6. Retome a sincronização dos hosts bare metal para cada nó:

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

  7. Verifique o status dos nós usando kubectl get nodes -A.

    • Se todos os nós estiverem no estado Ready, aguarde duas horas para que o processo de reconciliação seja concluído. A saída pode ser semelhante a esta:

      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

      Nesse caso, nenhuma outra ação é necessária.

    • Caso contrário, se um ou mais nós estiverem no estado "NotReady", reinicie alguns serviços para preparar o cluster. A saída pode ser semelhante a esta:

      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

      Nesse caso, anote o nome do nó que não está pronto e siga para as próximas etapas.

  8. Estabeleça uma conexão SSH com o nó NotReady. Os endereços IP de destino do SSH são valores na coluna INTERNAL-IP da saída de kubectl get nodes -A -o wide:

    ssh root@INTERNAL-IP

  9. Reinicie os serviços containerd e kubelet no nó NotReady. Os comandos a seguir devem ser executados em nós, não no laptop ou na estação de trabalho do cliente conectados ao appliance isolado do Google Distributed Cloud (GDC):

    systemctl stop containerd
systemctl daemon-reload
systemctl restart containerd
systemctl stop kubelet
systemctl start kubelet

  10. Para verificar o status dos serviços containerd e kubelet, execute os seguintes comandos no nó NotReady:

    systemctl status kubelet
systemctl status containerd

    A saída pode ser semelhante a esta:

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

    Se os serviços containerd e kubelet estiverem funcionando bem após a reinicialização, aguarde duas horas para que a reconciliação seja concluída.