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.
Configurar contas de serviço do IAM para o GKE
O GKE usa contas de serviço do IAM anexadas aos nós para
executar tarefas do sistema, como geração de registros e monitoramento. No mínimo, essas contas de serviço de nó
precisam ter o papel
Conta de serviço de nó padrão do Kubernetes Engine
(roles/container.defaultNodeServiceAccount) no seu projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.
Para conceder o papel roles/container.defaultNodeServiceAccount à conta de serviço padrão do Compute Engine, siga estas etapas:
Console
- Acesse a página Boas-vindas:
- No campo Número do projeto, clique em Copiar para a área de transferência.
- Acesse a página do IAM:
- Clique em Conceder acesso.
- No campo Novos principais, especifique o seguinte valor:
SubstituaPROJECT_NUMBER-compute@developer.gserviceaccount.comPROJECT_NUMBERpelo número do projeto que você copiou. - No menu Selecionar um papel, escolha o papel Conta de serviço de nó padrão do Kubernetes Engine.
- Clique em Salvar.
gcloud
- Encontre o Google Cloud número do projeto:
gcloud projects describe PROJECT_ID \ --format="value(projectNumber)"
Substitua
PROJECT_IDpela ID do seu projeto.O resultado será o seguinte:
12345678901
- Conceda o papel
roles/container.defaultNodeServiceAccountà conta de serviço padrão 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_NUMBERpelo número do projeto da etapa anterior.
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 recomendada do Windows Server 2022 (LTSC) ou na versão 2019 (LTSC), que está descontinuada pelo GKE e não pode ser usada para pools de nós que executam a versão 1.37 ou mais recente do GKE. 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ó:
- Atualizações: use o LTSC2022, porque o LTSC2019 foi descontinuado pelo
GKE. Entenda o seguinte sobre o LTSC2019:
- Sem atualizações de imagem de nó: o GKE não fornece atualizações de imagem de nó para o LTSC2019 devido a problemas de estabilidade com atualizações da imagem subjacente, já que a Microsoft encerrou o Suporte Principal para a imagem. As imagens de nó do GKE estão fixadas na versão de dezembro de 2025 da imagem subjacente. Para mais informações, consulte Windows Server 2019.
- Compatibilidade com 1.37: para o GKE versão 1.37 e mais recentes, não é possível usar o LTSC2019. Não é possível criar pools de nós com LTSC2019 e com a versão 1.37 nem fazer upgrade de pools de nós LTSC2019 para a versão 1.37.
- 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.
- 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:
- O Windows Server Core e o Nano Server (em inglês) podem ser usados como uma imagem de base para seus contêineres.
- Criar suas imagens de contêiner do servidor 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.
Atualizar e configurar gcloud
Antes de começar, verifique se você realizou as tarefas a seguir:
- Ative 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 o comando
gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
- 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.
Antes de criar um cluster usando pools de nós do Windows Server, consulte a seção Como fazer upgrade de pools de nós do Windows Server.
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 \
--location=CONTROL_PLANE_LOCATION \
--enable-ip-alias \
--num-nodes=NUMBER_OF_NODES \
--cluster-version=VERSION_NUMBER \
--release-channel CHANNEL
Substitua:
CLUSTER_NAME: o nome escolhido para o cluster.CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.--enable-ip-aliasativa 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. Se você não especificar um canal de lançamento, o GKE vai inscrever seu 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, que pode serrapid,regular,stableouNone(descontinuado). Por padrão, o cluster está inscrito no canal de lançamentoregular.
Recomendamos especificar uma conta de serviço do IAM com privilégios mínimos para os nós usarem em vez da conta de serviço padrão do Compute Engine. Para saber como criar uma conta de serviço com privilégios mínimos, consulte Usar uma conta de serviço privilégio mínimo mínimos.
Para especificar uma conta de serviço personalizada na CLI gcloud, adicione a seguinte flag ao comando:
--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.comSubstitua SERVICE_ACCOUNT_NAME pelo nome da sua conta de serviço com privilégios mínimos.
Crie o pool de nós do Windows Server com os seguintes campos:
gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION \
--image-type=WINDOWS_LTSC_CONTAINERD \
--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.CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.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-microeg1-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: uma flag opcional que define a versão do SO Windows a ser usada para o tipo de imagemWINDOWS_LTSC_CONTAINERD. Para a versão 1.37 e mais recentes do GKE, só é possível usar o LTSC2022 (ltsc2022). Para a versão 1.36 ou anterior, recomendamos definir explicitamente o valor comoltsc2022. Caso contrário, o GKE usa o LTSC2019 (ltsc2019), que não é recomendado porque está descontinuado pelo GKE.
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 \
--location=us-central1 \
--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 \
--location=us-central1 \
--windows-os-version=ltsc2022
Console
- No console do Google Cloud , acesse a página Criar um cluster do Kubernetes.
- Na seção Princípios básicos do cluster, faça o seguinte:
- Insira o Nome do cluster.
- Em Tipo de local, selecione uma região ou zona para o cluster.
- Em Canais de lançamento, selecione um Canal de lançamento e, opcionalmente, uma Versão de destino.
- 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, faça o seguinte:
- Insira um Nome para o pool de nós.
- 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 a seguinte imagem de nó:
- Windows Long Term Servicing 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-microeg1-smallnã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, 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 (descontinuado pelo GKE). 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 \
--location CONTROL_PLANE_LOCATION
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 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 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 \ CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATIONSubstitua:
CLUSTER_NAME: o nome do cluster.NODE_POOL_NAME: o nome do pool de nós do Windows Server.CONTROL_PLANE_LOCATION: o local do Compute Engine do plano de controle do cluster. Forneça uma região para clusters regionais ou uma zona para clusters zonais.
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 \ --location=$CONTROL_PLANE_LOCATION \ --format="value(version)"`Consiga 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\")"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: 2024Consiga a versão do Windows Server para o tipo de imagem
WINDOWS_LTSC:gcloud beta container get-server-config \ --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \ --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_LTSC" \ --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"O resultado será o seguinte:
10.0.17763.1577
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. Confira as recomendações a seguir sobre como fazer upgrade desse tipo de pool de nós:
- Impeça os upgrades automáticos de nós, se necessário, com exclusões de manutenção.
- Para garantir que suas imagens de contêiner permaneçam compatíveis com seus nós, 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.
- Se você estiver impedindo os upgrades automáticos de nós, faça upgrades manuais do pool de nós regularmente, porque os nós não podem estar mais de duas versões secundárias atrás da versão do plano de controle.
- Para receber atualizações proativamente sobre novas versões do GKE e as versões do sistema operacional Windows que elas usam, inscreva-se para receber notificações de upgrade.
- Permita que o GKE faça upgrades automáticos de nós somente se você criar continuamente imagens de contêiner do servidor do Windows Server de multiarquiteturas que visam as versões mais recentes do Windows Server. Os upgrades automáticos de nós não costumam 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 $gmsaNameSubstitua:
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_NAMEforwebapp01e o domínio forexample.com,DNS_HOST_NAMEserá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 o console Google Cloud .
gcloud
gcloud container node-pools delete NODE_POOL_NAME \
--cluster=CLUSTER_NAME
--location=CONTROL_PLANE_LOCATION
Console
Para excluir um pool de nós do Windows Server usando o Google Cloud console, siga estas etapas:
Acesse a página do 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
Os seguintes recursos não são compatíveis com os pools de nós do Windows Server:
Recursos de computação e nós:
Recursos de rede:
- Configurar o máximo de pods por nó acima do limite padrão de 110
- Visibilidade intranós
- Nó local e cache DNS
- Geração de registros de política de rede
- Agente de mascaramento de IP. Os nós do Windows realizam o mascaramento de IP para destinos externos, mas o agente não é compatível.
- Rede de pilha dupla IPv4/IPv6. A rede IPv6 não é compatível com nós do Windows.
- Uso particular de endereços IP de classe E
- Uso particular de endereços IP públicos
- Suporte completo ao GKE Dataplane V2. Os nós do Windows com o GKE Dataplane V2 são limitados à aplicação da política de rede, além das limitações descritas no documento referenciado.
Recursos de segurança:
- Confidential GKE Nodes
- Recursos de segurança específicos do Linux (por exemplo, Seccomp, Apparmor e SELinux)
Recursos do Kubernetes
- Namespaces de host (por exemplo, hostNetwork, hostPID e hostIPC). Esses não são compatíveis com o sistema operacional Windows.
- Kubernetes
service.spec.sessionAffinity - Recursos listados na seção Compatibilidade e limitações do documento "Contêineres do Windows no Kubernetes"
Recursos de armazenamento:
- O fstype padrão (ext4), que é usado com o tipo de disco permanente equilibrado. Para mais informações, consulte StorageClasses.
- Driver CSI do Filestore
- SSD local com interfaces NVMe para armazenamento temporário
Recursos de observabilidade:
- Os rótulos de pod do Kubernetes não aparecem nos registros de carga de trabalho para nós do Windows se a porta somente leitura do kubelet estiver desativada, porque o agente de geração de registros não consegue recuperar os rótulos de pod.
Recursos da Microsoft:
Diversos:
- Proxy do CloudSQL Auth baseado em Docker
- Não é possível criar um cluster com apenas pools de nós do Windows Server. É necessário ter pelo menos um pool de nós do Linux.
Para limitações específicas com outros produtos do Google Cloud que você pode querer usar com clusters do GKE, consulte a documentação respectiva desse produto.
Solução de problemas
Para orientações de solução de problemas específicas para pools de nós do Windows Server, consulte Resolver problemas em pools de nós do Windows Server.
Para orientações gerais, consulte a documentação do Kubernetes sobre depuração de pods e serviços.
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.