Англійська мова для Cilium Networking

Cilium вводить справді відмінну модель від традиційної мережі Kubernetes — безпека, заснована на ідентичності, замість правил, заснованих на IP, eBPF замість iptables — і використання старого словника для опису цього (назва Cilium ідентичності «IP allowlist») має тенденцію заплутати, а не прояснити обговорення.

Ключовий словник

** програма eBPF ** — невелика програма, що працює у пісочниці, яку Cilium завантажує у ядро Linux для обробки фільтрування пакетів, маршрутизації і спостереження без накладних витрат, які виникає від традиційних ланцюгів правил iptables. “Ми повністю відійшли від режиму iptables kube-proxy — програми eBPF Cilium обробляють маршрутизацію послуг безпосередньо в ядрі, саме тому ми побачили справжнє поліпшення затримки під час високої кількості з’єднань.”

CiliumNetworkPolicy (CNP) — розширений ресурс мережевої політики Cilium, який підтримує правила шару 7 (HTTP-методи, виклики gRPC) крім стандартного відповідання шару 3/4 Kubernetes NetworkPolicy. “Стандартна NetworkPolicy не може обмежити це лише запитами GET — нам потрібен CiliumNetworkPolicy, оскільки він вимагає фільтрування HTTP-знання шару 7.”

** Безпека на основі ідентифікатора ** — модель Cilium, яка призначає ідентифікаційний код безпеки групам підрозділів на основі міток, а не фільтрування за IP- адресами, отже правила залишаються правильними навіть після зміни розкладу підрозділів і IP- адрес. “Політика не була порушена під час розгортання, тому що Cilium застосовує її на основі ідентичності піду, а не IP — просте правило iptables, засноване на IP, потребувало б оновлення кожного разу, коли піди переплановувались.”

** Hubble ** — компонент спостереження Cilium, який надає змогу у реальному часі бачити потоки мережі, зокрема, які служби спілкуються між собою, і чи було дозволено або заборонено трафік за допомогою політики. “Замість того, щоб здогадуватися, чому трафік був зупинений, ми просто перевірили Хаббл і побачили, що точно поток був відмовлений, разом з конкретною політикою, яка відмовила йому.”

Cluster mesh — функція Cilium для з’єднання декількох кластерів Kubernetes в один мережевий домен, що дозволяє під-до-под комунікації і спільні мережеві правила через межі кластера. “Ми використовуємо кластерну мережу, щоб служба в кластері ЄС могла викликати службу в кластері США безпосередньо, з тими ж правилами, що базуються на ідентичності, які застосовуються в обох кластерах.”

Звичайні фрази

• «Чи це примушується на шарі 3/4 зі стандартною NetworkPolicy, або нам потрібен CiliumNetworkPolicy для фільтрування шару 7?»
• «Чи є політика, що ключиться на ідентичності под, або є застаріле IP-засноване правило, яке буде порушено при наступному переплануванні?»
• «Чи ми перевірили Хаббл, щоб побачити, чи цей трафік дійсно знижується за політикою, чи несправність відбувається деінде?»
• Чи це комунікація, що перетинає кластерну мережу, чи обидві служби в одному кластері?»
• «Чи ми запускаємо kube-proxy разом з Cilium тут, або він був повністю замінений на eBPF-засноване маршрутизацію послуг?»

Приклади висловлювань

Зневадження проблеми з’ єднання: “Транспорт беззвучно відкидався між цими двома службами — Hubble показав рішення про «відмову», вказуючи прямо на CiliumNetworkPolicy, в якій не було правила виходу для цього призначення.”

Пояснення рішення щодо розробки політики: “Ми написали це як CiliumNetworkPolicy замість стандартного NetworkPolicy, тому що нам потрібно було дозволити тільки виклики POST /webhook, що вимагає розуміння Шляху 7.”

Опис вибору архітектури:

• “Ми використовуємо кластерну мережу, щоб наші два регіональні кластери могли спільно використовувати правила, засновані на ідентифікації, безпосередньо, замість маршрутизації всього міжрегіонального трафіку через окремий шар шлюзу.” *

Професійні поради

• Розрізняти ** політику, засновану на ідентичності ** від правил, заснованих на IP, явно - це основна цінність Cilium, і замовчування її робить обговорення міграції менш переконливими.
• Досягайте до ** Hubble ** за назвою під час сеансу зневадження мережі, а не описуйте його як « панель приладів » — це вказує колегам по команді на певний, точний інструмент діагностики.
• Вкажіть вимоги шару 7 при обґрунтуванні CiliumNetworkPolicy над стандартним — інакше рецензенти можуть розумно запитати, чому вбудованого ресурсу Kubernetes було недостатньо.
• Назва ** кластер mesh ** безпосередньо в обговореннях архітектури про багатокластерний трафік - це специфічна функція з конкретними компромісами, а не просто “крос-кластерна мережа” в абстракції.

