Crea un clúster mediante grupos de nodos de Windows Server

En esta página, aprenderás a crear un clúster de Google Kubernetes Engine (GKE) con grupos de nodos que ejecutan Microsoft Windows Server. Con este clúster, puedes usar contenedores de Windows Server. En la actualidad, los contenedores de Microsoft Hyper-V no son compatibles. Al igual que los contenedores de Linux, los contenedores de Windows Server proporcionan aislamiento de procesos y espacios de nombres.

Un nodo de Windows Server requiere más recursos que un nodo de Linux típico. Los nodos de Windows Server necesitan los recursos adicionales para ejecutar el SO de Windows y para los componentes de Windows Server que no se pueden ejecutar en contenedores. Dado que los nodos de Windows Server requieren más recursos, tus recursos asignables son más bajos que con los nodos de Linux.

Crea un clúster mediante grupos de nodos de Windows Server

En esta sección, crearás un clúster que use un contenedor de Windows Server.

Para crear este clúster, debes completar las siguientes tareas:

  1. Elige tu imagen de nodo de Windows Server.
  2. Actualiza y configura gcloud.
  3. Crea un clúster y grupos de nodos.
  4. Obtén credenciales kubectl.
  5. Espera la inicialización del clúster.

Elige tu imagen de nodo de Windows Server

Para ejecutarse en GKE, las imágenes de nodo del contenedor de Windows Server deben compilarse en Windows Server 2019 (LTSC), Windows Server 20H2 (SAC) o Windows Server 2022 (LTSC). Un solo clúster puede tener varios grupos de nodos de Windows Server con diferentes versiones de Windows Server, pero cada grupo de nodos individual puede usar solo una versión de Windows Server.

Ten en cuenta lo siguiente cuando elijas la imagen de nodo:

  • Tiempo de asistencia:
    • El tiempo de asistencia para una imagen de nodo de Windows Server está sujeto a los tiempos de asistencia proporcionados por Microsoft, como se describe en Política de asistencia para imágenes de SO. Puedes encontrar la fecha de finalización de la asistencia para las imágenes de nodo de Windows en GKE mediante el comando gcloud container get-server-config, como se describe en la sección Asigna versiones de GKE y Windows.
    • Las versiones de SAC solo son compatibles con Microsoft durante 18 meses después de su lanzamiento inicial. Si eliges SAC para el tipo de imagen de tu grupo de nodos, pero no actualizas el grupo de nodos a versiones más recientes de GKE, no puedes crear nodos nuevos en el grupo de nodos cuando el ciclo de vida de la compatibilidad para la versión de SAC finaliza. Obtén más información sobre la asistencia de Google para el sistema operativo Windows Server. Recomendamos usar LTSC debido a su ciclo de vida de compatibilidad más largo.
    • No elijas SAC si inscribes tu clúster de GKE en el canal de versiones estable. Debido a que Microsoft solo admite las versiones de SAC durante 18 meses, existe el riesgo de que la imagen del grupo de nodos de SAC deje de ser compatible mientras la versión estable de GKE aún está disponible.
  • Compatibilidad y complejidad de las versiones:
    • Solo elige SAC si puedes actualizar el grupo de nodos y los contenedores que se ejecutan en él con regularidad. GKE actualiza la versión de SAC que se usa para los grupos de nodos de Windows en las versiones nuevas de GKE de forma periódica. Por lo tanto, si deseas elegir SAC para el tipo de imagen del grupo de nodos, es necesario que vuelvas a compilar los contenedores con más frecuencia.
    • Si no estás seguro de qué tipo de imagen de Windows Server usar, recomendamos elegir LTSC de Windows Server para evitar problemas de incompatibilidad de versiones cuando actualizas el grupo de nodos. Para obtener información adicional, consulta Canales de servicio de Windows Server: LTSC y SAC en la documentación de Microsoft.
    • Windows Server Core y Nano Server se pueden usar como una imagen base para los contenedores.
    • Los contenedores de Windows Server tienen requisitos de compatibilidad de versión importantes:
      • Los contenedores de Windows Server compilados para LTSC no se ejecutan en nodos SAC y viceversa.
      • Los contenedores de Windows Server compilados para una versión específica de LTSC o SAC no se ejecutan en otras versiones de LTSC o SAC si no se vuelven a compilar con ese fin.
    • Si compilas las imágenes de contenedor de Windows Server como imágenes basadas en varios arcos que pueden orientarse a varias versiones de Windows Server, puede ser más sencilla la administración de esta complejidad del control de versiones.
  • Nuevas funciones
    • Por lo general, las funciones nuevas de Windows Server se presentan primero en las versiones de SAC. Debido a esto, es posible que primero se incorpore la funcionalidad nueva de GKE para Windows en los grupos de nodos de SAC.
    • Considera SAC si dependes de funciones que aún no están disponibles en la versión LTSC.

  • Entorno de ejecución del contenedor:

    • Para las imágenes de nodo de LTSC y SAC de Windows Server, el entorno de ejecución del contenedor puede ser Docker o Containerd. Para la versión de nodo 1.21.1-gke.2200 y posteriores de GKE, recomendamos usar el entorno de ejecución de Containerd. Para obtener más información, consulta Imágenes de nodo.

