Criar um cluster com node pools do Windows Server

Nesta página, vai saber como criar um cluster do Google Kubernetes Engine (GKE) com pools de nós a executar o Microsoft Windows Server. Com este cluster, pode usar contentores do Windows Server. Atualmente, os contentores do Microsoft Hyper-V não são suportados. Semelhantes aos contentores Linux, os contentores do Windows Server oferecem isolamento de processos e espaços de nomes.

Um nó do Windows Server requer mais recursos do que um nó do Linux típico. Os nós do Windows Server precisam dos recursos adicionais para executar o SO Windows e os componentes do Windows Server que não podem ser executados em contentores. Uma vez que os nós do Windows Server requerem mais recursos, os seus recursos atribuíveis são inferiores aos que seriam com nós do Linux.

Criar um cluster com node pools do Windows Server

Nesta secção, cria um cluster que usa um contentor do Windows Server.

Para criar este cluster, tem de concluir as seguintes tarefas:

  1. Escolha a imagem do nó do Windows Server.
  2. Atualize e configure gcloud.
  3. Crie um cluster e node pools.
  4. Obtenha kubectl credenciais.
  5. Aguarde a inicialização do cluster.

Configure contas de serviço IAM para o GKE

O GKE usa contas de serviço da IAM anexadas aos seus nós para executar tarefas do sistema, como registo e monitorização. No mínimo, estas contas de serviço de nós têm de ter a função Conta de serviço de nós predefinida do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por predefinição, o GKE usa a conta de serviço predefinida do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Para conceder a função roles/container.defaultNodeServiceAccount à conta de serviço predefinida do Compute Engine, conclua os passos seguintes:

consola

  1. Aceda à página Boas-vindas:

    Aceder a Boas-vindas

  2. No campo Número do projeto, clique em Copiar para a área de transferência.
  3. Aceda à página IAM:

    Aceda ao IAM

  4. Clique em Conceder acesso.
  5. No campo Novos responsáveis, especifique o seguinte valor: 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     Substitua PROJECT_NUMBER pelo número do projeto que copiou.
  6. No menu Selecionar uma função, selecione a função Conta de serviço do nó predefinido do Kubernetes Engine.
  7. Clique em Guardar.

gcloud

  1. Encontre o seu Google Cloud número do projeto: 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Substitua PROJECT_ID pelo ID do seu projeto.

    O resultado é semelhante ao seguinte:

    12345678901
  2. Conceda a função roles/container.defaultNodeServiceAccount à conta de serviço predefinida do Compute Engine: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Substitua PROJECT_NUMBER pelo número do projeto do passo anterior.

Escolha a imagem do nó do Windows Server

Para serem executadas no GKE, as imagens de nós de contentores do Windows Server têm de 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 conjuntos de nós do Windows Server com diferentes versões do Windows Server, mas cada conjunto de nós individual só pode usar uma versão do Windows Server.

