Guía del usuario para grupos de nodos del SO de Windows Server

Version 1.28 

• Versión más reciente
• Versión 1.16
• Versiones anteriores (no admitidas)

Con GKE en VMware, puedes crear un grupo de nodos del SO de Windows Server. El clúster de usuario que ejecuta los grupos de nodos del SO de Windows Server también puede ejecutar grupos de nodos que contienen nodos con Ubuntu o Container-Optimized OS.

Requisitos para un grupo de nodos del SO de Windows Server

Todos los nodos de un grupo de nodos deben usar el mismo sistema operativo, indicado por el parámetro osImageType.

En tu clúster de usuario, antes de crear un grupo de nodos que tenga nodos del SO de Windows Server, asegúrate de cumplir con estos requisitos:

• Para poder crear un grupo de nodos de Windows, ya debe existir un clúster de administrador, puesto que el grupo de nodos de Windows solo es compatible con el clúster de usuario.
• El clúster de usuario debe ejecutar al menos un grupo de nodos de Linux, ya que el grupo de nodos de Linux es necesario para crear un grupo de nodos de Windows.
• Un clúster de usuario con grupos de nodos de Windows debe tener el campo enabledataplanev2 configurado como true en el archivo de configuración del clúster de usuario. Esto habilita Dataplane V2 en los nodos de Linux de ese clúster.

• De forma predeterminada, Windows Dataplane V2 está habilitado para los grupos de nodos de Windows de los clústeres de usuario nuevos.

• Descargaste una ISO de Windows Server 2019 de Microsoft a fin de crear una plantilla de VM específica para los grupos de nodos de Windows. La etiqueta de idioma o región de ISO debe ser en-US.

• El entorno de vSphere debe ser vSphere 6.7, Update 3 o una versión posterior.

Nota: IPv6 no es compatible.

Nota: El campo enableDataplaneV2 debe configurarse como true.

Crea un grupo de nodos de Windows en un clúster de usuario

Nota: Las imágenes de contenedor de Windows no están disponibles como un paquete con la capa base, también conocida como capa externa, que proviene del registro de Microsoft. Esto se debe a que la imagen de la capa base del registro de Microsoft no se puede redistribuir. Por lo tanto, debes extraer la imagen de la capa base de Google Container Registry (GCR).

Paso 1: Crea la plantilla de VM de Windows para GKE en VMware

Antes de comenzar, asegúrate de haber creado un clúster de administrador.

Nota: Para la estación de trabajo de administrador, debes permitir que la estación de trabajo de administrador y el host de salto accedan a la IP del host de ESXi en la que se ejecuta la VM de Windows, de modo que puedas ejecutar gkectl prepare windows.

1. Crea una plantilla base de VM de Windows a partir de la imagen ISO de Windows Server 2019.

   • El tipo de adaptador de red inicial para que la VM de Windows instale la imagen ISO de Windows Server 2019 debe ser E1000E.
   • Sigue estos pasos: Crear una plantilla de VMware vSphere para Windows Server 2019.
   • Anota la contraseña inicial que se estableció cuando ejecutaste el instalador ISO de Windows para usarla en el futuro.
   • Asegúrate de usar la última versión de parche calificada para Windows Server 2019. Consulta nuestras notas de la versión a fin de averiguar cuál es la última versión calificada de imagen del SO de una versión de Anthos determinada. Consulta Proceso de aplicación de parches de seguridad.
   • No puedes adjuntar ningún dispositivo que use el controlador de IDE a la plantilla base de VM.

2. Instala las herramientas de VMware en la plantilla base de VM de Windows si aún no las instalaste, mediante las instrucciones de VMware.

3. Crea una plantilla de VM de Windows:

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

   Reemplaza lo siguiente:

   • ADMIN_CLUSTER_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.

   • BASE_WINDOWS_VM_TEMPLATE: la ruta a la plantilla base de VM de Windows

   • BUNDLE: La ruta de acceso al archivo de paquete de GKE en VMware

   Como parte de la compilación de la plantilla base de VM de Windows, gkectl prepare windows ejecuta Windows sysprep. Esto generaliza la plantilla de VM y limpia la configuración de red para la VM, por lo que ayuda a evitar conflictos de dirección IP cuando las VMs se clonan a partir de la misma plantilla. Sin embargo, sysprep de Windows se ejecuta como una caja cerrada, por lo que es difícil controlar ciertas fallas sysprep.

   Si deseas compilar una plantilla base de VM de Windows sin ejecutar sysprep de Windows, incluye --skip-sysprep en el comando gkectl prepare windows.

