Garantit la stabilité du plan de contrôle lors de l'utilisation de webhooks.

Les webhooks d'admission, ou webhooks dans Kubernetes, sont un type de contrôleur d'admission qui peuvent être utilisés dans les clusters Kubernetes pour valider ou muter des requêtes adressées au plan de contrôle avant la persistance d'une requête. Il est courant que les applications tierces utilisent des webhooks qui fonctionnent sur des ressources et des espaces de noms critiques pour le système. Des webhooks mal configurés peuvent affecter les performances et la fiabilité du plan de contrôle. Par exemple, un webhook mal configuré créé par une application tierce pourrait empêcher GKE de créer et modifier des ressources dans l'espace de noms kube-system géré, ce qui risque de dégrader les fonctionnalités du cluster.

Google Kubernetes Engine (GKE) surveille vos clusters et utilise l'outil de recommandation pour vous fournir des conseils sur la façon d'optimiser votre utilisation de la plate-forme. Pour vous assurer que votre cluster reste stable et performant, consultez les recommandations de GKE pour les scénarios suivants :

  • Webhooks qui fonctionnent, mais qui n'ont aucun point de terminaison disponible.
  • Webhooks considérés comme non sécurisés, car ils fonctionnent sur des ressources et des espaces de noms critiques pour le système.

Ces instructions vous expliquent comment vérifier vos webhooks potentiellement mal configurés et les mettre à jour si nécessaire.

Pour en savoir plus sur la gestion des insights et des recommandations fournis par les outils de recommandation, consultez la section Optimiser l'utilisation de GKE avec des insights et des recommandations.

Identifier les webhooks mal configurés qui pourraient affecter votre cluster

Pour obtenir des insights permettant d'identifier les webhooks susceptibles d'affecter les performances et la stabilité de votre cluster, suivez les instructions pour afficher des insights et des recommandations. Vous pouvez obtenir des insights de différentes manières :

  • Utilisez la console Google Cloud .
  • Utilisez la Google Cloud CLI ou l'API Recommender pour filtrer avec les sous-types K8S_ADMISSION_WEBHOOK_UNSAFE et K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Une fois que vous avez identifié les webhooks grâce aux insights, suivez les instructions pour résoudre les problèmes liés aux webhooks détectés.

Quand GKE détecte-t-il des webhooks mal configurés

GKE génère un insight et une recommandation si l'un des critères suivants est vrai pour un cluster :

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

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

Une fois les instructions et les webhooks correctement configurés, la recommandation est résolue dans les 24 heures et n'apparaît plus dans la console.

Si vous ne souhaitez pas appliquer la recommandation, vous pouvez l'ignorer.

Webhooks signalant l'absence de points de terminaison disponibles

Si un webhook indique qu'il ne dispose d'aucun point de terminaison, le service qui sauvegarde le point de terminaison du webhook possède un ou plusieurs pods qui ne sont pas en cours d'exécution. Pour rendre les points de terminaison du webhook disponibles, suivez les instructions afin de rechercher et de dépanner les pods du service qui sauvegardent le point de terminaison du webhook :

  1. Affichez les insights et les recommandations, en choisissant un insight à la fois pour résoudre les problèmes. GKE génère un insight par cluster. Cet insight liste un ou plusieurs webhooks avec un point de terminaison défaillant qui doit être examiné. Pour chacun de ces webhooks, l'insight indique également le nom du service, le point de terminaison défectueux et la date du dernier appel du point de terminaison.

  2. Recherchez les pods de diffusion pour le service associé au webhook :

    Console

    Dans le panneau latéral de l'insight, consultez le tableau des Webhooks mal configurés. Cliquez sur le nom du service.

    kubectl

    Exécutez la commande suivante pour décrire le service :

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Remplacez SERVICE_NAME et SERVICE_NAMESPACE respectivement par le nom et l'espace de noms du service.

    Si le nom du service est répertorié dans le webhook, le point de terminaison indisponible peut être dû à une incohérence entre le nom répertorié dans la configuration et le nom réel du service. Pour résoudre le problème de disponibilité du point de terminaison, mettez à jour le nom du service dans la configuration du webhook afin qu'il corresponde à l'objet de service approprié.

  3. Inspectez les pods actifs pour ce service :

    Console

    Sous Pods de diffusion dans Informations sur le service, consultez la liste des pods qui soutiennent ce service.

    kubectl

    Identifiez les pods qui ne sont pas en cours d'exécution en répertoriant le déploiement ou les pods :

    kubectl get deployment -n SERVICE_NAMESPACE

    Vous pouvez également exécuter la commande suivante :

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Pour tous les pods qui ne sont pas en cours d'exécution, inspectez les journaux pour savoir pourquoi le pod n'est pas en cours d'exécution. Pour obtenir des instructions sur les problèmes courants liés aux pods, consultez Résoudre les problèmes liés aux charges de travail déployées.

Webhooks considérés comme non sécurisés

