Compatibilità delle versioni dei contenitori Windows
Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016
Windows Server 2016 e Aggiornamento dell'anniversario di Windows 10 (entrambi nella versione 14393) sono stati i primi sistemi Windows in cui è stato possibile compilare ed eseguire contenitori Windows Server. I contenitori creati usando queste versioni possono essere eseguiti nelle versioni più recenti, ma prima di iniziare è necessario conoscere alcune informazioni.
L'architettura di Windows differisce notevolmente da quella di Linux. Linux ha un kernel monolitico, mentre in modalità utente e kernel di Windows sono più strettamente associati. Fino all'introduzione dei contenitori, la modalità utente e kernel di Windows veniva fornita in sincronizzazione, causando così requisiti di compatibilità dei contenitori in Windows che differiscono dalla norma in Linux.
Il disaccoppiamento del limite utente/kernel in Windows è un'attività monumentale e altamente non semplice, tuttavia, abbiamo lavorato duramente per stabilizzare questo limite in tutte le finestre per offrire ai nostri clienti la flessibilità di eseguire contenitori di livello inferiore. A partire da Windows 11 e Windows Server 2022, è possibile eseguire contenitori WS2022 isolati dal processo negli host Windows 11. Abbiamo fatto del nostro meglio per acquisire le aree che interrompono il limite, ma ora vogliono aprire la funzionalità agli sviluppatori in Windows 11 per il feedback. Microsoft si impegna a abilitare questa esperienza per l'utente, quindi comunicarci quando si verificano problemi.
Per qualsiasi altro scenario in cui si verifica una mancata corrispondenza nella compatibilità del controllo delle versioni di Windows host/guest tra la modalità Utente/Kernel, ma non è garantito, e pertanto l'immagine del contenitore non verrà eseguita nell'host. Per qualsiasi versione non corrispondente, l'esecuzione con isolamento Hyper-V fornisce al contenitore un set di file binari kernel corrispondenti e non dipende dalla versione dell'host. Per una matrice di compatibilità dettagliata, vedere le tabelle seguenti.
Compatibilità del sistema operativo host Windows Server
Versione del sistema operativo dell'immagine di base del contenitore | Supporta l'isolamento Hyper-V | Supporta l'isolamento del processo |
---|---|---|
Windows Server 2022 | ✔ | ✔ |
Windows Server 2019 | ✔ | ❌ |
Windows Server 2016 | ✔ | ❌ |
Compatibilità del sistema operativo host client Windows
Versione del sistema operativo dell'immagine di base del contenitore | Supporta l'isolamento Hyper-V | Supporta l'isolamento del processo |
---|---|---|
Windows Server 2022 | ✔ | ✔ (anteprima) |
Windows Server 2019 | ✔ | ❌ |
Windows Server 2016 | ✔ | ❌ |
Nota
Windows 10 versione 1809 e Windows Server 2019 avevano lo stesso numero di build disponibile a livello generale. Da allora, hanno ricevuto aggiornamenti indipendenti con conseguente mancata corrispondenza del numero di build. L'isolamento del processo nel client Windows è disponibile in anteprima per Windows 11 con immagini di Windows Server 2022, con numero di build non corrispondente. Se è necessario eseguire contenitori isolati di processo in windows 10, segnalare i problemi relativi a GitHub.
Corrispondenza della versione dell'host del contenitore con le versioni delle immagini del contenitore
Contenitori di Windows Server
Numero di build (nuova versione di Windows)
Il sistema operativo Windows ha quattro livelli di versioni: principale, secondaria, build e revisione. La versione 10.0.14393.103, ad esempio, ha 10 come versione principale, 0 come versione secondaria, 14393 come numero di build e 103 come numero di revisione. Il numero di build cambia solo quando vengono pubblicate nuove versioni del sistema operativo e il numero di revisione viene aggiornato man mano che vengono applicati gli aggiornamenti di Windows.
Ad eccezione di WS2022 + Windows 11, i contenitori di Windows Server vengono bloccati a partire dal momento in cui il numero di build tra l'host contenitore e l'immagine del contenitore sono diversi. Ad esempio, quando l'host contenitore è versione 10.0.14393.* (Windows Server 2016) e si tenta di eseguire un contenitore con un'immagine versione 10.0.16299.* (Windows Server, versione 1709) il servizio di calcolo del sistema operativo restituirà un errore di incompatibilità della versione.
Restrizioni di Windows Server 2016
I contenitori basati su Windows Server 2016 non verranno eseguiti in un sistema in cui i numeri di revisione dell'host contenitore e l'immagine del contenitore sono diversi. Se, ad esempio, la versione dell'host del contenitore è 10.0.14393.1914 (Windows Server 2016 con KB4051033 applicato) e quella dell'immagine del contenitore è 10.0.14393.1944 (Windows Server 2016 con KB4053579 applicato), è possibile che l'immagine non venga avviata.
Per gli host o le immagini che usano Windows Server, versione 1809 e successive, questa regola non si applica: l'immagine host e contenitore non richiede revisioni corrispondenti.
Nota
È fortemente consigliabile aggiornare sia l'host che i contenitori con le patch e gli aggiornamenti più recenti per garantirne la sicurezza e la compatibilità. Per indicazioni importanti su come aggiornare i contenitori Windows, vedi Aggiornare i contenitori Windows Server.
Applicazione pratica
Esempio 1: l'host contenitore esegue Windows Server 2016 con KB4041691 applicato. Qualsiasi contenitore Windows Server distribuito in questo host deve essere basato sulle immagini di base di contenitore della versione 10.0.14393.1770. Se applichi KB4053579 al contenitore dell'host, devi anche aggiornare le immagini per assicurarti che siano supportate da tale contenitore.
Esempio 2: l'host contenitore esegue Windows Server versione 1809 con KB4534273 applicato. Qualsiasi contenitore Windows Server distribuito in questo host deve essere basato su un'immagine di base di contenitore Windows Server versione 1809 (10.0.17763), ma non deve necessariamente corrispondere al KB dell'host. Se KB4534273 viene applicato all'host, le immagini del contenitore continueranno a essere supportate, ma è consigliabile aggiornarle per risolvere eventuali problemi di sicurezza.
Esecuzione di query sulla versione
Metodo 1: introdotto nella versione 1709, il prompt dei comandi e il comando ver ora restituiscono i dettagli della revisione.
Microsoft Windows [Version 10.0.16299.125]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\>ver
Microsoft Windows [Version 10.0.16299.125]
Metodo 2: Eseguire una query sulla chiave del Registro di sistema seguente: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
Ad esempio:
C:\>reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion" /v BuildLabEx
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Users\Administrator> (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\').BuildLabEx
14393.321.amd64fre.rs1_release_inmarket.161004-2338
Per verificare quale versione viene usata dall'immagine di base, esamina i tag dell'hub Docker o la tabella hash inclusa nella descrizione dell'immagine. Nella pagina Cronologia aggiornamenti di Windows 10 è indicato quando sono state rilasciate le singole build e revisioni.
Isolamento Hyper-V per i contenitori
I contenitori Windows possono essere eseguiti con o senza isolamento Hyper-V. L'isolamento Hyper-V crea un limite sicuro intorno al contenitore con una macchina virtuale ottimizzata. A differenza dei contenitori Windows standard, che condividono il kernel tra i contenitori e l'host, ogni contenitore isolato Hyper-V usa una propria istanza del kernel di Windows. Ciò significa che possono essere disponibili diverse versioni del sistema operativo nell'immagine e nell'host del contenitore. Per altre informazioni, vedi la matrice di compatibilità riportata di seguito.
Per eseguire un contenitore con isolamento Hyper-V, è sufficiente aggiungere il tag --isolation=hyperv
al comando docker run.
Errori di versioni non corrispondenti
Se provi a eseguire una combinazione non supportata, riceverai l'errore seguente:
docker: Error response from daemon: container b81ed896222eb87906ccab1c3dd2fc49324eafa798438f7979b87b210906f839 encountered an error during CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101) extra info: {"SystemType":"Container","Name":"b81ed896222eb87906ccab1c3dd2fc49324eafa798438f7979b87b210906f839","Owner":"docker","IsDummy":false,"VolumePath":"\\\\?\\Volume{2443d38a-1379-4bcf-a4b7-fc6ad4cd7b65}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\docker\\windowsfilter\\b81ed896222eb87906ccab1c3dd2fc49324eafa798438f7979b87b210906f839","Layers":[{"ID":"1532b584-8431-5b5a-8735-5e1b4fe9c2a9","Path":"C:\\ProgramData\\docker\\windowsfilter\\b2b88bc2a47abcc682e422507abbba9c9b6d826d34e67b9e4e3144cc125a1f80"},{"ID":"a64b8da5-cd6e-5540-bc73-d81acae6da54","Path":"C:\\ProgramData\\docker\\windowsfilter\\5caaedbced1f546bccd01c9d31ea6eea4d30701ebba7b95ee8faa8c098a6845a"}],"HostName":"b81ed896222e","MappedDirectories":[],"HvPartition":false,"EndpointList":["002a0d9e-13b7-42c0-89b2-c1e80d9af243"],"Servicing":false,"AllowUnqualifiedDNSQuery":true}.
Puoi risolvere questo errore in tre modi:
- Ricompila il contenitore in base alla versione corretta di
mcr.microsoft.com/microsoft-windows-nanoserver
omcr.microsoft.com/windows/servercore
- Se l'host è più recente, esegui docker run --isolation=hyperv ...
- Prova a eseguire il contenitore in un host diverso con la stessa versione di Windows
Scegli la versione del sistema operativo del contenitore da usare
Nota
A partire dal 16 aprile 2019, il tag "latest" non viene più pubblicato o mantenuto per le immagini del contenitore del sistema operativo di base di Windows Server, Windows Server Core e Nano Server . È necessario dichiarare un tag specifico quando si esegue il pull o si fa riferimento a immagini da questi repository.
Devi conoscere la versione da usare per il tuo contenitore. Se, ad esempio, usi Windows Server versione 1809 come sistema operativo del contenitore e vuoi disporre delle patch più recenti per tale sistema, devi usare il tag 1809
quando specifichi la versione delle immagini di contenitore del sistema operativo di base desiderato, come indicato di seguito:
FROM mcr.microsoft.com/windows/nanoserver:1809
...
Se tuttavia vuoi una patch specifica di Windows Server versione 1809, puoi indicare il numero di KB nel tag. Ad esempio, per ottenere un'immagine di contenitore del sistema operativo di base Nano Server di Windows Server versione 1809, con KB4493509 applicato, devi specificare questa informazione nel modo seguente:
FROM mcr.microsoft.com/windows/nanoserver:1809-KB4493509
...
Puoi anche specificare le patch esatte che sono necessarie con lo schema utilizzato in precedenza specificando la versione del sistema operativo nel tag:
FROM mcr.microsoft.com/windows/nanoserver:10.0.17763.437
...
Le immagini di base Server Core basate su Windows Server 2022 e Windows Server 2019 sono versioni di Long-Term Servicing Channel (LTSC). Se, ad esempio, vuoi usare Windows Server 2019 come sistema operativo del contenitore dell'immagine Server Core e vuoi avere le patch più recenti per tale sistema operativo, puoi specificare le versioni LTSC nel modo seguente:
FROM mcr.microsoft.com/windows/servercore:ltsc2019
...
Versioni corrispondenti con Docker Swarm
Attualmente lo swarm Docker non dispone di un metodo integrato per stabilire la corrispondenza tra la versione di Windows usata da un contenitore e un host con la stessa versione. Se aggiorni il servizio in modo da usare un contenitore più recente, l'esecuzione verrà effettuata correttamente.
Se devi eseguire più versioni di Windows per un lungo periodo di tempo, puoi adottare due approcci: configurare gli host Windows in modo da usare sempre l'isolamento Hyper-V o usare i vincoli di etichetta.
Ricerca di un servizio che non verrà avviato
Se un servizio non si avvia, noterai che MODE
è replicated
ma REPLICAS
viene bloccato in corrispondenza di 0. Per verificare se il problema è dovuto alla versione del sistema operativo, esegui i comandi seguenti:
Esegui docker service ls per trovare il nome del servizio:
ID NAME MODE REPLICAS IMAGE PORTS
xh6mwbdq2uil angry_liskov replicated 0/1 windows/servercore/iis
Esegui docker service ps (nome servizio) per ottenere lo stato e i tentativi più recenti:
C:\Program Files\Docker>docker service ps angry_liskov
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
klkbhn742lv0 angry_liskov.1 windows/servercore/iis WIN-BSTMQDRQC2E Ready Ready 3 seconds ago
y5blbdum70zo \_ angry_liskov.1 windows/servercore/iis WIN-BSTMQDRQC2E Shutdown Failed 24 seconds ago "starting container failed: co…"
yjq6zwzqj8kt \_ angry_liskov.1 windows/servercore/iis WIN-BSTMQDRQC2E Shutdown Failed 31 seconds ago "starting container failed: co…"
ytnnv80p03xx \_ angry_liskov.1 windows/servercore/iis WIN-BSTMQDRQC2E Shutdown Failed about a minute ago "starting container failed: co…"
xeqkxbsao57w \_ angry_liskov.1 windows/servercore/iis WIN-BSTMQDRQC2E Shutdown Failed about a minute ago "starting container failed: co…"
Se viene restituito starting container failed: ...
, puoi visualizzare l'errore completo con docker service ps --no-trunc (nome contenitore):
C:\Program Files\Docker>docker service ps --no-trunc angry_liskov
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
dwsd6sjlwsgic5vrglhtxu178 angry_liskov.1 windows/servercore/iis@sha256:868bca7e89e1743792e15f78edb5a73070ef44eae6807dc3f05f9b94c23943d5 WIN-BSTMQDRQC2E Running Starting less than a second ago
y5blbdum70zoh1f6uhx5nxsfv \_ angry_liskov.1 windows/servercore/iis@sha256:868bca7e89e1743792e15f78edb5a73070ef44eae6807dc3f05f9b94c23943d5 WIN-BSTMQDRQC2E Shutdown Failed 39 seconds ago "starting container failed: container e7b5d3adba7e510569c18d8e55f7c689d7cb92be40a516c91b363e27f84604d0 encountered an error during CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101) extra info: {"SystemType":"Container","Name":"e7b5d3adba7e510569c18d8e55f7c689d7cb92be40a516c91b363e27f84604d0","Owner":"docker","VolumePath":"\\\\?\\Volume{2443d38a-1379-4bcf-a4b7-fc6ad4cd7b65}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\docker\\windowsfilter\\e7b5d3adba7e510569c18d8e55f7c689d7cb92be40a516c91b363e27f84604d0","Layers":[{"ID":"bcf2630f-ea95-529b-b33c-e5cdab0afdb4","Path":"C:\\ProgramData\\docker\\windowsfilter\\200235127f92416724ae1d53ed3fdc86d78767132d019bdda1e1192ee4cf3ae4"},{"ID":"e3ea10a8-4c2f-5b93-b2aa-720982f116f6","Path":"C:\\ProgramData\\docker\\windowsfilter\\0ccc9fa71a9f4c5f6f3bc8134fe3533e454e09f453de662cf99ab5d2106abbdc"},{"ID":"cff5391f-e481-593c-aff7-12e080c653ab","Path":"C:\\ProgramData\\docker\\windowsfilter\\a49576b24cd6ec4a26202871c36c0a2083d507394a3072186133131a72601a31"},{"ID":"499cb51e-b891-549a-b1f4-8a25a4665fbd","Path":"C:\\ProgramData\\docker\\windowsfilter\\fdf2f52c4323c62f7ff9b031c0bc3af42cf5fba91098d51089d039fb3e834c08"},{"ID":"1532b584-8431-5b5a-8735-5e1b4fe9c2a9","Path":"C:\\ProgramData\\docker\\windowsfilter\\b2b88bc2a47abcc682e422507abbba9c9b6d826d34e67b9e4e3144cc125a1f80"},{"ID":"a64b8da5-cd6e-5540-bc73-d81acae6da54","Path":"C:\\ProgramData\\docker\\windowsfilter\\5caaedbced1f546bccd01c9d31ea6eea4d30701ebba7b95ee8faa8c098a6845a"}],"HostName":"e7b5d3adba7e","HvPartition":false,"EndpointList":["298bb656-8800-4948-a41c-1b0500f3d94c"],"AllowUnqualifiedDNSQuery":true}"
Questo errore è analogo a CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101)
.
Correzione: aggiornare il servizio per usare una versione corrispondente
Esistono due considerazioni per Docker Swarm. Se disponi di un file di composizione con un servizio che usa un'immagine non creata da te, dovresti aggiornare il riferimento di conseguenza. Ad esempio:
version: '3'
services:
YourServiceName:
image: windows/servercore:1709
...
L'altra considerazione riguarda la possibilità che l'immagine a cui fai riferimento non sia stata creata da te (ad esempio, contoso/myimage):
version: '3'
services:
YourServiceName:
image: contoso/myimage
...
In questo caso, per modificare tale Dockerfile invece della riga docker-compose, è preferibile usare il metodo descritto in Errori da versioni non corrispondenti.
Mitigazione: usare l'isolamento Hyper-V con Docker Swarm
I contenitori di Windows supportano l'uso dell'isolamento Hyper-V per ogni contenitore, che richiede la modifica della configurazione del servizio Docker e quindi il riavvio del motore Docker.
Modifica
C:\ProgramData\docker\config\daemon.json
Aggiungi una riga con
"exec-opts":["isolation=hyperv"]
Nota
Il file daemon.json non esiste per impostazione predefinita. Se si scopre che questo è il caso quando si visualizza la directory, è necessario creare il file. Sarà quindi opportuno copiarlo nel codice seguente:
{ "exec-opts":["isolation=hyperv"] }
Chiudi e salva il file, quindi riavvia il motore Docker eseguendo i cmdlet seguenti in PowerShell:
Stop-Service docker Start-Service docker
Dopo aver riavviato il servizio, avvia i contenitori. Quando i contenitori sono in esecuzione, puoi verificarne il livello di isolamento usando il cmdlet seguente:
docker inspect --format='{{json .HostConfig.Isolation}}' $instanceNameOrId
Restituirà "process" o "hyperv". Se il daemon.json è stato modificato e impostato come descritto in precedenza, verrà visualizzato quest'ultimo.
Mitigazione - Usare etichette e vincoli
Ecco come usare etichette e vincoli per stabilire la corrispondenza tra le versioni:
Aggiungi etichette a ogni nodo.
In ogni nodo aggiungi due etichette:
OS
eOsVersion
. Ciò presuppone che l'esecuzione sia in locale, ma potrebbe essere modificata per impostarle in un host remoto.docker node update --label-add OS="windows" $ENV:COMPUTERNAME docker node update --label-add OsVersion="$((Get-ComputerInfo).OsVersion)" $ENV:COMPUTERNAME
Successivamente, puoi controllarle eseguendo il comando docker node inspect, che dovrebbe mostrare le etichette appena aggiunte:
"Spec": { "Labels": { "OS": "windows", "OsVersion": "10.0.16296" }, "Role": "manager", "Availability": "active" }
Aggiungi un vincolo di servizio.
Dopo aver applicato etichette a ogni nodo, puoi aggiornare i vincoli che determinano il posizionamento dei servizi. Nell'esempio seguente sostituisci "contoso_service" con il nome del servizio effettivo:
docker service update \ --constraint-add "node.labels.OS == windows" \ --constraint-add "node.labels.OsVersion == $((Get-ComputerInfo).OsVersion)" \ contoso_service
In questo modo vengono applicati limiti e in cui un nodo può essere eseguito.
Per altre informazioni su come usare i vincoli di servizio, consulta l'articolo di riferimento relativo alla creazione del servizio.
Versioni corrispondenti con Kubernetes
Lo stesso problema descritto in Corrispondenza delle versioni tramite lo swarm Docker può verificarsi quando in Kubernetes sono pianificati dei pod. Questo problema può essere evitato adottando strategie simili:
- Ricompilare il contenitore in base alla stessa versione del sistema operativo durante le fasi di sviluppo e di produzione. Per informazioni, vedi Scegliere la versione del sistema operativo del contenitore da usare.
- Usare le etichette di nodo e nodeSelector per assicurarsi che i pod siano pianificati in nodi compatibili, se nello stesso cluster sono presenti entrambi i nodi di Windows Server 2016 e Windows Server versione 1709
- Usare cluster separati in base alla versione del sistema operativo
Individuazione dei pod non riuscita nella mancata corrispondenza del sistema operativo
In questo caso, in una distribuzione è stato incluso un pod che era stato pianificato in un nodo con una versione del sistema operativo non corrispondente e senza l'abilitazione dell'isolamento Hyper-V.
Lo stesso errore viene visualizzato negli eventi elencati con kubectl describe pod <podname>
. Dopo diversi tentativi, lo stato del pod sarà probabilmente CrashLoopBackOff
.
$ kubectl -n plang describe pod fabrikamfiber.web-789699744-rqv6p
Name: fabrikamfiber.web-789699744-rqv6p
Namespace: plang
Node: 38519acs9011/10.240.0.6
Start Time: Mon, 09 Oct 2017 19:40:30 +0000
Labels: io.kompose.service=fabrikamfiber.web
pod-template-hash=789699744
Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"plang","name":"fabrikamfiber.web-789699744","uid":"b5062a08-ad29-11e7-b16e-000d3a...
Status: Running
IP: 10.244.3.169
Created By: ReplicaSet/fabrikamfiber.web-789699744
Controlled By: ReplicaSet/fabrikamfiber.web-789699744
Containers:
fabrikamfiberweb:
Container ID: docker://eab0151378308315ed6c31adf4ad9e31e6d65fd300e56e742757004a969a803a
Image: patricklang/fabrikamfiber.web:latest
Image ID: docker-pullable://patricklang/fabrikamfiber.web@sha256:562741016ce7d9a232a389449a4fd0a0a55aab178cf324144404812887250ead
Port: 80/TCP
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: ContainerCannotRun
Message: container eab0151378308315ed6c31adf4ad9e31e6d65fd300e56e742757004a969a803a encountered an error during CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101) extra info: {"SystemType":"Container","Name":"eab0151378308315ed6c31adf4ad9e31e6d65fd300e56e742757004a969a803a","Owner":"docker","IsDummy":false,"VolumePath":"\\\\?\\Volume{037b6606-bc9c-461f-ae02-829c28410798}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\docker\\windowsfilter\\eab0151378308315ed6c31adf4ad9e31e6d65fd300e56e742757004a969a803a","Layers":[{"ID":"f8bc427f-7aa3-59c6-b271-7331713e9451","Path":"C:\\ProgramData\\docker\\windowsfilter\\e206d2514a6265a76645b9d6b3dc6a78777c34dbf5da9fa2d564651645685881"},{"ID":"a6f35e41-a86c-5e4d-a19a-a6c2464bfb47","Path":"C:\\ProgramData\\docker\\windowsfilter\\0f21f1e28ef13030bbf0d87cbc97d1bc75f82ea53c842e9a3250a2156ced12d5"},{"ID":"4f624ca7-2c6d-5c42-b73f-be6e6baf2530","Path":"C:\\ProgramData\\docker\\windowsfilter\\4d9e2ad969fbd74fd58c98b5ab61e55a523087910da5200920e2b6f641d00c67"},{"ID":"88e360ff-32af-521d-9a3f-3760c12b35e2","Path":"C:\\ProgramData\\docker\\windowsfilter\\9e16a3d53d3e9b33344a6f0d4ed34c8a46448ee7636b672b61718225b8165e6e"},{"ID":"20f1a4e0-a6f3-5db3-9bf2-01fd3e9e855a","Path":"C:\\ProgramData\\docker\\windowsfilter\\7eec7f59f9adce38cc0a6755da58a3589287d920d37414b5b21b5b543d910461"},{"ID":"c2b3d728-4879-5343-a92a-b735752a4724","Path":"C:\\ProgramData\\docker\\windowsfilter\\8ed04b60acc0f65f541292a9e598d5f73019c8db425f8d49ea5819eab16a42f3"},{"ID":"2973e760-dc59-5800-a3de-ab9d93be81e5","Path":"C:\\ProgramData\\docker\\windowsfilter\\cc71305d45f09ce377ef497f28c3a74ee027c27f20657d2c4a5f157d2457cc75"},{"ID":"454a7d36-038c-5364-8a25-fa84091869d6","Path":"C:\\ProgramData\\docker\\windowsfilter\\9e8cde1ce8f5de861a5f22841f1ab9bc53d5f606d06efeacf5177f340e8d54d0"},{"ID":"9b748c8c-69eb-55fb-a1c1-5688cac4efd8","Path":"C:\\ProgramData\\docker\\windowsfilter\\8e02bf5404057055a71d542780a2bb2731be4b3707c01918ba969fb4d83b98ec"},{"ID":"bfde5c26-b33f-5424-9405-9d69c2fea4d0","Path":"C:\\ProgramData\\docker\\windowsfilter\\77483cedfb0964008c33d92d306734e1fab3b5e1ebb27e898f58ccfd108108f2"},{"ID":"bdabfbf5-80d1-57f1-86f3-448ce97e2d05","Path":"C:\\ProgramData\\docker\\windowsfilter\\aed2ebbb31ad24b38ee8521dd17744319f83d267bf7f360bc177e27ae9a006cf"},{"ID":"ad9b34f2-dcee-59ea-8962-b30704ae6331","Path":"C:\\ProgramData\\docker\\windowsfilter\\d44d3a675fec1070b61d6ea9bacef4ac12513caf16bd6453f043eed2792f75d8"}],"HostName":"fabrikamfiber.web-789699744-rqv6p","MappedDirectories":[{"HostPath":"c:\\var\\lib\\kubelet\\pods\\b50f0027-ad29-11e7-b16e-000d3afd2878\\volumes\\kubernetes.io~secret\\default-token-rw9dn","ContainerPath":"c:\\var\\run\\secrets\\kubernetes.io\\serviceaccount","ReadOnly":true,"BandwidthMaximum":0,"IOPSMaximum":0}],"HvPartition":false,"EndpointList":null,"NetworkSharedContainerName":"586870f5833279678773cb700db3c175afc81d557a75867bf39b43f985133d13","Servicing":false,"AllowUnqualifiedDNSQuery":false}
Exit Code: 128
Started: Mon, 09 Oct 2017 20:27:08 +0000
Finished: Mon, 09 Oct 2017 20:27:08 +0000
Ready: False
Restart Count: 10
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-rw9dn (ro)
Conditions:
Type Status
Initialized True
Ready False
PodScheduled True
Volumes:
default-token-rw9dn:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-rw9dn
Optional: false
QoS Class: BestEffort
Node-Selectors: beta.kubernetes.io/os=windows
Tolerations: <none>
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
49m 49m 1 default-scheduler Normal Scheduled Successfully assigned fabrikamfiber.web-789699744-rqv6p to 38519acs9011
49m 49m 1 kubelet, 38519acs9011 Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-rw9dn"
29m 29m 1 kubelet, 38519acs9011 spec.containers{fabrikamfiberweb} Warning Failed Failed to pull image "patricklang/fabrikamfiber.web:latest": rpc error: code = 2 desc = Error response from daemon: {"message":"Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: no such host"}
49m 3m 12 kubelet, 38519acs9011 spec.containers{fabrikamfiberweb} Normal Pulling pulling image "patricklang/fabrikamfiber.web:latest"
33m 3m 11 kubelet, 38519acs9011 spec.containers{fabrikamfiberweb} Normal Pulled Successfully pulled image "patricklang/fabrikamfiber.web:latest"
33m 3m 11 kubelet, 38519acs9011 spec.containers{fabrikamfiberweb} Normal Created Created container
33m 2m 11 kubelet, 38519acs9011 spec.containers{fabrikamfiberweb} Warning Failed Error: failed to start container "fabrikamfiberweb": Error response from daemon: {"message":"container fabrikamfiberweb encountered an error during CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101) extra info: {\"SystemType\":\"Container\",\"Name\":\"fabrikamfiberweb\",\"Owner\":\"docker\",\"IsDummy\":false,\"VolumePath\":\"\\\\\\\\?\\\\Volume{037b6606-bc9c-461f-ae02-829c28410798}\",\"IgnoreFlushesDuringBoot\":true,\"LayerFolderPath\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\fabrikamfiberweb\",\"Layers\":[{\"ID\":\"f8bc427f-7aa3-59c6-b271-7331713e9451\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\e206d2514a6265a76645b9d6b3dc6a78777c34dbf5da9fa2d564651645685881\"},{\"ID\":\"a6f35e41-a86c-5e4d-a19a-a6c2464bfb47\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\0f21f1e28ef13030bbf0d87cbc97d1bc75f82ea53c842e9a3250a2156ced12d5\"},{\"ID\":\"4f624ca7-2c6d-5c42-b73f-be6e6baf2530\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\4d9e2ad969fbd74fd58c98b5ab61e55a523087910da5200920e2b6f641d00c67\"},{\"ID\":\"88e360ff-32af-521d-9a3f-3760c12b35e2\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\9e16a3d53d3e9b33344a6f0d4ed34c8a46448ee7636b672b61718225b8165e6e\"},{\"ID\":\"20f1a4e0-a6f3-5db3-9bf2-01fd3e9e855a\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\7eec7f59f9adce38cc0a6755da58a3589287d920d37414b5b21b5b543d910461\"},{\"ID\":\"c2b3d728-4879-5343-a92a-b735752a4724\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\8ed04b60acc0f65f541292a9e598d5f73019c8db425f8d49ea5819eab16a42f3\"},{\"ID\":\"2973e760-dc59-5800-a3de-ab9d93be81e5\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\cc71305d45f09ce377ef497f28c3a74ee027c27f20657d2c4a5f157d2457cc75\"},{\"ID\":\"454a7d36-038c-5364-8a25-fa84091869d6\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\9e8cde1ce8f5de861a5f22841f1ab9bc53d5f606d06efeacf5177f340e8d54d0\"},{\"ID\":\"9b748c8c-69eb-55fb-a1c1-5688cac4efd8\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\8e02bf5404057055a71d542780a2bb2731be4b3707c01918ba969fb4d83b98ec\"},{\"ID\":\"bfde5c26-b33f-5424-9405-9d69c2fea4d0\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\77483cedfb0964008c33d92d306734e1fab3b5e1ebb27e898f58ccfd108108f2\"},{\"ID\":\"bdabfbf5-80d1-57f1-86f3-448ce97e2d05\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\aed2ebbb31ad24b38ee8521dd17744319f83d267bf7f360bc177e27ae9a006cf\"},{\"ID\":\"ad9b34f2-dcee-59ea-8962-b30704ae6331\",\"Path\":\"C:\\\\ProgramData\\\\docker\\\\windowsfilter\\\\d44d3a675fec1070b61d6ea9bacef4ac12513caf16bd6453f043eed2792f75d8\"}],\"HostName\":\"fabrikamfiber.web-789699744-rqv6p\",\"MappedDirectories\":[{\"HostPath\":\"c:\\\\var\\\\lib\\\\kubelet\\\\pods\\\\b50f0027-ad29-11e7-b16e-000d3afd2878\\\\volumes\\\\kubernetes.io~secret\\\\default-token-rw9dn\",\"ContainerPath\":\"c:\\\\var\\\\run\\\\secrets\\\\kubernetes.io\\\\serviceaccount\",\"ReadOnly\":true,\"BandwidthMaximum\":0,\"IOPSMaximum\":0}],\"HvPartition\":false,\"EndpointList\":null,\"NetworkSharedContainerName\":\"586870f5833279678773cb700db3c175afc81d557a75867bf39b43f985133d13\",\"Servicing\":false,\"AllowUnqualifiedDNSQuery\":false}"}
33m 11s 151 kubelet, 38519acs9011 Warning FailedSync Error syncing pod
32m 11s 139 kubelet, 38519acs9011 spec.containers{fabrikamfiberweb} Warning BackOff Back-off restarting failed container
Prevenzione: uso di etichette dei nodi e nodeSelector
Esegui kubectl get node per ottenere un elenco di tutti i nodi. Successivamente, puoi eseguire kubectl describe node (nome nodo) per ottenere maggiori dettagli.
Nell'esempio seguente, due nodi Windows eseguono versioni diverse:
$ kubectl get node
NAME STATUS AGE VERSION
38519acs9010 Ready 21h v1.7.7-7+e79c96c8ff2d8e
38519acs9011 Ready 4h v1.7.7-25+bc3094f1d650a2
k8s-linuxpool1-38519084-0 Ready 21h v1.7.7
k8s-master-38519084-0 Ready 21h v1.7.7
$ kubectl describe node 38519acs9010
Name: 38519acs9010
Role:
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=Standard_D2_v2
beta.kubernetes.io/os=windows
failure-domain.beta.kubernetes.io/region=westus2
failure-domain.beta.kubernetes.io/zone=0
kubernetes.io/hostname=38519acs9010
Annotations: node.alpha.kubernetes.io/ttl=0
volumes.kubernetes.io/controller-managed-attach-detach=true
Taints: <none>
CreationTimestamp: Fri, 06 Oct 2017 01:41:02 +0000
...
System Info:
Machine ID: 38519acs9010
System UUID:
Boot ID:
Kernel Version: 10.0 14393 (14393.1715.amd64fre.rs1_release_inmarket.170906-1810)
OS Image:
Operating System: windows
Architecture: amd64
...
$ kubectl describe node 38519acs9011
Name: 38519acs9011
Role:
Labels: beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=Standard_DS1_v2
beta.kubernetes.io/os=windows
failure-domain.beta.kubernetes.io/region=westus2
failure-domain.beta.kubernetes.io/zone=0
kubernetes.io/hostname=38519acs9011
Annotations: node.alpha.kubernetes.io/ttl=0
volumes.kubernetes.io/controller-managed-attach-detach=true
Taints: <none>
CreationTimestamp: Fri, 06 Oct 2017 18:13:25 +0000
Conditions:
...
System Info:
Machine ID: 38519acs9011
System UUID:
Boot ID:
Kernel Version: 10.0 16299 (16299.0.amd64fre.rs3_release.170922-1354)
OS Image:
Operating System: windows
Architecture: amd64
...
Useremo questo esempio per illustrare come stabilire la corrispondenza tra le versioni:
Prendi nota di ogni nome di nodo e del valore di
Kernel Version
dalle informazioni di sistema.In questo esempio, le informazioni avranno un aspetto simile al seguente:
Nome Versione 38519acs9010 14393.1715.amd64fre.rs1_release_inmarket.170906-1810 38519acs9011 16299.0.amd64fre.rs3_release.170922-1354 Aggiungere un'etichetta a ogni nodo denominato
beta.kubernetes.io/osbuild
. Windows Server 2016 necessita sia della versione principale sia di quella secondaria (14393.1715 in questo esempio) per essere supportato senza isolamento Hyper-V. Windows Server versione 1709 necessita solo della versione principale (16299 in questo esempio) per la corrispondenza.In questo esempio, il comando per aggiungere le etichette ha un aspetto simile al seguente:
$ kubectl label node 38519acs9010 beta.kubernetes.io/osbuild=14393.1715 node "38519acs9010" labeled $ kubectl label node 38519acs9011 beta.kubernetes.io/osbuild=16299 node "38519acs9011" labeled
Verifica che le etichette siano presenti eseguendo kubectl get nodes --show-labels.
In questo esempio, l'output sarà simile al seguente:
$ kubectl get nodes --show-labels NAME STATUS AGE VERSION LABELS 38519acs9010 Ready,SchedulingDisabled 3d v1.7.7-7+e79c96c8ff2d8e beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=Standard_D2_v2,beta.kubernetes.io/os=windows,beta.kubernetes.io/osbuild=14393.1715,failure-domain.beta.kubernetes.io/region=westus2,failure-domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=38519acs9010 38519acs9011 Ready 3d v1.7.7-25+bc3094f1d650a2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=Standard_DS1_v2,beta.kubernetes.io/os=windows,beta.kubernetes.io/osbuild=16299,failure-domain.beta.kubernetes.io/region=westus2,failure-domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=38519acs9011 k8s-linuxpool1-38519084-0 Ready 3d v1.7.7 agentpool=linuxpool1,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=Standard_D2_v2,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=westus2,failure-domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=k8s-linuxpool1-38519084-0,kubernetes.io/role=agent k8s-master-38519084-0 Ready 3d v1.7.7 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=Standard_D2_v2,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=westus2,failure-domain.beta.kubernetes.io/zone=0,kubernetes.io/hostname=k8s-master-38519084-0,kubernetes.io/role=master
Aggiungi selettori di nodo alle distribuzioni. In questo esempio aggiungeremo un
nodeSelector
alla specifica del contenitore conbeta.kubernetes.io/os
= windows ebeta.kubernetes.io/osbuild
= 14393.* o 16299 per la corrispondenza del sistema operativo di base usato dal contenitore.Ecco un esempio completo per l'esecuzione di un contenitore compilato per Windows Server 2016:
apiVersion: extensions/v1beta1 kind: Deployment metadata: annotations: kompose.cmd: kompose convert -f docker-compose-combined.yml kompose.version: 1.2.0 (99f88ef) creationTimestamp: null labels: io.kompose.service: fabrikamfiber.web name: fabrikamfiber.web spec: replicas: 1 strategy: {} template: metadata: creationTimestamp: null labels: io.kompose.service: fabrikamfiber.web spec: containers: - image: patricklang/fabrikamfiber.web:latest name: fabrikamfiberweb ports: - containerPort: 80 resources: {} restartPolicy: Always nodeSelector: "beta.kubernetes.io/os": windows "beta.kubernetes.io/osbuild": "14393.1715" status: {}
Il pod può ora iniziare con la distribuzione aggiornata. I selettori di nodo vengono visualizzati anche in
kubectl describe pod <podname>
. Puoi quindi eseguire anche tale comando per verificare che siano stati aggiunti.Questo è l'output dell'esempio:
$ kubectl -n plang describe po fa Name: fabrikamfiber.web-1780117715-5c8vw Namespace: plang Node: 38519acs9010/10.240.0.4 Start Time: Tue, 10 Oct 2017 01:43:28 +0000 Labels: io.kompose.service=fabrikamfiber.web pod-template-hash=1780117715 Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"plang","name":"fabrikamfiber.web-1780117715","uid":"6a07aaf3-ad5c-11e7-b16e-000d3... Status: Running IP: 10.244.1.84 Created By: ReplicaSet/fabrikamfiber.web-1780117715 Controlled By: ReplicaSet/fabrikamfiber.web-1780117715 Containers: fabrikamfiberweb: Container ID: docker://c94594fb53161f3821cf050d9af7546991aaafbeab41d333d9f64291327fae13 Image: patricklang/fabrikamfiber.web:latest Image ID: docker-pullable://patricklang/fabrikamfiber.web@sha256:562741016ce7d9a232a389449a4fd0a0a55aab178cf324144404812887250ead Port: 80/TCP State: Running Started: Tue, 10 Oct 2017 01:43:42 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-rw9dn (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: default-token-rw9dn: Type: Secret (a volume populated by a Secret) SecretName: default-token-rw9dn Optional: false QoS Class: BestEffort Node-Selectors: beta.kubernetes.io/os=windows beta.kubernetes.io/osbuild=14393.1715 Tolerations: <none> Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 5m 5m 1 default-scheduler Normal Scheduled Successfully assigned fabrikamfiber.web-1780117715-5c8vw to 38519acs9010 5m 5m 1 kubelet, 38519acs9010 Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-rw9dn" 5m 5m 1 kubelet, 38519acs9010 spec.containers{fabrikamfiberweb} Normal Pulling pulling image "patricklang/fabrikamfiber.web:latest" 5m 5m 1 kubelet, 38519acs9010 spec.containers{fabrikamfiberweb} Normal Pulled Successfully pulled image "patricklang/fabrikamfiber.web:latest" 5m 5m 1 kubelet, 38519acs9010 spec.containers{fabrikamfiberweb} Normal Created Created container 5m 5m 1 kubelet, 38519acs9010 spec.containers{fabrikamfiberweb} Normal Started Started container