Déployer une application Windows Server

Standard

Dans cette page, vous allez apprendre à déployer une application Windows Server sans état sur un cluster Google Kubernetes Engine (GKE), qui peut être public ouprivé. Vous pouvez également apprendre à déployer une application Windows avec état.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Artifact Registry et l'API Google Kubernetes Engine.

Activer les API

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Déployer une application Windows Server sur un cluster

Pour déployer une application Windows Server sur un cluster public GKE, vous devez effectuer les tâches suivantes :

Créer un cluster.
Créer un fichier manifeste de déploiement.
Créer et exposer le déploiement.
Vérifier que le pod est en cours d'exécution.

Créer un cluster

Si vous disposez déjà d'un cluster GKE qui utilise des pools de nœuds Windows Server, passez à l'étape suivante. Dans le cas contraire, créez un cluster à l'aide de pools de nœuds Windows Server.

Créer un fichier manifeste de déploiement

Les nœuds Windows Server sont rejetés par la paire clé-valeur suivante : node.kubernetes.io/os=windows:NoSchedule.

Ce rejet garantit que le programmeur GKE ne tente pas d'exécuter des conteneurs Linux sur des nœuds Windows Server. Pour programmer des conteneurs Windows Server sur des nœuds Windows Server, votre fichier manifeste doit inclure ce sélecteur de nœud :

nodeSelector:
 kubernetes.io/os: windows

Un webhook d'admission s'exécutant dans le cluster vérifie la présence de ce sélecteur de nœuds Windows dans les nouvelles charges de travail et applique la tolérance suivante à la charge de travail, afin qu'elle puisse s'exécuter sur les nœuds Windows Server rejetés :

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

Dans certains cas, vous devrez peut-être inclure explicitement cette tolérance dans votre fichier manifeste. Par exemple, si vous déployez un DaemonSet avec une image de conteneur multi-arch à exécuter sur tous les nœuds Linux et Windows Server du cluster, votre fichier manifeste n'inclut pas le sélecteur de nœuds Windows. Vous devez inclure explicitement la tolérance pour le rejet Windows.

Exemple de fichier manifeste

L'exemple de fichier de déploiement suivant (iis.yaml) déploie l'image IIS de Microsoft sur un seul 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

Ce fichier est destiné à un cluster où toutes les charges de travail utilisent le même type et la même version d'image de nœud Windows Server. Pour en savoir plus sur l'utilisation des images de nœuds mixtes, consultez la section Utiliser des images de nœuds mixtes.

Créer et exposer le déploiement

Créez et exposez le fichier de déploiement que vous avez créé à l'étape précédente en tant que service Kubernetes avec un déploiement d'équilibreur de charge externe.

Pour créer la ressource de déploiement, exécutez la commande suivante :
```
kubectl apply -f iis.yaml
```
Pour exposer le déploiement en tant qu'équilibreur de charge externe, exécutez la commande suivante :
```
kubectl expose deployment iis \
    --type=LoadBalancer \
    --name=iis
```

Vérifier que le pod est en cours d'exécution.

Assurez-vous que le pod fonctionne correctement en le validant.

Vérifiez l'état du pod avec kubectl :
```
kubectl get pods
```

Attendez que le résultat renvoyé indique que l'état du pod est Running :

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

Obtenez l'état du service et attendez que le champ EXTERNAL-IP soit renseigné :

kubectl get service iis

Vous devriez obtenir le résultat suivant :

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

Vous pouvez maintenant utiliser votre navigateur pour ouvrir http://EXTERNAL_IP et afficher la page Web IIS.

Déployer une application Windows Server sur un cluster privé

Cette section explique comment déployer une application de conteneur Windows Server sur un cluster privé.

Les images de conteneur Windows Server comportent plusieurs couches et les couches de base sont fournies par Microsoft. Les couches de base sont stockées en tant que couches étrangères au lieu d'être intégrées à l'image comme les couches d'images Docker Linux. Lorsqu'une image de conteneur Windows Server est extraite pour la première fois, les couches de base doivent généralement être téléchargées depuis des serveurs Microsoft. Étant donné que les nœuds de cluster privés ne sont pas connectés à Internet, les couches de conteneur de base de Windows Server ne peuvent pas être extraites directement des serveurs Microsoft.

Pour utiliser des clusters privés, vous pouvez configurer le daemon Docker pour autoriser le transfert des couches non distribuables vers des registres privés. Pour en savoir plus, consultez la section Autoriser le transfert d'artefacts non distribuables sur la page GitHub de Docker.

Pour déployer votre application Windows Server sur un cluster privé, vous allez suivre la procédure suivante :

Créer un cluster privé avec des nœuds Windows Server.
Créer l'image Docker de l'application Windows Server.
Déployer l'application sur un cluster privé.
Vérifier que le pod est en cours d'exécution.

Créer un cluster privé

Suivez les instructions des sections Créer un cluster avec des nœuds Windows Server et Créer un cluster privé pour créer et ajouter un pool de nœuds Windows à un cluster privé.

Créer l'image Docker de l'application Windows Server

