Примітки до оновлення 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"

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

Оновлення ambient з проксі DNS

Для оновлення до Istio 1.24.0 у режимі Ambient з параметром cni.ambient.dnsCapture=true, користувачам потрібно виконати певний набір кроків для оновлення:

  1. Оновлення Istio CNI
  2. Перезапуск всіх робочих навантажень, що перейшли в режим ambient
  3. Оновлення Ztunnel

Якщо цього не зробити, це призведе до збоїв у процесі розпізнавання DNS. Якщо це станеться, ви можете перезапустити робочі навантаження, щоб розвʼязати проблему.

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

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

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

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

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

Завдяки цій зміні позасмугове встановлення та оновлення Istio CRD за допомогою команди kubectl під час використання Helm більше не потрібне.

Якщо ви не використовуєте Helm для встановлення, шаблонування або керування ресурсами Istio, ви можете продовжити робити це і встановити CRD вручну за допомогою kubectl apply -f manifests/charts/base/files/crd-all.gen.yaml.

Якщо ви раніше встановлювали 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, щоб отримати простір імен учасника.

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

Сумісність з istio-csr cert-manager’а

У цьому випуску Istio вводить посилені перевірки валідації в gRPC-звʼязку з панеллю управління. Зверніть увагу, що це впливає лише на внутрішнє використання gRPC в Istio, а не на трафік користувачів.

Хоча на панель управління Istio це не впливає, це впливає на популярну реалізацію стороннього центру сертифікації [istio-csr] (https://github.com/cert-manager/istio-csr). Хоча це було виправлено, на момент написання статті ще не було випущено версії з виправленням (v0.12.0 не має виправлення).

Тим часом цю проблему можна вирішити, встановивши Istio з наступними налаштуваннями:

meshConfig:
  defaultConfig:
    proxyMetadata:
      GRPC_ENFORCE_ALPN_ENABLED: "false"

Якщо у вас виникла ця проблема, ви побачите повідомлення про помилку на кшталт «transport: authentication handshake failed: credentials: cannot check peer: missing selected ALPN property».