Actualiza y configura gcloud

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Kubernetes Engine de Google.
    • Habilitar la API de Kubernetes Engine de Google
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Crea un clúster y grupos de nodos

Para ejecutar contenedores de Windows Server, tu clúster debe tener al menos un grupo de nodos de Windows y uno de Linux. No puedes crear un clúster solo mediante un grupo de nodos de Windows Server. El grupo de nodos de Linux es necesario para ejecutar complementos esenciales del clúster.

Debido a su importancia, recomendamos activar el ajuste de escala automático a fin de garantizar que el grupo de nodos de Linux tenga capacidad suficiente para ejecutar complementos del clúster.

gcloud

Crea un clúster con los siguientes campos:

gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
    --cluster-version=VERSION_NUMBER \
    --release-channel CHANNEL

Reemplaza lo siguiente:

  • CLUSTER_NAME es el nombre que eliges para el clúster.
  • --enable-ip-alias activa el alias de IP. El alias de IP es obligatorio para los nodos de Windows Server. Para obtener más información sobre sus beneficios, consulta la Descripción del enrutamiento de contenedores nativos con alias de IP.
  • NUMBER_OF_NODES es la cantidad de nodos de Linux que creas. Debes proporcionar recursos de procesamiento suficientes para ejecutar complementos del clúster. Este es un campo opcional y, si se omite, se usará con el valor predeterminado de 3.
  • VERSION_NUMBER: la versión específica del clúster que deseas usar, que debe ser 1.16.8-gke.9 o superior. Si no especificas un canal de versiones, GKE inscribe tu clúster en el canal de versiones más maduro en el que está disponible esa versión.
  • CHANNEL es el canal de versiones para inscribir el clúster, que puede ser uno de rapid, regular, stable o None. De forma predeterminada, el clúster se inscribe en el canal de versiones regular, a menos que se especifique al menos una de las siguientes marcas: --cluster-version, --release-channel, --no-enable-autoupgrade y --no-enable-autorepair. Debes especificar None si eliges una versión del clúster y no quieres que tu clúster esté inscrito en un canal de versiones.

Crea el grupo de nodos de Windows Server con los siguientes campos:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME \
    --windows-os-version=WINDOWS_OS_VERSION

Reemplaza lo siguiente:

  • NODE_POOL_NAME es el nombre que eliges para el grupo de nodos de Windows Server.
  • CLUSTER_NAME es el nombre del clúster que creaste antes.

  • IMAGE_NAME: Puedes especificar uno de los siguientes valores:

    Para obtener más información sobre estas imágenes de nodo, consulta la sección sobre cómo elegir tu imagen de nodo de Windows.

  • --no-enable-autoupgrade inhabilita la actualización automática de nodos. Revisa Actualiza grupos de nodos de Windows Server antes de habilitarlos.

  • MACHINE_TYPE_NAME define el tipo de máquina. n1-standard-2 es el tipo de máquina mínimo recomendado, ya que los nodos de Windows Server requieren recursos adicionales. Los tipos de máquina f1-micro y g1-small no son compatibles. Cada tipo de máquina se factura de manera diferente. Para obtener más información, consulta la hoja de precios de los tipos de máquinas.

  • WINDOWS_OS_VERSION: Define la versión del SO de Windows que se usará para el tipo de imagen WINDOWS_LTSC_CONTAINERD. Esta es una marca opcional. Si no se especifica, la versión predeterminada del SO que se usará será LTSC2019. Establece el valor en ltsc2022 para crear un grupo de nodos de Windows Server 2022. Establece el valor en ltsc2019 para crear un grupo de nodos de Windows Server 2019.

