Kubernetes Ingress (Маршрутизация трафика в Kubernetes)

Kubernetes Ingress — это такой «входной шлюз» в кластер, который принимает внешний HTTP(S)-трафик и по набору правил отправляет его на нужные сервисы внутри. В отличие от варианта «каждому сервису по своему LoadBalancer», здесь одна точка входа, а маршрутизация уже внутри — по хостам, путям и прочим критериям.

Работает всё это в паре с Ingress Controller — отдельным контроллером, который читает объекты Ingress, генерирует под них конфиг и настраивает реальный прокси (NGINX, Envoy, что угодно). Один такой контроллер обычно обслуживает десятки доменов и роутов, умеет HTTPS, редиректы, лимиты и прочие L7-фишки.

Зачем вообще заморачиваться с Ingress #

• Одна точка входа на весь кластер, централизованные правила.
• Экономия: вам не нужен отдельный облачный балансировщик под каждый микросервис.
• Гибкие маршруты — по host, path, префиксам, с приоритетами и прочей логикой.
• HTTPS/TLS — можно нормально автоматизировать сертификаты (через тот же cert-manager).
• Расширяемость — у разных контроллеров свои аннотации, CRD, middleware и плагины.

Как это устроено примерно #

1. В кластере крутится Ingress Controller (например, NGINX Ingress Controller) и следит за объектами Ingress.
2. Вы описываете в YAML’е правила: какой домен, какие пути, на какой Service вести.
3. Контроллер на лету обновляет конфиг прокси (NGINX/Envoy/свой движок) под эти правила.
4. Запрос снаружи прилетает на IP/DNS контроллера, сверяется с правилом и прокидывается дальше в нужный сервис и в нужный pod.

Простой пример Ingress-манифеста #

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: app.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80

В итоге запросы на https://app.example.com/api уедут в сервис api-service внутри кластера.

Какие контроллеры чаще всего используют #

• Ingress-NGINX — де-факто стандарт в open source-мире, тонны аннотаций и примеров.
• AWS ALB Ingress Controller — завязан на Application Load Balancer от AWS, хорошо интегрирован с их экосистемой.
• GKE Ingress — управляемый вариант от Google Cloud, где большинство магии делает сам клауд.
• Traefik — лёгкий и довольно приятный вариант, с поддержкой TCP, WebSocket, встроенным Let’s Encrypt.
• Kong Ingress Controller — ближе к API Gateway, с кучей enterprise-фич.
• Istio Gateway — если у вас сервис-меш, то уже играете этими игрушками, Ingress там немного по-другому выглядит.

Что ещё Ingress умеет (в зависимости от контроллера) #

• Заканчивать HTTPS (TLS termination) или просто прокидывать его дальше (passthrough).
• Подключать middleware: авторизацию, rate limiting, фильтрацию по IP, и т.д.
• Балансировать нагрузку, делать sticky-сессии.
• Canary и A/B-трафик в некоторых решениях (Traefik, Istio и др.).
• Работать с WebSocket и gRPC — NGINX, Envoy и прочие современные прокси это умеют.

В продакшене Ingress — это уже базовая часть архитектуры, без которой сложно аккуратно выстроить внешнюю маршрутизацию, не плодя лишнюю инфраструктуру.

Практика: Ingress с TLS и cert-manager #

1. ClusterIssuer для cert-manager #

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: admin@example.com
privateKeySecretRef:
name: letsencrypt-prod-key
solvers:
- http01:
ingress:
class: nginx

2. Ingress, который сам получает сертификат #

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: secure-app
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
tls:
- hosts:
- app.example.com
secretName: app-example-com-tls
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80

cert-manager сам сходит к Let’s Encrypt, докажет владение доменом через HTTP‑01, создаст secret с сертификатом и будет его обновлять по мере необходимости.

Сравнение популярных Ingress-контроллеров (по верхам) #

• NGINX Ingress — TLS есть, middleware через аннотации, WebSocket/gRPC поддерживаются, rate limiting и canary можно выкрутить, но местами через Lua и костыли.
• Traefik — TLS и Let’s Encrypt встроены, middleware через CRD, canary и прочие штуки задаются декларативно.
• Kong — мощный плагинный движок, хорош для API, много готовых расширений.
• AWS ALB / GKE Ingress — тесно интегрированы с соответствующими облаками, но в рамках их возможностей.
• Istio Gateway — если у вас уже mesh, там богатый функционал, но и порог входа соответствующий.

Canary rollout через NGINX Ingress #

1. Основной маршрут #

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "false"
spec:
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-v1
port:
number: 80

2. Canary-маршрут #

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-canary
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10" # 10% трафика
spec:
rules:
- host: app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-v2
port:
number: 80

Так раскладывается трафик: 90% идут на app-v1, 10% — на app-v2. Можно вместо процента использовать заголовок или cookie, чтобы явно включать канарейку только определённым пользователям.

Canary через Traefik (IngressRoute) #

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: app
spec:
entryPoints:
- web
routes:
- match: Host(`app.example.com`)
kind: Rule
services:
- name: app-v1
port: 80
weight: 90
- name: app-v2
port: 80
weight: 10

В Traefik веса задаются прямо в CRD и работают на L7-уровне, без дополнительных аннотаций и «магии».

И немного сравнения NGINX vs Traefik по канарейкам #

• NGINX делает canary через набор аннотаций (процент, заголовок, cookie), достаточно гибко, но конфиг получается «размазанный» по метаданным.
• Traefik описывает веса прямо в IngressRoute — чуть более чистый и декларативный подход, особенно если вы активно пользуетесь его CRD.
• Оба варианта рабочие, выбор чаще зависит от того, что уже используется в инфраструктуре и кто что лучше умеет поддерживать.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Арендовать VPS