4. En la última línea del resultado del comando, puedes encontrar el nombre de la plantilla de VM de Windows generada. Toma nota del nombre para usarlo más adelante. El nombre tiene el siguiente formato:

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

Nota: La plantilla de VM creada se usará como la imagen de SO para los grupos de nodos de Windows y está preparada para activar una secuencia de comandos durante el primer inicio, que es necesaria para que el nodo funcione correctamente. Por lo tanto, te recomendamos que no realices implementaciones en esta plantilla de VM (por ejemplo, conviértela en una VM, realiza algunas acciones y vuelve a convertirla en una plantilla de VM).

Paso 2: Subir imágenes de contenedor de Windows al registro privado

Omite este paso si no usas un registro privado.

Puedes automatizar la carga de imágenes de contenedor de Windows a un registro privado mediante containerd en una estación de trabajo de administrador de Linux. Sin embargo, containerd no puede enviar la capa base de la imagen de contenedor de Windows, lo que significa que las capas base deben extraerse del registro de Microsoft cuando se extrae la imagen. Para enviar las capas base, sigue los pasos de la opción 2.

Opción 1: Si no necesitas enviar de forma manual las imágenes de la capa base de Windows al registro privado, sigue estos pasos:

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

Reemplaza ADMIN_CLUSTER_CONFIG por la ruta de acceso al archivo kubeconfig del clúster de administrador.

La marca --upload-windows-images especifica que se enviarán las imágenes de contenedor de Windows. Solo las imágenes de contenedor de Linux se enviarán al registro privado sin especificar esta marca.

Opción 2: Si necesitas enviar de forma manual las imágenes de la capa base de Windows al registro privado, sigue estos pasos:

• Antes de intentar estos pasos, usa una máquina de Windows con Docker instalado y con acceso a gcr.io. Solo puedes extraer imágenes de contenedor de Windows a una máquina de Windows.
• Ejecuta docker login para autenticarte en el registro privado.

• Sube las imágenes de contenedor de Windows junto con sus capas base a tu registro privado mediante estos pasos:

  • Ve al archivo daemon.json de Docker en tu máquina de Windows:

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

  • Agrega las siguientes líneas a fin de configurar tu archivo daemon.json de Docker para permitir el envío de capas externas a tu registro privado:

  {
    "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
  }
  

  • Descarga las imágenes de contenedor de Windows necesarias en tu máquina local de Windows y, luego, etiquétalas y envíalas a tu registro privado. Los cambios que realizaste en el archivo de configuración de Docker daemon.json implican que la capa base puede enviarse al registro privado. Para completar estas tareas, ejecuta los siguientes 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

Paso 3: Las URL en la lista de entidades permitidas para crear grupos de nodos de Windows (obligatorio si se usa un proxy)

Si tu clúster se encuentra detrás de un servidor proxy, agrega estas URLs a la lista de entidades permitidas de tu servidor proxy, además de las otras direcciones que requiere GKE en 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

Nota: Consulta la lista completa de las URLs que usa Windows Server.

Paso 4: Agregar un grupo de nodos de Windows al archivo de configuración del clúster de usuario

1. Dataplane V2 debe estar habilitado en el clúster de usuario para usar los grupos de nodos de Windows. Agrega la siguiente línea al archivo de configuración de tu clúster de usuario para habilitar Dataplane V2:

   enableDataplaneV2: true
   

2. Agrega un grupo de nodos de Windows a la sección nodePools en el archivo de configuración del clúster de usuario. Se requiere al menos un grupo de nodos de Linux, además de tus grupos de nodos de Windows. Configura los campos osImage y osImageType para crear grupos de nodos de Windows:

• osImage: reemplaza WINDOWS_VM_TEMPLATE_NAME por el nombre de la plantilla de VM de Windows preparada en el paso 1, que debe estar en el mismo almacén de datos de vCenter especificado en el archivo de configuración del clúster de usuario.
• osImageType: especifica el tipo de imagen de SO que será windows.

# user-cluster.yaml

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

Nota: Los nodos de Windows Server requieren más recursos que los de Linux. Recomendamos los valores de CPU y memoria que se muestran en el ejemplo anterior.

Paso 5: Crear grupos de nodos de Windows

Antes de crear grupos de nodos de Windows, ejecuta una lista de validadores de solución preliminar para Windows. Omite este paso si ya tienes un clúster de usuario. - Ejecuta una o ambas comprobaciones de soluciones preliminares rápidas y lentas, que crean una VM de prueba para Windows y validan la plantilla de VM de Windows (opcional):

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

• Este comando está diseñado para que lo ejecutes antes de crear un clúster de usuario. Si ya tienes un clúster de usuario, ciertas verificaciones pueden fallar. Por ejemplo, es posible que los nodos existentes de tu clúster de usuario ya usen las direcciones IP del archivo hostconfig.yaml.
• Aunque no se recomienda, puedes omitir las comprobaciones de soluciones preliminares de Windows con la marca --skip-validation-windows.
• La administración de los grupos de nodos de Windows es la misma que la de los grupos de nodos de Linux. Consulta Administra grupos de nodos. Los comandos para crear, actualizar y mejorar clústeres y grupos de nodos también permanecen intactos y se enumeran aquí.

# 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

Paso 6: Validar los nodos de Windows que se ejecutan

1. Verifica que tus nodos de Windows se hayan creado y que sean Ready.

   kubectl --kubeconfig USER_KUBECONFIG get nodes
   

2. Diagnostica el clúster de usuario para verificar si está en buen estado.

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

Implementa un Pod de Windows

Los nodos de Windows Server tienen taints con este par clave-valor: node.kubernetes.io/os=windows:NoSchedule.

Este taint garantiza que el programador de GKE no intente ejecutar contenedores de Linux en nodos de Windows Server. Para programar contenedores de Windows Server en nodos de Windows Server, tu archivo de manifiesto debe incluir esta sección nodeSelector:

nodeSelector:
    kubernetes.io/os: windows

Con nodeSelector configurado, un webhook de admisión que se ejecuta en el clúster analiza las cargas de trabajo nuevas en busca de este selector de nodos de Windows y, cuando lo encuentra, aplica la siguiente tolerancia a la carga de trabajo, que le permite ejecutarse en los nodos de Windows Server con taints:

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

Paso 1: Crear un archivo de implementación de Internet Information Services (IIS)

Esta es una configuración de muestra, que implementa la imagen IIS oficial de Microsoft en un Pod único.

Crea un archivo IIS llamado iis.yaml con el siguiente contenido:

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]

Paso 2: Crear la implementación y exponerla a través de un servicio

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

Paso 3: Validar el Pod

Comprueba el estado del pod mediante kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Espera hasta que el resultado obtenido muestre que el Pod tiene el estado "En ejecución".

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

Obtén el estado del servicio y espera hasta que se propague el campo de la IP externa.

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

Puedes usar tu navegador para abrir http://EXTERNAL_IP y ver la página web de IIS.

Nota: Recuerda que las imágenes de contenedor de Windows deben compilarse en Windows Server 2019 para que se ejecuten en los grupos de nodos de Windows. Consulta Haz coincidir la versión del host del contenedor con las versiones con imágenes del contenedor.

Actualiza el clúster de usuario con los grupos de nodos de Windows

El proceso de actualización de un clúster de usuario con grupos de nodos de Windows es similar a que se utiliza para actualizar los clústeres de usuario exclusivo de Linux, con la excepción de que debes crear una plantilla de VM de Windows a partir de una plantilla de VM base antes de realizar la actualización.

Advertencia: La plantilla base de VM debe ser una plantilla de VM vacía de Windows Server 2019. No vuelvas a usar la plantilla de VM de Windows existente que utilizan los grupos de nodos actuales para compilar una plantilla de VM nueva.

Puedes actualizar la versión de compilación de parche de la plantilla base de VM durante la actualización si descargas una versión de parche más reciente de Windows Server 2019 desde Microsoft como un parche de seguridad. Consulta Proceso de aplicación de parches de seguridad.

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

Nota: El comando imprime el nuevo nombre de la plantilla de VM preparada.

Actualiza el campo osImage del grupo de nodos en el archivo de configuración con el nombre de la plantilla de VM nueva. Ejecute el siguiente comando para actualizar el clúster de usuario:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Reemplaza lo siguiente:

• ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso de tu archivo kubeconfig de administrador
• ADMIN_CLUSTER_CONFIG por la ruta de acceso del archivo de configuración del clúster de administrador

Accede a nodos de Windows

La manera estándar de acceder a los nodos de Windows es con un nombre de usuario y una contraseña, los cuales difieren de los nodos de Linux, a los que generalmente se accede mediante pares de claves SSH para la autenticación.

Para los nodos de Windows en vSphere, el nombre de usuario es Administrator. clusterapi-controller genera la contraseña, que se almacena en el Secret windows-node-password, en el espacio de nombres de usuario del clúster de administrador. El comando para obtener la contraseña de ese Secret es el siguiente:

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

También puedes usar la interfaz de usuario de vCenter para obtener la contraseña. Navega a la VM a la que deseas acceder y, luego, puedes encontrar la contraseña en la propiedad vApp password de esa VM.

Una vez que tengas el nombre de usuario y la contraseña, puedes acceder a la VM de Windows con cualquiera de los siguientes enfoques:

Usa el protocolo de escritorio remoto

Nota: El acceso a RDP (protocolo de escritorio remoto) se habilita durante la compilación de la plantilla de VM de Windows en gkectl prepare windows. También tendrás que asegurarte de que tus reglas de firewall permitan el acceso de RDP en el puerto TCP 3389.

Como el RDP se habilitó durante la compilación de la plantilla, puede acceder a la VM de Windows con un cliente de RDP.

Usa SSH

Nota: El servidor SSH se instala durante la compilación de la plantilla de VM de Windows en gkectl prepare windows. Por lo tanto, puedes usar SSH para tu VM de Windows mediante ese servidor SSH.

Para establecer una conexión SSH a una VM de Windows, sigue estos pasos:

ssh Administrator@[VM_IP_ADDRESS]

Sigue las indicaciones para escribir la contraseña y conectarte a la VM.

Transfiere archivos desde y hacia tu VM de Windows

Puedes transferir archivos desde y hacia tu VM de Windows con el comando scp:

Sube archivos a la VM de Windows:

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

Descarga archivos de la VM de Windows:

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

Escribe la contraseña cuando se te solicite.

Como alternativa, también puedes transferir archivos mediante Cloud Storage o RDP, como se describe en Transfiere archivos a VM de Windows.

Actualiza tu configuración de Windows Server

Containerd y Windows Dataplane V2 están en disponibilidad general a partir de la versión 1.11.

Docker y Flannel para nodos de Windows quedarán obsoletos en una versión posterior. Te recomendamos actualizar la configuración ahora, si corresponde, para usar containerd y Windows Dataplane V2 en su lugar. Consulta Actualiza la configuración de Windows Server.

No puedes establecer una conexión SSH/RDP a la VM de Windows

Ejecuta Test-NetConnection en la consola web de vCenter para verificar si la VM tiene una conexión de red.

El resultado debería contener PingSucceeded: true si hay una conexión de red. Si la VM no tiene una conexión de red, verifica el adaptador de red que se usa para esta VM. Asegúrate de que la red permita conexiones entrantes a la VM desde la estación de trabajo en la que deseas ejecutar la conexión SSH/RDP.

Verifica que el servicio de CNI, kubelet y kube-proxy se ejecuten en la VM de Windows

Sigue los pasos que se indican aquí para conectarte a tu VM y ejecuta los siguientes comandos, según tu configuración:

1. Para todas las configuraciones, ejecuta estos comandos:

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

2. Si tu clúster está configurado con windowsDataplaneV2 establecido en true, comprueba que los servicios antrea-agent, ovsdb-server y ovs-vswitchd estén “En ejecución”.

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

3. De lo contrario, verifica que el proceso flanneld esté “En ejecución”:

   # Check that the flanneld process exists
   Get-Process flanneld
   

Usa la herramienta de instantáneas

Usa la herramienta de instantánea para tomar el archivo comprimido de instantánea. En este archivo comprimido, se encuentran los archivos de registro en los nodos y los resultados para los comandos de solución de problemas que se ejecutan en el nodo.

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

La creación de la VM de Windows falla

Verifica los registros del contenedor vsphere-controller-manager en el Pod clusterapi-controllers en el espacio de nombres de usuario del clúster de administrador.

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

Asegúrate de que tu plantilla de VM se encuentre en el mismo centro de datos y almacén de datos que se especifica en el archivo de configuración del clúster de usuario.

Se creó la VM de Windows, pero el nodo no se inicia correctamente o no se muestra

