Esta página foi traduzida pela API Cloud Translation.

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

É possível executar esse runbook em um laptop ou estação de trabalho conectado à rede do appliance isolado do Google Distributed Cloud (GDC). Você também pode conectar um laptop ou uma estação de trabalho ao switch seguindo Conectar o dispositivo.
Verifique se você tem acesso ao kubeconfig do cluster root-admin.
Defina a variável de ambiente KUBECONFIG correta executando export KUBECONFIG=PATH_TO_KUBECONFIG.
Verifique se você tem a chave SSH e o certificado.

Desligue as lâminas

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

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

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

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

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

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.

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

Desligue normalmente os dois nós seguidores do etcd. Siga a próxima etapa uma por uma para os dois nós.
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, o que significa 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.
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. Depois de uma perda de energia inesperada, você pode perder dados, mesmo após a reinicialização.

Plano de ação

Insira os yubikeys em cada nó.
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.
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.
Para conferir os nomes dos nós, execute kubectl get nodes -A.
Remova a restrição de cada nó para ativar o agendamento:
```
kubectl uncordon `NODE_NAME`
```

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

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.

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

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

systemctl status kubelet
systemctl status containerd