Что такое Ingress

Ingress — это объект API в Kubernetes, который описывает правила доступа HTTP/HTTPS к сервисам внутри кластера. Инgress позволяет собрать маршрутизацию для множества сервисов за одним внешним адресом (или несколькими) и задаёт правила вида «host + path → backend service». Основные возможности Ingress: виртуальные хосты (name-based), маршрутизация по путям, TLS (SNI)-терминация, перенаправления и переписывания URL (если контроллер это поддерживает), указание дефолтного бэкенда для ненайденных запросов.

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

Что такое Ingress Controller

Ingress Controller — это контроллер (обычно деплоймент/daemonset), который «подписывается» на API-сервер и наблюдает за объектами Ingress. Когда появляются или меняются правила Ingress, контроллер переконфигурирует свой HTTP-прокси/балансировщик (например, NGINX, HAProxy, Envoy, Traefik и т.д.) или настраивает облачный LB, чтобы обеспечить маршрутизацию в соответствии с ресурсами Ingress. Контроллеры могут предоставлять дополнительные функции: TLS termination, rate limiting, basic auth, rewrite/redirect, sticky sessions, WebSocket/gRPC проксирование, метрики и интеграции с внешними провайдерами.

Ingress Controller обычно выставляется наружу через Service типа LoadBalancer или NodePort, либо интегрируется с облачным сетевым LB для получения единого внешнего IP.

Как это работает (процесс)

1. Администратор создаёт Ingress с правилами (hosts, paths, tls).

2. Ingress Controller видит ресурс через Kubernetes API.

3. Контроллер обновляет конфигурацию своего прокси (или вызывает провайдера LB) — добавляет виртуальные хосты, настройки TLS, бэкенды (имена service + порт).

4. Внешние запросы приходят на контроллер, который проксирует их к нужному Service → Pods.

Важные детали и термины

• ingressClassName / IngressClass: связывает Ingress с конкретным контроллером; позволяет в одном кластере использовать несколько реализаций.

• TLS: Ingress ссылается на Secret с cert/key; контроллер выполняет TLS-терминацию и SNI.

• pathType: Exact, Prefix и др. (поведение совпадения путей).

• Default backend: указывает куда направлять запросы, которые не попали под правила.

• Аннотации: контроллеры читают аннотации в метаданных для включения специфичных возможностей (rewrites, timeouts, rate limits и т.д.).

Ограничения и альтернативы

Ingress ориентирован на HTTP/HTTPS; для произвольных TCP/UDP портов часто используют Service type=LoadBalancer или дополнительные конфигурации контроллера (некоторые контроллеры поддерживают TCP через ConfigMap). Для более богатой и выраженной L4–L7 конфигурации и мультиплексирования возможностей существуют более современные CRD, например Gateway API (предоставляет более гибкие модели маршрутизации, политики и т.д.), а также сервис-меш решения (Istio/Linkerd) для сложных сценариев.

Пример (упрощённый)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
ingressClassName: nginx
tls:
\- hosts: \["example.com"\]
secretName: example-tls
rules:
\- host: example.com
http:
paths:
\- path: /app
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80

Этот манифест говорит контроллеру nginx принимать запросы для example.com по пути /app и проксировать их в сервис app-service:80, а также использовать TLS-секрет example-tls для сертификата.