Guia do usuário para pools de nós do SO do Windows Server

Com clusters do Anthos no VMware (GKE no local), é possível criar um pool de nós do SO Windows Server. O cluster de usuário que executa os pools de nós do Windows Server OS também pode executar pools que contenham nós usando o Ubuntu ou o Container-Optimized OS.

Requisitos para um pool de nós do SO Windows Server

Os nós em um pool precisam usar o mesmo sistema operacional, indicado pelo parâmetro osImageType.

Antes de criar, no cluster de usuário, um pool de nós que tenha nós do SO do Windows Server, verifique se você atende a estes requisitos:

  • Um cluster de administrador já precisa estar em vigor antes de ser possível criar um pool de nós do Windows, porque um pool de nós do Windows é compatível apenas com o cluster de usuário.
  • O cluster do usuário precisa executar pelo menos um pool de nós do Linux, porque o pool de nós do Linux é necessário para criar um pool de nós do Windows.
  • Um cluster de usuário com pools de nós do Windows precisa ter o campo enabledataplanev2 definido como true no arquivo de configuração do cluster de usuário. Isso ativa o Dataplane V2 nos nós do Linux nesse cluster.

  • Se você quiser que o Windows Dataplane V2 seja ativado para os pools de nós do Windows no cluster de usuários, o arquivo de configuração do cluster de usuário precisará ter o campo enableWindowsDataplaneV2 definido como true. Se você ativar esse recurso, sua vSwitch (especificada com network.vCenter.networkName no arquivo de configuração do cluster de usuário) precisará ter o aprendizado MAC ativado.

  • Você fez o download de um ISO do Windows Server 2019 da Microsoft para criar um modelo de VM específico para os pools de nós do Windows. A tag de idioma/região da ISO precisa ser en-US.

  • Seu ambiente do vSphere precisa ser o vSphere 6.7, a atualização 3 ou posterior.

Criar um pool de nós do Windows em um cluster de usuário

Etapa 1: criar o modelo de VM do Windows para clusters do Anthos no VMware

Antes de começar, verifique se você já criou um cluster de administrador.

  1. Crie um modelo de VM base do Windows no Windows Server 2019 ISO.

    • O tipo de adaptador de rede inicial para a VM do Windows para instalar o Windows Server 2019 ISO precisa ser E1000E.
    • Siga estas etapas: Criar um modelo do VMware vSphere para Windows Server 2019.
    • Anote a senha inicial definida quando você executa o instalador do Windows ISO para usá-la no futuro.
    • Verifique se você está usando a versão de patch mais recente qualificada para o Windows Server 2019, 10.0.17763.2114. Consulte Processo de patch de segurança.
    • Não é possível anexar nenhum dispositivo que usa o controlador de IDE ao modelo de VM base.

  2. Instale o VMware Tools no modelo base de VM do Windows, se ainda não estiver instalado, usando as instruções do VMWare.

  3. Crie um modelo de VM do Windows: 

    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG_PATH

  4. Na última linha da saída do comando, é possível encontrar o nome do modelo de VM do Windows gerado. Anote o nome para uso futuro. O nome tem o seguinte formato:

Successfully created Anthos Windows VM template "gke-on-prem-windows-server-2019-VERSION"

Etapa 2: fazer upload de imagens de contêiner do Windows para o registro particular

Pule esta etapa se você não estiver usando um registro particular.

É possível automatizar o upload de imagens de contêiner do Windows para um registro particular usando o containerd em uma estação de trabalho de administrador do Linux. No entanto, o containerd não pode enviar a camada base da imagem do contêiner do Windows. Isso significa que as camadas base precisam ser extraídas do registro da Microsoft ao extrair a imagem. Para enviar as camadas de base, siga as etapas da Opção 2.

Opção 1: se você não precisar enviar manualmente as imagens da camada de base do Windows para o registro particular:

gkectl prepare --config <var class="edit">ADMIN_CLUSTER_CONFIG</var> --upload-windows-images

Substitua ADMIN_CLUSTER_CONFIG pelo caminho para o arquivo de configuração do cluster de administrador.

A sinalização --upload-windows-images especifica que as imagens de contêiner do Windows serão enviadas. Somente imagens de contêiner do Linux serão enviadas para o registro particular sem especificar essa sinalização.

Opção 2: se você precisar enviar manualmente as imagens da camada de base do Windows para o registro particular:

  • Use uma máquina Windows com o Docker instalado e com acesso a gcr.io antes de seguir estas etapas. Só é possível extrair imagens de contêiner do Windows para uma máquina Windows.
  • Execute docker login para autenticar no seu registro particular.

  • Faça upload das imagens do contêiner do Windows com as camadas de base para o registro particular seguindo estas etapas:

    • Acesse o arquivo daemon.json do Docker no seu computador Windows: 

      PS C:> cat C:\ProgramData\docker\config\daemon.json

    • Adicione as seguintes linhas para configurar o arquivo daemon.json do Docker para permitir o envio de camadas estrangeiras para seu registro particular:

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • Faça o download das imagens necessárias do Windows Container para sua máquina local do Windows, depois marque-as e as envie para o registro particular. As alterações feitas no arquivo de configuração do Docker daemon.json significam que a camada base pode ser enviada para o registro particular. Para concluir essas tarefas, execute os seguintes comandos:
# Pull the Windows container images
docker pull gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019
docker pull gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker pull gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Tag the images to use private registry
docker tag gcr.io/gke-on-prem-release/pause-win:gke_windows_pause_20210302_RC00_2019 $PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker tag gcr.io/gke-on-prem-release/fluent-bit-win:v1.8.3-gke.1_ltsc2019 $PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker tag gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0_2019 $PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

# Push to private registry
docker push PRIVATE_REGISTRY_URL/pause-win:gke_windows_pause_20210302_RC00_2019
docker push PRIVATE_REGISTRY_URL/fluent-bit-win:v1.8.3-gke.1_ltsc2019
docker push PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0_2019

Etapa 3: (obrigatório se estiver usando proxy) Permitir a listagem de URLs para criar pools de nós do Windows

Se o cluster estiver protegido por um servidor proxy, adicione esses URLs à lista de permissões do servidor proxy, além dos outros endereços exigidos pelos clusters do Anthos no VMware.

# Microsoft registry URLs, needed by every Windows node if using GCR
mcr.microsoft.com
.data.mcr.microsoft.com
go.microsoft.com
winlayers.cdn.mscr.io

# Microsoft WSUS server URLs, needed by `gkectl prepare windows` on the Windows VM
windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.windowsupdate.microsoft.com
.update.microsoft.com
.windowsupdate.com
download.windowsupdate.com
download.microsoft.com
.download.windowsupdate.com
wustat.windows.com
ntservicepack.microsoft.com
go.microsoft.com
dl.delivery.mp.microsoft.com

# Cloudbase-Init URL, needed by `gkectl prepare windows` on the Windows VM
https://cloudbase.it

# Powershell Gallery URLs, needed by `gkectl prepare windows` on the Windows VM
psg-prod-eastus.azureedge.net
az818661.vo.msecnd.net
devopsgallerystorage.blob.core.windows.net
.powershellgallery.com

# Windows Update Service, needed by `gkectl prepare windows` on the Windows VM
onegetcdn.azureedge.net
sws.update.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
fe3.delivery.mp.microsoft.com
.prod.do.dsp.mp.microsoft.com
emdl.ws.microsoft.com
adl.windows.com
activation-v2.sls.microsoft.com
crl.microsoft.com
ocsp.digicert.com
ctldl.windowsupdate.com
login.live.com
licensing.mp.microsoft.com
www.msftconnecttest.com
settings-win.data.microsoft.com
wdcp.microsoft.com
smartscreen-prod.microsoft.com
checkappexec.microsoft.com
arc.msn.com
ris.api.iris.microsoft.com
.tlu.dl.delivery.mp.microsoft.com
.au.windowsupdate.com
www.microsoft.com
fe3.delivery.dsp.mp.microsoft.com.nsatc.net
cs9.wac.phicdn.net
geo-prod.do.dsp.mp.microsoft.com
slscr.update.microsoft.com
v10.events.data.microsoft.com

# Access for Installing docker, needed by `gkectl prepare windows` on the Windows VM
dockermsft.azureedge.net

Etapa 4: adicionar um pool de nós do Windows ao arquivo de configuração do cluster de usuário

  1. O Dataplane V2 precisa estar ativado no cluster de usuário para usar os pools de nós do Windows. Adicione a seguinte linha ao arquivo de configuração do cluster de usuário para ativar o Dataplane V2:

    enableDataplaneV2: true

  2. Adicione um pool de nós do Windows à seção nodePools no arquivo de configuração do cluster de usuário. Pelo menos um pool de nós do Linux é necessário além dos pools de nós do Windows. Defina os campos osImage e osImageType para criar pools de nós do Windows:

  • osImage: substitua WINDOWS_VM_TEMPLATE_NAME pelo nome do modelo de VM do Windows preparado na etapa 1, que precisa estar no mesmo armazenamento de dados do vCenter especificado no arquivo de configuração do cluster de usuário.
  • osImageType: especifique o tipo de imagem do SO como windows.
# user-cluster.yaml

nodePools:
- name: windows-nodepool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  bootDiskSizeGB: 100
  osImage: WINDOWS_VM_TEMPLATE_NAME
  osImageType: windows

Etapa 5: criar pools de nós do Windows

Antes de criar pools de nós do Windows, execute uma lista de validadores de simulação para o Windows. Pule esta etapa se você já tiver um cluster de usuário. - (Opcional) Execute as verificações de simulação rápidas e lentas para criar uma VM de teste para Windows e validar o modelo de VM do Windows:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • Esse comando destina-se a você executar antes de criar um cluster de usuário. Se você já tiver um cluster de usuário, algumas verificações poderão falhar. Por exemplo, os endereços IP no arquivo hostconfig.yaml já podem estar em uso pelos nós existentes no cluster de usuário.
  • Embora não seja recomendado, é possível ignorar as verificações de simulação do Windows com a sinalização --skip-validation-windows.
  • O gerenciamento de pools de nós do Windows é igual ao dos pools de nós do Linux. Consulte Como gerenciar pools de nós. Os comandos para criar, atualizar e fazer upgrade de clusters e pools de nós também permanecem os mesmos e estão listados aqui.
# Create a new cluster
gkectl create cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Update an existing cluster with the new Windows node pool
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

# Upgrade an existing cluster with the new Windows node pool
gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Etapa 6: validar os nós do Windows em execução

  1. Verifique se os nós do Windows foram criados e se são Ready.

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. Diagnóstico do cluster de usuários para verificar se ele está íntegro.

    gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG  --cluster-name CLUSTER_NAME

Implantar um pod do Windows

Os nós do Windows Server estão tainted com este par de chave-valor: node.kubernetes.io/os=windows:NoSchedule.

Esse taint garante que o programador do GKE não tente executar contêineres do Linux em nós do Windows Server. Para programar contêineres do Windows Server em nós do Windows Server, o arquivo de manifesto precisa incluir esta seção nodeSelector:

nodeSelector:
    kubernetes.io/os: windows

Um nodeSelector configurado, um webhook de admissão em execução no cluster verifica novas cargas de trabalho quanto à presença desse seletor de nós do Windows e, quando encontrado, aplica a tolerância à carga de trabalho a seguir, que permite a execução nos nós do Windows Server corrompidos:

tolerations:
- key: "node.kubernetes.io/os"
  operator: "Equal"
  value: "windows"
  effect: "NoSchedule"

Etapa 1: criar um arquivo de implantação do Internet Information Services (IIS)

Veja uma configuração de amostra, que implanta a imagem oficial da Microsoft de IIS em apenas um pod.

Crie um arquivo IIS chamado iis.yaml com o seguinte conteúdo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: iis
  name: iis
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: iis
  sessionAffinity: None
  type: LoadBalancer
  loadBalancerIP: [Fill in with an available IP address]

Etapa 2: criar a implantação e expô-la por meio de um serviço

# Create the deployment
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG create -f iis.yaml

Etapa 3: validar o pod

Verifique o status do pod usando kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Aguarde até que a saída retornada mostre que o pod tem o status "Running".

NAME                   READY     STATUS    RESTARTS   AGE
iis-5c997657fb-w95dl   1/1       Running   0          28s

Receba o status do serviço e aguarde até que o campo de IP externo seja preenchido.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

Saída esperada:

NAME   TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
iis    LoadBalancer   10.44.2.112   35.x.x.x     80:32233/TCP   17s

Você pode usar o navegador para abrir http://EXTERNAL_IP e ver a página da Web do IIS.

Fazer upgrade do cluster de usuário com pools de nós do Windows

O processo de upgrade para um cluster de usuários com pools de nós do Windows é semelhante ao de upgrades para clusters de usuários somente do Linux, exceto pelo fato de que é necessário criar um modelo de VM do Windows a partir de um modelo de VM base antes de fazer upgrade.

É possível atualizar a versão de compilação do patch do modelo de VM base durante o upgrade fazendo o download de uma versão de patch mais recente do Windows Server 2019 da Microsoft como um patch de segurança. Consulte Processo de patch de segurança.

gkectl prepare windows --base-vm-template $BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Execute o comando abaixo para fazer upgrade do cluster de usuário:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua:

  • ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do administrador
  • ADMIN_CLUSTER_CONFIG pelo caminho do arquivo de configuração do cluster de administrador

Como acessar nós do Windows

A maneira padrão de acessar nós do Windows é com um nome de usuário e senha, que difere dos nós do Linux, que normalmente são acessados por meio de pares de chaves ssh para autenticação.

Para nós do Windows no vSphere, o nome de usuário é Administrator. A senha é gerada pelo clusterapi-controller e armazenada no secret windows-node-password no namespace do usuário do cluster de administrador. O comando para receber a senha desse secret é:

kubectl get secret windows-node-password -n [USER_CLUSTER_NAME] --kubeconfig admin-kubeconfig.yaml -o jsonpath={.data.*} | base64 -d

Você também pode usar a senha usando a interface do usuário do vCenter. Navegue até a VM em que você quer fazer login e encontre a senha na propriedade password do vApp dessa VM.

Quando você tiver o nome de usuário e a senha, poderá acessar sua VM do Windows usando uma das seguintes abordagens:

Como usar o protocolo da área de trabalho remota

Como o RDP foi ativado durante a criação do modelo, você pode acessar sua VM do Windows usando um cliente RDP.

Como usar SSH

Para usar ssh em uma VM do Windows:

ssh Administrator@[VM_IP_ADDRESS]

Siga a solicitação para digitar a senha para se conectar à VM.

Como transferir arquivos de e para sua VM do Windows

É possível transferir arquivos de e para a VM do Windows via SCP:

Faça upload de arquivos para a VM do Windows:

scp [LOCAL_FILE_PATH] Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH]

Faça o download de arquivos da VM do Windows:

scp Administrator@[VM_IP_ADDRESS]:/[REMOTE_FILE_PATH] [LOCAL_FILE_PATH]

Digite a senha quando solicitada.

Como alternativa, também é possível transferir arquivos usando o Cloud Storage ou o RDP, conforme descrito em Como transferir arquivos para VMs do Windows.

Solução de problemas

Não foi possível usar o SSH/RDP para a VM do Windows

Verifique se a VM tem uma conexão de rede executando Test-NetConnection no console da Web do vCenter.

O resultado deverá conter PingSucceeded: true se houver uma conexão de rede. Se a VM não tiver uma conexão de rede, verifique o adaptador de rede usado para esta VM. Verifique se a rede permite conexões de entrada com a VM da estação de trabalho em que você quer executar o SSH/RDP.

Verifique se o kubelet, o kube-proxy e o flanneld estão em execução na VM do Windows.

Siga estas etapas para se conectar à VM e execute os seguintes comandos:

# Check that kubelet and kube-proxy services have status 'Running'
Get-Service kubelet
Get-Service kube-proxy
# Check that the flanneld process exists
Get-Process flanneld

Como usar a ferramenta de snapshot

Use a ferramenta de snapshot para capturar o tarball. Esse tarball contém os arquivos de registro nos nós, bem como saídas para comandos de solução de problemas em execução no nó.

gkectl diagnose snapshot --scenario system-with-logs --cluster-name [USER_CLUSTER_NAME] --kubeconfig [PATH_TO_KUBECONFIG]

Falha na criação da VM do Windows

Verifique os registros do contêiner vsphere-controller-manager no pod clusterapi-controllers no namespace do usuário do cluster de administrador.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME logs clusterapi-controllers-POD_NAME_SUFFIX vsphere-controller-manager

Verifique se o modelo de VM está localizado no mesmo data center e armazenamento de dados, conforme especificado no arquivo de configuração do cluster de usuário.

A VM do Windows foi criada, mas o nó não foi iniciado corretamente ou não foi exibido

  • Verifique os registros de inicialização no nó localizado em C:\var\log\startup.log para ver se algo falhou ao iniciar.

    • Se o flanneld não estiver em execução, tente executar novamente o script de inicialização localizado em C:\etc\startup\startup-script.ps1
    • Se o kubelet não estiver em execução, verifique os registros do kubelet em "C:\var\log".
    • Se o kube-proxy não estiver em execução, verifique os registros do kube-proxy em C:\var\log.

Geração de registros e monitoramento

Os clusters do Anthos no VMware são compatíveis com o registro e monitoramento para nós e pods do Windows, assim como para nós e pods do Linux.

Quando a geração de registros e o monitoramento estão configurados, os agentes são implantados em nós do Windows. Esses agentes coletam, processam e exportam os registros e as métricas do nó.

Agente do Windows Logging

O agente de geração de registros do Windows coleta os seguintes registros:

  • Tipo de recurso do pod: cargas de trabalho do aplicativo do usuário e do sistema.

    Os registros de cargas de trabalho de aplicativos de usuários do Windows são coletados por padrão. Para desativar os registros do aplicativo:

    • Edite o configmap fluent-bit-windows-config e comente o item [Input] que coleta os registros do aplicativo (o primeiro item [Input]): 
      kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
      Comente todos os campos desse item. Por exemplo: 
      #    [INPUT]
#      # https://docs.fluentbit.io/manual/input/tail
#      Name               tail
#      Tag_Regex          var.log.containers.(?a-z0-9?(?:.a-z0-9?))_(?[^]+)(?.+)-(?[a-z0-9]{64}).log$
#      Tag                k8s_container...
#      Path               C:\var\log\containers\.log
#      Exclude_Path       kube-system.log,gke-connect.log,knative-serving.log,gke-system.log,istio-system.log,monitoring-system.log,config-management-system.log,gatekeeper-system.log,cnrm-system.log
#      DB                 C:\var\log\fluent-bit-k8s-container-application.db
#      Mem_Buf_Limit      30MB
#      Skip_Long_Lines    On
#      Refresh_Interval   10
#      # storage.type       filesystem
#      Buffer_Chunk_Size  512KB
#      Buffer_Max_Size    5M
#      Rotate_Wait        30
#      Ignore_Older       4h
    • Execute o comando rollout restart para reiniciar o daemonset fluent-bit-windows: 
      kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system

  • Tipo de recurso do nó: kubelet, kube-proxy e registros de eventos do Windows

É possível acessar registros usando o Explorador de registros no console. Consulte Registros de acesso para mais informações.

Agente de monitoramento do Windows

O agente de monitoramento do Windows coleta um conjunto diferente de métricas de uso de CPU e memória do que o agente de monitoramento do Linux. Para monitorar o status dos nós e dos pods do Windows, use os painéis preparados. No console, selecione Monitoramento > Painéis e, em seguida, "Status do nó do Windows do GKE On-Prem" e "Status do pod do Windows do GKE On-Prem" na lista Todos os painéis.

Os painéis serão criados automaticamente durante a instalação do cluster de administrador se o Cloud Monitoring estiver ativado. Se você já tiver um cluster de administrador em execução, siga estas instruções para criar esses painéis usando os seguintes arquivos json:

Veja a lista completa de métricas coletadas pelos agentes do Windows.

Armazenamento permanente do Windows

Ao trabalhar com contêineres do Windows Server com armazenamento permanente, é necessário criar um objeto StorageClass e especificar o nome desse objeto no campo storageClassName do objeto PersistentVolumeClaim, já que o StorageClass padrão no cluster de usuário local usa ext4 como o tipo de sistema de arquivos, que só funciona para contêineres do Linux. No Windows, é necessário definir o tipo de sistema de arquivos como ntfs.

Exemplo de classe de armazenamento do Windows:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-storage-class
provisioner: kubernetes.io/vsphere-volume
parameters:
  datastore: my-datastore
  diskformat: thin
  fstype: ntfs

Detector de problemas de nó em nós do Windows

O daemon do detector de problemas do nó está disponível nos nós do Windows. Se você fez upgrade para a versão 1.9, o detector de problemas do nó será ativado automaticamente. O detector de problemas do nó ajuda na detecção rápida de alguns problemas comuns do nó. O detector de problemas do nó continua verificando se há possíveis problemas e os informa como eventos e condições no nó. Quando um nó se comporta de maneira incorreta, você pode usar o comando kubectl para encontrar eventos e condições correspondentes.

As seguintes configurações de monitor estão ativadas para o Node Problem Detector:

Para receber eventos e condições em um nó:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Substitua:

  • KUBECONFIG pelo caminho do arquivo kubeconfig do cluster que contém o nó.
  • NODE_NAME pelo nome do nó.

Para identificar os eventos gerados pelos monitores do detector de problemas do nó, procure o nome do monitor no campo reason de uma regra especificada na seção rules.

Os monitores do detector de problemas do nó também geram as seguintes condições no nó. Cada um deles será definido como true se o detector de problemas do nó detectar o cenário de falha correspondente no nó.

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

Sempre que uma das condições for definida como true, a condição "Pronto" do nó se tornará false, o que impedirá que novos pods sejam programados no nó.

Quando uma condição não íntegra é encontrada, o detector de problemas do nó tenta reparar o nó automaticamente reiniciando o serviço do sistema relevante.

Os registros do detector de problemas do nó estão localizados na pasta C:\var\log\node-problem-detector do nó. Se a geração de registros e o monitoramento estiverem ativados, os registros serão exportados para o Cloud Logging, e você poderá visualizá-los no Explorador de registros.

Use este filtro para acessar os registros do detector de problemas do Node no Explorador de registros:

resource.type="k8s_node"
log_name="projects/PROJECT_NAME/logs/node-problem-detector"

Substitua PROJECT_NAME pelo nome do projeto.

Processo de patch de segurança

Além das versões regulares para as versões compatíveis do Anthos, a equipe do Anthos também qualifica continuamente as atualizações mais recentes do patch do Windows durante períodos que não são de lançamento e publica os resultados para sua referência. Se uma atualização de patch de segurança urgente for necessária entre as versões de patch do Anthos, você poderá criar um novo modelo de VM usando a versão mais recente e executar uma atualização contínua para os pools de nós do Windows existentes para usar o novo modelo.

O processo de patch de segurança inclui estas etapas:

  • A Microsoft lançou um novo patch de segurança para o Windows Server 2019.
  • O Anthos qualifica a versão mais recente do patch de segurança e anuncia o resultado da qualificação.
  • Se qualificado, os usuários:
    • Fazer o download da versão de patch mais recente no site da Microsoft
    • Crie um novo modelo de VM do Windows usando essa versão do patch seguindo estas etapas.
    • Atualize os pools de nós do Windows para usar o novo modelo executando:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

  • Se a nova versão exigir alterações do lado do Anthos, aguarde a próxima versão mensal do patch do Anthos e faça upgrade dos clusters.

  • Se a nova versão do Windows não for compatível com o Anthos, a equipe do Anthos pulará essa versão e aguardará a próxima atualização de segurança da Microsoft.

Junção de domínio do Active Directory

A associação ao domínio do Active Directory exige que o comprimento do nome do host da VM seja <= 15 caracteres. Para o modo IPAM, como o nome do host da VM está definido no arquivo de configuração do cluster de usuário, você precisa garantir que o comprimento seja menor que 15 caracteres. Essas instruções são baseadas nas instruções para criar pools de nós do Windows, com a etapa adicional de fornecer um script personalizado durante a criação do modelo de VM do Windows.

Verificar se o servidor DNS do domínio ativo pode ser acessado

O Active Directory Domain Services (AD DS) usa serviços de resolução de nomes do Sistema de Nome de Domínio (DNS) para permitir que os clientes localizem controladores de domínio e para os controladores de domínio que hospedam o serviço de diretório para se comunicarem entre si.

O servidor DNS foi criado quando o papel do AD DS instalou a floresta raiz. Para que qualquer VM do Windows participe do domínio do AD, ela precisa conseguir acessar o servidor DNS. Defina as configurações de DNS e firewall seguindo as orientações do provedor de serviços de DNS que você está usando. É possível verificar se as VMs do Windows na rede atual podem entrar em contato com o servidor DNS do domínio do AD executando este comando:

PS C:\> nslookup DOMAIN_NAME DOMAIN_SERVER_IP
Server:  example-1-2-3-4.anthos
Address:  1.2.3.4
Name:    example.org
Address:  1.2.3.4

Etapa 1: criar um modelo de VM do Windows com um script personalizado

  1. Execute um script personalizado antes que o nó do Windows ingresse no cluster de usuário da associação de domínio do Active Directory. Armazene esse script em um caminho local na estação de trabalho de administrador. Observações:

    • É possível substituir o script pelo seu próprio script para fazer a associação ao domínio do Active Directory.
    • É recomendável usar uma conta de usuário com as permissões mínimas necessárias para participar de um domínio do Active Directory, em vez de usar um usuário Administrador.
    • (Opcional) Para evitar o armazenamento da senha como texto simples nesse script, coloque-a em um arquivo no modelo de VM, deixe o script ler esse arquivo de senha e exclua o arquivo após a associação ao domínio.
    $domain = "[DOMAIN_NAME]"
$password = "[PASSWORD]" | ConvertTo-SecureString -asPlainText -Force
$username = "$domain\[USERNAME]"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential -restart –force

  2. Crie um modelo de VM do Windows com um script personalizado:

    gkectl prepare windows --base-vm-template BASE_WINDOWS_VM_TEMPLATE_NAME --bundle-path BUNDLE_PATH --kubeconfig ADMIN_CLUSTER_KUBECONFIG --customized-script CUSTOMIZED_SCRIPT_PATH

Substitua BUNDLE_PATH pelo caminho para o pacote.

Etapa 2: criar um pool de nós do Windows

Continue com as instruções padrão das Etapas 2 a 6 para criar um pool de nós do Windows usando o modelo personalizado de VM do Windows.

Etapa 3: verificar a junção do domínio ativo para os nós do Windows

Na VM do controlador de domínio do AD, execute o seguinte comando:

PS C:\> Get-ADComputer -Filter 'Name -like "user-host-prefix*"'

DistinguishedName : CN=AD-VM-1,CN=Computers,DC=example,DC=org
DNSHostName       : ad-vm-1.example.org
Enabled           : True
Name              : AD-VM-1
ObjectClass       : computer
ObjectGUID        : b3609717-d24b-4df6-bccb-26ca8e8b9eb0
SamAccountName    : AD-VM-1$
SID               : S-1-5-21-3236879623-1561052741-2808297733-1103

Etapa 4: configurar contas de serviço gerenciadas em grupo (opcional)

Siga estas instruções: Configurar o GMSA para pods e contêineres do Windows. Você pode configurar o GMSA para pods e contêineres do Windows após os nós serem mesclados ao domínio.

Solução de problemas

Os registros da execução do script personalizado do cloudbase-init estão localizados em C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log. Procure LocalScriptPlugin no arquivo de registros e verifique os registros relacionados. - Crie um novo modelo de VM do Windows. - Atualize os pools de nós do Windows para usar o novo modelo executando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Considerações sobre contêineres do Windows

Algumas diferenças notáveis entre os contêineres do Windows e do Linux são:

  • Compatibilidade de versão das imagens de contêiner do Windows e das imagens do SO host/nó.
    • A tupla da versão do SO Windows Server tem quatro partes: principal, secundária, de compilação e revisão.
    • A imagem base do contêiner do servidor Windows precisa corresponder às três primeiras partes da tupla da versão da imagem do SO host. A revisão não precisa corresponder, embora seja recomendado atualizar as imagens de base do host e do contêiner.
    • Os usuários precisam recriar as imagens de contêiner sempre que a versão da imagem do SO for alterada
  • Contêineres privilegiados e namespaces de host não são compatíveis.
    • Os usuários não podem configurar/alterar os nós implantando contêineres, como os Daemonsets.

