Esta página foi traduzida pela API Cloud Translation.

Renove manualmente os certificados de cluster expirados

Este documento descreve como renovar manualmente os certificados expirados para o seu Google Distributed Cloud. Os certificados Transport Layer Security (TLS) são usados pelos componentes do plano de controlo do Google Distributed Cloud. Quando estes certificados expiram, a sua capacidade de gerir cargas de trabalho e ciclos de vida de clusters é bloqueada até que os certificados possam ser renovados. Para mais informações sobre o impacto dos certificados expirados, consulte o artigo Expiração de certificados.

Esta página destina-se a administradores, arquitetos e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente e respondem a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são cumpridos ou as aplicações falham. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulteFunções e tarefas comuns do utilizador do GKE.

Por predefinição, os certificados TLS, incluindo os certificados etcd, têm um período de validade de 1 ano. O Google Distributed Cloud renova estes certificados durante as atualizações do cluster e quando roda as autoridades de certificação. Estes certificados não são atualizados periodicamente de forma autónoma. Recomendamos que atualize os seus clusters regularmente para os manter seguros, suportados e evitar que os certificados TLS expirem.

Erros causados pela expiração do certificado

Se os certificados TLS no seu cluster expirarem, os controladores principais não podem estabelecer ligações TLS com o servidor da API Kubernetes. Esta falta de conetividade causa os seguintes erros:

Não é possível estabelecer ligação ao servidor: x509

Quando usa kubectl para obter os nós do cluster, a resposta inclui um erro a indicar que os seus certificados expiraram, semelhante ao seguinte exemplo de resultado:
```
Unable to connect to the server: x509: certificate has expired or is not yet valid
```
Não foi possível estabelecer ligação: x509 ou ligação rejeitada

Os certificados expirados bloqueiam o acesso ao cluster etcd, uma vez que os pares não conseguem comunicar entre si. Os registos do etcd podem conter entradas de erro como as seguintes:
```
W | rafthttp: health check for peer 6221a1d241bb2d0a could not connect: x509: certificate
has expired or is not yet valid
I | embed: rejected connection from "10.200.0.4:46108" (error "remote error: tls: bad
certificate", ServerName "")
```

Verifique as horas de validade dos certificados

Para verificar os prazos de validade dos certificados, efetue os seguintes passos em cada nó do plano de controlo:

Inicie sessão numa das máquinas de nós do plano de controlo e execute o seguinte comando:

sudo kubeadm certs check-expiration

A saída do comando apresenta os certificados criados pelo kubeadm para os componentes do plano de controlo e a respetiva data de validade, conforme mostrado na seguinte saída de exemplo:

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Nov 28, 2021 19:09 UTC   53m                                     no
apiserver                  Nov 28, 2021 19:09 UTC   53m             ca                      no
apiserver-etcd-client      Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
apiserver-kubelet-client   Nov 28, 2021 19:09 UTC   53m             ca                      no
controller-manager.conf    Nov 28, 2021 19:09 UTC   53m                                     no
etcd-healthcheck-client    Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
etcd-peer                  Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
etcd-server                Nov 28, 2021 19:09 UTC   53m             etcd-ca                 no
front-proxy-client         Nov 28, 2021 19:09 UTC   53m             front-proxy-ca          no
scheduler.conf             Nov 28, 2021 19:09 UTC   53m                                     no

CERTIFICATE AUTHORITY   EXPIRES                  RESIDUAL TIME   EXTERNALLY MANAGED
ca                      Nov 26, 2031 18:06 UTC   9y              no
etcd-ca                 Nov 26, 2031 18:06 UTC   9y              no
front-proxy-ca          Nov 26, 2031 18:06 UTC   9y              no

Execute o seguinte comando para verificar os prazos de validade dos kubelet certificados:
```
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
```
A resposta para cada comando tem o seguinte aspeto:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
Se todos os nós do plano de controlo tiverem sido iniciados ao mesmo tempo, os prazos de validade dos certificados estão a poucos minutos uns dos outros. Esta relação de tempo aplica-se a todos os nós do plano de controlo. Pode verificar os prazos de validade executando os comandos anteriores em cada nó do plano de controlo.