• Verifica los registros de inicio en el nodo ubicado en C:\var\log\startup.log para ver si algo no se inició.

  • Si flanneld no se ejecuta, intenta volver a ejecutar la secuencia de comandos de inicio ubicada en C:\etc\startup\startup-script.ps1.
  • Si kubelet no está en ejecución, verifica los registros de kubelet en C:\var\log.
  • Si kube-proxy no se ejecuta, verifica los registros de kube-proxy en C:\var\log.

• Verifica si cloudbase-init ya ejecutó UserDataPlugin antes de ejecutar la secuencia de comandos de inicio.

Para comprobarlo, obtén una conexión SSH a la VM de Windows y ejecuta el siguiente comando:

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

Si encuentras UserDataPlugin: 1 en el resultado, significa que cloudbase-init ya ejecutó ese complemento, lo que hará que se omita la ejecución de la secuencia de comandos de inicio y que el nodo de Windows no se inicie en absoluto.

Por lo general, esto se debe a que se vuelve a convertir la plantilla de VM que genera gkectl prepare windows en una VM y se la enciende.

A fin de resolver esto, crea una plantilla de VM nueva ejecutando gkectl prepare windows nuevamente y úsala para crear, actualizar o actualizar el grupo de nodos de Windows.

Logging y Monitoring

GKE en VMware admite el registro y la supervisión para los nodos y Pods de Windows, al igual que para los nodos y Pods de Linux.

Cuando se configuran los registros y la supervisión, los agentes se implementan en los nodos de Windows. Estos agentes recopilan, procesan y exportan los registros y las métricas del nodo.

Agente de Logging de Windows

El agente de Logging de Windows recopila los siguientes registros:

• Tipo de recurso de Pod: cargas de trabajo de la aplicación del sistema y del usuario.

  Ten en cuenta que los registros de las cargas de trabajo de la aplicación del usuario de Windows se recopilan de forma predeterminada. Para inhabilitar los registros de las aplicaciones, sigue estos pasos:

  • Edita el configmap de fluent-bit-windows-config y marca como comentario el elemento [Input] que recopila los registros de la aplicación (el primer elemento [Input]):

    kubectl --kubeconfig KUBECONFIG edit configmap fluent-bit-windows-config -n kube-system
    

    Asegúrate de comentar todos los campos de este elemento. Por ejemplo:

    #    [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
    

  • Ejecuta el comando rollout restart para reiniciar el daemonset fluent-bit-windows:

    kubectl --kubeconfig KUBECONFIG rollout restart daemonset fluent-bit-windows -n kube-system
    

• Tipo de recurso de nodo: kubelet, kube-proxy y registros de eventos de Windows.

Puedes acceder a los registros con el Explorador de registros en la consola. Consulta Registros de acceso para obtener más información.

Agente de supervisión de Windows

El agente de supervisión de Windows recopila un conjunto diferente de métricas de CPU y uso de memoria que el agente de supervisión de Linux. Para supervisar el estado de los nodos y Pods de Windows, usa los paneles preparados. En la consola, selecciona Monitoring > Dashboards y, luego, “GKE on-prem Windows node status” y “GKE on-prem Windows pod status” en la lista All Dashboards.

Estos paneles se crean de forma automática durante la instalación del clúster de administrador si Cloud Monitoring está habilitado. Si ya tienes un clúster de administrador en ejecución, sigue estas instrucciones para crear estos paneles con los siguientes archivos json:

• windows_pod_status.json
• windows_node_status.json

Consulta la lista completa de métricas que recopilan los agentes de Windows.

Almacenamiento persistente de Windows

Cuando trabajas con contenedores de Windows Server con almacenamiento persistente, debes crear un objeto StorageClass y especificar el nombre de ese objeto en el campo storageClassName del objeto PersistentVolumeClaim, ya que la StorageClass predeterminada en el clúster de usuario local usa ext4 como el tipo de sistema de archivos, que solo funciona con contenedores de Linux. Para Windows, debemos establecer el tipo de sistema de archivos en ntfs.

Ejemplo de clase de almacenamiento de 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

El proxy de CSI se implementa de forma automática en los nodos de Windows. Puedes instalar y usar un controlador de CSI de Windows que desees, como el controlador de CSI de PyME.

Node Problem Detector en nodos de Windows

El daemon del detector de problemas de nodos está disponible en los nodos de Windows. Si actualizaste a la versión 1.9, el detector de problemas de nodos se habilita de forma automática. El detector de problemas de nodos ayuda a detectar con rapidez algunos problemas comunes de los nodos. El detector de problemas de nodos continúa realizando verificaciones en busca de posibles problemas y los informa como eventos y condiciones en el nodo. Cuando un nodo se comporta de manera incorrecta, puedes usar el comando kubectl para encontrar los eventos y las condiciones correspondientes.

