Instalei o kubernetes em um servidor de nó único usando kubeadm. Descobri que, ao realizar a instalação em uma ordem específica, tudo funciona bem. Isso inclui os principais componentes do sistema kube (servidor API, proxy, agendador, etcd, etc.) que foram ativados e executados primeiro (exceto coredns), após o qual o plug-in cilium CNI foi instalado usando o helm para rede (resultando no funcionamento do coredns).
Após esta instalação, pude instalar e usar outros serviços como o operador de GPU da NVIDIA e o kubeflow com sucesso. No entanto, depois de reiniciar, descobri que os diferentes componentes entram em um estado de desligamento do loop de travamento.
Acho que isso tem algo a ver com a ordem em que os diferentes recursos estão sendo inicializados e com a duração de vários tempos limite diferentes. Existe uma maneira de definir uma ordem para os diferentes componentes iniciarem na inicialização? Ou possivelmente configurar um tempo limite padrão apropriado ou comportamento de travamento dos pods?
Provavelmente há um efeito dominó acontecendo aqui, onde a falha de um componente resulta em outro, o que leva a tempos de espera cada vez maiores e, em última análise, a um cluster que não responde.
Para obter informações adicionais, persisti as regras do iptables para que sejam aplicadas na inicialização. Além disso, normalmente todos os componentes principais entram no estado de execução, exceto o agendador kube, que permanece em back-off do loop de travamento. Então os outros componentes também começam a falhar, no que parece ser um efeito dominó.
Até agora, tentei principalmente atualizar os arquivos de manifesto em /etc/kubernetes/manifests/ para usar vários tempos limites e failThresholds diferentes para os pods do sistema kubernetes, no entanto, isso não pareceu resolver o problema. Eu poderia replicar o comportamento de reinicialização do servidor primeiro parando o serviço kubelet e destruindo todos os pods/contêineres em execução e, em seguida, reiniciando o kubelet.
Responder1
Acontece que este problema é muito semelhante ao descrito neste GitHubemitir. Essencialmente, sem especificar a SystemdCgroup = trueopção para meu tempo de execução CRI containerd (que era onvidiatempo de execução do contêinerem vez do padrão runc), os pods continuariam travando inexplicavelmente. Isso estava acontecendo devido a uma violação da regra de gravador único de cgroups, já que o driver padrão para gerenciar cgroups cgroupfsnão é interoperável com systemd. Você pode ver odocumentaçãopara mais detalhes. Também inclui uma especificação completa da configuração do plugin CRIaqui.
Outros recursos relevantes em contêineres são: