Kubernetes Networking Vocabulary: CNI, Services, Ingress, and Policies (англійською)

Мережа Kubernetes є номінально складною - і англійський словник, який описує її, може бути настільки ж залякуваним. Інженери, які не можуть точно назвати, що вони мають на увазі (ClusterIP проти безголової служби, правило вхідного сигналу проти правила вихідного сигналу, режим iptables проти eBPF), сповільнюють кожну дискусію про архітектуру, в якій вони беруть участь. Цей посібник надає вам словниковий запас, який допоможе вам безпечно робити внесок.

Лаєр CNI

CNI (Container Network Interface) — це стандартний інтерфейс, який Kubernetes використовує для налаштування мережі підсистем. CNI плагін є реалізацією - Calico, Cilium, Flannel, і Weave Net є найбільш поширеними. Додаток CNI відповідає за присвоєння IP- адрес підсистемам і налаштування мережевих маршрутів, які надають підсистемам змогу спілкуватися між собою.

** Подова мережа ** в Kubernetes слідує за плоскою моделлю мережі: кожен под отримує свою власну IP-адресу, і поди можуть спілкуватися один з одним безпосередньо через вузли — без NAT. Цей параметр називається pod CIDR (діапазон IP- адрес, що зарезервовано для підсистем). Кластер також має service CIDR — діапазон IP, який використовується для IP-адрес віртуальних служб.

Інженери обговорюють CNI плагіни при вирішенні проблем з’єднання: * “Нові вузли не приєднуються до мережі правильно - перевірте, чи працює CNI plugin daemonset на цих вузлах.” *

Типи послуг

** Служба Kubernetes ** є стабільною кінцевою точкою мережі, яка балансує трафік до набору підсистем. Існує чотири основних типи служб:

• ** ClusterIP ** — типове значення; служба доступна лише всередині кластера, на віртуальному IP. * “Службою бази даних є ClusterIP — вона не доступна поза кластером.” *
• ** NodePort ** — показує службу на статичному порту на IP- адресі кожного вузла. Корисний для розробки, але рідко використовується у виробництві.
• ** LoadBalancer ** — забезпечує зовнішній балансувальник навантаження (зазвичай, балансувальник навантаження хмарного провайдера) і призначає службі публічний IP- адресу.
• ** ExternalName ** — відображає службу у зовнішній DNS, що дозволяє підсистемам використовувати DNS- назву служби Kubernetes для доступу до зовнішніх служб.

Безголова служба є службою ClusterIP з clusterIP: None. За допомогою цього пункту не створюється віртуальний IP- адреса; замість цього DNS повертає окремі IP- адреси підсистем безпосередньо. Цей параметр використовується для завантажень з показом стану (наприклад, баз даних), де клієнтам потрібно з’ єднатися з певними екземплярами.

Вхід і управління рухом

Ingress є ресурсом Kubernetes, який визначає правила маршрутизації HTTP — відображення доменных імен і URL-адрес до серверних служб. Контролер вхідних даних є програмним забезпеченням, яке реалізує ці правила - NGINX Ingress Controller, Traefik і AWS Load Balancer Controller є популярними виборами. ** IngressClass ** вказує, який контролер Ingress має обробляти даний ресурс Ingress (користовується, якщо встановлено декілька контролерів).

Інженери кажуть: “Нове правило Ingress не маршрутизується правильно — перевірте, чи відповідає анотація IngressClass розгорнутому контролеру.”

Правила мережі і DNS

** NetworkPolicy ** це ресурс Kubernetes, який керує тим, які підсистеми можуть спілкуватися з іншими підсистемами і кінцевими точками. У ньому визначено правила вхідного трафіку (хто може надсилати трафік до підсистеми) і правила вихідного трафіку (де підсистема може надсилати трафік). Без параметра NetworkPolicies всі підсистеми кластера можуть спілкуватися з усіма іншими підсистемами, що є значним ризиком для безпеки.

“Ми застосовуємо мережеву модель нульового довіри — кожен простір імен має типовий параметр NetworkPolicy-deny, а служби повинні явно дозволяти потрібний їм трафік.”

CoreDNS — це DNS-сервер, який працює в Kubernetes. Він розв’ язує назви служб до їх кластерних IP- адрес. Конвенція DNS Kubernetes є <service-name>.<namespace>.svc.cluster.local. Крос-просторове обмін інформацією вимагає використання повної назви DNS: “Фронт-енд служба в веб-просторі імен не може досягти аутентифікації служби в просторі імен платформи за допомогою короткої назви вузла — використовуйте повне кваліфіковане ім’я.”