Pour créer l'image Docker, démarrez une instance Compute Engine avec la version de Windows Server sur laquelle vous souhaitez exécuter vos conteneurs d'applications, telle que Windows Server 2019 ou Windows Server 20H2. Vérifiez également que vous disposez d'une connexion Internet.
Dans l'instance Compute Engine, accédez à la configuration du daemon Docker :
```
cat C:\ProgramData\docker\config\daemon.json
```
Configurez le fichier Docker daemon.json pour autoriser le transfert de couches étrangères vers votre registre privé en ajoutant les lignes suivantes :
```
{
  "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
}
```
Dans cet exemple, REGISTRY_REGION-docker.pkg.dev fait référence à Artifact Registry, où l'image sera hébergée.
Redémarrez le daemon Docker :
```
Restart-Service docker
```
Créez un dépôt Docker dans Artifact Registry.
Créez l'image Docker de votre application et ajoutez un tag comme suit :
```
cd C:\my-app
```
```
docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
```
Cette commande demande à Docker de créer l'image à l'aide du fichier Dockerfile dans le répertoire actuel et de lui attribuer un tag, tel que us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.
Transférez l'image Docker de l'application vers le dépôt Artifact Registry de votre projet. Avec la configuration allow-nondistributable-artifacts définie, les couches de base Windows doivent être transférées vers votre registre privé.
```
docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
```

Créer un fichier manifeste de déploiement

Voici un exemple de fichier manifeste de déploiement nommé my-app.yaml. L'image de cet exemple est celle que vous avez envoyée à l'étape précédente (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

Utilisez la commande get-credentials pour activer kubectl afin de pouvoir l'utiliser avec le cluster que vous venez de créer.
```
gcloud container clusters get-credentials CLUSTER_NAME
```
Remplacez CLUSTER_NAME par le nom du cluster privé que vous avez créé.
Déployez l'application spécifiée dans le fichier my-app.yaml sur votre cluster privé :
```
kubectl apply -f my-app.yaml
```

Vérifier que le pod est en cours d'exécution

Répertoriez tous les pods pour vous assurer que l'application s'exécute correctement :

kubectl get pods

Le pod devrait s'afficher avec l'état Running, comme dans le résultat suivant :

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

Utiliser des images de nœuds mixtes

Vos clusters peuvent contenir des pools de nœuds avec plusieurs types et versions de Windows Server. Ils peuvent également combiner des charges de travail Windows Server et Linux. Les sections suivantes expliquent comment configurer vos charges de travail pour utiliser ces types de clusters.

Utiliser des charges de travail avec différents types d'images de nœuds Windows Server

Vous pouvez ajouter des pools de nœuds à votre cluster à l'aide de différents types d'images Windows Server. Dans un cluster avec des types Windows Server mixtes, vous devez vous assurer que vos conteneurs Windows Server ne sont pas programmés sur un nœud Windows Server incompatible.

Si vous disposez d'un pool de nœuds LTSC Windows Server et d'un pool de nœud SAC Windows Server, ajoutez le libellé de nœud gke-os-distribution à vos deux charges de travail.

Incluez le sélecteur de nœuds suivant dans le fichier manifeste de vos charges de travail LTSC Windows Server :

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

Incluez le sélecteur de nœuds suivant dans le fichier manifeste de vos charges de travail SAC Windows Server :

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

L'ajout de ce libellé garantit que vos images de conteneur LTSC ne sont pas programmées sur des nœuds SAC incompatibles, et inversement.

Utiliser des charges de travail avec différentes versions d'OS LTSC Windows Server

Les nœuds Windows Server sont compatibles avec les images d'OS LTSC2022 et LTSC2019. Vous pouvez spécifier la version d'OS Windows à utiliser (LTSC2022) avec la paire clé/valeur suivante dans nodeSelector : cloud.google.com/gke-windows-os-version=2022.

Ce libellé de nœud garantit que le programmeur GKE choisira les nœuds Windows Server appropriés pour exécuter les charges de travail LTSC2022 ou LTSC2019. Les nœuds Windows Server appartiennent tous deux au type d'image windows_ltsc_containerd. La valeur du libellé de nœud peut être 2022 ou 2019. Si le libellé de nœud n'est pas spécifié, vous pouvez utiliser les nœuds LTSC2019 ou LTSC2022 pour programmer des conteneurs. Pour programmer des conteneurs Windows Server uniquement sur des nœuds Windows Server LTSC2022, votre fichier manifeste doit inclure ce sélecteur de nœud :

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

Utiliser des charges de travail avec différentes versions de Windows Server

Si vous devez exécuter des pools de nœuds Windows Server avec plusieurs versions LTSC ou SAC différentes, nous vous recommandons de créer vos images de conteneurs en tant qu'images multi-arch pouvant s'exécuter sur toutes les versions de Windows Server utilisées dans votre cluster. Le libellé de nœud gke-os-distribution n'est pas suffisant pour empêcher la programmation potentielle de vos charges de travail sur des nœuds incompatibles.

Utiliser des charges de travail Linux et Windows Server dans un cluster

Ajoutez le sélecteur de nœuds suivant à vos charges de travail Linux pour vous assurer qu'elles sont toujours programmées sur les nœuds Linux :

nodeSelector:
   kubernetes.io/os: linux

Vous disposez ainsi d'une protection supplémentaire pour éviter que les charges de travail Linux ne soient programmées sur des nœuds Windows Server au cas où le rejet NoSchedule serait accidentellement supprimé des nœuds Windows Server.