mirror of https://github.com/istio/istio.io.git
[uk] Sync Ukrainian translation with upstream documentation (#16473)
* Add Ukrainian language support * [uk] operations * [uk] setup * Update Ukrainian content for ambient mode and fix logo paths * [uk] Sync Ukrainian translation with upstream documentation * [uk] Re GKE platform profile #16035 * [uk] Sync Ukrainian translation with upstream documentation * [uk] sync with upstream * [uk] Sync Ukrainian translation with upstream documentation
This commit is contained in:
Andrii Holovin
GitHub
parent
231bb03b00
commit
0b560196bb
Binary file not shown.
|
After Width: | Height: | Size: 3.3 MiB |
|
|
@ -0,0 +1,102 @@
|
|||
---
|
||||
title: "Istio на KubeCon Europe 2025"
|
||||
description: Короткий огляд Istio на KubeCon Europe, в Excel London.
|
||||
publishdate: 2025-04-25
|
||||
social_image: istioday-welcome.jpg
|
||||
attribution: "Faseela K, від імені Керівного комітету Istio"
|
||||
keywords: [Istio Day,IstioCon,Istio,conference,KubeCon,CloudNativeCon]
|
||||
---
|
||||
|
||||
З 1 по 4 квітня в Лондоні зібралася спільнота розробників програмного забезпечення з відкритим вихідним кодом та хмарних обчислень на першому KubeCon 2025 року. Чотириденна конференція, організована Cloud Native Computing Foundation, була «великою» для Istio, адже наша присутність була помітна майже скрізь - від основних доповідей до проєктного павільйону.
|
||||
|
||||
Ми розпочали свою діяльність у Лондоні з Istio Day — заходу, який відбувся 1 квітня одночасно з KubeCon та CloudNativeCon. Захід був добре сприйнятий, демонструючи уроки, отримані під час запуску Istio у промислову експлуатацію, практичний досвід та участь супровідників з усієї екосистеми Istio.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./istioday-welcome.jpg"
|
||||
caption="Istio Day Europe 2025, ласкаво просимо"
|
||||
>}}
|
||||
|
||||
Istio Day розпочався з [вступної доповіді](https://youtu.be/v10UpNQIoT0?si=CEOwz3nMMPVP7XWE) від голів програмного комітету, Кіта Маттікса та Деніса Жаннота. Після доповіді відбувся [довгоочікуваний виступ від Microsoft про підтримку Istio Ambient Mesh в Windows](https://youtu.be/sULnWlj8sR8?si=ewQ2hgdEZ5ZSRGuK). Ми мали дуже цікаву доповідь Ліора Лібермана з Google та Еріка Паріенті з Riskified [про архітектуру Istio для великомасштабних розгортань](https://youtu.be/GNi9ZJFuups?si=7gjH_tW6dURyJOLZ), після чого відбувся виступ супровідників Kiali Йосуне Кордоби та Айка Овсепяна з RedHat про [усунення несправностей Istio ambient mesh з Kiali 2.0](https://youtu.be/kodNy436ND0?si=Qyh4ebtfnYV2H6Ap).
|
||||
|
||||
{{< image width="75%"
|
||||
link="./istioday-session-1.jpg"
|
||||
caption="Istio Day Europe 2025, сесія в Kiali"
|
||||
>}}
|
||||
|
||||
Мультикластерність Istio — завжди актуальна тема, і Памела Ернандес з BlackRock розкрила її у своїй доповіді [«Навігація лабіринтом мультикластерності Istio»](https://youtu.be/WpEkfVGWmd8?si=amUJ2sbZVq_sDV3a), занурившись у складнощі реалізації мультикластерної сервісної мережі Istio в масштабі, висвітливши модель hub-and-spoke. Аудиторія була в захваті, коли Денис Жанно з Solo.io [провів живий, репрезентативний бенчмарк в масштабі з Istio Ambient](https://youtu.be/oi4TpxuIYXk?si=EBITga8tgsKvII9-), розвінчавши всі міфи про накладні витрати і складність mesh-мережі. На заході було продемонстровано, як Istio відіграє ключову роль в управлінні трафіком і забезпеченні безпеки даних, що в кінцевому підсумку дозволяє створити безпечну та ефективну платформу штучного інтелекту, яка відповідає корпоративним стандартам, коли [SAP представила виклики платформи GenAI в багатокористувацьких середовищах](https://youtu.be/j2jS_62N19I?si=Szz0ZFURpryD9H0H). Завершив доповіді виступ Роба Салмонда з SuperOrbit на тему [Як отримати допомогу в Istio](https://youtu.be/WNqEQrrQnMs?si=LJaDDVqRX_03kz4B), в якому йшлося про те, куди краще звертатися, як ставити правильні запитання та уникати поширених помилок.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./istioday-session-2.jpg"
|
||||
caption="Istio Day Europe 2025, Jam packed сесії"
|
||||
>}}
|
||||
|
||||
Слайди всіх сесій можна знайти в [розкладі Istio Day EU 2025](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/istio-day/).
|
||||
|
||||
Наша присутність на конференції не закінчилася на Istio Day. Перший день KubeCon + CloudNativeCon розпочався з [доповіді про проєкт Istio](https://youtu.be/B7lpXPZPFoI?si=im1PIxsUdHyIXKKk) від Мітча Коннорса.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./project-update.jpg"
|
||||
caption="Istio Day Europe 2025, доповіді проєктів"
|
||||
>}}
|
||||
|
||||
На головній сцені було кілька ключових доповідей, в яких згадувався Istio. Під час виступу в день відкриття Васу Чандрасехара з SAP оголосив про заснування [Фонду NeoNephos](https://youtu.be/85MDID9Ju04?si=qLGfpbZBC6IMuT_K) в рамках Linux Foundation Europe — великого кроку вперед для цифрового суверенітету в Європі, і Istio був згаданий як проєкт, що підтримується Фондом.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./kubecon-keynote-1.jpg"
|
||||
caption="KubeCon Europe 2025, Announcing NeoNephos"
|
||||
>}}
|
||||
|
||||
Стівен Конноллі поділився досвідом роботи HSBC з Kubernetes, а також поділився [планами щодо впровадження Istio ambient mesh](https://youtu.be/6D8EZ1fZyh4?si=GvcSG28Lnuy5eTLD), щоб заощадити на витратах. Компанія Ant Group, яка отримала нагороду CNCF End User Award, також [розповіла про використання Istio](https://youtu.be/bjCT7-mFYEo?si=AUMoTzN713_qUVhh). Ідіт Левін та Кіт Бабо з Solo.io анонсували [безкоштовний інструмент для оцінки та міграції](https://youtu.be/-k1CdrRAGMM?si=sDKdfJG5GDn7FWfw) для Istio ambient mesh. Фасіла К виступила з доповіддю на панелі кінцевих користувачів телекомунікаційних компаній на тему [Еволюція хмарних технологій в телекомі](https://youtu.be/qj9q_-S91L8?si=8r3f1d396DSzp1Mg) разом з Vodafone, Orange і Swisscom, в якій знову підкреслила використання Istio для мережевих функцій телекомунікаційних компаній.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./kubecon-keynote-2.jpg"
|
||||
caption="KubeCon Europe 2025, еволюція Cloud Native в телекомі"
|
||||
>}}
|
||||
|
||||
Також добре була сприйнята [трек-сесія мейнтейнерів Istio](https://youtu.be/poBOYc_EkpA?si=WtxYWvzU4MErnOq4), де Реймонд Вонг з Forbes приєднався до мейнтейнерів Луїса Райана та Ліна Суна, щоб обговорити шлях Forbes до Istio ambient у промисловому використанні. Зал був переповнений, і після цього було багато запитань.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./maintainer-track.jpg"
|
||||
caption="KubeCon Europe 2025, трек-сесія мейнтейнерів Istio"
|
||||
>}}
|
||||
|
||||
Під час сесії Contribfest, яку провели Мітч Коннорс (Microsoft), Деніел Хоутон (Solo.io) та Джекі Маертенс (Microsoft), вони розповіли про структуру репозиторіїв Istio, де живе код кожного компонента, про те, як розвʼязувати проблеми, налаштовувати та використовувати інтеграційні тести, робити перші внески в проєкт, а також про ресурси для створення та запуску середовищ розробки та про те, куди звертатися за допомогою.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./contrib-fest.jpg"
|
||||
caption="KubeCon Europe 2025, сесія Istio contrib fest"
|
||||
>}}
|
||||
|
||||
Розробники Istio, Лін Сун та Фасіла К, провели захід з автограф-сесії [книги Istio Phippy](https://youtu.be/mtqUtbMaSDw?si=qB4vbo4ytUL8eLO_) «Іззі рятує день народження».
|
||||
|
||||
{{< image width="75%"
|
||||
link="./izzy-book-signing.jpg"
|
||||
caption="KubeCon Europe 2025, Іззі рятує день народження, автограф-сесія"
|
||||
>}}
|
||||
|
||||
Наступні сесії на KubeCon були засновані на Istio, і майже всі вони збирали величезну аудиторію:
|
||||
|
||||
* [Project Lightning Talk: Що нового в Istio?](https://youtu.be/B7lpXPZPFoI?si=im1PIxsUdHyIXKKk)
|
||||
* [Спонсорська демонстрація: перенесення агентного ШІ в хмарні середовища - знайомство з kagent](https://youtu.be/-k1CdrRAGMM?si=sDKdfJG5GDn7FWfw)
|
||||
* [«Іззі рятує день народження» — сюжетна демонстрація, що досліджує магію Service Mesh](https://youtu.be/mtqUtbMaSDw?si=qB4vbo4ytUL8eLO_)
|
||||
* [Trino та управління даними в Kubernetes](https://youtu.be/vCfehltPKxk?si=WHnMknL_O9K2qKuS)
|
||||
* [Подорож у New York Times: Чи зникає в інфраструктурі Service Mesh без Sidecar?](https://youtu.be/9U3WMez9q74?si=_lHKUcuTKCCJ2gGQ)
|
||||
* [Lightning Talk: Висока доступність з «503: Unavailable»](https://youtu.be/0adVcinYGC8?si=b3p6LDgxf2RvQPHK)
|
||||
|
||||
Istio мав стенд у проєктному павільйоні, і більшість запитань стосувалися розширюваності та багатокластерних удосконалень. Багато наших учасників і супровідників пропонували підтримку в нашому стенді, допомагаючи нам відповісти на всі запитання наших користувачів.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./istio-booth-1.jpg"
|
||||
caption="KubeCon Europe 2025, стенд Istio"
|
||||
>}}
|
||||
|
||||
Багато з наших членів TOC також запропонували підтримку на стенді, де відбулося багато цікавих дискусій про мережу Istio ambient mesh, в тому числі і на тему ambient mesh.
|
||||
|
||||
{{< image width="75%"
|
||||
link="./istio-booth-2.jpg"
|
||||
caption="KubeCon Europe 2025, More support at Istio Kiosk"
|
||||
>}}
|
||||
|
||||
Ми хотіли б висловити нашу щиру подяку нашому золотому спонсору Microsoft Azure за підтримку Istio Day Europe! І останнє, але не менш важливе, ми хотіли б подякувати членам програмного комітету Istio Day за всю їхню важку роботу і підтримку!
|
||||
|
||||
[До зустрічі в Атланті в листопаді 2025 року!](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 143 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.5 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 331 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 534 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 242 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 437 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 488 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 122 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.8 MiB |
|
|
@ -0,0 +1,44 @@
|
|||
---
|
||||
title: "Istio на KubeCon Europe, до зустрічі в Лондоні!"
|
||||
description: Зустрічайте Istio на KubeCon + CloudNativeCon Europe 2025.
|
||||
publishdate: 2025-03-25
|
||||
attribution: "Faseela K, від імені Керівного комітету Istio"
|
||||
social_image: kubecon-eu.png
|
||||
keywords: [Istio Day,Istio,conference,KubeCon,CloudNativeCon]
|
||||
---
|
||||
|
||||
{{< image width="75%"
|
||||
link="./kubecon-eu.png"
|
||||
alt="KubeCon + CloudNativeCon Europe, квітень 1-4, 2025, Лондон. #KubeCon"
|
||||
>}}
|
||||
|
||||
Дивовижна лінійка заходів Istio чекає на вас у Лондоні на [KubeCon + CloudNativeCon Europe 2025](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/)!
|
||||
|
||||
- Приєднуйтесь до [Istio Project Meeting](https://sched.co/1uSO5), що відбудеться на [Maintainer Summit](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/features-add-ons/maintainer-summit/).
|
||||
|
||||
{{< image width="75%"
|
||||
link="./maintainer-summit.png"
|
||||
alt="Maintainer Summit, березень 31, 2025, Лондон. #CNmaintainersummit"
|
||||
>}}
|
||||
- Приходьте на спільний захід [Istio Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/istio-day/).
|
||||
|
||||
{{< image width="75%"
|
||||
link="./istio-day.png"
|
||||
alt="IstioDay, кввітень 1, 2025, Лондон. #istioday"
|
||||
>}}
|
||||
|
||||
- Відвідайте сесію Istio Maintainers' Track: [Istio: минуле, сьогодення та майбутнє проєкту та спільноти] (https://sched.co/1tczp)
|
||||
- Завітайте на сесію Istio Contribfest: [Посібник для початківців по внеску в Istio — практичний воркшоп по розробці та внеску] (https://sched.co/1wau5)
|
||||
|
||||
- Додайте до свого розкладу наступні сесії KubeCon, кожна з яких присвячена Istio:
|
||||
- [Project Lightning Talk: Що нового в Istio?](https://sched.co/1tcvB)
|
||||
- [Спонсорована демонстрація: Перенесення агентного ШІ в хмарні середовища — знайомство з kagent](https://sched.co/1x0Gh)
|
||||
- [«Izzy Saves the Birthday» — сюжетна демонстрація в реальному часі, що досліджує магію Service Mesh](https://sched.co/1txFn)
|
||||
- [Trino та управління даними на Kubernetes](https://sched.co/1txF1)
|
||||
- [Подорож у New York Times: Чи зникає в інфраструктурі сервісна мережа без Sidecar?](https://sched.co/1txEX)
|
||||
- [Lightning Talk: Висока доступність за допомогою «503: Unavailable»](https://sched.co/1txCk)
|
||||
|
||||
- Поспілкуйтеся з розробниками та користувачами на стенді Istio в Павільйоні проєктів протягом усього заходу.
|
||||
- Ми також організуємо автограф-сесію Istio Phippy, яка відбудеться паралельно з сесією «Іззі рятує день народження». Приєднуйтесь до розмови та отримайте безкоштовний примірник книги з автографом від авторів!
|
||||
|
||||
Слідкуйте за нами в [X](https://x.com/istiomesh), [LinkedIn](https://www.linkedin.com/company/istio/) або [Bluesky](https://bsky.app/profile/istio.io), щоб отримувати новини з події в прямому ефірі. До зустрічі!
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
|
|
@ -0,0 +1,276 @@
|
|||
---
|
||||
title: "Випущено Sail Operator 1.0.0: керуйте Istio за допомогою оператора"
|
||||
description: Зануртеся в основи Sail Operator і перегляньте приклад, щоб побачити, як легко використовувати його для управління Istio.
|
||||
publishdate: 2025-04-03
|
||||
attribution: "Francisco Herrera - Red Hat"
|
||||
keywords: [istio,operator,sail,incluster,istiooperator]
|
||||
---
|
||||
|
||||
[Sail Operator](https://github.com/istio-ecosystem/sail-operator) — це проєкт спільноти, започаткований Red Hat для створення сучасного [оператора](https://www.redhat.com/en/topics/containers/what-is-a-kubernetes-operator) для Istio. [Вперше анонсований у серпні 2024 року](/blog/2024/introducing-sail-operator/), ми раді повідомити, що Sail Operator тепер є GA з чіткою місією: спростити та впорядкувати управління Istio у вашому кластері.
|
||||
|
||||
## Спрощене розгортання та керування {#simplified-deployment--management}
|
||||
|
||||
Sail Operator розроблений, щоб зменшити складність встановлення та запуску Istio. Він автоматизує ручні завдання, забезпечуючи послідовну, надійну і нескладну роботу від початкового встановлення до постійного обслуговування та оновлення версій Istio у вашому кластері. API-інтерфейси Sail Operator побудовані на основі API-інтерфейсів Helm chart Istio, що означає, що всі конфігурації Istio доступні через значення CRD Sail Operator.
|
||||
|
||||
Ми рекомендуємо користувачам ознайомитися з нашою [документацією](https://github.com/istio-ecosystem/sail-operator/tree/main/docs), щоб дізнатися більше про цей новий спосіб керування середовищем Istio.
|
||||
|
||||
Основними ресурсами, що входять до складу Sail Operator, є
|
||||
|
||||
* `Istio`: керує панеллю управлінняIstio.
|
||||
* `IstioRevision`: представляє ревізію панелі управління.
|
||||
* `IstioRevisionTag`: представляє стабільний теґ ревізії, який функціонує як псевдонім для ревізії панелі управління Istio.
|
||||
* `IstioCNI`: керує агентом вузла CNI Istio.
|
||||
* `ZTunnel`: керує режимом оточення ztunnel DaemonSet (функція Alpha).
|
||||
|
||||
{{< idea >}}
|
||||
Якщо ви мігруєте з [since-removed Istio in-cluster operator](/blog/2024/in-cluster-operator-deprecation-announcement/), ви можете ознайомитися з цим розділом нашої [документації](https://github.com/istio-ecosystem/sail-operator/tree/main/docs#migrating-from-istio-in-cluster-operator), де ми пояснюємо еквівалентність ресурсів, або ви також можете спробувати наш [конвертер ресурсів](https://github.com/istio-ecosystem/sail-operator/tree/main/docs#converter-script), щоб легко перетворити ваш ресурс `IstioOperator` на ресурс `Istio`.
|
||||
{{< /idea >}}
|
||||
|
||||
## Основні функції та підтримка {#main-features-and-support}
|
||||
|
||||
- Кожним компонентом панелі управління Istio керує Sail Operator незалежно за допомогою спеціальних власних ресурсів Kubernetes (CR). Sail Operator надає окремі CRD для таких компонентів, як `Istio`, `IstioCNI` та `ZTunnel`, що дозволяє вам налаштовувати, керувати та оновлювати їх окремо. Крім того, існують CRD для `IstioRevision` та `IstioRevisionTag` для керування ревізіями панелі управління Istio.
|
||||
- Підтримка декількох версій Istio. Наразі підтримується версія 1.0.0: 1.24.3, 1.24.2, 1.24.1, 1.23.5, 1.23.4, 1.23.3, 1.23.0.
|
||||
- Підтримуються дві стратегії оновлення: `InPlace` і `RevisionBased`. Для отримання додаткової інформації про підтримувані типи оновлень зверніться до нашої документації.
|
||||
- Підтримка багатокластерної [моделі розгортання](/docs/setup/install/multicluster/) Istio: multi-primary, primary-remote, зовнішня панель управління. Більше інформації та прикладів у нашій [документації](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md#multi-cluster).
|
||||
- Підтримка режиму Ambient у версії Alpha: зверніться до нашої спеціальної [документації](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/common/istio-ambient-mode.md).
|
||||
- Надбудови управляються окремо від Sail Operator. Вони можуть бути легко інтегровані з Sail Operator, зверніться до цього розділу [документації](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md#addons) за прикладами та додатковою інформацією.
|
||||
|
||||
## Чому зараз? {#why-now}
|
||||
|
||||
Оскільки хмарні архітектури продовжують розвиватися, ми вважаємо, що надійний і зручний оператор для Istio є більш важливим, ніж будь-коли. Sail Operator пропонує розробникам та операційним командам послідовне, безпечне та ефективне рішення, яке є звичним для тих, хто звик працювати з операторами. Його випуск GA сигналізує про зрілість рішення, готового підтримувати навіть найвимогливіші виробничі середовища.
|
||||
|
||||
## Спробуйте {#try-it-out}
|
||||
|
||||
Хочете спробувати Sail Operator?
|
||||
Цей приклад покаже вам, як безпечно оновити панель управління Istio, використовуючи стратегію оновлення на основі ревізій. Це означає, що у вас будуть одночасно працювати дві панелі управління Istio, що дозволить вам легко мігрувати робочі навантаження, мінімізуючи ризик перебоїв у роботі.
|
||||
|
||||
Необхідні умови:
|
||||
|
||||
- Працюючий кластер
|
||||
- Helm
|
||||
- Kubectl
|
||||
- Istioctl
|
||||
|
||||
### Встановіть Sail Operator за допомогою Helm {#install-the-sail-operator-using-helm}
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm repo add sail-operator https://istio-ecosystem.github.io/sail-operator
|
||||
$ helm repo update
|
||||
$ kubectl create namespace sail-operator
|
||||
$ helm install sail-operator sail-operator/sail-operator --version 1.0.0 -n sail-operator
|
||||
{{< /text >}}
|
||||
|
||||
Тепер оператор встановлений у вашому кластері:
|
||||
|
||||
{{< text plain >}}
|
||||
NAME: sail-operator
|
||||
LAST DEPLOYED: Tue Mar 18 12:00:46 2025
|
||||
NAMESPACE: sail-operator
|
||||
STATUS: deployed
|
||||
REVISION: 1
|
||||
TEST SUITE: None
|
||||
{{< /text >}}
|
||||
|
||||
Перевірте, чи працює pod оператора:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pods -n sail-operator
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
sail-operator-56bf994f49-j67ft 1/1 Running 0 87s
|
||||
{{< /text >}}
|
||||
|
||||
### Створіть ресурси `Istio` та `IstioRevisionTag` {#create-istio-and-istiorevisiontag-resources}
|
||||
|
||||
Створіть ресурси `Istio` з версією `v1.24.2` та `IstioRevisionTag`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create ns istio-system
|
||||
$ cat <<EOF | kubectl apply -f-
|
||||
apiVersion: sailoperator.io/v1
|
||||
kind: Istio
|
||||
metadata:
|
||||
name: default
|
||||
spec:
|
||||
namespace: istio-system
|
||||
updateStrategy:
|
||||
type: RevisionBased
|
||||
inactiveRevisionDeletionGracePeriodSeconds: 30
|
||||
version: v1.24.2
|
||||
---
|
||||
apiVersion: sailoperator.io/v1
|
||||
kind: IstioRevisionTag
|
||||
metadata:
|
||||
name: default
|
||||
spec:
|
||||
targetRef:
|
||||
kind: Istio
|
||||
name: default
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
Зверніть увагу, що теґ `IstioRevisionTag` має цільове посилання на ресурс `Istio` з іменем `default`.
|
||||
|
||||
Перевірте стан створених ресурсів:
|
||||
|
||||
- podʼи `istiod` запущено
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pods -n istio-system
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
istiod-default-v1-24-2-bd8458c4-jl8zm 1/1 Running 0 3m45s
|
||||
{{< /text >}}
|
||||
|
||||
- ресурс `Istio` створено
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istio
|
||||
NAME REVISIONS READY IN USE ACTIVE REVISION STATUS VERSION AGE
|
||||
default 1 1 1 default-v1-24-2 Healthy v1.24.2 4m27s
|
||||
{{< /text >}}
|
||||
|
||||
- ресурс `IstioRevisionTag` створено
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istiorevisiontag
|
||||
NAME STATUS IN USE REVISION AGE
|
||||
default NotReferencedByAnything False default-v1-24-2 4m43s
|
||||
{{< /text >}}
|
||||
|
||||
Зверніть увагу, що статус `IstioRevisionTag` має значення `NotReferencedByAnything`. Це повʼязано з тим, що наразі немає ресурсів, які використовують ревізію `default-v1-24-2`.
|
||||
|
||||
### Розгорніть демонстраційний застосунок {#deploy-sample-application}
|
||||
|
||||
Створіть простір імен та позначте його, щоб увімкнути інʼєкцію Istio:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create namespace sample
|
||||
$ kubectl label namespace sample istio-injection=enabled
|
||||
{{< /text >}}
|
||||
|
||||
Після позначення міткою простору імен ви побачите, що статус ресурсу `IstioRevisionTag` зміниться на 'In Use: True', оскільки тепер існує ресурс, який використовує ревізію `default-v1-24-2`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istiorevisiontag
|
||||
NAME STATUS IN USE REVISION AGE
|
||||
default Healthy True default-v1-24-2 6m24s
|
||||
{{< /text >}}
|
||||
|
||||
Розгорніть демонстраційний застосунок:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f {{< github_file >}}/samples/sleep/sleep.yaml -n sample
|
||||
{{< /text >}}
|
||||
|
||||
Переконайтеся, що проксі-версія демонстраційного застосунку збігається з версією панелі управління:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-status
|
||||
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
|
||||
sleep-5fcd8fd6c8-q4c9x.sample Kubernetes SYNCED (78s) SYNCED (78s) SYNCED (78s) SYNCED (78s) IGNORED istiod-default-v1-24-2-bd8458c4-jl8zm 1.24.2
|
||||
{{< /text >}}
|
||||
|
||||
### Оновлення панелі управління Istio до версії 1.24.3 {#upgrade-the-istio-control-plane-to-version-1243}
|
||||
|
||||
Оновіть ресурс `Istio` до нової версії:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl patch istio default -n istio-system --type='merge' -p '{"spec":{"version":"v1.24.3"}}'
|
||||
{{< /text >}}
|
||||
|
||||
Перевірте ресурс `Istio`. Ви побачите, що там є дві версії і обидві 'ready':
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istio
|
||||
NAME REVISIONS READY IN USE ACTIVE REVISION STATUS VERSION AGE
|
||||
default 2 2 2 default-v1-24-3 Healthy v1.24.3 10m
|
||||
{{< /text >}}
|
||||
|
||||
Тег `IstioRevisiontag` тепер посилається на нову ревізію:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istiorevisiontag
|
||||
NAME STATUS IN USE REVISION AGE
|
||||
default Healthy True default-v1-24-3 11m
|
||||
{{< /text >}}
|
||||
|
||||
Існує дві `IstioRevisions`, по одній для кожної версії Istio:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istiorevision
|
||||
NAME TYPE READY STATUS IN USE VERSION AGE
|
||||
default-v1-24-2 True Healthy True v1.24.2 11m
|
||||
default-v1-24-3 True Healthy True v1.24.3 92s
|
||||
{{< /text >}}
|
||||
|
||||
Sail Operator автоматично визначає, чи використовується дана панель управління Istio, і записує цю інформацію в стан «In Use», який ви бачите вище. Наразі всі `IstioRevisions` та наш `IstioRevisionTag` вважаються «In Use»:
|
||||
|
||||
* Стара ревізія `default-v1-24-2` вважається такою, що використовується, оскільки на неї є посилання у sidecar демонстраційного застосунку.
|
||||
* Нова ревізія `default-v1-24-3` вважається такою, що використовується, оскільки на неї посилається теґ.
|
||||
* Теґ вважається таким, що використовується, оскільки на нього посилається простір імен демонстраційного застосунку.
|
||||
|
||||
Переконайтеся, що запущено два pod'и панелі управління, по одному для кожної ревізії:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pods -n istio-system
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
istiod-default-v1-24-2-bd8458c4-jl8zm 1/1 Running 0 16m
|
||||
istiod-default-v1-24-3-68df97dfbb-v7ndm 1/1 Running 0 6m32s
|
||||
{{< /text >}}
|
||||
|
||||
Переконайтеся, що версія проксі-sidecar не змінилася:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-status
|
||||
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
|
||||
sleep-5fcd8fd6c8-q4c9x.sample Kubernetes SYNCED (6m40s) SYNCED (6m40s) SYNCED (6m40s) SYNCED (6m40s) IGNORED istiod-default-v1-24-2-bd8458c4-jl8zm 1.24.2
|
||||
{{< /text >}}
|
||||
|
||||
Перезапустіть pod sample:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl rollout restart deployment -n sample
|
||||
{{< /text >}}
|
||||
|
||||
Переконайтеся, що версія проксі-sidecar оновлена:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-status
|
||||
NAME CLUSTER CDS LDS EDS RDS ECDS ISTIOD VERSION
|
||||
sleep-6f87fcf556-k9nh9.sample Kubernetes SYNCED (29s) SYNCED (29s) SYNCED (29s) SYNCED (29s) IGNORED istiod-default-v1-24-3-68df97dfbb-v7ndm 1.24.3
|
||||
{{< /text >}}
|
||||
|
||||
Коли `IstioRevision` більше не використовується і не є активною ревізією ресурсу `Istio` (наприклад, коли це не та версія, що вказана у полі `spec.version`), Sail Operator видалить її після пільгового періоду, який стандартно становить 30 секунд. Підтвердьте видалення старої панелі управління та `IstioRevision`:
|
||||
|
||||
- Pod старої панелі управління видалено
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pods -n istio-system
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
istiod-default-v1-24-3-68df97dfbb-v7ndm 1/1 Running 0 10m
|
||||
{{< /text >}}
|
||||
|
||||
- Старий ресурс `IstioRevision` видалено
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istiorevision
|
||||
NAME TYPE READY STATUS IN USE VERSION AGE
|
||||
default-v1-24-3 True Healthy True v1.24.3 13m
|
||||
{{< /text >}}
|
||||
|
||||
- Ресурс `Istio`тепер має тільки одну ревізію
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istio
|
||||
NAME REVISIONS READY IN USE ACTIVE REVISION STATUS VERSION AGE
|
||||
default 1 1 1 default-v1-24-3 Healthy v1.24.3 24m
|
||||
{{< /text >}}
|
||||
|
||||
**Вітаємо!** Ви успішно оновили панель управління Istio за допомогою стратегії оновлення на основі ревізій.
|
||||
|
||||
{{< idea >}}
|
||||
Щоб перевірити останню версію Sail Operator, відвідайте нашу [сторінку випусків](https://github.com/istio-ecosystem/sail-operator/releases). Оскільки цей приклад може змінюватися з часом, будь ласка, зверніться до нашої [документації](https://github.com/istio-ecosystem/sail-operator/tree/main/docs#example-using-the-revisionbased-strategy-and-an-istiorevisiontag), щоб переконатися, що ви читаєте найновішу версію.
|
||||
{{< /idea >}}
|
||||
|
||||
## Висновок {#висновок}
|
||||
|
||||
Sail Operator автоматизує ручні завдання, забезпечуючи послідовну, надійну і нескладну роботу від початкового встановлення до поточного обслуговування та оновлення Istio у вашому кластері. Sail Operator є проєктом [istio-екосистеми](https://github.com/istio-ecosystem), і ми заохочуємо вас випробувати його і надати відгуки, щоб допомогти нам поліпшити його, ви можете ознайомитися з нашим [посібником з участі](https://github.com/istio-ecosystem/sail-operator/blob/main/CONTRIBUTING.md) для отримання додаткової інформації про те, як зробити свій внесок у проєкт.
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
title: "Istio публікує результати аудиту безпеки ztunnel"
|
||||
description: Проходить на відмінно.
|
||||
publishdate: 2025-04-18
|
||||
attribution: "Craig Box — Solo.io, для робочої групи з безпеки продуктів Istio"
|
||||
keywords: [istio,security,audit,ztunnel,ambient]
|
||||
---
|
||||
|
||||
Ambient-режим Istio розділяє сервісну мережу на два окремі шари: Обробка 7-го рівня (проксі-сервер «[waypoint proxy](/docs/ambient/usage/waypoint/)»), який, як і раніше, працює за допомогою традиційного проксі-сервера Envoy; і безпечний оверлей («тунель нульової довіри» або «[ztunnel](https://github.com/istio/ztunnel)»), який являє собою [нову кодову базу](/blog/2023/rust-based-ztunnel/), написану з нуля на Rust.
|
||||
|
||||
Ми хочемо, щоб проєкт ztunnel можна було безпечно встановлювати стандартно у кожному кластері Kubernetes, а для цього він має бути безпечним та продуктивним.
|
||||
|
||||
Ми всебічно продемонстрували продуктивність ztunnel, показавши, що він є [способом створення безпечної мережі нульової довіри в Kubernetes з найвищою пропускною здатністю](/blog/2025/ambient-performance/) — забезпечує вищу пропускну здатність TCP, ніж навіть такі внутрішньоядерні засоби передачі даних, як IPsec і WireGuard, і що його продуктивність збільшилася на 75% за останні 4 випуски.
|
||||
|
||||
Сьогодні ми раді підтвердити безпеку ztunnel, опублікувавши [результати аудиту кодової бази](https://ostif.org/wp-content/uploads/2025/04/Istio-Ztunnel-Final-Summary-Report-1.pdf), проведеного [Trail of Bits](https://www.trailofbits.com/).
|
||||
|
||||
Ми хотіли б подякувати [Cloud Native Computing Foundation](https://cncf.io/) за фінансування цієї роботи, а також [OSTIF за її координацію](https://ostif.org/istio-ztunnel-audit-complete/).
|
||||
|
||||
## Обсяг та загальні висновки {#scope-and-overall-findings}
|
||||
|
||||
Istio було оцінено у [2020](/blog/2021/ncc-security-assessment/) та [2023](/blog/2023/ada-logics-security-assessment/), а проксі Envoy [отримав незалежну оцінку](https://github.com/envoyproxy/envoy#security-audit). Обʼєктом цього огляду був новий код в середовищі Istio, компонент ztunnel: зокрема, код, повʼязаний з авторизацією L4, проксіюванням вхідних запитів, безпекою на транспортному рівні (TLS) та управлінням сертифікатами.
|
||||
|
||||
Аудитори заявили, що «кодова база ztunnel добре написана і структурована», і не виявили жодних вразливостей у коді. Три їхні висновки, один середньої тяжкості і два інформаційних, стосуються рекомендацій щодо зовнішніх факторів, включаючи ланцюжок постачання програмного забезпечення і тестування.
|
||||
|
||||
## Результат та запропоновані покращення {#resolution-and-suggested-improvements}
|
||||
|
||||
## Покращення управління залежностями {#improving-dependency-management}
|
||||
|
||||
На момент проведення аудиту у звіті [cargo audit](https://crates.io/crates/cargo-audit) для залежностей ztunnel було показано три версії з актуальними рекомендаціями щодо безпеки. Не було жодних припущень про те, що у залежностях ztunnel можуть бути доступні будь-які вразливі шляхи коду, і супровідники регулярно оновлюють залежності до останніх відповідних версій. Щоб оптимізувати цей процес, ми [застосували Dependabot від GitHub](https://github.com/istio/ztunnel/pull/1400) для автоматизованого оновлення.
|
||||
|
||||
Аудитори вказали на ризик наявності Rust crates у ланцюжку залежностей ztunnel, які або не підтримуються, або підтримуються одним власником. Це поширена ситуація в екосистемі Rust (і взагалі у всьому відкритому коді). Ми замінили два явно ідентифіковані crate.
|
||||
|
||||
### Розширення тестового покриття {#enhancing-test-coverage}
|
||||
|
||||
Команда Trail of Bits виявила, що більшість функціональних можливостей ztunnel добре протестовано, але було виявлено деякі шляхи коду обробки помилок, які не було покрито [тестуванням мутацій](https://mutants.rs/).
|
||||
|
||||
Ми оцінили пропозиції і виявили, що прогалини у покритті, виявлені цими результатами, стосуються як тестового коду, так і коду, який не впливає на коректність.
|
||||
|
||||
Хоча мутаційне тестування корисне для виявлення потенційних областей для покращення, мета не полягає в тому, щоб досягти точки, коли звіт не повертає жодних результатів. Мутації можуть не спричинити збоїв тестування в ряді очікуваних випадків, таких як поведінка без «правильного» результату (наприклад, повідомлення журналу), поведінка, яка впливає лише на продуктивність, але не на коректність (вимірюється за межами області, про яку знає інструментарій), шляхи коду, які мають кілька способів досягти того самого результату, або код, який використовується лише для тестування. Тестування та безпека є основним пріоритетом для команди Istio, і ми постійно вдосконалюємо наше тестове покриття, використовуючи такі інструменти, як мутаційне тестування та [розробляючи нові рішення](https://blog.howardjohn.info/posts/ztunnel-testing/) для тестування проксі-серверів.
|
||||
|
||||
### Посилення розбору заголовків HTTP {#hardening-http-header-parsing}
|
||||
|
||||
Для розбору значення заголовка HTTP [Forwarded](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Forwarded), який може бути присутнім у зʼєднаннях з ztunnel, використовувалася бібліотека сторонніх розробників. Аудитори зазначили, що розбір заголовків є поширеною сферою атак, і висловили занепокоєння тим, що бібліотека, яку ми використовували, не пройшла нечіткий тест. Враховуючи, що ми використовували цю бібліотеку лише для аналізу одного заголовка, ми [написали власний парсер для заголовка Forwarded](https://github.com/istio/ztunnel/pull/1418), доповнивши його фаззі-арканом для тестування.
|
||||
|
||||
## Долучайтеся {#get-involved}
|
||||
|
||||
Завдяки високій продуктивності та підтвердженій безпеці, режим ambient продовжує розвивати сучасний рівень дизайну сервісних мереж. Ми рекомендуємо вам спробувати його вже сьогодні.
|
||||
|
||||
Якщо ви бажаєте долучитися до роботи над безпекою продукту Istio або стати його супровідником, ми будемо раді бачити вас! Приєднуйтесь до [нашого робочого простору Slack](https://slack.istio.io/) або [наших публічних зустрічей](https://github.com/istio/community/blob/master/WORKING-GROUPS.md), щоб ставити питання або дізнатися про те, що ми робимо для забезпечення безпеки Istio.
|
||||
|
|
@ -55,8 +55,9 @@ command terminated with exit code 56
|
|||
|
||||
{{< text syntax=bash snip_id=deploy_waypoint >}}
|
||||
$ istioctl waypoint apply --enroll-namespace --wait
|
||||
waypoint default/waypoint applied
|
||||
namespace default labeled with "istio.io/use-waypoint: waypoint"
|
||||
✅ waypoint default/waypoint applied
|
||||
✅ waypoint default/waypoint is ready!
|
||||
✅ namespace default labeled with "istio.io/use-waypoint: waypoint"
|
||||
{{< /text >}}
|
||||
|
||||
Ви можете перевірити проксі waypoint і переконатися, що він має статус `Programmed=True`:
|
||||
|
|
|
|||
|
|
@ -85,7 +85,6 @@ spec:
|
|||
to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
Навіть якщо ідентичність клієнтського podʼа є правильною, наявність атрибута L7 змушує ztunnel відмовити у зʼєднанні:
|
||||
|
|
|
|||
|
|
@ -31,6 +31,14 @@ Istio [автоматично](/docs/ops/configuration/traffic-management/tls-co
|
|||
|
||||
Наприклад, у [завданні авторизації для HTTP-трафіку](/docs/tasks/security/authorization/authz-http/), політика авторизації з назвою `allow-nothing` гарантує, що весь трафік стандартно заборонено. Від цього моменту ви можете налаштовувати інші політики авторизації, які дозволяють трафік на основі конкретних умов.
|
||||
|
||||
#### Шаблон "стандартно заборонено" з waypoints {#default-deny-pattern-with-waypoints}
|
||||
|
||||
Новий режим панелі даних режиму Ambient представив нову архітектуру розділеної панелі даних у Istio. У цій архітектурі проксі waypoint налаштовується за допомогою Kubernetes Gateway API, який використовує більш явне привʼязування до шлюзів за допомогою `parentRef` і `targetRef`. Оскільки waypoints ближче відповідають принципам Kubernetes Gateway API, шаблон default-deny вмикається дещо по-іншому, коли політика застосовується для waypoints. Починаючи з Istio 1.25, ви можете привʼязати ресурси `AuthorizationPolicy` до `istio-waypoint` `GatewayClass`. Прив'язавши `AuthorizationPolicy` до `GatewayClass`, ви можете налаштувати всі шлюзи, які реалізують цей `GatewayClass`, за стандартною політикою. Важливо зазначити, що `GatewayClass` є кластерним ресурсом, і привʼязка до нього політик, що масштабуються у просторі імен, вимагає особливої обережності. Istio вимагає, щоб політики, привʼязані до `GatewayClass`, знаходилися у кореневому просторі імен, зазвичай `istio-system`.
|
||||
|
||||
{{< tip >}}
|
||||
При використанні шаблону default-deny з waypoints, політика, привʼязана до `istio-waypoint` `GatewayClass`, повинна використовуватися на додаток до «класичної» політики default-deny. «Класична» політика default-deny буде застосована ztunnel до робочих навантажень у вашій мережі, і вона все ще має цінність.
|
||||
{{< /tip >}}
|
||||
|
||||
#### Використовуйте підхід `ALLOW-with-positive-matching` і `DENY-with-negative-match` {#use-allow-with-positive-matching-and-deny-with-negative-match-patterns}
|
||||
|
||||
Використовуйте підходи `ALLOW-with-positive-matching` або `DENY-with-negative-match` за можливості. Ці політики авторизації є безпечнішими, оскільки найгірший результат у разі помилки політики — це несподіване відмова від обслуговування (помилка 403), а не обхід політики авторизації.
|
||||
|
|
@ -125,7 +133,7 @@ spec:
|
|||
|
||||
### Налаштування системи щодо нормалізації шляху {#customize-your-system-on-path-normalization}
|
||||
|
||||
Політики авторизації Istio можуть базуватися на URL-шляху в HTTP-запитах.
|
||||
Політики авторизації Istio можуть базуватися на URL-шляху в HTTP-запитах.
|
||||
[Нормалізація шляху (або URI-нормалізація)](https://en.wikipedia.org/wiki/URI_normalization) модифікує та стандартизує шляхи вхідних запитів, щоб обробляти їх у стандартний спосіб. Синтаксично різні шляхи можуть бути еквівалентні після нормалізації.
|
||||
|
||||
Istio підтримує такі схеми нормалізації шляхів перед перевіркою запиту щодо політик авторизації та маршрутизацією запиту:
|
||||
|
|
|
|||
|
|
@ -58,6 +58,20 @@ serviceSettings:
|
|||
|
||||
{{< /tabset >}}
|
||||
|
||||
Ви також можете обмежити доступ до сервісів, встановивши глобальне правило cluster-local і додавши явні винятки, які можуть бути конкретними або шаблонними. У наведеному нижче прикладі всі сервіси у кластері будуть локальними для кластера, окрім сервісів у просторі назв `myns`:
|
||||
|
||||
{{< text yaml >}}
|
||||
serviceSettings:
|
||||
- settings:
|
||||
clusterLocal: true
|
||||
hosts:
|
||||
- "*"
|
||||
- settings:
|
||||
clusterLocal: false
|
||||
hosts:
|
||||
- "*.myns.svc.cluster.local"
|
||||
{{< /text >}}
|
||||
|
||||
## Розділення сервісів {#partitioning-services}
|
||||
|
||||
[`DestinationRule.subsets`](/docs/reference/config/networking/destination-rule/#Subset) дозволяє розділяти сервіс, вибираючи мітки. Ці мітки можуть бути взяті з метаданих Kubernetes або з [вбудованих міток](/docs/reference/config/labels/). Одна з таких вбудованих міток, `topology.istio.io/cluster`, у селекторі підмножин для `DestinationRule` дозволяє створювати підмножини для кожного кластера.
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Istio була побудована на патерні sidecar з першог
|
|||
<tr>
|
||||
<th>Розширюваність</th>
|
||||
<td>Повний набір функцій Istio</td>
|
||||
<td>Повний набір функцій Istio (потребує використання waypoint) <sup><a href="#supported-features">α</a></sup></td>
|
||||
<td>За допомогою <a href="/docs/ambient/usage/extend-waypoint-wasm">втулків WebAssembly</a> (вимагає використання waypoint)<br> API EnvoyFilter не підтримується.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Додавання навантажень до мережі</th>
|
||||
|
|
|
|||
|
|
@ -61,9 +61,9 @@ Istio не гарантує, що мінорні релізи, які виход
|
|||
|
||||
| Мінорні релізи | Виправлені версії без відомих CVE |
|
||||
|----------------|-----------------------------------|
|
||||
| 1.26.x | 1.26.0+ |
|
||||
| 1.25.x | 1.25.0+ |
|
||||
| 1.24.x | 1.24.0+ |
|
||||
| 1.23.x | 1.23.2+ |
|
||||
|
||||
## Підтримувані версії Envoy {#supported-envoy-versions}
|
||||
|
||||
|
|
@ -73,8 +73,8 @@ Data plane Istio базується на [Envoy](https://github.com/envoyproxy/e
|
|||
|
||||
| Версія Istio | Гілка релізу Envoy |
|
||||
|--------------|--------------------|
|
||||
| 1.25.x | release/v1.33 |
|
||||
| 1.24.x | release/v1.32 |
|
||||
| 1.23.x | release/v1.31 |
|
||||
| 1.26.x | release/v1.34 |
|
||||
| 1.25.x | release/v1.33 |
|
||||
| 1.24.x | release/v1.32 |
|
||||
|
||||
Ви можете знайти точний коміт Envoy, який використовується Istio [в репозиторії `istio/proxy`](https://github.com/istio/proxy/blob/{{< source_branch_name >}}/WORKSPACE#L26): шукайте змінну `ENVOY_SHA`.
|
||||
|
|
|
|||
|
|
@ -230,6 +230,9 @@ $ export REMOTE_CLUSTER_NAME=<your remote cluster name>
|
|||
--create-service-account=false | \
|
||||
kubectl apply -f - --context="${CTX_EXTERNAL_CLUSTER}"
|
||||
{{< /text >}}
|
||||
{{< tip >}}
|
||||
Якщо ви працюєте в `kind`, то вам потрібно передати `--server https://<api-server-node-ip>:6443` в команду `istioctl create-remote-secret`, де `<api-server-node-ip>` — це IP-адреса вузла, на якому запущено сервер API.
|
||||
{{< /tip >}}
|
||||
|
||||
3. Створіть конфігурацію Istio для встановлення панелі управління у просторі імен `external-istiod` у зовнішньому кластері. Зверніть увагу, що `istiod` налаштований на використання локально змонтованого configmap `istio`, а змінна середовища `SHARED_MESH_CONFIG` має значення `istio`. Це вказує `istiod` обʼєднати значення, встановлені адміністратором сервісної мережі в configmap кластера конфігурації, із значеннями у локальному configmap, встановленому оператором сервісної мережі, які матимуть пріоритет у разі конфліктів:
|
||||
|
||||
|
|
|
|||
|
|
@ -20,9 +20,9 @@ owner: istio/wg-environments-maintainers
|
|||
|
||||
{{< text bash >}}
|
||||
$ istioctl remote-clusters --context="${CTX_CLUSTER1}"
|
||||
NAME SECRET STATUS ISTIOD
|
||||
cluster1 synced istiod-a5jg5df5bd-2dfa9
|
||||
cluster2 istio-system/istio-remote-secret synced istiod-a5jg5df5bd-2dfa9
|
||||
NAME SECRET STATUS ISTIOD
|
||||
cluster1 synced istiod-7b74b769db-kb4kj
|
||||
cluster2 istio-system/istio-remote-secret-cluster2 synced istiod-7b74b769db-kb4kj
|
||||
{{< /text >}}
|
||||
|
||||
Всі кластери повинні мати статус `synced`. Якщо кластер вказано зі статусом `STATUS` `timeout`, це означає, що Istiod на головному кластері не може звʼязатися з віддаленим кластером. Докладні повідомлення про помилки дивіться у журналах Istiod.
|
||||
|
|
|
|||
|
|
@ -175,34 +175,94 @@ API Gateway мають багато спільного з API Istio, таким
|
|||
|
||||
### Автоматизоване розгортання {#automated-deployment}
|
||||
|
||||
Стандартно кожен `Gateway` автоматично створює `Service` та `Deployment` з тим самим імʼям. Ці конфігурації автоматично оновлюватимуться, якщо `Gateway` зміниться (наприклад, якщо буде додано новий порт).
|
||||
Стандартно кожен `Gateway` автоматично створює `Service` та `Deployment`. Вони отримають назву `<Gateway name>-<GatewayClass name>` (за винятком `istio-waypoint` `GatewayClass`, до якого не додається суфікс). Ці конфігурації автоматично оновлюватимуться, якщо `Gateway` зміниться (наприклад, якщо буде додано новий порт).
|
||||
|
||||
Ці ресурси можна налаштувати кількома способами:
|
||||
Ці ресурси можна налаштувати за допомогою поля `infrastructure`:
|
||||
|
||||
* Анотації та мітки на `Gateway` будуть скопійовані до `Service` та `Deployment`. Це дозволяє налаштовувати такі речі, як [Внутрішні балансувальники навантаження](https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer), які читають з цих полів.
|
||||
* Istio пропонує додаткову анотацію для налаштування створених ресурсів:
|
||||
{{< text yaml >}}
|
||||
apiVersion: gateway.networking.k8s.io/v1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: gateway
|
||||
spec:
|
||||
infrastructure:
|
||||
annotations:
|
||||
some-key: some-value
|
||||
labels:
|
||||
key: value
|
||||
parametersRef:
|
||||
group: ""
|
||||
kind: ConfigMap
|
||||
name: gw-options
|
||||
gatewayClassName: istio
|
||||
{{< /text >}}
|
||||
|
||||
|Анотація|Призначення|
|
||||
|--------|-----------|
|
||||
|`networking.istio.io/service-type`|Контролює поле `Service.spec.type`. Наприклад, встановіть `ClusterIP`, щоб не відкривати сервіс зовні. Стандартне значення — `LoadBalancer`.|
|
||||
Пари ключ-значення у розділах `label` та `annotations` буде скопійовано до створених ресурсів. Параметр `parametersRef` може бути використано для повного налаштування створених ресурсів. Він має посилатися на `ConfigMap` у тому ж просторі імен, що і `Gateway`.
|
||||
|
||||
* Поле `Service.spec.loadBalancerIP` може бути явно задано шляхом конфігурації поля `addresses`:
|
||||
Приклад конфігурації:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: gateway.networking.k8s.io/v1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: gateway
|
||||
{{< text yaml >}}
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: gw-options
|
||||
data:
|
||||
horizontalPodAutoscaler: |
|
||||
spec:
|
||||
addresses:
|
||||
- value: 192.0.2.0
|
||||
type: IPAddress
|
||||
...
|
||||
{{< /text >}}
|
||||
minReplicas: 2
|
||||
maxReplicas: 2
|
||||
|
||||
Примітка: можна вказати лише одну адресу.
|
||||
deployment: |
|
||||
metadata:
|
||||
annotations:
|
||||
additional-annotation: some-value
|
||||
spec:
|
||||
replicas: 4
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- name: istio-proxy
|
||||
resources:
|
||||
requests:
|
||||
cpu: 1234m
|
||||
|
||||
* (Додатково) Згенеровану конфігурацію Pod можна налаштувати за допомогою [власних шаблонів інʼєкцій](/docs/setup/additional-setup/sidecar-injection/#custom-templates-experimental).
|
||||
service: |
|
||||
spec:
|
||||
ports:
|
||||
- "\$patch": delete
|
||||
port: 15021
|
||||
{{< /text >}}
|
||||
|
||||
Ці конфігурації будуть накладені поверх згенерованих ресурсів за допомогою стратегії [Strategic Merge Patch](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md). Наступні ключі є дійсними:
|
||||
|
||||
* `service`
|
||||
* `deployment`
|
||||
* `serviceAccount`
|
||||
* `horizontalPodAutoscaler`
|
||||
* `podDisruptionBudget`
|
||||
|
||||
{{< tip >}}
|
||||
Стандартно `HorizontalPodAutoscaler` та `PodDisruptionBudget` не створюються. Однак, якщо відповідне поле присутнє в налаштуванні, вони будуть створені.
|
||||
{{< /tip >}}
|
||||
|
||||
#### Стандартні значення GatewayClass {#gatewayclass-defaults}
|
||||
|
||||
Стандартні значення для всіх `Gateway` можуть бути налаштовані для кожного `GatewayClass`. Це робиться за допомогою `ConfigMap` з міткою `gateway.istio.io/defaults-for-class: <імʼя класу шлюзу>`. Цей файл `ConfigMap` має знаходитися у [кореневому просторі імен](/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-root_namespace) (зазвичай, `istio-system`). Дозволено лише один `ConfigMap` для кожного `GatewayClass`. Цей `ConfigMap` має той самий формат, що й `ConfigMap` для `Gateway`.
|
||||
|
||||
Налаштування може бути присутнім як для `GatewayClass`, так і для `Gateway`. Якщо присутні обидва, то налаштування `Gateway` застосовується після налаштування `GatewayClass`.
|
||||
|
||||
Ця `ConfigMap` також може бути створена під час встановлення. Наприклад:
|
||||
|
||||
{{< text yaml >}}
|
||||
kind: IstioOperator
|
||||
spec:
|
||||
values:
|
||||
gatewayClasses:
|
||||
istio:
|
||||
deployment:
|
||||
spec:
|
||||
replicas: 2
|
||||
{{< /text >}}
|
||||
|
||||
#### Прикріплення ресурсів і масштабування {#resource-attachment-and-scaling}
|
||||
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ istio-ingressgateway LoadBalancer 172.21.109.129 130.211.10.121 ...
|
|||
|
||||
Якщо встановлено значення `EXTERNAL-IP`, ваше середовище має зовнішнього балансувальника навантаження, який ви можете використовувати для вхідного шлюзу. Якщо значення `EXTERNAL-IP` дорівнює `<none>` (або постійно `<pending>`), у вашому середовищі не передбачено зовнішнього балансувальника навантаження для вхідного шлюзу.
|
||||
|
||||
Якщо ваше середовище не підтримує зовнішні балансувальники навантаження, ви можете спробувати [доступ до вхідного шлюзу за допомогою портів вузла](#using-node-ports-of-the-ingress-gateway-service). В іншому випадку, встановіть IP-адресу і порти вхідного шлюзу за допомогою наступних команд:
|
||||
Якщо ваше середовище не підтримує зовнішні балансувальники навантаження, ви можете спробувати [доступ до вхідного шлюзу за допомогою портів вузла](/docs/tasks/traffic-management/ingress/ingress-control/#using-node-ports-of-the-ingress-gateway-service). В іншому випадку, встановіть IP-адресу і порти вхідного шлюзу за допомогою наступних команд:
|
||||
|
||||
{{< text bash >}}
|
||||
$ export INGRESS_HOST=$(kubectl -n "$INGRESS_NS" get service "$INGRESS_NAME" -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
|
||||
|
|
@ -460,7 +460,7 @@ $ export TCP_INGRESS_PORT=$(kubectl -n "${INGRESS_NS}" get service "${INGRESS_NA
|
|||
$ kubectl get ingress --all-namespaces
|
||||
{{< /text >}}
|
||||
|
||||
1. Якщо у вас є зовнішній навантажувач, і він не працює, спробуйте [отримати доступ до шлюзу, використовуючи його NodePort](#using-node-ports-of-the-ingress-gateway-service).
|
||||
1. Якщо у вас є зовнішній навантажувач, і він не працює, спробуйте [отримати доступ до шлюзу, використовуючи його NodePort](/docs/tasks/traffic-management/ingress/ingress-control/#using-node-ports-of-the-ingress-gateway-service).
|
||||
|
||||
## Очищення {#cleanup}
|
||||
|
||||
|
|
|
|||
|
|
@ -23,17 +23,23 @@ test: yes
|
|||
|
||||
Подивімось, як можна налаштувати `Ingress` на порту 80 для HTTP-трафіку.
|
||||
|
||||
1. Створіть ресурс `Ingress`:
|
||||
1. Створіть ресурс `Ingress` та `IngressClass`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: IngressClass
|
||||
metadata:
|
||||
name: istio
|
||||
spec:
|
||||
controller: istio.io/ingress-controller
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
annotations:
|
||||
kubernetes.io/ingress.class: istio
|
||||
name: ingress
|
||||
spec:
|
||||
ingressClassName: istio
|
||||
rules:
|
||||
- host: httpbin.example.com
|
||||
http:
|
||||
|
|
@ -48,7 +54,9 @@ test: yes
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
Анотація `kubernetes.io/ingress.class` необхідна для того, щоб вказати контролеру шлюзу Istio, що він повинен обробляти цей `Ingress`, інакше він буде проігнорований.
|
||||
Ресурс `IngressClass` ідентифікує контролер шлюзу Istio для Kubernetes, а значення `ingressClassName: istio` вказує Kubernetes, що контролер шлюзу Istio повинен обробляти наступний `Ingress`.
|
||||
|
||||
У старих версіях Ingress API використовувалася анотація `kubernetes.io/ingress.class`, і хоча вона все ще працює, [вона була визнана застарілою в Kubernetes](https://kubernetes.io/docs/concepts/services-networking/ingress/#deprecated-annotation) протягом деякого часу.
|
||||
|
||||
1. Зверніться до сервісу _httpbin_ за допомогою _url_:
|
||||
|
||||
|
|
@ -83,42 +91,12 @@ test: yes
|
|||
|
||||
У Kubernetes 1.18 було додане нове поле `pathType`. Це дозволяє явно вказувати шлях як `Exact` або `Prefix`.
|
||||
|
||||
### Налаштування `IngressClass` {#specifying-ingressclass}
|
||||
|
||||
У Kubernetes 1.18 був доданий новий ресурс `IngressClass`, який замінює анотацію `kubernetes.io/ingress.class` на ресурсі `Ingress`. Якщо ви використовуєте цей ресурс, вам потрібно встановити поле `controller` в `istio.io/ingress-controller`. Наприклад:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: IngressClass
|
||||
metadata:
|
||||
name: istio
|
||||
spec:
|
||||
controller: istio.io/ingress-controller
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: ingress
|
||||
spec:
|
||||
ingressClassName: istio
|
||||
rules:
|
||||
- host: httpbin.example.com
|
||||
http:
|
||||
paths:
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: httpbin
|
||||
port:
|
||||
number: 8000
|
||||
{{< /text >}}
|
||||
|
||||
## Очищення {#cleanup}
|
||||
|
||||
Видаліть конфігурацію `Ingress` і вимкніть службу [httpbin]({{< github_tree >}}/samples/httpbin):
|
||||
Видаліть конфігурацію `IngressClass` та `Ingress` і вимкніть службу [httpbin]({{< github_tree >}}/samples/httpbin):
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete ingress ingress
|
||||
$ kubectl delete ingressclass istio
|
||||
$ kubectl delete --ignore-not-found=true -f @samples/httpbin/httpbin.yaml@
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -605,9 +605,10 @@ EOF
|
|||
|
||||
Istio підтримує кілька різних форматів секретів для інтеграції з різними інструментами, такими як [cert-manager](/docs/ops/integrations/certmanager/):
|
||||
|
||||
* TLS секрет з ключами `tls.key` та `tls.crt`, як описано вище. Для взаємного TLS можна використовувати ключ `ca.crt`.
|
||||
* Загальний секрет з ключами `key` та `cert`. Для взаємного TLS можна використовувати ключ `cacert`.
|
||||
* Загальний секрет з ключами `key` та `cert`. Для взаємного TLS можна використовувати окремий загальний секрет з назвою `<secret>-cacert`, який містить ключ `cacert`. Наприклад, `httpbin-credential` має `key` та `cert`, а `httpbin-credential-cacert` має `cacert`.
|
||||
* TLS Secret з ключами `tls.key` та `tls.crt`, як описано вище. Для взаємного TLS можна використовувати ключ `ca.crt`.
|
||||
* TLS Secret з ключами `tls.key` і `tls.crt`, як описано вище. Для взаємного TLS, окремий загальний Secret з назвою `<secret>-cacert`, з ключем `cacert`. Наприклад, `httpbin-credential` має `tls.key` і `tls.crt`, а `httpbin-credential-cacert` має `cacert`.
|
||||
* Загальний Secret з ключами `key` та `cert`. Для взаємного TLS можна використовувати ключ `cacert`.
|
||||
* Загальний Secret з ключами `key` та `cert`. Для взаємного TLS можна використовувати окремий загальний секрет з назвою `<secret>-cacert`, який містить ключ `cacert`. Наприклад, `httpbin-credential` має `key` та `cert`, а `httpbin-credential-cacert` має `cacert`.
|
||||
* Значення ключа `cacert` може бути зв'язкою сертифікатів CA, яка складається з окремих об'єднаних сертифікатів CA.
|
||||
|
||||
### SNI маршрутизація {#sni-routing}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
title: Анонс Istio 1.23.6
|
||||
linktitle: 1.23.6
|
||||
subtitle: Патч-реліз
|
||||
description: Патч-реліз Istio 1.23.6.
|
||||
publishdate: 2025-04-07
|
||||
release: 1.23.6
|
||||
aliases:
|
||||
- /uk/news/announcing-1.23.6
|
||||
---
|
||||
|
||||
Цей реліз містить виправлення помилок для покращення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.23.5 та Istio 1.23.6.
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
## Оновлення безпеки {#security-updates}
|
||||
|
||||
- [CVE-2025-30157](https://nvd.nist.gov/vuln/detail/CVE-2025-30157) (CVSS Score 6.5, Medium): Envoy аварійно завершує роботу, коли HTTP `ext_proc` обробляє локальні відповіді.
|
||||
|
||||
Для цілей Istio ця CVE може бути використана лише у випадку, коли `ext_proc` налаштовано через `EnvoyFilter`.
|
||||
|
||||
## Зміни {#changes}
|
||||
|
||||
- **Виправлено** проблему, яка полягала у тому, що налаштування імені сокета ідентифікатора робочого навантаження SDS
|
||||
через `WORKLOAD_IDENTITY_SOCKET_FILE` не працювало через те, що не було оновлено завантажувач Envoy.
|
||||
([Тікет #51979](https://github.com/istio/istio/issues/51979))
|
||||
|
||||
- **Виправлено** проблему, через яку Istiod виходив з ладу з помилкою LDS для проксі <1.23, коли `meshConfig.accessLogEncoding` встановлено у `JSON`.
|
||||
([Тікет #55116](https://github.com/istio/istio/issues/55116))
|
||||
|
||||
- **Виправлено** проблему, коли шаблон інʼєкції `gateway` не враховував контейнер `kubectl.kubernetes.io/default-logs-container` та `kubectl.kubernetes.io/default-logs-container`.
|
||||
та `kubectl.kubernetes.io/default-container` анотації.
|
||||
|
||||
- **Виправлено** проблему, яка призводила до відхилення валідаційного веб-хука, якщо він мав `connectionPool.tcp.IdleTimeout=0s`.
|
||||
([Тікет #55409](https://github.com/istio/istio/issues/55409))
|
||||
|
||||
- **Виправлено** проблему, яка полягала у тому, що веб-хук перевірки некоректно повідомляв про попередження, коли `ServiceEntry` налаштовував `workloadSelector` з роздільною здатністю DNS.
|
||||
([Тікет #50164](https://github.com/istio/istio/issues/50164))
|
||||
|
||||
- **Виправлено** проблему, через яку вхідні шлюзи не використовували виявлення WDS для отримання метаданих для пунктів призначення ambient.
|
||||
|
||||
- **Виправлено** трафік DNS (UDP і TCP) тепер впливає на анотації трафіку, такі як `traffic.sidecar.istio.io/excludeOutboundIPRanges` і `traffic.sidecar.istio.istio.io/excludeOutboundPorts`. Раніше UDP/DNS трафік однозначно ігнорував ці анотації трафіку, навіть якщо був вказаний порт DNS, через структуру правил. Зміна поведінки фактично відбулася у серії випусків 1.23, але її не було зазначено у примітках до випуску 1.23.
|
||||
([Тікет #53949](https://github.com/istio/istio/issues/53949))
|
||||
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
title: Анонс Istio 1.24.4
|
||||
linktitle: 1.24.4
|
||||
subtitle: Патч-реліз
|
||||
description: Патч-реліз Istio 1.24.4.
|
||||
publishdate: 2025-03-25
|
||||
release: 1.24.4
|
||||
---
|
||||
|
||||
|
||||
Цей реліз містить виправлення помилок для покращення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.24.3 та Istio 1.24.4.
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
## Оновлення безпеки {#security-updates}
|
||||
|
||||
- [CVE-2025-30157](https://nvd.nist.gov/vuln/detail/CVE-2025-30157) (CVSS Score 6.5, Medium): Envoy аварійно завершує роботу, коли HTTP `ext_proc` обробляє локальні відповіді.
|
||||
|
||||
Для цілей Istio ця CVE може бути використана лише у випадку, коли `ext_proc` налаштовано через `EnvoyFilter`.
|
||||
|
||||
## Зміни {#changes}
|
||||
|
||||
- **Виправлено** помилку, яка призводила до застарілих RDS через змішаний регістр хостів у перенаправленнях шлюзу та TLS.
|
||||
([Тікет #49638](https://github.com/istio/istio/issues/49638))
|
||||
|
||||
- **Виправлено** проблему, коли політики Ambient `PeerAuthentication` були надто суворими.
|
||||
([Тікет #53884](https://github.com/istio/istio/issues/53884))
|
||||
|
||||
- **Виправлено** невдалу спробу виправити розгортання керованих шлюзів/waypoint під час оновлення до версії 1.24.
|
||||
([Тікет #54145](https://github.com/istio/istio/issues/54145))
|
||||
|
||||
- **Виправлено** помилку, коли декілька `STRICT` правил mTLS на рівні порту у політиці `PeerAuthentication` у режимі ambient призводили до політики дозволу через неправильну логіку оцінки (AND проти OR).
|
||||
([Тікет #54146](https://github.com/istio/istio/issues/54146))
|
||||
|
||||
- **Виправлено** формулювання повідомлення про стан, коли у політиці авторизації, привʼязаній до ztunnel, присутні правила L7, на більш зрозуміле.
|
||||
([Тікет #54334](https://github.com/istio/istio/issues/54334))
|
||||
|
||||
- **Виправлено** помилку, коли фільтр дзеркала запитів неправильно обчислював відсоток.
|
||||
([Тікет #54357](https://github.com/istio/istio/issues/54357))
|
||||
|
||||
- **Виправлено** проблему, коли використання теґу у мітці `istio.io/rev` у шлюзі призводило до неправильного програмування шлюзу та відсутності статусу.
|
||||
([Тікет #54458](https://github.com/istio/istio/issues/54458))
|
||||
|
||||
- **Виправлено** проблему, через яку неправильне розʼднання з тунелем могло призвести до того, що `istio-cni` вважатиме, що у нього немає зʼєднань.
|
||||
([Тікет #54544](https://github.com/istio/istio/issues/54544)), ([Тікет #53843](https://github.com/istio/istio/issues/53843))
|
||||
|
||||
- **Виправлено** проблему, яка призводила до нестабільної роботи під час очищення зʼєднань через неправильний порядок ведення журналу доступу.
|
||||
([Тікет #54672](https://github.com/istio/istio/issues/54672))
|
||||
|
||||
- **Виправлено** проблему у таблиці шлюзів, коли `--set platform` працював, але `--set global.platform` не працював.
|
||||
|
||||
- **Виправлено** проблему, через яку вхідні шлюзи не використовували виявлення WDS для отримання метаданих для пунктів призначення у режимі ambient.
|
||||
|
||||
- **Виправлено** проблему, що призводила до невдалого виконання команди `istio-iptables`, коли у системі присутня не вбудована таблиця.
|
||||
|
||||
- **Виправлено** проблему, що призводила до відхилення конфігурації у разі часткового збігу IP-адрес у декількох сервісах. Наприклад, сервіс з `[IP-A]` і сервіс з `[IP-B, IP-A]`.
|
||||
([Тікет #52847](https://github.com/istio/istio/issues/52847))
|
||||
|
||||
- **Виправлено** на трафік DNS (UDP і TCP) тепер впливають такі анотації трафіку, як `traffic.sidecar.istio.io/excludeOutboundIPRanges` і `traffic.sidecar.istio.io/excludeOutboundPorts`. Раніше UDP/DNS трафік однозначно ігнорував ці анотації трафіку, навіть якщо був вказаний порт DNS, через структуру правил. Зміна поведінки фактично відбулася в серії випусків 1.23, але про неї не було повідомлено у примітках до випуску 1.23.
|
||||
([Тікет #53949](https://github.com/istio/istio/issues/53949))
|
||||
|
||||
- **Виправлено* вебхук валідації, який відхиляв правильну конфігурацію `connectionPool.tcp.IdleTimeout=0s`.
|
||||
([Тікет #55409](https://github.com/istio/istio/issues/55409))
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
title: Анонс Istio 1.24.5
|
||||
linktitle: 1.24.5
|
||||
subtitle: Патч-реліз
|
||||
description: Патч-реліз Istio 1.24.5.
|
||||
publishdate: 2025-04-14
|
||||
release: 1.24.5
|
||||
---
|
||||
|
||||
|
||||
Цей реліз містить виправлення помилок для покращення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.24.4 та Istio 1.24.5.
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
## Зміни {#changes}
|
||||
|
||||
- **Виправлено** крайні випадки, коли `istio-cni` може заблокувати власне оновлення. Додано резервне ведення журналу (на випадок непрацездатності агента) до локального файлу журналу вузла фіксованого розміру.
|
||||
([Тікет #55215](https://github.com/istio/istio/issues/55215))
|
||||
|
||||
- **Виправлено** проблему, коли вебхук перевірки неправильно повідомляв про попередження, коли `ServiceEntry` налаштовував `workloadSelector` з DNS-дозволом.
|
||||
([Тікет #50164](https://github.com/istio/istio/issues/50164))
|
||||
|
||||
- **Виправлено** проблему, що призводила до збільшення памʼяті проксі-сервера під час використання потокових сервісів gRPC.
|
||||
|
||||
- **Виправлено** проблему, що призводила до того, що зміни у сервісах `ExternalName` іноді пропускалися через помилку витіснення кешу.
|
||||
|
||||
- **Виправлено** регресію, коли ресурс SDS `ROOTCA` включав лише один кореневий сертифікат, навіть якщо панель управління було налаштовано з обома, як з активним кореневим сертифікатом, так і з пасивним кореневим сертифікатом, що було введено у 1.24.4.
|
||||
([Тікет #55793](https://github.com/istio/istio/issues/55793))
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
title: Анонс Istio 1.25.1
|
||||
linktitle: 1.25.1
|
||||
subtitle: Патч-реліз
|
||||
description: Патч-реліз Istio 1.25.1.
|
||||
publishdate: 2025-03-26
|
||||
release: 1.25.1
|
||||
---
|
||||
|
||||
Цей реліз містить виправлення помилок для покращення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.25.0 та Istio 1.25.1.
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
## Оновлення безпеки {#security-updates}
|
||||
|
||||
- [CVE-2025-30157](https://nvd.nist.gov/vuln/detail/CVE-2025-30157) (CVSS Score 6.5, Medium): Envoy аварійно завершує роботу, коли HTTP `ext_proc` обробляє локальні відповіді.
|
||||
|
||||
Для цілей Istio ця CVE може бути використана лише у випадку, коли `ext_proc` налаштовано через `EnvoyFilter`.
|
||||
|
||||
## Зміни {#changes}
|
||||
|
||||
- **Додано** інформацію про стан ресурсів `HTTPRoute` для позначення статусу `parentRefs` для сервісу та ресурсів введення сервісу, а також нову умову для вказівки статусу конфігурації waypoint у режимі ambient.
|
||||
|
||||
- **Виправлено** веб-хук валідації, який відхиляв правильну конфігурацію `connectionPool.tcp.IdleTimeout=0s`.
|
||||
([Тікет #55409](https://github.com/istio/istio/issues/55409))
|
||||
|
||||
- **Виправлено** проблему, коли веб-хук перевірки некоректно повідомляв про попередження, коли `ServiceEntry` налаштовував `workloadSelector` з DNS-дозволом.
|
||||
([Тікет #50164](https://github.com/istio/istio/issues/50164))
|
||||
|
||||
- **Виправлено** проблему, коли статус `HTTPRoute` не повідомляв про `parentRef`, пов'язаний з одним результатом через складну логіку згортання `parentRefs` одного і того ж посилання, але з різними `sectionNames`.
|
||||
|
||||
- **Виправлено `IstioCertificateService` для забезпечення того, щоб `IstioCertificateResponse.CertChain` містив лише один сертифікат на елемент масиву.
|
||||
([Тікет #1061](https://github.com/istio/ztunnel/issues/1061))
|
||||
|
||||
- **Виправлено** проблему, що призводила до того, що точки шляху понижували HTTP2-трафік до HTTP/1.1, якщо порт не було явно визначено як `http2`.
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
title: Анонс Istio 1.25.2
|
||||
linktitle: 1.25.2
|
||||
subtitle: Патч-реліз
|
||||
description: Патч-реліз Istio 1.25.2.
|
||||
publishdate: 2025-04-14
|
||||
release: 1.25.2
|
||||
---
|
||||
|
||||
Цей реліз містить виправлення помилок для покращення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.25.1 nf Istio 1.25.2.
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
## Зміни {#changes}
|
||||
|
||||
- Додано префікс змінної оточення `CA_HEADER_` (подібно до `XDS_HEADER_`), який можна додавати до запитів CA для різних цілей, наприклад, для маршрутизації на відповідний зовнішній `istiod`.
|
||||
Проксі Istio sidecar, роутер і waypoint тепер підтримують цю функцію. ([Тікет #55064](https://github.com/istio/istio/issues/55064))
|
||||
|
||||
- **Виправлено** крайні випадки, коли `istio-cni` може блокувати власне оновлення. Додано резервне ведення журналу (на випадок непрацездатності агента) до локального файлу журналу вузла фіксованого розміру.
|
||||
([Тікет #55215](https://github.com/istio/istio/issues/55215))
|
||||
|
||||
- **Виправлено** проблему, через яку стан `WaypointAccepted` політики авторизації `AuthorizationPolicy` не оновлювався у відповідності до дозволу цільового посилання `GatewayClass`.
|
||||
|
||||
- **Виправлено** проблему, повʼязану з тим, що стан `WaypointAccepted` для `AuthorizationPolicy`, який посилався на `GatewayClass` і не перебував у кореневому просторі імен, не оновлювався з правильною причиною та повідомленням.
|
||||
|
||||
- **Виправлено** проблему, яка призводила до збільшення памʼяті проксі-сервера під час використання потокових сервісів gRPC.
|
||||
|
||||
- **Виправлено** проблему, через яку зміни у сервісах `ExternalName` іноді пропускалися через помилку витіснення кешу.
|
||||
|
||||
- **Виправлено** регресію, коли ресурс SDS `ROOTCA` містив лише один кореневий сертифікат, навіть якщо панель управління було сконфігуровано з обома активними кореневими сертифікатами.
|
||||
було налаштовано як з активним кореневим, так і з пасивним кореневим сертифікатом, що було введено у версії 1.25.1.
|
||||
([Тікет #55793](https://github.com/istio/istio/issues/55793))
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: Випуски 1.26.x
|
||||
description: Анонси випуску 1.26 та повʼязаних з ним патчів.
|
||||
weight: 6
|
||||
list_by_publishdate: true
|
||||
layout: release-grid
|
||||
decoration: dot
|
||||
---
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
---
|
||||
title: Анонс Istio 1.26.0
|
||||
linktitle: 1.26.0
|
||||
subtitle: Основний випуск
|
||||
description: Анонс випуску Istio 1.26.
|
||||
publishdate: 2025-05-08
|
||||
release: 1.26.0
|
||||
aliases:
|
||||
- /uk/news/announcing-1.26
|
||||
- /uk/news/announcing-1.26.0
|
||||
---
|
||||
|
||||
Ми раді повідомити про випуск Istio 1.26. Дякуємо всім нашим учасникам, тестувальникам, користувачам та ентузіастам за допомогу в публікації версії 1.26.0! Ми хотіли б подякувати менеджерам релізу, **Daniel Hawton** з Solo.io, **Faseela K** з Ericsson Software Technology та **Gustavo Meira** з Microsoft.
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
{{< tip >}}
|
||||
Istio 1.26.0 офіційно підтримується на Kubernetes версій від 1.29 до 1.32. Ми очікуємо, що 1.33 також буде працювати, і плануємо додати тестування і підтримку до Istio 1.26.1.
|
||||
{{< /tip >}}
|
||||
|
||||
## Що нового? {#whats-new}
|
||||
|
||||
### Налаштування ресурсів, що надаються за допомогою API Gateway {#customization-of-resources-provisioned-by-the-gateway-api}
|
||||
|
||||
Коли ви створюєте шлюз або waypoint за допомогою API Gateway, автоматично створюються `Service` та `Deployment`. Було поширеним проханням дозволити кастомізацію цих обʼєктів, і тепер це підтримується у Istio 1.26 за допомогою вказівки `ConfigMap` параметрів. Якщо вказано конфігурацію для `HorizontalPodAutoscaler` або `PodDisruptionBudget`, ці ресурси також буде автоматично створено. [Дізнайтеся більше про налаштування згенерованих ресурсів API Gateway.](/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment)
|
||||
|
||||
### Нова підтримка API Gateway {#new-gateway-api-support}
|
||||
|
||||
[`TCPRoute`](https://gateway-api.sigs.k8s.io/guides/tcp/) тепер доступний у waypoints, що дозволяє перенаправляти TCP-трафік у режимі ambient.
|
||||
|
||||
Ми також додали підтримку експериментальної [`BackendTLSPolicy`](https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/) і почали реалізацію [`BackendTrafficPolicy`](https://gateway-api.sigs.k8s.io/api-types/backendtrafficpolicy/) у Gateway API 1.3, яка згодом дозволить встановлювати обмеження на повторні спроби.
|
||||
|
||||
### Підтримка нового `ClusterTrustBundle` в Kubernetes {#support-for-the-new-kubernetes-clustertrustbundle}
|
||||
|
||||
Ми додали експериментальну підтримку [експериментального ресурсу `ClusterTrustBundle` у Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#cluster-trust-bundles), що дозволяє підтримувати новий метод обʼєднання сертифіката і його кореня довіри в один обʼєкт.
|
||||
|
||||
### Плюс багато-багато іншого {#plus-much-much-more}
|
||||
|
||||
* `istioctl analyze` тепер може виконувати конкретні перевірки!
|
||||
* Агент вузла CNI більше не запускається стандартно у просторі імен `hostNetwork`, що зменшує ймовірність конфліктів портів з іншими сервісами, запущеними на хості!
|
||||
* Необхідні ресурси `ResourceQuota` та значення `cniBinDir` встановлюються автоматично під час інсталяції на GKE!
|
||||
* Фільтр `EnvoyFilter` тепер може співпадати з `VirtualHost` на доменному імені!
|
||||
|
||||
Про ці та інші зміни читайте у повному [release notes](change-notes/).
|
||||
|
||||
## Наздогнати проєкт Istio {#catch-up-with-the-istio-project}
|
||||
|
||||
Якщо ви перевіряєте нас тільки тоді, коли у нас зʼявляється новий реліз, ви могли пропустити, що [ми опублікували аудит безпеки ztunnel](/blog/2025/ztunnel-security-assessment/), [ми порівняли продуктивність пропускної здатності ambient-режиму та роботи в ядрі](/blog/2025/ambient-performance/), або що [у нас була велика презентація на KubeCon EU](/blog/2025/istio-at-kubecon-eu/). Перевірте ці пости!
|
||||
|
||||
## Оновлення до 1.26 {#upgrading-to-126}
|
||||
|
||||
Ми хотіли б почути від вас відгуки про ваш досвід роботи з Istio 1.26. Ви можете залишити відгук у каналі `#release-1.26` у нашому [Slack](https://slack.istio.io/).
|
||||
|
||||
Бажаєте взяти безпосередню участь у розробці Istio? Знайдіть і приєднайтеся до однієї з наших [Робочих груп](https://github.com/istio/community/blob/master/WORKING-GROUPS.md) і допоможіть нам покращити Istio.
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
---
|
||||
title: Примітки до змін Istio 1.26.0
|
||||
linktitle: 1.26.0
|
||||
subtitle: Основний реліз
|
||||
description: Примітки до релізу Istio 1.26.0.
|
||||
publishdate: 2025-05-08
|
||||
release: 1.26.0
|
||||
weight: 10
|
||||
aliases:
|
||||
- /uk/news/announcing-1.26.0
|
||||
- /uk/news/announcing-1.26.x
|
||||
---
|
||||
|
||||
## Керування трафіком {#traffic-management}
|
||||
|
||||
* **Покращено** агент CNI більше не потребує параметра `hostNetwork`, що покращує сумісність. Динамічне перемикання на хост-мережу тепер виконується за необхідності. Попередню поведінку можна тимчасово відновити, встановивши поле `ambient.shareHostNetworkNamespace` у чарті `istio-cni`. ([Тікет #54726](https://github.com/istio/istio/issues/54726))
|
||||
|
||||
* **Покращено** бінарне визначення iptables для перевірки підтримки базового ядра та надання переваги `nft`, коли доступні як застарілі, так і `nft`, але жоден з них не має існуючих правил.
|
||||
|
||||
* **Оновлено** стандартне значення максимальної кількості зʼєднань, що приймаються за одну подію сокета, до 1 для покращення продуктивності. Щоб повернутися до попередньої поведінки, встановіть `MAX_CONNECTIONS_PER_SOCKET_EVENT_LOOP` в нуль.
|
||||
|
||||
* **Додано** можливість для `EnvoyFilter` зіставляти `VirtualHost` за доменним іменем.
|
||||
|
||||
* **Додано** початкову підтримку експериментальних функцій API Gateway `BackendTLSPolicy` та `XBackendTrafficPolicy`. Стандартно вони вимкнені і потребують встановлення `PILOT_ENABLE_ALPHA_GATEWAY_API=true`.
|
||||
([Тікет #54131](https://github.com/istio/istio/issues/54131)), ([Тікет #54132](https://github.com/istio/istio/issues/54132))
|
||||
|
||||
* **Додано** підтримку посилання на `ConfigMap`, на додачу до `Secret`, для `DestinationRule` TLS у режимі `SIMPLE` — корисно, коли потрібен лише сертифікат ЦС.
|
||||
([Тікет #54131](https://github.com/istio/istio/issues/54131)), ([Тікет #54132](https://github.com/istio/istio/issues/54132))
|
||||
|
||||
* **Додано** підтримку кастомізації для [Автоматизованого розгортання Gateway API](/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment). Це стосується як типів Istio `Gateway` (вхід і вихід), так і типів Istio Waypoint `Gateway` (ambient waypoints). Користувачі тепер можуть налаштовувати згенеровані ресурси, такі як `Service`, `Deployment`, `ServiceAccount`, `HorizontalPodAutoscaler` і `PodDisruptionBudget`.
|
||||
|
||||
* **Додано** нову змінну оточення `ENABLE_GATEWAY_API_MANUAL_DEPLOYMENT` для `istiod`. Якщо встановлено у значення `false`, вона вимикає автоматичне приєднання ресурсів API Gateway до існуючих розгортань шлюзу. Стандартно це значення `true`, щоб зберегти поточну поведінку.
|
||||
|
||||
* **Додано** можливість налаштовувати предикати хостів для повторних спроб за допомогою Retry API (`retry_ignore_previous_hosts`).
|
||||
|
||||
* **Додано** підтримку вказівки інтервалів очікування під час повторних спроб.
|
||||
|
||||
* **Додано** підтримку використання `TCPRoute` у проксі-waypoint.
|
||||
|
||||
* **Виправлено** помилку, коли веб-хук перевірки неправильно повідомляв про попередження, коли `ServiceEntry` налаштовував `workloadSelector` з роздільною здатністю DNS.
|
||||
([Тікет #50164](https://github.com/istio/istio/issues/50164))
|
||||
|
||||
* **Виправлено** проблему, коли FQDN не працювали у `WorkloadEntry` з використанням режиму ambient.
|
||||
|
||||
* **Виправлено** випадок, коли `ReferenceGrants` не працювали, коли mTLS було увімкнено на слухачі шлюзу.
|
||||
([Тікет #55623](https://github.com/istio/istio/issues/55623))
|
||||
|
||||
* **Виправлено** проблему, коли Istio не міг коректно отримати `allowedRoutes` для waypoint у пісочниці.
|
||||
([Тікет #56010](https://github.com/istio/istio/issues/56010))
|
||||
|
||||
* **Виправлено** ваду, через яку витікали точки доступу `ServiceEntry` під час виселення podʼа.
|
||||
([Тікет #54997](https://github.com/istio/istio/issues/54997))
|
||||
|
||||
* **Виправлено** проблему, через яку адреса слухача дублювалася для двостекових сервісів з пріоритетом IPv6. ([Тікет #56151](https://github.com/istio/istio/issues/56151))
|
||||
|
||||
## Безпека {#security}
|
||||
|
||||
* **Додано** експериментальну підтримку v1alpha1 API `ClusterTrustBundle`. Її можна увімкнути, встановивши `values.pilot.env.ENABLE_CLUSTER_TRUST_BUNDLE_API=true`. Переконайтеся, що у вашому кластері увімкнено відповідні функціональні можливості; див. [KEP-3257](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3257-cluster-trust-bundles) для отримання детальної інформації.
|
||||
([Тікет #43986](https://github.com/istio/istio/issues/43986))
|
||||
|
||||
## Телеметрія {#telemetry}
|
||||
|
||||
* **Додано** підтримку поля `omit_empty_values` у провайдері `EnvoyFileAccessLog` через API телеметрії.
|
||||
([Тікет #54930](https://github.com/istio/istio/issues/54930))
|
||||
|
||||
* **Додано** змінну оточення `PILOT_SPAWN_UPSTREAM_SPAN_FOR_GATEWAY`, яка розділяє діапазони трасування для серверного та клієнтського шлюзів. Наразі цей параметр стандартно має значення `false`, але у майбутньому він стане стандартним.
|
||||
|
||||
* Додано попередження щодо використання застарілих постачальників телеметрії Lightstep та OpenCensus.
|
||||
([Тікет #54002](https://github.com/istio/istio/issues/54002))
|
||||
|
||||
## Встановлення {#installation}
|
||||
|
||||
* **Покращено** процес встановлення на GKE. Якщо встановлено `global.platform=gke`, необхідні ресурси `ResourceQuota` буде розгорнуто автоматично. Під час встановлення за допомогою `istioctl` цей параметр також буде автоматично ввімкнено, якщо буде виявлено GKE. Крім того, тепер належним чином налаштовано `cniBinDir`.
|
||||
|
||||
* **Покращено** чарт `ztunnel` Helm, щоб не призначати назви ресурсів до `.Release.Name`, натомість, стандартно, до `ztunnel`. Це відкидає зміну, зроблену у Istio 1.25.
|
||||
|
||||
* **Додано** підтримку встановлення параметра `reinvocationPolicy` у веб-хуку revision-tag під час встановлення Istio за допомогою `istioctl` або Helm.
|
||||
|
||||
* **Додано** можливість налаштування сервісу `loadBalancerClass` у чарті Gateway Helm.
|
||||
([Тікет #39079](https://github.com/istio/istio/issues/39079))
|
||||
|
||||
* **Додано** значення `ConfigMap`, яке зберігає як надані користувачем значення Helm, так і обʼєднані значення після застосування профілів для чарту `istiod`.
|
||||
|
||||
* **Додано** підтримку читання значень заголовків зі змінних оточення `istiod`.
|
||||
([Тікет #53408](https://github.com/istio/istio/issues/53408))
|
||||
|
||||
* **Додано** конфігураційну `updateStrategy` для чартів `ztunnel` та `istio-cni` Helm.
|
||||
|
||||
* **Виправлено** ваду у шаблоні інʼєкції sidecar, яка некоректно видаляла наявні контейнери init, коли було вимкнено перехоплення трафіку та власний sidecar.
|
||||
([Тікет #54562](https://github.com/istio/istio/issues/54562))
|
||||
|
||||
* **Виправлено** відсутність міток `topology.istio.io/network` на pod'ах шлюзу при використанні `--set networkGateway`.
|
||||
([Тікет #54909](https://github.com/istio/istio/issues/54909))
|
||||
|
||||
* **Виправлено** проблему, коли встановлення `replicaCount=0` у чарті `istio/gateway` Helm призводило до того, що поле `replicas` було пропущено замість того, щоб бути явно встановленим у `0`.
|
||||
([Тікет #55092](https://github.com/istio/istio/issues/55092))
|
||||
|
||||
* **Виправлено** проблему, яка призводила до того, що посилання на файлові сертифікати (наприклад, з `DestinationRule` або `Gateway`) не працювали при використанні SPIRE в якості центру сертифікації.
|
||||
|
||||
* **Видалено** застарілий прапорець `ENABLE_AUTO_SNI` та повʼязані з ним шляхи коду.
|
||||
|
||||
## istioctl
|
||||
|
||||
* **Додано** параметр `--locality' до `іstioctl experimental workload group create'.
|
||||
([Тікет #54022](https://github.com/istio/istio/issues/54022))
|
||||
|
||||
* **Додано** можливість запуску певних перевірок аналізатором за допомогою команди `istioctl analyze`.
|
||||
|
||||
* **Додано** параметр `--tls-server-name` до `istioctl create-remote-secret`, який дозволяє встановити `tls-server-name` у згенерованому kubeconfig. Це гарантує успішне TLS-зʼєднання, коли поле `server` замінено на імʼя хоста проксі-шлюзу.
|
||||
|
||||
* **Додано** підтримку поля `envVarFrom` у чарті `istiod`.
|
||||
|
||||
* **Виправлено** проблему, коли `istioctl analyze` повідомляв про невідому анотацію `idecar.istio.io/statsCompression`.
|
||||
([Тікет #52082](https://github.com/istio/istio/issues/52082))
|
||||
|
||||
* **Виправлено** помилку, яка блокувала встановлення, якщо було пропущено `IstioOperator.components.gateways.ingressGateways.label` або `IstioOperator.components.gateways.ingressGateways.label`.
|
||||
([Тікет #54955](https://github.com/istio/istio/issues/54955))
|
||||
|
||||
* **Виправлено** помилку, коли `istioctl` ігнорував поля `tag` у `IstioOperator.components.gateways.ingressGateways` та `egressGateways`.
|
||||
([Тікет #54955](https://github.com/istio/istio/issues/54955))
|
||||
|
||||
* **Виправлено** проблему, коли `istioctl waypoint delete` могла видаляти ресурс, який не є шлюзом, коли було вказано імʼя.
|
||||
([Тікет #55235](https://github.com/istio/istio/issues/55235))
|
||||
|
||||
* **Виправлено** проблему, коли `istioctl experimental describe` не враховував прапорець `--namespace`.
|
||||
([Тікет #55243](https://github.com/istio/istio/issues/55243))
|
||||
|
||||
* **Виправлено** помилку, яка унеможливлювала одночасну генерацію міток `istio.io/waypoint-for` та `istio.io/rev` при створенні проксі-waypoint за допомогою `istioctl`.
|
||||
([Тікет #55437](https://github.com/istio/istio/issues/55437))
|
||||
|
||||
* **Виправлено** проблему, коли `istioctl admin log` не міг змінити рівень журналу для `ingress status`.
|
||||
([Тікет #55741](https://github.com/istio/istio/issues/55741))
|
||||
|
||||
* **Виправлено** помилку перевірки, коли у конфігурації YAML `istioctl` було встановлено `reconcileIptablesOnStartup: true`.
|
||||
([Тікет #55347](https://github.com/istio/istio/issues/55347))
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Примітки до оновлення Istio 1.26
|
||||
description: Важливі зміни, на які слід звернути увагу при оновленні до Istio 1.26.0.
|
||||
weight: 20
|
||||
---
|
||||
|
||||
При оновленні з Istio 1.25.x до Istio 1.26.x вам необхідно врахувати зміни на цій сторінці. У цих примітках детально описано зміни, які цілеспрямовано порушують зворотну сумісність з Istio 1.25.x. У примітках також згадуються зміни, які зберігають зворотну сумісність, але запроваджують нову поведінку. Зміни включено лише у тому випадку, якщо нова поведінка буде неочікуваною для користувача Istio 1.26.x.
|
||||
|
||||
## Майбутнє видалення постачальників телеметрії {#upcoming-removal-of-telemetry-providers}
|
||||
|
||||
Постачальники телеметрії для Lightstep та OpenCensus є застарілими (починаючи з 1.22 та 1.25 відповідно), оскільки їх було замінено на постачальника OpenTelemetry. Вони будуть видалені в Istio 1.27. Будь ласка, перейдіть на використання постачальника OpenTelemetry, якщо ви використовуєте будь-який з них.
|
||||
|
||||
## Зміни у чарті Ztunnel Helm {#ztunnel-helm-chart-changes-changes}
|
||||
|
||||
У Istio 1.25 ресурси в чарті ztunnel Helm було змінено на `.Resource.Name`. Це часто спричиняло проблеми, оскільки назву потрібно синхронізувати з чартом Istiod Helm.
|
||||
|
||||
У цьому випуску ми знову повернулися до стандартного статичного імені `ztunnel`. Як і раніше, його можна замінити за допомогою `--set resourceName=my-custom-name`.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Підтримку Istio 1.23 завершено
|
||||
subtitle: Оголошення про підтримку
|
||||
description: Istio 1.23 Повідомлення про завершення життєвого циклу.
|
||||
publishdate: 2025-04-16
|
||||
---
|
||||
|
||||
Як [раніше повідомлялося] (/news/support/announcing-1.23-eol/), підтримку Istio 1.23 офіційно завершено.
|
||||
|
||||
На цьому етапі ми більше не будемо здійснювати бек-порт виправлень проблем безпеки та критичних помилок у версії 1.23. Ми наполегливо рекомендуємо вам оновитися до останньої версії Istio ({{<istio_release_name>}}), якщо ви цього ще не зробили.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: Підтримка Istio 1.23 закінчується 16 квітня 2025 року
|
||||
subtitle: Оголошення про підтримку
|
||||
description: Майбутнє оголошення про завершення життя Istio 1.23.
|
||||
publishdate: 2025-03-17
|
||||
---
|
||||
|
||||
Згідно з [політикою підтримки](/docs/releases/supported-releases#support-policy) Istio, мінорні випуски, такі як 1.23, підтримуються протягом шести тижнів після випуску N+2 мінорних випусків (у цьому випадку 1.25). [Istio 1.25 було випущено 3 березня 2025 року](/news/releases/1.25.x/announcing-1.25/), а підтримка 1.23 завершиться 16 квітня 2025 року.
|
||||
|
||||
На той момент ми припинимо перенесення виправлень проблем безпеки і критичних помилок у 1.23, тому радимо вам оновитися до останньої версії Istio ({{<istio_release_name>}}). Якщо ви цього не зробите, ви можете опинитися в ситуації, коли вам доведеться виконати велике оновлення за короткий проміжок часу, щоб виправити критичну помилку.
|
||||
|
||||
Ми дбаємо про вас і ваші кластери, тому, будь ласка, зробіть оновлення.
|
||||
Loading…
Reference in New Issue