Execute o seguinte comando na estação de trabalho do administrador para verificar a hora de expiração do certificado do cliente no ficheiro kubeconfig do cluster:

grep 'client-certificate-data' KUBECONFIG_PATH | \
    awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2

A resposta tem o seguinte aspeto:

Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT

Execute o seguinte comando para procurar a data de validade do certificado para o kubeconfig do cluster no cluster de administrador:
```
kubectl get secret/CLUSTER_NAME-kubeconfig \
    -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG \
    -o jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | \
    awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
```
Substitua o seguinte:
- ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
- CLUSTER_NAME: o nome do cluster para o qual está a renovar os certificados.
- CLUSTER_NAMESPACE: o espaço de nomes do cluster para o qual está a renovar os certificados.
A resposta tem o seguinte aspeto:
```
Validity
    Not Before: Sep 17 22:27:53 2021 GMT
    Not After : Sep 17 22:33:16 2022 GMT
```
O certificado kubeconfig no cluster de administrador e o certificado no ficheiro kubeconfig na estação de trabalho do administrador são iguais. Por conseguinte, o resultado deste comando e do comando do passo anterior têm de corresponder.

Renove certificados manualmente

Para renovar manualmente os certificados TLS de um cluster, siga as instruções nas secções seguintes.

Renove os certificados em cada nó do plano de controlo

Execute os seguintes passos em cada nó do plano de controlo do cluster afetado:

Faça uma cópia de segurança da pasta /etc/kubernetes.

Execute o seguinte comando kubeadm para renovar todos os certificados. O comando renova os certificados através das autoridades de certificação (ACs) existentes na máquina:

sudo kubeadm certs renew all

O resultado do comando é semelhante ao seguinte exemplo:

certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
certificate for serving the Kubernetes API renewed
certificate the apiserver uses to access etcd renewed
certificate for the API server to connect to kubelet renewed
certificate embedded in the kubeconfig file for the controller manager to use renewed
certificate for liveness probes to healthcheck etcd renewed
certificate for etcd nodes to communicate with each other renewed
certificate for serving etcd renewed
certificate for the front proxy client renewed
certificate embedded in the kubeconfig file for the scheduler manager to use renewed

Verifique se os certificados têm uma nova data de validade executando o seguinte comando:
```
sudo kubeadm certs check-expiration
```
Nem todos os componentes do plano de controlo suportam o recarregamento dinâmico de certificados. Para recolher os certificados renovados, os seguintes passos reiniciam os seguintes contentores: kube-apiserver, etcd, kube-scheduler e kube-controller-manager.

Repita os seguintes passos para cada um dos quatro contentores:

Nota: se os seus certificados tiverem expirado, recomendamos que execute o passo seguinte para os contentores kube-apiserver e etcd primeiro. Em seguida, pare os contentores kube-scheduler e kube-controller-manager.
1. Encontre o ID do contentor de cada contentor:
```
sudo crictl ps | grep CONTAINER_NAME
```
  Substitua CONTAINER_NAME pelo nome dos seguintes contentores: kube-apiserver, etcd (não etcd-defrag), kube-scheduler ou kube-controller-manager.
  
  A resposta é semelhante ao seguinte resultado:
```
c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
```
  O ID do contentor é o valor na primeira coluna.
2. Parar cada contentor:
```
sudo crictl stop CONTAINER_ID
```
  Substitua CONTAINER_ID pelo ID do contentor do passo anterior.
  
  Quando o contentor parado sai, o kubelet cria um novo contentor no respetivo lugar e elimina o parado. Se encontrar um erro, como context deadline exceeded (código de erro DeadlineExceeded), volte a executar o comando.

Verifique se a conetividade foi restaurada

Os certificados do kubeadm devem ser renovados em todos os nós do plano de controlo. Se estiver a renovar certificados expirados, siga este passo:

Para validar a ligação ao servidor da API Kubernetes, execute o seguinte comando kubectl em qualquer nó do plano de controlo:
```
kubectl get nodes --kubeconfig /etc/kubernetes/admin.conf
```