Las siguientes opciones de configuración de supervisión están habilitadas para Node Problem Detector:

• windows-health-checker-kubelet
• windows-health-checker-kubeproxy
• windows-health-checker-docker
• windows-health-checker-containerd
• windows-defender-monitor

Para obtener eventos y condiciones en un nodo, haz lo siguiente:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Reemplaza lo siguiente:

• KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster que contiene el nodo
• NODE_NAME por el nombre del nodo

Para identificar los eventos que generan los monitores de Node Problem Detector, busca el nombre del monitor en el campo reason de una regla especificada en la sección rules.

Los monitores de Node Problem Detector también generan las siguientes condiciones en el nodo. Cada uno de ellos se establece como true si Node Problem Detector detecta la situación de falla correspondiente en el nodo.

• KubeletUnhealthy
• KubeProxyUnhealthy
• ContainerRuntimeUnhealthy

Cada vez que una de las condiciones se configure como true, la condición Ready del nodo se convertirá en false, lo que evita que se programen Pods nuevos en el nodo.

Cuando se encuentra una condición en mal estado, Node Problem Detector intenta reparar automáticamente el nodo mediante el reinicio del servicio del sistema relevante.

Nota: En el caso de containerd, el detector de problemas de nodos solo muestra los problemas al servidor de la API y no intenta reparar automáticamente el nodo mediante el reinicio del servicio containerd.

Los registros de Node Problem Detector se encuentran en la carpeta C:\var\log\node-problem-detector del nodo. Si los registros y la supervisión están habilitados, el registro se exporta a Cloud Logging y puedes verlo en el Explorador de registros.

Usa este filtro para obtener los registros de Node Problem Detector en el Explorador de registros:

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

Reemplaza PROJECT_NAME por el nombre del proyecto.

Proceso de aplicación de parches de seguridad

Además de las versiones de parche normales para las versiones de Anthos compatibles, el equipo de Anthos también califica de forma continua las actualizaciones de parches de Windows más recientes durante los períodos de no lanzamiento y publica los resultados a modo de referencia. Si se necesita una actualización de parche de seguridad urgente entre las versiones de parche de Anthos, puedes compilar una plantilla de VM nueva con la versión más reciente y, luego, realizar una actualización progresiva para que los grupos de nodos existentes de Windows usen las plantillas nuevas.

El proceso de aplicación de parches de seguridad incluye los siguientes pasos:

• Microsoft lanza un nuevo parche de seguridad para Windows Server 2019.
• Anthos califica la última versión del parche de seguridad y anuncia el resultado de la calificación.
• Si está calificada, los usuarios podrán hacer lo siguiente:
  • Descargar la última versión del parche de Microsoft
  • Compilar una plantilla de VM de Windows nueva con la versión de este parche a través de los pasos que se indican aquí.
  • Actualizar los grupos de nodos de Windows para usar la plantilla nueva mediante la ejecución del siguiente comando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

• Si la versión nueva requiere cambios del lado de Anthos, debes esperar a que se realice la próxima actualización mensual del parche de Anthos y actualizar los clústeres.

• Si la nueva versión de Windows no es compatible con Anthos, el equipo de Anthos omitirá esa versión y esperará la próxima actualización de seguridad de Microsoft.

Unión de dominio de Active Directory

La unión de dominio de Active Directory requiere que la longitud del nombre de host de la VM sea <= 15 caracteres. Para el modo IPAM, debido a que el nombre de host de la VM está configurado en el archivo de configuración del clúster de usuario, debes asegurarte de que la longitud sea <= 15 caracteres. Estas instrucciones se basan en las instrucciones para crear grupos de nodos de Windows, con el paso adicional de proporcionar una secuencia de comandos personalizada durante la compilación de la plantilla de VM de Windows.

Verifica que se pueda acceder al servidor DNS de dominio activo

Los servicios de dominio de Active Directory (AD DS) usan los servicios de resolución de nombres del sistema de nombres de dominio (DNS) para que los clientes puedan localizar los controladores de dominio y para que los controladores de dominio que alojan el servicio de directorio se comuniquen entre sí.

