Asegurar la estabilidad del plano de control al usar webhooks

Los webhooks de admisión, o webhooks en Kubernetes, son un tipo de controlador 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 conserven. Es habitual que las aplicaciones de terceros usen webhooks que operan en recursos y espacios de nombres críticos para el sistema. Los webhooks configurados incorrectamente pueden afectar al rendimiento y la fiabilidad del plano de control. Por ejemplo, un webhook configurado incorrectamente creado por una aplicación de terceros podría impedir que GKE cree y modifique recursos en el espacio de nombres kube-system gestionado, lo que podría reducir la funcionalidad del clúster.

Google Kubernetes Engine (GKE) monitoriza tus clústeres y usa el servicio Recommender para ofrecerte recomendaciones sobre cómo optimizar el uso de la plataforma. Para ayudarte a asegurarte de que tu clúster se mantiene estable y con un buen rendimiento, consulta las recomendaciones de GKE para los siguientes casos:

  • Webhooks que funcionan, pero que no tienen ningún endpoint disponible.
  • Webhooks que se consideran no seguros porque operan en recursos y espacios de nombres críticos del sistema.

Con estas instrucciones, puedes comprobar si tus webhooks están mal configurados y actualizarlos si es necesario.

Para obtener más información sobre cómo gestionar las estadísticas y las recomendaciones de Recommenders, consulta Optimizar el uso de GKE con estadísticas y recomendaciones.

Identificar webhooks mal configurados que podrían afectar a tu clúster

Para obtener información valiosa que identifique los webhooks que podrían afectar al rendimiento y la estabilidad de tu clúster, sigue las instrucciones para ver información valiosa y recomendaciones. Puedes obtener estadísticas de las siguientes formas:

  • Usa la Google Cloud consola.
  • Usa Google Cloud CLI o la API Recommender y filtra por los subtipos K8S_ADMISSION_WEBHOOK_UNSAFE y K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Una vez que hayas identificado las webhooks a través de las estadísticas, sigue las instrucciones para solucionar los problemas de las webhooks detectadas.

Cuando GKE detecta webhooks mal configurados

GKE genera una estadística y una recomendación si se cumple alguno de los siguientes criterios en un clúster:

Solucionar los problemas de los webhooks detectados

En las siguientes secciones se incluyen instrucciones para solucionar los problemas de los webhooks que GKE ha detectado como potencialmente mal configurados.

Una vez que haya implementado las instrucciones y los webhooks estén configurados correctamente, la recomendación se resolverá en un plazo de 24 horas y dejará de aparecer en la consola.

Si no quieres implementar la recomendación, puedes rechazarla.

Los webhooks informan de que no hay endpoints disponibles

Si un webhook informa de que no tiene endpoints disponibles, significa que el servicio que respalda el endpoint del webhook tiene uno o varios pods que no se están ejecutando. Para que los endpoints de webhook estén disponibles, sigue las instrucciones para encontrar y solucionar problemas de los pods del servicio que respalda este endpoint de webhook:

  1. Ver estadísticas y recomendaciones, eligiendo una estadística cada vez para solucionar problemas. GKE genera una estadística por clúster, y esta estadística muestra uno o varios webhooks con un endpoint roto que debe investigarse. En cada uno de estos webhooks, la estadística también indica el nombre del servicio, qué endpoint no funciona y la última vez que se llamó al endpoint.

  2. Busca los pods de servicio del servicio asociado al webhook:

    Consola

    En el panel lateral de la estadística, consulta la tabla de webhooks mal configurados. Haz clic en el nombre del servicio.

    kubectl

    Ejecuta el siguiente comando para describir el servicio:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Sustituye SERVICE_NAME y SERVICE_NAMESPACE por el nombre y el espacio de nombres del servicio, respectivamente.

    Si no encuentras el nombre del servicio en el webhook, es posible que el endpoint no esté disponible debido a una discrepancia entre el nombre que figura en la configuración y el nombre real del servicio. Para solucionar el problema de disponibilidad del endpoint, actualiza el nombre del servicio en la configuración del webhook para que coincida con el objeto de servicio correcto.

  3. Inspecciona los pods de servicio de este servicio:

    Consola

    En Serving Pods (Pods de servicio) de Service details (Detalles del servicio), consulta la lista de pods que respaldan este servicio.

    kubectl

    Para identificar qué pods no se están ejecutando, enumera los despliegues o los pods:

    kubectl get deployment -n SERVICE_NAMESPACE

    También puedes ejecutar 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 para ver por qué no se están ejecutando. Para obtener instrucciones sobre problemas habituales con los pods, consulta Solucionar problemas con cargas de trabajo implementadas.

Webhooks que se consideran no seguros

