Deployment di un'applicazione Windows Server

Standard

In questa pagina scoprirai come eseguire il deployment di un'applicazione Windows Server stateless su un cluster Google Kubernetes Engine (GKE), che può essere pubblico o privato. Puoi anche scoprire come eseguire il deployment di un'applicazione Windows stateful.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

Abilita l'API Artifact Registry e l'API Google Kubernetes Engine.

Abilita le API

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Deployment di un'applicazione Windows Server in un cluster

Per eseguire il deployment di un'applicazione Windows Server in un cluster pubblico GKE, dovrai eseguire le seguenti attività:

Crea un cluster.
Crea un file manifest di deployment.
Crea ed esponi il deployment.
Verifica che il pod sia in esecuzione.

crea un cluster

Se hai già un cluster GKE che utilizza pool di nodi Windows Server, vai al passaggio successivo. In caso contrario, crea un cluster utilizzando i pool di nodi di Windows Server.

crea un file manifest di deployment

I nodi Windows Server sono incompatibili con la seguente coppia chiave-valore: node.kubernetes.io/os=windows:NoSchedule.

Questa incompatibilità garantisce che lo scheduler GKE non tenti di eseguire container Linux sui nodi di Windows Server. Per pianificare i container Windows Server sui nodi Windows Server, il file manifest deve includere questo selettore di nodi:

nodeSelector:
 kubernetes.io/os: windows

Un webhook di ammissione in esecuzione nel cluster verifica la presenza di questo selettore di nodi Windows nei nuovi carichi di lavoro e, se individuato, applica la seguente tolleranza al carico di lavoro che ne consente l'esecuzione sui nodi Windows Server incompatibili:

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

In alcuni casi, può essere necessario includere esplicitamente questa tolleranza nel file manifest. Ad esempio, se esegui il deployment di un DaemonSet con un'immagine container multi-arch da eseguire su tutti i nodi Linux e Windows Server del cluster, il file manifest non includerà il selettore di nodi Windows. Devi includere esplicitamente la tolleranza per l'incompatibilità di Windows.

Esempio di file manifest

Il seguente file di deployment di esempio (iis.yaml) esegue il deployment dell'immagine IIS di Microsoft in un singolo 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

Questo file è relativo a un cluster in cui tutti i carichi di lavoro utilizzano lo stesso tipo e la stessa versione di immagine dei nodi Windows Server. Per maggiori dettagli su come utilizzare le immagini dei nodi misti, consulta la sezione Utilizzo delle immagini dei nodi misti.

Crea ed esponi il deployment

Crea ed esponi il file di deployment creato nel passaggio precedente come servizio Kubernetes con un deployment di un bilanciatore del carico esterno.

Per creare la risorsa Deployment, esegui questo comando:
```
kubectl apply -f iis.yaml
```
Per esporre il deployment come bilanciatore del carico esterno, esegui questo comando:
```
kubectl expose deployment iis \
    --type=LoadBalancer \
    --name=iis
```

Verifica che il pod sia in esecuzione

Assicurati che il pod funzioni eseguendo la convalida.

Controlla lo stato del pod utilizzando kubectl:
```
kubectl get pods
```

Attendi finché l'output restituito mostra che lo stato del pod è Running:

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

Ottieni lo stato del servizio e attendi che venga completato il campo EXTERNAL-IP:

kubectl get service iis

Dovresti vedere l'output seguente:

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

A questo punto, puoi utilizzare il browser per aprire http://EXTERNAL_IP e vedere la pagina web di IIS.

Deployment di un'applicazione Windows Server in un cluster privato

Questa sezione mostra come eseguire il deployment di un'applicazione container di Windows Server in un cluster privato.

Le immagini container Windows Server hanno diversi livelli e quelli di base sono forniti da Microsoft. I livelli di base vengono archiviati come livello estraneo invece di essere incorporati nell'immagine, come lo sono i livelli dell'immagine Docker di Linux. Quando un'immagine container di Windows Server viene estratta per la prima volta, i livelli di base devono essere scaricati dai server Microsoft. Poiché i nodi cluster privato non hanno connettività a internet, non è possibile estrarre direttamente dai server Microsoft i livelli di container di base di Windows Server.

Per utilizzare cluster privati, puoi configurare il daemon Docker in modo da consentire il push di livelli non distribuibili nei registri privati. Per scoprire di più, consulta Consenti il push di artefatti non distribuibili sulla pagina GitHub di Docker.

Per eseguire il deployment della tua applicazione Windows Server in un cluster privato:

Crea un cluster privato con nodi Windows Server.
Crea l'immagine Docker dell'applicazione Windows Server.
Esegui il deployment dell'applicazione in un cluster privato.
Verifica che il pod sia in esecuzione.

Creare un cluster privato

Segui le istruzioni in Creazione di un cluster con nodi Windows Server e Creazione di un cluster privato per creare e aggiungere un pool di nodi Windows a un cluster privato.

Crea l'immagine Docker dell'applicazione Windows Server