El servidor DNS se creó cuando la función de AD DS instaló el bosque raíz. Para que cualquier VM de Windows se una al dominio de AD, debe poder acceder al servidor DNS. Para establecer las configuraciones de DNS y firewall, sigue la guía del proveedor de servicios de DNS que usas. Puedes verificar si las VM de Windows de la red actual pueden comunicarse con el servidor DNS del dominio de AD; para ello, ejecuta 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

Paso 1: Crear una plantilla de VM de Windows con una secuencia de comandos personalizada

1. Ejecuta una secuencia de comandos personalizada antes de que el nodo de Windows se una al clúster de usuario para la unión de dominio de Active Directory. Almacena esta secuencia de comandos en una ruta de acceso local en la estación de trabajo de administrador. Ten en cuenta lo siguiente:

   • Puedes reemplazar la secuencia de comandos por tu propia secuencia de comandos para realizar la unión de dominio de Active Directory.
   • Se recomienda usar una cuenta de usuario con los permisos mínimos que requiere la unión de dominio de Active Directory, en lugar de un usuario de administrador.
   • Para evitar almacenar la contraseña como texto simple en esta secuencia de comandos, coloca la contraseña en un archivo de la plantilla de VM y deja que la secuencia de comandos lea desde ese archivo de contraseña. Luego, borra el archivo después de la unión de dominio (opcional).

   $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. Crea una plantilla de VM de Windows con una secuencia de comandos personalizada:

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

Reemplaza BUNDLE_PATH por la ruta de acceso al paquete.

Paso 2: Crear un grupo de nodos de Windows

Continúa con las instrucciones estándar en los pasos 2 y 6 para crear un grupo de nodos de Windows con la plantilla personalizada de VM de Windows.

Paso 3: Verificar la unión de dominios activos para los nodos de Windows

En la VM del controlador de dominio de AD, ejecuta el siguiente 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

Paso 4: Configurar cuentas de servicio administradas de grupo (opcional)

Sigue estas instrucciones: Configura GCEA para contenedores y Pods de Windows. Puedes configurar GMSA para Pods y contenedores de Windows una vez que los nodos se hayan unido al dominio.

Soluciona problemas

Los registros para la ejecución de la secuencia de comandos personalizada de cloudbase-init se encuentran en C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\cloudbase-init.log. Busca LocalScriptPlugin en el archivo de registro y verifica los registros relacionados. - Compila una plantilla de VM de Windows nueva. - Actualiza los grupos de nodos de Windows para usar la plantilla nueva mediante la ejecución del siguiente comando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Consideraciones para contenedores de Windows

Algunas diferencias notables entre los contenedores de Windows y Linux son las siguientes:

• Compatibilidad de versiones de las imágenes de contenedor de Windows y las imágenes de SO del host/nodo.
  • La tupla de la versión del SO de Windows Server tiene cuatro partes: principal, secundaria, de compilación y revisión.
  • La imagen base del contenedor de Windows Server debe coincidir con las tres primeras partes de la tupla de la versión de la imagen de SO del host. No es necesario que la revisión coincida, aunque se recomienda que actualices las imágenes base del host y del contenedor.
  • Los usuarios deben volver a compilar sus imágenes de contenedor cada vez que cambie la versión con imágenes del SO
• No se admiten los contenedores privilegiados ni los espacios de nombres del host.
  • Los usuarios no pueden configurar ni cambiar nodos mediante la implementación de contenedores, como Daemonsets.

Limitaciones para GKE en VMware en Windows de vSphere

• Los clústeres de usuario deben contener al menos un grupo de nodos de Linux.

  • No puedes crear un clúster solo con un grupo de nodos de Windows
  • Los grupos de nodos de Linux son necesarios para ejecutar complementos fundamentales.

• Debido a que se reservan 1.5 veces más recursos para los nodos de Windows que para los de Linux, los recursos asignables para Windows son más bajos.

• El uso de nodos de Windows puede requerir un tamaño mínimo de máquina mayor que el tamaño mínimo de máquina de GKE en VMware para Linux. Por lo general, los nodos de Windows requieren más recursos debido a la sobrecarga superior que se genera por ejecutar componentes o servicios de nodos.

Problemas conocidos

En esta sección, se enumeran los problemas conocidos de los nodos de Windows que se usan con GKE en VMware, junto con las soluciones alternativas para evitarlos o solucionarlos.

Los Pods de Windows no pueden comunicarse con direcciones IP externas

Nota: Este problema solo se aplica a Flannel (con WindowsDataplaneV2 inhabilitado). Este problema no se produce con WindowsDataplaneV2 habilitado.

