Resolver problemas em pools de nós do Windows Server

Ao executar pools de nós do Windows Server no Google Kubernetes Engine (GKE), você pode encontrar problemas como falha na inicialização de pods, erros ao extrair imagens de contêiner do Windows, problemas de conectividade de rede ou falha na inicialização de nós.

Use este documento para diagnosticar e resolver esses problemas comuns e manter seus aplicativos baseados no Windows funcionando de maneira confiável.

Essas informações são importantes para administradores e operadores de plataforma que gerenciam clusters do GKE com pools de nós do Windows e para desenvolvedores de aplicativos que implantam e executam aplicativos baseados no Windows no GKE. Para mais informações sobre as funções comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Para orientações mais gerais, consulte a documentação do Kubernetes sobre depuração de pods e serviços (links em inglês).

Problemas de nó containerd

Para informações sobre como resolver problemas se você usa uma imagem de nó do containerd, consulte Problemas em pools de nós do Windows Server.

Falha ao iniciar pods do Windows

Incompatibilidades entre a imagem de base e as versões do SO host do Windows Server podem impedir a inicialização dos pods.

Sintomas

  • Falha ao iniciar pods do Windows.
  • O nó informa o status NotReady.

Causa

A imagem do contêiner foi criada em uma imagem de base do Windows mais antiga que é incompatível com a versão do Windows Server do nó host.

Resolução

Crie as imagens de contêiner usando imagens base do Windows que incluam atualizações do Windows de março de 2020 ou mais recentes. Para mais informações sobre a compatibilidade de contêineres da Microsoft, consulte a documentação da Microsoft sobre o problema de incompatibilidade de contêineres do Windows Server de fevereiro de 2020.

Erros de extração de imagem

As imagens de contêiner do Windows Server costumam ser significativamente maiores do que as do Linux, o que pode levar a tempos limite.

Sintomas

  • Mensagens de erro, como Failed to pull image ou context cancelled.
  • Os pods mostram o status ErrImagePull.

Causa

As imagens de contêiner do Windows Server e as camadas individuais de que elas são compostas podem ser grandes. O tamanho delas pode fazer com que o agente kubelet atinja o tempo limite e falhe ao baixar e extrair as camadas do contêiner.

Resolução

Para resolver essas falhas de extração de imagem, tente as seguintes soluções:

  • Aumentar a CPU do nó: a extração de contêineres é executada em paralelo em núcleos. Portanto, tipos de máquina com mais núcleos reduzem o tempo geral de extração.
  • Otimize as camadas de imagem: para melhorar o armazenamento em cache de camadas do Docker e aumentar a probabilidade de sucesso das novas tentativas de extração de imagens, divida as camadas do aplicativo em camadas menores. Para mais informações, consulte Imagens e camadas na documentação do driver de armazenamento do Docker.
  • Use extrações manuais: conecte-se aos nós do Windows Server e execute manualmente o comando docker pull nas imagens de contêiner antes de criar os pods.

Para mais orientações gerais, consulte Resolver problemas de extração de imagens.

A família de imagens atingiu o fim da vida útil

O GKE periodicamente descontinua famílias de imagens mais antigas do Windows Server quando o suporte do fornecedor termina. Essa descontinuação impede a criação de pools de nós com essas imagens.

Sintomas

Ao criar um pool de nós com uma imagem do Windows, você recebe um erro semelhante ao seguinte:

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer
versions are still available.

Causa

A família de imagens do Windows Server selecionada não é mais compatível com o GKE.

Resolução

Escolha uma imagem do Windows disponível e compatível. Para encontrar a data de término do suporte para imagens de nós do Windows no GKE, use o comando gcloud container get-server-config, conforme descrito em Como mapear versões do GKE e do Windows.

Tempo limite durante a criação do pool de nós

A inicialização de um grande número de nós do Windows Server simultaneamente pode causar tempos limite.

Sintomas

As operações de criação de pool de nós atingem o tempo limite antes de serem concluídas.

Causa

A criação do pool de nós pode atingir o tempo limite se você estiver criando um grande número de nós (por exemplo, 500) e for o primeiro pool de nós no cluster a usar uma imagem do Windows Server.

