Crear 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 ejecuten Microsoft Windows Server. Con este clúster, puedes usar contenedores de Windows Server. Actualmente, no se admiten contenedores de Microsoft Hyper-V. 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 normal. Los nodos de Windows Server necesitan recursos adicionales para ejecutar el sistema operativo Windows y los componentes de Windows Server que no se pueden ejecutar en contenedores. Como los nodos de Windows Server requieren más recursos, los recursos asignables son inferiores a los que tendrías con nodos de Linux.

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

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

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

  1. Elige la imagen del nodo de Windows Server.
  2. Actualiza y configura gcloud.
  3. Crea un clúster y grupos de nodos.
  4. Obtener las credenciales de kubectl.
  5. Espera a que se inicialice el clúster.

Configurar cuentas de servicio de IAM para GKE

GKE usa cuentas de servicio de gestión de identidades y accesos que están asociadas a tus nodos para ejecutar tareas del sistema, como el registro y la monitorización. Como mínimo, estas cuentas de servicio de nodo deben tener el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como cuenta de servicio del nodo.

Para asignar el rol roles/container.defaultNodeServiceAccount a la cuenta de servicio predeterminada de Compute Engine, sigue estos pasos:

consola

  1. Ve a la página Bienvenida:

    Ir a Bienvenida

  2. En el campo Número de proyecto, haz clic en Copiar en el portapapeles.
  3. Ve a la página Gestión de identidades y accesos:

    Ir a IAM

  4. Haz clic en Conceder acceso.
  5. En el campo Nuevos principales, especifique el siguiente valor: 
    PROJECT_NUMBER-compute@developer.gserviceaccount.com
     Sustituye PROJECT_NUMBER por el número de proyecto que has copiado.
  6. En el menú Seleccionar un rol, elige el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine.
  7. Haz clic en Guardar.

gcloud

  1. Busca tu Google Cloud número de proyecto: 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Sustituye PROJECT_ID por el ID del proyecto.

    El resultado debería ser similar al siguiente:

    12345678901
  2. Asigna el rol roles/container.defaultNodeServiceAccount a la cuenta de servicio predeterminada de Compute Engine: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Sustituye PROJECT_NUMBER por el número de proyecto del paso anterior.

Elegir la imagen de nodo de Windows Server

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

Ten en cuenta lo siguiente al elegir la imagen de tu nodo:

  • Horario de asistencia:
    • Los plazos de asistencia de una imagen de nodo de Windows Server están sujetos a los plazos de asistencia proporcionados por Microsoft, tal como se describe en la política de asistencia de imágenes de SO. Para consultar la fecha de finalización del servicio de asistencia de las imágenes de nodo de Windows de GKE, usa el comando gcloud container get-server-config, tal como se describe en la sección Asignación de versiones de GKE y Windows.
    • Microsoft solo admite las versiones de SAC durante 18 meses después de su lanzamiento inicial. Si eliges SAC como tipo de imagen para tu grupo de nodos, pero no actualizas tu grupo de nodos a versiones de GKE más recientes que tengan como objetivo versiones de SAC más recientes, no podrás crear nodos en tu grupo de nodos cuando finalice el ciclo de vida de asistencia de la versión de SAC. Consulta más información sobre la compatibilidad de Google con el sistema operativo Windows Server. Te recomendamos que uses LTSC por su ciclo de vida de asistencia más largo.
    • No elijas SAC si registras tu clúster de GKE en el canal de lanzamiento estable. Como 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 siga disponible.
  • Compatibilidad y complejidad de las versiones:
    • Elige SAC solo si puedes actualizar tu grupo de nodos y los contenedores que se ejecutan en él con regularidad. GKE actualiza periódicamente la versión de SAC que se usa en los grupos de nodos de Windows en las nuevas versiones de GKE, por lo que, si eliges SAC para el tipo de imagen de tu grupo de nodos, tendrás que recompilar tus contenedores con más frecuencia.
    • Si no sabes qué tipo de imagen de Windows Server usar, te recomendamos que elijas Windows Server LTSC para evitar problemas de incompatibilidad de versiones al actualizar tu grupo de nodos. Para obtener más información, consulta Canales de mantenimiento de Windows Server: LTSC y SAC en la documentación de Microsoft.
    • Puedes usar Windows Server Core y Nano Server como imagen base para tus contenedores.
    • Los contenedores de Windows Server tienen requisitos de compatibilidad de versiones importantes:
      • Los contenedores de Windows Server creados para LTSC no se ejecutan en nodos SAC y viceversa.
      • Los contenedores de Windows Server creados para una versión específica de LTSC o SAC no se ejecutan en otras versiones de LTSC o SAC sin que se vuelvan a compilar para la otra versión.
    • Crear tus imágenes de contenedor de Windows Server como imágenes de varios arcos que puedan dirigirse a varias versiones de Windows Server puede ayudarte a gestionar esta complejidad de versiones.
  • Nuevas funciones:
    • Las nuevas funciones de Windows Server suelen introducirse primero en las versiones de SAC. Por este motivo, es posible que las nuevas funciones de GKE Windows se introduzcan primero en los grupos de nodos de SAC.
    • Considera la opción de SAC si dependes de funciones que aún no están disponibles en la versión LTSC.

  • Entorno de ejecución del contenedor:

    • En el caso de las imágenes de nodo de Windows Server LTSC y SAC, el tiempo de ejecución del contenedor puede ser Docker o containerd. En el caso de la versión de nodo de GKE 1.21.1-gke.2200 y posteriores, te recomendamos que uses el tiempo de ejecución de containerd. Para obtener más información, consulta Imágenes de nodos.

