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 unavailablepode se tornar um problema quando um podcalico-nodefalhar ao atingir um estadoRunning, e sua contagem de reinício de container continua a aumentar. - Um nó do trabalhador permanece no estado
Node network unavailablepor 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:
- O pod cliente VPN se muda para o novo trabalhador como está começando.
calico-nodeno novo trabalhador começa, mas fica preso porque faz uma chamadaapiservere tempos fora após 2 seconds minutos.- A chamada
apiserverentã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 porquecalico-nodeainda 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.
- Remova o
sysdig-admission-controller-webhookdo sistema. - Modifique o
sysdig-admission-controller-webhooke altere o tempo limite para ser menor que 2 seconds. - Modifique o
sysdig-admission-controller-webhookpara escoá-lo para os namespaces apropriados, e evite espaços de nomes críticos do sistema comocalico-system. - 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.