In questa pagina scoprirai come eseguire il deployment di un'applicazione Windows Server stateless su 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:
- Attiva l'API Artifact Registry e l'API Google Kubernetes Engine. Abilita 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
gcloud components update
.
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à:
- 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 con il 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
durante la creazione del cluster.
Crea un file manifest di deployment
I nodi Windows Server sono
contaminati
con la seguente coppia chiave-valore: node.kubernetes.io/os=windows:NoSchedule
.
Questa contaminazione 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 verifica la presenza di questo selettore di nodi Windows nei nuovi carichi di lavoro e, quando lo trova, applica la seguente tolleranza al carico di lavoro, che gli consente di essere eseguito sui nodi Windows Server tainted:
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 stai eseguendo 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 esplicitamente 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 di immagine del nodo Windows Server. Per informazioni dettagliate 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 del 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 con la convalida.
Controlla lo stato del pod utilizzando
kubectl
:kubectl get pods
Attendi che l'output restituito mostri 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 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.
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 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 archiviati come livello esterno anziché essere incorporati nell'immagine come i livelli dell'immagine Docker Linux. Quando viene estratta per la prima volta un'immagine container Windows Server, i livelli di base devono in genere essere scaricati dai server Microsoft. Poiché i nodi privati non hanno connettività a internet, i livelli di base del container 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 il push di livelli non distribuibili nei registri privati. Per saperne di più, consulta la pagina Allow push of non-distributable artifacts su GitHub di Docker.
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 abilitato con nodi privati.
- 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. Inoltre, assicurati di avere una connessione 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 per consentire il push dei livelli esterni nel tuo registro privato aggiungendo queste righe:{ "allow-nondistributable-artifacts": ["REGISTRY_REGION-docker.pkg.dev"] }
In questo esempio,
REGISTRY_REGION-docker.pkg.dev
si riferisce ad Artifact Registry, dove verrà ospitata l'immagine.Riavvia il daemon Docker:
Restart-Service docker
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 Dockerfile nella directory corrente e di taggarla 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 del tuo progetto. Il set di configurazione
allow-nondistributable-artifacts
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 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 consentire akubectl
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 tuo 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 del nodo miste
I cluster possono contenere node pool con più tipi e versioni di Windows Server. Possono anche combinare carichi di lavoro Windows Server e Linux. Le sezioni seguenti forniscono dettagli su come configurare i carichi di lavoro per utilizzare questi tipi di cluster.
Utilizzo di carichi di lavoro con diversi tipi di immagini dei nodi Windows Server
Puoi aggiungere al cluster node pool utilizzando 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.
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 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
Utilizzo di workload con versioni diverse di Windows Server
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 potenziale pianificazione dei tuoi 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 tuoi carichi di lavoro Linux per assicurarti che vengano sempre pianificati per i nodi Linux:
nodeSelector:
kubernetes.io/os: linux
In questo modo, viene fornita una protezione aggiuntiva per evitare che i carichi di lavoro Linux vengano pianificati
sui nodi Windows Server nel caso in cui il
taint NoSchedule
venga rimosso accidentalmente
dai nodi Windows Server.