Implementa una aplicación de Windows Server

Estándar

En esta página, aprenderás a implementar una aplicación de Windows Server sin estado en un clúster de Google Kubernetes Engine (GKE), que puede ser de alguna de las clases siguientes: pública oprivada. También puedes aprender a implementar una aplicación de Windows con estado.

Antes de comenzar

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

Habilita la API de Artifact Registry y la API de Google Kubernetes Engine.

Habilita las APIs

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Implementa una aplicación de Windows Server en un clúster

Para implementar una aplicación de Windows Server en un clúster público de GKE, deberás realizar las siguientes tareas:

Crea un clúster.
Crea un archivo de manifiesto de Deployment.
Crea y expón el objeto Deployment.
Verificar que el pod se esté ejecutando

Cree un clúster

Si ya tienes un clúster de GKE que usa grupos de nodos de Windows Server, continúa con el paso siguiente. En caso contrario, crea un clúster con los grupos de nodos de Windows Server.

Crea un archivo de manifiesto de Deployment

Los nodos de Windows Server tienen taints con el siguiente par clave-valor: node.kubernetes.io/os=windows:NoSchedule.

Este taint garantiza 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 analiza las cargas de trabajo nuevas en busca de este selector de nodos de Windows y, cuando lo encuentra, aplica la siguiente tolerancia a la carga de trabajo, que le permite ejecutarse en los nodos de Windows Server con taints:

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

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

Archivo de manifiesto de ejemplo

En el siguiente archivo de Deployment (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 la misma versión de imagen de nodo de Windows Server. Si deseas obtener más información sobre cómo trabajar con imágenes de nodo variadas, consulta la sección Usa imágenes de nodo variadas.

Crea y expón el objeto Deployment

Crea y expón el archivo de Deployment que creaste en el paso anterior como un Service de Kubernetes con un Deployment de balanceador de cargas externo.

Para crear un recurso de Deployment, ejecuta el siguiente comando:
```
kubectl apply -f iis.yaml
```
Para exponer Deployment como un balanceador de cargas externo, ejecuta el siguiente comando:
```
kubectl expose deployment iis \
    --type=LoadBalancer \
    --name=iis
```

Verifica que el Pod esté en ejecución.

Valida el pod para asegurarte de que está funcionando.

Comprueba el estado del Pod mediante kubectl:
```
kubectl get pods
```

Espera hasta que el resultado obtenido muestre que el Pod tiene Running como su estado:

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

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

kubectl get service iis

Debería ver el siguiente 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 y ver la página web de IIS.

Implementa una aplicación de Windows Server en un clúster privado

En esta sección, se muestra cómo implementar una aplicación de contenedor de Windows Server en un clúster privado.

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 estar incorporadas con la imagen como las capas de imagen de Docker de Linux. Cuando se extrae una imagen de contenedor de Windows Server por primera vez, lo usual es que las capas base deban descargarse de los servidores de Microsoft. Debido a que los nodos de clúster privado no tienen conectividad a Internet, las capas base del contenedor de Windows Server no se pueden extraer directamente de los servidores de Microsoft.

Para usar clústeres privados, puedes configurar el daemon de Docker a fin de permitir el envío de capas no distribuibles a registros privados. Para obtener más información, consulta Permite el envío de artefactos no distribuibles en la página GitHub de Docker.

Para implementar tu aplicación de Windows Server en un clúster privado, sigue estos pasos:

Crear un clúster privado con nodos de Windows Server
Compilar la imagen de Docker de la aplicación de Windows Server
Implementar la aplicación en un clúster privado
Verificar que el pod se esté ejecutando

Cree un clúster privado

Sigue las instrucciones que se encuentran en Crea un clúster con nodos de Windows Server y Crea un clúster privado para crear un grupo de nodos de Windows y agregarlo a un clúster privado.

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

Para compilar la imagen de Docker, inicia una instancia de Compute Engine con la versión de Windows Server en la que deseas ejecutar los contenedores de tu aplicación, como Windows Server 2019 o Windows 20H2. Además, asegúrate de tener conexión a Internet.
En la instancia de Compute Engine, navega al archivo de configuración del daemon de Docker:
```
cat C:\ProgramData\docker\config\daemon.json
```
Configura el archivo daemon.json de Docker a fin de permitir que las capas externas se envíen a tu registro privado. Para ello, agrega 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.
Reinicia el daemon de Docker:
```
Restart-Service docker
```
Crea un repositorio de Docker en Artifact Registry
Compila y etiqueta la imagen de 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 le indica a Docker que compile la imagen con el Dockerfile en el directorio actual y que la etiquete con un nombre, como us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.
Envía la imagen de Docker de la aplicación al repositorio de Artifact Registry de tu proyecto. El conjunto de configuración allow-nondistributable-artifacts provoca que las capas base de Windows se envíen a tu registro privado.
```
docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
```

Crea un archivo de manifiesto de Deployment

El siguiente es un archivo de manifiesto de Deployment llamado my-app.yaml. La imagen de este ejemplo es la que enviaste 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

Usa el comando get-credentials para habilitar kubectl de modo de que funcione con el clúster que creaste:
```
gcloud container clusters get-credentials CLUSTER_NAME
```
Reemplaza CLUSTER_NAME por el nombre del clúster que creaste.
Implementa la aplicación especificada en el archivo my-app.yaml en el clúster privado:
```
kubectl apply -f my-app.yaml
```

Verifica que el pod esté en ejecución

Enumera todos los pods para asegurarte de que la aplicación se ejecute de forma correcta:

kubectl get pods

Deberías 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

Usa imágenes de nodo variadas

Tus 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 proporcionan detalles sobre cómo configurar tus cargas de trabajo de modo que usen estos tipos de clústeres.

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

Puedes agregar grupos de nodos con diferentes tipos de imágenes de Windows Server a tu clúster. En un clúster con distintos tipos de Windows Server, debes asegurarte de que tus contenedores de Windows Server no estén programados en un nodo incompatible.

Si tienes un grupo de nodos de LTSC y un grupo de nodos de SAC en Windows Server, agrega la etiqueta de nodo gke-os-distribution en ambas cargas de trabajo.

Incluye el siguiente nodeSelector en el archivo de manifiesto para tus cargas de trabajo de LTSC de Windows Server:

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

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

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

Cuando se agrega esta etiqueta, se garantiza que tus imágenes de contenedor de LTSC no se programen en nodos de SAC incompatibles, y viceversa.

Usa cargas de trabajo con diferentes versiones de SO de Windows Server

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

Esta etiqueta de nodo garantiza que el programador de GKE elija los nodos de Windows Server correctos para ejecutar las cargas de trabajo LTSC2022 o LTSC2019. Los nodos de Windows Server pertenecen al tipo de imagen windows_ltsc_containerd. El valor de la etiqueta de nodo puede ser 2022 o 2019. Si no se especifica la etiqueta de nodo, se pueden usar los nodos LTSC2019 o LTSSC2022 para programar contenedores. Para programar contenedores de Windows Server solo en nodos de LTSC2022 de Windows Server, el 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

Usa cargas de trabajo con diferentes versiones de Windows Server

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

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

Agrega el siguiente selector de nodos a las cargas de trabajo de Linux a fin de asegurarte de que siempre estén programadas para los nodos de Linux:

nodeSelector:
   kubernetes.io/os: linux

De este modo, se proporciona protección adicional a fin de evitar que las cargas de trabajo de Linux se programen en nodos de Windows Server en caso de que el taint NoSchedule se quite por accidente de los nodos de Windows Server.