Megosztás a következőn keresztül:


Windows-tároló verziókompatibilitása

A következőkre vonatkozik: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

A Windows Server 2016 és a Windows 10 évfordulós frissítése (mindkét verzió: 14393) volt az első Windows-kiadás, amely Windows Server-tárolókat tudott létrehozni és futtatni. Az ezekből a verziókból készült tárolók újabb kiadásokon is futtathatók, de a kezdés előtt néhány dolgot tudnia kell.

A Windows architektúrája nagymértékben eltér a Linux architektúrájától. A Linux monolitikus kernelrel rendelkezik, míg Windows felhasználó és kernel módban szorosabban kötődik. A tárolók bevezetéséig a Windows-felhasználó és a kernel mód szinkronban lett szállítva, ami a Windows tárolókompatibilitási követelményeit eredményezte, amelyek eltérnek a Linuxban megszokottól.

A Felhasználó/Kernel határának leválasztása a Windowsban monumentális feladat, és rendkívül nem triviális, azonban keményen dolgoztunk azon, hogy stabilizáljuk ezt a határt az összes Windowsban, hogy az ügyfeleink számára rugalmasságot biztosítsunk az alacsonyabb szintű tárolók futtatásához. A Windows 11-től és a Windows Server 2022-től kezdve lehetővé tesszük a folyamat által izolált WS2022-tárolók futtatását Windows 11-gazdagépeken. Mindent megtettünk, hogy rögzítsük a határt átlépő területeket, de most meg szeretnénk nyitni a funkciót a Windows 11 fejlesztőinek visszajelzés céljából. Elkötelezettek vagyunk a felhasználói élmény engedélyezése mellett, ezért kérjük, tudassa velünk, ha problémákat tapasztal.

Bármely más forgatókönyv esetében, ahol a gazdagép/vendég Windows verziószámozási kompatibilitása nem egyezik a felhasználó/kernel mód között, lehetséges, de nem garantált, így a tárolólemezkép nem fog futni a gazdagépen. A nem egyező verziók esetén az Hyper-V elkülönítéssel futtatva a tároló egyező Kernel bináris fájlok készletét biztosítja, és nem függ a gazdagép verziójától. Részletes kompatibilitási mátrixért tekintse meg az alábbi táblázatokat.

A Windows Server gazdagép operációs rendszerének kompatibilitása

Tároló alaprendszer képének operációs rendszer verziója Támogatja a Hyper-V elkülönítését Támogatja a folyamatelkülönítést
Windows Server 2025
Windows Server 2022
Windows Server 2019
Windows Server 2016

Windows-ügyfél gazdagép operációs rendszerének kompatibilitása

Tároló alaprendszer képének operációs rendszer verziója Támogatja a Hyper-V elkülönítését Támogatja a folyamatelkülönítést
Windows Server 2025 1 1
Windows Server 2022
Windows Server 2019
Windows Server 2016
  1. A Windows 11 24H2 (Build 2600) verziótól kezdve támogatott.

Megjegyzés:

A Windows 10 1809-es és a Windows Server 2019-es verziója jelenleg ugyanazzal a buildszámmal rendelkezett. Azóta független frissítéseket kaptak, ami a buildszám eltérését eredményezte. A Windows-ügyfélhez elérhető folyamatok elkülönítése előzetes verzióban elérhető Windows 11 rendszeren, Windows Server 2022 képekkel – a verziószám nem egyezik. Ha a folyamat elkülönített tárolóinak Windows 10-en való futtatására van szüksége, kérjük, tudassa velünk a GitHub problémáit.

A konténergazda verziójának egyeztetése a konténerkép-verziókkal

Windows Server-tárolók

Buildszám (a Windows új kiadása)

A Windows operációs rendszer négy verziószámozási szinttel rendelkezik: főverzió, alverzió, build és változat. A 10.0.14393.103-es verzió például a 10 főverzióval, a 0-s alverzióval, az 14393-es buildszámmal és a 103-es verziószámmal rendelkezik. A buildszám csak az operációs rendszer új verzióinak közzétételekor változik, és a verziószám a Windows-frissítések alkalmazásakor frissül.

