Gateway API v1.3.0: Віддзеркалення запитів, CORS та інші новації

Головна — News — Gateway API v1.3.0: Віддзеркалення запитів, CORS та інші новації

Приєднуйтесь до спільноти Kubernetes SIG Network, щоб відзначити загальну доступність Gateway API v1.3.0, яка була випущена 24 квітня 2025 року. Після ретельного тестування та перевірки відповідності, провідні реалізації — Cilium 1.14, Envoy Gateway v1.4.0, Airlock Microgateway 4.6 та Istio 1.27 — вже впровадили ці функції, що свідчить про швидке прийняття нововведень в індустрії.

Перехід до стандартного каналу

Перехід функції відображення запитів на основі відсотків до стандартного каналу означає важливий етап у стабільності API, що підтримується гарантіями семантичного версіонування згідно з Політикою версіонування Gateway API. Оператори тепер можуть оновлюватися з упевненістю, знаючи, що зворотна сумісність буде збережена.

Відображення запитів на основі відсотків

Керівники: Ліор Лібман, Джейк Беннерт • Дивіться GEP-3171.

Покращене відображення HTTP запитів тепер підтримує відсоткову та дробову вибірку. Шлюзи реалізують консистентно-хешовані кошики для рівномірного розподілу трафіку відображення, зменшуючи упередженість при високих запитах. Оператори можуть вказувати ціле число відсотків (0–100) або дробову частку, що зменшує навантаження на контрольну площину.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-filter-mirror
spec:
  parentRefs:
    - name: mirror-gateway
  hostnames:
    - mirror.example
  rules:
    - backendRefs:
        - name: foo-v1
          port: 8080
      filters:
        - type: RequestMirror
          requestMirror:
            backendRef:
              name: foo-v2
              port: 8080
            percent: 42  # вибірка відсотків

Додатки до експериментального каналу

Експериментальні API тепер доступні під gateway.networking.x-k8s.io з префіксом “X”. Це ізоляція забезпечує безпечне тестування нових функцій до їх переходу в стандартний статус.

Фільтрація CORS

Керівники: Лян Лі, Ейал Пазз, Роб Скотт • Дивіться GEP-1767.

Реалізація протоколу CORS Fetch Standard на рівні шлюзу зменшує навантаження на управління заголовками з боку сервісів. Налаштовувані поля включають allowOrigins, allowMethods, allowHeaders, exposeHeaders, allowCredentials та maxAge. Це централізує політику безпеки та зменшує складність мікросервісів.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
spec:
  parentRefs:
    - name: http-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /resource/foo
      filters:
        - type: CORS
          cors:
            allowOrigins: ["*"]
            allowMethods: ["GET","HEAD","POST"]
            allowHeaders: ["Accept","Content-Type"]

XListenerSets (Стандартизоване злиття слухачів)

Керівник: Дейв Протасовський • Дивіться GEP-1713.

XListenerSets відокремлюють конфігурацію слухачів і TLS від об’єктів Gateway, що дозволяє командам керувати сертифікатами у власних просторах імен. Шлюзи визначають allowedListeners, щоб контролювати, які XListenerSets можуть підключатися, що полегшує багатокористувацькі розгортання та ротацію сертифікатів через інтеграції з cert-manager.

Бюджети повторних спроб (XBackendTrafficPolicy)

Керівники: Ерік Біishop, Майк Морріс • Дивіться GEP-3388.

XBackendTrafficPolicy об’єднує управління навантаженням і контролем повторних спроб в один CRD. Новий параметр retryConstraint.budget обмежує кількість повторних спроб до відсотка активних запитів протягом ковзного вікна, запобігаючи бурям повторних спроб і згладжуючи сплески трафіку для стабільності бекенду.

apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackendTrafficPolicy
spec:
  retryConstraint:
    budget: { percent: 20, interval: 10s }
    minRetryRate:
      count: 3
      interval: 1s

Аналіз продуктивності та масштабованості

Тестування CNCF показує, що відображення на основі відсотків споживає <5% додаткових ресурсів CPU на Envoy при 100 kRPS, масштабуючись лінійно. Рекомендуємо починати з вибірки менше 15% у виробництві та моніторити за допомогою гістограм Prometheus.

Розгляд питань безпеки

Централізація CORS та TLS зменшує складність з боку сервісів, але вимагає суворого контролю доступу (RBAC) на CRD. Контролери повинні перевіряти простори імен certificateRefs, щоб запобігти ескалації привілеїв. Журнали аудиту на рівні API-сервера допомагають виявляти несанкціоновані зміни слухачів.

Найкращі практики реалізації

Корелюйте вибірку відображення з метриками канарок у Grafana для оцінки впливу на продуктивність.

Обмежте CORS до явних джерел у виробництві, щоб зменшити площу можливих атак.

Використовуйте XListenerSets для ротації сертифікатів, інтегруючись з ACME-операторами.

Встановлюйте бюджети повторних спроб обережно — бібліотеки на стороні клієнта обробляють повторні спроби по-різному (наприклад, HTTP/2 проти gRPC).

Спробуйте це

Встановіть CRD Gateway API на Kubernetes 1.26+ через Посібник з початку роботи. Експериментальні маніфести доступні під config/crd/experimental/. Сумісні контролери включають:

Airlock Microgateway 4.6

Cilium 1.14 (основний)

Envoy Gateway v1.4.0

Istio 1.27-dev

Долучайтеся

Вносіть свій вклад у Gateway API на GitHub, пропонуйте GEP або приєднуйтесь до зустрічей SIG Network, щоб допомогти формувати майбутні випуски.