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

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• 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 poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

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 svolgere le seguenti attività:

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

Creare un cluster con nodi pubblici

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 Windows Server. Per eseguire il provisioning dei nodi con indirizzi IP esterni (nodi pubblici), utilizza il --no-enable-private-nodes flag quando crei il cluster.

Creare un file manifest di deployment

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

Questo stato alterato garantisce che lo scheduler GKE non provi a eseguire i container Linux sui nodi Windows Server. Per pianificare i contenitori Windows Server su 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 carichi di lavoro e, se lo trova, applica la seguente tolleranza al carico di lavoro, che consente di eseguirlo sui nodi Windows Server compromessi:

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

In alcuni casi, potresti dover includere questa tolleranza esplicitamente nel file manifest. Ad esempio, se esegui il deployment di un DaemonSet con un'immagine contenitore multi-arch da eseguire su tutti i nodi Linux e Windows Server del cluster, il file manifest non includerà il selettore dei nodi Windows. Devi includere esplicitamente la tolleranza per l'alterazione 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 è destinato a un cluster in cui tutti i carichi di lavoro 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 le 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.

1. Per creare la risorsa Deployment, esegui il comando seguente:

   kubectl apply -f iis.yaml
   

2. Per esporre il deployment come bilanciatore del carico esterno, esegui il seguente comando:

   kubectl expose deployment iis \
       --type=LoadBalancer \
       --name=iis
   

Verifica che il pod sia in esecuzione

Verifica che il pod funzioni convalidandolo.

1. Controlla lo stato del pod utilizzando kubectl:

   kubectl get pods
   

2. Attendi finché l'output restituito non indica che lo stato del pod è Running:

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

3. Visualizza lo stato del servizio e attendi che il campo EXTERNAL-IP sia 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 e visualizzare la pagina web di 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 di container Windows Server in un cluster GKE abilitato solo con nodi privati.

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

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

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

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

Creare un cluster con nodi privati

Segui le istruzioni riportate in Creare un cluster con nodi Windows Server. Per eseguire il provisioning di nodi con solo indirizzi IP interni (nodi privati), utilizza il flag --enable-private-nodes durante la creazione del cluster.

Crea l'immagine Docker dell'applicazione Windows Server

1. 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. Inoltre, assicurati di avere una connessione a internet.

2. Nell'istanza Compute Engine, vai alla configurazione del daemon Docker:

   cat C:\ProgramData\docker\config\daemon.json
   

3. Configura il file daemon.json Docker per consentire il push di livelli esterni nel tuo registry 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 l'immagine verrà ospitata.

4. Riavvia il daemon Docker:

   Restart-Service docker
   

5. Crea un repository Docker in Artifact Registry.

6. 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 la tagga con un nome, ad esempio us-central1-docker.pkg.dev/my-project/my-repository/my-app:v2.

7. Esegui il push dell'immagine Docker dell'applicazione nel repository Artifact Registry del progetto. Il set di configurazione allow-nondistributable-artifacts consente di eseguire il push dei livelli di base di Windows nel tuo registry privato.

   docker push REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/my-app:v2
   

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

1. Utilizza il comando get-credentials 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.

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

Utilizzo di immagini dei nodi misti

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

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

Puoi aggiungere al cluster pool di nodi che utilizzano diversi tipi di immagini Windows Server. 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 Windows Server LTSC e un node pool Windows Server SAC, aggiungi l'etichetta del nodo gke-os-distribution a entrambi i workload.

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

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 Windows Server SAC.

Avviso: le immagini del canale semestrale (SAC) di Windows Server non sono supportate dopo il 9 agosto 2022 perché Microsoft sta rimuovendo il supporto per il canale SAC. Per potenziali effetti e istruzioni sulla migrazione, consulta Ritiro del servizio del canale semestrale 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 versioni diverse del sistema operativo Windows Server LTSC

I nodi Windows Server supportano sia le immagini del sistema operativo LTSC2022 sia quelle 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 LTSC 2022 o LTSC 2019. Entrambi i nodi Windows Server appartengono 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 sia i nodi LTSC2019 sia quelli LTSC2022 per pianificare i container. Per pianificare i contenitori Windows Server solo sui nodi Windows Server LTSC 2022, 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 diverse di Windows Server

Se devi eseguire pool di nodi Windows Server con più versioni diverse di LTSC o SAC, ti consigliamo di creare le immagini dei container come immagini multi-arch che possono essere eseguite su tutte le versioni di Windows Server in uso nel tuo 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 dei nodi ai tuoi carichi di lavoro Linux per assicurarti che vengano sempre pianificati sui nodi Linux:

nodeSelector:
   kubernetes.io/os: linux

Ciò fornisce una protezione aggiuntiva per evitare la pianificazione dei carichi di lavoro Linux su nodi Windows Server nel caso in cui l'contaminazione NoSchedule venga rimossa accidentalmente dai nodi Windows Server.

Nota: per i DaemonSet che funzionano solo su Linux, questo nodeSelector è obbligatorio.