Nesta página, você aprenderá a criar um cluster do Google Kubernetes Engine (GKE) com pools de nós executando o Microsoft Windows Server. Use contêineres do Windows Server com esse cluster. No momento, os contêineres do Microsoft Hyper-V não são compatíveis. Assim como os contêineres Linux, os contêineres do Windows Server oferecem isolamento de processo e de namespace.
Um nó do Windows Server requer mais recursos do que um nó típico do Linux. Os nós do Windows Server precisam dos recursos extras para executar o sistema operacional Windows e os componentes do Windows Server que não podem ser executados em contêineres. Como os nós do Windows Server exigem mais recursos, os recursos alocáveis são menores do que seriam com os nós do Linux.
Como criar um cluster usando os pools de nós do Windows Server
Nesta seção, você criará um cluster que usa um contêiner do Windows Server.
Para criar esse cluster, você precisa concluir as seguintes tarefas:
- Escolher a imagem de nó do Windows Server.
- Atualizar e configurar
gcloud
. - Criar um cluster e pools de nós.
- Receba as credenciais
kubectl
. - Aguarde a inicialização do cluster.
Escolher a imagem de nó do Windows Server
Para serem executadas no GKE, as imagens de nó de contêiner do Windows Server precisam ser criadas na versão 2019 (LTSC), na versão 20H2 (SAC) ou na versão 2022 (LTSC) do Windows Server. Um único cluster pode ter vários pools de nós do Windows Server usando diferentes versões do Windows Server, mas cada pool de nós individual só pode usar uma versão do Windows Server.
Considere o seguinte ao escolher a imagem do nó:
- Tempo de suporte:
- O tempo de suporte para uma imagem de nó do Windows Server está sujeito ao tempo de suporte fornecido pela Microsoft, conforme descrito na Política de suporte para imagens do SO.
Encontre a data de término do suporte para imagens de nó do GKE do Windows usando o comando
gcloud container get-server-config
, conforme descrito na seção Como mapear versões do GKE e do Windows. - As versões do SAC são compatíveis apenas com a Microsoft por 18 meses após o lançamento inicial. Se você escolher o SAC para o tipo de imagem do pool de nós, mas não fizer upgrade dele para versões mais recentes do GKE que segmentam versões mais recentes do SAC, não será possível criar novos nós no pool de nós quando o ciclo de vida do suporte para a versão do SAC termina. Saiba mais sobre a compatibilidade do Google com o sistema operacional Windows Server. Recomendamos o uso do LTSC devido ao ciclo de vida maior.
- Não escolha o SAC se você registrar seu cluster do GKE no canal de lançamento estável. Como a versão SAC é compatível com a Microsoft só por 18 meses, há um risco de que a imagem do pool de nós do SAC se torne incompatível durante a disponibilidade da versão estável do GKE.
- O tempo de suporte para uma imagem de nó do Windows Server está sujeito ao tempo de suporte fornecido pela Microsoft, conforme descrito na Política de suporte para imagens do SO.
Encontre a data de término do suporte para imagens de nó do GKE do Windows usando o comando
- Compatibilidade e complexidade de versões:
- Escolha SAC somente se for possível fazer upgrade do pool de nós e dos contêineres em execução nele regularmente. O GKE atualiza periodicamente a versão do SAC usada para pools de nós do Windows em novos lançamentos do GKE. Portanto, escolher o SAC para o tipo de imagem do pool de nós exige que você recrie os contêineres com mais frequência.
- Se você não souber qual tipo de imagem do Windows Server usar, recomendamos escolher o Windows Server LTSC para evitar problemas de incompatibilidade de versão ao fazer upgrade do pool de nós. Para mais informações, consulte Canais de serviço do Windows Server: LTSC e SAC na documentação da Microsoft.
- O Windows Server Core e o Nano Server (em inglês) podem ser usados como uma imagem de base para seus contêineres.
- Os contêineres do Windows Server têm requisitos importantes de compatibilidade de versão:
- Os contêineres do Windows Server criados para LTSC não são executados em nós SAC e vice-versa.
- Os contêineres do Windows Server criados para uma versão LTSC ou SAC específica não são executados em outras versões LTSC ou SAC sem serem recriados para segmentar a outra versão.
- Criar suas imagens de contêiner do Windows Server como imagens de multiarquiteturas que podem segmentar várias versões do Windows Server pode ajudar você a gerenciar essa complexidade de controle de versão.
- Novos recursos:
- Os novos recursos do Windows Server geralmente são introduzidos nas versões do SAC primeiro. Por isso, a nova funcionalidade do GKE para Windows pode ser introduzida primeiro nos pools de nós do SAC.
- Considere o SAC se você depende de recursos que ainda não estão disponíveis na versão LTSC.
Ambiente de execução do contêiner:
Para as imagens de nó LTSC e SAC do Windows Server, o ambiente de execução do contêiner pode ser Docker ou Containerd. Para a versão 1.21.1-gke.2200 do nó do GKE e posterior, recomendamos o uso do ambiente de execução do Containerd. Para mais informações, consulte Imagens de nó.
Atualizar e configurar gcloud
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ativar a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa,
instale e, em seguida,
inicialize a
CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update
.
- Verifique se você tem a permissão correta para criar clusters. Você precisa ser, no mínimo, um Administrador de clusters do Kubernetes Engine.
Criar um cluster e pools de nós
Para executar contêineres do Windows Server, o cluster precisa ter pelo menos um pool de nós do Windows e um do Linux. Não é possível criar um cluster usando apenas um pool de nós do Windows Server. O pool de nós do Linux é necessário para executar complementos de cluster críticos.
Devido à importância, recomendamos ativar o escalonamento automático para garantir que o pool de nós do Linux tenha capacidade suficiente para executar complementos de cluster.
gcloud
Crie um cluster com os seguintes campos:
gcloud container clusters create CLUSTER_NAME \
--enable-ip-alias \
--num-nodes=NUMBER_OF_NODES \
--cluster-version=VERSION_NUMBER \
--release-channel CHANNEL
Substitua:
CLUSTER_NAME
: o nome escolhido para o cluster.--enable-ip-alias
ativa o IP do alias. O IP do alias é necessário para os nós do Windows Server. Para saber mais sobre os benefícios, consulte Noções básicas sobre o roteamento de contêiner nativo com IPs de alias.NUMBER_OF_NODES
: o número de nós do Linux que você cria. Forneça recursos de computação suficientes para executar complementos do cluster. Este é um campo opcional e, se omitido, usa o valor padrão3
.VERSION_NUMBER
: a versão do cluster específica que você quer usar (precisa ser 1.16.8-gke.9 ou superior). Se você não especificar um canal de lançamento, o GKE registrará o cluster no canal de lançamento mais consolidado em que essa versão está disponível.CHANNEL
: o canal de lançamento para registrar o cluster (pode serrapid
,regular
,stable
ouNone
. Por padrão, o cluster é inscrito no canal de lançamentoregular
, a menos que pelo menos uma das sinalizações a seguir seja especificada:--cluster-version
,--release-channel
,--no-enable-autoupgrade
, e--no-enable-autorepair
. EspecifiqueNone
ao escolher uma versão do cluster quando você não quiser que ele seja registrado em um canal de lançamento.
Crie o pool de nós do Windows Server com os seguintes campos:
gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--image-type=IMAGE_NAME \
--no-enable-autoupgrade \
--machine-type=MACHINE_TYPE_NAME \
--windows-os-version=WINDOWS_OS_VERSION
Substitua:
NODE_POOL_NAME
: o nome escolhido para o pool de nós do Windows Server;CLUSTER_NAME
: o nome do cluster que você criou acima.IMAGE_NAME
: é possível especificar um dos seguintes valores:WINDOWS_LTSC_CONTAINERD
: Windows Server LTSC com containerd. Esse é o tipo de imagem do SO para o Windows Server 2022 e o Windows Server 2019.WINDOWS_SAC_CONTAINERD
: SAC do Windows Server com containerd (incompatível após 9 de agosto de 2022)WINDOWS_LTSC
: Windows Server LTSC com DockerWINDOWS_SAC
: SAC do Windows Server com Docker (incompatível após 9 de agosto de 2022)
Para mais informações sobre essas imagens de nó, consulte a seção Escolher sua imagem de nó do Windows.
--no-enable-autoupgrade
desativa o upgrade automático do nó. Revise Como fazer o upgrade de pools de nós do Windows Server antes de ativar.MACHINE_TYPE_NAME
: define o tipo de máquina.n1-standard-2
é o tipo de máquina mínimo recomendado, já que os nós do Windows Server exigem recursos adicionais. Não há compatibilidade com os tipos de máquinaf1-micro
eg1-small
. O faturamento varia de acordo com cada tipo de máquina. Para mais informações, consulte a Tabela de preços do tipo de máquina.WINDOWS_OS_VERSION
: define a versão do SO Windows que será usada para o tipo de imagemWINDOWS_LTSC_CONTAINERD
. Essa é uma sinalização é opcional. Quando não for especificada, a versão padrão do SO usada será LTSC2019. Defina o valor comoltsc2022
para criar um pool de nós do Windows Server 2022. Defina o valor comoltsc2019
para criar um pool de nós do Windows Server 2019.
O exemplo a seguir mostra como criar um pool de nós do Windows Server 2022:
gcloud container node-pools create node_pool_name \
--cluster=cluster_name \
--image-type=WINDOWS_LTSC_CONTAINERD \
--windows-os-version=ltsc2022
O exemplo a seguir mostra como atualizar um pool de nós atual do Windows para usar a imagem do SO do Windows Server 2022:
gcloud container node-pools create node_pool_name \
--cluster=cluster_name \
--windows-os-version=ltsc2022
Console
Acesse a página Google Kubernetes Engine no console do Google Cloud.
Clique em add_box Criar.
Na seção Princípios básicos do cluster, conclua o seguinte:
- Insira o Nome do cluster.
- Em Tipo de local, selecione a região ou zona pretendida para o cluster.
- Em Versão do plano de controle, selecione um Canal de lançamento ou especifique uma Versão estática. Ela precisa ser 1.16.8-gke.9 ou superior.
No painel de navegação, em Pools de nós, clique em default-pool para criar o pool de nós do Linux. Ao configurar esse pool de nós, forneça recursos de computação suficientes para executar complementos de cluster. Também é necessário ter uma cota de recursos disponível para os nós e os respectivos recursos, como rotas de firewall.
Na parte superior da página, clique em add_box Adicionar pool de nós para criar seu pool de nós do Windows Server.
Na seção Detalhes do pool de nós, preencha o seguinte:
- Insira um Nome para o pool de nós.
- Para nós de versão estática, escolha a Versão do nó.
- Digite o Número de nós a serem criados no pool de nós.
No painel de navegação, em Pools de nós, clique em Nós.
Na lista suspensa Tipo de imagem, selecione uma das seguintes imagens de nó:
- Windows Long Term Servicing Channel com o Docker
- Windows Long Term Servicing Channel com Containerd
- Windows Semi-Annual Channel com Docker
- Windows Semi-Annual Channel com Containerd
Para mais informações, consulte a seção Escolher sua imagem de nó do Windows.
Escolha a Configuração da máquina padrão para usar nas instâncias.
n1-standard-2
é o tamanho mínimo recomendado, já que os nós do Windows Server exigem recursos adicionais. Os tipos de máquinaf1-micro
eg1-small
não são compatíveis. O faturamento varia de acordo com cada tipo de máquina. Para mais informações, consulte a tabela de preços do tipo de máquina.
No painel de navegação, selecione o nome do pool de nós do Windows Server. Isso retorna à página Detalhes do pool de nós.
- Em Automação, desmarque a caixa de seleção Ativar upgrade automático do nós. Revise a seção Como fazer o upgrade de pools de nós do Windows Server antes de ativar o upgrade automático.
No painel de navegação, em Cluster, selecione Rede.
- Em Opções de rede avançadas, verifique se a opção Ativar roteamento de tráfego nativo de VPC (usa IP do alias) está selecionada. O IP do alias é necessário para os nós do Windows Server. Para saber mais sobre os benefícios, consulte Noções básicas sobre o roteamento de contêiner nativo com IPs de alias.
Clique em Criar.
Terraform
Para criar um cluster do GKE Standard e um pool de nós do Windows Server usando o Terraform, consulte o exemplo a seguir:
Este exemplo usa o LTSC do Windows Server com containerd. Esse é o tipo de imagem do SO para o Windows Server 2022 e o Windows Server 2019. Para mais informações sobre imagens de nó, consulte Escolher a imagem de nó do Windows.
Para saber mais como usar o Terraform, consulte o Suporte do Terraform para GKE.
Depois de criar um pool de nós do Windows Server, o cluster entra em um estado
RECONCILE
por vários minutos durante a atualização do plano de controle.
Receber credenciais do kubectl
Use o comando get-credentials
para permitir que kubectl
funcione com o cluster que você criou.
gcloud container clusters get-credentials CLUSTER_NAME
Para mais informações sobre o comando get-credentials
, consulte a documentação get-credentials do SDK.
Aguardar a inicialização do cluster
Antes de usar o cluster, aguarde alguns segundos até que windows.config.common-webhooks.networking.gke.io
seja criado. Esse webhook adiciona tolerâncias de programação aos pods criados com o seletor de nós kubernetes.io/os: windows
para garantir que eles sejam executados nos nós do Windows Server. Ele também valida o pod para garantir que ele use apenas recursos compatíveis com o Windows.
Para garantir que o webhook seja criado, execute o seguinte comando:
kubectl get mutatingwebhookconfigurations
A saída precisa mostrar o webhook em execução:
NAME CREATED AT
windows.config.common-webhooks.networking.gke.io 2019-12-12T16:55:47Z
Agora que você tem um cluster com dois pools de nós (um Linux e um Windows), é possível implantar um aplicativo do Windows.
Como mapear versões do GKE e do Windows
A Microsoft lança novas versões do SAC aproximadamente a cada seis meses e novas versões do LTSC a cada dois ou três anos. Essas novas versões geralmente estão disponíveis em novas versões secundárias do GKE. Em uma versão secundária do GKE, as versões LTSC e SAC geralmente permanecem fixas.
Para ver o mapeamento de versões entre as versões do GKE e do Windows Server, use o comando gcloud beta container get-server-config
:
gcloud beta container get-server-config
O mapeamento de versão é retornado no campo windowsVersionMaps
da
resposta. Para filtrar a resposta e ver o mapeamento de versões específicas
do GKE no cluster, execute as etapas a seguir em um
shell do Linux ou no Cloud Shell.
Configure as variáveis a seguir:
CLUSTER_NAME=CLUSTER_NAME NODE_POOL_NAME=NODE_POOL_NAME ZONE=COMPUTE_ZONE
Substitua:
CLUSTER_NAME
: o nome do cluster.NODE_POOL_NAME
: o nome do pool de nós do Windows Server.COMPUTE_ZONE
: a zona do Compute para o cluster.
Consiga a versão do pool de nós e armazene-a na variável
NODE_POOL_VERSION
:NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \ --cluster $CLUSTER_NAME --zone $ZONE --format="value(version)"`
Consiga as versões do Windows Server para
NODE_POOL_VERSION
:gcloud beta container get-server-config \ --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"
A resposta será semelhante a:
windowsVersionMaps: 1.18.6-gke.6601: windowsVersions: - imageType: WINDOWS_SAC osVersion: 10.0.18363.1198 supportEndDate: day: 10 month: 5 year: 2022 - imageType: WINDOWS_LTSC osVersion: 10.0.17763.1577 supportEndDate: day: 9 month: 1 year: 2024
Consiga a versão do Windows Server para o tipo de imagem
WINDOWS_SAC
:gcloud beta container get-server-config \ --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \ --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_SAC" \ --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"
O resultado será assim:
10.0.18363.1198
Como fazer upgrade de pools de nós do Windows Server
Os requisitos de compatibilidade da versão do contêiner do Windows Server significam que suas imagens de contêiner precisam ser recriadas para corresponder à versão do Windows Server de uma nova versão do GKE antes de fazer upgrade dos pools de nós.
Para garantir que suas imagens de contêiner permaneçam compatíveis com seus nós, recomendamos que você verifique o mapeamento de versão e crie suas imagens de contêiner do Windows Server como imagens de multiarquiteturas que podem segmentar várias versões do Windows Server. Em seguida, atualize as implantações de contêiner para segmentar as imagens de multiarquitetura que funcionarão na versão atual e seguinte do GKE, antes de invocar manualmente um upgrade do pool de nós do GKE. Os upgrades manuais do pool de nós precisam ser executados regularmente porque os nós não podem ter mais de duas versões secundárias além da versão do plano de controle.
Recomendamos que você se inscreva para receber notificações de upgrade usando o Pub/Sub para receber atualizações proativamente sobre novas versões do GKE e as versões do sistema operacional Windows que elas usam.
Recomendamos ativar os upgrades automáticos de nós somente se você criar continuamente imagens de contêiner do Windows Server de multiarquiteturas que visam as versões mais recentes do Windows Server, especialmente se estiver usando o SAC do Windows Server como o tipo de imagem do nó. Os upgrades automáticos de nós têm menos probabilidade de causar problemas com o tipo de imagem de nó LTSC do Windows Server, mas ainda há risco de encontrar problemas de incompatibilidade de versão.
Atualizações do Windows
As atualizações do Windows estão desativadas para os nós do Windows Server. As atualizações automáticas podem causar reinicializações do nó em momentos imprevisíveis, e as atualizações do Windows instaladas após o início de um nó são perdidas quando o nó é recriado pelo GKE. O GKE disponibiliza atualizações do Windows atualizando periodicamente as imagens de nó do Windows Server usadas em novas versões do GKE. Pode haver um atraso entre o momento em que as atualizações do Windows são lançadas pela Microsoft e o momento em que ficam disponíveis no GKE. Quando atualizações essenciais de segurança são lançadas, o GKE atualiza as imagens de nó do Windows Server o mais rápido possível.
Controle como os pods e serviços do Windows se comunicam
É possível controlar como os pods e serviços do Windows se comunicam usando políticas de rede.
É possível ter um contêiner do Windows Server em clusters com a
política de rede ativada no GKE versão 1.22.2 e posterior. Esse recurso está disponível para clusters que usam os tipos de imagem de nó WINDOWS_LTSC
ou WINDOWS_LTSC_CONTAINERD
.
Se os planos de controle ou nós estiverem executando versões anteriores, será possível migrar
os pools de nós para uma versão compatível com a política de rede. Para isso, faça upgrade dos pools
de nós e do plano de controle para a versão 1.22.2 ou mais recente do GKE.
Essa opção só estará disponível se você tiver criado o cluster com
o flag --enable-dataplane-v2
.
Depois de ativar a política de rede, todas as políticas configuradas anteriormente, incluindo as que não funcionavam em contêineres do Windows Server antes de você ativar o recurso, ficam ativas.
Alguns clusters não podem ser usados com contêineres do Windows Server em clusters com a política de rede ativada. Para mais informações, consulte a seção de limitações.
Como visualizar e consultar registros
A geração de registros é ativada automaticamente nos clusters do GKE. É possível ver os registros dos contêineres e de outros serviços nos nós do Windows Server usando o monitoramento do Kubernetes Engine.
Veja a seguir um exemplo de filtro para receber o registro do contêiner:
resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"
Como acessar um nó do Windows Server usando o protocolo de computador remoto (RDP, na sigla em inglês)
Conecte-se a um nó do Windows Server no cluster usando RDP. Para instruções sobre como se conectar, consulte Como se conectar a instâncias do Windows na documentação do Compute Engine.
Como criar imagens de multiarquiteturas
Crie manualmente as imagens de multiarquiteturas ou use um builder do Cloud Build. Para instruções, consulte Como criar imagens de multiarquiteturas do Windows.
Como usar o gMSA
As etapas a seguir mostram como usar uma conta de serviço gerenciado de grupo (gMSA) com seus pools de nós do Windows Server.
Como configurar nós do Windows Server no cluster para ingressar automaticamente no domínio do AD. Para instruções, consulte Configurar nós do Windows Server para ingressar automaticamente em um domínio do Active Directory.
Crie e conceda acesso de gMSA ao grupo de segurança criado automaticamente pelo serviço de associação do domínio. Essa etapa precisa ser feita em uma máquina com acesso administrativo ao domínio do AD.
$instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)" $securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1] $securityGroup = dsquery group -name $securityGroupName $gmsaName = GMSA_NAME $dnsHostName = DNS_HOST_NAME New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup Get-ADServiceAccount $gmsaName Test-ADServiceAccount $gmsaName
Substitua:
NODE_POOL_NAME
: o nome do pool de nós do Windows Server. O grupo de segurança criado automaticamente tem o mesmo nome que o pool de nós do Windows Server;CLUSTER_NAME
: o nome do cluster.GMSA_NAME
: o nome escolhido para o novo gMSA;DNS_HOST_NAME
: o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) da conta de serviço que você criou. Por exemplo, seGMSA_NAME
forwebapp01
e o domínio forexample.com
,DNS_HOST_NAME
seráwebapp01.example.com
.
Configure o gMSA seguindo as instruções no tutorial Configurar o GMSA para pods e contêineres do Windows.
Como excluir pools de nós do Windows Server
Exclua um pool de nós do Windows Server usando gcloud
ou com o Console do Google Cloud.
gcloud
gcloud container node-pools delete NODE_POOL_NAME \
--cluster=CLUSTER_NAME
Console
Para excluir um pool de nós do Windows Server pelo console do Google Cloud, siga estas etapas:
Acesse a página Google Kubernetes Engine no console do Google Cloud.
Ao lado do cluster que você quer editar, clique em more_vert Ações e em edit Editar.
Selecione a guia Nós.
Na seção Pools de nós, clique em delete Excluir ao lado do pool de nós que você quer excluir.
Quando solicitado a confirmar, clique em Excluir novamente.
Limitações
Há alguns recursos do Kubernetes que ainda não são compatíveis com os contêineres do Windows Server. Além disso, alguns recursos são específicos do Linux e não funcionam no Windows. Para ver a lista completa de recursos compatíveis e incompatíveis do Kubernetes, consulte a documentação do Kubernetes (em inglês).
Além dos recursos incompatíveis do Kubernetes, há alguns recursos do GKE que não são compatíveis.
Para clusters do GKE, os seguintes recursos não são compatíveis com os pools de nós do Windows Server:
- Cloud TPUs (
--enable-tpu
) - Streaming de imagens
- Entrada com grupos de endpoints de rede
- Gateway
- Visibilidade intranós
(
--enable-intra-node-visibility
) - Agente de mascaramento de IP
- Cluster Alfa do Kubernetes(
--enable-kubernetes-alpha
) - Nó local e cache DNS
- Uso particular de endereços IP de classe E
- Uso particular de endereços IP públicos
- Geração de registros de política de rede
- Kubernetes
service.spec.sessionAffinity
- GPUs (
--accelerator
) - Definir o máximo de pods por nó acima do limite padrão de 110
- Driver CSI do Filestore
- Proxy do CloudSQL Auth baseado em Docker
- Rede de pilha dupla IPv4/IPv6 IPv6 não é compatível com nós do Windows.
A política de tráfego externo local no pool de nós do Windows é compatível apenas com a versão do GKE v1.23.4-gke.400 ou posterior.
Outros produtos do Google Cloud que você quer usar com clusters do GKE talvez não sejam compatíveis com pools de nós do Windows Server. Para limitações específicas, consulte a documentação desse produto.
Solução de problemas
Consulte a documentação do Kubernetes para orientações gerais sobre depuração de pods e serviços (links em inglês).
Problemas de nó containerd
Para problemas conhecidos usando uma imagem de nó do Containerd, consulte Problemas conhecidos.
Falha ao iniciar pods do Windows
Uma incompatibilidade de versão entre o contêiner do Windows Server e o nó do Windows que está tentando executar o contêiner pode resultar na falha dos pods do Windows.
Se a versão do pool de nós do Windows for 1.16.8-gke.8 ou superior, consulte a documentação da Microsoft para o problema de incompatibilidade do contêiner do Windows Server de fevereiro de 2020 e crie suas imagens de contêiner com imagens básicas do Windows que incluem atualizações do Windows de março de 2020. As imagens de contêiner criadas com base em imagens anteriores do Windows podem não ser executadas nesses nós do Windows e também podem causar falha no nó com status NotReady
.
Erros de extração de imagem
As imagens de contêiner do Windows Server e as camadas individuais de que elas são compostas podem ser bem grandes. O tamanho deles pode fazer com que o Kubelet atinja o tempo limite e falhe ao fazer o download e extrair as camadas do contêiner.
Você talvez encontrou esse problema se vir as mensagens de erro "Falha ao extrair imagem" ou "Contexto de extração de imagem cancelado" ou um status ErrImagePull
para seus pods.
Se a imagem de pull ocorrer com frequência, use pools de nós com uma especificação de CPU mais alta. 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 pull.
Tente as seguintes opções para extrair os contêineres do Windows Server:
Divida as camadas do aplicativo da imagem do contêiner do Windows Server em camadas menores que podem ser extraídas mais rapidamente. Isso pode tornar o armazenamento em cache da camada do Docker mais eficaz e tornar as tentativas de extração de imagens mais bem-sucedidas. Para saber mais sobre camadas, consulte o artigo do Docker Sobre imagens, contêineres e drivers de armazenamento (em inglês).
Conecte-se aos nós do Windows Server e use manualmente o comando
docker pull
nas imagens de contêiner antes de criar os pods.Defina a sinalização
image-pull-progress-deadline
(em inglês) do serviçokubelet
para aumentar o tempo limite para extrair imagens de contêiner.Defina a sinalização conectando-se aos nós do Windows e executando os seguintes comandos do PowerShell.
Receba a linha de comando atual para o serviço Kubelet do registro do Windows.
PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"
PS C:\> $name = "ImagePath"
PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match ` "(?s)${name}.*(C:.*kubelet\.exe.*)"
PS C:\> $kubelet_cmd = $Matches[1] -replace ` "--image-pull-progress-deadline=.* ","" -replace "\r\n"," "
Defina uma nova linha de comando para o serviço Kubelet, com uma sinalização adicional para aumentar o tempo limite.
PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} ` --image-pull-progress-deadline=40m "
Confirme se a alteração foi bem-sucedida.
PS C:\> reg query ${regkey} /v ${name}
Reinicie o serviço
kubelet
para que a nova sinalização entre em vigor.PS C:\> Restart-Service kubelet
Confirme se o serviço
kubelet
foi reiniciado.PS C:\> Get-Service kubelet # ensure state is Running
A família de imagens atingiu o fim da vida útil
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.
Para resolver esse erro, escolha uma imagem do Windows disponível e compatível.
Encontre a data de término do suporte para imagens de nó do GKE do Windows
usando o comando gcloud container get-server-config
, conforme descrito na
seção Como mapear versões do GKE e do Windows.
Tempo limite durante a criação do pool de nós
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 usando uma imagem do Windows Server.
Para resolver esse problema, reduza o número de nós que você está criando. É possível aumentar o número de nós posteriormente.
Os nós do Windows se tornam NotReady
com erro: "PLEG não está íntegro"
Esse é um problema conhecido do Kubernetes que acontece quando vários pods são iniciados muito rapidamente em um único nó do Windows. Para se recuperar dessa situação, reinicie o nó do Windows Server. Uma solução recomendada para evitar esse problema é limitar a taxa em que os pods do Windows são criados para um pod a cada 30 segundos.
TerminationGracePeriod inconsistente
O tempo limite do sistema Windows para o contêiner pode ser diferente do período de carência configurado. Essa diferença pode fazer com que o Windows force o encerramento do contêiner antes do término do período de carência passado para o ambiente de execução.
É possível modificar o tempo limite do Windows editando as chaves de registro do local do contêiner no momento da criação da imagem. Se você modificar o tempo limite do Windows, também precisará ajustar TerminationGracePeriodSeconds para que corresponda.
Problemas de conectividade de rede
Se você tiver problemas de conectividade de rede dos contêineres do Windows Server, talvez seja porque a rede de contêineres do Windows Server pressupõe uma MTU de rede de 1500
, incompatível com a MTU do Google Cloud de 1460
.
Verifique se a MTU da interface de rede no contêiner e as interfaces de rede do próprio nó do Windows Server estão definidas com o mesmo valor (ou seja, 1460
ou menos). Para informações sobre como definir a MTU, consulte problemas conhecidos para contêineres do Windows.
Problemas de inicialização de nós
Se os nós falharem ao iniciar no cluster ou ao entrar no cluster com sucesso, analise as informações de diagnóstico fornecidas na saída da porta serial do nó.
Execute o seguinte comando para ver a saída da porta serial:
gcloud compute instances get-serial-port-output NODE_NAME --zone=COMPUTE_ZONE
Substitua:
NODE_NAME
: o nome do nó.COMPUTE_ZONE
: a zona do Compute do nó específico.
Serviços intermitentemente inacessíveis em nós do Windows com cluster executando a versão 1.24 ou anterior
Ao iniciar nós do Windows em clusters do Kubernetes com um alto número de regras do balanceador de carga de serviço de rede de host, há um atraso no processamento das regras. Os serviços são ininterruptamente inacessíveis durante o atraso, que dura cerca de 30 segundos por regra, e o atraso total pode ser significativo se houver regras suficientes. Para saber mais, consulte o problema original no GitHub.
Para clusters do GKE que executam a versão 1.24 ou anterior, com qualquer nó do Windows que tenha um evento que reiniciou kube-proxy
, por exemplo, inicialização de nó, upgrade de nó, reinicialização manual, qualquer serviço acessado por um pod em execução nesse nó estará inacessível até que todas as regras sejam sincronizadas pelo componente.
Para clusters do GKE que executam a versão 1.25 ou posterior, esse comportamento é significativamente aprimorado. Para detalhes sobre essa melhoria, consulte a solicitação de envio no GitHub. Se você estiver com esse problema, recomendamos atualizar o plano de controle do cluster para 1.25 ou posterior.
A seguir
- Saiba como implantar um aplicativo do Windows.
- Leia a breve introdução (em inglês) da Microsoft sobre os contêineres do Windows.
- Leia as orientações da Microsoft (em inglês) sobre como escolher as imagens de base do contêiner.
- Leia sobre a compatibilidade de versão do contêiner (em inglês) da Microsoft no Windows.