Примітки до оновлення Istio 1.24

Важливі зміни, на які слід звернути увагу при оновленні до Istio 1.24.0.

Nov 7, 2024

Коли ви оновлюєтесь з Istio 1.23.x до Istio 1.24.x, будь ласка, зверніть увагу на зміни на цій сторінці. Ці примітки деталізують зміни, які навмисно порушують зворотну сумісність з Istio 1.23.x. Примітки також згадують зміни, які зберігають зворотну сумісність, одночасно вводячи нову поведінку. Зміни включені лише в тому випадку, якщо нова поведінка може бути несподіваною для користувача Istio 1.23.x.

Оновлені профілі сумісності

Для підтримки сумісності зі старішими версіями, Istio 1.24 вводить новий профіль сумісності 1.23 профіль сумісності та оновлює інші профілі для врахування змін в Istio 1.24.

Цей профіль встановлює такі значення:

ENABLE_INBOUND_RETRY_POLICY: "false"
EXCLUDE_UNSAFE_503_FROM_DEFAULT_RETRY: "false"
PREFER_DESTINATIONRULE_TLS_FOR_EXTERNAL_SERVICES: "false"
ENABLE_ENHANCED_DESTINATIONRULE_MERGE: "false"
PILOT_UNIFIED_SIDECAR_SCOPE: "false"
ENABLE_DEFERRED_STATS_CREATION: "false"
BYPASS_OVERLOAD_MANAGER_FOR_STATIC_LISTENERS: "false"

Дивіться індивідуальні примітки щодо змін та оновлень для отримання додаткової інформації.

Istio CRD стандартно шаблонізовані та можуть бути встановлені та оновлені через helm install istio-base

Це змінює спосіб оновлення CRD. Раніше ми рекомендували:

Ця зміна дозволяє:

Раніше це працювало лише за певних умов, і при використанні певних прапорців встановлення могло призводити до генерації CRD, які не можна було оновити через Helm і потребували ручного втручання для виправлення.

Як наслідок цього, мітки на CRD змінено для відповідності іншим ресурсам, встановленим через Helm.

Якщо ви раніше встановлювали або оновлювали CRD за допомогою kubectl apply, а не Helm, ви можете продовжити робити це.

Якщо ви раніше встановлювали CRD за допомогою helm install istio-base АБО kubectl apply, ви можете почати безпечно оновлювати Istio CRD за допомогою helm upgrade istio-base з цієї та всіх наступних версій, після того як ви виконаєте нижче вказані команди kubectl для одноразової міграції:

Якщо бажано, можна згенерувати застарілі мітки, встановивши base.enableCRDTemplates=false під час helm install base, але ця опція буде видалена в наступних версіях.

Чарт istiod-remote замінено на профіль remote

Встановлення кластерів istio з віддаленою/зовнішньою панеллю управління через Helm ніколи не було офіційно задокументовано або стабільним. Це змінює спосіб встановлення кластерів, які використовують віддалений екземпляр istio, підготовляючи документацію з цього питання.

Чарт istiod-remote був обʼєднаний з регулярним чартом istio-discovery.

Раніше:

З цією зміною:

Зверніть увагу, що, як зазначено у попередній примітці щодо оновлень, тепер встановлення чарта istio-base є обовʼязковим як для локальних, так і для віддалених кластерів.

Зміни у сфері дії Sidecar

Під час обробки сервісів Istio має різні стратегії вирішення конфліктів. Історично ці стратегії дещо відрізнялися, коли користувач мав ресурс Sidecar, порівняно з тим, коли він його не мав. Це застосовувалося навіть у випадку, якщо ресурс Sidecar містив лише egress: "*/*", що повинно було бути тим самим, як не мати його взагалі.

У цій версії поведінка між двома варіантами була уніфікована:

Багато сервісів, визначених з одним і тим самим ім’ям хоста

Поведінка раніше, без Sidecar: надавати перевагу Kubernetes Service (а не ServiceEntry), інакше вибрати будь-який випадковий. Поведінка раніше, з Sidecar: надавати перевагу сервісу в тій самій простору імен, що і проксі, інакше вибрати будь-який випадковий. Нова поведінка: надавати перевагу сервісу в тій самій простору імен, що і проксі, потім Kubernetes Service (не ServiceEntry), інакше вибрати будь-який випадковий.

Багато маршрутів API Gateway, визначених для одного сервісу

Поведінка раніше, без Sidecar: надавати перевагу локальному простору імен проксі для дозволу перевизначення споживачами. Поведінка раніше, з Sidecar: випадковий порядок. Нова поведінка: надавати перевагу локальному простору імен проксі для дозволу перевизначення споживачами.

Стару поведінку можна зберегти тимчасово, встановивши PILOT_UNIFIED_SIDECAR_SCOPE=false.

Стандартизація атрибутів метаданих учасників

Вирази CEL в API телеметрії повинні використовувати стандартні атрибути Envoy замість власних розширених атрибутів Wasm.

Метадані учасників тепер зберігаються в filter_state.downstream_peer та filter_state.upstream_peer замість filter_state["wasm.downstream_peer"] та filter_state["wasm.upstream_peer"]. Метадані вузлів зберігаються в xds.node замість node. Атрибути Wasm повинні бути повністю кваліфікованими, наприклад, використовуйте filter_state["wasm.istio_responseClass"] замість istio_responseClass.

Оператор присутності можна використовувати для сумісних виразів у змішаному проксі-сценарії, наприклад, has(filter_state.downstream_peer) ? filter_state.downstream_peer.namespace : filter_state["wasm.downstream_peer"].namespace, щоб отримати простір імен учасника.

Метадані учасників використовують кодування багажу з наступними атрибутами полів: