Implementa una aplicación de Windows Server

En esta página, aprenderás a implementar una aplicación de Windows Server sin estado. También puedes aprender a implementar una aplicación de Windows con estado.

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

Las siguientes tareas te guiarán a través de la implementación de tu aplicación de Windows Server:

  1. Crea un clúster.
  2. Crea un archivo de manifiesto de Deployment.
  3. Crea y expón el objeto Deployment.
  4. Verifica que el pod esté en ejecución.

Crea un clúster

Para obtener instrucciones, consulta 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.

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

    kubectl apply -f iis.yaml
    
  2. Para exponer un Deployment, 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.

  1. Comprueba el estado del pod mediante kubectl.

    kubectl get pods
    
  2. 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
    
  3. Obtén el estado del servicio y espera hasta que se propague el campo de la IP externa.

    kubectl get service iis
    

    Deberías 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 Consideraciones para los registros aislados en la página GitHub de Docker.

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

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

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

Crea una imagen de la aplicación de Windows Server para usar con clústeres privados.

  1. 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 Server 1909. Además, asegúrate de tener conexión a Internet.

  2. En la instancia de Compute, navega al archivo de configuración del daemon de Docker:

    PS C:\> cat C:\ProgramData\docker\config\daemon.json
    
  3. 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": ["gcr.io"]
    }
    

    gcr.io hace referencia a Container Registry, donde se alojará la imagen.

  4. Reinicia el daemon de Docker:

    PS C:\> Restart-Service docker
    
  5. Compila y etiqueta la imagen de Docker de tu aplicación:

    PS C:\> cd C:\my-app
    
    PS C:\my-app> docker build -t gcr.io/my-project/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 gcr.io/my-project/my-app:v2.

  6. Envía la imagen de Docker de la aplicación al registro gcr.io en my-project. El conjunto de configuración allow-nondistributable-artifacts provoca que las capas base de Windows se envíen a tu registro privado.

    PS C:\my-app> docker push gcr.io/my-project/my-app:v2
    

Crea un archivo de manifiesto de Deployment

A continuación, se muestra un archivo de manifiesto de implementación llamado my-app.yaml. La imagen de este ejemplo es la que enviaste en el paso anterior (gcr.io/my- project/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: gcr.io/my-project/my-app:v2

Para implementar esta aplicación en tu clúster privado ingresa lo siguiente:

gcloud container clusters get-credentials var>private-cluster-name
kubectl apply -f my-app.yaml

en este ejemplo, private-cluster-name es el nombre del clúster que creaste.

Verifica que el pod esté en ejecución

Enumera todos los pods para asegurarte de que se ejecute de forma correcta.

kubectl get pods

El resultado previsto debe mostrar el pod con el estado Running.

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 (LTSC o SAC) 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 SAC de Windows Server:

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