Англійський словник для API Kubernetes Gateway

API Kubernetes Gateway є сучасним наступником ресурсу Ingress, розробленого для більш виразного, розширюваного і орієнтованого на ролі. Оскільки він досягає загальної доступності і замінює Ingress у більшому кількості кластерів, інженерам, які працюють в мережах Kubernetes, потрібна точна лексика, використана в документації Gateway API, розмовах CNCF і каналах Kubernetes Slack.

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

** Клас шлюзу ** Клас Шлюзів — це ресурс з обсягом кластера, який визначає клас Шлюзів, якими керує певний контролер (наприклад, Envoy Gateway, Nginx або Istio). Команди інфраструктури «визначають», «реєструють» або «налаштовують» класи шлюзу. Це аналогічно до IngressClass.

• Приклад: « Команда розробників платформи визначила клас GatewayClass, підтримуваний Envoy Gateway, і поділилася ним зі всіма командами розробників програм у кластері. » *

Шлюз Ресурс Шлюз створюється командами з інфраструктури для забезпечення балансування навантаження або екземпляра проксі. У ньому вказано клас GatewayClass і визначено слухачів (протоколи, порти, сертифікати). Оператори «надання», «створення» і «налаштування» Шлюзів.

• Приклад: « Ми створили ресурс Шлюз з протоколом HTTPS на порту 443 і долучили наш сертифікат TLS з шаблонами. » *

** HTTPRoute ** HTTPRoute визначає правила маршрутизації для HTTP і HTTPS трафіку до серверних служб. Команди програм «визначають», «приєднують» і «налаштовують» HTTPRoutes. Правила можуть збігатися з вузлом, шляхом, заголовками або параметрами запиту. Приклад: «Я визначив HTTPRoute, який маршрутизує /api/v2/ трафік до нової версії сервісу і залишає всі інші шляхи на стабільній версії.»

• Гей, гей, гей GRPCRoute забезпечує національне маршрутизацію для гРПЦ трафіку з методом і службою відповідності. Він схожий на HTTPRoute, але оптимізований для gRPC. Команди «налаштовують» GRPCRoutes для серверів gRPC.

• Приклад: « Замість використання HTTPRoute з нетиповими заголовками для gRPC, ми перейшли на ресурс GRPCRoute для чистішого маршрутизації на рівні методів. » *

Спосіб посилання ReferenceGrant надає змогу ресурсу у одному просторі назв посилатися на ресурс у іншому просторі назв. Без цього параметра, типово, з метою безпеки, посилання на крос- простори імен буде відхилено. Команди інфраструктури «створюють» або «надають» ReferenceGrants. Приклад: «Команді програми потрібно було посилатися на спільний секрет TLS з простору імен tls-certs, тому команда платформи створила ReferenceGrant, щоб дозволити це.»

** Правила сервера TLS ** BackendTLSPolicy налаштовує параметри TLS для потоку даних між Шлюзом і службою сервера (передачі TLS). Цей протокол відрізняється від TLS слухача, який покриває трафік від клієнта до Шлюзу. Команди «налаштовують» або «застосовують» правила сервера TLS.

• Приклад: « Ми застосували BackendTLSPolicy, щоб забезпечити шифрування трафіку між балансувальником навантаження і підсистемою служби замовлень, а не лише трафіку між клієнтом і шлюзом. » *

** Розділення руху ** Розділення трафіку використовує HTTPRoute для розподілу трафіку між декількома серверними службами за значенням. Зазвичай використовується для канарських розгортань і синіх / зелених розгортань. Інженери «налаштовують», «реалізують» або «налаштують» розділення трафіку.

• Приклад: « Ми налаштували розділення трафіку так, щоб 10% запитів надсилались до версії canary і 90% — до стабільної версії, а потім поступово збільшували вагу canary. » *

** Міграція з Ingress ** Багато команд зараз переходять з ресурсу Ingress на API Gateway. Цей метод передбачає перетворення правил Ingress на HTTPRoutes і заміну IngressClasses на GatewayClasses. Команди «мігрують з Ingress», «конвертують правила Ingress» або «приймають API Gateway» Приклад: «Ми мігруємо з Ingress на Gateway API поетапно — починаючи з кластера розробки перед тим, як торкнутися виробництва.»

Фрази і фразеологізми

** “налаштувати ресурс Шлюзу” ** Типовий вираз під час налаштування шлюзу. Завжди « налаштовувати ресурс Шлюз » у офіційній документації.

• Приклад: « Налаштувати ресурс Шлюз для прослуховування на портах 80 і 443, і встановити дозволені маршрути для посилання на простори імен з міткою app-team. » *

** “визначити HTTPRoute” ** Дія, що створює правила маршрутизації. « Визначити » означає декларативний ресурс; краще використовувати його, ніж « створити » або « записати » у дискусіях щодо архітектури. Приклад: «Встановити HTTPRoute, який відповідає запитам з заголовком X-Feature-Flag: beta і маршрутизує їх до бета-служби.»

“положення класу Шлюз” Описує дію автоматичного забезпечення, яку виконує контролер Шлюз під час створення ресурсу Шлюз.

• Приклад: « Під час застосування ресурсу Шлюз, GatewayClass забезпечує новий підрозділ проксі- сервера Envoy і приєднує його до балансувальника навантаження кластера. » *

“приєднати маршрут” Маршрути «приєднуються» до Шлюзів за допомогою поля parentRefs. Це стандартне дієслово у документації API Gateway.

• Приклад: « Приєднайте HTTPRoute до виробничого шлюзу, встановивши у полі parentRefs вказівник на назву і простір імен шлюзу. » *

