Résoudre les problèmes liés aux CRD avec un groupe d'autorités de certification non valide

Les définitions de ressources personnalisées (CRD) sont des outils puissants pour étendre les fonctionnalités de Kubernetes. Toutefois, si une CRD contient un groupe d'autorités de certification (CA) non valide ou mal formé dans sa configuration de webhook de conversion spec.conversion.webhook.clientConfig.caBundle, cela peut perturber les opérations du cluster. Ce problème peut se manifester par des erreurs lors de la création, de la mise à jour ou de la suppression de ressources, ce qui affecte la stabilité et les performances de votre cluster.

Pour éviter ce problème, Google Kubernetes Engine (GKE) détecte automatiquement les CRD avec des groupes d'autorités de certification non valides et génère une recommandation. Consultez ce document pour trouver la recommandation, identifier vos CRD mal configurées et les mettre à jour.

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme ainsi que pour les autres utilisateurs qui gèrent les CRD et les ressources personnalisées dans GKE.

Identifier les clusters concernés

Pour obtenir des insights identifiant les clusters affectés par des CRD avec des groupes d'autorités de certification non valides, suivez les instructions pour afficher les insights et les recommandations pour le sous-type K8S_CRD_WITH_INVALID_CA_BUNDLE. Vous pouvez obtenir des insights de différentes manières :

  • Utilisez la Google Cloud console.
  • Utilisez la Google Cloud CLI ou l'API Recommender pour filtrer avec le sous-type K8S_CRD_WITH_INVALID_CA_BUNDLE.

Une fois que vous avez identifié les CRD à l'aide des insights, suivez les instructions pour résoudre les problèmes liés au groupe d'autorités de certification mal configuré.

Quand GKE détecte-t-il des CRD mal configurées ?

GKE génère un insight et une recommandation avec le sous-type K8S_CRD_WITH_INVALID_CA_BUNDLE si le cluster GKE comporte une ou plusieurs CRD signalant un caBundle mal configuré pour la configuration du client webhook dans spec.conversion.webhook.clientConfig.

Suivez les instructions pour vérifier les CRD avec un groupe d'autorités de certification mal configuré.

Résoudre les problèmes liés aux CRD détectées

Les sections suivantes contiennent des instructions pour vous aider à résoudre les problèmes liés aux CRD que GKE a détectées comme potentiellement mal configurées.

Une fois les instructions et les CRD correctement configurées, la recommandation est résolue dans les 24 heures et n'apparaît plus dans la console. Si moins de 24 heures se sont écoulées depuis que vous avez mis en œuvre les conseils de la recommandation, vous pouvez marquer la recommandation comme résolue. Si vous ne souhaitez pas mettre en œuvre la recommandation, vous pouvez ignorer it.

Identifier les CRD concernées dans un cluster

  1. Affichez les insights et les recommandations pour le sous-type K8S_CRD_WITH_INVALID_CA_BUNDLE, en choisissant un insight à la fois pour résoudre les problèmes. GKE génère un insight par cluster comportant une CRD défectueuse.

  2. Exécutez la commande suivante pour décrire le service afin de trouver les CRD avec des groupes d'autorités de certification potentiellement problématiques :

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

    Le résultat comprend les éléments suivants :

    • Nom : nom de la CRD.
    • CaBundle : groupe d'autorités de certification associé au webhook de conversion de la CRD, le cas échéant. Examinez le résultat. Si la colonne caBundle est vide pour une CRD dont vous savez qu'elle utilise un webhook de conversion, cela signale un problème potentiel avec le caBundle.

Recréer la CRD

Pour résoudre cette erreur, recréez la CRD concernée avec un groupe d'autorités de certification valide :

  1. Sauvegardez les ressources personnalisées existantes associées à cette CRD problématique, le cas échéant. Exécutez la commande suivante pour exporter les ressources existantes :

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

  2. Supprimez la CRD existante :

      kubectl delete crd <crd-name>

  3. Assurez-vous que le champ caBundle de la CRD contient un certificat PEM encodé en base64 correctement formé. Pour ce faire, vous pouvez modifier directement la CRD ou contacter ses auteurs.

  4. Modifiez la définition YAML de la CRD en mettant à jour le champ spec.conversion.webhook.clientConfig.caBundle avec les données valides du groupe d'autorités de certification. Le résultat devrait ressembler à ceci :

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

  5. Appliquez la CRD corrigée :

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

  6. Restaurez vos ressources personnalisées :

        kubectl apply -f backup.yaml

Étape suivante