Como criar um cluster usando os pools de nós do Windows Server

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:

  1. Atualize e configure gcloud.
  2. Escolha a imagem do nó.
  3. Crie um cluster e pools de nós.
  4. Receba as credenciais kubectl.
  5. Aguarde a inicialização do cluster.

Atualizar e configurar gcloud

Antes de começar, veja se você realizou as seguintes tarefas:

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  1. Execute gcloud init e siga as instruções:

    gcloud init

    Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

    gcloud init --console-only
  2. Siga as instruções para autorizar a gcloud a usar sua conta do Google Cloud.
  3. Crie uma nova configuração ou selecione uma atual.
  4. Escolha um projeto do Google Cloud.
  5. Escolha uma zona padrão do Compute Engine.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão:
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão:
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente:
    gcloud components update

Escolher a imagem de nó do Windows Server

Para executar no GKE, as imagens de nó de contêiner do Windows Server precisam ser criadas no Windows Server versão 2019 (LTSC) ou Windows Server versão 1909 (SAC). 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 o tipo de imagem:

  • 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.

  • 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.

  • 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.

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.

Compatibilidade de versões

O Windows Server Core e o Nano Server (em inglês) podem ser usados como uma imagem 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.

Mapeamento de versão

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.

Na tabela a seguir, mostramos como as versões do GKE são mapeadas para as versões do Windows Server Core:

1.15

Versão do GKE Versão do SAC Versão do LTSC
1.15.x (somente acesso antecipado) 10.0.17763 (Windows Server versão 1809 Core) N/A

1.16

