Перевірка реальності Kubernetes Gateway API: все ще потрібен контролер Ingress

Ознайомтеся із сесіями за запитом на саміті Low-Code/No-Code Summit, щоб дізнатися, як успішно впроваджувати інновації та досягати ефективності шляхом підвищення кваліфікації та масштабування громадянських розробників. Дивитися зараз.


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

Спільна архітектура — у всіх масштабах — вимагає гнучких, масштабованих і розширюваних засобів для керування, спостереження та безпеки цієї інфраструктури. API шлюзу призначений для цих завдань. Після повної зрілості він допоможе розробникам, SRE, командам платформ, архітекторам і технічним директорам, зробивши інструменти і управління інфраструктурою Kubernetes більш модульними та менш індивідуальними.

Але будьмо впевнені, що ажіотаж не випередить сьогоднішні потреби.

Минулий і майбутній API шлюзу Kubernetes

Залишається розрив між поточним і майбутнім станами контролю входу в Kubernetes. Це призвело до поширеної помилки, що Gateway API замінить Kubernetes Ingress Controller (KIC) найближчим часом або зробить його менш корисним у довгостроковій перспективі. Ця точка зору є неправильною з кількох причин.

Подія

Саміт інтелектуальної безпеки

8 грудня дізнайтеся про важливу роль штучного інтелекту та машинного навчання в кібербезпеці та конкретних галузевих прикладах. Зареєструйтеся, щоб отримати безкоштовний пропуск сьогодні.

Зареєструватися зараз

Контролери Ingress тепер вбудовані у функціональну архітектуру більшості розгортань Kubernetes. Вони стали де-факто. У якийсь момент Gateway API стане достатньо зрілим, щоб замінити всі функції Ingress API і навіть специфічні для реалізації анотації та спеціальні ресурси, які використовують багато реалізацій Ingress, але цей день ще далекий.

Сьогодні більшість ІТ-організацій все ще знаходяться на стадії раннього впровадження або тестування Kubernetes. Для багатьох просто ознайомлення з новою архітектурою, мережевими конструкціями та вимогами до керування додатками та послугами вимагає значної внутрішньої освіти та перетравлення.

Gateway API та контролери Ingress не є взаємовиключними

Як і ми в NGINX, інші супроводжувачі Ingress, імовірно, впровадять Gateway API у свої продукти, щоб скористатися перевагами нової функціональності та бути в курсі Kubernetes API і проекту. Подібно до того, як RESTful API корисні для багатьох завдань, Kubernetes API лежить в основі багатьох продуктів і служб, усі вони створені на основі його потужного механізму оркестровки контейнерів.

API шлюзу створено як універсальний компонентний рівень для керування підключенням і поведінкою сервісів у Kubernetes. Він виразний і розширюваний, що робить його корисним для багатьох ролей, від DevOps до безпеки та NetOps.

Як команда, яка інвестувала значні ресурси в контролер Ingress з відкритим кодом, NGINX могла вибрати інтеграцію API шлюзу в нашу поточну роботу. Натомість ми вирішили використовувати Gateway API як окремий, більш відкритий проект. Ми обрали цей шлях, щоб не проектувати існуючі обмеження реалізації нашого контролера Ingress на способи, якими ми сподіваємося використовувати Gateway API або NGINX у майбутньому. З меншою кількістю обмежень легше швидше вийти з ладу або досліджувати нові дизайни та концепції. Як і більшість хмарних технологій, конструкція Gateway API розроблена для вільного зв’язку та модульності — навіть більше, ніж контролер Ingress.

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

Можна витлумачити, що API, що розвивається, надає безцінну точку вставки та можливість для «переробки» мережевих сервісів. Але це не означає, що всі поспішають викинути роки інвестицій в інші проекти. Ingress залишатиметься важливим у міру дозрівання та розвитку Gateway API, і вони не є взаємовиключними.

Плануйте гібридне майбутнє

Звучить так, ніби ми вважаємо, що світ Kubernetes повинен мати свій пиріг Gateway API і з’їсти свій контролер Ingress? Ну, ми робимо. Визнаний винним. Підсумок: ми вважаємо, що Kubernetes — це великий намет, у якому достатньо місця як для нових конструкцій, так і для старих категорій. Удосконалення існуючих контролерів Ingress, які були прив’язані до обмеженої можливості анотації, що спричинило складність і зменшення модульності, залишається критично важливим для організацій у найближчому майбутньому.

Так, Gateway API допоможе нам покращити контролери Ingress і розкрити інновації, але це API, а не категорія продукту. Цей новий API не є ні чарівною паличкою, ні срібною кулею. Розумні команди планують це гібридне майбутнє, дізнаючись про покращення, які принесе Gateway API, одночасно продовжуючи планувати поточне вдосконалення контролера Ingress. Краса цієї гібридної реальності полягає в тому, що кожен може керувати кластерами у спосіб, який він знає та хоче. Кожна команда отримує те, що хоче і чого потребує.

Браян Елерт, директор з управління продуктами в NGINX.

DataDecisionMakers

Ласкаво просимо до спільноти VentureBeat!

DataDecisionMakers — це місце, де експерти, включно з технічними спеціалістами, які працюють з даними, можуть ділитися інформацією та інноваціями, пов’язаними з даними.

Якщо ви хочете прочитати про передові ідеї та актуальну інформацію, найкращі практики та майбутнє даних і технологій обробки даних, приєднуйтесь до нас у DataDecisionMakers.

Ви навіть можете подумати про те, щоб написати власну статтю!

Докладніше від DataDecisionMakers

Leave a Comment