Garantiza la estabilidad del plano de control cuando usas webhooks

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:

  • Usa la consola de Google Cloud .
  • Usa Google Cloud CLI o la API del recomendador y filtra con los subtipos K8S_ADMISSION_WEBHOOK_UNSAFE y K8S_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:

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 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:

  1. 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.

  2. 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.

  3. 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. Si quieres 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.

  1. 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.

  2. 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 por mutatingwebhookconfigurations.

    En la sección webhooks, se enumeran uno o más webhooks.

  3. 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 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 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 como Namespaced, no *, para que el webhook solo funcione en espacios de nombres específicos. Además, si operator es NotIn, asegúrate de incluir 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 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 como Namespaced, no *, para que el webhook solo funcione en espacios de nombres específicos. Asegúrate de que si operator es In, no se incluya kube-system ni kube-node-lease en values. En este ejemplo, solo blue-system debe estar en values, ya que operator es In.

    Excluye recursos coincidentes

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

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

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

Webhooks que bloquean componentes críticos del sistema

Los webhooks que interceptan solicitudes para crear o actualizar ClusterRoles y ClusterRoleBindings pueden interferir en la capacidad del plano de control para conciliar estos recursos críticos del sistema. Por ejemplo, durante una actualización del clúster, es posible que kube-apiserver deba actualizar sus roles del sistema. Si un webhook que no está disponible o está mal configurado bloquea esta actualización, el kube-apiserver no podrá alcanzar el estado correcto, 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 esta situación.

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

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

Para evitar esta situación, asegúrate de que tus webhooks no intercepten solicitudes de ClusterRoles y ClusterRoleBindings que tengan el parámetro de configuración system: prefix.

Interbloqueo de admisión

Cuando un webhook está configurado para fallar de forma cerrada, puede crear una situación en la que el clúster no se pueda recuperar automáticamente. Por ejemplo, si se borran todos los nodos de un clúster, el webhook también estará inactivo. Dado que agregar un nodo nuevo 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 bloqueo de admisión, por lo que no se genera ninguna estadística para esta situación. Sin embargo, puede ocurrir un bloqueo de admisión si los Pods de webhook no están disponibles, en cuyo caso GKE detecta que el webhook no tiene extremos disponibles y genera una estadística de K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

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

Disponibilidad del plano de control del clúster

Cuando un webhook se configura para que falle de forma cerrada, la disponibilidad del plano de control de Kubernetes depende de la disponibilidad del webhook. Para mejorar la disponibilidad del plano de control, considera 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 para este caso.

  • Limita el alcance del webhook: Puedes eximir los recursos críticos de la validación del webhook para evitar que interfiera en procesos sensibles. Puedes eximir 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 crítico para la elección de líderes en Kubernetes.

  • Protege la implementación del webhook: Ejecutar el webhook en varios Pods puede aumentar su capacidad de recuperación y tiempo de actividad. Puedes usar selectores de nodos para distribuir los Pods en diferentes dominios con fallas.

¿Qué sigue?