Encerre 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 uma nova localização.

Pode usar o dispositivo isolado do ar do GDC em localizações operacionais temporárias, onde é necessário desligar o dispositivo para transporte de modo a movê-lo entre localizações. Também pode ter de restaurar o dispositivo a partir de uma falha de energia, uma vez que os geradores podem alimentá-lo em ambientes difíceis.

Antes de começar

Certifique-se de que para todas as cargas de trabalho antes de continuar. A Google não pode garantir o que acontece se as cargas de trabalho estiverem ativas durante um encerramento.

Pré-requisitos

  1. Pode executar este manual de procedimentos num portátil ou numa estação de trabalho ligados à rede do dispositivo isolado do Google Distributed Cloud (GDC). Em alternativa, pode ligar um portátil ou uma estação de trabalho ao comutador seguindo as instruções em Ligue o dispositivo.
  2. Certifique-se de que tem acesso ao kubeconfig do cluster de administrador principal.
  3. Defina a variável de ambiente KUBECONFIG correta executando export KUBECONFIG=PATH_TO_KUBECONFIG.
  4. Certifique-se de que tem a chave e o certificado SSH.

Desligar as lâminas

  1. Obtenha informações dos nós executando kubectl get nodes -A -o wide.

  2. Pausa a sincronização de BareMetalHost executando o seguinte comando para todos os nós um a um.Substitua NODE_NAME pelos nomes dos nós obtidos no passo 1:

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

    O resultado pode ter o seguinte aspeto:

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

  3. Isolar todos os nós um a um:

    kubectl cordon NODE_NAME

    O resultado pode ter o seguinte aspeto:

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

  4. Para determinar o nó principal do etcd e os nós seguidores, execute este passo um a um para todos os nós:

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

      ssh root@INTERNAL-IP

    2. Para determinar se o nó atual é o líder ou o 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.

      O resultado pode ter o seguinte aspeto para o nó principal 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 ter o seguinte aspeto para os dois nós seguidor 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 estado etcd-leader e etcd-follower dos nós.

  5. Esvazie os dois nós seguidor do etcd. Não esvazie o nó principal do etcd.

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

    O resultado pode ter o seguinte aspeto:

    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. Encerre corretamente os dois nós seguidor do etcd. Siga o passo seguinte um a um para ambos os nós.

  7. Desative o NODE_NAME através do iLO:

    1. Recupere o nome de utilizador do iLO:

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

    2. Recupere a palavra-passe do iLO:

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

    3. Obter a morada BMC-IP de NODE_NAME a partir dos valores na coluna BMC-IP:

      kubectl get servers -A

    4. Aceda ao endereço BMC-IP obtido no passo anterior e inicie sessão introduzindo o nome de utilizador e a palavra-passe obtidos.

    5. Passe o cursor do rato sobre o primeiro botão na linha superior. Deve apresentar Power: ON. Clique nele. É apresentado um menu pendente. Clique no primeiro item com a etiqueta Momentary Press. A cor do botão muda de verde para laranja, o que significa que o nó está a ser encerrado. Aguarde que o botão mude de cor para amarelo, o que indica que a máquina foi desligada. Esta operação demora alguns minutos.

  8. Depois de ambos os nós etcd-follower terem sido encerrados, repita finalmente o passo 7 para o nó líder do etcd.

Remova as Yubikeys para transportes

Se precisar de transportar o sistema após a conclusão da instalação, remova os Yubikeys e transporte-os separadamente. Certifique-se de que etiqueta as chaves sozinho.

Ligue e estabeleça ligação

Se a energia foi perdida inesperadamente, como num encerramento forçado, o dispositivo é reiniciado automaticamente. Neste caso, deve começar no passo 7 e ignorar os passos 1 a 6. Após uma perda de energia inesperada, pode ocorrer uma perda de dados, mesmo depois de reiniciar.

Plano de ação

  1. Insira os YubiKeys em cada nó.

  2. Ligue a máquina de dispositivo com isolamento de ar do GDC à fonte de alimentação e prima o botão ligar/desligar em cada nó por qualquer ordem.

  3. Depois de os nós serem ligados, aguarde alguns minutos para que o plano de controlo se ligue. kubectl pode estabelecer ligação ao plano de controlo em menos de 30 minutos.

  4. Obtenha os nomes dos nós executando kubectl get nodes -A.

  5. Descordone cada nó para ativar o agendamento:

    kubectl uncordon `NODE_NAME`

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

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

  7. Verifique o estado dos nós através da app kubectl get nodes -A.

    • Se todos os nós estiverem no estado Ready, aguarde duas horas para que o processo de conciliação seja concluído. O resultado pode ter o seguinte aspeto:

      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

      Neste caso, não é necessária nenhuma ação adicional.

    • Caso contrário, se um ou mais nós estiverem no estado "NotReady" (Não pronto), reinicie alguns serviços para preparar o cluster. O resultado pode ter o seguinte aspeto:

      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

      Neste caso, anote o nome do nó que não está pronto e avance para os passos seguintes.

  8. Estabeleça uma ligação SSH ao 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 seguintes comandos devem ser executados nos nós e não no portátil ou na estação de trabalho do cliente ligados ao dispositivo 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 estado dos serviços containerd e kubelet, execute os seguintes comandos no nó NotReady:

    systemctl status kubelet
systemctl status containerd

    O resultado pode ter o seguinte aspeto:

    # 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 a funcionar corretamente após o reinício, aguarde duas horas para que a conciliação seja concluída.