Resolver problemas de CRDs com um pacote de CA inválido

As definições de recursos personalizados (CRDs) são ferramentas poderosas para estender os recursos do Kubernetes. No entanto, se uma CRD contiver um pacote de autoridade de certificação (CA) inválido ou malformado na configuração do webhook de conversão spec.conversion.webhook.clientConfig.caBundle, isso poderá interromper as operações do cluster. Esse problema pode se manifestar como erros durante a criação, atualização ou exclusão de recursos, afetando a estabilidade e o desempenho do cluster.

Para evitar esse problema, o Google Kubernetes Engine (GKE) detecta automaticamente CRDs com pacotes de CA inválidos e gera uma recomendação. Use este documento para encontrar a recomendação, identificar os CRDs mal configurados e atualizá-los.

Essas informações são importantes para administradores e operadores de plataforma e outros usuários que gerenciam CRDs e recursos personalizados no GKE.

Identificar clusters afetados

Para receber insights que identificam clusters afetados por CRDs com pacotes de CA inválidos, siga as instruções para ver insights e recomendações do subtipo K8S_CRD_WITH_INVALID_CA_BUNDLE. É possível conseguir insights das seguintes maneiras:

  • Use o console do Google Cloud .
  • Use a Google Cloud CLI ou a API Recommender filtrando com o subtipo K8S_CRD_WITH_INVALID_CA_BUNDLE.

Depois de identificar os CRDs usando os insights, siga as instruções para resolver problemas com o pacote de CA mal configurado.

Quando o GKE detecta CRDs mal configurados

O GKE gera um insight e uma recomendação com o subtipo K8S_CRD_WITH_INVALID_CA_BUNDLE se o cluster do GKE tiver um ou mais CRDs informando um caBundle mal configurado para a configuração do cliente de webhook em spec.conversion.webhook.clientConfig.

Siga as instruções para verificar CRDs com pacote de AC mal configurado.

Resolver problemas dos CRDs detectados

As seções a seguir têm instruções para você solucionar problemas de CRDs que o GKE detectou como possivelmente configurados incorretamente.

Depois que você implementar as instruções e os CRDs forem configurados corretamente, a recomendação será resolvida em até 24 horas e não vai mais aparecer no console. Caso tenha se passado menos de 24 horas desde que você implementou a orientação da recomendação, marque-a como resolvida. Se você não quiser implementar a recomendação, dispense-a.

Identificar CRDs afetados em um cluster

  1. Acesse insights e recomendações para o subtipo K8S_CRD_WITH_INVALID_CA_BUNDLE, escolhendo um insight de cada vez para resolver problemas. O GKE gera um insight por cluster com um CRD corrompido.

  2. Execute o comando a seguir para descrever o serviço e encontrar CRDs com pacotes de CA potencialmente problemáticos:

    kubectl get crd -o custom-columns=NAME:.metadata.name,CABUNDLE:.spec.conversion.webhook.clientConfig.caBundle

    A saída inclui estes elementos:

    • Nome: o nome do CRD.
    • CaBundle: o pacote de CA associado ao webhook de conversão do CRD, se presente. Analise a saída. Se a coluna "caBundle" estiver vazia para um CRD que você sabe que usa um webhook de conversão, isso indica um possível problema com o caBundle.

Recrie a CRD

Para resolver esse erro, recrie o CRD afetado com um pacote de CA válido:

  1. Faça backup dos recursos personalizados associados a essa CRD problemática, se houver. Execute o comando a seguir para exportar os recursos atuais:

      kubectl get <crd-name> -o yaml > backup.yaml

  2. Exclua a CRD:

      kubectl delete crd <crd-name>

  3. Verifique se o campo caBundle da CRD contém um certificado PEM bem formado e codificado em base64. Para isso, edite o CRD diretamente ou entre em contato com os autores.

  4. Modifique a definição YAML da CRD, atualizando o campo spec.conversion.webhook.clientConfig.caBundle com os dados válidos do pacote de CA. O resultado será similar a este:

        spec:
      conversion:
        webhook:
          clientConfig:
            caBundle: <base64-encoded-ca-bundle>

  5. Aplique o CRD corrigido:

        kubectl apply -f <corrected-crd-file.yaml>

  6. Restaure seus recursos personalizados:

        kubectl apply -f backup.yaml

A seguir