Per creare l'immagine Docker, avvia un'istanza di Compute Engine con la versione di Windows Server su cui vuoi eseguire i container delle applicazioni, ad esempio Windows Server 2019 o Windows Server versione 20H2. Assicurati inoltre che sia disponibile una connessione a internet.
Nell'istanza Compute Engine, vai alla configurazione del daemon Docker:
```
cat C:\ProgramData\docker\config\daemon.json
```
Configura il file Docker daemon.json per consentire il push dei livelli esterni al registro privato aggiungendo queste righe:
```
{
  "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
}
```
In questo esempio, REGISTRY_REGION-docker.pkg.dev fa riferimento ad Artifact Registry, dove verrà ospitata l'immagine.
Riavvia il daemon Docker:
```
Restart-Service docker
```
Crea un repository Docker in Artifact Registry.
Crea e tagga l'immagine Docker per la tua applicazione:
```
cd C:\my-app
```
```
docker build -t REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2 .
```
Questo comando indica a Docker di creare l'immagine utilizzando il Dockerfile nella directory corrente e di assegnargli un nome, ad esempio us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.
Esegui il push dell'immagine Docker dell'applicazione nel repository Artifact Registry nel tuo progetto. Il set di configurazione allow-nondistributable-artifacts determina il push dei livelli di base di Windows al tuo registro privato.
```
docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
```

crea un file manifest di deployment

Di seguito è riportato un esempio di file manifest del deployment denominato my-app.yaml. L'immagine in questo esempio è quella che hai inviato nel passaggio precedente (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

Utilizza il comando get-credentials per abilitare kubectl in modo che funzioni con il cluster che hai creato:
```
gcloud container clusters get-credentials CLUSTER_NAME
```
Sostituisci CLUSTER_NAME con il nome del cluster privato che hai creato.
Esegui il deployment dell'applicazione specificata nel file my-app.yaml nel tuo cluster privato:
```
kubectl apply -f my-app.yaml
```

Verifica che il pod sia in esecuzione

Elenca tutti i pod per assicurarti che l'applicazione funzioni correttamente:

kubectl get pods

Dovresti vedere il pod con uno stato di Running come nell'output seguente:

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

Utilizzo di immagini dei nodi misti

I cluster possono contenere pool di nodi con più tipi di Windows Server e versioni Windows Server. Possono anche combinare carichi di lavoro Windows Server e Linux. Le seguenti sezioni forniscono dettagli su come configurare i carichi di lavoro per utilizzare questi tipi di cluster.

Utilizzo di carichi di lavoro con tipi di immagini dei nodi Windows Server diversi

Puoi aggiungere pool di nodi al cluster utilizzando tipi di immagini Windows Server diversi. In un cluster con tipi di Windows Server misti, devi assicurarti che i container Windows Server non siano pianificati su un nodo Windows Server incompatibile.

Se hai un pool di nodi LTSC Windows Server e un pool di nodi SAC di Windows Server, aggiungi l'etichetta del nodo gke-os-distribution a entrambi i carichi di lavoro.

Includi il seguente nodeSelector nel file manifest per i carichi di lavoro LTSC di Windows Server:

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

Includi il seguente nodeSelector nel file manifest per i carichi di lavoro SAC di Windows Server.

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

L'aggiunta di questa etichetta garantisce che le immagini container LTSC non vengano pianificate su nodi SAC incompatibili e viceversa.

Utilizzo di carichi di lavoro con diverse versioni del sistema operativo LTSC di Windows Server

I nodi Windows Server supportano le immagini del sistema operativo LTSC2022 e LTSC2019. Puoi specificare la versione del sistema operativo Windows da utilizzare (LTSC2022) con la seguente coppia chiave-valore in nodeSelector: cloud.google.com/gke-windows-os-version=2022.

Questa etichetta del nodo garantisce che lo scheduler GKE sceglierà i nodi del server Windows corretti per eseguire i carichi di lavoro LTSC2022 o LTSC2019. I nodi Windows Server appartengono entrambi al tipo di immagine windows_ltsc_containerd. Il valore dell'etichetta del nodo può essere 2022 o 2019. Se l'etichetta del nodo non è specificata, è possibile utilizzare entrambi i nodi LTSC2019 o LTSC2022 per pianificare i container. Per pianificare i container Windows Server solo sui nodi LTSC2022 di Windows Server, il file manifest deve includere questo selettore di nodi:

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

Utilizzo di carichi di lavoro con versioni di Windows Server diverse

Se devi eseguire pool di nodi Windows Server con più versioni LTSC o SAC diverse, ti consigliamo di creare le immagini container come immagini multi-arch che possono essere eseguite su tutte le versioni di Windows Server in uso nel cluster. L'etichetta del nodo gke-os-distribution non è sufficiente per impedire la pianificazione dei carichi di lavoro su nodi incompatibili.

Utilizzo di carichi di lavoro Linux e Windows Server in un cluster

Aggiungi il seguente selettore di nodi ai carichi di lavoro Linux per assicurarti che siano sempre pianificati per i nodi Linux:

nodeSelector:
   kubernetes.io/os: linux

Ciò fornisce una protezione aggiuntiva per evitare che i carichi di lavoro Linux vengano pianificati sui nodi Windows Server nel caso in cui l'incompatibilità NoSchedule venga rimossa accidentalmente dai nodi di Windows Server.