Kubernetes Gateway API v1.7.0 перевів повторні спроби HTTPRoute у канал Standard

29 жовтня 2026 року відбувся реліз Kubernetes Gateway API v1.7.0. Головною зміною стало переведення конфігурації повторних спроб (retries) для HTTPRoute до каналу Standard. Поля retry.codes, retry.attempts та retry.backoff отримали статус стабільних, що замінює використання специфічних для окремих контролерів анотацій.

Зміни у специфікації Gateway API v1.7.0

Раніше політика повторних спроб для HTTPRoute вимагала підключення каналу Experimental і встановлення відповідного набору CRD. У версії v1.7.0 ці три поля переведені у статус Standard. Водночас логіка backoff та поведінка jitter залишаються залежними від реалізації конкретного контролера.

Також оновилися назви перевірок відповідності (conformance): старі ознаки HTTPRouteRetry та HTTPRouteRetryBackendTimeout видалено, а замість них додано стандартні HTTPRouteRetryCodes та HTTPRouteRetryConnectionError.

Серед нових експериментальних можливостей у версії v1.7.0 з'явилися:

• маршрутизація адрес шлюзів (Gateway address routability);
• словники атрибутів (attribute dictionaries);
• збереження сесій бекенду (backend session persistence);
• фільтри до маршрутизації (pre-routing filters);
• посилання на ClusterTrustBundle;
• політика телеметрії (telemetry policy).

Раніше у версії v1.5 до каналу Standard перейшли ListenerSet, TLSRoute, CORS-фільтр для HTTPRoute, валідація клієнтських сертифікатів, вибір сертифіката для ініціації TLS та ReferenceGrant. У релізі v1.6 статус Standard також отримали ресурси TCPRoute та UDPRoute.

Розбіжність версій між специфікацією та Cilium 1.20.4

Попри вихід специфікації Gateway API v1.7.0, офіційна документація Cilium версії 1.20.4 станом на листопад 2026 року заявляє про підтримку Gateway API v1.6.3 і потребує встановлення CRD саме версії v1.6.3. Керівництво з оновлення лінійки Cilium 1.20 вказує версію v1.6.1 як мінімально необхідну, зокрема через перехід TLSRoute із v1alpha2 у v1.

Документація Cilium 1.20.4 досі позначає повторні спроби HTTPRoute як експериментальну функцію. Безпосереднє застосування маніфестів CRD версії v1.7.0 до контролера, скомпільованого під v1.6.3, є непідтримуваною комбінацією, яка може перевести об'єкт Gateway у невизначений стан.

У розробці перебуває версія Cilium 1.21 (опубліковано пререліз 1.21.0-pre.4), де заявлено додавання валідації клієнтських сертифікатів (mTLS), параметрів версії TLS для слухачів та виправлення порядку маршрутів. Проте цей випуск ще не є стабільним.

Особливості розгортання та тестування на Cilium

При інтеграції Cilium як CNI та Gateway API контролера діють такі правила:

• Контролер Cilium вимагає заміни kube-proxy (kubeProxyReplacement: true) і відключення дефолтного CNI в тестових кластерах kind.
• CRD Gateway API обов'язково мають бути встановлені до запуску Cilium, інакше оператор пропускає реєстрацію контролера шлюзів.
• Для перевірки роботи повторних спроб використовується експериментальний бандл CRD v1.6.3, після чого налаштування тестуються практичними запитами проти бекенду, який імітує помилки HTTP 503.
• Маршрутизація трафіку між різними просторами імен за замовчуванням заблокована і вимагає обов'язкового створення ресурсу ReferenceGrant у цільовому просторі імен.