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

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

Requisitos de un grupo de nodos del SO de Windows Server

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

Antes de crear un grupo de nodos con nodos del SO Windows Server en tu clúster de usuario, asegúrate de cumplir estos requisitos:

  • Antes de crear un grupo de nodos de Windows, debe haber un clúster de administrador, ya que los grupos de nodos de Windows solo se admiten en el clúster de usuario.
  • El clúster de usuario debe ejecutar al menos un grupo de nodos de Linux, ya que este es necesario para crear un grupo de nodos de Windows.
  • Un clúster de usuarios con grupos de nodos de Windows debe tener el campo enabledataplanev2 definido como true en el archivo de configuración del clúster de usuarios. De esta forma, se habilita Dataplane V2 en los nodos de Linux de ese clúster.

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

  • Has descargado una ISO de Windows Server 2019 de Microsoft para crear una plantilla de VM específica para grupos de nodos de Windows. La etiqueta de idioma o región de la ISO debe ser "en-US".

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

  • Los grupos de nodos del SO de Windows Server tienen las siguientes limitaciones:

Crear un grupo de nodos de Windows en un clúster de usuarios

Paso 1: Crea la plantilla de VM de Windows para Google Distributed Cloud

Antes de empezar, asegúrese de que ya ha creado un clúster de administradores.

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

    • El tipo de adaptador de red inicial de la VM de Windows para instalar la 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 establece al ejecutar el instalador ISO de Windows para usarla en el futuro.
    • Asegúrate de que estás usando la versión de parche cualificada más reciente de Windows Server 2019. Consulta nuestras notas de lanzamiento para ver la versión de imagen del SO Windows cualificada más reciente para una versión de lanzamiento de Anthos determinada. Consulta el proceso de parche de seguridad.
    • No puedes conectar ningún dispositivo que use el controlador IDE a la plantilla de VM base.

  2. Instala VMware Tools en la plantilla de VM de Windows base si aún no lo has hecho. Consulta Instalar manualmente VMware Tools en Windows en la documentación 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]

    Haz los cambios siguientes:

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

    • BASE_WINDOWS_VM_TEMPLATE: ruta a la plantilla base de la máquina virtual Windows

    • BUNDLE: ruta al archivo del paquete de Google Distributed Cloud

    Como parte de la creación de la plantilla de VM de Windows base, gkectl prepare windows ejecuta Windows sysprep. De esta forma, se generaliza la plantilla de VM y se limpian los ajustes de red de la VM, lo que ayuda a evitar conflictos de direcciones IP cuando se clonan VMs a partir de la misma plantilla. Sin embargo, Windows sysprep funciona como una caja cerrada, por lo que es difícil gestionar ciertos errores de sysprep.

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

  4. En la última línea del resultado del comando, puede encontrar el nombre de la plantilla de máquina virtual de Windows generada. Anota el 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"

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

Omite este paso si no usas un registro privado.

Puedes automatizar la subida de imágenes de contenedores Windows a un registro privado mediante containerd en una estación de trabajo de administrador 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 al extraer la imagen. Para enviar las capas base, sigue los pasos de la opción 2.

Opción 1: Si no necesitas enviar manualmente las imágenes de la capa base de Windows al registro privado:

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

Sustituye ADMIN_CLUSTER_CONFIG por la ruta al archivo de configuración del clúster de administrador.

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

Opción 2: Si necesitas enviar manualmente las imágenes de la capa base de Windows al registro privado:

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

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

    • Ve al archivo daemon.json de Docker en tu equipo Windows: 

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

    • Añade las siguientes líneas para configurar tu archivo daemon.json de Docker y permitir que se inserten capas externas en tu registro privado:

    {
  "allow-nondistributable-artifacts": ["PRIVATE_REGISTRY_NAME"]
}
    • Descarga las imágenes de contenedor de Windows necesarias en tu máquina Windows local y, a continuación, etiquétalas y súbelas a tu registro privado. Los cambios que has hecho en el archivo de configuración de daemon.json Docker significan que la capa base se puede enviar 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: (Obligatorio si se usa un proxy) Incluir URLs en la lista de permitidos para crear grupos de nodos de Windows

