Використання Ingress у Kubernetes: спрощення зовнішнього доступу до кількох сервісів

У Kubernetes Ingress є потужним об'єктом API, який керує зовнішнім доступом до сервісів у кластері, зазвичай для HTTP та HTTPS трафіку. Замість того, щоб створювати кілька сервісів типу LoadBalancer або NodePort для кожного застосунку, Ingress дозволяє консолідувати зовнішній доступ в один ресурс, надаючи розширені можливості, такі як маршрутизація за URL, завершення SSL та балансування навантаження. Це робить його незамінним інструментом для керування трафіком у продукційних Kubernetes застосунках.

Ось детальне пояснення використання Ingress:

1. Спрощення зовнішнього доступу для кількох сервісів

Виклик:

У типовому розгортанні Kubernetes, коли ви хочете зробити кілька сервісів (наприклад, фронтенд, API і базу даних) доступними для зовнішнього світу, у вас є кілька варіантів:

• LoadBalancer сервіси, які створюють зовнішній балансувальник навантаження для кожного сервісу.
• NodePort сервіси, які відкривають порт на кожному вузлі кластера.

Однак використання сервісів LoadBalancer або NodePort може швидко стати неефективним і складним для управління, особливо коли у вас є кілька сервісів. Керування кількома зовнішніми IP-адресами, портами або балансувальниками навантаження може збільшити операційні витрати, призвести до додаткових витрат (у хмарних середовищах) і ускладнити архітектуру.

Рішення за допомогою Ingress:

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

Приклад:

Уявіть, що у вас є наступні сервіси:

• frontend-service
• api-service
• auth-service

Без Ingress вам доведеться виставити кожен сервіс через окремий LoadBalancer або NodePort, що призведе до множинних зовнішніх IP-адрес і портів. З Ingress ви можете об'єднати ці сервіси під одним зовнішнім URL, з правилами маршрутизації для спрямування трафіку до правильного сервісу.

2. Маршрутизація на основі хоста та шляху

Виклик:

Багато застосунків вимагають, щоб різні сервіси були доступні через різні домени або шляхи. Наприклад:

• www.example.com може бути фронтенд-застосунком.
• api.example.com може вести до бекенд-API.
• auth.example.com може бути для аутентифікації.

Рішення за допомогою Ingress:

Ingress підтримує як маршрутизацію за хостом, так і маршрутизацію за шляхом, дозволяючи вам спрямовувати трафік до різних сервісів залежно від домену (хоста) або шляху URL вхідного запиту.

Приклад:

Ви можете налаштувати Ingress для маршрутизації трафіку таким чином:

• Запити до www.example.com спрямовуються до frontend-service.
• Запити до api.example.com спрямовуються до api-service.
• Запити до auth.example.com спрямовуються до auth-service.

Це особливо корисно, коли ви хочете використовувати один зовнішній IP або домен для маршрутизації трафіку до кількох сервісів, спрощуючи зовнішній доступ і зменшуючи потребу в кількох IP-адресах або балансувальниках навантаження.

Приклад YAML для Ingress:

apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
 name: my-ingress  
spec:  
 rules:  
 - host: "www.example.com"  
 http:  
 paths:  
 - path: "/"  
 pathType: Prefix  
 backend:  
 service:  
 name: frontend-service  
 port:  
 number: 80  
 - host: "api.example.com"  
 http:  
 paths:  
 - path: "/"  
 pathType: Prefix  
 backend:  
 service:  
 name: api-service  
 port:  
 number: 80  
 - host: "auth.example.com"  
 http:  
 paths:  
 - path: "/"  
 pathType: Prefix  
 backend:  
 service:  
 name: auth-service  
 port:  
 number: 80

3. Завершення SSL і підтримка HTTPS

Виклик:

При розгортанні застосунків важливо забезпечити захист трафіку через HTTPS.
Традиційно вам потрібно налаштувати SSL сертифікати для кожного окремого сервісу, що може бути обтяжливим і схильним до помилок.

Рішення з Ingress:

Ingress підтримує SSL/TLS завершення (SSL/TLS termination), що означає, що ви можете керувати SSL сертифікатами на рівні Ingress, замість того, щоб налаштовувати їх для кожного окремого сервісу. Це дозволяє вам зняти навантаження зі завершення SSL на контролері Ingress і забезпечити, щоб увесь трафік до ваших сервісів був зашифрований.

