Por que o meu nó trabalhador mostra um erro NetworkUnavailable ?

Resolva problemas relacionados à integridade dos nós do serviço “ Calico ” e problemas de rede.

Nuvem privada virtual Infraestrutura clássica Satellite

Quando você atualiza seus nós de mestrado ou trabalhador, seus nós do trabalhador entram em um estado Node network unavailable.

Seus nós do trabalhador podem entrar em um estado NetworkUnavailable ou Node network unavailable sempre que o pod calico-node for encerrado. Isso pode ocorrer durante uma atualização do patch Calico, mas não deve afetar a disponibilidade do aplicativo.

Quando o Calico é atualizado, o taint node.kubernetes.io/network-unavailable:NoSchedule é adicionado ao seu nó do trabalhador e a condição Node network unavailable torna-se True. Ambas as condições são liberadas quando Calico reinicia, o que tipicamente leva apenas alguns segundos.

Enquanto isso acontece, você pode ver uma mensagem de erro semelhante ao exemplo a seguir.

[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

Às vezes, o reinício pode demorar mais. Em quase todos os casos, o reinício é rápido o suficiente para evitar problemas de rede do nó do trabalhador. No entanto, há situações em que um reinício do Calico é atrasado e, assim, pode haver interrupções de rede. Para esses casos, a mácula indisponível da rede do nó e condição são projetadas para manter novos apps de serem implementados para o novo nó até que o Calico e o nó sejam corrigidos. As atualizações do Calico são roladas de maneira muito controlada, de modo a minimizar o impacto geral do aplicativo deve haver um problema de nó.

Monitore o estado do Node network unavailable com IBM Cloud Monitoring

Ao usar serviços para monitorar aplicativos como IBM Cloud Monitoring, é possível configurar alertas para quando um nó do trabalhador entrar em um estado Node network unavailable, e contar cada vez que isso acontecer. Também é possível configurar limites e ajustar seus alertas para permitir quando os nós do trabalhador estiverem em um estado Node network unavailable durante correções da rotina Calico.

Ao configurar os alertas IBM Cloud Monitoring, leve em consideração os seguintes cenários.

  • Um alerta Node network unavailable pode se tornar um problema quando um pod calico-node falhar ao atingir um estado Running, e sua contagem de reinício de container continua a aumentar.
  • Um nó do trabalhador permanece no estado Node network unavailable por um longo período de tempo.

Depois de uma atualização ou substituição do trabalhador, às vezes o pod calico-node ainda não inicia em Red Hat OpenShift VPC Cluster. O pod calico_node pode ficar preso em um estado onde não é possível iniciar em um cluster de Red Hat OpenShift VPC. Esta não é uma questão sobre IKS ou clusters Classic. Isso pode ocorrer quando você tem o sysdig-admission-controller-webhook instalado e tente fazer uma atualização ou substituição do trabalhador. Isso acontece porque:

  1. O pod cliente VPN se muda para o novo trabalhador como está começando.
  2. calico-node no novo trabalhador começa, mas fica preso porque faz uma chamada apiserver e tempos fora após 2 seconds minutos.
  3. A chamada apiserver então tenta chamar o webhook que falha porque o pod cliente VPN estava tentando iniciar no novo nó. O nó VPN não pode fazê-o com sucesso porque calico-node ainda não foi iniciado.

Em resumo, a inicialização do pod calico-node depende do webhook funcionando; o webhook depende do pod cliente VPN; e o pod do cliente VPN depende de calico-node iniciando. O sistema está preso em uma dependência circular. Se você é capaz de reunir logs a partir de um pod calico-node implementado com sucesso, você pode ver um erro como este:

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)

Workarounds para calico-node

Você pode usar um dos seguintes métodos para trabalhar em torno do assunto e obter o pod calico-node rodando novamente.

  1. Remova o sysdig-admission-controller-webhook do sistema.
  2. Modifique o sysdig-admission-controller-webhook e altere o tempo limite para ser menor que 2 seconds.
  3. Modifique o sysdig-admission-controller-webhook para escoá-lo para os namespaces apropriados, e evite espaços de nomes críticos do sistema como calico-system.
  4. Cordão o novo nó mas não o drene. Exclua a poda VPN e aguarde que ela comece em outro trabalhador. Descortem o nó.

Após realizar qualquer uma das alternativas de trabalho anteriores, o pod calico-node pode iniciar com sucesso.