Что сейчас больше используется, ингресс класс в ингрессе или указывается ингресс контроллер непосредственно в апликейшене

Анализ подходов к определению Ingress в Kubernetes

На практике сегодня в подавляющем большинстве случаев используется прямое указание Ingress Controller в Ingress-ресурсе через аннотации (annotations) или специфические поля, а не через параметр ingressClassName. Однако оба подхода имеют свои ниши и активно развиваются, так как Kubernetes Ingress API находится в состоянии эволюции.

Текущее состояние и распространённость

1. Прямое указание контроллера через аннотации (Доминирующий подход)

Это исторически сложившийся и наиболее распространённый метод, особенно в production-средах.

• Причина популярности: Ingress-контроллеры (Nginx Ingress Controller, Traefik, HAProxy Ingress и др.) изначально появились как самостоятельные проекты со своими уникальными возможностями (кеширование, перезапись заголовков, аутентификация). Эти функции конфигурируются через специфичные аннотации.

• Пример для Nginx Ingress Controller:

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: my-app-ingress
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /
      nginx.ingress.kubernetes.io/use-regex: "true"
      kubernetes.io/ingress.class: "nginx" # Классический способ указания класса
  spec:
    rules:
    - host: app.example.com
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: my-service
              port:
                number: 80
  

    **Ключевой момент:** Поле `ingressClassName` здесь не используется. Контроллер выбирает Ingress-ресурсы по аннотации `kubernetes.io/ingress.class` или по своей собственной логике (например, контроллер по умолчанию).

2. Использование поля ingressClassName (Новый стандартный подход)

Это подход, продвигаемый самим Kubernetes API для унификации и упрощения конфигурации.

• Причина появления: С появлением Kubernetes API networking.k8s.io/v1 (стабильная версия) было введено явное поле spec.ingressClassName. Это часть движения к более декларативной и унифицированной модели, где класс — это отдельный ресурс (IngressClass), описывающий, какой контроллер должен его обрабатывать.

• Пример использования:

  apiVersion: networking.k8s.io/v1
  kind: IngressClass
  metadata:
    name: public-nginx
  spec:
    controller: k8s.io/ingress-nginx
  ---
  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    name: my-app-ingress
  spec:
    ingressClassName: public-nginx # Ссылка на IngressClass
    rules:
    - host: app.example.com
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: my-service
              port:
                number: 80
  

    В этом случае аннотации для специфичных функций контроллера всё ещё могут использоваться дополнительно.

Сравнение и рекомендации

Итог и что используется больше сейчас:

Прямое указание через аннотации (фактически ingress.class) пока используется значительно чаще, особенно в сложных средах. Причины:

1. Наследие: Большая часть существующей документации, Helm-чартов и инфраструктуры построена на этом подходе.
2. Необходимость расширенных функций: Для реальных задач (TLS, redirect, auth) аннотации необходимы в любом случае, поэтому поле ingressClassName часто рассматривается как дополнительное, а не основное.
3. Поддержка по умолчанию: Многие Ingress-контроллеры по умолчанию смотрят на аннотацию kubernetes.io/ingress.class.

Однако тренд однозначно движется в сторону ingressClassName. Новые проекты и кластеры на современных версиях Kubernetes (где доступен ресурс IngressClass) начинают использовать этот более чистый подход в комбинации с аннотациями для тонкой настройки. Для простых сценариев роутинга ingressClassName может быть достаточен.

Рекомендация: При создании нового Ingress в 2023-2024 году лучше указывать и spec.ingressClassName, и необходимые аннотации вашего контроллера. Это обеспечивает совместимость со стандартом будущего и работу со всеми текущими возможностями выбранного Ingress-контроллера. Проверьте документацию вашего Ingress-контроллера на предмет поддержки IngressClass.