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. Actualiza y configura gcloud.
  2. Elige tu imagen de nodo.
  3. Crea un clúster y grupos de nodos.
  4. Obtén credenciales kubectl.
  5. Espera la inicialización del clúster.

Actualiza y configura gcloud

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

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

  • Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
  • Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

  1. Ejecuta gcloud init y sigue las instrucciones:

    gcloud init

    Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

    gcloud init --console-only
  2. Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
  3. Crea una configuración nueva o selecciona una existente.
  4. Elige un proyecto de Google Cloud.
  5. Elige una zona predeterminada de Compute Engine para clústeres zonales o una región para clústeres regionales o de Autopilot.

Usa gcloud config

  • Establece tu ID del proyecto predeterminado:
    gcloud config set project PROJECT_ID
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada: 
    gcloud config set compute/zone COMPUTE_ZONE
  • Si trabajas con clústeres Autopilot o regionales, configura la región de procesamiento predeterminada: 
    gcloud config set compute/region COMPUTE_REGION
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

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) o Windows Server 1909 (SAC). 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 el tipo de imagen:

  • El tiempo de compatibilidad para una imagen de nodo de Windows Server está sujeto al tiempo de compatibilidad que proporciona Microsoft, como se describe en Política de compatibilidad y ciclo de vida de los sistemas operativos. Recomendamos usar LTSC debido a su ciclo de vida de compatibilidad más largo. Considera SAC si dependes de funciones que aún no están disponibles en la versión LTSC.

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

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

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

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

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.

Compatibilidad de versiones

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.

Asignación de versiones

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.

En la siguiente tabla, se muestra cómo se mapean las versiones de GKE a las versiones de Windows Server Core:

1.15

Versión de GKE Versión de SAC Versión de LTSC
1.15.x (solo acceso anticipado) 10.0.17763 (Windows Server Core versión 1809) N/A

1.16

Versión de GKE Versión de SAC Versión de LTSC
1.16.8-gke.8 - 1.16.13-gke.401 10.0.18363.720 (Windows Server Core versión 1909) 10.0.17763.1098 (Windows Server Core 2019)
1.16.13-gke.402 - 1.16.13-gke.404 10.0.18363.1082 (Windows Server Core versión 1909) 10.0.17763.1457 (Windows Server Core 2019)
1.16.15-gke.500 10.0.18363.720 (Windows Server Core versión 1909) 10.0.17763.1098 (Windows Server Core 2019)
1.16.15-gke.1600 - 1.16.15-gke.3500 10.0.18363.1082 (Windows Server Core versión 1909) 10.0.17763.1457 (Windows Server Core 2019)
1.16.15-gke.4300 - 1.16.15-gke.7400 10.0.18363.1016 (Windows Server versión 1909 Core) 10.0.17763.1397(Windows Server 2019 Core)
1.16.15-gke.7800+ 10.0.18363.1198 (Windows Server versión 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)

1.17

Versión de GKE Versión de SAC Versión de LTSC
1.17.9-gke.1504 - 1.17.12-gke.500 10.0.18363.900 (Windows Server Core versión 1909) 10.0.17763.1282 (Windows Server Core 2019)
1.17.12-gke.1501 10.0.18363.1082 (Windows Server Core versión 1909) 10.0.17763.1457 (Windows Server Core 2019)
1.17.12-gke.1504 - 1.17.13-gke.600 10.0.18363.900 (Windows Server Core versión 1909) 10.0.17763.1282 (Windows Server Core 2019)
1.17.13-gke.1400 - 1.17.14-gke.1600 10.0.18363.1016 (Windows Server versión 1909 Core) 10.0.17763.1397(Windows Server 2019 Core)
1.17.15-gke.300+ 10.0.18363.1198 (Windows Server versión 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)

1.18

Versión de GKE Versión de SAC Versión de LTSC
1.18.6-gke.3503 - 1.18.9-gke.801 10.0.18363.900 (Windows Server Core versión 1909) 10.0.17763.1282 (Windows Server Core 2019)
1.18.9-gke.1501 10.0.18363.1082 (Windows Server Core versión 1909) 10.0.17763.1457 (Windows Server Core 2019)
1.18.9-gke.2501 - 1.18.10-gke.601 10.0.18363.900 (Windows Server Core versión 1909) 10.0.17763.1282 (Windows Server Core 2019)
1.18.10-gke.1500 - 1.18.12-gke.1700 (no incluye: 1.18.12-gke.1201) 10.0.18363.1016 (Windows Server versión 1909 Core) 10.0.17763.1397(Windows Server 2019 Core)
1.18.12-gke.1201 10.0.18363.1198 (Windows Server versión 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)
1.18.14-gke.1200+ 10.0.18363.1198 (Windows Server versión 1909 Core) 10.0.17763.1577(Windows Server 2019 Core)

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, no cambies el tamaño del grupo de nodos de Linux a cero y asegúrate de que 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-gke.9 o superior. También puedes optar por usar la marca --release-channel para seleccionar un canal de versiones.
  • CHANNEL es el canal de versiones a fin de 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 si no se especifican las siguientes marcas: --cluster-version, --release-channel, --no-enable-autoupgrade y --no-enable-autorepair.

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

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: Ya sea WINDOWS_LTSC o WINDOWS_SAC. Para obtener más información sobre estas imágenes de nodo, consulta la sección Elige 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.

Console

  1. Ve al menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú 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 principal, 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 Canal semianual de Windows o Canal de servicio a largo plazo de Windows. Para obtener más información sobre estas imágenes de nodo, consulta 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_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_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: Ya sea WINDOWS_LTSC o WINDOWS_SAC. Para obtener más información sobre estas imágenes de nodo, consulta la sección Elige 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 (principal).

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

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.

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

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.

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. Sigue el instructivo que se muestra en la página Configura Active Directory para que las VM se unan automáticamente a un dominio a fin de configurar Active Directory y un proyecto de Google, de modo que los nodos de Windows Server en tu clúster de Windows de GKE puedan unirse automáticamente a un dominio de Active Directory.

  2. Crea un clúster. Por el momento, los nodos protegidos no son compatibles con gMSA.

    gcloud container clusters create CLUSTER_NAME \
    --enable-ip-alias \
    --num-nodes=NUMBER_OF_NODES \
     --no-enable-shielded-nodes \
    --cluster-version=VERSION

    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 especifica 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.
    • --no-enable-shielded-nodes inhabilita los nodos protegidos.
    • VERSION debe ser 1.17.14-gke.1200 o versiones posteriores, o 1.18.9-gke.100 o versiones posteriores. También puedes usar la marca --release-channel para seleccionar un canal de versiones.

  3. Configura variables.

    export DOMAIN_PROJECT_ID=PROJECT_ID
export SERVERLESS_REGION=REGION
export REGISTER_URL=https://$SERVERLESS_REGION-$DOMAIN_PROJECT_ID.cloudfunctions.net/register-computer

    Reemplaza lo siguiente:

  4. Inicia un grupo de nodos de Windows Server pasando el scriptlet especializado que hace que el nodo se una al dominio

     gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --image-type=IMAGE_NAME \
    --no-enable-autoupgrade \
    --machine-type=MACHINE_TYPE_NAME \
    "--metadata=sysprep-specialize-script-ps1=iex((New-Object System.Net.WebClient).DownloadString('$REGISTER_URL'))"

    Reemplaza lo siguiente:

    • NODE_POOL_NAME es el nombre que eliges para el grupo de nodos de Windows Server.
    • CLUSTER_NAME: El nombre de tu clúster.
    • IMAGE_NAME: Ya sea WINDOWS_LTSC o WINDOWS_SAC. Para obtener más información sobre estas imágenes de nodo, consulta la sección Elige tu imagen de nodo de Windows Server.
    • MACHINE_TYPE_NAME es 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.

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

    $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 es el nombre que eliges para el clúster.
    • GMSA_NAME es el nombre que eliges para la gMSA nueva.
    • DNS_HOST_NAME es el FQDN (nombre de dominio completamente calificado) de la cuenta de servicio creada. Por ejemplo, si gmsaName es webapp01 y el dominio es example.com, entonces dnsHostName es webapp01.example.com.

  6. Configura gMSA según las instrucciones mencionadas en 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 Google Cloud Console.

gcloud

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

Console

Para borrar un grupo de nodos de Windows Server mediante Cloud Console, sigue estos pasos:

  1. Ve al menú de Google Kubernetes Engine en Cloud Console.

    Ir al menú 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, algunas funciones de GKE no son compatibles.

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

Para los grupos de nodos de Windows Server, no se admiten las siguientes funciones:

Soluciona problemas

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

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

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 `
"${name}.*(C:.*kubelet\.exe.*)\r"

      PS C:\> $kubelet_cmd = $Matches[1]

    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=15m

    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

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 conexión 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 sean 1460 o menos. Si deseas obtener información sobre cómo configurar la MTU, consulta problemas conocidos de los contenedores de Windows.

¿Qué sigue?