Контейнери Windows у Kubernetes

Застосунки Windows становлять значну частину сервісів та застосунків, що працюють у багатьох організаціях. Контейнери Windows дають змогу інкапсулювати процеси та пакувати залежності, що спрощує використання практик DevOps і дотримання патернів cloud native для застосунків Windows.

Організаціям, що інвестували в застосунки на базі Windows і Linux, не потрібно шукати окремі оркестратори для керування своїми робочими навантаженнями, що підвищує операційну ефективність їхніх розгортань незалежно від операційної системи.

Вузли Windows у Kubernetes

Щоб увімкнути оркестрування контейнерів Windows у Kubernetes, додайте вузли Windows до вашого наявного кластера Linux. Планування контейнерів Windows у Podʼах у Kubernetes подібне до планування контейнерів на базі Linux.

Щоб запускати контейнери Windows, ваш кластер Kubernetes має містити кілька операційних систем. Хоча панель управління можна запускати лише на Linux, ви можете розгортати робочі вузли, що працюють як на Windows, так і на Linux.

Вузли Windows підтримуються за умови, що операційною системою є Windows Server 2022 або Windows Server 2025.

У цьому документі термін контейнери Windows означає контейнери Windows з ізоляцією на рівні процесів. Kubernetes не підтримує запуск контейнерів Windows з ізоляцією Hyper-V.

Сумісність та обмеження

Деякі можливості вузлів доступні лише за використання певного середовища виконання контейнерів; інші недоступні на вузлах Windows, зокрема:

• HugePages: не підтримуються для контейнерів Windows
• Привілейовані контейнери: не підтримуються для контейнерів Windows. Контейнери HostProcess пропонують схожу функціональність.
• TerminationGracePeriod: вимагає containerD

Підтримуються не всі можливості спільних просторів імен. Докладніше дивіться в розділі Сумісність API.

Докладніше про версії Windows, з якими тестується Kubernetes, дивіться в розділі Сумісність версій операційної системи Windows.

З точки зору API та kubectl контейнери Windows поводяться майже так само, як контейнери на базі Linux. Проте існують деякі помітні відмінності в ключовій функціональності, описані в цьому розділі.

Порівняння з Linux

Ключові елементи Kubernetes працюють у Windows так само, як і в Linux. У цьому розділі описано кілька ключових абстракцій робочих навантажень і те, як вони відображаються у Windows.

• Podʼи

  Pod — це базовий будівельний блок Kubernetes: найменша та найпростіша одиниця в обʼєктній моделі Kubernetes, яку ви створюєте або розгортаєте. Не можна розгортати контейнери Windows і Linux в одному Podʼі. Усі контейнери в Podʼі плануються на один вузол, де кожен вузол представляє певну платформу та архітектуру. З контейнерами Windows підтримуються такі можливості, властивості та події Podʼа:

  • Один або кілька контейнерів на Pod з ізоляцією процесів та спільним використанням томів

  • Поля status Podʼа

  • Проби готовності, життєздатності та запуску

  • Хуки життєвого циклу контейнера postStart та preStop

  • ConfigMap, Secrets: як змінні середовища або томи

  • Томи emptyDir

  • Монтування іменованих каналів хоста

  • Обмеження ресурсів

  • Поле OS:

    Значення поля .spec.os.name має бути встановлено у windows, щоб вказати, що поточний Pod використовує контейнери Windows.

    Якщо ви встановлюєте поле .spec.os.name у windows, ви не повинні встановлювати такі поля в .spec цього Podʼа:

    • spec.hostPID
    • spec.hostIPC
    • spec.securityContext.seLinuxOptions
    • spec.securityContext.seccompProfile
    • spec.securityContext.fsGroup
    • spec.securityContext.fsGroupChangePolicy
    • spec.securityContext.sysctls
    • spec.shareProcessNamespace
    • spec.securityContext.runAsUser
    • spec.securityContext.runAsGroup
    • spec.securityContext.supplementalGroups
    • spec.containers[*].securityContext.seLinuxOptions
    • spec.containers[*].securityContext.seccompProfile
    • spec.containers[*].securityContext.capabilities
    • spec.containers[*].securityContext.readOnlyRootFilesystem
    • spec.containers[*].securityContext.privileged
    • spec.containers[*].securityContext.allowPrivilegeEscalation
    • spec.containers[*].securityContext.procMount
    • spec.containers[*].securityContext.runAsUser
    • spec.containers[*].securityContext.runAsGroup

    У наведеному вище списку символи підстановки (*) позначають усі елементи списку. Наприклад, spec.containers[*].securityContext стосується обʼєкта SecurityContext для всіх контейнерів. Якщо вказано будь-яке з цих полів, API-сервер не прийме цей Pod.