A WS2022 + Windows 11 kivételével a Windows Server-tárolók nem indulnak el, ha a tároló gazdagép és a tárolórendszerkép közötti buildszám eltérő. Ha például a tárológazda 10.0.14393.* verziójú (Windows Server 2016), és megpróbál futtatni egy tárolót a 10.0.16299.* (Windows Server, 1709-es verzió) rendszerképpel, az operációs rendszer számítási szolgáltatása verziókompatibilitási hibát ad vissza.

A Windows Server 2016 korlátozásai

A Windows Server 2016-alapú tárolók nem futnak olyan rendszerben, ahol a tároló gazdagépének és a tárolólemezképnek a változatszáma eltérő. Ha például a konténer gazdagépe a 10.0.14393.1914 (Windows Server 2016, KB4051033 alkalmazva) verzió, és a konténer képfájlja a 10.0.14393.1944 (Windows Server 2016, KB4053579 alkalmazva) verzió, akkor előfordulhat, hogy a lemezkép nem indul el.

A Windows Server 1809-es vagy újabb verzióját használó gazdagépek vagy konténerképek esetében ez a szabály nem érvényes – a gazdagépnek és a konténerképnek nem kell egyező revíziókat használnia.

Megjegyzés:

Határozottan javasoljuk, hogy frissítse mind a gazdagépét, mind a tárolóit a legújabb javításokkal és frissítésekkel a biztonság és a megfelelőség megőrzése érdekében. A Windows-tárolók frissítésének fontos útmutatását a Windows Server-tárolók frissítése című témakörben talál.

Gyakorlati alkalmazás

1. példa: A tárológazda Windows Server 2016 rendszert futtat, KB4041691 alkalmazva. A gazdagéphez üzembe helyezett Windows Server-tárolóknak a 10.0.14393.1770-es verziójú tároló alaprendszerképeken kell alapulniuk. Ha a KB4053579-et alkalmazza a gazdagép konténerre, akkor frissítenie kell a képeket is annak biztosítására, hogy a gazdagép konténer támogassa azokat.

2. példa: A tároló gazdagép a Windows Server 1809-es verzióját futtatja KB4534273 alkalmazva. A gazdagépen üzembe helyezett Windows Server-tárolóknak a Windows Server 1809-es (10.0.17763-os) tároló alaprendszerképén kell alapulnia, de nem kell megegyezniük a gazdagép tudásbázisával. Ha a KB4534273 frissítést alkalmazzák a gazdagépre, a konténerképek továbbra is támogatottak maradnak, de javasoljuk, hogy frissítse őket az esetleges biztonsági problémák megoldása érdekében.

Verzió lekérdezése

1. módszer: Az 1709-es verzióban bevezetett cmd parancssor és ver parancs most megadja a verzió részleteit.

Microsoft Windows [Version 10.0.16299.125]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\>ver

Microsoft Windows [Version 10.0.16299.125]

2. módszer: A következő beállításkulcs lekérdezése: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

Például:

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

Az alapkép verziójának ellenőrzéséhez tekintse át a Docker Hubon található címkéket vagy a kép leírásában található képkivonat-táblát. A Windows 10 frissítési előzményoldala felsorolja, hogy mikor jelentek meg az egyes buildek és változatok.

A Hyper-V-izoláció a tárolók számára

Windows-tárolókat Hyper-V elkülönítéssel vagy anélkül is futtathat. Hyper-V elkülönítés biztonságos határt hoz létre a tároló körül egy optimalizált virtuális géppel. Ellentétben a standard Windows-tárolókkal, amelyek a kernelt a tárolók és a gazdagép között osztják meg, minden Hyper-V izolált tároló saját Windows-kernelpéldányt használ. Ez azt jelenti, hogy a tároló gazdagépében és rendszerképében különböző operációsrendszer-verziók is lehetnek (további információkért tekintse meg a következő kompatibilitási mátrixot).