En el siguiente ejemplo, se muestra cómo crear un grupo de nodos de Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

En el siguiente ejemplo, se muestra cómo actualizar un grupo de nodos de Windows existente para usar la imagen de SO de Windows Server 2022:

gcloud container node-pools create node_pool_name \
    --cluster=cluster_name \
    --windows-os-version=ltsc2022

Consola

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Haz clic en Crear.

  3. En la sección Aspectos básicos del clúster, completa lo siguiente:

    1. Ingresa el nombre de tu clúster.
    2. En Tipo de ubicación, selecciona la región o zona deseada para el clúster.
    3. En Versión del plano de control, selecciona un canal de versiones o elige especificar una versión estática. La versión estática debe ser 1.16.8-gke.9 o versión posterior.

  4. En el panel de navegación, en Grupos de nodos, haz clic en default-pool para crear tu grupo de nodos de Linux. Cuando configures este grupo de nodos, debes proporcionar recursos de procesamiento suficientes para ejecutar complementos del clúster. También debes tener una cuota de recursos disponible para los nodos y sus recursos (como las rutas de firewall).

  5. En la parte superior de la página, haz clic en Agregar grupo de nodos para crear el grupo de nodos de Windows Server.

  6. En la sección Detalles del grupo de nodos, completa lo siguiente:

    1. Ingresa un Nombre para el grupo de nodos.
    2. Para los nodos de la versión estática, elige la Versión de nodo.
    3. Ingresa la Cantidad de nodos que se crearán en el grupo.

  7. En el panel de navegación, en Grupos de nodos, haz clic en Nodos.

    1. En la lista desplegable Tipo de imagen, selecciona una de las siguientes imágenes de nodo:

      • Canal de servicio a largo plazo de Windows con Docker
      • Canal de servicio a largo plazo de Windows con Containerd
      • Canal semianual de Windows con Docker
      • Canal semianual de Windows con Containerd

      Para obtener más información, consulta la sección Elige tu imagen de nodo de Windows.

    2. Elige la Configuración de la máquina predeterminada para usar en las instancias. n1-standard-2 es el tamaño mínimo recomendado, ya que los nodos de Windows Server requieren recursos adicionales. Los tipos de máquina f1-micro y g1-small no son compatibles. Cada tipo de máquina se factura de manera diferente. Para obtener más información, consulta la hoja de precios de tipos de máquinas.

  8. En el panel de navegación, selecciona el nombre de tu grupo de nodos de Windows Server. Esto te lleva de vuelta a la página Detalles del grupo de nodos.

    1. En Automatización, desactiva la casilla de verificación Habilitar la actualización automática de nodos. Revisa la sección Actualiza grupos de nodos de Windows Server antes de habilitar la actualización automática.

  9. En el panel de navegación, en Clúster, selecciona Herramientas de redes.

    1. En Opciones avanzadas de redes, asegúrate de que esté seleccionada la opción Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP). El alias de IP es obligatorio para los nodos de Windows Server. Para obtener más información sobre sus beneficios, consulta la Descripción del enrutamiento de contenedores nativos con alias de IP.

  10. Haz clic en Crear.

Terraform

Puedes usar el proveedor de Terraform de Google para crear un clúster de GKE con un grupo de nodos de Windows Server.

Agrega este bloque a la configuración de Terraform:

resource "google_container_cluster" "cluster" {
  project  = "PROJECT_ID"
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  min_master_version = "VERSION_NUMBER"

  # Enable Alias IPs to allow Windows Server networking.
  ip_allocation_policy {
    cluster_ipv4_cidr_block  = "/14"
    services_ipv4_cidr_block = "/20"
  }

  # Removes the implicit default node pool, recommended when using
  # google_container_node_pool.
  remove_default_node_pool = true
  initial_node_count       = 1
}

# Small Linux node pool to run some Linux-only Kubernetes Pods.
resource "google_container_node_pool" "linux_pool" {
  name       = "linux-pool"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type = "COS_CONTAINERD"
  }
}

# Node pool of Windows Server machines.
resource "google_container_node_pool" "windows_pool" {
  name       = "NODE_POOL_NAME"
  project    = google_container_cluster.cluster.project
  cluster    = google_container_cluster.cluster.name
  location   = google_container_cluster.cluster.location
  node_count = 1

  node_config {
    image_type   = "IMAGE_NAME"
    machine_type = "MACHINE_TYPE_NAME"
  }

  # The Linux node pool must be created before the Windows Server node pool.
  depends_on = [google_container_node_pool.linux_pool]
}

Reemplaza lo siguiente:

  • PROJECT_ID es el ID del proyecto en el que se crea el clúster.
  • CLUSTER_NAME es el nombre del clúster de GKE.
  • LOCATION es la ubicación (región o zona) en la que se crea el clúster.
  • VERSION_NUMBER debe ser 1.16.8-gke.9 o una versión posterior.
  • NODE_POOL_NAME es el nombre que eliges para el grupo de nodos de Windows Server.

  • IMAGE_NAME: Puedes especificar uno de los siguientes valores:

    Para obtener más información sobre estas imágenes de nodo, consulta la sección sobre cómo elegir tu imagen de nodo de Windows.

  • MACHINE_TYPE_NAME define el tipo de máquina. n1-standard-2 es el tipo de máquina mínimo recomendado, ya que los nodos de Windows Server requieren recursos adicionales. Los tipos de máquina f1-micro y g1-small no son compatibles. Cada tipo de máquina se factura de manera diferente. Para obtener más información, consulta la hoja de precios de los tipos de máquinas.

Después de crear un grupo de nodos de Windows Server, el clúster entra en un estado de RECONCILE durante varios minutos mientras se actualiza el plano de control.

Obtén credenciales de kubectl

Usa el comando get-credentials para habilitar kubectl, de modo de que funcione con el clúster que creaste.

gcloud container clusters get-credentials CLUSTER_NAME

Para obtener más información sobre el comando get-credentials, consulta la documentación get-credentials del SDK.

Espera la inicialización del clúster

Antes de usar el clúster, espera varios segundos hasta que se cree windows.config.common-webhooks.networking.gke.io. Este webhook agrega tolerancias de programación a los pods creados mediante el selector de nodos kubernetes.io/os: windows para garantizar que se puedan ejecutar en nodos de Windows Server. También valida el pod para garantizar que solo use funciones compatibles con Windows.

Para asegurarte de que se cree el webhook, ejecuta el siguiente comando:

kubectl get mutatingwebhookconfigurations

La salida debería mostrar el webhook en ejecución:

NAME                                              CREATED AT
windows.config.common-webhooks.networking.gke.io  2019-12-12T16:55:47Z

Ahora que tienes un clúster con dos grupos de nodos (uno de Linux y uno de Windows), puedes implementar en una aplicación de Windows.

Asigna versiones de GKE y Windows

Microsoft lanza versiones nuevas de SAC alrededor de cada seis meses y versiones nuevas de LTSC cada dos o tres años. Estas versiones nuevas suelen estar disponibles en las versiones secundarias de GKE nuevas. Dentro de una versión secundaria de GKE, las versiones de LTSC y SAC suelen permanecer fijas.

Para ver la asignación de versiones entre versiones de GKE y versiones de Windows Server, usa el comando gcloud beta container get-server-config:

gcloud beta container get-server-config

La asignación de versiones se muestra en el campo windowsVersionMaps de la respuesta. Para filtrar la respuesta y ver la asignación de versiones para las versiones específicas de GKE en tu clúster, realiza los siguientes pasos en una shell de Linux o en Cloud Shell.

  1. Configura las siguientes variables:

    CLUSTER_NAME=CLUSTER_NAME
