Soluciona problemas de Distributed Cloud conectado

Google supervisa y mantiene de forma remota las implementaciones de Google Distributed Cloud conectado. Para ello, los ingenieros de Google tienen acceso de Secure Shell (SSH) al hardware de Distributed Cloud conectado. Si Google detecta un problema, un ingeniero de Google se comunicará contigo para solucionar problemas y resolverlo. Si identificaste un problema por tu cuenta, comunícate con el equipo de Atención al cliente de Google de inmediato para diagnosticarlo y resolverlo.

Actualizaciones de software de Distributed Cloud conectado

En esta sección, se describe cómo usar el Explorador de métricas para verificar si un clúster conectado de Distributed Cloud está en proceso de actualización de software.

En este procedimiento, se usan las siguientes métricas de Monitoring:

  • Versión actual del clúster (/edge_cluster/current_cluster_version): Indica la versión actual del software de Distributed Cloud conectado que se ejecuta en el clúster.

  • Versión de destino del clúster (/edge_cluster/target_cluster_version): Indica la versión de destino de Distributed Cloud conectado a la que se actualiza el clúster.

Para completar los pasos de esta sección, debes cumplir con los siguientes requisitos previos:

  1. Acceso a la consola de Google Cloud y a tu proyecto de Distributed Cloud conectado Google Cloud .
  2. El rol de IAM Visualizador de Monitoring, que te permite ver las métricas de Monitoring.
  3. (Opcional) El valor machine_id de la máquina conectada de Distributed Cloud de destino para filtrar los resultados que se muestran.

Usa el Explorador de métricas para verificar las versiones de software actuales y de destino del clúster

  1. Navega al Explorador de métricas:

    1. En la consola de Google Cloud , navega a la sección Monitoring.

    2. En el árbol de navegación de la izquierda, haz clic en Explorador de métricas.

  2. Selecciona el tipo de recurso de destino:

    1. En la página Explorador de métricas, navega a la página Configuración.

    2. Haz clic en Selecciona una métrica.

    3. Usa la barra de búsqueda para encontrar el tipo de recurso Clúster. También puedes usar el identificador de recurso completo edgecontainer.googleapis.com/Cluster.

    4. En los resultados que se muestran, haz clic en el tipo de recurso Clúster.

  3. Obtén la versión de software actual del clúster:

    1. En la sección Métrica, busca el valor current_cluster_version.

    2. Selecciona la métrica Tiempo de actividad de la máquina. Su ruta de acceso completa es edgecontainer.googleapis.com/edge_cluster/current_cluster_version.

    3. (Opcional) Filtra por el valor machine_id objetivo con la sección Filtro.

  4. Obtén la versión de software de destino del clúster:

    1. Haz clic en Agregar consulta.

    2. En la sección Métrica, busca el valor target_cluster_version.

    3. Selecciona la métrica Versión del clúster de destino. Su ruta de acceso completa es edgecontainer.googleapis.com/edge_cluster/target_cluster_version.

    4. Opcional: Filtra por el valor machine_id de destino con la sección Filtro.

  5. Verifica el estado de la actualización de software del clúster en el gráfico que aparece.

    • Si las líneas Current Cluster Version y Target Cluster Version indican valores diferentes, el clúster está en proceso de actualización de software.

    • Si las líneas Versión actual del clúster y Versión de destino del clúster indican el mismo valor, el clúster no se está sometiendo a una actualización de software.

  6. Verifica el resultado del paso anterior con el siguiente comando:

    gcloud edge-cloud container clusters describe CLUSTER_ID --location=REGION

    Reemplaza lo siguiente:

    • CLUSTER_ID: Es el ID del clúster de destino.
    • REGION: Es la región Google Cloud en la que se creó el clúster.

    En el resultado del comando, toma nota de los valores de los siguientes campos:

    • Si el valor del campo status es UPDATING, el clúster está en proceso de actualización de software.
    • Si los valores de los campos clusterVersion y targetVersion son diferentes, compáralos con los valores que muestra el Explorador de métricas.

Comprende los resultados

En la siguiente tabla, se explican los resultados que devuelven el Explorador de métricas y el comando gcloud.

Estado del clúster Diagnóstico Solución
En buen estado
Los valores de currentVersion y targetVersion coinciden
El valor de `status` es RUNNING
 El clúster ejecuta la versión de destino del software de Distributed Cloud conectado. Ninguno
Actualizando
El valor de currentVersion es inferior a targetVersion
El valor de `status` es UPDATING
 El clúster se está actualizando a la versión de destino del software conectado de Distributed Cloud. Supervisa el clúster en el Explorador de métricas hasta que coincidan los valores de la versión actual y de destino del clúster.
Bloqueado
El valor de currentVersion es inferior a targetVersion de forma indefinida
El valor de `status` es UPDATING de forma indefinida
 No se pudo actualizar a la versión de destino del software conectado de Distributed Cloud en al menos un nodo del clúster. Verifica la conectividad de la máquina y los registros del sistema. Comunícate con Google para obtener ayuda.
Reversión
El valor de currentVersion es mayor que targetVersion
El valor de `status` es UPDATING
 El clúster se está revirtiendo a una versión anterior del software de Distributed Cloud conectado. Comunícate con Google para identificar el motivo de la reversión.

Si la actualización de software en el clúster falló o el clúster se revirtió a una versión de software anterior, verifica lo siguiente:

  • Estado del nodo. Verifica que cada máquina física conectada de Distributed Cloud tenga conectividad de red y que informe el tiempo de actividad como se describe en la siguiente sección.
  • Períodos de mantenimiento. Verifica si la actualización de software se pausó debido a un período de exclusión de mantenimiento.
  • Registros del sistema. Examina los registros del sistema para identificar los posibles motivos de la falla de actualización del software, como los tiempos de espera de expulsión de Pods.

Si los pasos de resolución que se indican en la tabla no resuelven el problema, comunícate con el equipo de Atención al cliente de Google con el valor machine_id de la máquina afectada y la marca de tiempo de la interrupción.

Reinicios de máquinas de Distributed Cloud conectado

En esta sección, se describe cómo usar el Explorador de métricas para verificar si se reinició una máquina física conectada a Distributed Cloud y determinar el motivo del reinicio. Supervisar los reinicios ayuda a determinar si formaron parte de un mantenimiento planificado o si fueron el resultado de una falla de hardware o una interrupción del suministro eléctrico.

En este procedimiento, se usan las siguientes métricas de Monitoring:

  • Tiempo de actividad de la máquina (/machine/uptime): Indica el tiempo, en segundos, desde el último reinicio.

  • Reinicios de la máquina (/machine/restart_count): Indica la cantidad total de reinicios de la máquina de destino desde su implementación.

Para completar los pasos de esta sección, debes cumplir con los siguientes requisitos previos:

  1. Acceso a la consola de Google Cloud y a tu proyecto de Distributed Cloud conectado Google Cloud .
  2. El rol de IAM Visualizador de Monitoring, que te permite ver las métricas de Monitoring.
  3. (Opcional) El valor machine_id de la máquina conectada de Distributed Cloud de destino para filtrar los resultados que se muestran.

Usa el Explorador de métricas para verificar el tiempo de actividad de la máquina y el recuento de reinicios

  1. Navega al Explorador de métricas:

    1. En la consola de Google Cloud , navega a la sección Monitoring.

    2. En el árbol de navegación de la izquierda, haz clic en Explorador de métricas.

  2. Selecciona el tipo de recurso de destino:

    1. En la página Explorador de métricas, navega a la página Configuración.

    2. Haz clic en Selecciona una métrica.

    3. Usa la barra de búsqueda para buscar el tipo de recurso Máquina. También puedes usar el identificador de recurso completo edgecontainer.googleapis.com/Machine.

    4. En los resultados que se muestran, haz clic en el tipo de recurso Máquina.

  3. Verifica el tiempo de actividad de la máquina:

    1. En la sección Métrica, busca el valor uptime.

    2. Selecciona la métrica Tiempo de actividad de la máquina. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/uptime.

    3. Opcional: Filtra por el valor machine_id de destino con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que el gráfico de tiempo de actividad aumente de forma continua. Si en algún momento el valor del tiempo de actividad cae a cero y se reinicia, esto indica que la máquina se reinició.

  4. Verifica el recuento de reinicios de la máquina:

    1. En la sección Métrica, busca el valor restart_count.

    2. Selecciona la métrica Reinicios de la máquina. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/restart_count.

    3. Opcional: Filtra por el valor machine_id de destino con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que la línea del gráfico permanezca en 0, lo que indica que no se produjeron reinicios. Si en algún momento la línea alcanza un aumento repentino de 1, significa que la máquina se reinició. Anota la marca de tiempo exacta del reinicio para solucionar problemas.

    5. Opcional: Para ver eventos individuales en lugar de un gráfico, navega a la sección Agregación de la página, establece el campo Período de alineación en 1 minute y el campo Alineador por serie en Delta.

Comprende los resultados

En la siguiente tabla, se explican los resultados que devuelve el Explorador de métricas.

Estado de la máquina Diagnóstico Solución
Estable
La métrica "Tiempo de actividad de la máquina" aumenta de forma constante
La diferencia de la métrica "Reinicios de la máquina" es 0
 La máquina no se reinició. Ninguno
Reinicio limpio
La métrica "Tiempo de actividad de la máquina" disminuye a 0
La métrica "Reinicios de la máquina" aumenta a 1
 La máquina se reinició y se volvió a conectar correctamente a Google Cloud. Revisa los registros del sistema para determinar el motivo del reinicio.
Falla de alimentación
El gráfico de la métrica "Tiempo de actividad de la máquina" tiene una interrupción sin datos
La métrica "Reinicios de la máquina" no cambió durante la interrupción del tiempo de actividad de la máquina
 La máquina perdió la alimentación o la conectividad de red antes de que pudiera reiniciarse. Verifica el cableado de alimentación y de red, la configuración de la red local y el estado del indicador LED.
Intermitente
El valor de la métrica "Máquina conectada" alterna entre 0 y 1
El valor de la métrica "Conectividad de red" alterna entre 0 y 1
 Conexión de red inestable, pérdida de paquetes o latencia excesiva. Verifica si hay congestión y hardware defectuoso en tu red local.

Si los pasos de resolución que se indican en la tabla no resuelven el problema, comunícate con el equipo de Atención al cliente de Google con el valor machine_id de la máquina afectada y la marca de tiempo de la interrupción.

Conectividad de máquinas de Distributed Cloud conectado

En esta sección, se describe cómo verificar la conectividad de Internet y de Google Cloud para tus máquinas conectadas de Distributed Cloud con la función Explorador de métricas de Cloud Monitoring.

En este procedimiento, se usan las siguientes métricas de Monitoring:

  • Máquina conectada (/machine/connected): Indica si la máquina está conectada a Google Cloud.

  • Conectividad de red (/machine/network/connectivity): Indica si la interfaz de red principal de la máquina tiene conectividad a Internet.

Para completar los pasos de esta sección, debes cumplir con los siguientes requisitos previos:

  1. Acceso a la consola de Google Cloud y a tu proyecto de Distributed Cloud conectado Google Cloud .
  2. El rol de IAM Visualizador de Monitoring, que te permite ver las métricas de Monitoring.
  3. (Opcional) El valor machine_id de la máquina conectada de Distributed Cloud de destino para filtrar los resultados que se muestran.

Usa el Explorador de métricas para verificar la conectividad de la máquina

  1. Navega al Explorador de métricas:

    1. En la consola de Google Cloud , navega a la sección Monitoring.

    2. En el árbol de navegación de la izquierda, haz clic en Explorador de métricas.

  2. Selecciona el tipo de recurso de destino:

    1. En la página Explorador de métricas, navega a la página Consultas.

    2. Usa la barra de búsqueda para buscar el tipo de recurso Máquina. También puedes usar el identificador de recurso completo edgecontainer.googleapis.com/Machine.

    3. En los resultados que se muestran, haz clic en el tipo de recurso Máquina.

  3. Verifica la conexión de la máquina a Google Cloud:

    1. En la sección Métrica, busca el valor connected.

    2. Selecciona la métrica Machine Connected. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/connected.

    3. Opcional: Filtra por el valor machine_id de destino con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que la línea En buen estado permanezca en el 100% de forma continua. Si en algún momento este valor es 0% o En mal estado, la máquina perdió la conectividad con Google Cloud en el momento indicado.

  4. Verifica la conectividad a Internet de la máquina:

    1. En la sección Métrica, busca el valor connectivity.

    2. Selecciona la métrica Conectividad de red. Su ruta de acceso completa es edgecontainer.googleapis.com/machine/network/connectivity.

    3. Opcional: Filtra por el valor machine_id de destino con la sección Filtro.

    4. En el gráfico de tiempo que aparece, verifica que la línea En buen estado permanezca en el 100% de forma continua. Si en algún momento este valor es 0% En mal estado, la máquina perdió la conectividad a Internet en el momento indicado.

Comprende los resultados

En la siguiente tabla, se explican los resultados que devuelve el Explorador de métricas.

Estado de la máquina Diagnóstico Solución
En buen estado
El valor de la métrica "Máquina conectada" es 1
El valor de la métrica "Conectividad de red" es 1
 Operación normal. Ninguno
Desconectada
El valor de la métrica "Máquina conectada" es 0
El valor de la métrica "Conectividad de red" es 1
 La máquina tiene conectividad a Internet, pero no se puede conectar a Google Cloud. Verifica tus reglas de firewall para los servicios de Google y los endpoints de API. Verifica que los agentes conectados de Distributed Cloud se estén ejecutando en la máquina.
Aislado
El valor de la métrica "Máquina conectada" es 0
El valor de la métrica "Conectividad de red" es 0
 La máquina no tiene conexión a Internet. Verifica el cableado de alimentación y de red, la configuración de la red local y el estado del indicador LED. Verifica la configuración de la VLAN y del enrutamiento.
Intermitente
El valor de la métrica "Máquina conectada" alterna entre 0 y 1
El valor de la métrica "Conectividad de red" alterna entre 0 y 1
 Conexión de red inestable, pérdida de paquetes o latencia excesiva. Verifica si hay congestión y hardware defectuoso en tu red local.

Si notas valores sostenidos de 0 para cualquiera de las métricas, sigue los pasos para solucionar problemas que se describen en la tabla para resolverlos. Si el problema persiste, comunícate con el equipo de Atención al cliente de Google con el valor machine_id de la máquina afectada y la marca de tiempo de la interrupción.

Máquinas virtuales atascadas en el estado Pending

Una carga de trabajo de máquina virtual puede quedar bloqueada en el estado Pending y no programarse en un nodo si ocurre una de las siguientes situaciones:

  • Distributed Cloud conectado no puede asignar los recursos solicitados, como el tiempo de CPU, la memoria o el espacio en el disco, a la máquina virtual.
  • Hay un error en la configuración de la máquina virtual.
  • Hay una falla en el almacenamiento de la máquina virtual.
  • El nodo de destino tiene una tacha.

Para solucionar este problema, haz lo siguiente:

  1. Obtén las credenciales del clúster como se describe en Obtén credenciales para un clúster.

  2. Obtén información sobre la máquina virtual afectada:

    kubectl describe virtualmachine VM_NAME -n NAMESPACE

    Reemplaza lo siguiente:

    • VM_NAME: Es el nombre de la máquina virtual de destino.
    • NAMESPACE: Es el espacio de nombres de la máquina virtual de destino.

    El comando muestra un resultado similar al siguiente:

    Status:
...
State:                    Pending
...
Events:
Type     Reason                  Age   From                       Message
----     ------                  ----  ----                       -------
Normal   SuccessfulCreate        15m   virtualmachine-controller  Created virtual machine my-stuck-vm
Warning  DiskProvisioningFailed  14m   virtualmachine-controller  Failed to provision disk: DataVolume my-stuck-vm-data-disk not ready
Warning  PVCNotBound             14m   virtualmachine-controller  PersistentVolumeClaim my-stuck-vm-data-disk is in phase Pending
Warning  VMINotCreated           10m   virtualmachine-controller  VirtualMachineInstance cannot be created: dependencies not ready

    El resultado del comando contiene mensajes que podrían indicar restricciones de recursos, fallas de programación, fallas de almacenamiento y otros problemas.

  3. Examina el resultado para determinar las causas de la falla de programación, como se explica en las siguientes secciones.

Recursos insuficientes

Es posible que veas un mensaje que indique que los recursos, como la CPU, la memoria o el espacio en el disco, son insuficientes. Por ejemplo:

5/8 nodes are available: 3 Insufficient memory, 3 Insufficient CPU.

Para solucionar este problema, verifica los recursos asignados a las máquinas virtuales afectadas y otras cargas de trabajo programadas en el nodo. Luego, haz lo siguiente según tus necesidades empresariales:

  • Reduce la escala verticalmente de otras cargas de trabajo programadas en el nodo.
  • Reduce la cantidad de recursos asignados a la máquina virtual afectada.
  • Agrega más máquinas al clúster afectado.

Nodos con taint

Es posible que veas un mensaje que indica que el nodo de destino está contaminado. Por ejemplo:

5/8 nodes are available: 3 node(s) had taint {<taint-key>:<taint-value>}, that the pod didn't tolerate.

Para solucionar este problema, haz lo siguiente:

  1. Usa el siguiente comando para verificar si hay taints en el nodo:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

    El comando muestra un resultado similar al siguiente:

    NAME                           TAINTS
node-name-1   [map[effect:PreferNoSchedule key:node-role.kubernetes.io/master] map[effect:PreferNoSchedule key:node-role.kubernetes.io/control-plane]]
node-name-2   <none>

  2. Realiza una de las siguientes acciones:

    • En el caso de los taints inesperados, quítalos como se describe en Taints y tolerancias.
    • Para los taints esperados, agrega las tolerancias correspondientes a la configuración de la máquina virtual, como se describe en Taints y tolerancias.

Fallas de almacenamiento

Es posible que veas un mensaje que indica una falla en el almacenamiento de la máquina virtual. Por ejemplo:

5/8 nodes are available: 3 node(s) had volume node affinity conflict, 3 node(s) had unbound immediate PersistentVolumeClaims.

Este mensaje puede indicar que el volumen persistente correspondiente no se puede activar en el nodo de destino.

Para solucionar este problema, haz lo siguiente:

  1. Usa el siguiente comando para obtener el estado de las reclamaciones de volumen persistente (PVC) en el espacio de nombres de la máquina virtual afectada:

    kubectl get pvc -n NAMESPACE

    Reemplaza NAMESPACE por el nombre del espacio de nombres de destino.

    El comando muestra un resultado similar al siguiente:

    NAME                                               STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            AGE
windows-robin-disk-0                               Bound     pvc-b1a1d264-84bf-4e58-857d-f37f629d5082   25Gi       RWX            robin-block-immediate   30h
windows-robin-disk-1                               Bound     pvc-0130b9a8-7fed-4df0-8226-d79273792a16   25Gi       RWX            robin-block-immediate   30h
windows-robin-vm-0-restored-windows-robin-disk-0   Pending                                                                        gce-pd-gkebackup-in     26m

  2. Verifica que la PVC correspondiente tenga el estado Bound. Si el estado es Pending, el subsistema de almacenamiento no pudo aprovisionar el volumen. En esos casos, debes solucionar los problemas de configuración del subsistema de almacenamiento y asegurarte de que esté disponible el StorageClass adecuado.

Bloqueos de programación causados por webhooks de admisión con errores

Los webhooks de admisión te permiten interceptar solicitudes al servidor de la API de Kubernetes antes de que el objeto se vuelva persistente. Si bien son útiles para aplicar políticas de seguridad personalizadas, los webhooks mal configurados pueden causar interrupciones en todo el clúster, en especial durante operaciones críticas, como actualizaciones de software y de certificados. En particular, un webhook de admisión bloqueado o no disponible puede detener el plano de control de Kubernetes, lo que impide que se programen más cargas de trabajo en el clúster.

Bloqueo del plano de control

Se puede producir un interbloqueo de dependencia circular cuando un webhook de admisión es responsable de validar los recursos que se requieren para la recuperación del webhook. Por ejemplo, si se configura un webhook de admisión para validar Pods y ese Pod de webhook debe reprogramarse durante una actualización del software del nodo, el servidor de la API de Kubernetes puede intentar comunicarse con el webhook para autorizar la creación del Pod nuevo. Si no se puede acceder al webhook, la solicitud falla, no se crea el Pod y el clúster entra en un estado de interbloqueo en el que no se pueden programar cargas de trabajo nuevas.

Cuando se configura un webhook con failurePolicy: Fail, cualquier error de comunicación o tiempo de espera entre el servidor de la API y el webhook genera el rechazo de la solicitud a la API. Esto provoca los siguientes problemas:

  • Las actualizaciones de software fallan: Los componentes del sistema y las VMs no se pueden programar durante y después de una actualización de software de nodo.
  • Los servicios del sistema no se pueden iniciar: Los Pods de infraestructura, como Symcloud Storage y el entorno de ejecución de VM en GDC, no se pueden iniciar.
  • Nodos atascados en modo de mantenimiento: Los nodos en modo de mantenimiento no se pueden conciliar ni salir porque la lógica de admisión bloquea el controlador.

Prácticas recomendadas para la configuración de webhooks

Sigue las prácticas recomendadas que se describen en esta sección para evitar el interbloqueo del plano de control que se describió anteriormente. Estas prácticas recomendadas se aplican a todos los objetos ValidatingWebhookConfiguration y MutatingWebhookConfiguration.

Utilizar failurePolicy: Ignore

A menos que los requisitos de tu empresa indiquen que una solicitud a la API debe fallar si no se puede validar, establece siempre el campo failurePolicy en Ignore. Esto garantiza que el servidor de la API de Kubernetes siga funcionando incluso cuando el servicio de webhook afectado esté inactivo, lo que permite que los Pods críticos del sistema se programen y se recuperen.

Excluye los espacios de nombres reservados

Tus webhooks nunca deben interceptar solicitudes de recursos en espacios de nombres reservados. Debes excluir esos espacios de nombres de la configuración del webhook con el campo namespaceSelector. Consulta Restricciones de espacios de nombres de administración para obtener una lista completa de los espacios de nombres reservados. Por ejemplo:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "customer-policy-webhook"
webhooks:
- name: "validate-labels.example.com"
  failurePolicy: Ignore
  sideEffects: None
  admissionReviewVersions: ["v1"]
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system
      - kube-node-lease
      - kube-public
      - capi-system
      - capi-kubeadm-bootstrap-system
      - gke-system
      - gke-connect
      - gke-operators
      - gke-managed-metrics-server
      - anthos-identity-service
      - anthos-creds
      - robinio
      - robin-admin
      - vm-system
      - cert-manager
      - cert-manager-cluster-resources
      - dns-system
      - g-istio-system
      - nf-operator
      - prom-monitoring
      - gpu-system
      - oclcm-system
      - saas-system
  rules:
  - operations: ["CREATE", "UPDATE"]
    apiGroups: ["*"]
    apiVersions: ["*"]
    resources: ["pods", "deployments"]

Recupera un clúster bloqueado por webhooks con errores

Si tu clúster se bloqueó por webhooks con errores y tus comandos kubectl para crear recursos agotan el tiempo de espera o devuelven errores, suele deberse a que el webhook tiene su failurePolicy configurado como Fail. Sigue los pasos que se indican en esta sección para recuperar el clúster del interbloqueo. Si el webhook con errores es un webhook de mutación, usa mutatingwebhookconfiguration en lugar de validatingwebhookconfiguration.

  1. Identifica los webhooks con errores:

    1. Enumera los webhooks de validación implementados en el clúster:

      kubectl get validatingwebhookconfigurations

    2. Enumera los webhooks de mutación implementados en el clúster:

      kubectl get mutatingwebhookconfigurations

  2. Verifica si los Pods que respaldan esos webhooks se están ejecutando:

    kubectl get pods -A | grep WEBHOOK_SERVICE

    Reemplaza WEBHOOK_SERVICE por el nombre del servicio del webhook de destino.

  3. Establece el failurePolicy del webhook con errores en Ignore:

    kubectl patch validatingwebhookconfiguration WEBHOOK_CONFIG \
  --type='json' \
  -p='[{"op": "replace", "path": "/webhooks/0/failurePolicy", "value":"Ignore"}]'

    Reemplaza WEBHOOK_SERVICE por el nombre del servicio del webhook de destino.

  4. (Opcional) Si el paso anterior falló, borra de manera forzosa la configuración del webhook afectado:

    kubectl delete validatingwebhookconfiguration WEBHOOK_CONFIG --timeout=10s

    Reemplaza WEBHOOK_CONFIG por el nombre de la configuración del webhook de destino.

Después de modificar o forzar la eliminación de la configuración del webhook, el servidor de la API de Kubernetes reanuda el procesamiento de las solicitudes, lo que resuelve el interbloqueo y permite que se completen los procesos bloqueados.