Considere o seguinte ao escolher a imagem do nó:

  • Tempo de apoio técnico:
    • O tempo de suporte de 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 de SO. Pode encontrar a data de fim do suporte para imagens de nós do Windows do GKE através do comando gcloud container get-server-config, conforme descrito na secção Mapeamento das versões do GKE e do Windows.
    • As versões SAC só são suportadas pela Microsoft durante 18 meses após o respetivo lançamento inicial. Se escolher o SAC para o tipo de imagem do seu conjunto de nós, mas não atualizar o conjunto de nós para versões mais recentes do GKE que segmentam versões mais recentes do SAC, não pode criar novos nós no seu conjunto de nós quando o ciclo de vida de suporte da versão do SAC terminar. Saiba mais acerca do apoio técnico da Google para o sistema operativo Windows Server. Recomendamos a utilização do LTSC devido ao seu ciclo de vida de apoio técnico mais longo.
    • Não escolha SAC se inscrever o seu cluster do GKE no canal de lançamento estável. Uma vez que as versões SAC só são suportadas pela Microsoft durante 18 meses, existe o risco de a imagem do conjunto de nós SAC deixar de ser suportada enquanto a versão estável do GKE ainda estiver disponível.
  • Compatibilidade e complexidade das versões:
    • Escolha apenas o SAC se puder atualizar o conjunto de nós e os contentores que são executados 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, pelo que a escolha do SAC para o tipo de imagem do pool de nós requer que reconstrua os contentores com mais frequência.
    • Se não tiver a certeza de que tipo de imagem do Windows Server usar, recomendamos que escolha o Windows Server LTSC para evitar problemas de incompatibilidade de versões ao atualizar o pool de nós. Para mais informações, consulte o artigo Canais de manutenção do Windows Server: LTSC e SAC na documentação da Microsoft.
    • O Windows Server Core e o Nano Server podem ser usados como uma imagem base para os seus contentores.
    • Os contentores do Windows Server têm requisitos de compatibilidade de versões importantes:
      • Os contentores do Windows Server criados para o LTSC não são executados em nós SAC e vice-versa.
      • Os contentores do Windows Server criados para uma versão LTSC ou SAC específica não são executados noutras versões LTSC ou SAC sem serem recompilados para segmentar a outra versão.
    • A criação de imagens de contentores do Windows Server como imagens multi-arquitetura que podem segmentar várias versões do Windows Server pode ajudar a gerir esta complexidade de controlo de versões.
  • Novas funcionalidades:
    • Normalmente, as novas funcionalidades do Windows Server são introduzidas primeiro nas versões do SAC. Por este motivo, a nova funcionalidade do Windows do GKE pode ser introduzida primeiro nos conjuntos de nós SAC.
    • Considere o SAC se depender de funcionalidades ainda não disponíveis na versão LTSC.

  • Tempo de execução do contentor:

    • Para as imagens de nós do Windows Server LTSC e SAC, o tempo de execução do contentor pode ser o Docker ou o containerd. Para a versão 1.21.1-gke.2200 e posteriores do nó do GKE, recomendamos que use o tempo de execução do containerd. Para mais informações, consulte o artigo Imagens de nós.

Atualize e configure o gcloud

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Crie um cluster e node pools

Para executar contentores do Windows Server, o cluster tem de ter, pelo menos, um pool de nós do Windows e um pool de nós do Linux. Não pode criar um cluster usando apenas um node pool do Windows Server. O conjunto de nós do Linux é necessário para executar suplementos de cluster críticos.

Devido à sua importância, recomendamos que ative o dimensionamento automático para garantir que o seu conjunto de nós do Linux tem capacidade suficiente para executar suplementos do cluster.

gcloud

Crie um cluster com os seguintes campos:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
    --cluster-version=VERSION_NUMBER \
    --release-channel CHANNEL

Substitua o seguinte:

  • CLUSTER_NAME: o nome que escolher para o seu cluster.
  • CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.
  • --enable-ip-alias ativa o IP de alias. O IP de alias é obrigatório para nós do Windows Server. Para ler mais sobre as respetivas vantagens, consulte o artigo Compreender o encaminhamento de contentores nativo com IPs de alias.
  • NUMBER_OF_NODES: o número de nós Linux que criar. Deve fornecer recursos computacionais suficientes para executar suplementos de cluster. Este é um campo opcional e, se for omitido, usa o valor predefinido de 3.
  • VERSION_NUMBER: a versão específica do cluster que quer usar, que tem de ser 1.16.8-gke.9 ou superior. Se não especificar um canal de lançamento, o GKE inscreve o cluster no canal de lançamento mais desenvolvido onde essa versão está disponível.
  • CHANNEL: o canal de lançamento no qual inscrever o cluster, que pode ser um dos seguintes: rapid, regular, stable ou None. Por predefinição, o cluster está inscrito no canal de lançamento regular, a menos que seja especificada, pelo menos, uma das seguintes flags: --cluster-version, --release-channel, --no-enable-autoupgrade e --no-enable-autorepair. Tem de especificar None se escolher uma versão do cluster e não quiser que o cluster seja inscrito num canal de lançamento.

Recomendamos vivamente que especifique uma conta de serviço do IAM com privilégios mínimos que os seus nós possam usar em vez da conta de serviço predefinida do Compute Engine. Para saber como criar uma conta de serviço com privilégios mínimos, consulte o artigo Use uma conta de serviço com privilégios mínimos.

Para especificar uma conta de serviço personalizada na CLI gcloud, adicione a seguinte flag ao seu comando:

--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Substitua SERVICE_ACCOUNT_NAME pelo nome da sua conta de serviço com privilégios mínimos.

Crie o node pool do Windows Server com os seguintes campos:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

Substitua o seguinte:

  • NODE_POOL_NAME: o nome que escolher para o seu conjunto de nós do Windows Server.
  • CLUSTER_NAME: o nome do cluster que criou acima.

  • CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

  • IMAGE_NAME: pode especificar um dos seguintes valores:

    Para mais informações sobre estas imagens de nós, consulte a secção Escolha a imagem do nó do Windows.

  • --no-enable-autoupgrade desativa a atualização automática de nós. Reveja o artigo Atualizar 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, uma vez que os nós do Windows Server requerem recursos adicionais. Os tipos de máquinas f1-micro e g1-small não são suportados. Cada tipo de máquina é faturado de forma diferente. Para mais informações, consulte a folha de preços do tipo de máquina.

  • WINDOWS_OS_VERSION: define a versão do SO Windows a usar para o tipo de imagem WINDOWS_LTSC_CONTAINERD. Esta é uma flag opcional. Quando não especificado, a versão do SO predefinida usada é o LTSC2019. Defina o valor como ltsc2022 para criar um node pool do Windows Server 2022. Defina o valor como ltsc2019 para criar um conjunto de nós do Windows Server 2019.

O exemplo seguinte mostra como pode criar um pool de nós do Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

O exemplo seguinte mostra como pode atualizar um conjunto de nós do Windows existente para usar a imagem do SO Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --location=us-central1 \
    --windows-os-version=ltsc2022

Consola

  1. Na Google Cloud consola, aceda à página Criar um cluster do Kubernetes.

    Aceda a Crie um cluster do Kubernetes

  2. Na secção Noções básicas do cluster, conclua o seguinte:
    1. Introduza o Nome do cluster.
    2. Para o Tipo de localização, selecione a região ou a zona desejada para o seu cluster.
    3. Em Versão do plano de controlo, selecione um canal de lançamento ou opte por especificar uma versão estática. A versão estática tem de ser 1.16.8-gke.9 ou superior.
  3. No painel de navegação, em Conjuntos de nós, clique em default-pool para criar o conjunto de nós do Linux. Quando configurar este conjunto de nós, deve fornecer recursos informáticos suficientes para executar suplementos do cluster. Também tem de ter quota de recursos disponível para os nós e os respetivos recursos (como trajetos de firewall).
  4. Na parte superior da página, clique em Adicionar conjunto de nós para criar o seu conjunto de nós do Windows Server.
  5. Na secção Detalhes do conjunto de nós, conclua o seguinte:
    1. Introduza um Nome para o conjunto de nós.
    2. Para nós de versão estática, escolha a Versão do nó.
    3. Introduza o Número de nós a criar no node pool.

  6. No painel de navegação, em Node Pools, clique em Nodes.

    1. Na lista pendente Tipo de imagem, selecione uma das seguintes imagens de nó:

      • Canal de manutenção a longo prazo do Windows com o Docker
      • Canal de manutenção a longo prazo do Windows com o containerd
      • Canal semestral do Windows com o Docker
      • Canal semestral do Windows com o containerd

      Para mais informações, consulte a secção Escolha a imagem do nó do Windows.

    2. Escolha a configuração da máquina predefinida a usar para as instâncias. n1-standard-2 é o tamanho mínimo recomendado, uma vez que os nós do Windows Server requerem recursos adicionais. Os tipos de máquinas f1-micro e g1-small não são suportados. Cada tipo de máquina é faturado de forma diferente. Para mais informações, consulte a folha de preços do tipo de máquina.

  7. No painel de navegação, selecione o nome do seu conjunto de nós do Windows Server. Esta ação regressa à página Detalhes do conjunto de nós.

    1. Em Automatização, desmarque a caixa de verificação Ativar atualização automática de nós. Reveja a secção Atualizar pools de nós do Windows Server antes de ativar a atualização automática.

  8. No painel de navegação, em Cluster, selecione Redes.

    1. Em Opções de rede avançadas, certifique-se de que a opção Ativar o encaminhamento de tráfego nativo da VPC (usa o IP de alias) está selecionada. O IP de alias é obrigatório para os nós do Windows Server. Para ler mais sobre as respetivas vantagens, consulte o artigo Compreender o encaminhamento de contentores nativo com IPs de alias.

  9. Clique em Criar.