Este problema se describe en la documentación de Microsoft, que indica “Debes excluir la IP externa que intentas consultar de ExceptionList”.

Comunícate con el equipo de Asistencia de Google Cloud para continuar con una solución alternativa.

Los contenedores de Windows no se limpian después de quitar los Pods de Windows.

Este es un problema conocido, en el que RemoveContainer de Docker también intenta llamar a CreateFile en Windows. Como solución alternativa, accede al nodo de Windows que tiene el problema, ejecuta Restart-Service docker y, luego, se debería mitigar el problema. A partir de GKE en VMware 1.9, la versión de imagen de contenedor fluent-bit-win y la versión de Docker se actualizaron para recoger las correcciones ascendentes de este problema. Esto ya no debería reproducirse más. Si te encuentras con este problema, comunícate con el equipo de asistencia de Google Cloud.

Nodos de Windows que tienen conflictos de direcciones IP

Este es un problema conocido que ocurre con muy poca frecuencia. Si te encuentras con esto durante la creación del grupo de nodos de Windows, puedes mitigarlo mediante los siguientes pasos:

• Si usas el modo IPAM, puedes quitar de forma manual las VM que tienen conflictos de IP de vCenter. Se crearán VM nuevas de forma automática, que deberían tener asignaciones de IP correctas. O bien, puedes esperar a que la reparación automática del nodo detecte este problema y vuelva a crear los nodos de Windows.

• Si usas el modo DHCP, es probable que las VM recién creadas tengan IP duplicadas nuevamente, ya que el servidor DHCP tiene problemas para la asignación de IP, puedes borrar el grupo de nodos de Windows pendiente mediante la ejecución de gkectl update cluster y volver a agregarlo en el user-cluster.yaml y vuelve a ejecutar gkectl update cluster para crearlo. El grupo de nodos recién creado debe tener las asignaciones de IP correctas.

El nodo de Windows se vuelve NotReady después de reiniciar la VM

Actualmente, la secuencia de comandos de inicio del nodo solo se ejecuta la primera vez que se enciende la VM. Por lo tanto, si reinicias la VM, la secuencia de comandos de inicio no se ejecutará de nuevo. Esto hará que algunos servicios de Windows dejen de ejecutarse, incluidos los servicios de kube-proxy, kubelet, etc., lo que causa que el nodo esté en estado NotReady. Si usas Windows Dataplane V2, la red inactiva también debe limpiarse antes de que los servicios de Dataplane V2 se puedan reiniciar, y deberás ejecutar una secuencia de comandos para la limpieza, lo que puede causar complicaciones. Por lo tanto, te recomendamos volver a crear el nodo. Como solución alternativa, puedes borrar el nodo ejecutando el siguiente comando y esperar a que el controlador lo vuelva a crear automáticamente.

kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

El comando de diagnóstico falla cuando las versiones de hardware de la VM de Windows son anteriores a las esperadas

Cuando la plantilla de VM de Windows usa una versión de hardware antigua, el comando gkectl diagnose cluster falla y muestra el siguiente mensaje:

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 solucionar el problema, sigue estos pasos:

1. Cambia el nombre de la plantilla de VM que se usa actualmente.

   Esto es necesario para poder crear una plantilla de VM nueva en los próximos pasos.

2. Convierte la plantilla de VM base de Windows en una VM.

3. Sigue los pasos que se indican en Actualiza una máquina virtual a la versión de hardware más reciente para actualizar la versión de hardware de la VM.

4. Volver a convertir la VM en una plantilla de VM

5. Ejecuta el siguiente comando para preparar una plantilla de VM nueva. Para ello, usa la plantilla de VM actualizada de los pasos anteriores como la plantilla de VM base.

   gkectl prepare windows
   

   El nuevo nombre de la plantilla de VM generada debe coincidir con el valor del campo osImage del grupo de nodos de Windows en el archivo de configuración del clúster de usuario. Si los valores coinciden, continúa con el siguiente paso para volver a crear el nodo de Windows.

   Si el nombre de la plantilla no coincide con el valor del campo osImage, actualiza el valor osImage para que coincida con el nombre de la plantilla de VM generada nueva y ejecuta el siguiente comando:

   gkectl update cluster
   

6. Ejecuta el siguiente comando para volver a crear el nodo de Windows:

   kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME
   

   Espera a que el controlador vuelva a crear el nodo de forma automática.