Soluciona problemas de webhook de GKE en Azure

En esta página, se muestra cómo resolver problemas relacionados con webhooks problemáticos o no seguros en GKE on Azure.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Tipos de webhooks problemáticos

Los webhooks de admisión, o webhooks en Kubernetes, son un tipo de controlador de admisión que se puede usar en los clústeres de Kubernetes para validar o modificar las solicitudes al plano de control antes de que persista 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 y creado por una aplicación de terceros podría impedir que GKE on Azure cree y modifique recursos en el espacio de nombres kube-system administrado, lo que podría degradar la funcionalidad del clúster.

Los webhooks problemáticos incluyen los siguientes tipos:

Webhooks que no tienen extremos disponibles

Si un webhook no tiene extremos disponibles, el servicio que respalda el extremo de webhook tiene uno o más Pods que no están en ejecución. Si deseas que los extremos de webhook estén disponibles, sigue las instrucciones para encontrar y solucionar los problemas de los pods del servicio que respaldan este extremo de webhook:

  1. Busca los Pods de entrega para el Service asociado con el webhook. Ejecuta el siguiente comando para describir el servicio:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Reemplaza lo siguiente:

    • SERVICE_NAME por el nombre del Service
    • SERVICE_NAMESPACE por el nombre del espacio de nombres

    Si no puedes encontrar el nombre del servicio enumerado en el webhook, es posible que el extremo no disponible se deba a una discrepancia entre el nombre indicado en la configuración y el nombre real del servicio. 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.

  2. Inspecciona los Pods de entrega para este Service. Para identificar los Pods que no se están ejecutando, enumera el Deployment:

    kubectl get deployment -n SERVICE_NAMESPACE

    O bien, ejecuta el siguiente comando para mostrar los Pods:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    En el caso de los Pods que no se están ejecutando, inspecciona los registros del Pod para ver por qué no se están ejecutando.

Webhooks que se consideran poco seguros

Si un webhook intercepta algún recurso en los espacios de nombres administrados por el sistema, recomendamos que los actualices para evitar interceptar estos recursos.

  1. Inspecciona la configuración del webhook. Ejecuta el siguiente comando de kubectl para obtener la configuración del webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Reemplaza CONFIGURATION_NAME por el nombre de la configuración de webhook.

    Si este comando no muestra nada, vuelve a ejecutarlo y reemplaza validatingwebhookconfigurations por mutatingwebhookconfigurations.

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

  2. Edita la configuración, según el motivo por el que el webhook se considera no seguro:

    Excluye los espacios de nombres kube-system y kube-node-lease

    Un webhook se considera no seguro si scope es *, o 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 # add 'kube-system' and 'kube-node-lease' if `NotIn`
  objectSelector: {}
  rules:
  - apiGroups:
    ...
    scope: '*' # 'Namespaced'
  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. Asegúrate de que si operator es NotIn, kube-system y kube-node-lease se incluyan en values.

    • 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 # remove as operator is `In`
      - kube-node-lease # remove as operator is `In`

      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, kube-system y kube-node-lease no se incluyan en values.

    Excluye recursos coincidentes

    Un webhook también se considera no seguro si nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests se enumeran en la sección de recursos, como en el siguiente ejemplo:

    - admissionReviewVersions:
...
    resources:
    - 'pods' # keep, remove everything else
    - 'nodes'
    - 'tokenreviews'
    - 'subjectacessreviews'
    - 'certificatesigningrequests'
    scope: '*'
  sideEffects: None
  timeoutSeconds: 3

    Quita nodes, tokenreviews, subjectaccessreviews y certificatesigningrequests de la sección de recursos.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.