Terraform

Para criar um cluster padrão do GKE e um node pool do Windows Server com o Terraform, consulte o exemplo seguinte:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-west1"

  initial_node_count = 1
}

resource "google_container_node_pool" "default" {
  name     = "windows-node-pool"
  cluster  = google_container_cluster.default.name
  location = google_container_cluster.default.location

  node_config {
    image_type = "WINDOWS_LTSC_CONTAINERD"
  }
}

Este exemplo usa o Windows Server LTSC com o containerd. Este é o tipo de imagem para a imagem do SO Windows Server 2022 e Windows Server 2019. Para mais informações sobre imagens de nós, consulte o artigo Escolha a imagem do nó do Windows.

Para saber mais sobre a utilização do Terraform, consulte o artigo Compatibilidade do Terraform com o GKE.

Depois de criar um pool de nós do Windows Server, o cluster entra num estado RECONCILE durante vários minutos enquanto o plano de controlo é atualizado.

Obtenha credenciais do kubectl

Use o comando get-credentials para permitir que o kubectl funcione com o cluster que criou.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

Para mais informações sobre o comando get-credentials, consulte a documentação get-credentials do SDK.

Aguarde pela inicialização do cluster

Antes de usar o cluster, aguarde vários segundos até que windows.config.common-webhooks.networking.gke.io seja criado. Este webhook adiciona tolerâncias de agendamento aos pods criados com o seletor de nós para garantir que podem ser executados em nós do Windows Server.kubernetes.io/os: windows Também valida o Pod para garantir que só usa funcionalidades suportadas no Windows.

Para garantir que o webhook é criado, execute o seguinte comando:

kubectl get mutatingwebhookconfigurations

O resultado deve mostrar o webhook em execução:

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

Agora que tem um cluster com dois conjuntos de nós (um Linux e um Windows), pode implementar uma aplicação Windows.

Mapeamento das versões do GKE e do Windows

A Microsoft lança novas versões SAC aproximadamente a cada seis meses e novas versões LTSC a cada dois a três anos. Normalmente, estas novas versões estão disponíveis em novas versões secundárias do GKE. Numa versão secundária do GKE, as versões LTSC e SAC permanecem normalmente fixas.

Para ver o mapeamento de versões entre as versões do GKE e as versões do Windows Server, use o comando gcloud beta container get-server-config:

gcloud beta container get-server-config

O mapeamento de versões é devolvido no campo windowsVersionMaps da resposta. Para filtrar a resposta e ver o mapeamento de versões para versões específicas do GKE no seu cluster, execute os seguintes passos numa shell do Linux ou no Cloud Shell.

  1. Defina as seguintes variáveis:

    CLUSTER_NAME=CLUSTER_NAME \
NODE_POOL_NAME=NODE_POOL_NAME \
CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster.
    • NODE_POOL_NAME: o nome do conjunto de nós do Windows Server.
    • CONTROL_PLANE_LOCATION: a localização do Compute Engine do plano de controlo do seu cluster. Indique uma região para clusters regionais ou uma zona para clusters zonais.

  2. Obtenha a versão do conjunto 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 \
