¿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 unavailablepuede convertirse en un problema cuando un podcalico-nodeno puede alcanzar un estadoRunningy su recuento de reinicios de contenedor sigue aumentando. - Un nodo trabajador permanece en estado
Node network unavailabledurante 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:
- El pod de cliente VPN se mueve al nuevo trabajador a medida que se inicia.
calico-nodeen el nuevo trabajador se inicia, pero se bloquea porque realiza una llamadaapiservery excede el tiempo de espera después de 2 segundos.- A continuación, la llamada
apiserverintenta 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 porquecalico-nodeno 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.
- Extraiga el
sysdig-admission-controller-webhookdel sistema. - Modifique
sysdig-admission-controller-webhooky cambie el tiempo de espera para que sea inferior a 2 segundos. - Modifique el
sysdig-admission-controller-webhookpara que se alcance a los espacios de nombres adecuados y evite los espacios de nombres críticos del sistema como, por ejemplo,calico-system. - 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.