Resolução

Reduza a contagem inicial de nós ao criar o pool de nós. Depois que o pool de nós for criado, será possível aumentar o número de nós.

Os nós do Windows se tornam NotReady com o erro: PLEG is not healthy

A programação rápida de vários contêineres do Windows em um único nó pode sobrecarregar o gerador de eventos de ciclo de vida do pod (PLEG).

Sintomas

  • Os nós do Windows entram em um status NotReady.
  • Os eventos ou registros mostram uma mensagem de erro PLEG is not healthy.

Causa

Um problema conhecido do Kubernetes ocorre quando vários pods são iniciados muito rapidamente em um único nó do Windows.

Resolução

Para se recuperar de falhas do PLEG e evitar que elas ocorram novamente:

  • Reinicie o nó afetado do Windows Server.
  • Limite a criação de pods do Windows a no máximo um pod a cada 30 segundos.

Inconsistente TerminationGracePeriod

Diferenças entre os timers de desligamento de contêineres do Windows e as configurações de período de grace do Kubernetes podem causar o encerramento inesperado dos contêineres.

Sintomas

Os contêineres são encerrados à força pelo Windows antes que a duração configurada no campo TerminationGracePeriodSeconds expire.

Causa

O tempo limite interno do sistema Windows para o contêiner difere do período de carência especificado no manifesto do pod do Kubernetes.

Resolução

Modifique o tempo limite do contêiner do Windows editando as chaves do registro local do contêiner no tempo de build da imagem. Alinhe o campo TerminationGracePeriodSeconds no manifesto do pod de acordo.

Problemas de conectividade de rede

Incompatibilidades de tamanho da unidade máxima de transmissão (MTU) entre a rede de contêineres do Windows Server e as redes do Google Cloud podem causar pacotes descartados.

Sintomas

Os aplicativos executados em contêineres do Windows Server sofrem falhas de conectividade de rede ou perda de pacotes.

Causa

A rede de contêineres do Windows Server geralmente pressupõe uma MTU de rede de 1500, que é incompatível com a MTU de 1460 do Google Cloud.

Resolução

Configure a MTU da interface de rede do contêiner e a MTU da interface de rede do nó do Windows Server como 1460 ou menos. Para mais informações, consulte problemas conhecidos dos contêineres do Windows na documentação do Compute Engine.

Problemas de inicialização de nós

Novas instâncias do Windows Server podem não concluir os scripts de inicialização ou não se registrar no plano de controle.

Sintomas

Os nós do Windows Server não são inicializados ou não conseguem entrar no cluster.

Causa

Erros durante a inicialização do nó impedem que ele seja iniciado ou entre no cluster.

Resolução

Para identificar quais erros de inicialização podem estar causando o problema, analise a saída da porta serial do nó:

gcloud compute instances get-serial-port-output NODE_NAME \
    --zone=COMPUTE_ZONE

Substitua:

Serviços intermitentemente inacessíveis em nós do Windows com cluster executando a versão 1.24 ou anterior

Em clusters que executam a versão 1.24 ou anterior, a reinicialização do componente kube-proxy cria atrasos temporários no roteamento de rede enquanto as regras do balanceador de carga do serviço de rede (HNS) do host são reprocessadas.

Sintomas

Os serviços ficam intermitentemente inacessíveis para pods em execução em nós do Windows.

Causa

Para clusters do GKE que executam a versão 1.24 ou anterior, se um evento reiniciar o componente kube-proxy em um nó do Windows, por exemplo, inicialização de nó, upgrade de nó ou reinicialização manual, o componente precisará sincronizar e recriar todas as regras do balanceador de carga do HNS. Se o cluster tiver um grande número dessas regras, pode haver um atraso significativo no processamento delas, que dura cerca de 30 segundos por regra. Durante esse atraso na sincronização, os serviços ficam intermitentemente inacessíveis para os pods em execução nesse nó. Para saber mais, consulte o problema original no GitHub.

Resolução

Faça upgrade do plano de controle do cluster para a versão 1.25 ou mais recente. Esse comportamento foi melhorado significativamente em versões mais recentes, conforme detalhado na solicitação de pull no GitHub.

A seguir

  • Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: