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

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

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

Зачем использовать Ingress

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

Как устроено

1. Ingress Controller (например, NGINX Ingress Controller) слушает изменения в объектах типа Ingress;
2. Пользователь описывает в YAML-файле правила маршрутизации (Ingress rules);
3. Контроллер автоматически настраивает прокси (например, NGINX, Envoy или собственный engine);
4. Входящий запрос (по IP, DNS и/или TLS) сопоставляется с правилом и направляется на нужный Service, а оттуда — в нужный 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

Здесь запросы к app.example.com/api будут перенаправляться на сервис api-service в кластере.

Поддерживаемые контроллеры

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

Дополнительные возможности:

• HTTPS termination и passthrough;
• Middleware (rate limiting, auth, IP white/blacklists);
• Load balancing, sticky sessions;
• Canary deployments и A/B-маршрутизация (в Traefik, Istio);
• Поддержка WebSocket и gRPC (в NGINX, Envoy).

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

Отлично. Вот продолжение — практическая реализация Ingress с TLS и автоматической выдачей сертификатов через cert-manager, плюс сравнение популярных Ingress-контроллеров.

Пример: Ingress с TLS + cert-manager (Let’s Encrypt)

1. Cert-manager: ClusterIssuer

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 с TLS-секцией

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 автоматически получит и обновит TLS-сертификат от Let’s Encrypt, связанный с app.example.com.

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

Пример: Canary rollout через NGINX Ingress Controller

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. Можно переключиться по заголовку (canary-by-header) или cookie.

Пример: Canary rollout через Traefik (CRD)

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-проксирования.

Сравнение: Canary через NGINX vs Traefik