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

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

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

Windows-вузли у Kubernetes

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

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

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

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

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

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

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

Не всі функції спільних просторів імен підтримуються. Дивіться Сумісність API для детальнішої інформації.

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

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

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

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

• Podsʼи

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

  • Один або кілька контейнерів на 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 для всіх контейнерів. Якщо будь-яке з цих полів вказано, Pod не буде прийнято API сервером.

• [Ресурси робочих навантажень]](/docs/concepts/workloads/controllers/):

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

• Service. Дивіться Балансування навантаження та Service для деталей.

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

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

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

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

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

Сумісність API

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

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

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

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

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

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

• Великі сторінки не реалізовані в контейнері Windows та недоступні. Вони потребують встановлення привілеїв користувача, які не налаштовуються для контейнерів.
• requests.cpu та requests.memory — запити віднімаються від доступних ресурсів вузла, тому вони можуть використовуватися для уникнення перевстановлення вузла. Проте вони не можуть гарантувати ресурси в перевстановленому вузлі. Їх слід застосовувати до всіх контейнерів як найкращу практику, якщо оператор хоче уникнути перевстановлення повністю.
• securityContext.allowPrivilegeEscalation — неможливо на Windows; жодна з можливостей не підключена
• securityContext.capabilities — можливості POSIX не реалізовані у 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 — див. нижче
• dnsPolicy — встановлення dnsPolicy Podʼа на ClusterFirstWithHostNet не підтримується у Windows, оскільки мережа хосту не надається. Podʼи завжди працюють з мережею контейнера.
• podSecurityContext див. нижче
• shareProcessNamespace — це бета-функція, яка залежить від просторів імен Linux, які не реалізовані у Windows. Windows не може ділитися просторами імен процесів або кореневою файловою системою контейнера. Можлива лише спільна мережа.
• terminationGracePeriodSeconds — це не повністю реалізовано в Docker у Windows, див. тікет GitHub. Поведінка на сьогодні полягає в тому, що процес ENTRYPOINT отримує сигнал CTRL_SHUTDOWN_EVENT, потім Windows типово чекає 5 секунд, і нарешті вимикає всі процеси за допомогою звичайної поведінки вимкнення Windows. Значення 5 секунд визначаються в реєстрі Windows всередині контейнера, тому їх можна перевизначити при збиранні контейнера.
• volumeDevices — це бета-функція, яка не реалізована у Windows. Windows не може підключати блочні пристрої безпосередньо до Podʼів.
• volumes
  • Якщо ви визначаєте том emptyDir, ви не можете встановити його джерело тома на memory.
• Ви не можете активувати mountPropagation для монтування томів, оскільки це не підтримується у Windows.

Сумісність полів для hostNetwork

Тепер kubelet може вимагати, щоб Podʼи, що працюють на вузлах Windows, використовували мережевий простір імен хоста замість створення нового простору імен мережі Podʼа. Щоб увімкнути цю функціональність, передайте --feature-gates=WindowsHostNetwork=true в kubelet.

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

Тільки поля securityContext.runAsNonRoot та securityContext.windowsOptions з поля Podʼа securityContext працюють у Windows.

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

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

Контейнер паузи

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

Kubernetes підтримує багатоархітектурний образ, який включає підтримку для Windows. Для Kubernetes v1.31.0 рекомендований образ паузи — 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 діють строгі правила сумісності, де версія операційної системи хосту повинна відповідати версії операційної системи базового образу контейнера. Повністю підтримуються лише Windows контейнери з операційною системою контейнера Windows Server 2019.

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

Випуск LTSC Windows Server

Windows Server 2019

Windows Server 2022

Випуск SAC Windows Server

Windows Server версії 20H2

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

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

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

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

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

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

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

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

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

Повідомлення про проблеми та запити нових функцій

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

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

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

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

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

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

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

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

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

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