¿Por qué mi nodo trabajador muestra un error NetworkUnavailable ?

Resolución de problemas relacionados con el estado de los nodos de Calico y con la red.

Nube privada virtual Infraestructura clásica Satellite

Cuando actualice los nodos maestro o trabajador, los nodos trabajadores entrarán en un estado Node network unavailable.

Los nodos trabajadores pueden entrar en un estado NetworkUnavailable o Node network unavailable siempre que se haya cerrado el pod calico-node. Esto puede ocurrir durante la actualización de un parche de Calico, pero no debería afectar a la disponibilidad de su aplicación.

Cuando se actualiza Calico, la marca node.kubernetes.io/network-unavailable:NoSchedule se añade al nodo trabajador y la condición Node network unavailable pasa a ser True. Ambas condiciones se borran cuando se reinicia Calico, que normalmente tarda sólo unos segundos.

Mientras esto ocurre, es posible que aparezca un mensaje de error similar al del siguiente ejemplo.

[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX
[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX
[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX

A veces, el reinicio puede tardar más tiempo. En casi todos los casos, el reinicio es lo suficientemente rápido para evitar cualquier problema de red de nodo trabajador. Sin embargo, hay situaciones en las que un reinicio de Calico se retrasa y, por lo tanto, podría haber interrupciones de red. En estos casos, la condición y la corrupción de la red de nodos no disponibles se han diseñado para evitar que se desplieguen nuevas apps en el nuevo nodo hasta que se arreglen Calico y el nodo. Las actualizaciones de Calico se despliegan de forma muy controlada para minimizar el impacto global de la aplicación en caso de que haya un problema de nodo.

Supervise el estado de Node network unavailable con IBM Cloud Monitoring

Mediante el uso de servicios para supervisar aplicaciones como IBM Cloud Monitoring, puede configurar alertas para cuando un nodo trabajador entra en un estado Node network unavailable y contar cada vez que esto sucede. También puede configurar umbrales y ajustar las alertas para permitir cuando los nodos trabajadores estén en un estado Node network unavailable durante los parches Calico de rutina.

Cuando configure alertas de IBM Cloud Monitoring, tenga en cuenta los escenarios siguientes.

  • Una alerta Node network unavailable puede convertirse en un problema cuando un pod calico-node no puede alcanzar un estado Running y su recuento de reinicios de contenedor sigue aumentando.
  • Un nodo trabajador permanece en estado Node network unavailable durante un periodo largo de tiempo.

Después de una actualización o sustitución de un trabajador, a veces el pod calico-node sigue sin iniciarse en el clúster de VPC Red Hat OpenShift. El pod calico_node puede atascarse en un estado en el que no se puede iniciar en un clúster de VPC de Red Hat OpenShift. Esto no es un problema en los clústeres de IKS o Classic. Esto puede ocurrir cuando tiene instalado sysdig-admission-controller-webhook e intenta realizar una actualización o sustitución de un trabajador. Esto sucede porque:

  1. El pod de cliente VPN se mueve al nuevo trabajador a medida que se inicia.
  2. calico-node en el nuevo trabajador se inicia, pero se bloquea porque realiza una llamada apiserver y excede el tiempo de espera después de 2 segundos.
  3. A continuación, la llamada apiserver intenta llamar al webhook que falla porque el pod de cliente VPN estaba intentando iniciarse en el nuevo nodo. El nodo VPN no puede hacerlo correctamente porque calico-node no se ha iniciado todavía.

En resumen, el inicio del pod calico-node depende del funcionamiento del webhook; el webhook depende del pod del cliente VPN; y el pod del cliente VPN depende del inicio de calico-node. El sistema está atascado en una dependencia circular. Si puede recopilar registros de un pod calico-node desplegado correctamente, es posible que vea un error como el siguiente:

2022-09-08 07:13:19.719 [WARNING][9] startup/utils.go 228: Failed to set NetworkUnavailable; will retry error=Patch "https://172.21.0.1:443/api/v1/nodes/10.242.64.17/status?timeout=2s": net/http: request canceled (Client.Timeout exceeded while awaiting headers)

Métodos alternativos para calico-node

Puede utilizar uno de los métodos siguientes para solucionar el problema y volver a ejecutar el pod calico-node.

  1. Extraiga el sysdig-admission-controller-webhook del sistema.
  2. Modifique sysdig-admission-controller-webhook y cambie el tiempo de espera para que sea inferior a 2 segundos.
  3. Modifique el sysdig-admission-controller-webhook para que se alcance a los espacios de nombres adecuados y evite los espacios de nombres críticos del sistema como, por ejemplo, calico-system.
  4. Cordon el nuevo nodo pero no lo drene. Suprima el pod de VPN y espere a que se inicie en otro trabajador. Descorche el nodo.

Después de realizar cualquiera de los métodos alternativos anteriores, el pod calico-node se puede iniciar correctamente.