Compatibilité des versions avec les conteneurs Windows
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
Windows Server 2016 et la mise à jour anniversaire Windows 10 (tous deux de version 14393) ont été les premières versions de Windows capables de générer et d’exécuter des conteneurs Windows Server. Les conteneurs créés à l’aide de ces versions peuvent s’exécuter sur des versions plus récentes, mais vous devez être au fait de certains éléments avant de commencer.
L’architecture de Windows diffère considérablement de celle de Linux. Linux a un noyau monolithique, tandis que dans Windows, le mode utilisateur et le mode noyau sont étroitement liés. Jusqu’à l’introduction des conteneurs, les modes utilisateur et noyau de Windows étaient fournis en synchronie, ce qui entraînait des exigences de compatibilité de conteneur sur Windows différentes de celles de Linux.
Le découplage de la limite utilisateur/noyau dans Windows est une tâche monumentale et extrêmement complexe, toutefois, nous avons travaillé dur pour stabiliser cette limite sur l’ensemble de Windows afin de fournir à nos clients la flexibilité nécessaire pour exécuter des conteneurs de niveau inférieur. À partir de Windows 11 et Windows Server 2022, nous donnons la possibilité d’exécuter des conteneurs WS2022 isolés des processus sur les hôtes Windows 11. Nous avons fait de notre mieux pour capturer les zones qui franchissent la limite, mais voulons à présent ouvrir la fonctionnalité aux développeurs sur Windows 11 pour avoir leurs commentaires. En nous engageant à activer cette expérience pour vous, nous comptons sur votre retour en cas de problèmes.
Dans tous les autres scénarios où le versioning de l’hôte/invité Windows ne correspond pas, la compatibilité entre le mode utilisateur et le mode noyau est possible, mais non garantie et, par conséquent, l’image conteneur ne peut pas s’exécuter sur l’hôte. Pour toute version incompatible, l’exécution avec l’isolation Hyper-V fournit le conteneur avec un ensemble de fichiers binaires de noyau correspondants et ne dépend pas de la version de l’hôte. Consultez les tableaux ci-dessous pour une matrice de compatibilité détaillée.
Compatibilité du système d’exploitation hôte Windows Server
| Version du système d’exploitation de l’image de base du conteneur | Prend en charge l’isolation Hyper-V | Prend en charge l’isolation des processus |
|---|---|---|
| Windows Server 2022 | ✔ | ✔ |
| Windows Server 2019 | ✔ | ❌ |
| Windows Server 2016 | ✔ | ❌ |
Compatibilité du système d’exploitation hôte du client Windows
| Version de système d’exploitation de l’image de base du conteneur | Prend en charge l’isolation Hyper-V | Prend en charge l’isolation des processus |
|---|---|---|
| Windows Server 2022 | ✔ | ✔(préversion) |
| Windows Server 2019 | ✔ | ❌ |
| Windows Server 2016 | ✔ | ❌ |
Notes
Windows 10 version 1809 et Windows Server 2019 avaient le même numéro de build au moment de la mise en disponibilité générale. Depuis lors, ils ont reçu des mises à jour indépendantes, ce qui a entraîné une incompatibilité des numéros de build. L’isolation de processus sur le client Windows est disponible en préversion pour Windows 11 avec les images Windows Server 2022, avec une incompatibilité de numéro de build. Si vous devez exécuter des conteneurs isolés par processus sur Windows 10, faites-le nous savoir dans nos problèmes GitHub.
Correspondance de la version d’hôte de conteneur avec les versions des images de conteneur
Conteneurs Windows Server
Numéro de build (nouvelle mise en production de Windows)
Le système d’exploitation Windows utilise quatre niveaux de gestion de version : majeure, mineure, build et révision. Par exemple, la version 10.0.14393.103 comprend la version majeure 10, la version mineure 0, la build 14393 et la révision 103. Le numéro de build change uniquement quand de nouvelles versions du système d’exploitation sont publiées, et le numéro de révision est mis à jour quand des mises à jour Windows sont appliquées.
À l’exception de WS2022 + Windows 11, les conteneurs Windows Server ne peuvent pas démarrer quand le numéro de build de l’hôte du conteneur diffère de celui de l’image conteneur. Par exemple, quand l’hôte de conteneur a la version 10.0.14393.* (Windows Server 2016) et que vous tentez d’exécuter un conteneur avec une version d’image 10.0.16299.* (Windows Server version 1709), le service de calcul du système d’exploitation retourne une erreur d’incompatibilité de version.
Restrictions de Windows Server 2016
Les conteneurs basés sur Windows Server 2016 ne s’exécutent pas dans un système où les numéros de révision de l’hôte du conteneur et de l’image conteneur diffèrent. Par exemple, si la version de l’hôte du conteneur est 10.0.14393.1914 (Windows Server 2016 avec la mise à jour KB4051033) et celle de l’image du conteneur est 10.0.14393.1944 (Windows Server 2016 avec la mise à jour KB4053579), l’image risque de ne pas démarrer.
Pour les hôtes ou les images utilisant Windows Server version 1809 et ultérieure, cette règle ne s’applique pas : l’hôte et l’image conteneur n’ont pas besoin de révisions correspondantes.
Notes
Nous vous recommandons vivement de mettre à jour votre hôte et vos conteneurs avec les correctifs et mises à jour les plus récents pour rester sécurisé et compatible. Pour obtenir des instructions importantes sur la mise à jour des conteneurs Windows, consultez Mettre à jour les conteneurs Windows Server.
Application pratique
Exemple 1 : L’hôte du conteneur exécute Windows Server 2016 avec la mise à jour KB4041691 appliquée. Tout conteneur Windows Server déployé sur cet hôte doit être basé sur la version 10.0.14393.1770 des images de base du conteneur. Si vous appliquez la mise à jour KB4053579 au conteneur hôte, vous devez également mettre à jour les images pour vous assurer que le conteneur hôte les prend en charge.
Exemple 2 : l’hôte du conteneur exécute Windows Server, version 1809 avec la mise à jour KB4534273. Tout conteneur Windows Server déployé sur cet hôte doit être basé sur une image de base de conteneur de Windows Server, version 1809 (10.0.17763), mais sa mise à jour KB ne doit pas nécessairement correspondre à celle de l’hôte. Si la mise à jour KB4534273 est appliquée à l’hôte, les images de conteneur sont toujours prises en charge, mais nous vous recommandons de les mettre à jour pour prévenir tout problème de sécurité potentiel.
Interrogation de la version
Méthode 1 : introduite dans la version 1709, l’invite de commandes et la commande ver retournent désormais les informations de révision.
Microsoft Windows [Version 10.0.16299.125]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\>ver
Microsoft Windows [Version 10.0.16299.125]
Méthode 2 : interrogez la clé de Registre suivante : HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
Par exemple :
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
Pour vérifier la version que votre image de base utilise, examinez les balises sur le Docker Hub ou la table de hachage d’image fournie dans la description de l’image. La page Historique des mises à jour de Windows 10 répertorie la date de publication de chaque build et révision.
Isolation Hyper-V pour les conteneurs
Vous pouvez exécuter les conteneurs Windows avec ou sans isolation Hyper-V. L’isolation Hyper-V crée une limite sécurisée autour du conteneur avec un ordinateur virtuel optimisé. Contrairement aux conteneurs Windows standard qui partagent le noyau avec l’hôte, chaque conteneur isolé Hyper-V dispose de sa propre instance du noyau Windows. Cela signifie que vous pouvez avoir des versions du système d’exploitation différentes dans l’hôte et dans l’image du conteneur (pour plus d’informations, consultez la matrice de compatibilité suivante).
Pour exécuter un conteneur ayant une isolation Hyper-V, ajoutez simplement la balise --isolation=hyperv à votre commande docker run.
Erreurs en cas d’incompatibilité des versions
Si vous tentez d’exécuter une combinaison non prise en charge, vous obtiendrez l’erreur suivante :
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}.
Vous pouvez résoudre cette erreur de trois façons :
- Reconstruire le conteneur en vous basant sur la version correcte de
mcr.microsoft.com/microsoft-windows-nanoserverou demcr.microsoft.com/windows/servercore. - Si l’hôte est plus récent, exécuter la commande docker run --isolation=hyperv ... .
- Tenter d’exécuter le conteneur sur un autre hôte avec la même version de Windows.
Choisir la version du système d’exploitation du conteneur à utiliser
Remarque
Depuis le 16 avril 2019, la balise « latest » n’est plus publiée ni maintenue pour les images de conteneurs du système d’exploitation de base Windows Server, Windows Server Core et Nano Server. Vous devez déclarer une balise spécifique lors de l’extraction ou du référencement d’images à partir de ces référentiels.
Vous devez connaître la version à utiliser pour votre conteneur. Par exemple, si vous voulez que le système d’exploitation de votre conteneur soit Windows Server, version 1809, et souhaitez obtenir les derniers correctifs applicables à cette version, vous devez utiliser la balise 1809 lorsque vous spécifiez la version des images du conteneur du système d’exploitation de base de votre choix comme suit :
FROM mcr.microsoft.com/windows/nanoserver:1809
...
Toutefois, si vous souhaitez appliquer un correctif spécifique de Windows Server, version 1809, vous pouvez spécifier le numéro de mise à jour KB dans la balise. Par exemple, pour obtenir l’image du conteneur du système d’exploitation de base Nano Server de Windows Server, version 1809 avec la mise à jour KB4493509, vous devez le spécifier comme suit :
FROM mcr.microsoft.com/windows/nanoserver:1809-KB4493509
...
Vous pouvez également spécifier les correctifs exacts dont vous avez besoin avec le schéma utilisé précédemment en spécifiant la version du système d’exploitation dans la balise :
FROM mcr.microsoft.com/windows/nanoserver:10.0.17763.437
...
Les images de base Server Core basées sur Windows Server 2022 et Windows Server 2019 sont des versions de Canal de maintenance à long terme (LTSC). Par exemple, si vous souhaitez que Windows Server 2019 soit le système d’exploitation du conteneur de votre image de Server Core et obtenir des derniers correctifs ad hoc, vous pouvez spécifier les mises en production du Canal de maintenance à long terme comme suit :
FROM mcr.microsoft.com/windows/servercore:ltsc2019
...
Correspondance des versions à l’aide de Docker Swarm
Docker Swarm n’inclut pas actuellement de méthode intégrée pour faire correspondre la version de Windows qu’un conteneur utilise à un hôte de la même version. Si vous mettez à jour le service pour utiliser un conteneur plus récent, celui-ci s’exécute correctement.
Si vous devez exécuter plusieurs versions de Windows pendant une longue période de temps, vous avez le choix entre deux approches : configurer les hôtes Windows pour qu’ils utilisent toujours l’isolation Hyper-V, ou utiliser des contraintes d’étiquette.
Recherche d’un service qui ne démarre pas
Si un service ne démarre pas, vous verrez que le MODE est replicated, mais que le nombre REPLICAS sera bloqué sur 0. Pour voir si le problème résulte de la version du système d’exploitation, utilisez les commandes suivantes :
Exécutez la commande docker service ls pour trouver le nom du service :
ID NAME MODE REPLICAS IMAGE PORTS
xh6mwbdq2uil angry_liskov replicated 0/1 windows/servercore/iis
Exécutez la commande docker service ps (nom du service) pour connaître l’état et les dernières tentatives :
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…"
Si vous voyez le message starting container failed: ..., vous pouvez voir l’erreur complète avec la commande docker service ps --no-trunc (nom du conteneur) :
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}"
Il s’agit de la même erreur que CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101).
Correctif : mettre à jour le service pour utiliser une version correspondante
Deux éléments sont à prendre en compte pour Docker Swarm. Si vous avez un fichier de composition disposant d’un service qui utilise une image que vous n’avez pas créée, vous pouvez mettre à jour la référence en conséquence. Par exemple :
version: '3'
services:
YourServiceName:
image: windows/servercore:1709
...
Vous devez également déterminer si l’image vers laquelle vous pointez est une image que vous avez créée (par exemple, contoso/myimage) :
version: '3'
services:
YourServiceName:
image: contoso/myimage
...
Dans ce cas, vous devez utiliser la méthode décrite dans Erreurs en cas d’incompatibilité des versions pour modifier ce fichier Dockerfile au lieu de la ligne docker-compose.
Atténuation : utiliser l’isolation Hyper-V avec Docker Swarm
Les conteneurs Windows prennent en charge l’utilisation de l’isolation Hyper-V en fonction de chaque conteneur, ce qui nécessite de modifier la configuration du service Docker, puis de redémarrer le moteur Docker.
Modifiez
C:\ProgramData\docker\config\daemon.json.Ajoutez une ligne contenant
"exec-opts":["isolation=hyperv"].Notes
Le fichier daemon.json n’existe pas par défaut. Si, après vérification dans le répertoire, cela s’avère être effectivement le cas, vous devez créer le fichier. Vous pouvez ensuite y copier ce qui suit :
{ "exec-opts":["isolation=hyperv"] }Fermez et enregistrez le fichier, puis redémarrez le moteur Docker en exécutant les cmdlets suivantes dans PowerShell :
Stop-Service docker Start-Service dockerUne fois avoir redémarré le service, lancez vos conteneurs. Une fois ceux-ci en cours d’exécution, vous pouvez vérifier le niveau d’isolation d’un conteneur en inspectant ce dernier avec la cmdlet suivante :
docker inspect --format='{{json .HostConfig.Isolation}}' $instanceNameOrId
Soit « process », soit « hyperv » sera renvoyé. Si vous avez modifié et défini votre fichier daemon.json comme décrit ci-dessus, il doit indiquer cette dernière éventualité.
Atténuation : utiliser des étiquettes et des contraintes
Voici comment utiliser des étiquettes et des contraintes pour faire correspondre les versions :
Ajouter des étiquettes à chaque nœud.
Sur chaque nœud, ajoutez deux étiquettes :
OSetOsVersion. Cela suppose une exécution locale, mais pouvez modifier cela afin de les définir sur un hôte distant.docker node update --label-add OS="windows" $ENV:COMPUTERNAME docker node update --label-add OsVersion="$((Get-ComputerInfo).OsVersion)" $ENV:COMPUTERNAMEPar la suite, vous pourrez vérifier les étiquettes en exécutant la commande docker node inspect, qui doit afficher les étiquettes ajoutées récemment :
"Spec": { "Labels": { "OS": "windows", "OsVersion": "10.0.16296" }, "Role": "manager", "Availability": "active" }Ajoutez une contrainte de service.
À présent que vous avez étiqueté chaque nœud, vous pouvez mettre à jour les contraintes qui déterminent l’emplacement des services. Dans l’exemple suivant, remplacez « contoso_service » par le nom de votre service réel :
docker service update \ --constraint-add "node.labels.OS == windows" \ --constraint-add "node.labels.OsVersion == $((Get-ComputerInfo).OsVersion)" \ contoso_serviceCela applique et limite l’emplacement d’exécution d’un nœud.
Pour plus d’informations sur l’utilisation de contraintes de service, consultez la service create reference.
Correspondance des version à l’aide de Kubernetes
Le problème décrit dans Correspondance des versions à l’aide de Docker Swarm peut se produire lorsque des pods sont planifiés dans Kubernetes. Vous pouvez éviter ce problème à l’aide de stratégies similaires :
- Reconstruisez le conteneur en utilisant la même version du système d’exploitation en développement et en production. Pour savoir comment procéder, consultez Choisir la version du système d’exploitation du conteneur à utiliser.
- Utilisez des étiquettes de nœud et des sélecteurs de nœuds pour vous assurer que les pods sont planifiés sur des nœuds compatibles si les nœuds de Windows Server 2016 et de Windows Server, version 1709 se trouvent dans le même cluster.
- Utilisez des clusters distincts en fonction de la version du système d’exploitation
Échec de la recherche des pods en raison de l’incompatibilité des systèmes d’exploitation
Dans ce cas, un déploiement incluait un pod qui était planifié sur un nœud dont la version du système d’exploitation était incompatible, et sur lequel l’isolation Hyper-V n’était pas activée.
Le même message d’erreur s’affiche dans les événements répertoriés, avec kubectl describe pod <podname>. Après plusieurs tentatives, l’état du pod sera probablement 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
Atténuation – utilisation d’étiquettes de nœud et de sélecteur de nœud
Exécutez la commande kubectl get node pour obtenir la liste de tous les nœuds. Après cela, vous pouvez exécuter la commande kubectl describe node (nom de nœud) pour obtenir plus de détails.
Dans l’exemple suivant, deux nœuds Windows exécutent des versions différentes :
$ 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
...
Utilisons cet exemple pour montrer comment faire correspondre les versions :
Prenez note de chaque nom de nœud et de la valeur
Kernel Versiondans les informations système.Dans notre exemple, les informations se présentent comme suit :
Nom Version 38519acs9010 14393.1715.amd64fre.rs1_release_inmarket.170906-1810 38519acs9011 16299.0.amd64fre.rs3_release.170922-1354 Ajoutez à chaque nœud une étiquette appelée
beta.kubernetes.io/osbuild. Windows Server 2016 a besoin que les versions majeure et mineure (14393.1715 dans cet exemple) soient prises en charge sans isolation Hyper-V. Windows Server, version 1709 a seulement besoin que la version majeure (16299 dans cet exemple) corresponde.Dans cet exemple, la commande pour l’ajout des étiquettes ressemble à ceci :
$ kubectl label node 38519acs9010 beta.kubernetes.io/osbuild=14393.1715 node "38519acs9010" labeled $ kubectl label node 38519acs9011 beta.kubernetes.io/osbuild=16299 node "38519acs9011" labeledVérifiez la présence des étiquettes en exécutant la commande kubectl get nodes --show-labels.
Dans cet exemple, la sortie doit ressembler à ceci :
$ 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=masterAjoutez des sélecteurs de nœuds aux déploiements. Dans cet exemple, nous allons ajouter un
nodeSelectorà la spécification de conteneur avecbeta.kubernetes.io/os= windows etbeta.kubernetes.io/osbuild= 14393.* ou 16299 pour assurer la correspondance avec le système d’exploitation de base que le conteneur utilise.Voici un exemple complet pour l’exécution d’un conteneur conçu pour 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: {}Le pod peut désormais lancer le déploiement mis à jour. Les sélecteurs de nœuds figurant également dans la commande
kubectl describe pod <podname>, vous pouvez utiliser celle-ci pour vérifier qu’ils ont été ajoutés.La sortie de notre exemple est la suivante :
$ 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