• Ресурси робочих навантажень, зокрема:

  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job
  • CronJob
  • ReplicationController

• Services. Докладніше дивіться в розділі Балансування навантаження та Services.

Podʼи, ресурси робочих навантажень та Services є критично важливими елементами для керування робочими навантаженнями Windows у Kubernetes. Однак самі по собі вони недостатні для належного керування життєвим циклом робочих навантажень Windows у динамічному середовищі cloud native.

• kubectl exec
• Метрики Podʼів та контейнерів
• Горизонтальне автомасштабування Podʼів
• Квоти ресурсів
• Витіснення планувальником

Параметри командного рядка для kubelet

Деякі параметри командного рядка kubelet поводяться у Windows інакше, як описано нижче:

• Параметр --windows-priorityclass дозволяє встановлювати пріоритет планування процесу kubelet (див. Керування ресурсами CPU)
• Прапорці --kube-reserved, --system-reserved та --eviction-hard оновлюють NodeAllocatable
• Виселення за допомогою --enforce-node-allocable не реалізовано
• Під час роботи на вузлі Windows kubelet не має обмежень памʼяті або CPU. --kube-reserved та --system-reserved лише віднімаються від NodeAllocatable і не гарантують ресурсів для робочих навантажень. Докладніше дивіться в розділі Керування ресурсами для вузлів Windows.
• Стан PIDPressure не реалізовано
• kubelet не вживає дій щодо виселення через OOM

Сумісність API

Існують тонкі відмінності в роботі API Kubernetes для Windows, зумовлені ОС та середовищем виконання контейнерів. Деякі властивості робочих навантажень було розроблено для Linux, і вони не працюють у Windows.

На високому рівні відрізняються такі концепції ОС:

• Ідентичність — Linux використовує ідентифікатор користувача (UID) та ідентифікатор групи (GID), які подаються як цілі числа. Імена користувачів і груп не є канонічними — це лише псевдоніми для UID+GID у /etc/groups або /etc/passwd. Windows використовує довший двійковий ідентифікатор безпеки (SID), який зберігається в базі даних Windows Security Access Manager (SAM). Ця база даних не є спільною між хостом і контейнерами або між контейнерами.
• Права доступу до файлів — Windows використовує список керування доступом на основі (SID), тоді як POSIX-системи, такі як Linux, використовують бітову маску на основі дозволів обʼєкта та UID+GID, а також необовʼязкові списки керування доступом.
• Шляхи до файлів — у Windows прийнято використовувати \ замість /. Бібліотеки вводу-виводу Go зазвичай приймають обидва варіанти й просто забезпечують їхню роботу, але коли ви задаєте шлях або командний рядок, що інтерпретується всередині контейнера, може знадобитися \.
• Сигнали — інтерактивні застосунки Windows обробляють завершення інакше і можуть реалізовувати один або кілька таких механізмів:
  • UI-потік обробляє чітко визначені повідомлення, зокрема WM_CLOSE.
  • Консольні застосунки обробляють Ctrl-C або Ctrl-break за допомогою обробника керування (Control Handler).
  • Служби реєструють функцію обробника керування службою (Service Control Handler), яка може приймати коди керування SERVICE_CONTROL_STOP.

Коди виходу контейнера дотримуються тієї самої домовленості: 0 означає успіх, а ненульове значення — помилку. Конкретні коди помилок у Windows та Linux можуть відрізнятися. Однак коди виходу, які передають компоненти Kubernetes (kubelet, kube-proxy), залишаються незмінними.

Сумісність полів для специфікацій контейнера

У цьому списку наведено відмінності в роботі специфікацій контейнерів Podʼа між Windows та Linux:

• Великі сторінки (huge pages) не реалізовані в середовищі виконання контейнерів Windows і недоступні. Вони потребують наявності привілею користувача, який не налаштовується для контейнерів.
• requests.cpu та requests.memory — запити віднімаються від доступних ресурсів вузла, тому їх можна використовувати, щоб уникнути надмірного виділення ресурсів вузла. Проте вони не можуть гарантувати ресурси на вузлі з надмірно виділеними ресурсами. Як найкращу практику їх слід застосовувати до всіх контейнерів, якщо оператор хоче повністю уникнути надмірного виділення ресурсів.
• securityContext.allowPrivilegeEscalation — неможливо у Windows; жодні можливості (capabilities) не підключені
• securityContext.capabilities — можливості POSIX (capabilities) не реалізовані у Windows
• securityContext.privileged — Windows не підтримує привілейовані контейнери, замість них використовуйте Контейнери HostProcess
• securityContext.procMount — Windows не має файлової системи /proc
• securityContext.readOnlyRootFilesystem — неможливо у Windows; для роботи реєстру та системних процесів усередині контейнера потрібен доступ на запис
• securityContext.runAsGroup — неможливо у Windows, оскільки немає підтримки GID
• securityContext.runAsNonRoot — це налаштування перешкоджатиме запуску контейнерів як ContainerAdministrator, який є найближчим еквівалентом користувача root у Windows.
• securityContext.runAsUser — використовуйте runAsUserName замість цього
• securityContext.seLinuxOptions — неможливо у Windows, оскільки SELinux специфічний для Linux
• terminationMessagePath — тут є певні обмеження, оскільки Windows не підтримує зіставлення окремих файлів. Стандартне значення — /dev/termination-log, і воно працює, бо цей шлях стандартно не існує у Windows.

Сумісність полів для специфікацій Podʼа

У цьому списку наведено відмінності в роботі специфікацій Podʼа між Windows та Linux:

• hostIPC та hostpid — спільне використання простору імен хоста неможливе у Windows
• hostNetwork — використання мережі хоста неможливе у Windows
• dnsPolicy — встановлення dnsPolicy Podʼа на ClusterFirstWithHostNet не підтримується у Windows, оскільки мережа хоста не надається. Podʼи завжди працюють з мережею контейнера.
• podSecurityContext див. нижче
• shareProcessNamespace — це бета-можливість, яка залежить від просторів імен Linux, не реалізованих у Windows. Windows не може спільно використовувати простори імен процесів або кореневу файлову систему контейнера. Спільною може бути лише мережа.
• terminationGracePeriodSeconds — це не повністю реалізовано в Docker у Windows, див. issue на GitHub. Наразі процес ENTRYPOINT отримує CTRL_SHUTDOWN_EVENT, потім Windows стандартно чекає 5 секунд і нарешті завершує всі процеси звичайним для Windows способом вимкнення. Стандартні 5 секунд насправді задані в реєстрі Windows усередині контейнера, тому їх можна перевизначити під час збирання контейнера.
• volumeDevices — це бета-можливість, яка не реалізована у Windows. Windows не може підключати сирі блочні пристрої до Podʼів.
• volumes
  • Якщо ви визначаєте том emptyDir, ви не можете встановити для нього джерело memory.
• Ви не можете увімкнути mountPropagation для монтування томів, оскільки це не підтримується у Windows.

Доступ до мережі хоста

Kubernetes від v1.26 до v1.32 містив альфа-підтримку запуску Podʼів Windows у мережевому просторі імен хоста.

Kubernetes v1.37 не містить функціональної можливості WindowsHostNetwork і не підтримує запуск Podʼів Windows у мережевому просторі імен хоста.

Сумісність полів для контексту безпеки Podʼа

Лише поля securityContext.runAsNonRoot та securityContext.windowsOptions із полів securityContext Podʼа працюють у Windows.

Виявлення проблем вузла

Механізм виявлення проблем вузла (див. Моніторинг справності вузла) має попередню підтримку для Windows. Для отримання додаткової інформації відвідайте сторінку проєкту на GitHub.

Контейнер pause

У Podʼі Kubernetes спочатку створюється інфраструктурний контейнер, або контейнер «pause», щоб розмістити контейнер. У Linux для cgroups та просторів імен, що утворюють Pod, потрібен процес, який підтримує їхнє подальше існування; цей процес забезпечує pause. Контейнери, які належать до одного Podʼа, зокрема інфраструктурні та робочі контейнери, мають спільну мережеву кінцеву точку (та сама адреса IPv4 та/або IPv6, ті самі простори мережевих портів). Kubernetes використовує контейнери pause, щоб робочі контейнери могли аварійно завершуватися або перезапускатися без втрати мережевої конфігурації.

Kubernetes супроводжує багатоархітектурний образ із підтримкою Windows. Для Kubernetes v1.37.0 рекомендований образ pause — registry.k8s.io/pause:3.6. Вихідний код доступний на GitHub.

Microsoft супроводжує інший багатоархітектурний образ із підтримкою Linux та Windows amd64, який можна знайти як mcr.microsoft.com/oss/kubernetes/pause:3.6. Цей образ зібрано з того самого вихідного коду, що й образ, який супроводжує Kubernetes, але всі бінарні файли Windows підписані authenticode компанією Microsoft. Проєкт Kubernetes рекомендує використовувати образ, який супроводжує Microsoft, якщо ви розгортаєте у промисловому або подібному до промислового середовищі, що потребує підписаних бінарних файлів.

