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 opèrent sur des ressources et des espaces de noms critiques. Les 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 peut empêcher GKE de créer et de modifier des ressources dans l'espace de noms kube-system
géré, ce qui peut 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 fonctionnant, mais sans point de terminaison disponible
- Webhooks considérés comme non sécurisés, car ils opèrent sur des ressources et des espaces de noms critiques.
Ces instructions vous indiquent 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 susceptibles d'affecter votre cluster
Pour obtenir des insights identifiant 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
etK8S_ADMISSION_WEBHOOK_UNAVAILABLE
.
Une fois que vous avez identifié les webhooks via les 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 :
K8S_ADMISSION_WEBHOOK_UNAVAILABLE
: un ou plusieurs webhooks signalent qu'aucun point de terminaison n'est disponible. Suivez les instructions pour vérifier les webhooks qui signalent qu'aucun point de terminaison n'est disponible.K8S_ADMISSION_WEBHOOK_UNSAFE
: le cluster GKE possède un ou plusieurs webhooks considérés comme non sécurisés en fonction des ressources qu'ils interceptent. Suivez les instructions pour vérifier les webhooks considérés comme non sécurisés. Les webhooks suivants sont considérés comme non sécurisés :- Les webhooks interceptent des ressources, y compris les pods et les baux, dans l'espace de noms
kube-system
. - Webhooks interceptant les baux dans l'espace de noms
kube-node-lease
. - Les webhooks interceptant les ressources système à l'échelle du cluster, y compris
Nodes
,TokenReviews
,SubjectAccessReviews
, etCertificateSigningRequests
.
- Les webhooks interceptent des ressources, y compris les pods et les baux, dans l'espace de noms
Résoudre les problèmes liés aux webhooks détectés
Les sections suivantes contiennent des instructions vous permettant de résoudre les problèmes liés aux webhooks que GKE a potentiellement détectés comme 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 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 l'ignorer.
Webhooks ne présentant aucun point de terminaison disponible
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 :
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, qui répertorie un ou plusieurs webhooks avec un point de terminaison défectueux qui doit être examiné. Pour chacun de ces webhooks, l'insight indique également le nom du service, le point de terminaison interrompu et la dernière fois que le point de terminaison a été appelé.
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 corriger la 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é.
Inspectez les pods actifs pour ce service :
Console
Sous Pods de diffusion, dans la section Informations sur le service, consultez la liste des pods qui sauvegardent 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 voir si le pod ne s'exécute pas. Pour obtenir des instructions sur les problèmes courants liés aux pods, consultez la page 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.
- 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, qui répertorie une ou plusieurs configurations de webhook, chacune répertoriant un ou plusieurs webhooks. Pour chaque configuration de webhook répertoriée, l'insight indique la raison pour laquelle la configuration a été signalée.
Examinez la configuration du webhook :
Console
Dans le panneau latéral de l'insight, consultez le tableau. Sur chaque ligne, le nom de la configuration de webhook et la raison pour laquelle cette configuration a été signalée.
Pour inspecter chaque configuration, cliquez sur le nom pour accéder à cette configuration 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 aucun résultat, exécutez-la à nouveau en remplaçant
validatingwebhookconfigurations
parmutatingwebhookconfigurations
.Dans la section
webhooks
, un ou plusieurs webhooks sont répertoriés.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 estNamespaced
et que l'une des conditions suivantes est remplie :La condition
operator
estNotIn
, etvalues
ometkube-system
etkube-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
surNamespaced
, et non sur*
, afin que le webhook ne fonctionne que dans des espaces de noms spécifiques. Assurez-vous également que si la valeur deoperator
estNotIn
, incluezkube-system
etkube-node-lease
dansvalues
(dans cet exemple, avecblue-system
).La condition
operator
est définie surIn
, etvalues
inclutkube-system
etkube-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
surNamespaced
, et non sur*
, afin que le webhook ne fonctionne que dans des espaces de noms spécifiques. Assurez-vous que sioperator
estIn
, n'incluez paskube-system
etkube-node-lease
dansvalues
. Dans cet exemple, seulblue-system
doit se trouver dansvalues
, caroperator
estIn
.
Exclure les ressources correspondantes
Un webhook est également signalé si
nodes
,tokenreviews
,subjectaccessreviews
oucertificatesigningrequests
sont répertoriés sous les ressources, comme dans l'exemple suivant :- admissionReviewVersions: ... resources: - 'pods' - 'nodes' - 'tokenreviews' - 'subjectacessreviews' - 'certificatesigningrequests' scope: '*' sideEffects: None timeoutSeconds: 3
Supprimez
nodes
,tokenreviews
,subjectaccessreviews
etcertificatesigningrequests
de la section des ressources. Vous pouvez conserverpods
dansresources
.
Étapes suivantes
- Optimiser votre utilisation de GKE avec des insights et des recommandations.
- Résoudre les problèmes courants