Renovar manualmente os certificados de cluster expirados

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

Esta página é destinada a administradores, arquitetos e operadores que gerenciam o ciclo de vida da infraestrutura tecnológica e responder a alertas e páginas quando os objetivos de nível de serviço (SLOs) não são atendidos ou os aplicativos falham. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE.

Por padrão, os certificados TLS, incluindo os do etcd, têm um período de validade de um ano. O Google Distributed Cloud renova esses certificados durante upgrades de cluster e quando você Alterna autoridades de certificação. Esses certificados não são atualizados periodicamente por conta própria. Recomendamos que você faça upgrade dos clusters regularmente para garantir a segurança e o suporte deles, além de evitar que os certificados TLS expirem.

Erros causados pela expiração do certificado

Se os certificados TLS no cluster expirarem, os controladores principais não poderão estabelecer conexões TLS com o servidor da API Kubernetes. Essa falta de conectividade causa os seguintes erros:

• Não foi possível estabelecer uma conexão com o servidor: x509

  Quando você usa kubectl para receber os nós do cluster, a resposta inclui um que os certificados expiraram, como no exemplo a seguir saída:

  Unable to connect to the server: x509: certificate has expired or is not yet valid
  

• Não foi possível conectar: x509 ou conexão recusada

  Os certificados expirados bloqueiam o acesso ao cluster do etcd porque os pares não podem se comunicar entre si. Os registros etcd podem conter entradas de erro, como o seguinte:

  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 "")
  

Verificar os prazos de validade do certificado

Para verificar os prazos de validade dos certificados, siga as etapas abaixo em cada nó do plano de controle:

1. Faça login em uma das máquinas de nó do plano de controle e execute o seguinte comando:

   sudo kubeadm certs check-expiration
   

   A resposta ao comando lista os certificados criados por kubeadm para o os componentes do plano de controle e a validade deles, conforme mostrado no exemplo a seguir: saída:

   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
   

2. Execute o seguinte comando para verificar os prazos de validade dos certificados kubelet:

   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 é semelhante à seguinte saída, por exemplo:

   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 controle tiverem sido inicializados ao mesmo tempo, os prazos de validade do certificado serão de minutos em minutos. Essa relação de tempo se aplica a todos os nós do plano de controle. É possível verificar os tempos de expiração executando os comandos anteriores em cada nó do plano de controle.

3. Execute o seguinte comando na estação de trabalho do administrador para verificar o prazo de validade do certificado do cliente no arquivo kubeconfig do cluster:

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

   A resposta é parecida com esta:

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

4. Execute o seguinte comando para procurar a validade do certificado 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:

   • ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.

   • CLUSTER_NAME: o nome do cluster para o qual você está renovando os certificados.

   • CLUSTER_NAMESPACE: o namespace do cluster para o qual você está renovando os certificados.

   A resposta é parecida com esta:

   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 arquivo kubeconfig da estação de trabalho do administrador são os mesmos. Portanto, a saída desse comando e do comando da etapa anterior precisam ser iguais.

Renovar certificados manualmente

Para renovar manualmente os certificados TLS de um cluster, siga as instruções nas seções a seguir.

Importante: as instruções a seguir renovam certificados expirados e não expirados. Em ambos os casos, o período de expiração dos certificados TLS renovados no cluster é redefinido para um ano. Recomendamos que você renove os certificados do cluster antes da expiração deles para evitar uma inatividade significativa do cluster. O método recomendado para renovar os certificados antes da expiração é fazer upgrade dos clusters regularmente.

Renovar certificados em cada nó do plano de controle

Siga estas etapas em cada nó do plano de controle do cluster afetado:

Importante: renove os certificados em apenas um nó por vez. Realize todas as etapas antes de começar em um novo nó do plano de controle.

1. Faça backup da pasta /etc/kubernetes.

2. Execute o seguinte comando kubeadm para renovar todos os certificados. O comando renova os certificados usando as autoridades certificadoras (CAs, na sigla em inglês) atuais na máquina.

   sudo kubeadm certs renew all
   

   A resposta ao comando será 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
   

3. Verifique se os certificados têm um novo expiry time executando o seguinte comando:

   sudo kubeadm certs check-expiration
   

4. Nem todos os componentes do plano de controle são compatíveis com o recarregamento dinâmico de certificados. Para escolher os certificados renovados, siga as etapas abaixo para reiniciar o seguinte: contêineres: kube-apiserver, etcd, kube-scheduler e kube-controller-manager.

   Repita as seguintes etapas para cada um dos quatro contêineres:

   Observação: se os certificados expirarem, recomendamos que você execute a etapa a seguir para os contêineres kube-apiserver e etcd primeiro. Em seguida, interrompa os contêineres kube-scheduler e kube-controller-manager.

   1. Encontre o ID de cada contêiner:

      sudo crictl ps | grep CONTAINER_NAME
      

      Substitua CONTAINER_NAME pelo nome dos seguintes contêineres: kube-apiserver, etcd (não etcd-defrag), kube-scheduler ou kube-controller-manager.

      A resposta é semelhante ao seguinte:

      c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...
      

      O ID do contêiner é o valor na primeira coluna.

   2. Interrompa cada contêiner:

      sudo crictl stop CONTAINER_ID
      

      Substitua CONTAINER_ID pelo ID do contêiner da etapa anterior.

      Quando o contêiner interrompido é encerrado, o kubelet cria um novo no lugar e exclui o interrompido. Se você encontrar um erro, como context deadline exceeded (código de erro DeadlineExceeded), execute novamente o comando.

