Мережа у Windows

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

Мережа контейнерів у Windows

Мережа для контейнерів Windows надається через втулки CNI. Контейнери Windows працюють подібно до віртуальних машин з погляду мережі. Кожен контейнер має віртуальний мережевий адаптер (vNIC), підключений до віртуального комутатора Hyper-V (vSwitch). Host Networking Service (HNS) та Host Compute Service (HCS) спільно створюють контейнери й підключають vNIC контейнерів до мереж. HCS відповідає за керування контейнерами, а HNS — за керування мережевими ресурсами, такими як:

• Віртуальні мережі (зокрема створення vSwitches)
• Точки доступу / vNIC
• Namespaces
• Політики, зокрема інкапсуляція пакетів, правила балансування навантаження, ACL та правила NAT.

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:

Як зазначено вище, втулок 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:

• Pod → Pod (IP)
• Pod → Pod (імʼя)
• Pod → Service (кластерний IP)
• Pod → Service (PQDN, але лише якщо немає ".")
• Pod → Service (FQDN)
• Pod → зовнішній (IP)
• Pod → зовнішній (DNS)
• Node → Pod
• Pod → Node

Керування IP-адресами (IPAM)

У Windows підтримуються такі варіанти IPAM:

• host-local
• azure-vnet-ipam (лише для azure-cni)
• IPAM Windows Server (запасний варіант, якщо IPAM не встановлено)

Пряме повернення до сервера (DSR)

Режим балансування навантаження, у якому виправлення IP-адрес і LBNAT відбуваються безпосередньо на порту vSwitch контейнера; трафік сервісу надходить з IP-адресою джерела, що дорівнює IP-адресі вихідного Podʼа. Це оптимізує продуктивність, дозволяючи зворотному трафіку, що маршрутизується через балансувальники навантаження, оминати балансувальник і відповідати безпосередньо клієнту; це зменшує навантаження на балансувальник і загальну затримку. Докладніше читайте в Direct Server Return (DSR) in a nutshell.

Балансування навантаження та Services

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

• NodePort
• ClusterIP
• LoadBalancer
• ExternalName

Мережа контейнерів Windows у деяких важливих аспектах відрізняється від мережі Linux. Документація Microsoft про мережу контейнерів Windows містить додаткові подробиці та контекст.

У Windows можна використовувати такі налаштування для конфігурації Services та поведінки балансування навантаження:

Обмеження

Така мережева функціональність не підтримується на вузлах Windows:

• Режим мережі хоста
• Локальний доступ до NodePort із самого вузла (працює для інших вузлів або зовнішніх клієнтів)
• Понад 64 Podʼи-бекенди (або унікальні адреси призначення) для одного Service
• Звʼязок IPv6 між Podʼами Windows, підключеними до оверлейних мереж
• Local Traffic Policy в режимі без DSR
• Вихідний звʼязок за протоколом ICMP через win-overlay, win-bridge або за допомогою втулка Azure-CNI. Зокрема, площина даних Windows (VFP) не підтримує транспозицію пакетів ICMP, і це означає:
  • Пакети ICMP, спрямовані до призначень у тій самій мережі (наприклад, звʼязок між Podʼами через ping), працюють як очікується;
  • TCP/UDP-пакети працюють, як очікується;
  • Пакети ICMP, спрямовані через віддалену мережу (наприклад, звʼязок Podʼа із зовнішнім інтернетом через ping), не можуть бути транспоновані, тому не маршрутизуються назад до свого джерела;
  • Оскільки TCP/UDP-пакети все ще можуть бути транспоновані, під час налагодження звʼязку із зовнішнім світом ви можете замінити ping <destination> на curl <destination>.

Інші обмеження:

• Еталонні мережеві втулки Windows win-bridge та win-overlay не реалізують специфікацію CNI v0.4.0 через відсутність реалізації CHECK.
• Втулок CNI Flannel VXLAN має такі обмеження у Windows:
  • Звʼязок між вузлом і Podʼом можливий лише для локальних Podʼів із Flannel v0.12.0 (або новішим).
  • Flannel обмежений використанням VNI 4096 та UDP-порту 4789. Докладніше про ці параметри див. в офіційній документації бекенда Flannel VXLAN.