Deployment di un'applicazione Windows Server

Standard

In questa pagina scoprirai come eseguire il deployment di un'applicazione Windows Server senza stato in un cluster Google Kubernetes Engine (GKE). Puoi anche scoprire come eseguire il deployment di un'applicazione Windows con stato.

Prima di iniziare

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

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

Attiva le API

Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Nota: per le installazioni esistenti di gcloud CLI assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Eseguire il deployment di un'applicazione Windows Server in un cluster con nodi pubblici

Per eseguire il deployment di un'applicazione Windows Server in un cluster GKE con solo nodi pubblici, devi eseguire le seguenti attività:

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

Crea un cluster con nodi pubblici

Se hai già un cluster GKE che utilizza i node pool Windows Server, continua al passaggio successivo. In caso contrario, crea un cluster utilizzando i node pool Windows Server. Per eseguire il provisioning dei nodi con indirizzi IP esterni (nodi pubblici), utilizza il flag --no-enable-private-nodes quando crei il cluster.

Crea un file manifest di deployment

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

Questo taint garantisce che lo scheduler GKE non tenti di eseguire container Linux sui nodi 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 controlla la presenza di questo selettore di nodi Windows nei nuovi workload e, quando lo trova, applica la seguente tolleranza al workload, che gli consente di essere eseguito sui nodi Windows Server contrassegnati:

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

In alcuni casi, potrebbe essere necessario includere questa tolleranza in modo esplicito 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 nel cluster, il file manifest non includerà il selettore di nodi Windows. Devi includere in modo esplicito la tolleranza per il taint di Windows.

File manifest di esempio

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 è per un cluster in cui tutti i workload utilizzano lo stesso tipo e la stessa versione dell'immagine del nodo Windows Server. Per informazioni dettagliate su come utilizzare le immagini dei nodi misti, consulta la sezione Utilizzare 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 del bilanciatore del carico esterno.

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

Verifica che il pod sia in esecuzione

Assicurati che il pod funzioni convalidandolo.

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

Attendi finché l'output restituito non mostra che il pod ha lo stato Running:

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

Recupera lo stato del servizio e attendi che il campo EXTERNAL-IP venga compilato:

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

Ora puoi utilizzare il browser per aprire http://EXTERNAL_IP per visualizzare la pagina web IIS.

Eseguire il deployment di un'applicazione Windows Server in un cluster con nodi privati

Questa sezione mostra come eseguire il deployment di un'applicazione container Windows Server in un cluster GKE con solo nodi privati.

Le immagini container Windows Server hanno diversi livelli e i livelli di base sono forniti da Microsoft. I livelli di base vengono archiviati come livello esterno anziché essere incorporati nell'immagine come i livelli delle immagini Docker Linux. Quando un'immagine container Windows Server viene eseguita per la prima volta, in genere i livelli di base devono essere scaricati dai server Microsoft. Poiché i nodi privati non hanno connettività a internet, i livelli container di base di Windows Server non possono essere eseguiti direttamente dai server Microsoft.

Per utilizzare i cluster con i nodi privati abilitati, puoi configurare il daemon Docker in modo da consentire il push dei livelli non distribuibili nei registri privati. Per saperne di più, consulta la pagina GitHub di Docker Consenti il push di artefatti non distribuibili.

Per eseguire il deployment dell'applicazione Windows Server in un cluster con nodi privati abilitati:

Crea un cluster con nodi Windows Server e abilita i nodi privati.
Crea l'immagine Docker dell'applicazione Windows Server.
Esegui il deployment dell'applicazione in un cluster con nodi privati abilitati.
Verifica che il pod sia in esecuzione.

Crea un cluster con nodi privati

Segui le istruzioni riportate in Creare un cluster con nodi Windows Server. Per eseguire il provisioning dei nodi con solo indirizzi IP interni (nodi privati), utilizza il flag --enable-private-nodes quando crei il cluster.

Crea l'immagine Docker dell'applicazione Windows Server

Per creare l'immagine Docker, avvia un'istanza Compute Engine con la versione di Windows Server su cui vuoi eseguire i container dell'applicazione, ad esempio Windows Server 2019 o Windows Server versione 20H2. Assicurati inoltre di avere la connettività a internet.
Nell'istanza Compute Engine, vai alla configurazione del daemon Docker:
```
cat C:\ProgramData\docker\config\daemon.json
```
Configura il file daemon.json di Docker in modo da consentire il push dei livelli esterni nel registro privato aggiungendo queste righe:
```
{
  "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"]
}
```
In questo esempio, REGISTRY_REGION-docker.pkg.dev si riferisce a 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 l'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 usando il Dockerfile nella directory corrente e la tagga con 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. La configurazione allow-nondistributable-artifacts impostata fa sì che i livelli di base di Windows vengano inviati 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 file manifest di deployment di esempio denominato my-app.yaml. L'immagine in questo esempio è quella di cui hai eseguito il push 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 get-credentials comando per consentire a kubectl di funzionare con il cluster che hai creato:
```
gcloud container clusters get-credentials CLUSTER_NAME
```
Sostituisci CLUSTER_NAME con il nome del cluster che hai creato.
Esegui il deployment dell'applicazione specificata nel file my-app.yaml nel cluster:
```
kubectl apply -f my-app.yaml
```

Verifica che il pod sia in esecuzione

Elenca tutti i pod per assicurarti che l'applicazione sia in esecuzione correttamente:

kubectl get pods

Dovresti vedere il pod con lo stato Running, come nell'output seguente:

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

Utilizzare immagini dei nodi misti

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

Utilizzare workload con versioni del sistema operativo Windows Server LTSC diverse

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 scelga i nodi Windows Server corretti per eseguire i workload 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 i nodi LTSC2019 o LTSC2022 per pianificare i container. Per pianificare i container Windows Server solo sui nodi Windows Server LTSC2022, 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

Utilizzare workload con versioni di Windows Server diverse

Se devi eseguire node pool Windows Server con più versioni LTSC 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 che i workload vengano pianificati su nodi potenzialmente incompatibili.

Utilizzare workload Linux e Windows Server in un cluster

Aggiungi il seguente selettore di nodi ai workload Linux per assicurarti che vengano sempre pianificati sui nodi Linux:

nodeSelector:
   kubernetes.io/os: linux

In questo modo viene fornita una protezione aggiuntiva per evitare che i workload Linux vengano pianificati sui nodi Windows Server nel caso in cui il NoSchedule taint venga rimosso accidentalmente dai nodi Windows Server.

Deployment di un'applicazione Windows Server Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Eseguire il deployment di un'applicazione Windows Server in un cluster con nodi pubblici

Crea un cluster con nodi pubblici

Crea un file manifest di deployment

File manifest di esempio

Crea ed esponi il deployment

Verifica che il pod sia in esecuzione

Eseguire il deployment di un'applicazione Windows Server in un cluster con nodi privati

Crea un cluster con nodi privati

Crea l'immagine Docker dell'applicazione Windows Server

Crea un file manifest di deployment

Verifica che il pod sia in esecuzione

Utilizzare immagini dei nodi misti

Utilizzare workload con versioni del sistema operativo Windows Server LTSC diverse

Utilizzare workload con versioni di Windows Server diverse

Utilizzare workload Linux e Windows Server in un cluster

Deployment di un'applicazione Windows Server