Ha tárolót szeretne futtatni Hyper-V elkülönítéssel, egyszerűen adja hozzá a címkét --isolation=hyperv a docker-futtatási parancshoz.

Nem egyező verziók hibái

Ha nem támogatott kombinációt próbál futtatni, a következő hibaüzenet jelenik meg:

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

A hiba megoldásának három módja van:

  • A tárolót a megfelelő mcr.microsoft.com/microsoft-windows-nanoserver vagy mcr.microsoft.com/windows/servercore verzió alapján építse újra.
  • Ha a gazdagép újabb, futtassa a docker run parancsot --isolation=hyperv ...
  • Próbálja meg futtatni a tárolót egy másik gazdagépen ugyanazzal a Windows-verzióval

A használni kívánt tároló operációs rendszer verziójának kiválasztása

Megjegyzés:

2019. április 16-tól a "legújabb" címke már nem lesz közzétéve vagy karbantartva a Windows Server, a Windows Server Core és a Nano Server alap operációsrendszer-tárolólemezképeihez. Ha képeket kér le vagy hivatkozik ezekről az adattárakról, deklarálnia kell egy adott címkét.

Tudnia kell, hogy melyik verziót kell használnia a tárolóhoz. Ha például a Windows Server 1809-es verzióját szeretné tároló operációs rendszerként használni, és a legújabb javításokat szeretné használni, akkor a címkét 1809 kell használnia az alap operációsrendszer-tárolólemezképek kívánt verziójának megadásakor, például:

FROM mcr.microsoft.com/windows/nanoserver:1809
...

Ha azonban a Windows Server 1809-es verziójának egy adott javítására van szüksége, a címkén megadhatja a KB-számot. Ha például le szeretne kérni egy Nano Server-alapú operációs rendszer-tárolóképet a Windows Server 1809-es verziójából, amelyre a KB4493509 került alkalmazásra, a következőképpen adja meg:

FROM mcr.microsoft.com/windows/nanoserver:1809-KB4493509
...

Megadhatja a korábban használt sémához szükséges pontos javításokat is, ha megadja az operációs rendszer verzióját a címkén:

FROM mcr.microsoft.com/windows/nanoserver:10.0.17763.437
...

A Windows Server 2022-n és a Windows Server 2019-en alapuló Server Core alaprendszerképek Long-Term Karbantartási csatorna (LTSC) kiadásai. Ha például a Windows Server 2019-et szeretné a Server Core rendszerkép tároló operációs rendszerének tekinteni, és a legújabb javításokat szeretné használni, az LTSC-kiadásokat a következőképpen adhatja meg:

FROM mcr.microsoft.com/windows/servercore:ltsc2019
...

Egyező verziók a Docker Swarm használatával

A Docker Swarm jelenleg nem rendelkezik beépített módszerrel arra, hogy a tárolók által használt Windows-verziót illessze az azonos verziójú gazdagépekhez. Ha újabb tároló használatára frissíti a szolgáltatást, az sikeresen lefut.

Ha hosszú ideig több Windows-verziót kell futtatnia, két módszert alkalmazhat: vagy konfigurálja a Windows-gazdagépeket, hogy mindig Hyper-V elkülönítést használjon, vagy használjon címkekorlátozásokat.

Nem induló szolgáltatás megkeresése

Ha egy szolgáltatás nem indul el, látni fogja, hogy az MODEreplicated, de a REPLICAS 0-nál megakad. Annak megtekintéséhez, hogy az operációs rendszer verziója a probléma, futtassa a következő parancsokat:

Futtassa a docker service ls parancsot a szolgáltatásnév megkereséséhez:

ID                  NAME                MODE                REPLICAS            IMAGE                                             PORTS
xh6mwbdq2uil        angry_liskov        replicated          0/1                 windows/servercore/iis

