Kubernetes Ingress: маршрутизация HTTP-трафика в кластер

Коротко: Набор правил, определяющий, какие веб-адреса снаружи ведут к каким сервисам в кластере Kubernetes.

Подробнее: Поды в Kubernetes недоступны напрямую снаружи. Сервис (service) делает их обнаруживаемыми внутри кластера. Чтобы веб-запрос из интернета дошёл, дополнительно нужен ingress: он описывает правила вроде «shop.example.com идёт в сервис shop». Ingress-контроллер (например, nginx или Traefik) реализует эти правила.

Подробности

Пример

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
spec:
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: shop, port: { number: 80 } }

Здесь хост shop.example.com с сертификатом TLS направляется в сервис shop.

Задачи контроллера

Контроллер работает как под в кластере и читает ресурсы ingress. Он действует как обратный прокси: принимает соединения, терминирует TLS, выбирает сервис по хосту и пути и распределяет по его подам. Дополнительные функции, такие как перенаправление HTTP на HTTPS, тайм-ауты или ограничения частоты, управляются через аннотации.

Автоматические сертификаты

С cert-manager сертификаты (например, от Let’s Encrypt) можно запрашивать и продлевать автоматически. Ingress тогда лишь ссылается на имя секрета.

Gateway API

Gateway API считается преемником. Он точнее разделяет роли (оператор инфраструктуры предоставляет шлюз, команды приложений создают маршруты) и поддерживает больше, чем HTTP. Классический ingress, однако, по-прежнему широко распространён.

См. также: Основы Kubernetes, nginx и обратный прокси, Let’s Encrypt и сертификаты TLS, Балансировщик нагрузки