Los webhooks de admisión, o webhooks en Kubernetes, son un tipo decontrolador de admisión que se puede usar en clústeres de Kubernetes para validar o mutar solicitudes al plano de control antes de que se conserve una solicitud. Es común que las aplicaciones de terceros usen webhooks que operan en recursos críticos del sistema y espacios de nombres. Los webhooks configurados de forma incorrecta pueden afectar el rendimiento y la confiabilidad del plano de control. Por ejemplo, un webhook configurado de forma incorrecta mediante una aplicación de terceros podría evitar que GKE cree y modifique recursos en el espacio de nombres administrado kube-system
, lo que podría degradar la funcionalidad del clúster.
Google Kubernetes Engine (GKE) supervisa tus clústeres y usa el servicio de recomendador para brindar orientación sobre cómo optimizar el uso de la plataforma. Para ayudarte a garantizar que tu clúster permanezca estable y tenga un buen rendimiento, consulta las recomendaciones de GKE en las siguientes situaciones:
- Webhooks que operan, pero no tienen extremos disponibles.
- Webhooks que se consideran poco seguros, ya que operan en recursos y espacios de nombres críticos del sistema.
Con esta guía, puedes ver instrucciones para verificar tus webhooks mal configurados y actualizarlos, si es necesario.
Para obtener más información sobre cómo administrar las estadísticas y las recomendaciones de recomendadores, consulta Optimiza el uso de GKE con estadísticas y recomendaciones.
Identifica los webhooks mal configurados que podrían afectar tu clúster
Para obtener estadísticas que identifiquen webhooks que podrían afectar el rendimiento y la estabilidad de tu clúster, sigue las instrucciones a fin de ver estadísticas y recomendaciones. Puedes obtener estadísticas de las siguientes maneras:
- Uso de consola de Google Cloud.
- Usa Google Cloud CLI o la API del recomendador y filtra con los subtipos
K8S_ADMISSION_WEBHOOK_UNSAFE
yK8S_ADMISSION_WEBHOOK_UNAVAILABLE
.
Después de identificar los webhooks a través de las estadísticas, sigue las instrucciones para solucionar problemas de los webhooks detectados.
Cuando GKE detecta webhooks mal configurados
GKE genera una estadística y recomendación si se cumple alguno de los siguientes criterios para un clúster:
K8S_ADMISSION_WEBHOOK_UNAVAILABLE
: el clúster de GKE tiene uno o más webhooks que no informan extremos disponibles. Sigue las instrucciones para verificar los webhooks que no informan extremos disponibles.K8S_ADMISSION_WEBHOOK_UNSAFE
: El clúster de GKE tiene uno o más webhooks que se consideran poco seguros según los recursos que interceptan. Sigue las instrucciones para verificar los webhooks que se consideran poco seguros. Los siguientes webhooks se consideran poco seguros:- Webhooks que interceptan los recursos, incluidos los Pods y las asignaciones, en el espacio de nombres
kube-system
. - Webhooks que interceptan las asignaciones de tiempo en el espacio de nombres
kube-node-lease
. - Webhooks que interceptan los recursos del sistema con alcance del clúster, lo que incluye
Nodes
,TokenReviews
,SubjectAccessReviews
yCertificateSigningRequests
.
- Webhooks que interceptan los recursos, incluidos los Pods y las asignaciones, en el espacio de nombres
Soluciona problemas de los webhooks detectados
En las secciones siguientes, se incluyen instrucciones para solucionar problemas de los webhooks que GKE detectó como potencialmente mal configurados.
Después de que implementes las instrucciones y los webhooks se configuraren de forma correcta, la recomendación se resuelve en un plazo de 24 horas y ya no aparece en la consola. Si transcurrieron menos de 24 horas desde que implementaste la guía de la recomendación, puedes marcarla como resuelta. Si no deseas implementar la recomendación, puedes descartarla.
Webhooks que informan que no hay extremos disponibles
Si un webhook informa que no tiene extremos disponibles, el Service que respalda el extremo del webhook tiene uno o más Pods que no están en ejecución. Si deseas que los extremos del webhook estén disponibles, sigue las instrucciones para encontrar y solucionar problemas de los Pods del Service que respalda este extremo del webhook:
Consulta estadísticas y recomendaciones y elige una estadística a la vez para solucionar problemas. GKE genera una estadística por clúster, y esta estadística enumera uno o más webhooks con un extremo dañado que se debe investigar. Para cada webhook, la estadística también indica el nombre del Service, qué extremo está dañado y la última vez que se llamó al extremo.
Busca los Pods de entrega para el Service asociado con el webhook:
Console
Desde el panel de la barra lateral de la estadística, consulte la tabla de webhooks mal configurados. Haz clic en el nombre del Service.
kubectl
Ejecuta el siguiente comando para describir el Service:
kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
Reemplaza SERVICE_NAME y SERVICE_NAMESPACE por el nombre y el espacio de nombres del servicio, respectivamente.
Si no puedes encontrar el nombre del Service en el webhook, el extremo no disponible puede deberse a una discrepancia entre el nombre que aparece en la configuración y el nombre real del Service. Para corregir la disponibilidad del extremo, actualiza el nombre del Service en la configuración del webhook para que coincida con el objeto Service correcto.
Inspecciona los Pods de entrega para este Service:
Console
En Pods de entrega en los Detalles del Service, consulta la lista de Pods que respaldan este Service.
kubectl
Para identificar los Pods que no se están ejecutando, enumera los Deployments o los Pods:
kubectl get deployment -n SERVICE_NAMESPACE
O bien, ejecuta este comando:
kubectl get pods -n SERVICE_NAMESPACE -o wide
En el caso de los Pods que no se están ejecutando, inspecciona los registros de Pod para ver por qué no se están ejecutando. A fin de obtener instrucciones para solucionar problemas comunes con Pods, consulta Soluciona problemas con cargas de trabajo implementadas.
Webhooks que se consideran poco seguros
Si un webhook intercepta cualquier recurso en los espacios de nombres administrados por el sistema o determinados tipos de recursos, GKE considera que esto es poco seguro y recomienda que actualices los webhooks para evitar la interceptación de estos recursos.
- Sigue las instrucciones para ver estadísticas y recomendaciones y elige una estadística a la vez a fin de solucionar problemas. GKE solo genera una estadística por clúster, y esta estadística enumera una o más configuraciones de webhook, cada una de las cuales enumera uno o más webhooks. Para cada configuración de webhook enumerada, la estadística indica el motivo por el que se marcó la configuración.
Inspecciona la configuración del webhook:
Console
En el panel de la barra lateral de la estadística, consulta la tabla. En cada fila, se muestra el nombre de la configuración de webhook y el motivo por el que se marcó esta configuración.
Para inspeccionar cada configuración, haz clic en el nombre a fin de navegar a esta configuración en el panel del Navegador de objetos de GKE.
kubectl
Ejecuta el siguiente comando de
kubectl
para obtener la configuración del webhook. Para ello, reemplaza CONFIGURATION_NAME por el nombre de la configuración del webhook:kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
Si este comando no muestra nada, vuelve a ejecutarlo y reemplaza
validatingwebhookconfigurations
pormutatingwebhookconfigurations
.En la sección
webhooks
, se enumeran uno o más webhooks.Edita la configuración, según el motivo por el que se marcó el webhook:
Excluye los espacios de nombres kube-system y kube-node-lease
Se marca un webhook si
scope
es*
. O bien, se marca un webhook si el alcance esNamespaced
y se cumple alguna de las siguientes condiciones:La condición
operator
esNotIn
, yvalues
omitekube-system
ykube-node-lease
, como se muestra en el siguiente ejemplo:webhooks: - admissionReviewVersions: ... namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: NotIn values: - blue-system objectSelector: {} rules: - apiGroups: ... scope: '*' sideEffects: None timeoutSeconds: 3
Asegúrate de que
scope
esté configurado comoNamespaced
, no*
, para que el webhook solo funcione en espacios de nombres específicos. Además, sioperator
esNotIn
, asegúrate de incluirkube-system
ykube-node-lease
envalues
(en este ejemplo, conblue-system
).La condición
operator
esIn
, yvalues
incluyekube-system
ykube-node-lease
, como se muestra en el siguiente ejemplo:namespaceSelector: matchExpressions: - key: kubernetes.io/metadata.name operator: In values: - blue-system - kube-system - kube-node-lease
Asegúrate de que
scope
esté configurado comoNamespaced
, no*
, para que el webhook solo funcione en espacios de nombres específicos. Asegúrate de que sioperator
esIn
, no se incluyakube-system
nikube-node-lease
envalues
. En este ejemplo, soloblue-system
debe estar envalues
, ya queoperator
esIn
.
Excluye recursos coincidentes
Un webhook también se marca si
nodes
,tokenreviews
,subjectaccessreviews
ocertificatesigningrequests
aparecen en los recursos, como en el siguiente ejemplo:- admissionReviewVersions: ... resources: - 'pods' - 'nodes' - 'tokenreviews' - 'subjectacessreviews' - 'certificatesigningrequests' scope: '*' sideEffects: None timeoutSeconds: 3
Quita
nodes
,tokenreviews
,subjectaccessreviews
ycertificatesigningrequests
de la sección de recursos. Puedes mantenerpods
enresources
.