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 consola Google Cloud .
  • 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 cerrarla.

Webhooks que 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. Consulta las estadísticas y las recomendaciones y elige una estadística cada vez para solucionar los problemas. GKE genera una información valiosa por clúster, y esta información valiosa muestra uno o varios webhooks con un endpoint roto que debe investigarse. En cada uno de estos webhooks, la información valiosa 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 incluye una o varias configuraciones de webhook, cada una de las cuales incluye 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 esta 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 modo 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

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

Siguientes pasos