Si tu clúster está detrás de un servidor proxy, añade estas URLs a la lista de permitidos del servidor proxy, además de las otras direcciones que requiere Google Distributed Cloud.

# 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

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

  1. Para usar grupos de nodos de Windows, debe habilitar Dataplane V2 en su clúster de usuario. Añade la siguiente línea al archivo de configuración del clúster de usuarios para habilitar Dataplane V2:

    enableDataplaneV2: true

  2. Añade un grupo de nodos de Windows a la sección nodePools del archivo de configuración del clúster de usuarios. Además de los grupos de nodos de Windows, debes tener al menos un grupo de nodos de Linux. Define los campos osImage y osImageType para crear grupos de nodos de Windows:

  • osImage: sustituye WINDOWS_VM_TEMPLATE_NAME por el nombre de la plantilla de VM de Windows que has preparado 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 del 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

Paso 5: Crea grupos de nodos de Windows

Antes de crear grupos de nodos de Windows, ejecuta una lista de validadores de comprobación previa para Windows. Sáltate este paso si ya tienes un clúster de usuarios. - (Opcional) Ejecuta una o ambas comprobaciones previas, la rápida y la lenta, que crean una máquina virtual de prueba para Windows y validan la plantilla de máquina virtual de Windows:

gkectl check-config --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG
  • Este comando está pensado para que lo ejecutes antes de crear un clúster de usuarios. Si ya tienes un clúster de usuarios, es posible que algunas comprobaciones fallen. Por ejemplo, las direcciones IP del archivo hostconfig.yaml ya pueden estar en uso por nodos de tu clúster de usuarios.
  • Aunque no es recomendable, puedes omitir las comprobaciones previas de Windows con la marca --skip-validation-windows.
  • La gestión de grupos de nodos de Windows es la misma que la de grupos de nodos de Linux. Consulta la guía de usuario para grupos de nodos del SO de Windows Server. Los comandos para crear, actualizar y cambiar a un plan superior de clústeres y grupos de nodos también siguen siendo los mismos y se indican 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: Valida que los nodos de Windows se estén ejecutando

  1. Comprueba que se hayan creado tus nodos de Windows y que estén Ready.

    kubectl --kubeconfig USER_KUBECONFIG get nodes

  2. Diagnostica el clúster de usuarios para comprobar si está en buen estado.

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

Desplegar un pod de Windows

Los nodos de Windows Server están etiquetados con este par clave-valor: node.kubernetes.io/os=windows:NoSchedule.

Esta marca asegura que el programador de GKE no intente ejecutar contenedores 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 comprueba si hay cargas de trabajo nuevas con este selector de nodos de Windows y, cuando lo encuentra, aplica la siguiente tolerancia a la carga de trabajo, lo que le permite ejecutarse en los nodos de Windows Server contaminados:

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

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

A continuación, se muestra una configuración de ejemplo que implementa la imagen oficial de IIS de Microsoft en un solo pod.

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: Crea la implementación y exponla a través de un servicio

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

Paso 3: Valida el Pod

Comprueba el estado del Pod con kubectl.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods

Espera hasta que el resultado devuelto muestre que el pod tiene el estado "Running".

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

Obtén el estado del servicio y espera hasta que se rellene el campo de 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.

Actualizar un clúster de usuarios con grupos de nodos de Windows

El proceso de actualización de un clúster de usuario con grupos de nodos de Windows es similar al de los clústeres de usuario solo de Linux, con la diferencia de que debes crear una plantilla de VM de Windows a partir de una plantilla de VM base antes de realizar la actualización.

Puedes actualizar la versión de compilación del parche de la plantilla de VM base durante la actualización descargando una versión de parche más reciente de Windows Server 2019 de Microsoft como parche de seguridad. Consulta el proceso de parche de seguridad.

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

Actualiza el campo osImage del archivo de configuración del grupo de nodos con el nuevo nombre de la plantilla de VM. Ejecuta el siguiente comando para actualizar el clúster de usuarios:

gkectl upgrade cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Haz los cambios siguientes:

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

Acceder a nodos de Windows

La forma estándar de acceder a los nodos de Windows es con un nombre de usuario y una contraseña, lo que difiere de los nodos de Linux, a los que se suele acceder mediante pares de claves SSH para la autenticación.

En el caso de los nodos de Windows en vSphere, el nombre de usuario es Administrator. La contraseña la genera clusterapi-controller y se almacena en el secreto windows-node-password en el espacio de nombres de usuario del clúster de administrador. El comando para obtener la contraseña de ese secreto 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 obtener la contraseña mediante la interfaz de usuario de vCenter. Desplázate hasta la máquina virtual en la que quieras iniciar sesión y, a continuación, busca la contraseña en la propiedad password vApp de esa máquina virtual.

Una vez que tengas el nombre de usuario y la contraseña, podrás acceder a tu VM de Windows de cualquiera de las siguientes formas:

Usar el protocolo de escritorio remoto

Como RDP se ha habilitado durante la compilación de la plantilla, puedes acceder a tu VM Windows mediante un cliente RDP.

Usar SSH

Para acceder a una VM de Windows mediante SSH, sigue estos pasos:

ssh Administrator@[VM_IP_ADDRESS]

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

Transferir archivos a tu máquina virtual de Windows y viceversa

Puedes transferir archivos a tu máquina virtual de Windows y desde ella con el comando scp:

Sube archivos a una máquina virtual de Windows:

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

Descargar archivos de una máquina virtual de Windows:

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

Introduce la contraseña cuando se te solicite.

También puedes transferir archivos mediante Cloud Storage o RDP, tal como se describe en el artículo sobre cómo transferir archivos a máquinas virtuales Windows.

Actualizar la configuración de Windows Server

Containerd y Windows Dataplane V2 ya están disponibles para todos los usuarios a partir de la versión 1.11.

Docker y Flannel para nodos de Windows dejarán de estar disponibles en una versión posterior. Si procede, te recomendamos que actualices tu configuración ahora para usar containerd y Windows Dataplane V2. Consulta Actualizar la configuración de Windows Server.

No se puede conectar a la VM de Windows mediante SSH o RDP

Comprueba si la máquina virtual tiene conexión de red ejecutando Test-NetConnection en la consola web de vCenter.

El resultado debe contener PingSucceeded: true si hay una conexión de red. Si la VM no tiene conexión de red, comprueba el adaptador de red que se usa en esta VM. Asegúrate de que la red permita las conexiones entrantes a la VM desde tu estación de trabajo, donde quieras ejecutar SSH o RDP.

Verifica que los servicios kubelet, kube-proxy y CNI se estén ejecutando en la VM de Windows

Conéctate a tu VM siguiendo estos pasos y ejecuta los siguientes comandos, según tu configuración:

  1. En 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 definido como true, comprueba que los servicios antrea-agent, ovsdb-server y ovs-vswitchd estén en el estado "Running" (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, comprueba que el proceso flanneld esté en el estado "Running":

    # Check that the flanneld process exists
Get-Process flanneld

Usar la herramienta de captura

Usa la herramienta de instantánea para obtener el archivo tar. Este archivo tar contiene los archivos de registro de los nodos, así como las salidas de 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]

No se puede crear una VM de Windows

Consulta los registros del contenedor vsphere-controller-manager en el pod clusterapi-controllers del espacio de nombres del 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 usuarios.

Se crea una VM de Windows, pero el nodo no se inicia correctamente o no aparece

  • Consulta los registros de inicio del nodo ubicado en C:\var\log\startup.log para ver si no se ha podido iniciar algún elemento.

    • Si flanneld no se está ejecutando, prueba a volver a ejecutar la secuencia de comandos de inicio ubicada en C:\etc\startup\startup-script.ps1.
    • Si kubelet no se está ejecutando, consulta los registros de kubelet en C:\var\log.
    • Si kube-proxy no se está ejecutando, consulta los registros de kube-proxy en C:\var\log.

  • Comprueba si cloudbase-init ya ha ejecutado UserDataPlugin antes de ejecutar la secuencia de comandos de inicio.