Actualizar y configurar gcloud

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Crear 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 otro de Linux. No puedes crear un clúster usando solo un grupo de nodos de Windows Server. El grupo de nodos de Linux es necesario para ejecutar complementos de clúster críticos.

Debido a su importancia, te recomendamos que actives el autoescalado para asegurarte de que tu grupo de nodos de Linux tenga capacidad suficiente para ejecutar complementos de clúster.

gcloud

Crea un clúster con los siguientes campos:

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

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre que elijas para tu clúster.
  • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.
  • --enable-ip-alias activa alias IP. Es obligatorio indicar una IP de alias para los nodos de Windows Server. Para obtener más información sobre sus ventajas, consulta Información sobre el enrutamiento de contenedores nativo con IPs de alias.
  • NUMBER_OF_NODES: número de nodos Linux que creas. Debes proporcionar suficientes recursos de computación para ejecutar los complementos del clúster. Este campo es opcional y, si se omite, se usará el valor predeterminado de 3.
  • VERSION_NUMBER: la versión específica del clúster que quieres usar, que debe ser 1.16.8-gke.9 o una versión posterior. Si no especificas ningún canal de lanzamiento, GKE registrará tu clúster en el canal de lanzamiento más estable en el que esté disponible esa versión.
  • CHANNEL: el canal de lanzamiento en el que se registrará el clúster, que puede ser rapid, regular, stable o None. De forma predeterminada, el clúster se registra en el canal de lanzamiento 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 de clúster y no quieres que tu clúster se registre en un canal de lanzamiento.

Te recomendamos que especifiques una cuenta de servicio de IAM con los privilegios mínimos que puedan usar tus nodos en lugar de la cuenta de servicio predeterminada de Compute Engine. Para obtener información sobre cómo crear una cuenta de servicio con el número mínimo de privilegios necesarios, consulta Usar una cuenta de servicio con el número mínimo de privilegios necesarios.

Para especificar una cuenta de servicio personalizada en la CLI de gcloud, añade la siguiente marca al comando:

--service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Sustituye SERVICE_ACCOUNT_NAME por el nombre de tu cuenta de servicio con el número mínimo de privilegios necesarios.

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

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

Haz los cambios siguientes:

  • NODE_POOL_NAME: el nombre que elijas para tu grupo de nodos de Windows Server.
  • CLUSTER_NAME: el nombre del clúster que has creado arriba.

  • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

  • IMAGE_NAME: puedes especificar uno de los siguientes valores:

    Para obtener más información sobre estas imágenes de nodos, consulta la sección Elegir una imagen de nodo de Windows.

  • --no-enable-autoupgrade inhabilita la actualización automática de nodos. Consulta el artículo Actualizar grupos de nodos de Windows Server antes de habilitar esta opción.

  • 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. No se admiten los tipos de máquinas f1-micro y g1-small. Cada tipo de máquina se factura de forma diferente. Para obtener más información, consulta la hoja de precios de los tipos de máquina.

  • WINDOWS_OS_VERSION: define la versión del SO Windows que se va a usar para el tipo de imagen WINDOWS_LTSC_CONTAINERD. Esta es una marca opcional. Si no se especifica, se usará la versión predeterminada del SO, que es LTSC2019. Asigna el valor ltsc2022 para crear un grupo de nodos de Windows Server 2022. Asigna el valor 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 \
    --location=us-central1 \
    --image-type=WINDOWS_LTSC_CONTAINERD \
    --windows-os-version=ltsc2022

En el siguiente ejemplo se muestra cómo puedes actualizar un grupo de nodos de Windows para que use la imagen del SO Windows Server 2022:

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

Consola

  1. En la Google Cloud consola, ve a la página Crear un clúster de Kubernetes.

    Ir a Crear un clúster de Kubernetes

  2. En la sección Información básica de los clústeres, haz lo siguiente:
    1. Introduce el nombre del clúster.
    2. En Tipo de ubicación, selecciona la región o zona que quieras para tu clúster.
    3. En Versión del plano de control, selecciona un canal de lanzamiento o elige especificar una versión estática. La versión estática debe ser 1.16.8-gke.9 o superior.
  3. En el panel de navegación, vaya a Grupos de nodos y haga clic en default-pool para crear su grupo de nodos de Linux. Al configurar este grupo de nodos, debes proporcionar suficientes recursos de computación para ejecutar los complementos del clúster. También debes tener cuota de recursos disponible para los nodos y sus recursos (como las rutas de cortafuegos).
  4. En la parte superior de la página, haz clic en Añadir grupo de nodos para crear tu grupo de nodos de Windows Server.
  5. En la sección Detalles del grupo de nodos, haz lo siguiente:
    1. Introduce un nombre para el grupo de nodos.
    2. En el caso de los nodos de versión estática, elige la versión del nodo.
    3. Introduce el Número de nodos que quieras crear en el grupo de nodos.

  6. En el panel de navegación, ve a Grupos de nodos y haz clic en Nodos.

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

      • Canal de mantenimiento a largo plazo de Windows con Docker
      • Canal de mantenimiento a largo plazo de Windows con containerd
      • Canal semestral de Windows con Docker
      • Canal semianual de Windows con containerd

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

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

  7. En el panel de navegación, selecciona el nombre de tu grupo de nodos de Windows Server. De esta forma, volverás a la página Detalles del grupo de nodos.

    1. En Automatización, desmarca la casilla Habilitar actualización automática de nodos. Consulta la sección Actualizar grupos de nodos de Windows Server antes de habilitar la actualización automática.

  8. En el panel de navegación, ve a Clúster y selecciona Redes.

    1. En Opciones de red avanzadas, asegúrate de que la opción Habilitar el enrutamiento del tráfico nativo de VPC (usa IP de alias) esté seleccionada. Es obligatorio indicar una IP de alias para los nodos de Windows Server. Para obtener más información sobre sus ventajas, consulta Información sobre el enrutamiento de contenedores nativo con IPs de alias.

  9. Haz clic en Crear.

Terraform

Para crear un clúster estándar de GKE y un grupo de nodos de Windows Server con Terraform, consulta el siguiente ejemplo:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-west1"

  initial_node_count = 1
}

resource "google_container_node_pool" "default" {
  name     = "windows-node-pool"
  cluster  = google_container_cluster.default.name
  location = google_container_cluster.default.location

  node_config {
    image_type = "WINDOWS_LTSC_CONTAINERD"
  }
}

En este ejemplo se usa Windows Server LTSC con containerd. Este es el tipo de imagen de los sistemas operativos Windows Server 2022 y Windows Server 2019. Para obtener más información sobre las imágenes de nodos, consulta Elegir una imagen de nodo de Windows.

Para obtener más información sobre el uso de Terraform, consulta Compatibilidad de Terraform con GKE.

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

Obtener credenciales de kubectl

Usa el comando get-credentials para habilitar kubectl y que funcione con el clúster que has creado.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

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

Esperar a que se inicialice el clúster

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

Para asegurarte de que se ha creado 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 otro de Windows), puedes desplegar una aplicación de Windows.

Asignación de versiones de GKE y Windows

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

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

gcloud beta container get-server-config

La asignación de versiones se devuelve en el campo windowsVersionMaps de la respuesta. Para filtrar la respuesta y ver la asignación de versiones de GKE específicas de tu clúster, sigue estos pasos en un shell de Linux o en Cloud Shell.

  1. Define las siguientes variables:

    CLUSTER_NAME=CLUSTER_NAME \
NODE_POOL_NAME=NODE_POOL_NAME \
CONTROL_PLANE_LOCATION=CONTROL_PLANE_LOCATION

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster.
    • NODE_POOL_NAME: nombre del grupo de nodos de Windows Server.
    • CONTROL_PLANE_LOCATION: la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

  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 \
--location=$CONTROL_PLANE_LOCATION \
--format="value(version)"`

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

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

    El resultado debería ser similar al siguiente:

    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 del 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 debería ser similar al siguiente:

    10.0.18363.1198

Actualizar grupos de nodos de Windows Server

Los requisitos de compatibilidad de la versión del contenedor de Windows Server implican que es posible que tengas que volver a compilar tus imágenes de contenedor para que coincidan con la versión de Windows Server de una nueva versión de GKE antes de actualizar tus grupos de nodos.

Para asegurarte de que tus imágenes de contenedor sigan siendo compatibles con tus nodos, te recomendamos que consultes la asignación de versiones y que crees tus imágenes de contenedor de Windows Server como imágenes de varios arcos que puedan usar varias versiones de Windows Server. Después, puedes actualizar tus despliegues de contenedores para que usen las imágenes de varias arquitecturas que funcionarán tanto en la versión actual como en la siguiente de GKE antes de invocar manualmente una actualización del grupo de nodos de GKE. Las actualizaciones manuales de grupos de nodos deben realizarse periódicamente, ya que los nodos no pueden tener una versión inferior a la del plano de control en más de dos versiones secundarias.

Te recomendamos que te suscribas a las notificaciones de actualización mediante Pub/Sub para recibir de forma proactiva información sobre las nuevas versiones de GKE y las versiones del SO Windows que utilizan.

Te recomendamos que habilites las actualizaciones automáticas de nodos solo si creas continuamente imágenes de contenedor de Windows Server de varias arquitecturas que estén orientadas a las versiones más recientes de Windows Server, sobre todo si usas Windows Server SAC como tipo de imagen de nodo. Es menos probable que las actualizaciones automáticas de nodos provoquen problemas con el tipo de imagen de nodo LTSC de Windows Server, pero sigue habiendo riesgo de que se produzcan problemas de incompatibilidad de versiones.

Actualizaciones de Windows

Las actualizaciones de Windows están inhabilitadas en los nodos de Windows Server. Las actualizaciones automáticas pueden provocar que los nodos se reinicien en momentos impredecibles, y las actualizaciones de Windows que se instalen después de que se inicie un nodo se perderán cuando GKE vuelva a crear el nodo. GKE pone a disposición las actualizaciones de Windows actualizando periódicamente las imágenes de nodos de Windows Server que se usan en las nuevas versiones de GKE. Puede haber un retraso entre el momento en que Microsoft lanza las actualizaciones de Windows y el momento en que están disponibles en GKE. Cuando se publican actualizaciones de seguridad críticas, GKE actualiza las imágenes de nodo de Windows Server lo antes posible.

Controlar cómo se comunican los pods y los servicios de Windows

Puedes controlar cómo se comunican los pods y los servicios de Windows mediante políticas de red.

Puedes tener un contenedor de Windows Server en clústeres que tengan habilitada la política de red en GKE 1.22.2 y versiones posteriores. Esta función está disponible para los 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 actualizando tus grupos de nodos y tu plano de control a la versión 1.22.2 de GKE o a una posterior. Esta opción solo está disponible si has creado el clúster con la marca --enable-dataplane-v2.

Después de habilitar la política de red, se activarán todas las políticas configuradas anteriormente, incluidas las 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. Para obtener más información, consulta la sección Limitaciones.

Ver y consultar registros

El registro se habilita automáticamente 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 la monitorización de Kubernetes Engine.

A continuación, se muestra un ejemplo de 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"

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

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

Crear imágenes de varias arquitecturas

Puedes crear las imágenes de varias arquitecturas manualmente o usar un compilador de Cloud Build. Para obtener instrucciones, consulta el artículo sobre cómo crear imágenes de varios arcos de Windows.

Usar gMSA

En los pasos siguientes se muestra cómo usar una cuenta de servicio gestionada por grupos (gMSA) con tus grupos de nodos de Windows Server.

  1. Configura los nodos de Windows Server de tu clúster para que se unan automáticamente a tu dominio de AD. Para obtener instrucciones, consulta Configurar nodos de Windows Server para que se unan automáticamente a un dominio de Active Directory.

  2. Crea una gMSA y concédele acceso al grupo de seguridad que se crea automáticamente con el servicio de unión al dominio. Este paso debe realizarse en un equipo 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

    Haz los cambios siguientes:

    • 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 elijas para la nueva gMSA.
    • DNS_HOST_NAME: el nombre de dominio completo (FQDN) de la cuenta de servicio que has creado. Por ejemplo, si GMSA_NAME es webapp01 y el dominio es example.com, DNS_HOST_NAME es webapp01.example.com.

  3. Configura tu gMSA siguiendo las instrucciones del tutorial Configurar gMSA para pods y contenedores de Windows.

Eliminar grupos de nodos de Windows Server

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

gcloud

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

Consola

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

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

    Ir a Google Kubernetes Engine

  2. Junto al clúster que quieras editar, haz clic en Acciones y, a continuación, en Editar.

  3. Selecciona la pestaña Nodos.

  4. En la sección Grupos de nodos, haga clic en Eliminar junto al grupo de nodos que quiera eliminar.

  5. Cuando se te solicite confirmación, vuelve a hacer clic en Eliminar.

Limitaciones

Hay algunas funciones de Kubernetes que aún no se admiten en los contenedores de Windows Server. Además, algunas funciones son específicas de Linux y no funcionan en Windows. Para ver la lista completa de funciones de Kubernetes compatibles y no compatibles, consulta la documentación de Kubernetes.

Además de las funciones de Kubernetes no admitidas, hay algunas funciones de GKE que no se admiten.

En los clústeres de GKE, las siguientes funciones no se admiten con grupos de nodos de Windows Server:

La política de tráfico externo local en el grupo de nodos de Windows solo se admite con la versión v1.23.4-gke.400 o posterior de GKE.

Es posible que otros productos de Google Cloud que quieras 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.

Solución de problemas

Consulta la documentación de Kubernetes para obtener información general sobre cómo depurar pods y servicios.

Problemas de nodos de containerd

Para ver los problemas conocidos al usar una imagen de nodo de Containerd, consulta Problemas conocidos.

Los pods de Windows no se inician

Si hay una versión incompatible 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 de tu grupo de nodos de Windows es 1.16.8-gke.8 o posterior, consulta la documentación de Microsoft sobre el problema de incompatibilidad de contenedores de Windows Server de febrero del 2020 y crea tus imágenes de contenedor con imágenes base de Windows que incluyan las actualizaciones de Windows de marzo del 2020. Es posible que las imágenes de contenedor creadas en imágenes de Windows base anteriores no se ejecuten en estos nodos de Windows y que provoquen un error en el 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 provocar que Kubelet agote el tiempo de espera y falle al descargar y extraer las capas del contenedor.

Es posible que te hayas encontrado con este problema si ves los mensajes de error "Failed to pull image" (No se ha podido extraer la imagen) o "Image pull context cancelled" (Se ha cancelado el contexto de extracción de la imagen) o el estado ErrImagePull de tus pods.

Si la extracción de imágenes se produce 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 total de extracción.

Prueba las siguientes opciones para extraer correctamente tus contenedores de Windows Server:

  • Divide las capas de la aplicación de la imagen de contenedor de Windows Server en capas más pequeñas que se puedan extraer y extraer más rápidamente. Esto puede hacer que el almacenamiento en caché de capas de Docker sea más eficaz y que sea más probable que se completen los reintentos de extracción de imágenes. Para obtener más información sobre las capas, consulta el artículo de Docker Controladores de almacenamiento.

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

  • Define la image-pull-progress-deadline marca del servicio kubelet para aumentar el tiempo de espera de la extracción de imágenes de contenedor.

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

    1. Obtén la línea de comandos del servicio Kubelet del 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. Define una nueva línea de comandos para el servicio Kubelet con una marca adicional para 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 ha realizado correctamente.

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

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

      PS C:\> Restart-Service kubelet

    5. Confirma que el servicio kubelet se ha reiniciado correctamente.

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

La familia de imágenes ha llegado al final de su vida útil

Al crear un grupo de nodos con una imagen de Windows, se produce 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 solucionar este error, elige una imagen de Windows que esté disponible y sea compatible. Para consultar la fecha de finalización del periodo de asistencia de las imágenes de nodos de Windows de GKE, utiliza el comando gcloud container get-server-config, tal como se describe en la sección Asignación de versiones de GKE y Windows.

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

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

Para solucionar este problema, reduce el número de nodos que estás creando. Puedes aumentar el número de nodos más adelante.

Los nodos de Windows se convierten en NotReady y muestran el error "PLEG is not healthy"

Se trata de un problema conocido de Kubernetes que se produce cuando se inician varios pods muy rápidamente en un solo nodo de Windows. Para recuperarte de esta situación, reinicia el nodo de Windows Server. Una solución alternativa recomendada para evitar este problema es limitar la frecuencia con la que se crean los pods de Windows a un pod cada 30 segundos.

TerminationGracePeriod incoherente

El tiempo de espera del sistema Windows para el contenedor puede ser diferente del periodo de gracia que configure. Esta diferencia puede provocar que Windows fuerce la finalización del contenedor antes de que termine el periodo de gracia transferido al tiempo de ejecución.

Puedes modificar el tiempo de espera de Windows editando las claves de registro locales del contenedor en el momento de compilar la imagen. Si modificas el tiempo de espera de Windows, es posible que también tengas que ajustar TerminationGracePeriodSeconds para que coincida.

Problemas de conectividad de red

Si tienes problemas de conectividad de red desde tus contenedores de Windows Server, puede deberse a que la red de contenedores de Windows Server suele asumir un MTU de red de 1500, que es incompatible con el MTU de Google Cloud, que es 1460.

Comprueba que el MTU de la interfaz de red del contenedor y el de las interfaces de red del propio nodo de Windows Server tengan el mismo valor (es decir, 1460 o menos). Para obtener información sobre cómo definir la MTU, consulta los problemas conocidos de los contenedores de Windows.

Problemas de inicio de nodos

Si los nodos no se inician en el clúster o no se unen a él correctamente, revisa la información de diagnóstico proporcionada en la salida del puerto serie del nodo.

Ejecuta el siguiente comando para ver la salida del puerto serie:

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

Haz los cambios siguientes:

Servicios a los que no se puede acceder de forma intermitente en nodos de Windows con un clúster que ejecuta la versión 1.24 o una anterior

Al iniciar nodos de Windows en clústeres de Kubernetes con un gran número de reglas de balanceador de carga de servicio de red de host, se produce un retraso en el procesamiento de las reglas. Los servicios no se pueden alcanzar de forma intermitente durante el retraso, que dura unos 30 segundos por regla, y el retraso total puede ser significativo si hay suficientes reglas. Para obtener más información, consulta el problema original en GitHub.

En los clústeres de GKE que ejecuten la versión 1.24 o una anterior, con nodos de Windows que hayan tenido un evento que haya reiniciado kube-proxy (por ejemplo, inicio de nodo, actualización de nodo o reinicio manual), no se podrá acceder a ningún servicio al que llegue un pod que se ejecute en ese nodo hasta que el componente sincronice todas las reglas.

En los clústeres de GKE que ejecutan la versión 1.25 o posterior, este comportamiento se ha mejorado considerablemente. Para obtener más información sobre esta mejora, consulta la solicitud de incorporación de cambios en GitHub. Si tienes este problema, te recomendamos que actualices el plano de control de tu clúster a la versión 1.25 o posterior.

Siguientes pasos