** kube- proxy ** — компонент, який реалізує балансування навантаження служб на кожному вузлі. Він працює або в ** iptables режимі ** (традиційний підхід, використовуючи правила брандмауера ядра) або ** режимі eBPF ** (використовуючи Cilium eBPF-засновану площину даних, яка швидша і більш спостережлива). Команди, що переходять на Cilium обговорюють: “Перехід з iptables на режим eBPF зменшив нашу затримку налаштування з’єднання на 40%.”

Сервісна мережа

Service mesh додає шар інфраструктури для обміну даними між службами — обробка mTLS, формування трафіку, повторні спроби і спостережливість. ** Введення бічного контейнера ** — це механізм, за допомогою якого мережа служб автоматично додає проксі- контейнер (бічний контейнер) до кожного поду. У Istio це проксі- сервер Envoy; зазвичай, введення керується за допомогою мітки простору імен.

• “Увімкніть введення sidecar у просторі імен платежів перед розгортанням нової служби — вона має бути частиною мережі, щоб mTLS працював.” *

Наступні кроки

Виберіть з цієї статті одну з концепцій мережі, яку ви вважаєте найменш інтуїтивно зрозумілою, і розгорніть невеликий тест у локальному кластері (мінікуб або подібний кластер). Створіть два підпрограми у різних просторах імен, напишіть NetworkPolicy і перевірте зміну з’ єднання за допомогою kubectl exec і curl. Потім описайте, що ви побудували англійською мовою — використовуючи словниковий запас з цієї статті — колегі або у записці.

На практиці: Навігація дискусій навколо Service Discovery

Будьмо чесними – іноді розуміння точно того, що колега має на увазі в обговоренні Kubernetes, може відчувати себе як розшифровування секретного коду. Це не тільки самі технічні терміни; це також те, як ці терміни використовуються, і тонкі нюанси фразування. Це особливо стосується розробників, чия перша мова не є англійською, і які швидко вивчають конкретний словник, який став стандартом у світі хмарних мов.

Я переглядав запит на витягання минулого тижня, де розробник створив нову службу, що викриває кінцеву точку API. У описі PR використано фразу « служба повинна бути доступною з * всіх * підсистем у просторі імен ». Спочатку я не був впевнений, що саме означає « всі ». Виявляється, вони хотіли, щоб його викрито через службу Kubernetes типу ClusterIP. Краще було б сказати « служба має бути доступною зі всіх підсистем у просторі імен за допомогою служби ClusterIP ». Це підкреслює важливу річ: слово « доступний » може мати різні конотації — чи є вона просто доступною, чи є вона * легко * доступною? Чим більш конкретним буде ваш вираз, тим менше буде непорозумінь. Інший поширений сценарій включає обговорення про виявлення послуг. Розробники можуть сказати: «Ми повинні переконатися, що CoreDNS правильно налаштований, щоб сервіси могли автоматично знаходити один одного». Це не просто технічна інструкція; це визнання ролі CoreDNS в Kubernetes - дії як центрального реєстру для всіх назв сервісів і їх пов’язаних IP-адрес. Це розуміння процесу, що стоїть за пошуком правильної служби, а не тільки самого інструмента.

Крім того, розгляньте це повідомлення Slack, яке я отримав: « Привіт, команда, чи хтось має проблеми з маршрутизацією трафіку до нової мікросервісу? Ми бачимо періодичні падіння з’ єднання.” Підставне питання тут не просто “чи є проблеми?” Це запит на дослідження * як * трафік маршрутизується - можливо, включаючи правила Ingress, налаштування Сервісу, або навіть NetworkPolicies. Точна мова допомагає вам швидко визначити джерело проблеми. Використання фраз на зразок « періодичні перепади з’ єднання » набагато корисніше, ніж нечітке твердження про « проблеми з’ єднання ». Це вказує на очікування і направляє зусилля по усуненню несправностей.

kubectl get svc my-service -n my-namespace

Ця проста команда, яку використовують для перевірки деталей служби, є повсякденним інструментом для підтвердження налаштувань і розуміння того, як Kubernetes керує доступом до мережі. Це не просто про запуск команди; це про * інтерпретацію * виводу - зауважте ClusterIP адресу, номери портів і селекторів, які визначають, які піди можуть спілкуватися з цією службою. Знання цих деталей дозволить вам безпечно брати участь у обговореннях і ефективно сприяти роботі вашої команди.