A resposta deve devolver a lista de nós do cluster. Se os seus certificados forem renovados corretamente, não são devolvidos erros de TLS nem de certificado.

Atualize o segredo kubeconfig no cluster

Atualize o segredo kubeconfig a partir do conteúdo do ficheiro admin.conf.

Para atualizar o novo kubeconfig para o segredo, execute os seguintes comandos no nó do plano de controlo:

CLUSTER_KUBECONFIG_BASE64=$(base64 /etc/kubernetes/admin.conf -w 0)

kubectl get secret/CLUSTER_NAME-kubeconfig \
    -n CLUSTER_NAMESPACE \
    --kubeconfig /etc/kubernetes/admin.conf -o json | jq \
    --arg conf "${CLUSTER_KUBECONFIG_BASE64}" '.data."value" |= $conf' | kubectl apply \
    --kubeconfig /etc/kubernetes/admin.conf -f -

Substitua o ficheiro kubeconfig do cluster

Para substituir o ficheiro kubeconfig do cluster por um que tenha os certificados renovados, siga estes passos:

Copie o ficheiro admin.conf de um dos nós do plano de controlo do cluster para a estação de trabalho do administrador.

Conforme indicado nas secções anteriores, o ficheiro admin.conf encontra-se no diretório etc/kubernetes nos nós do plano de controlo do cluster.
Para criar o novo ficheiro kubeconfig, execute o seguinte comando kubectl na estação de trabalho do administrador:
```
kubectl --kubeconfig ADMIN_CONF_PATH get secret/CLUSTER_NAME-kubeconfig  \
    -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}'  | \
    base64 --decode > new_kubeconfig.conf
```
Substitua o seguinte:
- ADMIN_CONF_PATH: o caminho do ficheiro admin.conf que foi copiado para a estação de trabalho do administrador a partir de um nó do plano de controlo.
- CLUSTER_NAME: o nome do cluster para o qual está a renovar os certificados.
- CLUSTER_NAMESPACE: o espaço de nomes do cluster para o qual está a renovar os certificados.
O ficheiro new_kubeconfig.conf contém os dados do certificado atualizados.
Verifique se o novo kubeconfig funciona executando qualquer comando kubectl com as novas credenciais:
```
kubectl get nodes --kubeconfig new_kubeconfig.conf
```
Substitua o conteúdo do ficheiro kubeconfig antigo guardado no diretório do cluster na estação de trabalho do administrador pelo conteúdo do novo ficheiro kubeconfig new-kubeconfig.conf.

Por predefinição, o caminho para o ficheiro de configuração do cluster é bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.

Valide os certificados do kubelet e reinicie o `etcd-defrag`

Para concluir o processo de renovação manual dos certificados do cluster, execute os seguintes passos para cada nó do plano de controlo:

Inicie sessão no nó do plano de controlo e verifique o cliente kubelet e a hora de validade do certificado de serviço executando os seguintes comandos:

Os certificados do Kubelet são rodados automaticamente, desde que o plano de controlo seja acessível. O período de renovação automática dos certificados kubelet é inferior ao período de validade dos certificados dos componentes do plano de controlo. Por conseguinte, é provável que os certificados do kubelet tenham sido renovados anteriormente:
```
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
```
O resultado de qualquer um dos comandos tem um aspeto semelhante ao seguinte exemplo:
```
Validity
    Not Before: Nov 28 18:04:57 2022 GMT
    Not After : Nov 28 19:04:57 2023 GMT
```
Use o seguinte comando para reiniciar o contentor etcd-defrag:

O contentor etcd-defrag usa o certificado de cliente apiserver-etcd para comunicar com o etcd e tem de ser reiniciado para receber os certificados atualizados.
```
kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
```

Depois de concluir estes passos manuais para renovar os certificados de cluster, verifique se todos os pods estão a ser executados corretamente e se não são comunicados erros de TLS para contentores do plano de controlo.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

Requisitos para abrir um registo de apoio técnico.
Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
Componentes suportados.