Versão do GKE Versão do SAC Versão do LTSC
1.16.4-gke.25 - 1.16.7.x (apenas versão Beta) 10.0.18363.592 (Windows Server versão 1909 Core) 10.0.17763.973 (Windows Server 2019 Core)
1.16.8-gke.8 - 1.16.15-gke.1300 10.0.18363.720 (Windows Server versão 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.16.15-gke.1400+ 10.0.18363.1082 (Windows Server versão 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)

1.17

Versão do GKE Versão do SAC Versão do LTSC
1.17.x - 1.17.4-gke.5 10.0.18363.592 (Windows Server versão 1909 Core) 10.0.17763.973 (Windows Server 2019 Core)
1.17.4-gke.6 - 1.17.8-gke.2 10.0.18363.720 (Windows Server versão 1909 Core) 10.0.17763.1098 (Windows Server 2019 Core)
1.17.8-gke.16 - 1.17.12-gke.1200 10.0.18363.900 (Windows Server versão 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.17.12-gke.1500+ 10.0.18363.1082 (Windows Server versão 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)

1.18

Versão do GKE Versão do SAC Versão do LTSC
1.18.x - 1.18.9-gke.1200 10.0.18363.900 (Windows Server versão 1909 Core) 10.0.17763.1282 (Windows Server 2019 Core)
1.18.9-gke.1300+ 10.0.18363.1082 (Windows Server versão 1909 Core) 10.0.17763.1457 (Windows Server 2019 Core)

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, não redimensione o pool de nós do Linux para zero e verifique se ele tem 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

Em que:

  • 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 especifica 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ão 3.
  • version-number precisa ser 1.16.8-gke.9 ou mais recente. Também é possível usar a sinalização --release-channel para selecionar um canal de lançamento com uma versão padrão 1.16.8-gke.9 ou superior.

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

Em que:

  • node-pool-name é o nome escolhido para o pool de nós do Windows Server;
  • cluster-name é o nome do cluster criado acima;
  • image-name é WINDOWS_SAC ou WINDOWS_LTSC. 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áquina f1-micro e g1-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.

Console

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Clique no botão Criar cluster.

  3. Na seção Princípios básicos do cluster, conclua o seguinte:

    1. Insira o Nome do seu cluster.
    2. Em Tipo de local, selecione a região ou zona pretendida para o cluster.
    3. Em Versão principal, selecione uma Versão estática da versão 1.16.8-gke.9 ou superior.
      Ou,
      em Versão principal, selecione um Canal de lançamento com uma versão padrão 1.16.8-gke.9 ou superior.
  4. 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.

  5. Na parte superior da página, clique em Adicionar pool de nós para criar seu pool de nós do Windows Server.

  6. Na seção Detalhes do pool de nós, preencha o seguinte:

    1. Insira um Nome para o pool de nós.
    2. Escolha a versão dos nós.
    3. Digite o Número de nós a serem criados no pool de nós.
  7. No painel de navegação, em Pools de nós, clique em Nós.

    1. Na lista suspensa Tipo de imagem, selecione Canal semestral do Windows Server ou Canal de serviço de longo prazo do Windows Server. Para mais informações sobre essas imagens de nó, consulte a seção Escolher sua imagem de nó do Windows.
    2. 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áquina f1-micro e g1-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.
  8. 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.

    1. Em Automação, desmarque Ativar upgrade automático do nó. Revise a seção Como fazer upgrade de pools de nós do Windows Server antes de ativar.
  9. No painel de navegação, selecione Rede.

    1. 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.
  10. Clique em Criar.

Terraform

Use o provedor Google Terraform para criar um cluster do GKE com um pool de nós do Windows Server.

Adicione este bloco à configuração do Terraform:

resource "google_container_cluster" "cluster" {
  project  = "project-id"
  name     = "cluster-name"
  location = "location"

  min_master_version = "version-number"

  # Enable Alias IPs to allow Windows Server networking.
  ip_allocation_policy {
    cluster_ipv4_cidr_block  = "/14"
    services_ipv4_cidr_block = "/20"
  }

  # Removes the implicit default node pool, recommended when using
  # google_container_node_pool.
  remove_default_node_pool = true
  initial_node_count       = 1
}

# Small Linux node pool to run some Linux-only Kubernetes Pods.
resource "google_container_node_pool" "linux_pool" {
  name     = "linux-pool"
  project  = google_container_cluster.cluster.project
  cluster  = google_container_cluster.cluster.name
  location = google_container_cluster.cluster.location

  node_config {
    image_type = "COS_CONTAINERD"
  }
}

# Node pool of Windows Server machines.
resource "google_container_node_pool" "windows_pool" {
  name     = "node-pool-name"
  project  = google_container_cluster.cluster.project
  cluster  = google_container_cluster.cluster.name
  location = google_container_cluster.cluster.location

  node_config {
    image_type   = "image-name"
    machine_type = "machine-type-name"
  }

  # The Linux node pool must be created before the Windows Server node pool.
  depends_on = [google_container_node_pool.linux_pool]
}

Substitua o seguinte:

  • project-id é o ID do projeto em que o cluster é criado.
  • cluster-name é o nome do cluster do GKE.
  • location é o local (região ou zona) onde o cluster será criado.
  • version-number precisa ser 1.16.8-gke.9 ou mais recente.
  • node-pool-name é o nome escolhido para o pool de nós do Windows Server.
  • image-name é WINDOWS_SAC ou WINDOWS_LTSC. Para mais informações sobre essas imagens de nó, consulte a seção Escolher sua imagem de nó do Windows.
  • 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áquina f1-micro e g1-small. O faturamento varia de acordo com cada tipo de máquina. Para mais informações, consulte a tabela de preços de tipo de máquina.

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 (mestre).

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 

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 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 a tabela de 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 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.

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 da área de trabalho remota (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

O Docker é compatível com imagens de multiarquiteturas (ou várias plataformas). O ambiente de execução do contêiner no nó pode extrair uma imagem compatível para a plataforma com uma imagem de multiarquiteturas. A criação de um manifesto de imagem de multiarquiteturas envolve a criação da imagem para cada plataforma e, em seguida, a criação do manifesto que referencia essas imagens para cada plataforma.

Para criar um manifesto de imagens de multiarquiteturas:

  1. Crie uma imagem LTSC do Docker 2019. Por exemplo, gcr.io/my-project/foo:1.0-2019.
  2. Crie uma imagem do Docker SAC 1909. Por exemplo, gcr.io/my-project/foo:1.0-1909.
  3. Crie uma VM do Windows Server versão 1909.
  4. Use o RDP para se conectar à VM.
  5. Execute o PowerShell.
  6. Ative o recurso experimental docker manifest.
    PS C:> $env:DOCKER_CLI_EXPERIMENTAL = 'enabled'
    
  7. Crie o manifesto de multiarquiteturas.
    docker manifest create gcr.io/my-project/foo:1.0 gcr.io/my-project/foo:1.0-2019 gcr.io/my-project/foo:1.0-1909
    
  8. Envie o manifesto recém-criado.
    docker manifest push gcr.io/my-project/foo:1.0 gcr.io/my-project/foo:1.0-2019 gcr.io/my-project/foo:1.0-1909
    

Como excluir pools de nós do Windows Server

Exclua um pool de nós do Windows Server usando gcloud ou o Console do Google Cloud.

gcloud

gcloud container node-pools delete --cluster=cluster-name node-pool-name

Console

Para excluir um pool de nós do Windows Server usando o Console do Cloud, siga estas etapas:

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o menu do Google Kubernetes Engine

  2. Clique no ícone Editar (semelhante a um lápis) ao lado do cluster que contém o pool de nós que você quer excluir.

  3. Na seção Pools de nós, clique no ícone Excluir (parece uma lixeira) ao lado do pool de nós que você quer excluir.

  4. 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 disso, alguns recursos do GKE não são compatíveis.

Para clusters, os seguintes recursos não são compatíveis com os pools de nós do Windows Server:

Para os pools de nós do Windows Server, os seguintes recursos não são compatíveis:

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).

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 das quais 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.

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ço kubelet 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.

    1. 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 `
      "${name}.*(C:.*kubelet\.exe.*)\r"
      
      PS C:\> $kubelet_cmd = $Matches[1]
      
    2. 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=15m
      
    3. Confirme se a alteração foi bem-sucedida.

      PS C:\> reg query ${regkey} /v ${name}
      
    4. Reinicie o serviço kubelet para que a nova sinalização entre em vigor.

      PS C:\> Restart-Service kubelet
      
    5. Confirme se o serviço kubelet foi reiniciado.

      PS C:\> Get-Service kubelet # ensure state is Running
      

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.

Como usar o gMSA

Se você tiver dificuldade para usar uma conta de serviço gerenciada em grupo (gMSA, na sigla em inglês), talvez seja devido ao limite de nomes de computadores no Active Directory. O Active Directory limita os nomes de computador a 15 caracteres. Quando você usa o GKE, esse nome é derivado do nome do nó do GKE. Os nomes de nós vêm do nome do pool de nós, seguido por uma string exclusiva. Quando o nome do nó excede 15 caracteres, ele é truncado para 15 caracteres.

Por exemplo, se um nó for chamado gke-cluster-windows--node-pool-window-3d3afc34- wnnn, ele será truncado para GKE-CLUSTER-WIN.

Se outro nó for chamado gke-cluster-windows--node-pool-window-123gtj12-aabb, ele também será truncado para GKE-CLUSTER-WIN.

O Active Directory tem uma relação direta entre computadores e nomes. Portanto, se dois computadores compartilharem um nome, ocorrerá um erro.

Para evitar esse problema, renomeie o computador ao ingressar no Active Directory. Depois de renomear o computador, você também precisa atualizar o kubelet do nó e a configuração kube-proxy para evitar que um nó pare de se conectar ao cluster. Para fazer isso, anexe a sinalização --hostname-override ao caminho dos serviços do kubelet e do kube-proxy. Defina a sinalização como o nome da instância do nó e reinicie os serviços.

Para atualizar a configuração, execute o seguinte comando:

sc.exe config service-name binPath="existing-service-binpath --hostname-override=node-instance-name"

Em que:

  • service-name é kubelet ou kube-proxy. Execute esse script uma vez por serviço.
  • existing-service-binpath é o binPath do serviço. Recupere isso usando sc.exe qc service-name.
  • node-instance-name é o nome da instância da VM do nó.

Isso resolve o problema e permite que os pods de nó e de host sejam exibidos. Também evita conflitos de nome no Active Directory.

Observação sobre o Serviço gerenciado para Microsoft Active Directory

No Serviço gerenciado para Microsoft Active Directory, a configuração de um gMSA requer algumas etapas extras. O processo é um pouco diferente devido a algumas diferenças entre os objetos e as permissões padrão no Microsoft AD gerenciado e no AD padrão. Saiba como criar um gMSA no Microsoft AD gerenciado.

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 nó do Windows Server são todas 1460 ou menos. Para informações sobre como definir a MTU, consulte problemas conhecidos para contêineres do Windows.

A seguir