Середовища виконання контейнерів

Вам потрібно встановити середовище виконання контейнерів на кожний вузол у кластері, щоб Podʼи могли там працювати.

Із Windows працюють такі середовища виконання контейнерів:

ContainerD

Ви можете використовувати ContainerD версії 1.4.0+ як середовище виконання контейнерів для вузлів Kubernetes, які працюють на Windows.

Дізнайтеся, як встановити ContainerD на вузол Windows.

Mirantis Container Runtime

Mirantis Container Runtime (MCR) доступне як середовище виконання контейнерів для всіх версій Windows Server 2019 та новіших.

Для отримання додаткової інформації дивіться Встановлення MCR на серверах Windows.

Сумісність версій операційної системи Windows

На вузлах Windows діють суворі правила сумісності: версія операційної системи хоста повинна збігатися з версією операційної системи базового образу контейнера.

Для Kubernetes v1.37 сумісність операційних систем для вузлів Windows (та Podʼів) така:

Випуск LTSC Windows Server

Windows Server 2022

Windows Server 2025

Також застосовується політика версійної розбіжності Kubernetes.

Рекомендації та важливі аспекти апаратного забезпечення

• 64-бітний процесор із 4 ядрами CPU або більше, здатний підтримувати віртуалізацію
• 8 GB або більше оперативної памʼяті
• 50 GB або більше вільного місця на диску

Найновішу інформацію про мінімальні апаратні вимоги дивіться на сторінці Вимоги до апаратного забезпечення для Windows Server у документації Microsoft. Рекомендації щодо вибору ресурсів для промислових робочих вузлів дивіться в розділі Промислові робочі вузли в документації Kubernetes.

Для оптимізації ресурсів системи, якщо графічний інтерфейс не потрібен, може бути краще використовувати інсталяцію Windows Server без варіанта встановлення Windows Desktop Experience, оскільки така конфігурація зазвичай звільняє більше ресурсів системи.

Оцінюючи дисковий простір для робочих вузлів Windows, врахуйте, що образи контейнерів Windows зазвичай більші за образи контейнерів Linux: розмір одного образу становить від 300 MB до понад 10 GB. Крім того, зверніть увагу, що диск C: у контейнерах Windows стандартно має віртуальний вільний розмір 20 GB: це не фактично зайнятий простір, а розмір диска, до якого може вирости один контейнер під час використання локального сховища на хості. Докладніше дивіться на сторінці Контейнери у Windows — документація про сховище контейнерів.

Отримання допомоги та усунення несправностей

Основним джерелом допомоги з усунення несправностей у вашому кластері Kubernetes має бути сторінка Усунення несправностей.

Додаткову допомогу з усунення несправностей, специфічну для Windows, наведено в цьому розділі. Логи є важливою складовою усунення несправностей у Kubernetes. Обовʼязково додавайте їх щоразу, коли звертаєтеся по допомогу до інших учасників. Дотримуйтесь інструкцій у настановах щодо збору логів від SIG Windows.

Повідомлення про проблеми та запити на нові можливості

Якщо у вас є щось схоже на помилку або ви хочете подати запит на нову можливість, дотримуйтесь настанов для учасників SIG Windows, щоб створити новий issue. Спочатку перегляньте список issues на випадок, якщо про проблему вже повідомляли, і додайте коментар про свій досвід та додаткові логи. Канал SIG Windows у Slack Kubernetes також є чудовим способом отримати початкову підтримку та ідеї щодо усунення несправностей перед створенням issue.

Перевірка правильності роботи кластера Windows

Проєкт Kubernetes надає специфікацію Windows Operational Readiness разом зі структурованим набором тестів. Цей набір поділено на дві групи тестів, базову та розширену, кожна з яких містить категорії, спрямовані на тестування конкретних областей. Його можна використовувати для перевірки всієї функціональності системи Windows та гібридної системи (разом із вузлами Linux) з повним покриттям.

Щоб налаштувати проєкт на щойно створеному кластері, дивіться інструкції в посібнику проєкту.

Інструменти розгортання

Інструмент kubeadm допомагає розгортати кластер Kubernetes, надаючи панель управління для керування кластером та вузли для запуску ваших робочих навантажень.

Проєкт Kubernetes cluster API також надає засоби для автоматизації розгортання вузлів Windows.

Канали поширення Windows

Для докладного пояснення каналів поширення Windows дивіться документацію Microsoft.

Інформацію про різні канали обслуговування Windows Server, зокрема їхні моделі підтримки, можна знайти на сторінці Канали обслуговування Windows Server.