Verificar se a conectividade foi restaurada

Os certificados do kubeadm agora precisam ser renovados em todos os nós do plano de controle. Se você estiver renovando os certificados expirados, siga a etapa a seguir:

• Para verificar a conexão com o servidor da API Kubernetes, execute o seguinte comando kubectl em qualquer nó do plano de controle:

  kubectl get nodes --kubeconfig /etc/kubernetes/admin.conf
  

A resposta retornará a lista de nós do cluster. Se os certificados forem renovados corretamente, nenhum erro de TLS ou certificado será retornado.

Atualizar o secret kubeconfig no cluster

As etapas a seguir usam os certificados renovados do arquivo admin.conf para atualizar o secret kubeconfig do cluster. No entanto, o conteúdo do arquivo admin.conf atualizado não pode ser usado como está. Primeiro, faça uma cópia do arquivo admin.conf com algumas edições necessárias.

Para atualizar o novo kubeconfig para a chave secreta, siga estas etapas em um nó do plano de controle:

1. Use sed para substituir kubernetes no arquivo admin.conf pelo nome do cluster e grave as mudanças em um novo arquivo, kubeconfig_secret.conf:

   sed "s/kubernetes/CLUSTER_NAME/g" \
       /etc/kubernetes/admin.conf > /etc/kubernetes/kubeconfig_secret.conf
   

2. Use diff para confirmar se o arquivo kubeconfig_secret.conf foi atualizado:

   diff /etc/kubernetes/admin.conf /etc/kubernetes/kubeconfig_secret.conf
   

   A resposta mostra todos os lugares em que o arquivo kubeconfig_secret.conf é diferente do arquivo admin.conf atualizado. Por exemplo, se você realizou a etapa anterior para um cluster chamado demo-cluster, a saída seria semelhante a esta:

   6c6
   <   name: kubernetes
   ---
   >   name: demo-cluster
   9,12c9,12
   <     cluster: kubernetes
   <     user: kubernetes-admin
   <   name: kubernetes-admin@kubernetes
   < current-context: kubernetes-admin@kubernetes
   ---
   >     cluster: demo-cluster
   >     user: demo-cluster-admin
   >   name: demo-cluster-admin@demo-cluster
   > current-context: demo-cluster-admin@demo-cluster
   16c16
   < - name: kubernetes-admin
   ---
   > - name: demo-cluster-admin
   

3. Execute os comandos a seguir para atualizar o secret kubeconfig no cluster:

   CLUSTER_KUBECONFIG_BASE64=$(base64 /etc/kubernetes/kubeconfig_secret.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 -
   

Substituir o arquivo kubeconfig do cluster

Para substituir o arquivo kubeconfig do cluster por um que tenha os certificados renovados, siga estas etapas:

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

   Conforme observado nas seções anteriores, o arquivo admin.conf está localizado no diretório etc/kubernetes nos nós do plano de controle do cluster.

2. Para criar o novo arquivo 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:

   • ADMIN_CONF_PATH é o caminho do arquivo admin.conf copiado para a estação de trabalho do administrador de um nó do plano de controle.

   • CLUSTER_NAME: o nome do cluster para o qual você está renovando os certificados.

   • CLUSTER_NAMESPACE: o namespace do cluster para o qual você está renovando os certificados.

   O arquivo new_kubeconfig.conf contém os dados atualizados do certificado.

3. Verifique se o novo kubeconfig funciona executando qualquer comando kubectl usando as novas credenciais:

   kubectl get nodes --kubeconfig new_kubeconfig.conf
   

4. Substitua o conteúdo do antigo arquivo kubeconfig salvo no diretório do cluster na estação de trabalho de administrador pelo conteúdo do novo arquivo kubeconfig new-kubeconfig.conf.

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

Verifique os certificados do kubelet e reinicie o etcd-defrag

Para concluir manualmente o processo de renovação dos certificados do cluster, execute as etapas a seguir em cada nó do plano de controle:

1. Faça login no nó do plano de controle e verifique o cliente do kubelet e o expiry time do certificado. Para isso, execute os seguintes comandos:

   Os certificados do kubelet são alternados automaticamente, desde que o plano de controle esteja acessível. O período de renovação automática dos certificados do kubelet é menor que o período de validade dos certificados do componente do plano de controle. Portanto, é 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
   

   A saída de qualquer um dos comandos será parecida com esta:

   Validity
       Not Before: Nov 28 18:04:57 2022 GMT
       Not After : Nov 28 19:04:57 2023 GMT
   

2. Use o seguinte comando para reiniciar o contêiner etcd-defrag:

   O contêiner etcd-defrag usa o certificado do cliente apiserver-etcd para se comunicar com o etcd e precisa ser reiniciado a fim de coletar os certificados atualizados.

   kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
   

Depois de concluir essas etapas manuais para renovar os certificados de cluster, verifique se: se todos os pods estão funcionando corretamente e que nenhum erro de TLS seja relatado para controle do plano de controle.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care. Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo:

• Requisitos para abrir um caso de suporte.
• Ferramentas para ajudar na solução de problemas, como configuração do ambiente, registros e métricas.
• Componentes compatíveis.