NODE_POOL_NAME=NODE_POOL_NAME
ZONE=COMPUTE_ZONE

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre de tu clúster.
    • NODE_POOL_NAME: el nombre de tu grupo de nodos de Windows Server.
    • COMPUTE_ZONE: es la zona de procesamiento del clúster.

  2. Obtén la versión del grupo de nodos y almacénala en la variable NODE_POOL_VERSION:

    NODE_POOL_VERSION=`gcloud container node-pools describe $NODE_POOL_NAME \
--cluster $CLUSTER_NAME --zone $ZONE --format="value(version)"`

  3. Obtén las versiones de Windows Server para NODE_POOL_VERSION:

    gcloud beta container get-server-config \
    --format="yaml(windowsVersionMaps.\"$NODE_POOL_VERSION\")"

    El resultado es similar a este:

    windowsVersionMaps:
  1.18.6-gke.6601:
    windowsVersions:
    - imageType: WINDOWS_SAC
      osVersion: 10.0.18363.1198
      supportEndDate:
        day: 10
        month: 5
        year: 2022
    - imageType: WINDOWS_LTSC
      osVersion: 10.0.17763.1577
      supportEndDate:
        day: 9
        month: 1
        year: 2024

  4. Obtén la versión de Windows Server para el tipo de imagen WINDOWS_SAC:

    gcloud beta container get-server-config \
  --flatten=windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions \
  --filter="windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.imageType=WINDOWS_SAC" \
  --format="value(windowsVersionMaps.\"$NODE_POOL_VERSION\".windowsVersions.osVersion)"

    El resultado es similar a este:

    10.0.18363.1198

Actualiza grupos de nodos de Windows Server

Los requisitos de compatibilidad de la versión del contenedor de Windows Server implican que es posible que las imágenes del contenedor deban volver a compilarse con el fin de que coincidan con la versión de Windows Server para una versión de GKE nueva antes de actualizar los grupos de nodos.

Para asegurarte de que tus imágenes de contenedor sigan siendo compatibles con tus nodos, te recomendamos revisar la asignación de versiones y compilar las imágenes de contenedor de Windows Server como imágenes basadas en varios arcos, que pueden orientarse a varias versiones de Windows Server. Luego, puedes actualizar las implementaciones de contenedor para orientar las imágenes basadas en varios arcos que funcionarán en la versión actual de GKE y en la próxima antes de invocar de forma manual una actualización del grupo de nodos de GKE. Las actualizaciones manuales del grupo de nodos deben realizarse con regularidad porque los nodos no pueden estar más de dos versiones secundarias detrás de la versión del plano de control.

Te recomendamos suscribirte a las notificaciones de actualización mediante Pub/Sub para recibir actualizaciones de forma proactiva sobre las versiones nuevas de GKE y las versiones del SO de Windows que usan.

Recomendamos habilitar las actualizaciones automáticas de nodos solo si compilas de forma continua imágenes de contenedor de Windows Server que se orientan a las últimas versiones de Windows Server, en particular, si usas SAC de Windows Server como el tipo de imagen. Las actualizaciones automáticas de nodos tienen menos probabilidades de causar problemas con el tipo de imagen de nodo de LTSC de Windows Server, pero aún existe el riesgo de encontrar problemas de incompatibilidad de versiones.

Actualizaciones de Windows

Las actualizaciones de Windows están inhabilitadas para los nodos de Windows Server. Las actualizaciones automáticas pueden hacer que los nodos se reinicien en momentos impredecibles, y cualquier actualización de Windows instalada después de que se inicie un nodo se perderá cuando GKE vuelva a crearlo. GKE ofrece actualizaciones de Windows mediante la actualización periódica de las imágenes de nodo de Windows Server que se usan en las versiones nuevas de GKE. Puede haber una demora entre el lanzamiento de las actualizaciones de Windows por parte de Microsoft y el momento en que están disponibles en GKE. Cuando se lanzan actualizaciones de seguridad críticas, GKE actualiza las imágenes de nodo de Windows Server lo más rápido posible.

Controla cómo se comunican los Services y los Pods de Windows

Puedes controlar cómo los Services y los Pods de Windows se comunican mediante las políticas de red.

Puedes tener un contenedor de Windows Server en clústeres que tengan habilitada la política de red en las versiones 1.22.2 y posteriores de GKE. Esta función está disponible para clústeres que usan los tipos de imagen de nodo WINDOWS_LTSC o WINDOWS_LTSC_CONTAINERD.

Si tus planos de control o nodos ejecutan versiones anteriores, puedes migrar tus grupos de nodos a una versión que admita la política de red mediante la actualización de tus grupos de nodos y tu plano de control a la versión 1.22.2 de GKE o posterior. Esta opción solo está disponible si creaste tu clúster con la marca --enable-dataplane-v2.

Después de habilitar la política de red, se activan todas las políticas configuradas antes, incluidas las políticas que no funcionaban en los contenedores de Windows Server antes de habilitar la función.

Algunos clústeres no se pueden usar con contenedores de Windows Server en clústeres que tengan habilitada la política de red. Si quieres obtener más información, revisa la sección de limitaciones que se encuentra más abajo.

Visualiza y consulta registros

Logging se habilita de forma automática en los clústeres de GKE. Puedes ver los registros de los contenedores y los registros de otros servicios en los nodos de Windows Server mediante Kubernetes Engine Monitoring.

El siguiente es un ejemplo de un filtro para obtener el registro del contenedor:

resource.type="k8s_container"
resource.labels.cluster_name="your_cluster_name"
resource.labels.namespace_name="your_namespace_id"
resource.labels.container_name="your_container_name"
resource.labels.Pod_name="your_Pod_name"

Accede a un nodo de Windows Server mediante el protocolo de escritorio remoto (RDP)

Puedes conectarte a un nodo de Windows Server en el clúster mediante RDP. Para obtener instrucciones sobre cómo conectarte, consulta Conéctate a instancias de Windows en la documentación de Compute Engine.

Compila imágenes de varios arcos

Puedes compilar las imágenes de varios arcos de forma manual o usar un compilador de Cloud Build. Para obtener instrucciones, consulta la sección sobre cómo compilar imágenes de varios arcos de Windows.

Usa gMSA

Los siguientes pasos te muestran cómo usar una cuenta de servicio administrada de grupo (gMSA) con tus grupos de nodos de Windows Server.

  1. Configura los nodos de Windows Server en tu clúster para unirte automáticamente a tu dominio de AD. Si deseas obtener instrucciones, consulta Configura nodos de Windows Server para unir automáticamente un dominio de Active Directory.

  2. Crea y otorga acceso gMSA al grupo de seguridad creado automáticamente por el servicio de unión del dominio. Este paso se debe realizar en una máquina con acceso de administrador a tu dominio de AD.

    $instanceGroupUri = gcloud container node-pools describe NODE_POOL_NAME --cluster CLUSTER_NAME --format="value(instanceGroupUrls)"
$securityGroupName = ([System.Uri]$instanceGroupUri).Segments[-1]
$securityGroup = dsquery group -name $securityGroupName
$gmsaName = GMSA_NAME
$dnsHostName = DNS_HOST_NAME

New-ADServiceAccount -Name $gmsaName -DNSHostName $dnsHostName -PrincipalsAllowedToRetrieveManagedPassword $securityGroup

Get-ADServiceAccount $gmsaName
Test-ADServiceAccount $gmsaName

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: el nombre de tu grupo de nodos de Windows Server. El grupo de seguridad creado automáticamente tiene el mismo nombre que tu grupo de nodos de Windows Server.
    • CLUSTER_NAME: El nombre de tu clúster.
    • GMSA_NAME: El nombre que eliges para la gMSA nueva.
    • DNS_HOST_NAME: El nombre de dominio completamente calificado (FQDN) de la cuenta de servicio que creaste. Por ejemplo, si GMSA_NAME es webapp01 y el dominio es example.com, entonces DNS_HOST_NAME es webapp01.example.com.

  3. A fin de configurar tu gMSA, sigue los pasos del instructivo Configura GMSA para Pods y contenedores de Windows.

Borra grupos de nodos de Windows Server

Borra un grupo de nodos de Windows Server mediante gcloud o la consola de Google Cloud.

gcloud

gcloud container node-pools delete NODE_POOL_NAME \
    --cluster=CLUSTER_NAME

Console

Para borrar un grupo de nodos de Windows Server mediante la consola de Google Cloud, sigue estos pasos:

  1. Ve a la página de Google Kubernetes Engine en la consola de Google Cloud.

    Ir a Google Kubernetes Engine

  2. Junto al clúster que deseas editar, haz clic en Acciones y, luego, en Editar.

  3. Selecciona la pestaña Nodos.

  4. En la sección Grupos de nodos, haz clic en Borrar junto al grupo de nodos que quieres borrar.

  5. Cuando se te solicite confirmación, haz clic en Borrar de nuevo.

Limitaciones

Hay algunas funciones de Kubernetes que aún no son compatibles con los contenedores de Windows Server. Además, algunas funciones son específicas de Linux y no funcionan para Windows. Para obtener una lista completa de las funciones de Kubernetes compatibles y no compatibles, consulta la documentación de Kubernetes.