Limitações para clusters do Anthos no VMware no vSphere Windows

  • Os clusters de usuário precisam conter pelo menos um pool de nós do Linux.

    • Não é possível criar um cluster com apenas um pool de nós do Windows
    • Os pools de nós do Linux são necessários para executar complementos essenciais.

  • Como os recursos do Windows são 1,5 vezes mais reservados do que os do Linux, os recursos alocáveis para Windows são menores.

  • O uso de nós do Windows pode exigir um tamanho mínimo de máquina maior do que os clusters do Anthos no tamanho mínimo da máquina do VMware Linux. Os nós do Windows normalmente exigem mais recursos devido à maior sobrecarga na execução de componentes/serviços de nó.

Problemas conhecidos

Esta seção lista problemas conhecidos com nós do Windows usados com clusters do Anthos no VMware, além de soluções alternativas para evitar ou se recuperar desses problemas.

Os pods do Windows não podem se comunicar com endereços IP externos

Esse problema está descrito na documentação da Microsoft, que declara "Você precisa excluir o IP externo que está tentando consultar na ExceptionList".

Entre em contato com o suporte do Google Cloud para receber uma solução alternativa.

Os contêineres do Windows não são limpos após a remoção de pods do Windows.

Esse é um problema conhecido, em que o Docker RemoveContainer também tenta chamar CreateFile no Windows. Como solução alternativa, faça login no nó do Windows que apresenta o problema, execute Restart-Service docker, e o problema será reduzido. A partir dos clusters do Anthos no VMware 1.9, a versão da imagem de contêiner fluent-bit-win e a versão do Docker foram atualizadas para acompanhar as correções upstream do problema, e isso não reproduzirá mais. Se você encontrar esse problema, entre em contato com o Suporte do Google Cloud.

Nós do Windows com conflitos de endereço IP

Esse é um problema conhecido que raramente acontece. Se isso ocorrer durante a criação do pool de nós do Windows, siga estas etapas para mitigá-lo:

  • Se você estiver usando o modo IPAM, poderá remover manualmente as VMs que têm conflitos de IP no vCenter. Novas VMs serão criadas automaticamente, o que deverá ter as alocações de IP corretas. Ou você pode simplesmente esperar pelo reparo automático de nó para detectar esse problema e recriar os nós do Windows.

  • Se você estiver usando o modo DHCP, as VMs recém-criadas provavelmente terão IPs duplicados novamente, já que o servidor DHCP está tendo problemas para alocação de IP, é possível excluir o pool de nós do Windows pendente executando gkectl update cluster e adicionando-o novamente em user-cluster.yaml, execute gkectl update cluster novamente para criá-lo, o pool de nós recém-criado precisa ter alocações de IP corretas.

O nó do Windows se torna NotReady depois da reinicialização da VM

Atualmente, esse script só é executado pela primeira vez que a VM é ligada. Portanto, se você reiniciar a VM, o script não será executado. Isso fará com que alguns serviços do Windows parem de funcionar, incluindo o kubelet e os serviços kube-proxy, entre outros. Assim, o nó estará no status NotReady. Se você estiver usando o Windows Dataplane V2, a rede desatualizada também precisará ser limpa antes que os serviços do Dataplane V2 sejam reiniciadas. Em seguida, será necessário executar um script para limpeza, o que pode complicar ainda mais. Sugerimos que você recrie o nó. Como alternativa, é possível excluir o nó executando o comando abaixo e aguardando a recriação automática do controlador.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

Falha ao preparar o modelo de VM em clusters com um registro particular

Ao executar gkectl prepare windows em clusters com um registro particular, a operação pode falhar com o seguinte erro:

Failed to prepare your Windows environment: failed to create Anthos Windows VM template: failed to setup Windows VM template: failed to preload docker container images: failed to run "powershell.exe Get-Content 'C:\ProgramData\docker\config\registry-key.json' | docker login --username="" --password-stdin """ on VM "": timed out waiting for the condition

Isso está acontecendo porque a VM do Windows usada durante o comando gkectl prepare windows não foi atualizada com o certificado raiz de registro particular. Portanto, o comando docker login falha.

Veja algumas soluções alternativas:

  • Faça upload do arquivo de certificado de CA para o modelo de VM base antes de executar gkectl prepare windows. O caminho do arquivo deve ser C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt.

  • Execute o comando gkectl prepare windows. Quando aparecer o erro, conecte-se via SSH à VM do Windows e faça upload do arquivo de certificado de CA. O caminho do arquivo precisa ser C:\ProgramData\docker\certs.d\<private-registry-server>\ca.crt.