Desplegar una aplicación de Windows Server

Estándar

En esta página, aprenderás a desplegar una aplicación de Windows Server sin estado en un clúster de Google Kubernetes Engine (GKE). También puedes consultar cómo desplegar una aplicación de Windows con reconocimiento del estado.

Antes de empezar

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

• Habilita la API de Artifact Registry y la API de Google Kubernetes Engine.
Habilitar APIs
• 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.
  Nota: Si ya tienes instalada la CLI gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Desplegar una aplicación de Windows Server en un clúster con nodos públicos

Para desplegar una aplicación de Windows Server en un clúster de GKE con solo nodos públicos, debes realizar las siguientes tareas:

1. Crea un clúster con nodos públicos.
2. Crea un archivo de manifiesto de Deployment.
3. Crea y expón el Deployment.
4. Comprueba que el pod se esté ejecutando.

Crear un clúster con nodos públicos

Si ya tienes un clúster de GKE que usa grupos de nodos de Windows Server, ve al siguiente paso. De lo contrario, crea un clúster mediante grupos de nodos de Windows Server. Para aprovisionar nodos con direcciones IP externas (nodos públicos), usa la marca --no-enable-private-nodes al crear el clúster.

Crear un archivo de manifiesto de Deployment

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

Esta marca asegura que el programador de GKE no intente ejecutar contenedores de Linux en nodos de Windows Server. Para programar contenedores de Windows Server en nodos de Windows Server, tu archivo de manifiesto debe incluir este selector de nodos:

nodeSelector:
 kubernetes.io/os: windows

Un webhook de admisión que se ejecuta en el clúster comprueba si hay cargas de trabajo nuevas que incluyan este selector de nodos de Windows y, si lo encuentra, aplica la siguiente tolerancia a la carga de trabajo, lo que le permite ejecutarse en los nodos de Windows Server contaminados:

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

En algunos casos, es posible que tengas que incluir esta tolerancia explícitamente en tu archivo de manifiesto. Por ejemplo, si vas a implementar un DaemonSet con una imagen de contenedor multiarquitectura para que se ejecute en todos los nodos de Linux y Windows Server del clúster, tu archivo de manifiesto no incluirá el selector de nodos de Windows. Debes incluir explícitamente la tolerancia para el taint de Windows.

Archivo de manifiesto de ejemplo

En el siguiente ejemplo de archivo de implementación (iis.yaml) se implementa la imagen de IIS de Microsoft en un solo pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: iis
  template:
    metadata:
      labels:
        app: iis
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: iis-server
        image: mcr.microsoft.com/windows/servercore/iis
        ports:
        - containerPort: 80

Este archivo es para un clúster en el que todas las cargas de trabajo usan el mismo tipo y versión de imagen de nodo de Windows Server. Para obtener información sobre cómo trabajar con imágenes de nodos mixtos, consulta la sección Usar imágenes de nodos mixtos.

Crear y exponer el Deployment

Crea y expón el archivo de Deployment que has creado en el paso anterior como un servicio de Kubernetes con un Deployment de balanceador de carga externo.

1. Para crear el recurso Deployment, ejecuta el siguiente comando:

   kubectl apply -f iis.yaml
   

2. Para exponer el Deployment como un balanceador de carga externo, ejecuta el siguiente comando:

   kubectl expose deployment iis \
       --type=LoadBalancer \
       --name=iis
   

Verificar que el pod se está ejecutando

Asegúrate de que el pod funciona validándolo.

1. Comprueba el estado del Pod con kubectl:

   kubectl get pods
   

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

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

3. Obtén el estado del servicio y espera hasta que se rellene el campo EXTERNAL-IP:

   kubectl get service iis
   

   Deberías ver este resultado:

   NAME   TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)        AGE
   iis    LoadBalancer   10.44.2.112   external-ip    80:32233/TCP   17s
   

Ahora puedes usar tu navegador para abrir http://EXTERNAL_IP para ver la página web de IIS.

Desplegar una aplicación de Windows Server en un clúster con nodos privados

En esta sección se explica cómo desplegar una aplicación de contenedor de Windows Server en un clúster de GKE que solo tenga nodos privados habilitados.

Las imágenes de contenedor de Windows Server tienen varias capas y Microsoft proporciona las capas base. Las capas base se almacenan como una capa externa en lugar de insertarse en la imagen como las capas de imagen de Docker de Linux. Cuando se extrae por primera vez una imagen de contenedor de Windows Server, las capas base normalmente se deben descargar de los servidores de Microsoft. Como los nodos privados no tienen conectividad a Internet, las capas del contenedor base de Windows Server no se pueden extraer directamente de los servidores de Microsoft.

Para usar clústeres con nodos privados habilitados, puedes configurar el daemon de Docker para permitir que se inserten capas no distribuibles en registros privados. Para obtener más información, consulta Allow push of non-distributable artifacts (Permitir el envío de artefactos no distribuibles) en la página de GitHub de Docker.

Para desplegar tu aplicación de Windows Server en un clúster con nodos privados habilitados, sigue estos pasos:

1. Crea un clúster con nodos de Windows Server y habilita los nodos privados.
2. Crea la imagen de Docker de la aplicación de Windows Server.
3. Despliega la aplicación en un clúster con nodos privados habilitados.
4. Comprueba que el pod se esté ejecutando.

Crear un clúster con nodos privados

Sigue las instrucciones que se indican en el artículo Crear un clúster con nodos de Windows Server. Para aprovisionar nodos que solo tengan direcciones IP internas (nodos privados), usa la marca --enable-private-nodes al crear el clúster.

Crear la imagen de Docker de la aplicación Windows Server

1. Para compilar la imagen de Docker, inicia una instancia de Compute Engine con la versión de Windows Server en la que quieras ejecutar los contenedores de tu aplicación, como Windows Server 2019 o Windows Server versión 20H2. Además, asegúrate de que tienes conexión a Internet.

2. En la instancia de Compute Engine, ve a la configuración del daemon de Docker:

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

3. Configura el archivo daemon.json de Docker para permitir que se inserten capas externas en tu registro privado añadiendo estas líneas:

   {
     "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
   }
   

   En este ejemplo, REGISTRY_REGION-docker.pkg.dev hace referencia a Artifact Registry, donde se alojará la imagen.

4. Reinicia el daemon de Docker:

   Restart-Service docker
   

5. Crea un repositorio de Docker en Artifact Registry.

6. Compila y etiqueta la imagen Docker de tu aplicación:

   cd C:\my-app
   

   docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
   

   Este comando indica a Docker que cree la imagen usando el Dockerfile del directorio actual y que la etiquete con un nombre, como us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.

7. Introduce la imagen Docker de la aplicación en el repositorio de Artifact Registry de tu proyecto. El conjunto de configuración allow-nondistributable-artifacts hace que las capas base de Windows se inserten en tu registro privado.

   docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
   

Crear un archivo de manifiesto de Deployment

A continuación, se muestra un ejemplo de archivo de manifiesto de implementación llamado my-app.yaml. La imagen de este ejemplo es la que has subido en el paso anterior (REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      containers:
      - name: my-server
        image: REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2

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

   Sustituye CLUSTER_NAME por el nombre del clúster que has creado.

2. Despliega la aplicación especificada en el archivo my-app.yaml en tu clúster:

   kubectl apply -f my-app.yaml
   

Verificar que el pod se está ejecutando

Lista todos los pods para asegurarte de que la aplicación se está ejecutando correctamente:

kubectl get pods

Debería ver el pod con el estado Running, como en el siguiente resultado:

NAME                     READY   STATUS    RESTARTS   AGE
my-app-c95fc5596-c9zcb   1/1     Running   0          5m

Usar imágenes de nodo mixtas

Los clústeres pueden contener grupos de nodos con varios tipos y versiones de Windows Server. También pueden combinar cargas de trabajo de Windows Server y Linux. En las siguientes secciones se explica cómo configurar tus cargas de trabajo para que usen estos tipos de clústeres.

Usar cargas de trabajo con diferentes tipos de imágenes de nodo de Windows Server

Puedes añadir grupos de nodos a tu clúster con diferentes tipos de imágenes de Windows Server. En un clúster con tipos de Windows Server mixtos, debes asegurarte de que tus contenedores de Windows Server no se programen en un nodo de Windows Server incompatible.

Si tienes un grupo de nodos de Windows Server LTSC y otro de Windows Server SAC, añade la etiqueta de nodo gke-os-distribution a ambas cargas de trabajo.

Incluya el siguiente nodeSelector en el archivo de manifiesto de sus cargas de trabajo de Windows Server LTSC:

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc

Incluye el siguiente nodeSelector en el archivo de manifiesto de tus cargas de trabajo de Windows Server SAC.

Advertencia: Las imágenes del canal semestral (SAC) de Windows Server no se admitirán después del 9 de agosto del 2022, ya que Microsoft dejará de admitir el SAC. Para obtener información sobre el posible impacto y las instrucciones de migración, consulta el artículo Fin del mantenimiento del canal semestral de Windows Server.

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_sac

Si añade esta etiqueta, se asegurará de que sus imágenes de contenedor LTSC no se programen en nodos SAC incompatibles y viceversa.

Usar cargas de trabajo con diferentes versiones del SO Windows Server LTSC

Los nodos de Windows Server admiten imágenes de SO LTSC2022 y LTSC2019. Puedes especificar la versión del SO Windows que quieres usar (LTSC2022) con el siguiente par clave-valor en nodeSelector: cloud.google.com/gke-windows-os-version=2022.

Esta etiqueta de nodo asegura que el programador de GKE elija los nodos de Windows Server correctos para ejecutar cargas de trabajo de LTSC2022 o LTSC2019. Ambos nodos de Windows Server pertenecen al tipo de imagen windows_ltsc_containerd. El valor de la etiqueta del nodo puede ser 2022 o 2019. Si no se especifica la etiqueta del nodo, se pueden usar nodos LTSC2019 o LTSC2022 para programar contenedores. Para programar contenedores de Windows Server solo en nodos de Windows Server LTSC2022, tu archivo de manifiesto debe incluir este selector de nodos:

nodeSelector:
   kubernetes.io/os: windows
   cloud.google.com/gke-os-distribution: windows_ltsc
   cloud.google.com/gke-windows-os-version: 2022

Usar cargas de trabajo con diferentes versiones de Windows Server

Si necesitas ejecutar grupos de nodos de Windows Server con varias versiones diferentes de LTSC o SAC, te recomendamos que crees tus imágenes de contenedor como imágenes de varios arcos que puedan ejecutarse en todas las versiones de Windows Server que se usen en tu clúster. La etiqueta de nodo gke-os-distribution no es suficiente para evitar que tus cargas de trabajo se programen en nodos incompatibles.

Usar cargas de trabajo de Linux y Windows Server en un clúster

Añade el siguiente selector de nodos a tus cargas de trabajo de Linux para asegurarte de que siempre se programen en nodos de Linux:

nodeSelector:
   kubernetes.io/os: linux

De esta forma, se proporciona protección adicional para evitar que las cargas de trabajo de Linux se programen en nodos de Windows Server en caso de que se elimine accidentalmente el NoSchedule taint de los nodos de Windows Server.

Nota: En el caso de los DaemonSets que solo se ejecutan en Linux, este nodeSelector es obligatorio.