Futtassa a docker service ps (szolgáltatásnév) parancsot az állapot és a legújabb kísérletek lekéréséhez:

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…"

Ha megjelenik starting container failed: ..., láthatja a teljes hibát a docker service ps --no-trunc (tároló neve) paranccsal:

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}"

Ez ugyanaz a hiba, mint a CreateContainer: failure in a Windows system call: The operating system of the container does not match the operating system of the host. (0xc0370101).

Javítás – A szolgáltatás frissítése egyező verzió használatára

A Docker Swarmnak két szempontja van. Abban az esetben, ha egy olyan összeállítási fájllal rendelkezik, amely olyan szolgáltatással rendelkezik, amely egy olyan képet használ, amelyet nem Ön hozott létre, frissítenie kell a referencia hivatkozást ennek megfelelően. Például:

version: '3'

services:
  YourServiceName:
    image: windows/servercore:1709
...

A másik szempont az, ha a rámutató kép egy saját maga által létrehozott kép (például contoso/myimage):

version: '3'

services:
  YourServiceName:
    image: contoso/myimage
...

Ebben az esetben az egyező verziók különbségeiből eredő hibák című részben leírt módszert kell használnia a docker-compose sor helyett a dockerfile módosításához.

Megoldás – Hyper-V elkülönítés használata a Docker Swarm használatával

A Windows-tárolók tárolónként támogatják Hyper-V elkülönítését, amelyhez módosítani kell a Docker szolgáltatás konfigurációját, majd újra kell indítani a Docker-motort.

  1. C:\ProgramData\docker\config\daemon.json szerkesztése

  2. Adjon hozzá egy sort "exec-opts":["isolation=hyperv"]-val

    Megjegyzés:

    A daemon.json fájl alapértelmezés szerint nem létezik. Ha úgy találja, hogy ez a helyzet, amikor betekint a könyvtárba, létre kell hoznia a fájlt. Ezután a következőket kell másolnia:

    {
        "exec-opts":["isolation=hyperv"]
    }
    
  3. Zárja be és mentse a fájlt, majd indítsa újra a Docker-motort a következő parancsmagok PowerShellben való futtatásával:

    Stop-Service docker
    Start-Service docker
    
  4. A szolgáltatás újraindítása után indítsa el a tárolókat. A futtatás után a tároló elkülönítési szintjét az alábbi parancsmaggal ellenőrizheti:

    docker inspect --format='{{json .HostConfig.Isolation}}' $instanceNameOrId
    

Vagy "folyamat", vagy "hyperv" értékét adja vissza. Ha módosította és beállította a daemon.json a fent leírtak szerint, az utóbbinak kell megjelennie.

Kockázatcsökkentés – Címkék és korlátozások használata

Az alábbiakban bemutatjuk, hogyan használhat címkéket és korlátozásokat a verziókhoz való igazodáshoz:

  1. Címkék hozzáadása minden csomóponthoz.

    Minden csomóponton adjon hozzá két címkét: OS és OsVersion. Ez azt feltételezi, hogy helyileg fut, azonban módosítható arra, hogy ehelyett egy távoli gazdagépen állítsák be őket.

    docker node update --label-add OS="windows" $ENV:COMPUTERNAME
    docker node update --label-add OsVersion="$((Get-ComputerInfo).OsVersion)" $ENV:COMPUTERNAME
    

    Ezt követően a Docker-csomópont vizsgálati parancsának futtatásával ellenőrizheti őket, amelynek az újonnan hozzáadott címkéket kell megjelenítenie:

           "Spec": {
                "Labels": {
                   "OS": "windows",
                   "OsVersion": "10.0.16296"
               },
                "Role": "manager",
                "Availability": "active"
            }
    
  2. Adjon hozzá egy szolgáltatáskorlátozást.

    Most, hogy felcímkézett minden csomópontot, frissítheti a szolgáltatások elhelyezését meghatározó korlátozásokat. Az alábbi példában cserélje le a "contoso_service" kifejezést a tényleges szolgáltatás nevére:

    docker service update \
        --constraint-add "node.labels.OS == windows" \
        --constraint-add "node.labels.OsVersion == $((Get-ComputerInfo).OsVersion)" \
        contoso_service
    

    Ez kikényszeríti és korlátozza, hogy a csomópontok hol futhatnak.