Приклад:

Ви можете визначити правило Ingress для обробки HTTPS трафіку, і контролер Ingress займеться дешифруванням SSL, передаючи незашифрований HTTP трафік до ваших бекенд-сервісів.

Приклад YAML для Ingress (з завершенням SSL):

apiVersion: networking.k8s.io/v1  
kind: Ingress  
metadata:  
 name: secure-ingress  
spec:  
 rules:  
 - host: "www.example.com"  
 http:  
 paths:  
 - path: "/"  
 pathType: Prefix  
 backend:  
 service:  
 name: frontend-service  
 port:  
 number: 80  
 tls:  
 - hosts:  
 - "www.example.com"  
 secretName: tls-secret # Зазначення SSL сертифіката, що зберігається в Secret

У цьому випадку, tls-secret міститиме ваш SSL сертифікат, а контролер Ingress завершить HTTPS трафік до того, як передасть його до frontend-service.

4. Балансування навантаження і розподіл трафіку

Виклик:

Якщо ваше застосування масштабуватиметься, ймовірно, у вас буде кілька Pods, що працюють за сервісом. Без належного механізму балансування навантаження трафік може направлятись до одного Pod, що призведе до перевантаження і погіршення продуктивності.

Рішення з Ingress:

Ingress надає можливості балансування навантаження "з коробки". Він може розподіляти вхідний трафік між кількома Pods, базуючись на конфігурації бекенд-сервісу. Це забезпечує ефективний розподіл трафіку та високу доступність.

Приклад:

Якщо у вас є frontend-service з кількома Pods, контролер Ingress буде балансувати трафік між цими Pods, забезпечуючи, щоб кожен Pod отримував відповідну частину вхідних запитів.

5. Розширена маршрутизація: A/B тестування, Canary деплойменти

Виклик:

При розгортанні нових версій застосунків ви, можливо, захочете протестувати їх на невеликій частині трафіку перед тим, як повністю розгорнути їх для всіх користувачів. Також може виникнути потреба тестувати різні версії сервісу (наприклад, A/B тестування).

Рішення з Ingress:

Розширені контролери Ingress (наприклад, Nginx або Traefik) підтримують функції такі як розподіл трафіку, що дозволяє вам спрямовувати певний відсоток трафіку до однієї версії сервісу, а решту — до іншої версії. Це ідеально підходить для канарейкових деплойментів або A/B тестування.

Приклад:

У вас може бути дві версії API (api-v1 і api-v2), і ви хочете направити 90% трафіку до api-v1, а 10% до api-v2.

6. Безпека та контроль доступу

Виклик:

Вам потрібно захистити доступ до ваших сервісів, щоб лише авторизовані користувачі могли отримати доступ до певних частин вашого застосунку.

Рішення з Ingress:

Ingress підтримує різні функції безпеки, включаючи:

• Аутентифікацію: Ви можете інтегрувати базову аутентифікацію або аутентифікацію через OAuth2 з вашим контролером Ingress.
• Білий список IP-адрес: Ви можете обмежити доступ до певних сервісів на основі IP-адрес клієнтів.
• Обмеження запитів: Деякі контролери Ingress дозволяють реалізовувати обмеження на кількість запитів, щоб захистити сервіси від зловживань.

Висновок: Чому варто використовувати Ingress?

Ingress є ключовим компонентом для керування зовнішнім HTTP(S) трафіком у Kubernetes.
Використовуючи Ingress, ви можете:

• Спростити зовнішній доступ до кількох сервісів через одну точку входу.
• Реалізувати маршрутизацію на основі шляху та хоста для точного керування трафіком.
• Завершувати SSL/TLS трафік на рівні Ingress для забезпечення безпечних з’єднань.
• Розподіляти трафік між кількома Pods за допомогою вбудованого балансування навантаження.
• Здійснювати A/B тестування та канарейкові деплойменти для поступового розгортання нових функцій.
• Покращити безпеку з використанням таких функцій контролю доступу, як аутентифікація та фільтрація IP-адрес.

Загалом, Ingress є необхідним інструментом для застосунків на базі Kubernetes, які потребують складного управління зовнішнім трафіком, масштабування та забезпечення безпеки.

Перекладено з: Use Case of Ingress in Kubernetes: Simplifying External Access to Multiple Services