Además de las características no compatibles de Kubernetes, hay algunas funciones de GKE que no son compatibles.

Para los clústeres de GKE, las siguientes funciones no son compatibles con los grupos de nodos de Windows Server:

La política de tráfico externo local en el grupo de nodos de Windows solo es compatible con la versión 1.23.4-gke.400 de GKE o una posterior.

Es posible que otros productos de Google Cloud que desees usar con clústeres de GKE no admitan grupos de nodos de Windows Server. Para conocer las limitaciones específicas, consulta la documentación de ese producto.

Soluciona problemas

Consulta la documentación de Kubernetes para obtener lineamientos generales sobre la depuración de pods y los servicios.

Problemas de nodos de containerd

Si tienes problemas conocidos con una imagen de nodo de Containerd, consulta Problemas conocidos.

Los pods de Windows no se inician

Si una versión no coincide entre el contenedor de Windows Server y el nodo de Windows que intenta ejecutar el contenedor, es posible que los pods de Windows no se inicien.

Si la versión del grupo de nodos de Windows es 1.16.8-gke.8 o posterior, revisa la documentación de Microsoft sobre el problema de incompatibilidad de contenedores de Windows Server de febrero de 2020 y compila las imágenes de contenedor con imágenes base de Windows que incluyan actualizaciones de Windows de marzo de 2020. Es posible que las imágenes de contenedor compiladas en imágenes base de Windows anteriores no se ejecuten en estos nodos de Windows y provoquen la falla del nodo con el estado NotReady.

Errores de extracción de imágenes

Las imágenes de contenedor de Windows Server y las capas individuales que las componen pueden ser bastante grandes. Su tamaño puede hacer que Kubelet agote el tiempo de espera y falle cuando se descarguen y extraigan las capas del contenedor.

Es posible que tengas este problema si ves los mensajes de error “No se pudo extraer la imagen” o “El contexto de extracción de imagen está cancelado” o un estado ErrImagePull para tus pods.

Si los errores de imagen de extracción se producen con frecuencia, debes usar grupos de nodos con una especificación de CPU más alta. La extracción de contenedores se ejecuta en paralelo en todos los núcleos, por lo que los tipos de máquinas con más núcleos reducen el tiempo de extracción general.

Prueba las siguientes opciones para extraer de forma correcta los contenedores de Windows Server:

  • Divide las capas de aplicación de la imagen del contenedor de Windows Server en capas más pequeñas que se pueden extraer más rápido. Esto puede hacer que el almacenamiento en caché de las capas de Docker sea más eficaz y que cuando se vuelva a intentar la extracción de imágenes haya más probabilidades de que se realice sin problemas. Para obtener más información sobre las capas, consulta el artículo de Docker Acerca de las imágenes, los contenedores y los controladores de almacenamiento.

  • Conéctate a los nodos de Windows Server y usa el comando docker pull de forma manual en las imágenes de contenedor antes de crear los pods.

  • Configura la marca image-pull-progress-deadline para el servicio kubelet a fin de aumentar el tiempo de espera para extraer imágenes de contenedor.

    Para establecer la marca, conéctate a los nodos de Windows y ejecuta los siguientes comandos de PowerShell.

    1. Obtén la línea de comandos existente para el servicio de Kubelet desde el registro de Windows.

      PS C:\> $regkey = "HKLM\SYSTEM\CurrentControlSet\Services\kubelet"

      PS C:\> $name = "ImagePath"

      PS C:\> $(reg query ${regkey} /v ${name} | Out-String) -match `
"(?s)${name}.*(C:.*kubelet\.exe.*)"

      PS C:\> $kubelet_cmd = $Matches[1] -replace `
"--image-pull-progress-deadline=.* ","" -replace "\r\n"," "

    2. Establece una línea de comandos nueva para el servicio de Kubelet, con una marca adicional a fin de aumentar el tiempo de espera.

      PS C:\> reg add ${regkey} /f /v ${name} /t REG_EXPAND_SZ /d "${kubelet_cmd} `