** « посилання на простір імен » ** Коли ресурс у одному просторі імен Kubernetes посилається на ресурс у іншому просторі імен. API Шлюз обмежує ці параметри типово і вимагає явних ReferenceGrants.

• Приклад: « Серверна служба HTTPRoute знаходиться в іншому просторі імен, отже, це посилання на інший простір імен — вам слід спочатку створити ReferenceGrant. »*

Практичні рекомендації

1. «GatewayClass забезпечується командою платформи; команди застосунків повинні тільки визначити свої HTTPRoutes.»
2. «Ми використовуємо розділення трафіку, щоб розгорнути новий платіжний сервіс — на даний момент на 5% канарійної ваги і зростає щодня»
3. «Референційний Grant потрібний, тому що HTTPRoute в просторі імен apps посилається на Сервіс в просторі імен shared.»
4. «Після міграції з Ingress, ми вилучили 200 рядків конфігурації на основі анотації і замінили їх явними правилами HTTPRoute»
5. «BackendTLSPolicy забезпечує шифрування в транзиті навіть всередині кластера, що є вимогою для нашого аудиту відповідності»

Необхідно уникати помилок

** Виклик HTTPRoute як « правила вхідного каналу » ** HTTPRoute і Ingress — це різні ресурси. Якщо ви перейшли на API Шлюз, називайте їх « Правила HTTPRoute », а не « Правила вхідних даних ». Поєднання двох словників у одному документі призведе до плутанини.

Сказав “Шлюз маршрутизує рух” Технічно, маршрути визначають правила маршрутизації і приєднуються до Шлюзу. Шлюз — це точка підключення інфраструктури. У точних обговореннях, скажіть « HTTPRoute визначає правило маршрутизації » і « Шлюз забезпечує слухачів »

** Плутанина між « слухачем TLS » і « сервером TLS » ** Слухач TLS (на шлюзі) захищає трафік клієнт-шлюз. Сервер TLS (BackendTLSPolicy) захищає трафік від шлюзу до служби. Це окремі конфігурації. Завжди вказуйте, на який сегмент ви посилаєтеся.

Summary

API Kubernetes Gateway вводить шаровий словник — GatewayClass, Gateway, HTTPRoute, GRPCRoute, ReferenceGrant і backend TLS policy — що відображає його ролево-орієнтований дизайн. Оператори керують Шлюзами; команди програм керують Маршрутами. Знання цього словника допоможе вам брати участь у обговореннях мережевих проблем Kubernetes, писати точні підручники з керування та чітко спілкуватися з командами розробників SRE і платформи. Офіційна документація Gateway API на gateway-api.sigs.k8s.io добре написана і використовує послідовну термінологію, що робить її відмінним англійським ресурсом навчання разом з технічним вмістом.

Розвиток комунікації: проблеми та перспективи

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

Наприклад, уявіть, що ви витратили години на налаштування розділення трафіку на основі заголовків HTTP в GatewayClass за допомогою API Kubernetes Gateway. Ви пишете запит на оновлення розгортання. Рецензент може відповісти щось на зразок: «В цілому це виглядає добре, але чи можете ви додати більше контексту про те, чому ви обрали цей конкретний розділ? Які показники ви стежите за? “Проблема не в тому, що конфігурація технічно правильна - це те, що рецензент непрямо просить про виправдання, пояснення процесу прийняття рішень. Просто сказати «розділення трафіку на основі заголовків» недостатньо; у нього немає бізнес-логіки і очікуваного рівня деталізації, знайденого в виробничих середовищах. Аналогічно, під час перегляду коду, ви можете побачити коментарі на кшталт «Розгляньте можливість додавання описового коментаря, який пояснює ціль цієї посилання» — це більше про документування наміру, ніж просто опис технічної реалізації.

Іншою областю, де виникають нюанси, є стратегії міграції. Припустимо, що ви переносите трафік з контролера Ingress на налаштування API Шлюз. Обговорення може включати такі фрази, як «нульовий час простою», «блакитні / зелені розгортання» і «процедури відновлення». Ці терміни не завжди прості в перекладі, і можуть легко виникнути непорозуміння щодо рівня складності або потенційних ризиків. Тут ключовим є чітке спілкування — не достатньо сказати « ми пересунули трафік ». Вам слід сформулювати * як * ви досягли цього пересування, одночасно мінімізуючи перешкоди і маючи міцний план для повернення, якщо це буде необхідно.

Нарешті, пам’ ятайте, що сама документація часто використовує конкретні формулювання, пов’ язані з дизайном і обмеженнями API. Приділіть особливу увагу тому, як описуються такі терміни, як « перевірка запиту » або « обмеження швидкості »; ці поняття часто мають більш складні наслідки, ніж їхні буквальні переклади.

apiVersion: networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-gatewayclass
spec:
  ...
    trafficSplits:
    - name: header-split
      httpRoute:
        path: "/api"
        matchHeaders:
          - key: "X-User-ID"
            test: "equals"
            value: "admin"
      weight: 80

Цей приклад показує конфігурацію GatewayClass з розділенням трафіку на основі заголовка X-User-ID. Під час обговорення цього питання на зустрічі, ви, ймовірно, поясните, * чому* цей конкретний заголовок використовується для маршрутизації — можливо, для пересування адміністративних запитів до окремої служби або середовища. Ключовим моментом є те, що ефективне спілкування виходить за рамки простого знання синтаксису; мова йде про розуміння контексту і очікувань, що оточують терміни в рамках робочого процесу вашої команди.