Ha többet szeretne megtudni a szolgáltatáskorlátozások használatáról, tekintse meg a szolgáltatás létrehozása referenciát.

Egyező verziók a Kubernetes használatával

A Docker Swarmot használó egyező verziókban ismertetett probléma akkor fordulhat elő, ha a podok a Kubernetesben vannak ütemezve. Ez a probléma hasonló stratégiákkal elkerülhető:

  • Építse újra a tárolót ugyanazon operációs rendszer verzió figyelembevételével a fejlesztési és az éles környezetben. További információ: Válassza ki, hogy melyik tároló operációsrendszer-verziót használja.
  • Csomópontcímkék és nodeSelector-ok használatával biztosítható, hogy a podok kompatibilis csomópontokon legyenek ütemezve, ha a Windows Server 2016 és a 1709-es verziójú Windows Server csomópontok ugyanabban a fürtben találhatók.
  • Különálló klaszterek használata az operációs rendszer verziója alapján

A podok keresése nem sikerült az operációs rendszer eltérése miatt

Ebben az esetben az üzembe helyezés tartalmazott egy podot, amelyet egy olyan csomópontra ütemeztek, ahol az operációs rendszer verziója nem felelt meg, és nem volt engedélyezve a Hyper-V elkülönítés.

Ugyanez a hiba jelenik meg a következővel felsorolt kubectl describe pod <podname>eseményekben: . Több kísérlet után a pod állapota valószínűleg az lesz 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

Megoldás – csomópontcímkék és nodeSelector használata

Futtassa a kubectl get node parancsot az összes csomópont listájának lekéréséhez. Ezután futtathatja a kubectl leíró csomópontot (csomópont nevét) a további részletekért.

Az alábbi példában két Windows-csomópont különböző verziókat futtat:

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

Az alábbi példában bemutatjuk, hogyan felelnek meg a verzióknak:

  1. Jegyezze fel az egyes csomópontneveket és a Kernel Version elemeket a rendszerinformációból.

    A példánkban az adatok a következőképpen fognak kinézni:

    Név verzió
    38519acs9010 14393.1715.amd64fre.rs1_release_inmarket.170906-1810
    38519acs9011 16299.0.amd64fre.rs3_release.170922-1354
  2. Adjon hozzá egy címkét az egyes csomópontok neveihez beta.kubernetes.io/osbuild. A Windows Server 2016-nak szüksége van mind a fő-, mind az alverziókra (például az 14393.1715-ös verzióra), hogy támogatva legyenek Hyper-V elkülönítés nélkül. A Windows Server 1709-es verziójának csak a főverzióra (ebben a példában az 16299-es verzióra) van szüksége.

    Ebben a példában a címkék hozzáadására szolgáló parancs a következőképpen néz ki:

    $ 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
    
    
  3. A kubectl get nodes --show-labels parancs futtatásával ellenőrizze a címkéket.

    Ebben a példában a kimenet a következőképpen fog kinézni:

    $ 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
    
  4. Csomópontválasztók hozzáadása a telepítésekhez. Ebben a példában hozzáadunk egy nodeSelector a tároló specifikációhoz, ahol beta.kubernetes.io/os = windows, és beta.kubernetes.io/osbuild = 14393.* vagy 16299, a tároló által használt alap operációs rendszernek megfelelően.

    Íme egy teljes példa a Windows Server 2016-hoz készült tároló futtatására:

    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: {}
    

    A pod mostantól megkezdheti a frissített üzembe helyezést. A csomópontválasztók is megjelennek, kubectl describe pod <podname>így a parancs futtatásával ellenőrizheti, hogy hozzáadták-e őket.

    A példánk kimenete a következő:

    $ 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