Мережеві аспекти Windows
Kubernetes підтримує використання як вузлів Linux, так і Windows, і можливе одночасне використання обох типів вузлів у межах одного кластеру. Ця сторінка надає огляд мережевих аспектів, специфічних для операційної системи Windows.
Мережева взаємодія контейнерів у Windows
Мережевий стек для контейнерів у Windows використовує CNI-втулки. Контейнери у Windows працюють схоже до віртуальних машин з погляду мережі. Кожен контейнер має віртуальний мережевий адаптер (vNIC), який підключений до віртуального комутатора Hyper-V (vSwitch). Host Networking Service (HNS) та Host Compute Service (HCS) спільно працюють для створення контейнерів і підключення віртуальних мережевих адаптерів контейнера до мереж. HCS відповідає за управління контейнерами, тоді як HNS відповідає за управління ресурсами мережі, такими як:
- Віртуальні мережі (включаючи створення vSwitches)
- Endpoint / vNIC
- Namespaces
- Політика, включаючи інкапсуляцію пакетів, правила балансування навантаження, ACL, та правила NAT.
Windows HNS та vSwitch реалізують простір імен та можуть створювати віртуальні мережеві адаптери за потреби для 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. У таблиці нижче наведено втулки, що не є частиною Kubernetes, які підтримуються у Windows, з рекомендаціями щодо використання кожного CNI:
| Драйвер мережі | Опис | Модифікації контейнерних пакетів | Втулки мережі | Характеристики втулків мережі |
|---|---|---|---|---|
| L2bridge | Контейнери підключені до зовнішнього vSwitch. Контейнери підключені до мережі нижнього рівня, хоча фізична мережа не повинна знати 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 | Включено тут для повноти. |
Як вказано вище, Flannel CNI plugin також підтримується у Windows через VXLAN мережевий бекенд (Бета-підтримка; делегує до win-overlay) та host-gateway мережевий бекенд (стабільна підтримка; делегує до win-bridge).
Цей втулок підтримує делегування до одного з втулків CNI за вибором користувача (win-overlay, win-bridge), для співпраці з демоном Flannel у Windows (Flanneld) для автоматичного присвоєння лізингу підмережі вузлу та створення мережі HNS. Цей втулок читає власний файл конфігурації (cni.conf) та агрегує його зі змінними середовища зі створеного FlannelD файлу subnet.env. Потім він делегує одному з втулків CNI для роботи з мережею, надсилаючи правильну конфігурацію, що містить призначену вузлом підмережу до IPAM-втулку (наприклад: host-local).
Для обʼєктів Node, Pod та Service підтримуються наступні потоки даних мережі для TCP/UDP-трафіку:
- Pod → Pod (IP)
- Pod → Pod (Імʼя)
- Pod → Сервіс (Кластерний IP)
- Pod → Сервіс (PQDN, але тільки якщо немає ".")
- Pod → Сервіс (FQDN)
- Pod → зовнішній (IP)
- Pod → зовнішній (DNS)
- Node → Pod
- Pod → Node
Управління IP-адресами (IPAM)
У Windows підтримуються наступні параметри IPAM:
- host-local
- azure-vnet-ipam (тільки для azure-cni)
- IPAM Windows Server (запасна опція, якщо не встановлено IPAM)
Балансування навантаження та Service
Service Kubernetes є абстракцією, яка визначає логічний набір Podʼів та засіб доступу до них мережею. У кластері, який включає вузли Windows, можна використовувати наступні типи Service:
NodePortClusterIPLoadBalancerExternalName
Мережева взаємодія контейнерів у Windows відрізняється в деяких важливих аспектах від мережі Linux. Документація Microsoft з мережевої взаємодії контейнерів у Windows надає додаткові відомості та контекст.
У Windows можна використовувати наступні налаштування для конфігурації Service та поведінки балансування навантаження:
| Функція | Опис | Мінімальна підтримувана версія Windows OS | Як ввімкнути |
|---|---|---|---|
| Подібність сесій (Session affinity) | Забезпечує, що підключення від певного клієнта передається тому самому Podʼу кожен раз. | Windows Server 2022 | Встановіть у service.spec.sessionAffinity значення "ClientIP" |
| Direct Server Return (DSR) | Режим балансування навантаження, де виправлення IP-адреси та LBNAT відбуваються на порту vSwitch контейнера напряму; трафік служби приходить з наблору вихідних IP, встановленого як IP походження Podʼу. | Windows Server 2019 | Встановіть наступні прапорці в kube-proxy: --feature-gates="WinDSR=true" --enable-dsr=true |
| Збереження-Призначення | Пропускає DNAT-трафік Servicʼу, тим самим зберігаючи віртуальну IP цільового Service в пакетах, що досягають фронтенду Podʼа. Також вимикає пересилання вузол-вузол. | Windows Server, версія 1903 | Встановіть "preserve-destination": "true" в анотаціях служби та увімкніть DSR в kube-proxy. |
| Подвійний мережевий стек IPv4/IPv6 | Нативна підтримка IPv4-до-IPv4 поряд з IPv6-до-IPv6 комунікацією до, з і всередині кластера | Windows Server 2019 | Див. Підтримка подвійного стеку IPv4/IPv6 |
| Збереження IP клієнта | Забезпечує збереження джерела ingress трафіку. Також вимикає пересилання вузол-вузол. | Windows Server 2019 | Встановіть service.spec.externalTrafficPolicy у "Local" та увімкніть DSR в kube-proxy |
Попередження:
Існують відомі проблеми з Serviceʼами NodePort в мережі оверлея, якщо вузол призначення працює під управлінням Windows Server 2022. Щоб уникнути проблеми повністю, ви можете налаштувати Service з externalTrafficPolicy: Local.
Існують відомі проблеми зі зʼєднаннями Pod-Pod в режимі мережі l2bridge у Windows Server 2022 з KB5005619 або вище. Для усунення проблеми та відновлення зʼєднаності Pod-Pod ви можете вимкнути функцію WinDSR в kube-proxy.
Ці проблеми потребують виправлень в операційній системі. Будь ласка, слідкуйте за https://github.com/microsoft/Windows-Containers/issues/204 для отримання оновлень.
Обмеження
Наступні функції мережі не підтримуються на вузлах Windows:
- Режим мережі хосту
- Локальний доступ NodePort з вузла (працює для інших вузлів або зовнішніх клієнтів)
- Більше 64 бекенд-Podʼів (або унікальних адрес призначення) для одного Service
- Зв'язок IPv6 між Pods Windows, підключеними до мереж оверлея
- Local Traffic Policy в режимі без DSR
- Вихідна комунікація за допомогою протоколу ICMP через
win-overlay,win-bridge, або використовуючи втулок Azure-CNI. Зокрема панель даних Windows (VFP) не підтримує ICMP-перетворення пакетів, і це означає:- Пакети ICMP, спрямовані до пунктів призначення в одній мережі (наприклад, звʼязок Pod-Pod за допомогою ping), працюють належним чином;
- TCP/UDP-пакети працюють, як очікується;
- Пакети ICMP, спрямовані на проходження через віддалену мережу (наприклад, Pod-зовнішньої точки в інтернет через ping), не можуть бути перенесені та, таким чином, не будуть перенаправлені назад до свого джерела;
- Оскільки TCP/UDP-пакети все ще можуть бути перетворені, ви можете замінити
ping <destination>наcurl <destination>при налагодженні зʼєднаності з зовнішнім світом.
Інші обмеження:
- Референсні мережеві втулки Windows, такі як win-bridge та win-overlay, не мають реалізації специфікації CNI v0.4.0, через відсутність реалізації
CHECK. - Втулок Flannel VXLAN має наступні обмеження на Windows:
- Зʼєднаність Node-Pod можлива лише для локальних Podʼів з Flannel v0.12.0 (або вище).
- Flannel обмежений використанням VNI 4096 та UDP-порту 4789. Див. офіційну Flannel VXLAN документацію про бекенд Flannel VXLAN щодо цих параметрів.