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 ao iniciar pods, erros ao extrair imagens de contêiner do Windows, problemas de conectividade de rede ou falha ao iniciar nós.

Use este documento para diagnosticar e resolver esses problemas comuns e manter seus aplicativos baseados no Windows em execução de forma 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 referenciamos no Google Cloud conteúdo, 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.

Problemas de nó containerd

Para informações sobre como resolver problemas se você usar 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 que os pods sejam iniciados.

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 mais antiga do Windows que é incompatível com a versão do Windows Server do nó host.

Resolução

Crie imagens de contêiner usando imagens de 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 imagens 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 fazer o download 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 entre os núcleos. Portanto, os tipos de máquina com mais núcleos reduzem o tempo total de extração.
  • Otimizar camadas de imagem: para melhorar o armazenamento em cache da camada do Docker e aumentar a probabilidade de sucesso das 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.
  • Usar 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 descontinua periodicamente famílias de imagens mais antigas do Windows Server quando o suporte do fornecedor termina. Essa descontinuação bloqueia 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 que esteja disponível e seja compatível. É possível encontrar a data de término do suporte para imagens de nós do Windows do GKE usando o comando gcloud container get-server-config, conforme descrito em Mapeamento de 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 que usa 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, você poderá aumentar o número de nós.

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

Programar rapidamente vários contêineres do Windows em um único nó pode sobrecarregar o gerador de eventos do ciclo de vida do pod (PLEG, na sigla em inglês).

Sintomas

  • Os nós do Windows entram em um status NotReady.
  • 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 recorrências:

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

TerminationGracePeriod inconsistente

Diferenças entre os timers de desligamento do contêiner do Windows e as configurações de período de carência do Kubernetes podem fazer com que os contêineres sejam encerrados inesperadamente.

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 é diferente 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 de registro locais 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, na sigla em inglês) entre a rede de contêineres do Windows Server e Google Cloud as redes podem causar pacotes descartados.

Sintomas

Os aplicativos em execução em contêineres do Windows Server apresentam falhas de conectividade de rede ou pacotes descartados.

Causa

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

Resolução

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

Problemas de inicialização de nós

Novas instâncias do Windows Server podem falhar ao concluir scripts de inicialização ou registrar-se 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, revise a saída da porta serial do nó: serial port

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 de host (HNS, na sigla em inglês) são reprocessadas.

Sintomas

Os serviços ficam intermitentemente inacessíveis em 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 reinicializar 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, poderá haver um atraso significativo no processamento delas, com duração de cerca de 30 segundos por regra. Durante esse atraso de sincronização, os serviços ficam intermitentemente inacessíveis em pods em execução nesse nó. Para mais informações, 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 é substancialmente melhorado 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 o problema na documentação, consulte Receber suporte para mais ajuda, incluindo orientações sobre os seguintes tópicos: