Guia do utilizador para pools de nós do SO Windows Server

Com o Google Distributed Cloud, pode criar um node pool de nós do SO Windows Server. O cluster de utilizadores que executa os pools de nós do SO Windows Server também pode executar pools de nós que contêm nós com o Ubuntu ou o SO otimizado para contentores.

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

Todos os nós num conjunto de nós têm de usar o mesmo sistema operativo, indicado pelo parâmetro osImageType.

Antes de criar, no cluster de utilizadores, um conjunto de nós com nós do SO Windows Server, certifique-se de que cumpre estes requisitos:

  • Já tem de existir um cluster de administrador antes de poder criar um pool de nós do Windows, porque um pool de nós do Windows só é suportado no cluster de utilizador.
  • O cluster de utilizadores tem de executar, pelo menos, um pool de nós Linux, porque o pool de nós Linux é necessário para criar um pool de nós Windows.
  • Um cluster de utilizadores com pools de nós do Windows tem de ter o campo enabledataplanev2 definido como true no ficheiro de configuração do cluster de utilizadores. Isto ativa o Dataplane V2 nos nós Linux desse cluster.

  • Por predefinição, o Windows Dataplane V2 está ativado para os pools de nós do Windows para novos clusters de utilizadores.

  • Transferiu um ISO do Windows Server 2019 da Microsoft para criar um modelo de VM específico para pools de nós do Windows. A etiqueta de idioma/região para o ISO tem de ser en-US.

  • O seu ambiente vSphere tem de ser o vSphere 6.7, Update 3 ou posterior.

  • Os pools de nós do SO Windows Server têm as seguintes limitações:

    • O IPv6 não é suportado.
    • Os pools de nós do Windows não são suportados em clusters avançados.

Crie um node pool do Windows num cluster de utilizador

Passo 1: crie o modelo de VM do Windows para o Google Distributed Cloud

Antes de começar, certifique-se de que já criou um cluster de administrador.

  1. Crie um modelo de VM do Windows base a partir da ISO do Windows Server 2019.

    • O tipo de adaptador de rede inicial para a VM do Windows para instalar a ISO do Windows Server 2019 deve ser E1000E.
    • Siga estes passos: crie um modelo do VMware vSphere para o Windows Server 2019.
    • Tome nota da palavra-passe inicial definida quando executa o instalador ISO do Windows para a usar no futuro.
    • Certifique-se de que está a usar a versão de patch qualificada mais recente para o Windows Server 2019. Consulte as nossas notas de lançamento para saber a versão de imagem do SO Windows qualificada mais recente para uma determinada versão de lançamento do Anthos. Consulte o processo de patch de segurança.
    • Não pode anexar nenhum dispositivo que use o controlador IDE ao modelo de VM base.

  2. Instale o VMware Tools no modelo de VM do Windows base, se ainda não estiver instalado. Consulte o artigo Instale manualmente as VMware Tools no Windows na documentação da VMware.

  3. Crie um modelo de VM do Windows:

    gkectl prepare windows \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --base-vm-template BASE_WINDOWS_VM_TEMPLATE \
    --bundle-path BUNDLE \
    [--skip-sysprep]

    Substitua o seguinte:

    • ADMIN_CLUSTER_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

    • BASE_WINDOWS_VM_TEMPLATE: O caminho para o modelo de VM do Windows base

    • BUNDLE: o caminho para o ficheiro do pacote do Google Distributed Cloud

    Como parte da criação do modelo de VM do Windows base, o gkectl prepare windows executa o Windows sysprep. Isto generaliza o modelo de VM e limpa as definições de rede da VM e, assim, ajuda a evitar conflitos de endereços IP quando as VMs são clonadas a partir do mesmo modelo. No entanto, o Windows sysprep é executado como uma caixa fechada, pelo que é difícil processar determinadas falhas do sysprep.

    Se quiser criar um modelo de VM Windows base sem executar o Windows sysprep, inclua o --skip-sysprep no comando gkectl prepare windows.

  4. Na última linha do resultado do comando, pode encontrar o nome do modelo de VM do Windows gerado. Anote o nome para utilização futura. O nome tem o seguinte formato:

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

Passo 2: carregue imagens de contentores do Windows para um registo privado

Omita este passo se não estiver a usar um registo privado.

Pode automatizar o carregamento de imagens de contentores Windows para um registo privado através do containerd numa estação de trabalho de administração Linux. No entanto, o containerd não consegue enviar a camada base da imagem do contentor do Windows, o que significa que as camadas base têm de ser extraídas do registo da Microsoft quando a imagem é extraída. Para enviar as camadas base, siga os passos da Opção 2.

Opção 1: se não precisar de enviar manualmente as imagens da camada base do Windows para o registo privado:

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

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

A flag --upload-windows-images especifica que as imagens de contentores Windows vão ser enviadas. Apenas as imagens de contentores Linux são enviadas para o registo privado sem especificar esta flag.

Opção 2: se precisar de enviar manualmente as imagens da camada base do Windows para o registo privado:

  • Use um computador Windows com o Docker instalado e com acesso ao gcr.io antes de tentar estes passos. Só pode extrair imagens de contentores Windows para uma máquina Windows.
  • Execute docker login para fazer a autenticação no seu registo privado.

  • Carregue as imagens do contentor do Windows juntamente com as respetivas camadas base para o seu registo privado, seguindo estes passos:

    • Aceda ao ficheiro daemon.json do Docker na sua máquina Windows: 

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

    • Adicione as seguintes linhas para configurar o seu ficheiro daemon.json do Docker para permitir o envio de camadas externas para o seu registo privado:

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • Transfira as imagens de contentores do Windows necessárias para o seu computador Windows local e, de seguida, etiquete-as e envie-as para o seu registo privado. As alterações que fez ao ficheiro de configuração do daemon.json Docker significam que a camada base pode ser enviada para o registo privado. Para concluir estas 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

Passo 3: (obrigatório se usar um proxy) crie uma lista de autorizações de URLs para criar pools de nós do Windows

Se o seu cluster estiver atrás de um servidor proxy, adicione estes URLs à lista de autorizações do servidor proxy, além dos outros endereços que o Google Distributed Cloud requer.

# 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

Passo 4: adicione um conjunto de nós do Windows ao ficheiro de configuração do cluster de utilizadores

  1. O Dataplane V2 tem de estar ativado no cluster de utilizadores para usar pools de nós do Windows. Adicione a seguinte linha ao ficheiro de configuração do cluster de utilizadores para ativar o Dataplane V2:

    enableDataplaneV2: true

  2. Adicione um conjunto de nós do Windows à secção nodePools no ficheiro de configuração do cluster de utilizadores. É necessário, pelo menos, um pool de nós do Linux, além dos pools de nós do Windows. Defina os campos osImage e osImageType para criar node pools do Windows:

  • osImage: substitua WINDOWS_VM_TEMPLATE_NAME pelo nome do modelo de VM do Windows preparado no passo 1, que deve estar no mesmo arquivo de dados do vCenter especificado no ficheiro de configuração do cluster de utilizadores.
  • osImageType: especifique o tipo de imagem do SO como windows.
# user-cluster.yaml

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

Passo 5: crie node pools do Windows

Antes de criar pools de nós do Windows, execute uma lista de validadores de pré-voo para o Windows. Ignore este passo se já tiver um cluster de utilizadores. - (Opcional) Execute uma ou ambas as verificações pré-implementação rápidas e lentas, que criam uma VM de teste para o Windows e validam o modelo de VM do Windows:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • Este comando destina-se a ser executado antes de criar um cluster de utilizadores. Se já tiver um cluster de utilizadores, determinadas verificações podem falhar. Por exemplo, os endereços IP no ficheiro hostconfig.yaml podem já estar a ser usados por nós existentes no seu cluster de utilizadores.
  • Embora não seja recomendado, pode ignorar as verificações prévias do Windows com a flag --skip-validation-windows.
  • A gestão de node pools do Windows é igual à dos node pools do Linux. Consulte o manual do utilizador para pools de nós do SO Windows Server. Os comandos para criar, atualizar e atualizar clusters e conjuntos de nós também permanecem iguais 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

Passo 6: valide se os nós do Windows estão em execução

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

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. Diagnosticar o cluster de utilizadores para verificar se está em bom estado.

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

Implemente um pod do Windows

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

Esta restrição garante que o programador do GKE não tenta executar contentores Linux em nós do Windows Server. Para agendar contentores do Windows Server em nós do Windows Server, o ficheiro de manifesto tem de incluir esta secção nodeSelector:

nodeSelector:
    kubernetes.io/os: windows

Com o nodeSelector configurado, um webhook de admissão em execução no cluster verifica novas cargas de trabalho quanto à presença deste seletor de nós do Windows e, quando encontrado, aplica a seguinte tolerância à carga de trabalho, o que lhe permite ser executada nos nós do Windows Server contaminados:

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

Passo 1: crie um ficheiro de implementação dos Serviços de Informação da Internet (IIS)

Segue-se uma configuração de exemplo que implementa a imagem oficial do IIS da Microsoft num único pod.

Crie um ficheiro IIS denominado 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]

Passo 2: crie a implementação e exponha-a através de um serviço

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

Passo 3: valide o Pod

Verifique o estado do Pod através da app kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Aguarde até que o resultado devolvido mostre que o Pod tem o estado "Running" (Em execução).

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

Aceda ao estado do serviço e aguarde até que o campo de IP externo seja preenchido.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get service iis

Resultado esperado:

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

Pode usar o navegador para abrir http://EXTERNAL_IP para ver a página Web do IIS.

Atualize o cluster de utilizadores com node pools do Windows

O processo de atualização de um cluster de utilizadores com pools de nós do Windows é semelhante ao de atualização de clusters de utilizadores apenas com Linux, exceto que tem de criar um modelo de VM do Windows a partir de um modelo de VM base antes da atualização.

Pode atualizar a versão de compilação do patch do modelo de VM base durante a atualização transferindo uma versão de patch mais recente do Windows Server 2019 da Microsoft como um patch de segurança. Consulte o 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

Atualize o campo osImage do node pool no ficheiro de configuração com o novo nome do modelo de VM. Execute o comando abaixo para atualizar o cluster de utilizadores:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua o seguinte:

  • ADMIN_CLUSTER_KUBECONFIG com o caminho do ficheiro kubeconfig do administrador
  • ADMIN_CLUSTER_CONFIG com o caminho do ficheiro de configuração do cluster de administrador

Aceder a nós do Windows

A forma padrão de aceder aos nós do Windows é com um nome de utilizador e uma palavra-passe, o que difere dos nós do Linux, aos quais se acede normalmente através de pares de chaves SSH para autenticação.

Para nós do Windows no vSphere, o nome de utilizador é Administrator. A palavra-passe é gerada pelo clusterapi-controller e armazenada no segredo windows-node-password no espaço de nomes do utilizador do cluster de administrador. O comando para obter a palavra-passe desse segredo é:

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

Também pode obter a palavra-passe através da interface do utilizador do vCenter. Navegue para a VM na qual quer iniciar sessão e, em seguida, pode encontrar a palavra-passe na propriedade password vApp dessa VM.

Assim que tiver o nome de utilizador e a palavra-passe, pode aceder à VM do Windows através de qualquer uma das seguintes abordagens:

Usar o protocolo de ambiente de trabalho remoto

Uma vez que o RDP foi ativado durante a criação do modelo, pode aceder à sua VM do Windows através de um cliente RDP.

Usar SSH

Para estabelecer ligação SSH a uma VM do Windows:

ssh Administrator@[VM_IP_ADDRESS]

Siga a instrução para introduzir a palavra-passe para se ligar à VM.

Transferir ficheiros de e para a sua VM do Windows

Pode transferir ficheiros de e para a sua VM do Windows com o comando scp:

Carregue ficheiros para a VM do Windows:

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

Transfira ficheiros da VM do Windows:

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

Introduza a palavra-passe quando lhe for pedido.

Em alternativa, também pode transferir ficheiros através do Cloud Storage ou do RDP, conforme descrito no artigo  Transferir ficheiros para VMs do Windows.

Atualizar a configuração do Windows Server

O Containerd e o Windows Dataplane V2 estão agora em disponibilidade geral a partir da versão 1.11.

O Docker e o Flannel para nós Windows vão ser descontinuados numa versão subsequente. Recomendamos que atualize a sua configuração agora, se aplicável, para usar o containerd e o Windows Dataplane V2. Consulte o artigo Atualize a configuração do Windows Server.

Não é possível realizar o SSH/RDP para a VM do Windows

Verifique se a VM tem uma ligação de rede executando Test-NetConnection na consola Web do vCenter.

O resultado deve conter PingSucceeded: true se existir uma ligação de rede. Se a MV não tiver uma ligação de rede, verifique o adaptador de rede usado para esta MV. Certifique-se de que a rede permite ligações de entrada à VM a partir da estação de trabalho onde quer executar o SSH/RDP.

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

Estabeleça ligação à sua VM seguindo os passos aqui e execute os seguintes comandos, consoante a sua configuração:

  1. Para todas as configurações, execute estes comandos:

    # Check that kubelet and kube-proxy services have status 'Running'
Get-Service kubelet
Get-Service kube-proxy

  2. Se o cluster estiver configurado com windowsDataplaneV2 definido como true, verifique se os serviços antrea-agent, ovsdb-server e ovs-vswitchd estão "Em execução".

    # Check that CNI services have the status of 'Running'
Get-Service antrea-agent
Get-Service ovsdb-server
Get-Service ovs-vswitchd

  3. Caso contrário, verifique se o processo flanneld está "Em execução":

    # Check that the flanneld process exists
Get-Process flanneld

Usar a ferramenta de captura de ecrã

Use a ferramenta de instantâneo para obter o ficheiro tar.gz do instantâneo. Este ficheiro tar.gz contém os ficheiros de registo nos nós, bem como os resultados dos comandos de resolução de problemas executados no nó.

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

A criação da VM do Windows falha

Verifique os registos do contentor vsphere-controller-manager no pod clusterapi-controllers no espaço de nomes do utilizador do cluster de administrador.

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

Certifique-se de que o modelo de VM está localizado no mesmo centro de dados e armazenamento de dados especificados no ficheiro de configuração do cluster de utilizadores.

A VM do Windows é criada, mas o nó não é iniciado corretamente nem é apresentado

  • Verifique os registos de arranque no nó localizado em C:\var\log\startup.log para ver se ocorreu alguma falha no arranque.

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

  • Verifique se o cloudbase-init já executou o UserDataPlugin antes de executar o script de arranque.

Para verificar esta situação, estabeleça uma ligação SSH à VM Windows e execute o seguinte comando:

ls "HKLM:\\Software\Cloudbase Solutions\Cloudbase-Init\id-ovf\"

Se encontrar UserDataPlugin: 1 no resultado, significa que o cloudbase-init já executou esse plug-in, o que fará com que a execução do script de arranque seja ignorada e o nó do Windows não seja iniciado.

Normalmente, isto é causado pela conversão do modelo de VM gerado pelo gkectl prepare windows novamente numa VM e pela respetiva ativação.

Para resolver este problema, crie um novo modelo de VM executando novamente o comando gkectl prepare windows e use-o para criar/atualizar/atualizar o conjunto de nós do Windows.

Registo e monitorização

O Google Distributed Cloud suporta o registo e a monitorização para nós e pods do Windows, tal como para nós e pods do Linux.

Quando o registo e a monitorização estão configurados, os agentes são implementados em nós do Windows. Estes agentes recolhem, processam e exportam os registos e as métricas do nó.

Agente de registos do Windows

O agente de registo do Windows recolhe os seguintes registos:

  • Tipo de recurso de pod: cargas de trabalho de aplicações do sistema e do utilizador.

    Tenha em atenção que os registos de cargas de trabalho de aplicações de utilizadores do Windows são recolhidos por predefinição. Para desativar os registos de aplicações:

    • Edite o fluent-bit-windows-config configmap e comente o item [Input] que recolhe os registos da aplicação (o primeiro item [Input]): 
      kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
      Certifique-se de que comenta todos os campos deste item. Por exemplo: 
      #    [INPUT]
#      # https://docs.fluentbit.io/manual/input/tail
#      Name               tail
#      Tag_Regex          var.log.containers.(?<podname>[a-z0-9](?:[-a-z0-9][a-z0-9])?(?:.[a-z0-9]([-a-z0-9][a-z0-9])?)*)(?<namespacename>[^]+)_(?<container_name>.+)-(?<docker_id>[a-z0-9]{64}).log$
#      Tag                k8s_container.<namespace_name>.<pod_name>.<container_name>
#      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 conjunto de daemons fluent-bit-windows: 
      kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system

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

Pode aceder aos registos através do Explorador de registos na consola. Consulte a secção Registos de acesso para mais informações.

Agente de monitorização do Windows

O agente de monitorização do Windows recolhe um conjunto diferente de métricas de utilização da CPU e da memória em comparação com o agente de monitorização do Linux. Para monitorizar o estado dos nós e dos pods do Windows, use os painéis de controlo preparados. Na consola, selecione Monitoring > Painéis de controlo e, de seguida, selecione "GKE on-prem Windows node status" e "GKE on-prem Windows pod status" na lista Todos os painéis de controlo.

Estes painéis de controlo são criados automaticamente durante a instalação do cluster de administrador se o Cloud Monitoring estiver ativado. Se já tiver um cluster de administrador em execução, siga estas instruções para criar estes painéis de controlo, usando os seguintes ficheiros JSON:

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

Armazenamento persistente do Windows

Quando trabalha com contentores do Windows Server com armazenamento persistente, tem de criar um objeto StorageClass e especificar o nome desse objeto no campo storageClassName do objeto PersistentVolumeClaim, porque o StorageClass predefinido no cluster de utilizadores no local usa ext4 como o tipo de sistema de ficheiros, que só funciona para contentores Linux. Para o Windows, temos de definir o tipo de sistema de ficheiros 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

O proxy CSI é implementado automaticamente em nós do Windows. Pode instalar e usar um controlador CSI do Windows à sua escolha, como o controlador CSI SMB.

Node Problem Detector em nós Windows

O daemon Node Problem Detector está disponível em nós Windows. Se atualizou para a versão 1.9, o Node Problem Detector é ativado automaticamente. O Node Problem Detector ajuda na deteção rápida de alguns problemas comuns de nós. O Node Problem Detector continua a verificar possíveis problemas e comunica-os como eventos e condições no nó. Quando um nó tem um comportamento incorreto, pode usar o comando kubectl para encontrar os eventos e as condições correspondentes.

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

Para obter eventos e condições num nó:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Substituição:

  • KUBECONFIG com o caminho do ficheiro kubeconfig para o cluster que contém o nó.
  • NODE_NAME com o nome do nó.

Para identificar os eventos gerados pelos monitores do Node Problem Detector, procure o nome do monitor no campo reason de uma regra especificada na secção rules.

Os monitores do Node Problem Detector também geram as seguintes condições no nó. Cada um destes está definido como true se o Node Problem Detector detetar o cenário de falha correspondente no nó.

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

Sempre que uma das condições estiver definida como true, a condição Ready do nó torna-se false, o que impede que novos pods sejam agendados no nó.

Quando é detetada uma condição não saudável, o Node Problem Detector tenta reparar automaticamente o nó reiniciando o serviço do sistema relevante.

Os registos do Node Problem Detector estão localizados na pasta C:\var\log\node-problem-detector do nó. Se o registo e a monitorização estiverem ativados, o registo é exportado para o Cloud Logging, e pode vê-lo no Explorador de registos.

Use este filtro para obter registos do Node Problem Detector no Explorador de registos:

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 dos lançamentos de patches normais para as versões do Anthos suportadas, a equipa do Anthos também valida continuamente atualizações de patches do Windows mais recentes durante períodos sem lançamentos e publica os resultados para sua referência. Se for necessária uma atualização urgente de patch de segurança entre as versões de patches do Anthos, pode criar um novo modelo de VM com a versão mais recente e, em seguida, fazer uma atualização contínua dos conjuntos de nós do Windows existentes para usar o novo modelo.

O processo de patch de segurança inclui estes passos:

  • A Microsoft lança um novo patch de segurança para o Windows Server 2019.
  • O Anthos qualifica a versão mais recente da correção de segurança e anuncia o resultado da qualificação.
  • Se forem elegíveis, os utilizadores:
    • Transfira a versão de patch mais recente da Microsoft
    • Crie um novo modelo de VM do Windows com esta versão de patch seguindo os passos aqui.
    • Atualize os node pools do Windows para usar o novo modelo executando o seguinte comando:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

  • Se a nova versão exigir alterações por parte do Anthos, tem de aguardar o lançamento do patch mensal seguinte do Anthos e atualizar os clusters.

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

Associação ao domínio do Active Directory

A associação ao domínio do Active Directory requer que o comprimento do nome do anfitrião da VM seja igual ou inferior a 15 carateres. Para o modo IPAM, uma vez que o nome do anfitrião da VM está definido no ficheiro de configuração do cluster de utilizadores, tem de garantir que o comprimento é <= 15 carateres. Estas instruções baseiam-se nas instruções para criar pools de nós do Windows, com o passo adicional de fornecer um script personalizado durante a criação do modelo de VM do Windows.

Valide se o servidor DNS do domínio ativo está acessível

Os Serviços de Domínio do Active Directory (AD DS) usam serviços de resolução de nomes do Sistema de Nomes de Domínio (DNS) para permitir que os clientes localizem controladores de domínio e que os controladores de domínio que alojam o serviço de diretório comuniquem entre si.

O servidor DNS foi criado quando a função AD DS instalou a floresta raiz. Para que qualquer VM do Windows possa aderir ao domínio do AD, tem de conseguir alcançar o servidor DNS. Configure as configurações de DNS e firewall seguindo as orientações do fornecedor de serviços de DNS que está a usar. Pode verificar se as VMs do Windows na rede atual conseguem contactar 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

Passo 1: crie um modelo de VM do Windows com um script personalizado

  1. Executar um script personalizado antes de o nó do Windows aderir ao cluster de utilizadores para a associação ao domínio do Active Directory. Armazene este script num caminho local na sua estação de trabalho de administração. Tenha em atenção que:

    • Pode substituir o guião pelo seu próprio guião para fazer a associação ao domínio do Active Directory.
    • Recomendamos que use uma conta de utilizador com as autorizações mínimas necessárias para uma associação ao domínio do Active Directory, em vez de usar um utilizador administrador.
    • (Opcional) Para evitar armazenar a palavra-passe como texto não cifrado neste script, coloque a palavra-passe num ficheiro no modelo de VM, permita que o script leia a partir desse ficheiro de palavra-passe e, em seguida, elimine o ficheiro 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.

Passo 2: crie um conjunto de nós do Windows

Proceda com as instruções padrão nos passos 2 a 6 para criar um conjunto de nós do Windows com o modelo de VM do Windows personalizado.

Passo 3: valide a associaçã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

Passo 4: configure contas de serviço geridas por grupos (opcional)

Siga estas instruções: configure a GMSA para contentores e pods do Windows. Pode configurar o GMSA para pods e contentores do Windows depois de os nós serem associados ao domínio.

Resolução de problemas

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

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Considerações para contentores do Windows

Algumas diferenças notáveis entre os contentores Windows e Linux são:

  • Compatibilidade de versões das imagens de contentores do Windows e das imagens do SO do anfitrião/nó.
    • A tupla da versão do SO Windows Server tem quatro partes: principal, secundária, compilação e revisão.
    • A imagem base do contentor do servidor Windows tem de corresponder às três primeiras partes da tupla de versão da imagem do SO anfitrião. A revisão não tem de corresponder, embora seja recomendável que atualize as imagens base do anfitrião e do contentor.
    • Os utilizadores têm de reconstruir as respetivas imagens de contentores sempre que a versão da imagem do SO muda
  • Os contentores privilegiados e os espaços de nomes de anfitriões não são suportados.
    • Os utilizadores não podem configurar/alterar nós implementando contentores, como Daemonsets.

Limitações do Google Distributed Cloud no vSphere Windows

  • Os clusters de utilizadores têm de conter, pelo menos, um conjunto de nós do Linux.

    • Não pode criar um cluster apenas com um conjunto de nós do Windows
    • Os pools de nós do Linux são necessários para executar suplementos críticos.

  • Uma vez que são reservados 1,5 vezes mais recursos para nós do Windows do que para nós do Linux, os recursos atribuíveis para o Windows são inferiores.

  • A utilização de nós do Windows pode exigir um tamanho mínimo da máquina superior ao tamanho mínimo da máquina do Google Distributed Cloud Linux. Normalmente, os nós do Windows requerem mais recursos devido à sobrecarga mais elevada da execução de componentes/serviços de nós.

Problemas Conhecidos

Esta secção apresenta problemas conhecidos com nós do Windows usados com o Google Distributed Cloud, juntamente com soluções alternativas para evitar ou recuperar destes problemas.

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

Este problema é descrito na documentação da Microsoft, que afirma "Tem de excluir o IP externo que está a tentar consultar da ExceptionList".

Contacte o apoio técnico do Google Cloud para avançar com uma solução alternativa.

Os contentores do Windows não são limpos após a remoção dos pods do Windows

Este é um problema conhecido em que o docker RemoveContainer também tenta chamar CreateFile no Windows. Como solução alternativa, inicie sessão no nó do Windows que tem o problema, execute Restart-Service docker e o problema deve ser atenuado. A partir do Google Distributed Cloud 1.9, a versão da imagem do contentor fluent-bit-win e a versão do Docker foram atualizadas para receber as correções upstream deste problema, que não deve voltar a ocorrer. Se ocorrer este problema, contacte o apoio técnico do Google Cloud.

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

Este é um problema conhecido que ocorre muito raramente. Se o encontrar durante a criação do conjunto de nós do Windows, pode mitigá-lo seguindo os passos:

  • Se estiver a usar o modo IPAM, pode remover manualmente as VMs que têm conflitos de IP do vCenter. As novas VMs são criadas automaticamente e devem ter atribuições de IP corretas. Em alternativa, pode aguardar que a reparação automática do nó detete este problema e recrie os nós do Windows.

  • Se estiver a usar o modo DHCP, é provável que as VMs criadas recentemente tenham novamente IPs duplicados, uma vez que o servidor DHCP está a ter problemas com a atribuição de IPs. Pode eliminar o conjunto de nós do Windows pendente executando gkectl update cluster e adicioná-lo novamente em user-cluster.yaml. Execute gkectl update cluster novamente para o criar. O conjunto de nós criado recentemente deve ter atribuições de IP corretas.

O nó do Windows fica com o estado NotReady após o reinício da VM

Atualmente, o script de arranque do nó só é executado na primeira vez que a VM é ligada. Por isso, se reiniciar a VM, o script de arranque não é executado novamente. Isto faz com que alguns serviços do Windows deixem de ser executados, incluindo os serviços kubelet, kube-proxy, entre outros. Isto faz com que o nó esteja no estado NotReady. Se estiver a usar o Windows Dataplane V2, a rede desatualizada também tem de ser limpa antes de os serviços Dataplane V2 poderem ser reiniciados. Além disso, é necessário executar um script para a limpeza, o que pode causar complicações. Por isso, recrie o nó. Como solução alternativa, pode eliminar o nó executando o comando abaixo e aguardar que o controlador o recrie automaticamente.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

O comando de diagnóstico falha quando as versões de hardware da VM do Windows são inferiores ao esperado

Quando o modelo de VM do Windows está a usar uma versão de hardware antiga, o comando gkectl diagnose cluster falha com a seguinte mensagem:

Checking storage...FAILURE
    Reason: 1 storage error(s).
    Unhealthy Resources:
    CSIPrerequisites [VM Hardware]: The current VM hardware versions are lower than vmx-15 which is unexpected. Please contact Anthos support to resolve this issue. Use --detailed=true for the list of VMs.
    Debug Information:
    {
      "NODE_NAME": "vmx-XX",
    }

Para corrigir este problema, siga estes passos:

  1. Mude o nome do modelo de VM atualmente em utilização.

    Isto é necessário para poder criar um novo modelo de VM nos passos seguintes.

  2. Converter o modelo de VM base do Windows numa VM.

  3. Siga os passos em Atualizar uma máquina virtual para a versão de hardware mais recente para atualizar a versão de hardware da VM.

  4. Converter novamente a VM num modelo de VM.

  5. Execute o seguinte comando para preparar um novo modelo de VM, usando o modelo de VM atualizado dos passos anteriores como o modelo de VM base.

    gkectl prepare windows

    O novo nome do modelo de VM gerado deve corresponder ao valor do campo osImagewindowsNodePool no ficheiro de configuração do cluster de utilizador. Se os valores corresponderem, avance para o passo seguinte para recriar o nó do Windows.

    Se o nome do modelo não corresponder ao valor do campo osImage, atualize o valor de osImage para corresponder ao novo nome do modelo de VM gerado e execute o seguinte comando:

    gkectl update cluster

  6. Volte a criar o nó do Windows executando o seguinte comando:

    kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

    Aguarde até que o controlador recrie automaticamente o nó.