Para comprobarlo, establece una conexión SSH con la VM Windows y ejecuta el siguiente comando:

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

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

Esto suele ocurrir cuando se convierte la plantilla de VM generada por gkectl prepare windows en una VM y se enciende.

Para resolver este problema, crea una plantilla de VM ejecutando gkectl prepare windows de nuevo y úsala para crear, actualizar o modificar un grupo de nodos de Windows.

Logging y Monitoring

Google Distributed Cloud admite registro y monitorización para nodos y pods de Windows, al igual que para nodos y pods de Linux.

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

Agente de registro de Windows

El agente de registro de Windows recoge los siguientes registros:

  • Tipo de recurso de pod: cargas de trabajo de aplicaciones del sistema y del usuario.

    Ten en cuenta que los registros de las cargas de trabajo de las aplicaciones de usuario de Windows se recogen de forma predeterminada. Para inhabilitar los registros de aplicaciones, sigue estos pasos:

    • Edita el fluent-bit-windows-config configmap y comenta el elemento [Input] que recoge 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.(?<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
    • Ejecuta el comando rollout restart para reiniciar el conjunto de daemons 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 mediante el Explorador de registros de la consola. Consulta Registros de acceso para obtener más información.

Agente de monitorización de Windows

El agente de monitorización de Windows recoge un conjunto de métricas de uso de CPU y memoria diferente al del agente de monitorización de Linux. Para monitorizar el estado de los nodos y los pods de Windows, usa los paneles de control preparados. En la consola, selecciona Monitorización > Paneles de control y, a continuación, elige "Estado del nodo de Windows de GKE On-Prem" y "Estado del pod de Windows de GKE On-Prem" en la lista Todos los paneles de control.

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

Consulte la lista completa de métricas que recogen los agentes de Windows.

Almacenamiento persistente de Windows

Cuando trabajes 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 el objeto StorageClass predeterminado del clúster de usuario local utiliza ext4 como tipo de sistema de archivos, que solo funciona con contenedores de Linux. En Windows, debemos definir el tipo de sistema de archivos como 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 despliega automáticamente en los nodos de Windows. Puedes instalar y usar un controlador de CSI de Windows de tu elección, como el controlador de CSI para SMB.

Node Problem Detector en nodos de Windows

El daemon Node Problem Detector está disponible en los nodos de Windows. Si has actualizado a la versión 1.9, Node Problem Detector se habilita automáticamente. Node Problem Detector ayuda a detectar rápidamente algunos problemas habituales de los nodos. Node Problem Detector sigue buscando posibles problemas y los comunica como eventos y condiciones en el nodo. Cuando un nodo se comporta de forma incorrecta, puedes usar el comando kubectl para buscar los eventos y las condiciones correspondientes.

Las siguientes configuraciones de monitorización están habilitadas para Node Problem Detector:

Para obtener los eventos y las condiciones de un nodo, sigue estos pasos:

kubectl --kubeconfig KUBECONFIG describe nodes NODE_NAME

Sustituye:

  • KUBECONFIG con la ruta del archivo kubeconfig del clúster que contiene el nodo.
  • NODE_NAME con el nombre del nodo.

Para identificar los eventos generados por 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 estos campos se define como true si Node Problem Detector detecta el escenario de fallo correspondiente en el nodo.

  • KubeletUnhealthy
  • KubeProxyUnhealthy
  • ContainerRuntimeUnhealthy

Cuando una de las condiciones se establece en true, la condición Ready del nodo pasa a ser false, lo que impide que se programen nuevos pods en el nodo.

Cuando se detecta un estado incorrecto, Node Problem Detector intenta reparar automáticamente el nodo reiniciando el servicio del sistema correspondiente.

Los registros de Node Problem Detector se encuentran en la carpeta C:\var\log\node-problem-detector del nodo. Si la monitorización y el registro 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"

Sustituye PROJECT_NAME por el nombre del proyecto.

Proceso de aplicación de parches de seguridad

Además de los lanzamientos de parches periódicos para las versiones de Anthos compatibles, el equipo de Anthos también valida continuamente las actualizaciones de parches de Windows más recientes durante los periodos en los que no se lanzan versiones y publica los resultados para que puedas consultarlos. Si se necesita una actualización de parche de seguridad urgente entre las versiones de parches de Anthos, puedes crear una plantilla de VM con la versión más reciente y, a continuación, realizar una actualización gradual de los grupos de nodos de Windows para que usen la nueva plantilla.

El proceso de aplicación de parches de seguridad incluye estos pasos:

  • Microsoft lanza un nuevo parche de seguridad para Windows Server 2019.
  • Anthos valida la versión más reciente del parche de seguridad y anuncia el resultado de la validación.
  • Si cumplen los requisitos, los usuarios podrán hacer lo siguiente:
    • Descargar la versión de parche más reciente de Microsoft
    • Crea una plantilla de VM de Windows con esta versión del parche siguiendo los pasos que se indican aquí.
    • Actualiza los grupos de nodos de Windows para que usen la nueva plantilla ejecutando el siguiente comando:
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

  • Si la nueva versión requiere cambios por parte de Anthos, debes esperar a la próxima versió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 se saltará esa versión y esperará a la siguiente actualización de seguridad de Microsoft.

Unión a un dominio de Active Directory

Para unir un dominio de Active Directory, el nombre de host de la máquina virtual debe tener 15 caracteres o menos. En el modo IPAM, como el nombre de host de la VM se define en el archivo de configuración del clúster de usuario, debes asegurarte de que la longitud sea de 15 caracteres o menos. 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.

Verificar que se puede acceder al servidor DNS del 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 controladores de dominio y para que los controladores de dominio que hospedan el servicio de directorio puedan comunicarse entre sí.

El servidor DNS se creó cuando el rol AD DS instaló el bosque raíz. Para que una máquina virtual de Windows se una al dominio de AD, debe poder acceder al servidor DNS. Configura el DNS y el cortafuegos siguiendo las instrucciones del proveedor del servicio de DNS que estés usando. Para comprobar si las VMs de Windows de la red actual pueden ponerse en contacto con el servidor DNS del dominio de AD, 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 usuarios para unirse al dominio de Active Directory. Guarda esta secuencia de comandos en una ruta local de tu estación de trabajo de administrador. Ten en cuenta que:

    • Puedes sustituir la secuencia de comandos por la tuya para unir el dominio de Active Directory.
    • Te recomendamos que uses una cuenta de usuario con los permisos mínimos necesarios para unirte a un dominio de Active Directory, en lugar de usar una cuenta de administrador.
    • (Opcional) Para evitar almacenar la contraseña como texto sin cifrar en esta secuencia de comandos, coloca la contraseña en un archivo de la plantilla de VM, deja que la secuencia de comandos lea ese archivo de contraseña y, a continuación, elimina el archivo después de unir el dominio.
    $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

Sustituye BUNDLE_PATH por la ruta del paquete.

Paso 2: Crea un grupo de nodos de Windows

Sigue las instrucciones estándar de los pasos del 2 al 6 para crear un grupo de nodos de Windows con la plantilla de VM de Windows personalizada.

Paso 3: Verifica la unión al dominio activo de 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: Configura las cuentas de servicio gestionadas grupales (opcional)

Sigue estas instrucciones: Configurar GMSA para pods y contenedores de Windows. Puedes configurar GMSA para pods y contenedores de Windows después de que los nodos se hayan unido al dominio.

Solución de problemas

Los registros de la ejecución del script personalizado 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 consulta los registros relacionados. - Crea una plantilla de VM de Windows. - Actualiza los grupos de nodos de Windows para que usen la nueva plantilla ejecutando el siguiente comando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Consideraciones sobre los contenedores de Windows

Estas son algunas de las diferencias más importantes entre los contenedores de Windows y Linux:

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

Limitaciones de Google Distributed Cloud en vSphere Windows

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

    • No puedes crear un clúster que solo tenga un grupo de nodos de Windows
    • Los grupos de nodos de Linux son necesarios para ejecutar complementos críticos.

  • Como se reservan 1,5 veces más recursos para los nodos de Windows que para los de Linux, los recursos asignables de Windows son inferiores.

  • Para usar nodos de Windows, puede que se requiera un tamaño mínimo de máquina superior al de Linux de Google Distributed Cloud. Los nodos de Windows suelen requerir más recursos debido a la mayor sobrecarga que supone 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 Google Distributed Cloud, así como las soluciones alternativas para evitar estos problemas o recuperarse de ellos.

Los pods de Windows no pueden comunicarse con direcciones IP externas

Este problema se describe en la documentación de Microsoft, donde se indica que "debe excluir la IP externa que está intentando consultar de ExceptionList".

Ponte en contacto con el equipo de Asistencia de Google Cloud para aplicar una solución alternativa.

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

Se trata de un problema conocido en el que docker RemoveContainer también intenta llamar a CreateFile en Windows. Como solución alternativa, inicia sesión en el nodo de Windows que tiene el problema, ejecuta Restart-Service docker y el problema debería solucionarse. A partir de Google Distributed Cloud 1.9, se han actualizado la versión de la imagen del contenedor fluent-bit-win y la versión de Docker para incluir las correcciones de este problema, por lo que ya no debería reproducirse. Si tienes este problema, ponte en contacto con el equipo de Asistencia de Google Cloud.

Nodos de Windows con conflictos de direcciones IP

Se trata de un problema conocido que ocurre muy raramente. Si te encuentras con él durante la creación de un grupo de nodos de Windows, puedes mitigarlo siguiendo estos pasos:

  • Si usas el modo IPAM, puedes quitar manualmente de vCenter las VMs que tengan conflictos de IP. Se crearán automáticamente VMs nuevas que deberían tener asignaciones de IP correctas. También puedes esperar a que la reparación automática de nodos detecte este problema y vuelva a crear los nodos de Windows.

  • Si usas el modo DHCP, es probable que las VMs recién creadas vuelvan a tener IPs duplicadas, ya que el servidor DHCP tiene problemas para asignar IPs. Puedes eliminar el grupo de nodos de Windows pendiente ejecutando gkectl update cluster y volver a añadirlo en user-cluster.yaml. Ejecuta gkectl update cluster de nuevo para crearlo. El grupo de nodos recién creado debería tener asignaciones de IP correctas.

El nodo de Windows pasa a tener el estado NotReady después de reiniciar la VM

Actualmente, la secuencia de comandos de inicio de nodo solo se ejecuta la primera vez que se enciende la VM, por lo que, si reinicias la VM, la secuencia de comandos de inicio no se vuelve a ejecutar. Esto hará que algunos servicios de Windows dejen de ejecutarse, incluidos los servicios kubelet y kube-proxy, entre otros. Esto provoca que el nodo tenga el estado NotReady. Si usas Windows Dataplane V2, también es necesario limpiar la red obsoleta antes de que se reinicien los servicios de Dataplane V2, y se requerirá ejecutar una secuencia de comandos para la limpieza, lo que podría causar complicaciones. Por lo tanto, vuelve a crear el nodo. Como solución alternativa, puedes eliminar el nodo ejecutando el comando que se indica a continuación 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 máquina virtual de Windows son inferiores a las esperadas

Si la plantilla de VM de Windows usa una versión de hardware antigua, el comando gkectl diagnose cluster falla y se 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 este problema, sigue estos pasos:

  1. Cambia el nombre de la plantilla de VM que se está usando.

    Esto es necesario para poder crear una plantilla de VM en los pasos siguientes.

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

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

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

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

    gkectl prepare windows

    El nombre de la plantilla de VM generada debe coincidir con el valor del campo osImage del 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, actualice el valor de osImage para que coincida con el nuevo nombre de la plantilla de VM generada y ejecute el siguiente comando:

    gkectl update cluster

  6. Vuelve a crear el nodo de Windows ejecutando el siguiente comando:

    kubectl --kubeconfig USER_KUBECONFIG delete node NODE_NAME

    Espera a que el controlador vuelva a crear el nodo automáticamente.