Практичні вправи

1. Поясніть різницю між безпекою мережі на основі ідентифікації та безпекою мережі на основі IP.
2. Описати, для чого використовується телескоп « Габбл » і чому він важливий під час мережевого інциденту.
3. Напишіть речення, у якому буде пояснено, коли потрібна CiliumNetworkPolicy замість стандартної NetworkPolicy.

Використання словника в кодовому перегляді

Поговоримо про те, як цей словник - особливо навколо мережевих правил і Хаббла - проявляється в типовому сценарії перегляду коду. Уявіть, що ви переглядаєте запит на звантаження, який вводить нове правило Cilium для обмеження вихідного трафіку з певної служби у вашому кластері програм. Опис PR згадує використання «примусового виконання політики» і посилання на «спостережливість Хаббла» для моніторингу. Під час перегляду ви можете побачити коментарі, подібні до наступних:

“@ розробник, чудове доповнення! Просто хотів попередити, що ми сильно покладаємося на ресурс NetworkPolicy тут. Давайте переконаємося, що ми маємо всеоб’ ємні метричні дані Hubble, налаштовані для відстеження трафіку, що проходить через цю політику - особливо зосереджуючись на вихідних з’ єднаннях. Важливо зрозуміти, чому це обмеження існує і чи відповідає воно нашій загальній позиції щодо безпеки. Чи можете ви додати коментар, у якому поясните причину блокування вихідного трафіку до [Назва зовнішньої служби]? Також, давайте переконаємося, що ми захоплюємо відповідні показники щодо ефективності політики - чи бачимо ми якісь несподівані шаблони трафіку? ”

Зауважте, як такі фрази, як «приведення в дію політики», «спостережливість Габбла» і запит на «всеосяжну метрику Габбла» безпосередньо пов’язані з словником, представленим в цій статті. Це не просто про те, щоб знати визначення; це про розуміння * як * ці концепції використовуються в контексті архітектури Cilium і мережі Kubernetes. Такий тип докладного зворотного зв’ язку є поширеним під час обговорення мережевих правил, особливо коли йдеться про складні розгортання, що включають декілька служб і суворих вимог безпеки. Метою є не просто сказати «політика правильна», а скоріше спільно оцінити її дизайн, впровадження і оперативний моніторинг. Крім того, проактивне запитання про метрику Хаббла демонструє прихильність до проактивної безпеки і усунення несправностей - ключових елементів професійної англійської мови в цій області.

Інша ситуація може виникнути під час розмов Slack з командою розробників щодо проблеми, позначених Hubble. Может, Хаббл обнаружил необычно высокий объем движения к определенному месту назначения, что вызвало уведомление. Розмова може бути приблизно такою: «Гей, команда, Hubble показує пік трафіку з нашого мікросервісу «OrderProcessor» до [External Payment Gateway]. Чи можемо ми дослідити, чи є неправильна конфігурація або несподіване збільшення попиту? ” Тут розуміння “спостережливості Хаббла” не просто теоретичне; воно активно використовується як діагностичний інструмент. Команда використовує здатність Hubble візуалізувати і аналізувати шаблони мережевого трафіку, щоб визначити кореневу причину проблеми - критичне вміння при усуненні проблем з мережею Kubernetes.

# Example Cilium Policy YAML (for illustrative purposes only)
apiVersion: cilium.io/v2
kind: NetworkPolicy
metadata:
  name: restrict-outbound-orderprocessor
spec:
  selector:
    matchLabels:
      app: OrderProcessor
  ingress:
  - from_port: 80
    to_ports:
    - 443
    protocol: TCP
    namespaceSelector:
      matchNames:
      - production

Цей простий приклад YAML демонструє практичне застосування мережевих правил — основний елемент словника. Правило selector призначено для обробки трафіку з служби « OrderProcessor », у той час як правило ingress визначає дозволені вихідні з’ єднання до зовнішніх служб, таких як [External Payment Gateway]. Сама по собі політика є конкретним проявом абстрактних концепцій, які обговорюються у цій статті, забезпечуючи реальний спосіб керування мережевим трафіком і підвищення безпеки у кластері.