KubernetesMiddleSystem design

Что такое Ingress и чем он отличается от Service типа LoadBalancer? Зачем нужен Ingress Controller?

Ingress описывает L7 HTTP/HTTPS маршруты по host и path, а LoadBalancer Service обычно дает внешний L4 вход к одному Service. Ingress Controller реализует эти правила реальным proxy.

Суть

Ingress — это не сам балансировщик, а Kubernetes API-объект с правилами HTTP/HTTPS маршрутизации. Он говорит: домен example.com и путь /api отправлять в Service api. Service типа LoadBalancer обычно создает внешний L4 балансировщик для конкретного Service. Поэтому Ingress нужен, когда много HTTP-сервисов должны жить за одним внешним адресом, с TLS termination, host/path routing и централизованной edge-конфигурацией.

Как работает

Ingress сам по себе ничего не делает без Ingress Controller. Controller наблюдает Ingress objects и конфигурирует реальный dataplane: NGINX, HAProxy, Envoy, Traefik или cloud-native load balancer. Обычно снаружи есть один Service типа LoadBalancer, который ведет на controller, а controller уже смотрит на Host и Path и отправляет запрос в нужный backend Service. TLS секреты, redirect, rewrite и rate limits часто реализуются controller-specific аннотациями, что важно для переносимости.

Пример

кода

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

Подводные камни

  • Создать Ingress без установленного controller и ждать, что трафик пойдет. Kubernetes хранит объект, но никто его не реализует.
  • Считать Ingress универсальным TCP/UDP router. Базовый Ingress ориентирован на HTTP/HTTPS.
  • Переносить аннотации NGINX в другой controller без проверки. Поведение часто vendor-specific.

Что отличает сильный ответ

Сильный ответ упоминает, что Gateway API постепенно заменяет часть сценариев Ingress более явной моделью ролей и ресурсов. Но на большинстве собеседований ожидают базовую цепочку: external LB -> Ingress Controller -> Service -> Pod.

Common mistakes

  • Называть Ingress самим nginx
  • Не знать роль ingressClassName
  • Путать L4 и L7

What the interviewer is testing

  • Объясняет controller
  • Отличает Ingress от LoadBalancer Service
  • Понимает TLS и host/path routing

Sources

Related topics