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

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

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

Requisitos para um pool de nós do SO do 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:

• Seu cluster de usuário que executa o pool de nós do Windows precisa ser clusters do Anthos no VMware versão 1.8 ou posterior.
• Seu cluster de administrador que controla esse cluster de usuário precisa ser a versão 1.7 ou posterior.
• 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.

• Os clusters de usuário com pools de nós do Windows precisam ter o dataplane V2 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.

Observação: o IPv6 não é compatível.

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

Observação: as imagens de contêiner do Windows não estão disponíveis como um pacote com a camada de base, também conhecida como camada externa, proveniente do registro da Microsoft. Isso ocorre porque a imagem da camada base do registro da Microsoft não pode ser redistribuída. Por isso, extraia a imagem da camada base do Google Container Registry (GCR).

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 mais recente do patch para o Windows Server 2019, 10.0.17763.1999, que foi qualificada para clusters Anthos no VMware versão 1.8.0. 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.
   • Se você estiver usando a versão do Windows >= 10.0.17763.1757, consulte esta solução alternativa.

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_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-10.0.17763.1999-1.8.0-gke.25"

Observação: o build do modelo de VM do Windows é um recurso de visualização, com um problema conhecido e uma solução alternativa. Consulte Problemas conhecidos.

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.

O uso de um registro privado tem os seguintes requisitos:

• Use uma máquina Windows com o Docker instalado e com acesso a gcr.io antes de tentar esta etapa, porque só é possível extrair imagens do Windows Container 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:1.6.1
docker pull gcr.io/gke-on-prem-release/fluent-bit-win:v1.7.7-gke.2_ltsc2019
docker pull gcr.io/gke-on-prem-release/gke-metrics-agent-windows:0.3.10-gke.0

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

# Push to private registry
docker push PRIVATE_REGISTRY_URL/pause-win:1.6.1
docker push PRIVATE_REGISTRY_URL/fluent-bit-win:v1.7.7-gke.2_ltsc2019
docker push PRIVATE_REGISTRY_URL/gke-metrics-agent-windows:0.3.10-gke.0

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

Observação: veja uma lista completa de URLs usados pelo Windows Server.

Observação: para a estação de trabalho de administrador, é preciso permitir que a estação de trabalho de administrador e o host de salto acessem o IP do host ESXi no qual a VM do Windows é executada para que você possa executar gkectl prepare windows.

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
  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. - (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_KUBECONFIG

• 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_KUBECONFIG --config USER_CLUSTER_CONFIG

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

# Upgrade an existing cluster with the new Windows node pool
gkectl upgrade cluster --kubeconfig ADMIN_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_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.

Observação: as imagens de contêiner do Windows precisam ser criadas no Windows Server 2019 para serem executadas nos pools de nós do Windows. Consulte Como corresponder a versão do host do contêiner com as versões da imagem do contêiner.

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.

Aviso: o modelo de VM base deve ser um modelo de VM vazio do Windows Server 2019. Não reutilize o modelo de VM do Windows atual usado pelos pools de nós atuais para criar um novo modelo de VM.

É 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_PATH

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

gkectl upgrade cluster --kubeconfig $ADMIN_KUBECONFIG --config $USER_CLUSTER_SEED_CONFIG

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

Observação: o acesso RDP (Remote Desktop Protocol) é ativado durante a criação do modelo de VM do Windows em gkectl prepare windows. Também será necessário garantir que suas regras de firewall permitam acesso RDP na porta TCP 3389.

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

Observação o servidor SSH é instalado durante a criação do modelo de VM do Windows em gkectl prepare windows. Portanto, use o SSH para a VM do Windows usando esse servidor 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_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:\Program Files\Cloudbase Solutions\Cloudbase-Init\startup.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:

• windows_pod_status.json
• windows_node_status.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

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_KUBECONFIG --config $USER_CLUSTER_SEED_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
   

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_KUBECONFIG --config $USER_CLUSTER_SEED_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

Nesta seção, listamos os problemas conhecidos dos nós do Windows usados com clusters do Anthos no VMware, além de maneiras de evitar ou recuperar esses problemas.

Serviço do Windows Update desativado por padrão a partir da versão 10.0.17763.1757

Como o serviço Windows Update está desativado por padrão a partir da versão 10.0.17763.1757, ele interrompe o build do modelo de VM do Windows, que tenta interromper a execução do serviço. Você verá a mensagem de erro "O serviço não foi iniciado".

Como alternativa, inicie manualmente esse serviço no modelo básico de VM do Windows se você estiver usando a versão 10.0.17763.1757 ou posterior. Execute este comando para iniciar o serviço do Windows Update:

sc.exe config wuauserv start= auto
Start-Service wuauserv

O build do modelo de VM do Windows trava enquanto aguarda a desativação da VM

O build do modelo de VM do Windows aguarda a desativação por cerca de 40 minutos. Continue aguardando, e o comando será concluído após um período.

Incompatibilidade do nome da interface de rede do Windows causa problema durante a inicialização do nó

Atualmente, Ethernet0 2 é usado como o nome da interface de rede durante a inicialização do nó. Se o nome da interface de rede real não for Ethernet0 2, o nó falhará até inicializar e não poderá participar do cluster de usuário. Se o tipo de adaptador de rede original no modelo de VM base já for VMXNET 3, o nome da interface de rede será Ethernet0 durante a inicialização do nó e, portanto, não corresponderá ao nome esperado Ethernet0 2.

Como solução alternativa, verifique se o tipo de adaptador de rede inicial especificado ao criar a VM do Windows para instalar o Windows Server 2019 ISO está usando E1000E. Como alternativa, faça login manualmente em cada nó do Windows, renomeie a interface de rede para Ethernet0 2 e execute novamente o script de inicialização.

Rename-NetAdapter -Name 'Ethernet0' -NewName 'Ethernet0 2'
Rename-NetAdapter -Name 'vEthernet (Ethernet0)' -NewName 'vEthernet (Ethernet0 2)'
./etc/startup/start-script.ps1

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

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

Entre em contato com o suporte do Cloud para continuar com a 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.

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