--location=$CONTROL_PLANE_LOCATION \
--format="value(version)"`

  3. Obtenha as versões do Windows Server para NODE_POOL_VERSION:

    gcloud beta container get-server-config \
    --location=$CONTROL_PLANE_LOCATION \
    --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"

    O resultado é semelhante ao seguinte:

    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

  4. Obtenha 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 é semelhante ao seguinte:

    10.0.18363.1198

Atualizar node pools do Windows Server

Os requisitos de compatibilidade da versão do contentor do Windows Server significam que pode ter de recriar as imagens de contentores para corresponder à versão do Windows Server para uma nova versão do GKE antes de atualizar os conjuntos de nós.

Para garantir que as suas imagens de contentor permanecem compatíveis com os seus nós, recomendamos que verifique o mapeamento de versões e crie as suas imagens de contentor do Windows Server como imagens multi-arquitetura que podem segmentar várias versões do Windows Server. Em seguida, pode atualizar as implementações de contentores para segmentar as imagens de várias arquiteturas que vão funcionar na versão atual e na versão seguinte do GKE antes de invocar manualmente uma atualização do conjunto de nós do GKE. As atualizações manuais do conjunto de nós têm de ser realizadas regularmente, uma vez que os nós não podem estar mais de duas versões secundárias atrás da versão do plano de controlo.

Recomendamos que subscreva as notificações de atualização através do Pub/Sub para receber proativamente atualizações sobre as novas versões do GKE e as versões do SO Windows que usam.

Recomendamos que ative as atualizações automáticas de nós apenas se criar continuamente imagens de contentores do Windows Server multiarquitetura que tenham como destino as versões mais recentes do Windows Server, especialmente se estiver a usar o Windows Server SAC como o tipo de imagem do nó. As atualizações automáticas de nós têm menor probabilidade de causar problemas com o tipo de imagem de nó do Windows Server LTSC, mas ainda existe o risco de encontrar problemas de incompatibilidade de versões.

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 provocar reinícios de nós em momentos imprevisíveis, e quaisquer atualizações do Windows instaladas após o início de um nó seriam perdidas quando o nó fosse recriado pelo GKE. O GKE disponibiliza atualizações do Windows atualizando periodicamente as imagens de nós do Windows Server usadas em novos lançamentos 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 são lançadas atualizações de segurança críticas, o GKE atualiza as imagens dos nós do Windows Server o mais rapidamente possível.

Controle a forma como os pods e os serviços do Windows comunicam

Pode controlar a forma como os Windows Pods e os serviços comunicam através de políticas de rede.

Pode ter um contentor do Windows Server em clusters com a política de rede ativada nas versões 1.22.2 e posteriores do GKE. Esta funcionalidade está disponível para clusters que usam os tipos de imagens de nós WINDOWS_LTSC ou WINDOWS_LTSC_CONTAINERD.

Se os seus planos de controlo ou nós estiverem a executar versões anteriores, pode migrar os seus conjuntos de nós para uma versão que suporte a política de rede atualizando os seus conjuntos de nós e o seu plano de controlo para a versão 1.22.2 ou posterior do GKE. Esta opção só está disponível se tiver criado o cluster com a flag --enable-dataplane-v2.

Depois de ativar a política de rede, todas as políticas configuradas anteriormente, incluindo as políticas que não funcionavam em contentores do Windows Server antes de ativar a funcionalidade, tornam-se ativas.

Não é possível usar alguns clusters com contentores do Windows Server em clusters com a política de rede ativada. Consulte a secção Limitações para ver mais detalhes.

Visualizar e consultar registos

O registo é ativado automaticamente nos clusters do GKE. Pode ver os registos dos contentores e os registos de outros serviços nos nós do Windows Server através da monitorização do Kubernetes Engine.

Segue-se um exemplo de um filtro para obter o registo do contentor:

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"

Aceder a um nó do Windows Server através do protocolo de ambiente de trabalho remoto (RDP)

Pode estabelecer ligação a um nó do Windows Server no seu cluster através do RDP. Para ver instruções sobre como estabelecer ligação, consulte Estabelecer ligação a instâncias do Windows na documentação do Compute Engine.

Criar imagens multi-arquitetura

Pode criar as imagens de várias arquiteturas manualmente ou usar um criador do Cloud Build. Para ver instruções, consulte o artigo Criar imagens multi-arquitetura do Windows.

Usar gMSA

Os passos seguintes mostram como usar uma conta de serviço gerida por um grupo (gMSA) com os seus conjuntos de nós do Windows Server.

  1. Configure nós do Windows Server no seu cluster para aderirem automaticamente ao seu domínio do AD. Para obter instruções, consulte o artigo Configure nós do Windows Server para aderirem automaticamente a um domínio do Active Directory.

  2. Crie e conceda acesso a uma gMSA ao grupo de segurança criado automaticamente pelo serviço de associação ao domínio. Este passo tem de ser realizado num computador com acesso administrativo ao seu 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 o seguinte:

    • NODE_POOL_NAME: o nome do seu conjunto de nós do Windows Server. O grupo de segurança criado automaticamente tem o mesmo nome que o seu node pool do Windows Server.
    • CLUSTER_NAME: o nome do cluster.
    • GMSA_NAME: o nome que escolher para o novo gMSA.
    • DNS_HOST_NAME: o nome de domínio totalmente qualificado (FQDN) da conta de serviço que criou. Por exemplo, se GMSA_NAME for webapp01 e o domínio for example.com, então DNS_HOST_NAME é webapp01.example.com.

  3. Configure a gMSA seguindo as instruções no tutorial Configure a gMSA para contentores e pods do Windows.

Eliminar node pools do Windows Server

Elimine um conjunto de nós do Windows Server através do comando gcloud ou da Google Cloud consola.

gcloud

gcloud container node-pools delete NODE_POOL_NAME \
    --cluster=CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION

Consola

Para eliminar um conjunto de nós do Windows Server através da Google Cloud consola, siga estes passos:

  1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

    Aceda ao Google Kubernetes Engine

  2. Junto ao cluster que quer editar, clique em Ações e, de seguida, em Editar.

  3. Selecione o separador Nós.

  4. Na secção Conjuntos de nós, clique em Eliminar junto ao conjunto de nós que quer eliminar.

  5. Quando lhe for pedido que confirme, clique novamente em Eliminar.

Limitações

Existem algumas funcionalidades do Kubernetes que ainda não são suportadas para contentores do Windows Server. Além disso, algumas funcionalidades são específicas do Linux e não funcionam no Windows. Para ver a lista completa de funcionalidades do Kubernetes suportadas e não suportadas, consulte a documentação do Kubernetes.

Além das funcionalidades do Kubernetes não suportadas, existem algumas funcionalidades do GKE que não são suportadas.

Para clusters do GKE, as seguintes funcionalidades não são suportadas com pools de nós do Windows Server:

A Política de Tráfego Externo Local no conjunto de nós do Windows só é suportada com o GKE versão v1.23.4-gke.400 ou posterior.

Outros Google Cloud produtos que quer usar com clusters do GKE podem não suportar pools de nós do Windows Server. Para ver limitações específicas, consulte a documentação desse produto.

Resolução de problemas

Consulte a documentação do Kubernetes para obter orientações gerais sobre como depurar pods e serviços.

Problemas com nós do Containerd

Para problemas conhecidos que usam uma imagem de nó do Containerd, consulte Problemas conhecidos.

Os pods do Windows não são iniciados

Uma incompatibilidade de versões entre o contentor do Windows Server e o nó do Windows que está a tentar executar o contentor pode fazer com que os seus pods do Windows não sejam iniciados.

Se a versão do seu conjunto de nós do Windows for 1.16.8-gke.8 ou posterior, reveja a documentação da Microsoft sobre o problema de incompatibilidade do contentor do Windows Server de fevereiro de 2020 e crie as suas imagens de contentores com imagens base do Windows que incluam atualizações do Windows de março de 2020. As imagens de contentores criadas com base em imagens do Windows anteriores podem não ser executadas nestes nós do Windows e também podem fazer com que o nó falhe com o estado NotReady.

Erros de obtenção de imagens

As imagens de contentores do Windows Server e as camadas individuais de que são compostas podem ser bastante grandes. O respetivo tamanho pode fazer com que o Kubelet exceda o limite de tempo e falhe ao transferir e extrair as camadas do contentor.

Pode ter encontrado este problema se vir as mensagens de erro "Failed to pull image" (Falha ao obter imagem) ou "Image pull context cancelled" (Contexto de obtenção de imagem cancelado) ou um estado ErrImagePull para os seus pods.

Se a obtenção de imagens ocorrer com frequência, deve usar conjuntos de nós com uma especificação de CPU mais elevada. A extração de contentores é executada em paralelo em vários núcleos, pelo que os tipos de máquinas com mais núcleos reduzem o tempo de obtenção geral.

Experimente as seguintes opções para extrair com êxito os contentores do Windows Server:

  • Divida as camadas de aplicação da imagem do contentor do Windows Server em camadas mais pequenas que podem ser obtidas e extraídas mais rapidamente. Isto pode tornar o armazenamento em cache de camadas do Docker mais eficaz e aumentar a probabilidade de sucesso das novas tentativas de obtenção de imagens. Para saber mais sobre as camadas, consulte o artigo do Docker Controladores de armazenamento.

  • Estabeleça ligação aos nós do Windows Server e use manualmente o comando docker pull nas imagens de contentores antes de criar os seus pods.

  • Defina a flag image-pull-progress-deadline para o serviço kubelet para aumentar o limite de tempo para obter imagens de contentores.

    Defina a flag ligando-se aos seus nós do Windows e executando os seguintes comandos do PowerShell.

    1. Obtenha a linha de comandos existente para o serviço Kubelet do registo 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"," "

    2. Defina uma nova linha de comandos para o serviço Kubelet, com uma flag adicional para aumentar o limite de tempo.

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
--image-pull-progress-deadline=40m "

    3. Confirme que a alteração foi bem-sucedida.

      PS C:\> reg query ${regkey} /v ${name}

    4. Reinicie o serviço kubelet para que a nova flag seja aplicada.

      PS C:\> Restart-Service kubelet

    5. Confirme que o serviço kubelet foi reiniciado com êxito.

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

A família de imagens atingiu o fim de vida

Quando cria um conjunto de nós com uma imagem do Windows, 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 este erro, escolha uma imagem do Windows disponível e suportada. Pode encontrar a data de fim do apoio técnico das imagens de nós do Windows do GKE através do comando gcloud container get-server-config, conforme descrito na secção Mapeamento das versões do GKE e do Windows.

Limite de tempo durante a criação do node pool

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

Para resolver este problema, reduza o número de nós que está a criar. Pode aumentar o número de nós mais tarde.

Os nós do Windows ficam com o estado NotReady com o erro: "PLEG is not healthy" (PLEG não está em bom estado)

Este é um problema conhecido do Kubernetes que ocorre quando vários pods são iniciados muito rapidamente num único nó do Windows. Para recuperar desta situação, reinicie o nó do Windows Server. Uma solução recomendada para evitar este problema é limitar a taxa de criação de Windows Pods a um Pod a cada 30 segundos.

Inconsistent TerminationGracePeriod

O limite de tempo do sistema Windows para o contentor pode diferir do período de tolerância que configurar. Esta diferença pode fazer com que o Windows termine o contentor à força antes do fim do período de tolerância transmitido ao tempo de execução.

Pode modificar o limite de tempo do Windows editando as chaves de registo locais do contentor no momento da criação da imagem. Se modificar o limite de tempo do Windows, também pode ter de ajustar o TerminationGracePeriodSeconds para corresponder.

Problemas de conetividade de rede

Se tiver problemas de conetividade de rede a partir dos contentores do Windows Server, tal pode dever-se ao facto de a rede de contentores do Windows Server assumir frequentemente um MTU de rede de 1500, que é incompatível com o MTU de Google Cloudde 1460.

Verifique se a MTU da interface de rede no contentor e as interfaces de rede do próprio nó do Windows Server estão definidas para o mesmo valor (ou seja, 1460 ou menos). Para obter informações sobre como definir a MTU, consulte os problemas conhecidos para contentores Windows.

Problemas de arranque do nó

Se os nós não forem iniciados no cluster ou não aderirem com êxito ao cluster, reveja as informações de diagnóstico fornecidas na saída da porta série do nó.

Execute o seguinte comando para ver a saída da porta de série:

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

Substitua o seguinte:

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

Quando inicia nós do Windows em clusters do Kubernetes com um número elevado de regras do balanceador de carga do serviço de rede do anfitrião, existe um atraso no processamento das regras. Os serviços ficam intermitentemente inacessíveis durante o atraso, que dura cerca de 30 segundos por regra, e o atraso total pode ser significativo se existirem regras suficientes. Para saber mais, consulte o problema original no GitHub.

Para clusters do GKE com a versão 1.24 ou anterior, com nós do Windows que tiveram um evento que reiniciou o kube-proxy—por exemplo, o arranque do nó, a atualização do nó ou o reinício manual—não é possível aceder a nenhum serviço através de um pod em execução nesse nó até que todas as regras sejam sincronizadas pelo componente.

Para clusters do GKE com a versão 1.25 ou posterior, este comportamento é substancialmente melhorado. Para ver detalhes sobre esta melhoria, consulte o pedido de incorporação no GitHub. Se estiver a ter este problema, recomendamos que atualize o plano de controlo do cluster para a versão 1.25 ou posterior.

O que se segue?