Si un webhook intercepta algún recurso en espacios de nombres gestionados por el sistema o determinados tipos de recursos, GKE considera que no es seguro y recomienda que actualice los webhooks para evitar que intercepten estos recursos.

  1. Sigue las instrucciones para ver estadísticas y recomendaciones y elige una estadística cada vez para solucionar los problemas. GKE solo genera una estadística por clúster, y esta estadística muestra una o varias configuraciones de webhook, cada una de las cuales muestra uno o varios webhooks. En cada configuración de webhook que se muestra, la estadística indica el motivo por el que se ha marcado la configuración.

  2. Inspecciona la configuración del webhook:

    Consola

    En el panel lateral de la estadística, consulta la tabla. En cada fila se muestra el nombre de la configuración del webhook y el motivo por el que se ha marcado.

    Para inspeccionar cada configuración, haz clic en el nombre para ir a esa configuración en el panel de control Explorador de objetos de GKE.

    kubectl

    Ejecuta el siguiente comando kubectl para obtener la configuración del webhook. Sustituye CONFIGURATION_NAME por el nombre de la configuración del webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Si este comando no devuelve nada, vuelve a ejecutarlo y sustituye validatingwebhookconfigurations por mutatingwebhookconfigurations.

    En la sección webhooks, hay uno o varios webhooks.

  3. Edita la configuración en función del motivo por el que se ha marcado el webhook:

    Excluir 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 ámbito es Namespaced y se cumple alguna de las siguientes condiciones:

    • La condición operator es NotIn y values omite kube-system y kube-node-lease, como 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 definir scope como Namespaced y no como * para que el webhook solo funcione en espacios de nombres específicos. Además, asegúrate de que, si operator es NotIn, incluyas kube-system y kube-node-lease en values (en este ejemplo, con blue-system).

    • La condición operator es In y values incluye kube-system y kube-node-lease, como 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 como Namespaced y no como *, de forma que el webhook solo funcione en espacios de nombres específicos. Asegúrate de que, si operator es In, no incluyas kube-system ni kube-node-lease en values. En este ejemplo, solo blue-system debe estar en values, ya que operator es In.

    Excluir recursos coincidentes

    Un webhook también se marca si nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests se incluyen en los recursos, como en el siguiente ejemplo:

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

    Elimina nodes, tokenreviews, subjectaccessreviews y certificatesigningrequests de la sección de recursos. Puedes guardar pods en resources.

Webhooks que bloquean componentes críticos del sistema

Los webhooks que interceptan las solicitudes para crear o actualizar ClusterRoles y ClusterRoleBindings pueden interferir en la capacidad del plano de control para reconciliar estos recursos críticos del sistema. Por ejemplo, durante una actualización de un clúster, es posible que el kube-apiserver tenga que actualizar sus roles del sistema. Si un webhook que no está disponible o está mal configurado bloquea esta actualización, kube-apiserver no podrá estar en buen estado, lo que bloqueará la actualización del clúster.

GKE no detecta si los webhooks interceptan ClusterRoles y ClusterRoleBindings, por lo que no se genera ninguna estadística para este caso.

En el ejemplo siguiente se muestra una configuración de webhook problemática que intercepta ClusterRoles:

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

Para evitarlo, asegúrate de que tus webhooks no intercepten solicitudes de ClusterRoles y ClusterRoleBindings que tengan el ajuste system: prefix.

Interbloqueo de admisión

Si un webhook está configurado para cerrarse cuando falla, puede darse una situación en la que el clúster no pueda recuperarse automáticamente. Por ejemplo, si se eliminan todos los nodos de un clúster, el webhook también dejará de funcionar. Como para añadir un nuevo nodo se requiere una validación de admisión, el webhook debe estar disponible para aprobar la solicitud. Esto crea una dependencia circular que puede impedir que se recupere el plano de control del clúster.

GKE no detecta situaciones de interbloqueo de admisión, por lo que no se genera ninguna estadística para este caso. Sin embargo, puede producirse un bloqueo de admisión si los pods de webhook no funcionan, en cuyo caso GKE detecta que el webhook no tiene endpoints disponibles y genera una estadística K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Para mitigar este problema, puedes eliminar el ValidatingWebhookConfiguration para romper la dependencia circular y permitir que el clúster se recupere.

Disponibilidad del plano de control del clúster

Si un webhook está configurado para fallar de forma cerrada, la disponibilidad del plano de control de Kubernetes dependerá de la disponibilidad del webhook. Para mejorar la disponibilidad del plano de control, ten en cuenta lo siguiente:

GKE no detecta problemas de disponibilidad del plano de control del clúster causados por webhooks, por lo que no se genera ninguna estadística en este caso.

  • Limita el ámbito del webhook: puedes eximir a los recursos críticos de la validación del webhook para evitar que interfiera en procesos sensibles. Puedes excluir espacios de nombres o tipos específicos de recursos. Sin embargo, ten en cuenta las dependencias no evidentes. Por ejemplo, un ConfigMap puede ser un recurso fundamental para la elección de líderes en Kubernetes.

  • Refuerza la implementación del webhook: ejecutar el webhook en varios pods puede aumentar su resiliencia y tiempo de actividad. Puedes usar selectores de nodos para distribuir los pods en diferentes dominios de errores.

Siguientes pasos