Si un webhook intercepte des ressources dans des espaces de noms gérés par le système ou certains types de ressources, GKE considère que ce processus n'est pas sécurisé et vous recommande de mettre à jour les webhooks pour éviter leur interception.

  1. Suivez les instructions pour afficher les insights et les recommandations, en choisissant un insight à la fois pour résoudre les problèmes. GKE ne génère qu'un seul insight par cluster. Cet insight liste une ou plusieurs configurations de webhook, chacune listant un ou plusieurs webhooks. Pour chaque configuration de webhook listée, l'insight indique la raison pour laquelle la configuration a été signalée.

  2. Examinez la configuration du webhook :

    Console

    Consultez le tableau dans le panneau latéral de l'insight. Chaque ligne indique le nom de la configuration du webhook et la raison pour laquelle cette configuration a été signalée.

    Pour inspecter chaque configuration, cliquez sur son nom pour y accéder dans le tableau de bord du Navigateur d'objets GKE.

    kubectl

    Exécutez la commande kubectl suivante pour obtenir la configuration du webhook, en remplaçant CONFIGURATION_NAME par le nom de la configuration du webhook :

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Si cette commande ne renvoie rien, exécutez-la à nouveau en remplaçant validatingwebhookconfigurations par mutatingwebhookconfigurations.

    Dans la section webhooks, un ou plusieurs webhooks sont répertoriés.

  3. Modifiez la configuration en fonction de la raison pour laquelle le webhook a été signalé :

    Exclure les espaces de noms kube-system et kube-node-lease

    Un webhook est signalé si scope est défini sur *. Ou, un webhook est signalé si le champ d'application est Namespaced et que l'une des conditions suivantes est remplie :

    • La condition operator est NotIn, et values omet kube-system et kube-node-lease, comme dans l'exemple suivant :

      webhooks:
- admissionReviewVersions:
  ...
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - blue-system
  objectSelector: {}
  rules:
  - apiGroups:
    ...
    scope: '*'
  sideEffects: None
  timeoutSeconds: 3

      Assurez-vous de définir scope sur Namespaced, et non sur *, afin que le webhook ne fonctionne que dans des espaces de noms spécifiques. Assurez-vous également que si la valeur de operator est NotIn, incluez kube-system et kube-node-lease dans values (dans cet exemple, avec blue-system).

    • La condition operator est définie sur In, et values inclut kube-system et kube-node-lease, comme dans l'exemple suivant :

      namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - blue-system
      - kube-system
      - kube-node-lease

      Assurez-vous de définir scope sur Namespaced, et non sur *, afin que le webhook ne fonctionne que dans des espaces de noms spécifiques. Assurez-vous que si operator est In, n'incluez pas kube-system et kube-node-lease dans values. Dans cet exemple, seul blue-system doit se trouver dans values, car operator est In.

    Exclure les ressources correspondantes

    Un webhook est également signalé si nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests sont répertoriés sous les ressources, comme dans l'exemple suivant :

    - admissionReviewVersions:
...
  resources:
  - 'pods'
  - 'nodes'
  - 'tokenreviews'
  - 'subjectaccessreviews'
  - 'certificatesigningrequests'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

    Supprimez nodes, tokenreviews, subjectaccessreviews et certificatesigningrequests de la section des ressources. Vous pouvez conserver pods dans resources.

Webhooks qui bloquent les composants critiques du système

Les webhooks qui interceptent les requêtes de création ou de mise à jour de ClusterRoles et de ClusterRoleBindings peuvent nuire à la capacité du plan de contrôle à réconcilier ces ressources système critiques. Par exemple, lors de la mise à niveau d'un cluster, le kube-apiserver peut avoir besoin de mettre à jour ses rôles système. Si un webhook indisponible ou mal configuré bloque cette mise à jour, l'état kube-apiserver ne passera pas à "Sain", ce qui bloquera la mise à niveau du cluster.

GKE ne détecte pas si les Webhooks interceptent ClusterRoles et ClusterRoleBindings. Par conséquent, aucun insight n'est généré pour ce scénario.

L'exemple suivant montre une configuration de webhook problématique qui intercepte ClusterRoles :

-   admissionReviewVersions:
  ...
  resources:
  -   'clusterroles'
  -   'clusterrolebindings'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

Pour éviter cette situation, assurez-vous que vos webhooks n'interceptent pas les requêtes pour ClusterRoles et ClusterRoleBindings qui ont le paramètre system: prefix.

Interblocage d'admission

Lorsqu'un webhook est configuré pour échouer de manière fermée, il peut créer une situation dans laquelle le cluster ne peut pas récupérer automatiquement. Par exemple, si tous les nœuds d'un cluster sont supprimés, le webhook sera également hors service. Étant donné que l'ajout d'un nœud nécessite une validation d'admission, le webhook doit être disponible pour approuver la requête. Cela crée une dépendance circulaire qui peut empêcher le plan de contrôle du cluster de récupérer.

GKE ne détecte pas les scénarios d'impasse d'admission. Aucune information n'est donc générée pour ce scénario. Toutefois, un blocage d'admission peut se produire si les pods de webhook sont hors service. Dans ce cas, GKE détecte que le webhook ne dispose d'aucun point de terminaison disponible et génère un insight K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Pour atténuer ce problème, vous pouvez supprimer le ValidatingWebhookConfiguration afin de rompre la dépendance circulaire et permettre au cluster de récupérer.

Disponibilité du plan de contrôle du cluster

Lorsqu'un webhook est configuré pour échouer en mode fermé, la disponibilité du plan de contrôle Kubernetes dépend de la disponibilité du webhook. Pour améliorer la disponibilité du plan de contrôle, pensez à ce qui suit :

GKE ne détecte pas les problèmes de disponibilité du plan de contrôle du cluster causés par les webhooks. Par conséquent, aucun insight n'est généré pour ce scénario.

  • Limitez le champ d'application du webhook : vous pouvez exempter les ressources critiques de la validation par le webhook pour éviter que celui-ci n'interfère avec les processus sensibles. Vous pouvez exempter des espaces de noms ou des types de ressources spécifiques. Toutefois, tenez compte des dépendances non évidentes. Par exemple, un ConfigMap peut être une ressource essentielle pour l'élection du leader dans Kubernetes.

  • Renforcer le déploiement du webhook : l'exécution du webhook dans plusieurs pods peut augmenter sa résilience et son temps d'activité. Vous pouvez utiliser des sélecteurs de nœuds pour répartir les pods sur différents domaines de défaillance.

Étapes suivantes