--image-pull-progress-deadline=40m "

    3. Confirma que el cambio se realizó de forma correcta.

      PS C:\> reg query ${regkey} /v ${name}

    4. Reinicia el servicio kubelet para que se aplique la marca nueva.

      PS C:\> Restart-Service kubelet

    5. Confirma que el servicio kubelet se reinició de forma correcta.

      PS C:\> Get-Service kubelet # ensure state is Running

Familia de imágenes que alcanzó el final del ciclo de vida

Cuando creas un grupo de nodos con una imagen de Windows, recibes un error similar al siguiente:

WINDOWS_SAC image family for 1.18.20-gke.501 has reached end of life, newer versions are still available.

Para resolver este error, elige una imagen de Windows que esté disponible y sea compatible. Puedes encontrar la fecha de finalización de la asistencia para las imágenes de nodo de Windows en GKE mediante el comando gcloud container get-server-config, como se describe en la sección Asigna versiones de GKE y Windows.

Tiempo de espera durante la creación del grupo de nodos

La creación del grupo de nodos puede agotar el tiempo de espera si creas una gran cantidad de nodos (por ejemplo, 500) y es el primer grupo de nodos del clúster que usa una imagen de Windows Server.

Para resolver este problema, reduce la cantidad de nodos que creas. Podrás aumentar la cantidad de nodos más adelante.

Los nodos de Windows se vuelven NotReady con el error “PLEG no está en buen estado”

Este es un problema conocido de Kubernetes que ocurre cuando varios pods se inician con rapidez en un solo nodo de Windows. Para arreglar esta situación, reinicia el nodo de Windows Server. Una solución recomendada para evitar este problema es limitar la frecuencia con la que se crean pods de Windows a un pod cada 30 segundos.

TerminationGracePeriod incoherente

El tiempo de espera del sistema de Windows para el contenedor puede diferir del período de gracia que configuraste. Esta diferencia puede hacer que Windows finalice de manera forzosa el contenedor antes del final del período de gracia que se pasó al entorno de ejecución.

Puedes modificar el tiempo de espera de Windows si editas las claves de registro locales del contenedor en el tiempo de compilación de la imagen. Si modificas el tiempo de espera de Windows, es posible que también debas ajustar TerminationGracePeriodSeconds para que coincida.

Problemas de conexión de red

Si tienes problemas de conectividad de red desde los contenedores de Windows Server, es posible que las herramientas de redes del contenedor de Windows Server supongan una MTU de red de 1500, que no es compatible con la MTU de 1460 de Google Cloud.

Verifica que la MTU de la interfaz de red en el contenedor y las interfaces de red del nodo de Windows Server estén configuradas en el mismo valor (es decir, 1460 o menos). Si deseas obtener información sobre cómo configurar la MTU, consulta problemas conocidos de los contenedores de Windows.

Problemas con el inicio de nodos

Si los nodos no se inician o no se unen al clúster de forma correcta, revisa la información de diagnóstico proporcionada en el resultado del puerto en serie del nodo.

Ejecuta el siguiente comando para consultar la salida del puerto en serie:

gcloud compute instances get-serial-port-output NODE_NAME --zone=COMPUTE_ZONE

Reemplaza lo siguiente:

Servicios intermitentes y inaccesibles en nodos de Windows con un clúster que ejecuta la versión 1.24 o anterior

Cuando se inician nodos de Windows en clústeres de Kubernetes con una gran cantidad de reglas de balanceador de cargas de servicio de red del host, hay un retraso en el procesamiento de las reglas. No se puede acceder a los servicios de forma intermitente durante el retraso, que dura alrededor de 30 segundos por regla. Este retraso puede ser significativo si hay suficientes reglas. Para obtener más información, consulta el problema original en GitHub.

Para los clústeres de GKE que ejecutan la versión 1.24 o anteriores, con cualquier nodo de Windows que tenga un evento que se reinició kube-proxy, por ejemplo, el inicio del nodo, la actualización del nodo, el reinicio manual, cualquier servicio al que se accede con un Pod que se ejecuta en ese nodo será inaccesible hasta que todas las reglas sean sincronizadas por el componente.

Para los clústeres de GKE que ejecutan la versión 1.25 o posterior, este comportamiento se mejora de forma sustancial. Para obtener detalles sobre esta mejora, consulta la solicitud de extracción en GitHub. Si tienes este problema, te recomendamos actualizar el plano de control de tu clúster a la versión 1.25 o posterior.

¿Qué sigue?