Вышла версия Traefik proxy 3.6

Обратный прокси(reverse proxy) Traefik
1

Пишу в общей теме Reverse proxy и без тега т.е. не нашел ничего по traefik, может @admin создаст и подправит

Релиз облачного прокси-сервера с открытым исходным кодом Traefik 3.6 «Ramequin»

Основные изменения и дополнения в Traefik 3.6:

  • появилась многоуровневая маршрутизация. В проекте реализована иерархическая структура маршрутизаторов, которая позволяет выполнять обработку запросов последовательно. Родительский маршрутизатор может аутентифицировать запрос или добавлять заголовки, в то время как дочерние маршрутизаторы используют обогащённые данные для принятия окончательного решения о маршрутизации. В результате устраняется необходимость дублировать логику аутентификации между сервисами или использовать отдельные прокси-серверы для разных этапов запроса. Также реализованы шаблоны маршрутизации, такие как направление трафика на основе ролей пользователей, уровней подписки или оценки флагов функций, в простой декларативной конфигурации;
  • интеграция с Knative. Теперь Traefik может управлять трафиком сервисов Knative, используя ту же модель провайдера, что и для контейнеров или виртуальных машин. Поставщик Knative отвечает за обнаружение сервисов, масштабирование событий до нуля и маршрутизацию запросов к бессерверным рабочим нагрузкам, устраняя необходимость в дополнительных компонентах шлюза;
  • поддержка Gateway API v1.4, обеспечивая более строгий контроль маршрутизации для облачных рабочих нагрузок. Функции, BackendTLSPolicy и SupportedFeatures переведены из экспериментальной в стабильные. BackendTLSPolicy обеспечивает сквозной TLS между шлюзом и бэкенд-сервисами, повышая безопасность внутреннего трафика. SupportedFeatures обеспечивает совместимость функций через поля статуса Kubernetes, предоставляя операторам более чёткое представление о том, что поддерживает реализация;
  • новые проверки работоспособности TCP, которые позволяют Traefik напрямую оценивать не-HTTP-сервисы, в то время как пассивные проверки работоспособности определяют работоспособность сервисов на основе фактических схем трафика;
  • обновлённые параметры балансировки нагрузки включают алгоритмы Least Time и Highest Random Weight для более детального распределения трафика. AWS ECS получает полную поддержку IPv6, а поставщик Docker теперь может обнаруживать неработающие контейнеры;
  • расширенная поддержка ExternalName в Kubernetes, новые параметры резолвера ACME, настраиваемые размеры таблиц HTTP/2 HPACK, поддержку системных вызовов для плагинов, более компактные таблицы панели управления и улучшенное логирование запуска на уровне провайдера (provider-level startup logging);
  • опубликована документация по миграции на новую версию, а также улучшены переводы.

Хотелось бы остановиться на многоуровневой маршрутизации

Я выяснил, что в consul оно не работает

Вот пример

http:
  routers:
    # Root router - matches all API requests and applies auth
    api-parent:
      rule: "Host(`api.example.com`) && PathPrefix(`/`)"
      middlewares:
        - auth-with-tier
      entryPoints:
        - websecure
      tls: {}
      # No service defined - this is a parent router
    
    # Leaf router - routes enterprise customers to stable
    api-enterprise:
      rule: "HeaderRegexp(`X-Customer-Tier`, `(enterprise|business)`)"
      service: stable-backend
      parentRefs:
        - api-parent
    
    # Leaf router - routes free tier to canary
    api-free:
      rule: "Header(`X-Customer-Tier`, `free`)"
      service: new-version
      parentRefs:
        - api-parent

  middlewares:
    auth-with-tier:
      forwardAuth:
        address: "http://auth-service:8080/validate"
        authResponseHeaders:
          - X-Customer-Tier
          - X-Customer-Id
          - X-User-Email

  services:
    stable-backend:
      loadBalancer:
        servers:
          - url: "http://api-v1-stable:8080"
    new-version:
      loadBalancer:
        servers:
          - url: "http://api-v2-canary:8080"

Здесь мы создали корневой маршрутизатор (Root Routers) api-parent

  • связали его с точкой подключения
  • Указали домен и префикс пути
  • Добавили мидлварку аутентификации

Созлали 2 дочерних маршрута (Leaf Routers): api-enterprise и api-free, каждый из них

  • Имеет ссылку на родительский маршрутизатор
  • Имеет дополнительные правила
  • Ссылается на свой сервис

Что позволяет сократить дублирование конфигов и реализовать сложные правила маршрутизации, например, в версии 3.5 это выглядело бы так

http:
  routers:
    api-enterprise:
      rule: "Host(`api.example.com`) && PathPrefix(`/`) && HeaderRegexp(`X-Customer-Tier`, `(enterprise|business)`)"
      middlewares:
        - auth-with-tier
      entryPoints:
        - websecure
      tls: {}
      service: stable-backend

    api-free:
      rule: "Host(`api.example.com`) && PathPrefix(`/`) && Header(`X-Customer-Tier`, `free`)"
      middlewares:
        - auth-with-tier
      entryPoints:
        - websecure
      tls: {}
      service: new-version

  middlewares:
    auth-with-tier:
      forwardAuth:
        address: "http://auth-service:8080/validate"
        authResponseHeaders:
          - X-Customer-Tier
          - X-Customer-Id
          - X-User-Email

  services:
    stable-backend:
      loadBalancer:
        servers:
          - url: "http://api-v1-stable:8080"
    new-version:
      loadBalancer:
        servers:
          - url: "http://api-v2-canary:8080"

Поддержка Knative

Для начала включаем провайдера в самом traefik

experimental:
  knative: true
providers:
  knative:
    namespaces:
      - "serverless-apps"
      - "production"

И описываем сервис

---
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: whoami
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: traefik/whoami
          ports:
            - containerPort: 80
          env:
            - name: WHOAMI_NAME
              value: "Knative Test Service"

Выполняем запрос к сервису

$ curl http://whoami.default.example.com

Name: Knative Test Service

На текущий момент времени уже версия 3.6.1