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:
- Actualiza y configura
gcloud
. - Elige tu imagen de nodo.
- Crea un clúster y grupos de nodos.
- Obtén credenciales
kubectl
. - Espera la inicialización del clúster.
Actualiza y configura gcloud
Antes de comenzar, asegúrate de haber realizado las siguientes tareas:
- Asegúrate de que habilitaste la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Asegúrate de que instalaste el SDK de Cloud.
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.
-
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
- Sigue las instrucciones a fin de autorizar a
gcloud
para que use tu cuenta de Google Cloud. - Crea una configuración nueva o selecciona una existente.
- Elige un proyecto de Google Cloud.
- 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
- Asegúrate de tener el permiso correcto para crear clústeres. Como mínimo, debes ser un administrador de clústeres de Kubernetes Engine.
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 de3
.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 derapid
,regular
,stable
oNone
. De forma predeterminada, el clúster se inscribe en el canal de versionesregular
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 seaWINDOWS_LTSC
oWINDOWS_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áquinaf1-micro
yg1-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
Ve al menú de Google Kubernetes Engine en Cloud Console.
Haz clic en add_box Crear.
En la sección Aspectos básicos del clúster, completa lo siguiente:
- Ingresa el nombre de tu clúster.
- En Tipo de ubicación, selecciona la región o zona deseada para el clúster.
- 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.
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).
En la parte superior de la página, haz clic en add_box Agregar grupo de nodos para crear el grupo de nodos de Windows Server.
En la sección Detalles del grupo de nodos, completa lo siguiente:
- Ingresa un Nombre para el grupo de nodos.
- Para los nodos de la versión estática, elige la Versión de nodo.
- Ingresa la Cantidad de nodos que se crearán en el grupo.
En el panel de navegación, en Grupos de nodos, haz clic en Nodos.
- 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.
- 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áquinaf1-micro
yg1-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.
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.
- 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.
En el panel de navegación, en Clúster, selecciona Herramientas de redes.
- 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.
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 seaWINDOWS_LTSC
oWINDOWS_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áquinaf1-micro
yg1-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.
- 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.
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.
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:
PROJECT_ID
es el ID del proyecto de tu dominio.REGION
es la región en la que se implementará la función de Cloud Functions. Elige una región que admita Cloud Functions y Acceso a VPC sin servidores. La región no tiene que ser la misma que aquella en la que planeas implementar instancias de VM.
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 seaWINDOWS_LTSC
oWINDOWS_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áquinaf1-micro
yg1-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.
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, sigmsaName
eswebapp01
y el dominio esexample.com
, entoncesdnsHostName
eswebapp01.example.com
.
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:
Ve al menú de Google Kubernetes Engine en Cloud Console.
Junto al clúster que deseas editar, haz clic en more_vert Acciones y, luego, en edit Editar.
Selecciona la pestaña Nodos.
En la sección Grupos de nodos, haz clic en deleteBorrar junto al grupo de nodos que quieres borrar.
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:
- Cloud TPU (
--enable-tpu
) - Ingress con grupos de extremos de red
- Visibilidad dentro de los nodos (
--enable-intra-node-visibility
) - Agente de enmascaramiento de IP
- Clúster Alfa de Kubernetes (
--enable-kubernetes-alpha
) - Política de red (
--enable-network-policy
) - NodeLocal DNSCache
- Uso privado de direcciones IP de clase E
- Uso privado de direcciones IP públicas
- Workload Identity
- Dataplane V2
- Registro de políticas de red
Para los grupos de nodos de Windows Server, no se admiten las siguientes funciones:
- GPU (
--accelerator
) - Interrumpible (
--preemptible
)
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 serviciokubelet
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.
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]
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
Confirma que el cambio se realizó de forma correcta.
PS C:\> reg query ${regkey} /v ${name}
Reinicia el servicio
kubelet
para que se aplique la marca nueva.PS C:\> Restart-Service kubelet
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?
- Obtén más información sobre cómo implementar una aplicación de Windows.
- Lee la introducción breve sobre los contenedores de Windows de Microsoft.
- Lee los lineamientos de Microsoft para elegir las imágenes base del contenedor.
- Lee acerca de la compatibilidad de versiones de contenedores de Microsoft en Windows.