Что сейчас больше используется: IngressClass в Ingress-ресурсе или указание Ingress Controller непосредственно в приложении?

В современных Kubernetes-кластерах (v1.19+) стандартной практикой стало использование IngressClass для явного указания контроллера, а не встраивание этой логики в приложение.

Почему IngressClass стал предпочтительным:

1. Разделение ответственности: Разработчики описывают правила маршрутизации (Ingress), а администраторы кластера настраивают контроллеры через IngressClass.
2. Поддержка нескольких контроллеров: В одном кластере могут работать Nginx Ingress, AWS ALB Controller и Traefik одновременно.
3. Явность конфигурации: Легко понять, какой контроллер обрабатывает конкретный Ingress.

Пример типичной конфигурации:

# 1. IngressClass (устанавливается администратором кластера)
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx-external
spec:
  controller: k8s.io/ingress-nginx
  parameters:
    apiGroup: k8s.example.com
    kind: IngressClassParameters
    name: external-nginx
---
# 2. Ingress (создается разработчиком)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx-external  # Явное указание класса
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

Ключевое отличие от старого подхода: Раньше аннотация kubernetes.io/ingress.class: "nginx" была нестандартизированной. Теперь IngressClass — это native Kubernetes-ресурс с валидацией и лучшей интеграцией.

Когда указывать контроллер в приложении: Почти никогда. Исключение — legacy-кластеры (<v1.18) или специфические кастомные контроллеры без поддержки IngressClass.