Kubernetes підтримує роботу вузлів як на Linux, так і на Windows. Ви можете поєднувати обидва види вузлів в одному кластері. На цій сторінці наведено огляд мережевих аспектів, специфічних для операційної системи Windows.
Мережа для контейнерів Windows надається через втулки CNI. Контейнери Windows працюють подібно до віртуальних машин з погляду мережі. Кожен контейнер має віртуальний мережевий адаптер (vNIC), підключений до віртуального комутатора Hyper-V (vSwitch). Host Networking Service (HNS) та Host Compute Service (HCS) спільно створюють контейнери й підключають vNIC контейнерів до мереж. HCS відповідає за керування контейнерами, а HNS — за керування мережевими ресурсами, такими як:
HNS та vSwitch у Windows реалізують простори імен і можуть за потреби створювати віртуальні NIC для Podʼа чи контейнера. Однак багато конфігурацій, таких як DNS, маршрути та метрики, зберігаються в базі даних реєстру Windows, а не у файлах в /etc, як у Linux. Реєстр Windows контейнера відокремлений від реєстру хоста, тому такі прийоми, як зіставлення /etc/resolv.conf з хоста в контейнер, не дають того ефекту, що в Linux. Це потрібно налаштовувати за допомогою API Windows, що виконуються в контексті цього контейнера. Тому реалізації CNI повинні викликати HNS, а не покладатися на зіставлення файлів, щоб передавати мережеві дані в Pod чи контейнер.
Windows підтримує пʼять різних мережевих драйверів/режимів: L2bridge, L2tunnel, Overlay (Beta), Transparent та NAT. У гетерогенному кластері з робочими вузлами Windows і Linux потрібно вибрати мережеве рішення, сумісне і з Windows, і з Linux. У таблиці нижче наведено зовнішні (out-of-tree) втулки, які підтримуються у Windows, з рекомендаціями щодо використання кожного CNI:
| Мережевий драйвер | Опис | Зміни пакетів контейнерів | Мережеві втулки | Характеристики мережевих втулків |
|---|---|---|---|---|
| L2bridge | Контейнери підключені до зовнішнього vSwitch. Контейнери підключені до базової мережі (underlay), хоча фізичній мережі не потрібно знати MAC-адреси контейнерів, оскільки вони переписуються на вході та виході. | MAC переписується на MAC хоста, IP може бути переписаний на IP хоста за допомогою політики HNS OutboundNAT. | win-bridge, Azure-CNI, Flannel host-gateway використовує win-bridge | win-bridge використовує режим мережі L2bridge, підключає контейнери до базової мережі хостів і забезпечує найкращу продуктивність. Потребує маршрутів, визначених користувачем (UDR), для звʼязку між вузлами. |
| L2Tunnel | Це особливий випадок l2bridge, який використовується лише в Azure. Усі пакети надсилаються на хост віртуалізації, де застосовується політика SDN. | MAC переписується, IP видно в базовій мережі | Azure-CNI | Azure-CNI дозволяє інтегрувати контейнери з Azure vNET і дає їм змогу використовувати набір можливостей, які надає Azure Virtual Network. Наприклад, безпечно підключатися до сервісів Azure або використовувати NSG Azure. Див. azure-cni, де є кілька прикладів |
| Overlay | Контейнерам надається vNIC, підключений до зовнішнього vSwitch. Кожна оверлейна мережа отримує власну IP-підмережу, визначену власним IP-префіксом. Драйвер оверлейної мережі використовує інкапсуляцію VXLAN. | Інкапсулюється із зовнішнім заголовком. | win-overlay, Flannel VXLAN (використовує win-overlay) | win-overlay слід використовувати, коли віртуальні мережі контейнерів потрібно ізолювати від базової мережі хостів (наприклад, з міркувань безпеки). Дозволяє повторно використовувати IP-адреси для різних оверлейних мереж (які мають різні теґи VNID), якщо у вашому центрі обробки даних обмаль IP-адрес. Цей варіант потребує KB4489899 у Windows Server 2019. |
| Transparent (особливий випадок для ovn-kubernetes) | Потребує зовнішнього vSwitch. Контейнери підключені до зовнішнього vSwitch, що забезпечує взаємодію всередині Podʼа через логічні мережі (логічні комутатори та маршрутизатори). | Пакет інкапсулюється через тунелювання GENEVE або STT, щоб досягти Podʼів, які не перебувають на тому самому хості. Пакети пересилаються або відкидаються на основі метаданих тунелю, які надає мережевий контролер ovn. NAT виконується для трафіку північ-південь. | ovn-kubernetes | Розгортається за допомогою ansible. Розподілені ACL можна застосовувати за допомогою політик Kubernetes. Підтримка IPAM. Балансування навантаження можливе без kube-proxy. NAT виконується без використання iptables/netsh. |
| NAT (не використовується в Kubernetes) | Контейнерам надається vNIC, підключений до внутрішнього vSwitch. DNS/DHCP надається внутрішнім компонентом, який називається WinNAT | MAC та IP переписуються на MAC/IP хоста. | nat | Наведено тут для повноти |
Як зазначено вище, втулок CNI Flannel також підтримується у Windows через мережевий бекенд VXLAN (бета-підтримка; делегує до win-overlay) та мережевий бекенд host-gateway (стабільна підтримка; делегує до win-bridge).
Цей втулок підтримує делегування одному з еталонних втулків CNI (win-overlay, win-bridge) для спільної роботи з демоном Flannel у Windows (Flanneld), щоб автоматично призначати оренду підмережі вузла та створювати мережу HNS. Цей втулок читає власний файл конфігурації (cni.conf) і обʼєднує його зі змінними середовища з файлу subnet.env, згенерованого FlannelD. Потім він делегує налаштування мережі одному з еталонних втулків CNI й надсилає правильну конфігурацію з призначеною вузлу підмережею до втулка IPAM (наприклад, host-local).
Для обʼєктів Node, Pod та Service підтримуються такі мережеві потоки для трафіку TCP/UDP:
У Windows підтримуються такі варіанти IPAM:
This is a stable feature in Kubernetes, and has been since version v1.34. It was first available in the v1.14 release. You can no longer disable or opt out of this feature or behavior (it is locked); if you explicitly set a value for the associated feature gate WinDSR, Kubernetes ignores it but does not report any error.
Режим балансування навантаження, у якому виправлення IP-адрес і LBNAT відбуваються безпосередньо на порту vSwitch контейнера; трафік сервісу надходить з IP-адресою джерела, що дорівнює IP-адресі вихідного Podʼа. Це оптимізує продуктивність, дозволяючи зворотному трафіку, що маршрутизується через балансувальники навантаження, оминати балансувальник і відповідати безпосередньо клієнту; це зменшує навантаження на балансувальник і загальну затримку. Докладніше читайте в Direct Server Return (DSR) in a nutshell.
Service Kubernetes — це абстракція, яка визначає логічний набір Podʼів і спосіб доступу до них мережею. У кластері з вузлами Windows можна використовувати такі типи Service:
NodePortClusterIPLoadBalancerExternalNameМережа контейнерів Windows у деяких важливих аспектах відрізняється від мережі Linux. Документація Microsoft про мережу контейнерів Windows містить додаткові подробиці та контекст.
У Windows можна використовувати такі налаштування для конфігурації Services та поведінки балансування навантаження:
| Можливість | Опис | Мінімальна підтримувана збірка ОС Windows | Як увімкнути |
|---|---|---|---|
| Спорідненість сесії (session affinity) | Гарантує, що підключення від певного клієнта щоразу передаються тому самому Podʼу. | Windows Server 2022 | Встановіть service.spec.sessionAffinity у "ClientIP" |
| Direct Server Return (DSR) | Див. примітки про DSR вище. | Windows Server 2019 | Встановіть такий аргумент командного рядка (для версії 1.37): --enable-dsr=true |
| Preserve-Destination | Пропускає DNAT трафіку сервісу, зберігаючи віртуальну IP-адресу цільового сервісу в пакетах, що досягають Podʼа-бекенда. Також вимикає пересилання між вузлами. | Windows Server, версія 1903 | Встановіть "preserve-destination": "true" в анотаціях сервісу та увімкніть DSR у kube-proxy. |
| Двостекова мережа IPv4/IPv6 | Нативний звʼязок IPv4-IPv4 паралельно зі звʼязком IPv6-IPv6 до кластера, з нього та всередині нього | Windows Server 2019 | Див. Подвійний стек IPv4/IPv6 |
| Збереження IP клієнта | Гарантує збереження IP-адреси джерела вхідного трафіку. Також вимикає пересилання між вузлами. | Windows Server 2019 | Встановіть service.spec.externalTrafficPolicy у "Local" та увімкніть DSR у kube-proxy |
Така мережева функціональність не підтримується на вузлах Windows:
win-overlay, win-bridge або за допомогою втулка Azure-CNI. Зокрема, площина даних Windows (VFP) не підтримує транспозицію пакетів ICMP, і це означає:ping <destination> на curl <destination>.Інші обмеження:
CHECK.