[uk] Updating the translation into Ukrainian (#15878)

* Add Ukrainian language support

* [uk] Add new blog posts for Istio community updates and events in 2024

* [uk] faq update

* [uk] update boilerplates

* [uk] update ambient

* [uk] update concepts/security

* [uk] examples

* [uk] operations

* [uk] releases

* [uk] setup

* [uk] tasks

* [uk] news

* [uk] main page

content/uk/_index.html

@@ -37,7 +37,7 @@ description: Сервісна мережа для спостережуванос
 
     <section id="landing-panels" class="container">
         <div class="panels">
-            {{< content_panel type="dark" title="latest_news" text="Istio оголошує про бета-реліз режиму оточення (ambient mode) у версії 1.22." button="read_more" url="/uk/blog/2024/ambient-reaches-beta/" >}}
+            {{< content_panel type="dark" title="latest_news" text="Istio оголошує про випуск режиму оточення (ambient mode) у версії 1.24." button="read_more" url="/uk/news/releases/1.24.x/announcing-1.24/" >}}
             {{< content_panel type="dark" title="join_the_community" text="Приєднуйтесь до більш ніж 10 000+ ваших колег, які використовують, тестують та впроваджують інновації за допомогою Istio." button="connect_with_us" url="/uk/get-involved" >}}
             {{< content_panel type="dark" title="get_started" text="Спробуйте Istio вже сьогодні. Швидко оцініть проєкт у чотири кроки." button="learn_more" url="/uk/docs/setup/getting-started" >}}
         </div>
@@ -66,7 +66,7 @@ description: Сервісна мережа для спостережуванос
             <a class="btn" href="/uk/about/case-studies">Дізнайтесь про приклади використання</a>
         </div>
     </section>
-    
+
     <section id="features" class="container">
         <h1>Можливості</h1>
 
@@ -89,7 +89,7 @@ description: Сервісна мережа для спостережуванос
             {{< company_logo link="https://cloud.google.com/service-mesh" logo="/logos/google-cloud.png" alt="Google Cloud" >}}
             {{< company_logo link="https://www.ibm.com/products/istio" logo="/logos/ibm-cloud.svg" alt="IBM Cloud" >}}
             {{< company_logo link="https://www.redhat.com/en/technologies/cloud-computing/openshift/what-is-openshift-service-mesh" logo="/logos/redhat.svg" alt="Red Hat" >}}
-            {{< company_logo link="https://learn.microsoft.com/en-us/azure/aks/istio-about" logo="/logos/microsoft-azure.svg" alt="Microsoft Azure" >}}        
+            {{< company_logo link="https://learn.microsoft.com/en-us/azure/aks/istio-about" logo="/logos/microsoft-azure.svg" alt="Microsoft Azure" >}}
             {{< company_logo link="https://www.solo.io/products/gloo-mesh/" logo="/logos/solo.png" alt="Solo.io" >}}
             {{< company_logo link="https://support.huaweicloud.com/asm/index.html/" logo="/logos/huawei.png" alt="Huawei" >}}
             {{< company_logo link="https://tetrate.io/tetrate-service-bridge/" logo="/logos/tetrate.svg" alt="Tetrate" >}}

content/uk/about/faq/setup/install-method-selection.md

@@ -13,29 +13,28 @@ weight: 10
 
     - Повна перевірка конфігурації та верифікація стану.
     - Використовує API `IstioOperator`, який надає широкі можливості конфігурації/кастомізації.
-    - Не потрібні привілейовані podʼи в кластері. Зміни виконуються шляхом запуску команди `istioctl`.
 
     Недоліки:
 
     - Необхідно керувати кількома бінарними файлами, по одному для кожної мінорної версії Istio.
-    - Команда `istioctl` може встановлювати значення, як-от `JWT_POLICY`, на основі вашого робочого середовища, що може призводити до різних установок в різних Kubernetes-середовищах.
+    - Команда `istioctl` може встановлювати значення автоматично на основі вашого робочого середовища, що може призводити до різних установок в різних Kubernetes-середовищах.
 
-1. [Генерація маніфесту за допомогою istioctl](/docs/setup/install/istioctl/#generate-a-manifest-before-installation)
+2. [Генерація маніфесту за допомогою istioctl](/docs/setup/install/istioctl/#generate-a-manifest-before-installation)
 
     Генерація Kubernetes-маніфесту, а потім застосування команди `kubectl apply --prune`. Цей метод підходить у випадках, коли потрібен суворий аудит або доопрацювання отриманих маніфестів.
 
     Переваги:
 
-    - Ресурси генеруються з того ж API `IstioOperator`, що й у `istioctl install` і Operator.
+    - Ресурси генеруються з того ж API `IstioOperator`, що й у `istioctl install`.
     - Використовує API `IstioOperator`, який надає широкі можливості конфігурації/кастомізації.
 
     Недоліки:
 
-    - Деякі перевірки, які виконуються в `istioctl install` і Operator, не виконуються.
+    - Деякі перевірки, які виконуються в `istioctl install`, не виконуються.
     - Цей тип використання з погляду користувача менш оптимізований у порівнянні з `istioctl install`.
     - Повідомлення про помилки менш інформативні, ніж у `istioctl install` на етапі застосування.
 
-1. [Установка за допомогою Helm](/docs/setup/install/helm/)
+3. [Установка за допомогою Helm](/docs/setup/install/helm/)
 
     Використання Helm-чартів дозволяє легко інтегруватися з робочими процесами на основі Helm і автоматично видаляти ресурси під час оновлень.
 
@@ -46,25 +45,7 @@ weight: 10
 
     Недоліки:
 
-    - Менше перевірок і валідацій порівняно з `istioctl install` і Operator.
+    - Менше перевірок і валідацій порівняно з `istioctl install`.
     - Деякі адміністративні завдання потребують більше кроків та мають вищу складність.
 
-1. [Istio Operator](/docs/setup/install/operator/)
-
-    {{< warning >}}
-    Використання оператора не рекомендується для нових установок. Хоча підтримка оператора триватиме, нові запити на функції не будуть мати високого пріоритету.
-    {{< /warning >}}
-
-    Istio operator забезпечує шлях установки без необхідності використовувати бінарний файл `istioctl`. Його можна використовувати для спрощених робочих процесів оновлення, якщо робота привілейованого контролера в кластері не є проблемою. Цей метод підходить, коли не потрібен суворий аудит або доопрацювання отриманих маніфестів.
-
-    Переваги:
-
-    - Такий самий API, як у `istioctl install`, але реалізація відбувається через контролер у кластері з повністю декларативною операцією.
-    - Використовує API `IstioOperator`, який надає широкі можливості конфігурації/кастомізації.
-    - Не потрібно керувати кількома бінарними файлами `istioctl`.
-
-    Недоліки:
-
-    - Робота привілейованого контролера в кластері має певні ризики з погляду безпеки.
-
 Інструкції з установки для всіх цих методів доступні на [сторінці установки Istio](/docs/setup/install).

content/uk/blog/2024/ambient-vs-cilium/index.md

@@ -0,0 +1,71 @@
+---
+title: "Масштабування в хмарі: Istio Ambient проти Cilium"
+description: Глибоке занурення в ефективність при масштабуванні.
+publishdate: 2024-10-21
+attribution: "Mitch Connors"
+keywords: [istio,cilium,analysis]
+---
+
+Звичне питання від потенційних користувачів Istio: "Як порівняти Istio з Cilium?" Хоча спочатку Cilium пропонував лише функціональність L3/L4, включаючи мережеву політику, останні релізи додали функції сервісної мережі за допомогою Envoy, а також шифрування за допомогою WireGuard. Як і Istio, Cilium є проєктом, що досяг статусу CNCF Graduated, та присутній у спільноті протягом багатьох років.
+
+Попри подібний набір функцій, ці два проєкти мають суттєво різні архітектури, особливо в тому, як Cilium використовує eBPF та WireGuard для обробки та шифрування L4-трафіку в ядрі, на відміну від Istio, який використовує компонент ztunnel для L4 у просторі користувача. Ці відмінності породили чимало припущень щодо продуктивності Istio на великих масштабах у порівнянні з Cilium.
+
+Хоча вже було зроблено чимало порівнянь щодо моделей оренди, протоколів безпеки та базової продуктивності двох проєктів, повна оцінка на рівні корпоративного масштабу ще не опублікована. Замість теоретичних показників продуктивності, ми випробували режим ambient в Istio та Cilium у реальних навантаженнях, зосередившись на таких ключових метриках, як затримка, пропускна здатність та споживання ресурсів. Ми збільшили навантаження у реалістичних сценаріях для Kubernetes, і врешті-решт розширили наш кластер AKS до 1 000 вузлів на 11 000 ядрах, щоб зрозуміти, як ці проєкти поводяться на великих масштабах. Наші результати показують, що обидва проєкти мають місце для вдосконалення, але також вказують, що Istio є очевидним переможцем.
+
+## Сценарій тестування {#test-scenario}
+
+Щоб випробувати Istio та Cilium на межі можливостей, ми створили 500 різних сервісів, кожен з яких підтримувався 100 подами. Кожен сервіс був створений в окремому просторі імен, який також містив клієнта для навантаження [Fortio](https://fortio.org/). Ми обмежили клієнтів пулом вузлів зі 100 32-ядерних машин, щоб усунути шум від спільних клієнтів, та виділили решту 900 8-ядерних екземплярів для наших сервісів.
+
+{{< image width="60%"
+    link="./scale-scenario.png"
+    alt="Масштабування до 500 сервісів з 50 000 подами."
+    >}}
+
+Для тесту Istio ми використали його режим ambient з [waypoint проксі](/docs/ambient/usage/waypoint/) у кожному просторі імен сервісу та стандартними параметрами інсталяції. Щоб зробити наші тестові сценарії схожими, ми увімкнули кілька нестандартних функцій у Cilium, включаючи шифрування WireGuard, L7-проксі та Node Init. Ми також створили мережеву політику Cilium у кожному просторі імен з правилами на основі HTTP-шляхів. У кожному сценарії ми створили зміни, масштабуючи один сервіс випадковим чином між 85 і 115 екземплярами щосекунди та переіменовуючи один простір імен щохвилини. Для перегляду точних налаштувань, які ми використовували, та для відтворення наших результатів, дивіться [ці нотатки](https://github.com/therealmitchconnors/tools/blob/2384dc26f114300687b21f921581a158f27dc9e1/perf/load/many-svc-scenario/README.md).
+
+## Оцінка масштабованості {#scalability-scorecard}
+
+{{< image width="80%"
+    link="./scale-scorecard.png"
+    alt="Оцінка масштабованості: Istio проти Cilium!"
+    >}}
+
+Istio вдалося обробити на 56% більше запитів за 20% меншої затримки. Споживання ресурсів процесора було на 30% менше у Cilium, хоча наші вимірювання не враховують ядра, які Cilium використовував для обробки шифрування, що здійснюється у ядрі.
+
+Враховуючи використані ресурси, Istio обробила 2178 запитів на ядро проти 1815 у Cilium, що є покращенням на 20%.
+
+* **Уповільнення Cilium:** Хоча Cilium має напрочуд низьку затримку зі стандартними параметрами встановлення, він значно уповільнюється, коли активуються основні функції Istio, такі як політики L7 та шифрування. Крім того, споживання памʼяті та процесора в Cilium залишалося високим, навіть коли в мережі не було трафіку. Це може вплинути на загальну стабільність та надійність вашого кластера, особливо при його зростанні.
+* **Istio — стабільний гравець:** Режим ambient в Istio продемонстрував свою силу у стабільності та підтримці пристойної пропускної здатності, навіть з додатковим навантаженням через шифрування. Хоча Istio споживав більше памʼяті та процесора ніж Cilium під час тесту, використання процесора стабілізувалося на рівні, що значно нижчий, ніж у Cilium, коли мережа не була навантажена.
+
+## За лаштунками: Чому така різниця? {#behind-the-scenes-why-the-difference}
+
+Ключ до розуміння цих відмінностей у продуктивності лежить в архітектурі та дизайні кожного інструменту.
+
+* **Дилема панелі управління Cilium:** Cilium запускає екземпляр панелі управління на кожному вузлі, що спричиняє навантаження на API-сервер та створює додаткові конфігураційні складнощі зі збільшенням кластера. Це часто призводило до збоїв API-сервера, через що Cilium ставав недоступним, і весь кластер ставав неактивним.
+* **Перевага Istio в ефективності:** Istio, завдяки централізованій панелі управління та підходу, заснованому на ідентифікації, спрощує конфігурацію та зменшує навантаження на API-сервер і вузли, спрямовуючи критичні ресурси на обробку та захист трафіку.
+
+## Додаткові подробиці {#digging-deeper}
+
+Хоча метою цього проєкту є порівняння масштабованості Istio та Cilium, існують кілька обмежень, що ускладнюють пряме порівняння.
+
+### Не завжди L4 — це L4 {#layer-4-isnt-always-layer-4}
+
+Хоча Istio та Cilium обидва забезпечують політику L4, їхні API та реалізація значно відрізняються.
+
+### Не все шифрування однакове {#not-all-encryption-is-created-equal}
+
+Cilium підтримує IPsec для шифрування, що відповідає FIPS, проте більшість інших функцій Cilium, як-от політика L7 та балансування навантаження, несумісні з IPsec.
+
+### Приховані витрати {#hidden-costs}
+
+Хоча Istio повністю працює у просторі користувача, панель даних L4 Cilium працює в ядрі Linux за допомогою eBPF. Метрики Prometheus для використання ресурсів враховують лише ресурси простору користувача.
+
+## Рекомендації: Вибір правильного інструменту для завдання {#recommendations-choosing-the-right-tool-for-the-job}
+
+Отже, яке рішення обрати? Це залежить від ваших конкретних потреб і пріоритетів. Для малих кластерів з чисто L3/L4 сценаріями використання та без потреби в шифруванні, Cilium пропонує економічно вигідне та продуктивне рішення. Проте для більших кластерів з акцентом на стабільність, масштабованість та розширені функції, варто обрати Istio в режимі ambient разом з альтернативною реалізацією NetworkPolicy. Багато клієнтів поєднують L3/L4 функції Cilium з L4/L7 та функціями шифрування Istio для стратегії багаторівневого захисту.
+
+Памʼятайте, що світ cloud-native мережевих технологій постійно розвивається. Слідкуйте за розвитком як Istio, так і Cilium, оскільки обидва інструменти продовжують вдосконалюватись і вирішувати ці виклики.
+
+## Продовжимо спілкування {#lets-keep-the-conversation-going}
+
+Ви вже працювали з Istio в режимі ambient або з Cilium? Які у вас досвід та враження? Поділіться своїми думками в коментарях нижче. Вчімося один в одного та разом досліджуймо захопливий світ Kubernetes!

content/uk/blog/2024/in-cluster-operator-deprecation-announcement/index.md

@@ -10,7 +10,7 @@ In-Cluster Operator Istio було визнано застарілим в Istio
 
 ## Чи це вплине на вас? {#does-this-affect-you}
 
-Це застарівання стосується лише користувачів [In-Cluster Operator](/docs/setup/install/operator/). **Користувачі, які встановлюють Istio за допомогою команди <code>istioctl install</code> і YAML файлу `IstioOperator`, не постраждають**.
+Це застарівання стосується лише користувачів [In-Cluster Operator](https://archive.istio.io/v1.23/docs/setup/install/operator/). **Користувачі, які встановлюють Istio за допомогою команди <code>istioctl install</code> і YAML файлу `IstioOperator`, не постраждають**.
 
 Щоб визначити, чи це вплине на вас, виконайте команди `kubectl get deployment -n istio-system istio-operator` і `kubectl get IstioOperator`. Якщо обидві команди повертають непорожні значення, ваш кластер знаходиться під впливом цього застарівання. Згідно з останніми опитуваннями, ми очікуємо, що це вплине на менше ніж 10% користувачів Istio.
 

content/uk/blog/2024/kubecon-na/index.md

@@ -0,0 +1,36 @@
+---
+title: "Istio в Солт-Лейк-Сіті!"
+description: Вітайте Istio на KubeCon + CloudNativeCon North America 2024.
+publishdate: 2024-11-05
+attribution: "Faseela K, від імені Istio Steering Committee"
+keywords: [Istio Day,Istio,conference,KubeCon,CloudNativeCon]
+---
+
+Неймовірна програма заходів Istio чекає на вас у Солт-Лейк-Сіті, штат Юта, на [KubeCon + CloudNativeCon North America 2024](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)!
+
+{{< image width="75%"
+    link="./kubecon-na.png"
+    alt="KubeCon + CloudNativeCon North America, 12-15 листопада 2024, Солт-Лейк-Сіті, Юта. #KubeCon"
+    >}}
+
+- Відвідайте [Istio Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/co-located-events/istio-day/), що проводиться на конференції.
+- Долучайтеся до сесії Istio Maintainers' Track: [Життя пакета: Ambient Edition](https://sched.co/1hovw)
+- Завітайте на сесію Istio Contribfest: [Сервісна мережа без sidecar: Давайте разом працювати над Istio V2](https://sched.co/1hoyI)
+
+- Додайте наступні сесії KubeCon до свого розкладу, всі вони мають тематику Istio:
+    - [Чому обрати Istio у 2025 році | Короткі доповіді проєктів](https://sched.co/1iW9Q)
+    - [Короткі доповіді: Легке, без sidecarʼів mTLS та політики авторизації за 5 хвилин](https://sched.co/1i7k0)
+    - [Cесія gjcnthsd: Використання прогнозування для масштабування компонентів панелі управління](https://sched.co/1i7mr)
+    - [Що Istio зробив неправильно: уроки з семирічного досвіду в Service Mesh](https://sched.co/1i7nP)
+    - [Навчання: Робота з API Gateway V1.2](https://sched.co/1i7np)
+    - [`Mish-Mesh`: Використання Service Mesh для компрометації середовищ Kubernetes](https://sched.co/1i7ow)
+    - [Взаємодія з KServe Community: Вплив інтеграції з проєктами CNCF](https://sched.co/1i7r4)
+    - [Як Google створив нову хмару на базі Kubernetes](https://sched.co/1i7pE)
+    - [Забезпечення вихідного трафіку: створення потужного шлюзу для надійного зʼєднання з Інтернетом](https://sched.co/1i7ps)
+    - [Тестування Kubernetes без Kubernetes: глибокий аналіз мережевих рішень](https://sched.co/1i7qh)
+    - [Як GoTo Financial автоматизує оновлення більш ніж 60 Istio Service Mesh без простоїв!](https://sched.co/1i7rH)
+
+- Поспілкуйтеся з розробниками та користувачами на стенді Istio в Project Pavilion протягом усього заходу, де ви зможете отримати круту футболку Istio з новим дизайном.
+- У нас також буде цікавий сюрприз для всіх шанувальників Istio, який буде представлено в магазині CNCF на KubeCon North America. Слідкуйте за новинами!
+
+Слідкуйте за нами на [X](https://x.com/istiomesh), [LinkedIn](https://www.linkedin.com/company/istio/) або [Bluesky](https://bsky.app/profile/istio.io), щоб отримувати актуальні новини з події. До зустрічі!

content/uk/blog/2024/l7-policy-with-opa/index.md

@@ -0,0 +1,454 @@
+---
+title: "Чи може ваша платформа реалізовувати політики? Прискорте команди завдяки функціональності платформних політик L7"
+description: Чи є політика вашою основною компетенцією? Ймовірно, ні, але важливо зробити все правильно. Зробіть це один раз з Istio та OPA і поверніть команді фокус на те, що має найбільше значення.
+publishdate: 2024-10-14
+attribution: "Antonio Berben (Solo.io), Charlie Egan (Styra)"
+keywords: [istio,opa,policy,platform,authorization]
+---
+
+Спільні обчислювальні платформи надають ресурси та функціональність для команд орендарів, щоб їм не доводилося створювати все з нуля. Хоча часом буває важко збалансувати всі запити від орендарів, важливо, щоб платформа ставила питання: яку найціннішу функцію ми можемо запропонувати нашим орендарям?
+
+Часто роботу доручають безпосередньо командам що створюють застосунки, але деякі функції найкраще реалізувати один раз і надавати їх як сервіс для всіх команд. Однією з таких функцій, яку може запропонувати більшість команд, що опікуються платформами, є надання стандартної, гнучкої системи політики авторизації для рівня застосунків L7. Політика як код дозволяє командам переносити рішення щодо авторизації з рівня застосунків у легку та ефективну розподілену систему. Це може здатися складним завданням, але з правильними інструментами воно не обов’язково є таким.
+
+Ми розглянемо, як Istio та Open Policy Agent (OPA) можуть використовуватися для забезпечення політик рівня L7 у вашій платформі. Ми покажемо, як почати з простого прикладу. Ви побачите, як ця комбінація є надійним варіантом для швидкого і прозорого надання політик командам розробки застосунків у бізнесі, а також забезпечує дані, необхідні командам безпеки для аудиту та дотримання стандартів.
+
+## Спробуйте самі {#try-it-out}
+
+Коли OPA інтегровано з Istio, він може використовуватися для забезпечення детальних політик контролю доступу для мікросервісів. У цьому посібнику описано, як забезпечити політики контролю доступу для простого мікросервісного застосунку.
+
+### Попередні вимоги {#prerequisites}
+
+- Кластер Kubernetes з встановленим Istio.
+- Встановлений інструмент командного рядка `istioctl`.
+
+Встановіть Istio і налаштуйте [параметри mesh](/docs/reference/config/istio.mesh.v1alpha1/), щоб увімкнути OPA:
+
+{{< text bash >}}
+$ istioctl install -y -f - <<'EOF'
+apiVersion: install.istio.io/v1alpha1
+kind: IstioOperator
+spec:
+  meshConfig:
+    accessLogFile: /dev/stdout
+    accessLogFormat: |
+      [OPA DEMO] my-new-dynamic-metadata: "%DYNAMIC_METADATA(envoy.filters.http.ext_authz)%"
+    extensionProviders:
+    - name: "opa.local"
+      envoyExtAuthzGrpc:
+        service: "opa.opa.svc.cluster.local"
+        port: "9191"
+EOF
+{{< /text >}}
+
+Зверніть увагу, що в конфігурації ми визначаємо розділ `extensionProviders`, який вказує на самостійне встановлення OPA.
+
+Розгорніть приклад застосунків. Httpbin — відомий застосунок, який можна використовувати для тестування HTTP-запитів; він швидко демонструє, як можна працювати з атрибутами запиту та відповіді.
+
+{{< text bash >}}
+$ kubectl create ns my-app
+$ kubectl label namespace my-app istio-injection=enabled
+
+$ kubectl apply -f {{< github_file >}}/samples/httpbin/httpbin.yaml -n my-app
+{{< /text >}}
+
+Розгорніть OPA. Це не вдасться, оскільки очікується `configMap`, що містить стандартне правило Rego для використання. Цей `configMap` буде розгорнуто пізніше у нашому прикладі.
+
+{{< text bash >}}
+$ kubectl create ns opa
+$ kubectl label namespace opa istio-injection=enabled
+
+$ kubectl apply -f - <<EOF
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app: opa
+  name: opa
+  namespace: opa
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: opa
+  template:
+    metadata:
+      labels:
+        app: opa
+    spec:
+      containers:
+      - image: openpolicyagent/opa:0.61.0-envoy
+        name: opa
+        args:
+          - "run"
+          - "--server"
+          - "--disable-telemetry"
+          - "--config-file=/config/config.yaml"
+          - "--log-level=debug" # Розкоментуйте цей рядок, щоб увімкнути журнали налагодження
+          - "--diagnostic-addr=0.0.0.0:8282"
+          - "/policy/policy.rego" # Стандартна політика
+        volumeMounts:
+          - mountPath: "/config"
+            name: opa-config
+          - mountPath: "/policy"
+            name: opa-policy
+      volumes:
+        - name: opa-config
+          configMap:
+            name: opa-config
+        - name: opa-policy
+          configMap:
+            name: opa-policy
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: opa-config
+  namespace: opa
+data:
+  config.yaml: |
+    # Тут ви знайдете конфігурацію OPA, яку ви можете знайти в офіційній документації
+    decision_logs:
+      console: true
+    plugins:
+      envoy_ext_authz_grpc:
+        addr: ":9191"
+        path: mypackage/mysubpackage/myrule # Default path for grpc plugin
+    # Тут ви можете додати власну конфігурацію з сервісами та пакетами
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: opa
+  namespace: opa
+  labels:
+    app: opa
+spec:
+  ports:
+    - port: 9191
+      protocol: TCP
+      name: grpc
+  selector:
+    app: opa
+---
+EOF
+{{< /text >}}
+
+Розгорніть `AuthorizationPolicy`, щоб визначити, які служби будуть захищені OPA.
+
+{{< text bash >}}
+$ kubectl apply -f - <<EOF
+apiVersion: security.istio.io/v1
+kind: AuthorizationPolicy
+metadata:
+  name: my-opa-authz
+  namespace: istio-system # Цей рядок застосовує політику до всіх мереж в просторі назв налаштувань istio-system
+spec:
+  selector:
+    matchLabels:
+      ext-authz: enabled
+  action: CUSTOM
+  provider:
+    name: "opa.local"
+  rules: [{}] # Порожнє правило, буде застосовуватися до селекторів з міткою ext-authz: enabled
+EOF
+{{< /text >}}
+
+Позначімо застосунок міткою, щоб впровадити політику:
+
+{{< text bash >}}
+$ kubectl patch deploy httpbin -n my-app --type=merge -p='{
+  "spec": {
+    "template": {
+      "metadata": {
+        "labels": {
+          "ext-authz": "enabled"
+        }
+      }
+    }
+  }
+}'
+{{< /text >}}
+
+Зверніть увагу, що в цьому ресурсі ми визначаємо OPA `extensionProvider`, який ви встановили в конфігурації Istio:
+
+{{< text yaml >}}
+[...]
+  provider:
+    name: "opa.local"
+[...]
+{{< /text >}}
+
+## Як це працює {#how-it-works}
+
+При застосуванні `AuthorizationPolicy` панель управління Istio (istiod) надсилає необхідні конфігурації до sidecar проксі (Envoy) вибраних сервісів, зазначених у політиці. Envoy потім відправляє запит на сервер OPA, щоб перевірити, чи дозволено цей запит.
+
+{{< image width="75%"
+    link="./opa1.png"
+    alt="Istio та OPA"
+    >}}
+
+Проксі Envoy працює шляхом налаштування фільтрів у ланцюгу. Одним із таких фільтрів є `ext_authz`, який реалізує зовнішню службу авторизації з певним повідомленням. Будь-який сервер, що реалізує відповідний protobuf, може підʼєднатися до проксі Envoy та надати рішення щодо авторизації; OPA є одним з таких серверів.
+
+{{< image width="75%"
+    link="./opa2.png"
+    alt="Фільтри"
+    >}}
+
+Раніше, коли ви встановлювали сервер OPA, ви використовували версію сервера Envoy. Цей образ дозволяє налаштувати втулок gRPC, який впроваджує службу `ext_authz` protobuf.
+
+{{< text yaml >}}
+[...]
+      containers:
+      - image: openpolicyagent/opa:0.61.0-envoy # Це версія образу OPA з втулком Envoy
+        name: opa
+[...]
+{{< /text >}}
+
+У конфігурації ви увімкнули втулок Envoy та порт, на якому він слухає:
+
+{{< text yaml >}}
+[...]
+    decision_logs:
+      console: true
+    plugins:
+      envoy_ext_authz_grpc:
+        addr: ":9191" # Це порт, на якому буде слухати втулок Envoy
+        path: mypackage/mysubpackage/myrule # Стандартний шлях для втулка grpc
+    # Тут ви можете додати власну конфігурацію з сервісами та наборами даних
+[...]
+{{< /text >}}
+
+Переглядаючи [документацію про службу авторизації Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto), можна побачити, що повідомлення має такі атрибути:
+
+{{< text json >}}
+OkHttpResponse
+{
+  "status": {...},
+  "denied_response": {...},
+  "ok_response": {
+      "headers": [],
+      "headers_to_remove": [],
+      "dynamic_metadata": {...},
+      "response_headers_to_add": [],
+      "query_parameters_to_set": [],
+      "query_parameters_to_remove": []
+    },
+  "dynamic_metadata": {...}
+}
+{{< /text >}}
+
+Це означає, що на основі відповіді від сервера authz Envoy може додавати або видаляти заголовки, параметри запиту та навіть змінювати статус відповіді. OPA також може це робити, як описано в його [документації](https://www.openpolicyagent.org/docs/latest/envoy-primer/#example-policy-with-additional-controls).
+
+## Тестування {#testing}
+
+Протестуймо просте використання (авторизацію), а потім створимо більш розширене правило, щоб показати, як можна використовувати OPA для зміни запиту та відповіді.
+
+Розгорніть застосунок для запуску команд curl до тестового застосунку httpbin:
+
+{{< text bash >}}
+$ kubectl -n my-app run --image=curlimages/curl curl -- /bin/sleep 100d
+{{< /text >}}
+
+Застосуйте перше правило Rego і перезапустіть розгортання OPA:
+
+{{< text bash >}}
+$ kubectl apply -f - <<EOF
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: opa-policy
+  namespace: opa
+data:
+  policy.rego: |
+    package mypackage.mysubpackage
+
+    import rego.v1
+
+    default myrule := false
+
+    myrule if {
+      input.attributes.request.http.headers["x-force-authorized"] == "enabled"
+    }
+
+    myrule if {
+      input.attributes.request.http.headers["x-force-authorized"] == "true"
+    }
+EOF
+{{< /text >}}
+
+{{< text bash >}}
+$ kubectl rollout restart deployment -n opa
+{{< /text >}}
+
+Простий сценарій передбачає дозвіл запитів, якщо вони містять заголовок `x-force-authorized` зі значенням `enabled` або `true`. Якщо заголовок відсутній або має інше значення, запит буде відхилено.
+
+Існує кілька способів створити правило Rego. У цьому випадку ми створили два різні правила. Виконуються вони у порядку, і перше правило, яке задовольняє всі умови, буде застосоване.
+
+### Просте правило {#simple-rule}
+
+Результатом наступного запиту буде відповідь `403`:
+
+{{< text bash >}}
+$ kubectl exec -n my-app curl -c curl  -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get
+{{< /text >}}
+
+Наступний запит поверне `200` та тіло відповіді:
+
+{{< text bash >}}
+$ kubectl exec -n my-app curl -c curl  -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get -H "x-force-authorized: enabled"
+{{< /text >}}
+
+### Складніші маніпуляції {#advanced-manipulations}
+
+Тепер складніше правило. Застосуйте друге правило Rego і перезапустіть розгортання OPA:
+
+{{< text bash >}}
+$ kubectl apply -f - <<EOF
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: opa-policy
+  namespace: opa
+data:
+  policy.rego: |
+    package mypackage.mysubpackage
+
+    import rego.v1
+
+    request_headers := input.attributes.request.http.headers
+
+    force_unauthenticated if request_headers["x-force-unauthenticated"] == "enabled"
+
+    default allow := false
+
+    allow if {
+      not force_unauthenticated
+      request_headers["x-force-authorized"] == "true"
+    }
+
+    default status_code := 403
+
+    status_code := 200 if allow
+
+    status_code := 401 if force_unauthenticated
+
+    default body := "Unauthorized Request"
+
+    body := "Authentication Failed" if force_unauthenticated
+
+    myrule := {
+      "body": body,
+      "http_status": status_code,
+      "allowed": allow,
+      "headers": {"x-validated-by": "my-security-checkpoint"},
+      "response_headers_to_add": {"x-add-custom-response-header": "added"},
+      "request_headers_to_remove": ["x-force-authorized"],
+      "dynamic_metadata": {"my-new-metadata": "my-new-value"},
+    }
+EOF
+{{< /text >}}
+
+{{< text bash >}}
+$ kubectl rollout restart deployment -n opa
+{{< /text >}}
+
+В цьому правилі ви можете побачити:
+
+{{< text plain >}}
+myrule["allowed"] := allow # Зверніть увагу, що `allowed` є обовʼязковим при поверненні обʼєкта, як тут `myrule`.
+myrule["headers"] := headers
+myrule["response_headers_to_add"] := response_headers_to_add
+myrule["request_headers_to_remove"] := request_headers_to_remove
+myrule["body"] := body
+myrule["http_status"] := status_code
+{{< /text >}}
+
+Це значення, які будуть повернуті проксі-серверу Envoy від OPA-сервера. Envoy буде використовувати ці значення для модифікації запиту і відповіді.
+
+Зверніть увагу, що при поверненні JSON-обʼєкта потрібно вказувати `allowed`, а не тільки true/false. Це можна знайти [в документації OPA](https://www.openpolicyagent.org/docs/latest/envoy-primer/#output-document).
+
+#### Зміна тіла відповіді {#change-returned-body}
+
+Випробуємо нові можливості:
+
+{{< text bash >}}
+$ kubectl exec -n my-app curl -c curl  -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get
+{{< /text >}}
+
+Тепер ми можемо змінити тіло відповіді. Значення `403` змінює тіло в правилі Rego на «Unauthorized Request» (Несанкціонований запит). За допомогою попередньої команди ви повинні отримати:
+
+{{< text plain >}}
+Unauthorized Request
+http_code=403
+{{< /text >}}
+
+#### Зміна тіла, що повертається і коду статусу {#change-returned-body-and-status-code}
+
+Запустивши запит із заголовком `x-force-authorized: enabled` ви повинні отримати тіло «Authentication Failed» і помилку «401»:
+
+{{< text bash >}}
+$ kubectl exec -n my-app curl -c curl  -- curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get -H "x-force-unauthenticated: enabled"
+{{< /text >}}
+
+#### Додавання заголовків до запиту {#adding-headers-to-request}
+
+Запустивши відповідний запит, ви повинні отримати тіло відповіді з новим заголовком `x-validated-by: my-security-checkpoint` і видаленим заголовком `x-force-authorized`:
+
+{{< text bash >}}
+$ kubectl exec -n my-app curl -c curl  -- curl -s httpbin:8000/get -H "x-force-authorized: true"
+{{< /text >}}
+
+#### Додавання заголовків до відповіді {#adding-headers-to-response}
+
+Запустивши той самий запит, але показавши лише заголовок, ви побачите заголовок відповіді, доданий під час перевірки Authz `x-add-custom-response-header: added`:
+
+{{< text bash >}}
+$ kubectl exec -n my-app curl -c curl  -- curl -s -I httpbin:8000/get -H "x-force-authorized: true"
+{{< /text >}}
+
+#### Обмін даними між фільтрами {#sharing-data-between-filters}
+
+Останнім кроком є передача даних іншим фільтрам Envoy за допомогою `dynamic_metadata`. Це корисно, коли потрібно передати дані іншому фільтру `ext_authz` у ланцюзі або вивести їх у логи застосунку.
+
+{{< image width="75%"
+    link="./opa3.png"
+    alt="Metadata"
+    >}}
+
+Для цього перегляньте формат журналу доступу, який ви налаштували раніше:
+
+{{< text plain >}}
+[...]
+    accessLogFormat: |
+      [OPA DEMO] my-new-dynamic-metadata: "%DYNAMIC_METADATA(envoy.filters.http.ext_authz)%"
+[...]
+{{< /text >}}
+
+`DYNAMIC_METADATA` — це зарезервоване ключове слово для доступу до обʼєкта метаданих. Далі вказується назва фільтра, до якого ви хочете звернутися. У вашому випадку, імʼя `envoy.filters.http.ext_authz` автоматично створюється Istio. Ви можете перевірити це, вивівши конфігурацію Envoy:
+
+{{< text bash >}}
+$ istioctl pc all deploy/httpbin -n my-app -oyaml | grep envoy.filters.http.ext_authz
+{{< /text >}}
+
+Ви побачите конфігурації для фільтра.
+
+Тепер перевіримо динамічні метадані. У розширеному правилі ви створюєте новий запис метаданих: `{"my-new-metadata": "my-new-value"}`.
+
+Виконайте запит і перевірте логи застосунку:
+
+{{< text bash >}}
+$ kubectl exec -n my-app curl -c curl  -- curl -s -I httpbin:8000/get -H "x-force-authorized: true"
+$ kubectl logs -n my-app deploy/httpbin -c istio-proxy --tail 1
+{{< /text >}}
+
+У виводі ви побачите нові атрибути, налаштовані за допомогою правил OPA Rego:
+
+{{< text plain >}}
+[...]
+ my-new-dynamic-metadata: "{"my-new-metadata":"my-new-value","decision_id":"8a6d5359-142c-4431-96cd-d683801e889f","ext_authz_duration":7}"
+[...]
+{{< /text >}}
+
+## Підсумки {#conclusion}
+
+У цьому посібнику ми показали, як інтегрувати Istio та OPA для впровадження політик для простого мікросервісного застосунку. Ми також продемонстрували, як використовувати Rego для модифікації атрибутів запиту та відповіді. Це основний приклад для побудови системи політик на платформі, яку можуть використовувати всі команди розробників застосунків.

content/uk/blog/2024/link-the-istio-service-mesh-for-people-who-have-stuff-to-do.md

@@ -0,0 +1,13 @@
+---
+title: "Зовнішня публікація: Сервісна мережа Istio для тих, хто має справи"
+description: Прочитайте про досвід Луки Каваліна у роботі з Istio.
+publishdate: 2024-10-10
+attribution: Luca Cavallin - GitHub
+link: https://www.lucavall.in/blog/the-istio-service-mesh-for-people-who-have-stuff-to-do
+---
+
+{{< quote >}}
+Нещодавно я зробив невеликий внесок в Istio, проєкт з відкритим кодом для створення сервісних мереж. Мій внесок полягав у додаванні кількох тестів для однієї з команд CLI Istio. Якщо вам цікаві деталі, ви можете знайти pull request тут. Це були незначні зміни, але чудовий досвід навчання. Робота з Istio допомогла мені глибше зрозуміти сервісні мережі. Я з нетерпінням чекаю можливості зробити ще більше змін. У цій публікації я поясню, що таке Istio, чому цей проєкт може бути корисним та як він працює.
+{{< /quote >}}
+
+[Прочитайте повну публікацію на lucavall.in](https://www.lucavall.in/blog/the-istio-service-mesh-for-people-who-have-stuff-to-do).

content/uk/blog/2024/toc-charter-elections/index.md

@@ -0,0 +1,56 @@
+---
+title: "Залучення спільноти: Регулярні вибори в Технічний наглядовий комітет Istio"
+description: Оголошення змін у статуті TOC та перших відкритих виборів.
+publishdate: 2024-10-17
+attribution: "Craig Box, від імені Istio Steering Committee"
+keywords: [istio,toc,governance,community,election]
+---
+
+Як і багато проєктів з відкритим кодом, проєкт Istio має дві керівні групи: [Керівний комітет](https://github.com/istio/community/blob/master/steering/CHARTER.md), що відповідає за адміністративні та маркетингові аспекти проєкту, і [Технічний наглядовий комітет](https://github.com/istio/community/blob/master/TECH-OVERSIGHT-COMMITTEE.md) (TOC), що відповідає за прийняття важливих рішень щодо продукту та дизайну.
+
+Керівний комітет представляє компанії та учасників, які підтримують проєкт Istio, тоді як TOC є найвищим щаблем в [індивідуальній системі внесків](https://github.com/istio/community/blob/master/ROLES.md), що включає членів, мейнтейнерів та лідерів робочих груп.
+
+Щороку ми формуємо Керівний комітет з представників наших основних комерційних учасників і членів, обраних нашою спільнотою мейнтейнерів. Саме ця група відповідає за вибори нових членів TOC, які раніше виконували свої обовʼязки безстроково.
+
+Ми хочемо гарантувати, що всі члени нашої спільноти мають можливість висувати свої кандидатури та обіймати наші керівні посади. Сьогодні ми раді оголосити про перехід до регулярних виборів у TOC, де члени працюватимуть впродовж дворічного терміну, і закликаємо кандидатів до участі у наших перших виборах.
+
+## Чим займається Технічний наглядовий комітет?
+
+Статут TOC описує обовʼязки його членів, включаючи:
+
+* Встановлення загального технічного напрямку та планів проєкту.
+* Розвʼязання технічних питань, розбіжностей і суперечок.
+* Призначення [рівнів зрілості для функцій Istio](/docs/releases/feature-stages/).
+* Схвалення створення та розпуску робочих груп і затвердження змін у керівництві робочих груп.
+* Забезпечення дотримання [кодексу поведінки](https://github.com/istio/community/blob/master/CONTRIBUTING.md#code-of-conduct) та поваги до [цінностей спільноти](https://github.com/istio/community/blob/master/VALUES.md).
+* Створення здорової та дружньої атмосфери для розробників і учасників спільноти.
+
+Хоча інтереси наших комерційних партнерів представлені Керівним комітетом, членство в TOC пов’язане з особистістю, незалежно від їхнього роботодавця. Члени діють незалежно, у своїй індивідуальній якості, і повинні ставити інтереси проєкту та спільноти на перше місце. Всі рішення ухвалюються на основі консенсусу, і тому кількість членів TOC є парною. TOC традиційно складається з 6 членів, і це залишиться без змін.
+
+## Що змінюється з новим статутом?
+
+Основні зміни в [новому статуті](https://github.com/istio/community/blob/master/TECH-OVERSIGHT-COMMITTEE.md#charter), нещодавно ратифікованому Керівним комітетом, включають:
+
+* Члени тепер працюватимуть терміном у 2 роки.
+* Керівний комітет щороку голосуватиме за переобрання 3 із 6 членів TOC.
+* Процедура виборів [чітко визначена](https://github.com/istio/community/blob/master/TECH-OVERSIGHT-COMMITTEE.md#qualification-and-eligibility), включаючи вимоги до кандидатів та оцінювання.
+* Формалізовано очікування щодо регулярних зустрічей між Керівним комітетом і TOC.
+* Передбачено формальний процес усунення члена TOC у разі втрати довіри з боку Керівного комітету.
+
+<sup>†</sup> Немає обмежень на кількість термінів, протягом яких член може перебувати на посаді, і чинні члени TOC можуть знову балотуватися після закінчення їхнього терміну.
+
+## Прощання з членами TOC
+
+Ми нещодавно оголосили про [вихід з проєкту давнього учасника Еріка Ван Нормана](/news/releases/1.22.x/announcing-1.22/#a-thank-you). Також ми прощаємось із Ніраджем Поддаром з Istio TOC. Нірадж брав участь у проєкті з 2017 року, став співзасновником Aspen Mesh у F5, а пізніше очолював Gloo Mesh як віце-президент з інженерії в Solo.io. Він вперше був обраний до TOC у 2020 році. [Нірадж прийняв посаду віце-президента інженерії в NimbleEdge](https://www.linkedin.com/feed/update/urn:li:activity:7251958639400206336/), і ми вітаємо його та бажаємо успіхів у майбутньому.
+
+## Мейнтейнери: беріть участь у перших виборах
+
+Ми запланували щорічні вибори до TOC після формування Керівного комітету кожного року, що дозволить провести перші вибори приблизно в березні 2025 року.
+
+Однак, оскільки в нас наразі є дві вакансії, ми оголошуємо наші перші вибори як додаткові, щоб заповнити ці два місця на [решту їхніх термінів](https://github.com/istio/community/blob/master/TECH-OVERSIGHT-COMMITTEE.md#members).
+
+Планка для приєднання до TOC навмисно встановлена високо. Кандидати повинні бути постійними мантейнерами, визнаними у спільноті Istio як технічні лідери, здатні до співпраці, і відповідати [вимогам кваліфікації](https://github.com/istio/community/blob/master/TECH-OVERSIGHT-COMMITTEE.md#qualification-and-eligibility), які демонструють їхню відповідність цій посаді.
+
+Щоб подати заявку на місце в TOC, надішліть електронного листа на [elections@istio.io](mailto:elections@istio.io), включивши посилання на односторінковий документ Google Doc з вашою самооцінкою за критеріями кваліфікації. Приймання заявок закривається через два тижні, 31 жовтня.
+
+Бажаємо успіхів!

content/uk/boilerplates/auto-san-validation.md

@@ -0,0 +1,5 @@
+---
+---
+{{< tip >}}
+Istio стандартно має `auto_sni` та `auto_san_validation` увімкненими. Це означає, що коли у вашому правилі `DestinationRule` не вказано явного значення `sni`, SNI транспортного сокета для нових висхідних зʼєднань буде встановлено на основі заголовка HTTP-хоста/авторитету нижчого рівня. Якщо в правилі `DestinationRule` не задано `subjectAltNames`, а `sni` не встановлено, спрацює `auto_san_validation`, і сертифікат, наданий висхідним потоком, для нових висхідних зʼєднань буде автоматично перевірено на основі низхідного заголовка HTTP-хоста/авторитету.
+{{< /tip >}}

content/uk/boilerplates/before-you-begin-egress.md

@@ -8,16 +8,16 @@
     Egress gateway та доступ до логів будуть увімкнені, якщо ви встановите профіль конфігурації `demo` з [додаткових налаштувань](/docs/setup/additional-setup/config-profiles/).
     {{< /tip >}}
 
-* Розгорніть демонстраційний застосунок [sleep]({{< github_tree >}}/samples/sleep) для використання як джерело тестових запитів. Якщо у вас увімкнено [автоматичне додавання sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду для розгортання демонстраційного застосунку:
+* Розгорніть демонстраційний застосунок [curl]({{< github_tree >}}/samples/curl) для використання як джерело тестових запитів. Якщо у вас увімкнено [автоматичне додавання sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду для розгортання демонстраційного застосунку:
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
-    Інакше, вручну додайте sidecar перед розгортанням застосунку `sleep` за допомогою наступної команди:
+    Інакше, вручну додайте sidecar перед розгортанням застосунку `curl` за допомогою наступної команди:
 
     {{< text bash >}}
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@)
     {{< /text >}}
 
     {{< tip >}}
@@ -27,5 +27,5 @@
 * Встановіть змінну середовища `SOURCE_POD` на імʼя вашого podʼа:
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})
     {{< /text >}}

content/uk/boilerplates/crd-upgrade-123.md

@@ -0,0 +1,19 @@
+---
+---
+{{< warning >}}
+Якщо ви оновлюєте CRD за допомогою Helm з версії Istio 1.23 або старішої, ви можете зіткнутися з такою помилкою
+
+`Error: rendered manifests contain a resource that already exists. Unable to continue with update: CustomResourceDefinition "wasmplugins.extensions.istio.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata`
+
+Ви можете розвʼязати цю проблему за допомогою одноразової міграції за допомогою наступних команд `kubectl`:
+
+{{< text syntax=bash snip_id=adopt_legacy_crds >}}
+$ for crd in $(kubectl get crds -l chart=istio -o name && kubectl get crds -l app.kubernetes.io/part-of=istio -o name)
+  do
+     kubectl label "$crd" "app.kubernetes.io/managed-by=Helm"
+     kubectl annotate "$crd" "meta.helm.sh/release-name=istio-base" # замініть на актуальну назву релізу Helm, якщо вона відрізняється від стандартної у документації.
+     kubectl annotate "$crd" "meta.helm.sh/release-namespace=istio-system" # замінити на актуальний простір імен istio
+  done
+{{< /text >}}
+
+{{< /warning >}}

content/uk/boilerplates/helm-preamble.md

@@ -1,4 +1,3 @@
 ---
 ---
-
-Helm-чарти для `base` та `istiod`, які використовуються в цьому посібнику, такі ж самі, як і ті, що використовуються при встановленні Istio через [Istioctl](/docs/setup/install/istioctl/) або [Operator](/docs/setup/install/operator/). Однак під час встановлення через Istioctl і Operator використовується інший [чарт шлюзу]({{< github_tree >}}/manifests/charts/gateways/istio-ingress), ніж [чарт]({{< github_tree >}}/manifests/charts/gateway), описаний у цьому посібнику.
+Helm-чарти для `base` та `istiod`, які використовуються в цьому посібнику, такі ж самі, як і ті, що використовуються при встановленні Istio через [Istioctl](/docs/setup/install/istioctl/). Однак під час встановлення через Istioctl використовується інший [чарт шлюзу]({{< github_tree >}}/manifests/charts/gateways/istio-ingress), ніж [чарт]({{< github_tree >}}/manifests/charts/gateway), описаний у цьому посібнику

content/uk/docs/ambient/architecture/traffic-redirection/index.md

@@ -77,7 +77,7 @@ inpod_mark: 1337
 Виконайте наведені нижче кроки, щоб підтвердити, що сокети на портах 15001, 15006 та 15008 відкриті та знаходяться у стані прослуховування.
 
 {{< text bash >}}
-$ kubectl debug $(kubectl get pod -l app=sleep -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it -n ambient-demo --image nicolaka/netshoot -- ss -ntlp
+$ kubectl debug $(kubectl get pod -l app=curl -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it -n ambient-demo --image nicolaka/netshoot -- ss -ntlp
 Defaulting debug container name to debugger-nhd4d.
 State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
 LISTEN 0      128        127.0.0.1:15080      0.0.0.0:*
@@ -91,7 +91,7 @@ LISTEN 0      128                *:15008            *:*
 Щоб переглянути налаштування правил iptables всередині одного з podʼів застосунку, виконайте цю команду:
 
 {{< text bash >}}
-$ kubectl debug $(kubectl get pod -l app=sleep -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it --image gcr.io/istio-release/base --profile=netadmin -n ambient-demo -- iptables-save
+$ kubectl debug $(kubectl get pod -l app=curl -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it --image gcr.io/istio-release/base --profile=netadmin -n ambient-demo -- iptables-save
 
 Defaulting debug container name to debugger-m44qc.
 # Generated by iptables-save

content/uk/docs/ambient/getting-started/cleanup/index.md

@@ -36,12 +36,12 @@ $ kubectl delete namespace istio-system
 
 ## Видалення демонстраційного застосунку {#remove-the-sample-application}
 
-Щоб видалити демонстраційний застосунок Bookinfo та deployment `sleep`, виконайте наступне:
+Щоб видалити демонстраційний застосунок Bookinfo та deployment `curl`, виконайте наступне:
 
 {{< text bash >}}
-$ kubectl delete -f {{< github_file >}}/samples/bookinfo/platform/kube/bookinfo.yaml
-$ kubectl delete -f {{< github_file >}}/samples/bookinfo/platform/kube/bookinfo-versions.yaml
-$ kubectl delete -f {{< github_file >}}/samples/sleep/sleep.yaml
+$ kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml
+$ kubectl delete -f samples/bookinfo/platform/kube/bookinfo-versions.yaml
+$ kubectl delete -f samples/curl/curl.yaml
 {{< /text >}}
 
 ## Видалення CRD для Kubernetes Gateway API {#remove-gateway-api-crds}

content/uk/docs/ambient/getting-started/enforce-auth-policies/index.md

@@ -36,16 +36,16 @@ EOF
 
 Якщо ви відкриєте застосунок Bookinfo в оглядачі (`http://localhost:8080/productpage`), ви побачите сторінку продукту, як і раніше. Однак, якщо ви спробуєте отримати доступ до сервісу `productpage` з іншого службового облікового запису, ви повинні побачити помилку.
 
-Спробуйте отримати доступ до застосунка Bookinfo з podʼа `sleep`:
+Спробуйте отримати доступ до застосунку Bookinfo з podʼа `curl`:
 
-{{< text syntax=bash snip_id=deploy_sleep >}}
-$ kubectl apply -f {{< github_file >}}/samples/sleep/sleep.yaml
+{{< text syntax=bash snip_id=deploy_curl >}}
+$ kubectl apply -f samples/curl/curl.yaml
 {{< /text >}}
 
-Оскільки pod `sleep` використовує інший службовий обліковий запис, він не матиме доступу до сервісу `productpage`:
+Оскільки pod `curl` використовує інший службовий обліковий запис, він не матиме доступу до сервісу `productpage`:
 
 {{< text bash >}}
-$ kubectl exec deploy/sleep -- curl -s "http://productpage:9080/productpage"
+$ kubectl exec deploy/curl -- curl -s "http://productpage:9080/productpage"
 command terminated with exit code 56
 {{< /text >}}
 
@@ -67,7 +67,7 @@ NAME       CLASS            ADDRESS       PROGRAMMED   AGE
 waypoint   istio-waypoint   10.96.58.95   True         42s
 {{< /text >}}
 
-Додавання [політики авторизації L7](/docs/ambient/usage/l7-features/) явно дозволить сервісу `sleep` надсилати `GET` запити до сервісу `productpage`, але не виконувати інші операції:
+Додавання [політики авторизації L7](/docs/ambient/usage/l7-features/) явно дозволить сервісу `curl` надсилати `GET` запити до сервісу `productpage`, але не виконувати інші операції:
 
 {{< text syntax=bash snip_id=deploy_l7_policy >}}
 $ kubectl apply -f - <<EOF
@@ -86,7 +86,7 @@ spec:
   - from:
     - source:
         principals:
-        - cluster.local/ns/default/sa/sleep
+        - cluster.local/ns/default/sa/curl
     to:
     - operation:
         methods: ["GET"]
@@ -103,7 +103,7 @@ EOF
 
 {{< text bash >}}
 $ # Це призведе до помилки RBAC, оскільки ми не використовуємо операцію GET
-$ kubectl exec deploy/sleep -- curl -s "http://productpage:9080/productpage" -X DELETE
+$ kubectl exec deploy/curl -- curl -s "http://productpage:9080/productpage" -X DELETE
 RBAC: access denied
 {{< /text >}}
 
@@ -114,9 +114,8 @@ RBAC: access denied
 {{< /text >}}
 
 {{< text bash >}}
-$ # Це працює, оскільки ми явно дозволили GET запити від podʼа sleep
-$ kubectl exec deploy/sleep -- curl -s http://productpage:9080/productpage | grep -o "<title>.*</title>"
-<title>Simple Bookstore App</title>
+$ # Це працює, оскільки ми явно дозволили GET запити від podʼа curl
+$ kubectl exec deploy/curl -- curl -s http://productpage:9080/productpage | grep -o "<title>.*</title>"
 {{< /text >}}
 
 ## Подальші кроки {#next-steps}

content/uk/docs/ambient/getting-started/manage-traffic/index.md

@@ -40,7 +40,7 @@ EOF
 Щоб підтвердити, що приблизно 10\% зі 100 запитів йдуть до `reviews-v2`, ви можете виконати наступну команду:
 
 {{< text syntax=bash snip_id=test_traffic_split >}}
-$ kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://productpage:9080/productpage | grep reviews-v.-; done"
+$ kubectl exec deploy/curl -- sh -c "for i in \$(seq 1 100); do curl -s http://productpage:9080/productpage | grep reviews-v.-; done"
 {{< /text >}}
 
 Ви помітите, що більшість запитів надходять до `reviews-v1`. Ви можете підтвердити те ж саме, відкривши застосунок Bookinfo у вашому оглядачі та кілька разів оновивши сторінку. Зверніть увагу, що запити від `reviews-v1` не мають зірок, тоді як запити від `reviews-v2` мають чорні зірки.

content/uk/docs/ambient/install/platform-prerequisites/index.md

@@ -39,6 +39,34 @@ spec:
       - system-node-critical
 {{< /text >}}
 
+### Amazon Elastic Kubernetes Service (EKS)
+
+Якщо ви використовуєте EKS:
+
+- з Amazon VPC CNI
+- з увімкненим Pod ENI trunking
+- **та** використовуєте прикріплені до подів SecurityGroups через [SecurityGroupPolicy](https://aws.github.io/aws-eks-best-practices/networking/sgpp/#enforcing-mode-use-strict-mode-for-isolating-pod-and-node-traffic)
+
+[`POD_SECURITY_GROUP_ENFORCING_MODE` має бути явно встановлено в значення `standard`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md#pod_security_group_enforcing_mode-v1110), інакше проби справності подів (які за стандартно автоматично виключені з політики VPC CNI) будуть провалені. Це повʼязано з тим, що Istio використовує локальну SNAT-адресу для проб справності kubelet, яку Amazon VPC CNI не розпізнає, а VPC CNI не має опції для виключення локальних адрес з політики.
+
+Ви можете перевірити, чи увімкнено pod ENI trunking, виконавши наступну команду:
+
+{{< text syntax=bash >}}
+$ kubectl set env daemonset aws-node -n kube-system --list | grep ENABLE_POD_ENI
+{{< /text >}}
+
+Ви можете перевірити, чи є у вашому кластері будь-які прикріплені до подів групи безпеки, виконавши таку команду:
+
+{{< text syntax=bash >}}
+$ kubectl get securitygrouppolicies.vpcresources.k8s.aws
+{{< /text >}}
+
+Ви можете встановити `POD_SECURITY_GROUP_ENFORCING_MODE=standard`, виконавши наступну команду, після чого перезапустіть відповідні поди:
+
+{{< text syntax=bash >}}
+$ kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING_MODE=standard
+{{< /text >}}
+
 ### k3d {#k3d}
 
 Коли ви використовуєте [k3d](https://k3d.io/) зі стандартним Flannel CNI, вам потрібно додати коректне значення `platform` до вашої команди встановлення, оскільки k3d використовує нестандартні розташування для конфігурацій CNI та двійкових файлів, що потребують певних перевизначень в Helm.
@@ -73,7 +101,7 @@ spec:
 
 ### K3s {#k3s}
 
-Коли ви використовуєте [K3s](https://k3s.io/) та одну з його вбудованих CNIs, ви повинні додати правильне значення `platform` до ваших команд установки, оскільки K3s використовує нестандартні розташування для конфігурацій CNI та бінарних файлів, що вимагає деяких перевизначень в Helm. Для стандартних шляхів K3s Istio надає вбудовані перевизначення на основі значення `global.platform`.
+Коли ви використовуєте [K3s](https://k3s.io/) та один з його вбудованих CNIs, ви повинні додати правильне значення `platform` до ваших команд установки, оскільки K3s використовує нестандартні розташування для конфігурацій CNI та бінарних файлів, що вимагає деяких перевизначень в Helm. Для стандартних шляхів K3s Istio надає вбудовані перевизначення на основі значення `global.platform`.
 
 {{< tabset category-name="install-method" >}}
 
@@ -202,7 +230,7 @@ OpenShift вимагає, щоб компоненти `ztunnel` та `istio-cni`
 
 1. Cilium наразі стандартно проактивно видаляє інші втулки CNI та їх конфігурацію, і його потрібно налаштувати з `cni.exclusive = false`, щоб правильно підтримувати ланцюжки. Див. [документацію Cilium](https://docs.cilium.io/en/stable/helm-reference/) для більш детальної інформації.
 2. BPF маскування в Cilium наразі стандартно вимкнено і має проблеми з використанням локальних IP-адрес Istio для перевірки справності Kubernetes. Увімкнення BPF маскування через `bpf.masquerade=true` наразі не підтримується і призводить до того, що в Istio ambient зʼявляються нефункціональні перевірки стану справності podʼів. Стандартна реалізація маскування iptables Cilium повинна продовжувати функціонувати правильно.
-3. Через те, як Cilium керує ідентифікацією вузлів та внутрішніми списками дозволів на рівні вузлів, проби справності можуть бути передані до podʼів, застосування default-DENY `NetworkPolicy` в установці Cilium CNI, що лежить в основі Istio в режимі оточення, призведе до блокування проб справності `kubelet` (які стандартно не підпадають під дію NetworkPolicy в Cilium)..
+3. Завдяки тому, як Cilium керує ідентифікацією вузлів та внутрішніми списками дозволів на рівні вузлів, проби справності можуть бути передані до подів, застосування будь-якої політики default-DENY `NetworkPolicy` в установці Cilium CNI, що лежить в основі Istio, у зовнішньому режимі призведе до блокування проб справності `kubelet` (які стандартно мовчки вилучаються з усіх політик, що застосовуються Cilium). Це повʼязано з тим, що Istio використовує локальну SNAT-адресу для перевірок справності kubelet, про яку Cilium не знає, а Cilium не має можливості вилучити локальні адреси з-під дії політик.
 
     Це можна вирішити, застосувавши наступну `CiliumClusterWideNetworkPolicy`:
 
@@ -212,7 +240,10 @@ OpenShift вимагає, щоб компоненти `ztunnel` та `istio-cni`
     metadata:
       name: "allow-ambient-hostprobes"
     spec:
-      description: "Дозволяє SNAT перевірки справності kubelet в ambient podʼах"
+      description: "Allows SNAT-ed kubelet health check probes into ambient pods"
+      enableDefaultDeny:
+        egress: false
+        ingress: false
       endpointSelector: {}
       ingress:
       - fromCIDR:

content/uk/docs/ambient/upgrade/helm/index.md

@@ -14,23 +14,19 @@ test: yes
 Скористайтесь цим посібником для оновлення та налаштування установки в режимі ambient, використовуючи [Helm](https://helm.sh/docs/). Цей посібник передбачає, що ви вже виконали [установку в режимі ambient за допомогою Helm](/docs/ambient/install/helm/) з попередньою версією Istio.
 
 {{< warning >}}
-На відміну від режиму sidecar, режим ambient підтримує переміщення podʼів застосунку на оновлений проксі ztunnel без обовʼязкового перезапуску або переспрямування працюючих podʼів застосунку. Однак, оновлення ztunnel **призведе** до скидання всіх довготривалих TCP-зʼєднань на оновленому вузлі, і Istio наразі не підтримує канаркове оновлення ztunnel.
+На відміну від режиму sidecar, режим ambient підтримує переміщення podʼів застосунку на оновлений проксі ztunnel без обовʼязкового перезапуску або переспрямування працюючих podʼів застосунку. Однак, оновлення ztunnel **призведе** до скидання всіх довготривалих TCP-зʼєднань на оновленому вузлі, і Istio наразі не підтримує канаркове оновлення ztunnel, **навіть з використанням ревізій**.
 
 Рекомендується використовувати ізоляцію вузлів та сині/зелені пули вузлів, щоб обмежити обсяг збою трафіку під час оновлень встановлень в операційному оточенні. Детальніше дивіться у документації вашого провайдера Kubernetes.
 {{< /warning >}}
 
 ## Розуміння оновлень у режимі ambient {#understanding-ambient-mode-upgrades}
 
-Усі оновлення Istio передбачають оновлення панелі управління, панелі даних та CRD Istio. Оскільки панель даних у режимі ambient розділена між [двома компонентами](/docs/ambient/architecture/data-plane), ztunnel та waypoint, оновлення включають окремі кроки для цих компонентів. Оновлення панелі управління та CRD розглянуті тут коротко, але по суті є аналогічними [процесу оновлення цих компонентів у режимі sidecar](/docs/setup/upgrade/canary/).
+Усі оновлення Istio передбачають оновлення панелі управління, панелі даних та CRD Istio. Оскільки панель даних у режимі ambient розділена між [двома компонентами](/docs/ambient/architecture/data-plane), ztunnel та шлюзів (які включають waypoint), оновлення включають окремі кроки для цих компонентів. Оновлення панелі управління та CRD розглянуті тут коротко, але по суті є аналогічними [процесу оновлення цих компонентів у режимі sidecar](/docs/setup/upgrade/canary/).
 
-Як і в режимі sidecar, шлюзи можуть використовувати [теґи ревізій](/docs/setup/upgrade/canary/#stable-revision-labels) для тонкого контролю за оновленнями ({{< gloss gateway>}}шлюзів{{</ gloss >}}), включаючи waypoint, з простими контролерами для відкочування у будь-який момент. Однак, на відміну від режиму sidecar, ztunnel працює як DaemonSet, проксі на кожному вузлі, — це означає, що оновлення ztunnel мінімум вплине на весь вузол одночасно. Хоча це може бути прийнятним у багатьох випадках, застосунки з довготривалими TCP-зʼєднаннями можуть бути порушені. У таких випадках ми рекомендуємо використовувати ізоляцію вузлів і очищення перед оновленням ztunnel для конкретного вузла. Заради простоти цей документ продемонструє оновлення ztunnel на місці, що може спричинити короткочасний простій.
+Як і в режимі sidecar, шлюзи можуть використовувати [теґи ревізій](/docs/setup/upgrade/canary/#stable-revision-labels) для тонкого контролю за оновленнями ({{< gloss gateway>}}шлюзів{{</ gloss >}}), включаючи waypoint, з простими контролерами для відкочування до попередньої версії панелі правління Istio в будь-який момент. Однак, на відміну від режиму sidecar, ztunnel працює як DaemonSet, проксі на кожному вузлі, — це означає, що оновлення ztunnel мінімум вплине на весь вузол одночасно. Хоча це може бути прийнятним у багатьох випадках, застосунки з довготривалими TCP-зʼєднаннями можуть бути порушені. У таких випадках ми рекомендуємо використовувати ізоляцію вузлів і очищення перед оновленням ztunnel для конкретного вузла. Заради простоти цей документ продемонструє оновлення ztunnel на місці, що може спричинити короткочасний простій.
 
 ## Попередні вимоги {#prerequisites}
 
-### Організуйте свої теґи та ревізії {#organize-your-tags-and-revisions}
-
-Для безпечного оновлення mesh у режимі ambient ваші шлюзи та простори імен повинні використовувати мітку `istio.io/rev` для вказання теґу ревізії, який контролює версію проксі, що виконується. Ми рекомендуємо розділити ваш операційний кластер на кілька теґів для організації вашого оновлення. Усі учасники одного теґу будуть оновлюватись одночасно, тому розумно розпочинати оновлення з найбільш низькоризикових застосунків. Ми не рекомендуємо використовувати ревізії безпосередньо через мітки для оновлень, оскільки цей процес може легко призвести до випадкового оновлення великої кількості проксі і його складно сегментувати. Щоб побачити, які теґи та ревізії ви використовуєте у вашому кластері, дивіться розділ про оновлення теґів.
-
 ### Підготовка до оновлення {#prepare-for-the-upgrade}
 
 Перед оновленням Istio ми рекомендуємо завантажити нову версію istioctl та запустити `istioctl x precheck`, щоб переконатися, що оновлення сумісне з вашим середовищем. Результат має виглядати приблизно так:
@@ -47,6 +43,20 @@ $ istioctl x precheck
 $ helm repo update istio
 {{< /text >}}
 
+{{< tabset category-name="upgrade-prerequisites" >}}
+
+{{< tab name="Оновлення на місці" category-value="in-place" >}}
+
+Без додаткової підготовки до оновлення на місці, переходьте до наступного кроку.
+
+{{< /tab >}}
+
+{{< tab name="Оновлення з ревізією" category-value="revisions" >}}
+
+### Організуйте свої теґи та ревізії {#organize-your-tags-and-revisions}
+
+Для безпечного оновлення mesh у режимі ambient ваші шлюзи та простори імен повинні використовувати мітку `istio.io/rev` для вказання теґу ревізії, який контролює версію проксі, що виконується. Ми рекомендуємо розділити ваш операційний кластер на кілька теґів для організації вашого оновлення. Усі учасники одного теґу будуть оновлюватись одночасно, тому розумно розпочинати оновлення з найбільш низькоризикових застосунків. Ми не рекомендуємо використовувати ревізії безпосередньо через мітки для оновлень, оскільки цей процес може легко призвести до випадкового оновлення великої кількості проксі і його складно сегментувати. Щоб побачити, які теґи та ревізії ви використовуєте у вашому кластері, дивіться розділ про оновлення теґів.
+
 ### Виберіть ім'я ревізії {#choose-a-revision-name}
 
 Ревізії визначають унікальні екземпляри панелі управління Istio, дозволяючи запускати кілька окремих версій панелі управління одночасно в одному mesh.
@@ -62,26 +72,48 @@ $ export REVISION=istio-1-22-1
 $ export OLD_REVISION=istio-1-21-2
 {{< /text >}}
 
+{{< /tab >}}
+
+{{< /tabset >}}
+
 ## Оновлення панелі управління {#upgrade-the-control-plane}
 
 ### Основні компоненти {#base-components}
 
+{{< boilerplate crd-upgrade-123 >}}
+
 Перш ніж розгортати нову версію панелі управління, необхідно оновити CRD, що охоплюють весь кластер:
 
-{{< text bash >}}
-$ kubectl apply -f manifests/charts/base/crds
+{{< text syntax=bash snip_id=upgrade_crds >}}
+$ helm upgrade istio-base istio/base -n istio-system
 {{< /text >}}
 
 ### Панель управління istiod {#istiod-control-plane}
 
-Панель управління [Istiod](/docs/ops/deployment/architecture/#istiod) керує і налаштовує проксі, які маршрутизують трафік в межах mesh. Наступна команда встановить новий екземпляр панелі управління поряд з поточним, але не додасть нових проксі та не візьме на себе керування наявними проксі.
+Панель управління [Istiod](/docs/ops/deployment/architecture/#istiod) керує і налаштовує проксі, які маршрутизують трафік в межах mesh. Наступна команда встановить новий екземпляр панелі управління поряд з поточним, але не додасть нових шлюзів проксі або waypoints та не візьме на себе керування наявними проксі.
 
 Якщо ви налаштували встановлення istiod, ви можете повторно використовувати файл `values.yaml` з попередніх оновлень або встановлень, щоб зберегти панелі управління узгодженими.
 
-{{< text syntax=bash snip_id=upgrade_istiod >}}
+{{< tabset category-name="upgrade-control-plane" >}}
+
+{{< tab name="Оновлення на місці" category-value="in-place" >}}
+
+{{< text syntax=bash snip_id=upgrade_istiod_inplace >}}
+$ helm upgrade istiod istio/istiod -n istio-system --wait
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="Оновлення з ревізією" category-value="revisions" >}}
+
+{{< text syntax=bash snip_id=upgrade_istiod_revisioned >}}
 $ helm install istiod-"$REVISION" istio/istiod -n istio-system --set revision="$REVISION" --set profile=ambient --wait
 {{< /text >}}
 
+{{< /tab >}}
+
+{{< /tabset >}}
+
 ### CNI node agent {#cni-node-agent}
 
 Агент вузла Istio CNI відповідає за виявлення podʼів, доданих до ambient mesh, інформування ztunnel про необхідність встановлення проксі-портів у доданих podʼах і налаштування перенаправлення трафіку в межах мережевого простору імен podʼа. Він не є частиною панелі даних або панелі управління.
@@ -89,7 +121,9 @@ $ helm install istiod-"$REVISION" istio/istiod -n istio-system --set revision="$
 CNI версії 1.x сумісний із панеллю управління версії 1.x+1 і 1.x. Це означає, що спочатку потрібно оновити панелі управління перед оновленням Istio CNI, якщо різниця між їхніми версіями не перевищує одну мінорну версію.
 
 {{< warning >}}
-Оновлення агента вузла Istio CNI до сумісної версії на місці не порушить роботу мережі для вже успішно доданих до ambient mesh podʼів, але жоден з podʼів, захоплених сервісною мережею, не буде успішно запланований (або перепланований) на вузлі, доки оновлення не завершиться, а оновлений агент Istio CNI на вузлі не пройде перевірку готовності. Якщо це може спричинити значні перебої, або якщо потрібен суворіший контроль над зоною впливу під час оновлення CNI, рекомендується застосувати taints вузла та/або cordons вузла.
+Istio зараз не підтримує канаркове оновлення istio-cni, **навіть з використанням ревізій**
+
+Оновлення агента вузла Istio CNI до сумісної версії на місці не призведе до порушення роботи мережі для вже успішно доданих до ambient мережі podʼів, але не слід планувати додавання нових podʼів на вузол, поки оновлення не буде завершено та оновлений агент Istio CNI на вузлі не пройде перевірку готовності. Якщо це може спричинити значні перебої, або якщо потрібен суворіший контроль над зоною впливу під час оновлення CNI, рекомендується застосувати taints вузла та/або cordons вузла.
 {{< /warning >}}
 
 {{< text syntax=bash snip_id=upgrade_cni >}}
@@ -103,15 +137,47 @@ $ helm upgrade istio-cni istio/cni -n istio-system
 {{< gloss >}}Ztunnel{{< /gloss >}} DaemonSet є проксі-компонентом вузла. Ztunnel версії 1.x сумісний з панеллю управління версії 1.x+1 і 1.x. Це означає, що спочатку потрібно оновити панель управління перед оновленням ztunnel, якщо різниця між їхніми версіями не перевищує одну мінорну версію. Якщо ви раніше налаштовували встановлення ztunnel, ви можете повторно використати файл `values.yaml` з попередніх оновлень або встановлень, щоб зберегти ваші {{< gloss "панель даних" >}}панелі даних{{< /gloss >}} послідовним.
 
 {{< warning >}}
-Оновлення ztunnel на місці короткочасно порушить весь трафік ambient mesh на вузлі, незалежно від використання версій. На практиці період порушення дуже короткий і в основному впливає на довготривалі зʼєднання.
+Оновлення ztunnel на місці короткочасно порушить весь трафік ambient mesh на вузлі, **навіть з від використанням ревізій**. На практиці період порушення дуже короткий і в основному впливає на довготривалі зʼєднання.
 
 Для зниження ризику зони впливу під час оновлень в операційних середовищах рекомендується використання cordoning вузлів і блакитно-зелених пулів вузлів. Дивіться документацію вашого постачальника Kubernetes для деталей.
 {{< /warning >}}
 
-{{< text syntax=bash snip_id=upgrade_ztunnel >}}
+{{< tabset category-name="upgrade-ztunnel" >}}
+
+{{< tab name="Оновлення на місці" category-value="in-place" >}}
+
+{{< text syntax=bash snip_id=upgrade_ztunnel_inplace >}}
+$ helm upgrade ztunnel istio/ztunnel -n istio-system --wait
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="Оновлення з ревізією" category-value="revisions" >}}
+
+{{< text syntax=bash snip_id=upgrade_ztunnel_revisioned >}}
 $ helm upgrade ztunnel istio/ztunnel -n istio-system --set revision="$REVISION" --wait
 {{< /text >}}
 
+{{< /tab >}}
+
+{{< /tabset >}}
+
+{{< tabset category-name="change-gateway-revision" >}}
+
+{{< tab name="Оновлення на місці" category-value="in-place" >}}
+
+### Оновлення чарту розгорнутого вручну шлюзу (необовʼязково) {#upgrade-manually-deployed-gateways-optional}
+
+`Gateway`, які були [розгорнуті вручну](/docs/tasks/traffic-management/ingress/gateway-api/#manual-deployment), потрібно оновити індивідуально за допомогою Helm:
+
+{{< text syntax=bash snip_id=none >}}
+$ helm upgrade istio-ingress istio/gateway -n istio-ingress
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="Оновлення з ревізією" category-value="revisions" >}}
+
 ### Оновлення waypoints та шлюзів за допомогою теґів {#upgrade-waypoints-and-gateways-using-tags}
 
 Якщо ви дотримувалися найкращих практик, усі ваші шлюзи, робочі навантаження та простори імен використовують або стандартну версію (фактично теґ з назвою `default`), або мітку `istio.io/rev` зі значенням, встановленим у назву теґу. Тепер ви можете оновити все це до нової версії панелі даних Istio, перемістивши їх теґи, щоб вони вказували на нову версію, по черзі. Щоб переглянути всі теґи у вашому кластері, виконайте:
@@ -134,7 +200,7 @@ $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisi
 $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{$MYTAG}" --set revision="$OLD_REVISION" -n istio-system | kubectl apply -f -
 {{< /text >}}
 
-### Оновлення вручну розгорнутих шлюзів (необов'язково) {#upgrade-manually-deployed-gateways-optional}
+### Оновлення вручну розгорнутих шлюзів (необовʼязково) {#upgrade-manually-deployed-gateways-optional}
 
 `Gateway`, які були [розгорнуті вручну](/docs/tasks/traffic-management/ingress/gateway-api/#manual-deployment), потрібно оновити індивідуально за допомогою Helm:
 
@@ -144,8 +210,12 @@ $ helm upgrade istio-ingress istio/gateway -n istio-ingress
 
 ## Видалення попередньої панелі управління {#uninstall-the-previous-control-plane}
 
-Якщо ви оновили всі компоненти панелі даних до нової версії Istio і задоволені тим, що вам не потрібно виконувати відкат, ви можете видалити попередню версію панелі управління, виконавши:
+Якщо ви оновили всі компоненти панелі даних до нової ревізії панелі управління Istio і задоволені тим, що вам не потрібно виконувати відкат, ви можете видалити попередню ревізію панелі управління, виконавши:
 
 {{< text syntax=bash snip_id=none >}}
 $ helm delete istiod-"$REVISION" -n istio-system
 {{< /text >}}
+
+{{< /tab >}}
+
+{{< /tabset >}}

content/uk/docs/ambient/usage/extend-waypoint-wasm/index.md

@@ -17,10 +17,10 @@ Istio надає можливість [розширити свої функці
 1. Налаштуйте Istio, дотримуючись інструкцій у [посібнику з початку роботи в режимі ambient](/docs/ambient/getting-started).
 2. Розгорніть [демонстраційний застосунок Bookinfo](/docs/ambient/getting-started/deploy-sample-app).
 3. [Додайте простір імен default до ambient mesh](/docs/ambient/getting-started/secure-and-visualize).
-4. Розгорніть демонстраційний застосунок [sleep]({{< github_tree >}}/samples/sleep), щоб використовувати його як джерело для надсилання тестових запитів.
+4. Розгорніть демонстраційний застосунок [curl]({{< github_tree >}}/samples/curl), щоб використовувати його як джерело для надсилання тестових запитів.
 
     {{< text syntax=bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
 ## На шлюзі {#at-a-gateway}
@@ -71,14 +71,14 @@ EOF
 1. Перевірте `/productpage` без облікових даних:
 
     {{< text syntax=bash snip_id=test_gateway_productpage_without_credentials >}}
-    $ kubectl exec deploy/sleep -- curl -s -w "%{http_code}" -o /dev/null "http://bookinfo-gateway-istio.default.svc.cluster.local/productpage"
+    $ kubectl exec deploy/curl -- curl -s -w "%{http_code}" -o /dev/null "http://bookinfo-gateway-istio.default.svc.cluster.local/productpage"
     401
     {{< /text >}}
 
 2. Перевірте `/productpage` з обліковими даними, налаштованими у ресурсі WasmPlugin:
 
     {{< text syntax=bash snip_id=test_gateway_productpage_with_credentials >}}
-    $ kubectl exec deploy/sleep -- curl -s -o /dev/null -H "Authorization: Basic YWRtaW4zOmFkbWluMw==" -w "%{http_code}" "http://bookinfo-gateway-istio.default.svc.cluster.local/productpage"
+    $ kubectl exec deploy/curl -- curl -s -o /dev/null -H "Authorization: Basic YWRtaW4zOmFkbWluMw==" -w "%{http_code}" "http://bookinfo-gateway-istio.default.svc.cluster.local/productpage"
     200
     {{< /text >}}
 
@@ -97,7 +97,7 @@ $ istioctl waypoint apply --enroll-namespace --wait
 Переконайтеся, що трафік досягає сервісу:
 
 {{< text syntax=bash snip_id=verify_traffic >}}
-$ kubectl exec deploy/sleep -- curl -s -w "%{http_code}" -o /dev/null http://productpage:9080/productpage
+$ kubectl exec deploy/curl -- curl -s -w "%{http_code}" -o /dev/null http://productpage:9080/productpage
 200
 {{< /text >}}
 
@@ -151,14 +151,14 @@ basic-auth-at-waypoint   14m
 1. Перевірте внутрішню точку доступу `/productpage` без облікових даних:
 
     {{< text syntax=bash snip_id=test_waypoint_productpage_without_credentials >}}
-    $ kubectl exec deploy/sleep -- curl -s -w "%{http_code}" -o /dev/null http://productpage:9080/productpage
+    $ kubectl exec deploy/curl -- curl -s -w "%{http_code}" -o /dev/null http://productpage:9080/productpage
     401
     {{< /text >}}
 
 2. Перевірте внутрішню точку доступу `/productpage` з обліковими даними:
 
     {{< text syntax=bash snip_id=test_waypoint_productpage_with_credentials >}}
-    $ kubectl exec deploy/sleep -- curl -s -w "%{http_code}" -o /dev/null -H "Authorization: Basic YWRtaW4zOmFkbWluMw==" http://productpage:9080/productpage
+    $ kubectl exec deploy/curl -- curl -s -w "%{http_code}" -o /dev/null -H "Authorization: Basic YWRtaW4zOmFkbWluMw==" http://productpage:9080/productpage
     200
     {{< /text >}}
 
@@ -198,21 +198,21 @@ EOF
 1. Перевірте внутрішню точку доступу `/productpage` з обліковими даними, налаштованими на загальному проксі `waypoint`:
 
     {{< text syntax=bash snip_id=test_waypoint_service_productpage_with_credentials >}}
-    $ kubectl exec deploy/sleep -- curl -s -w "%{http_code}" -o /dev/null -H "Authorization: Basic YWRtaW4zOmFkbWluMw==" http://productpage:9080/productpage
+    $ kubectl exec deploy/curl -- curl -s -w "%{http_code}" -o /dev/null -H "Authorization: Basic YWRtaW4zOmFkbWluMw==" http://productpage:9080/productpage
     200
     {{< /text >}}
 
 2. Перевірте внутрішню точку доступу `/reviews` з обліковими даними, налаштованими на конкретному проксі `reviews-svc-waypoint`:
 
     {{< text syntax=bash snip_id=test_waypoint_service_reviews_with_credentials >}}
-    $ kubectl exec deploy/sleep -- curl -s -w "%{http_code}" -o /dev/null -H "Authorization: Basic MXQtaW4zOmFkbWluMw==" http://reviews:9080/reviews/1
+    $ kubectl exec deploy/curl -- curl -s -w "%{http_code}" -o /dev/null -H "Authorization: Basic MXQtaW4zOmFkbWluMw==" http://reviews:9080/reviews/1
     200
     {{< /text >}}
 
 3. Перевірте внутрішню точку доступу `/reviews` без облікових даних:
 
     {{< text syntax=bash snip_id=test_waypoint_service_reviews_without_credentials >}}
-    $ kubectl exec deploy/sleep -- curl -s -w "%{http_code}" -o /dev/null http://reviews:9080/reviews/1
+    $ kubectl exec deploy/curl -- curl -s -w "%{http_code}" -o /dev/null http://reviews:9080/reviews/1
     401
     {{< /text >}}
 

content/uk/docs/ambient/usage/l4-policy/index.md

@@ -20,7 +20,7 @@ test: no
 apiVersion: security.istio.io/v1
 kind: AuthorizationPolicy
 metadata:
- name: allow-sleep-to-httpbin
+ name: allow-curl-to-httpbin
 spec:
  selector:
    matchLabels:
@@ -30,12 +30,12 @@ spec:
  - from:
    - source:
        principals:
-       - cluster.local/ns/ambient-demo/sa/sleep
+       - cluster.local/ns/ambient-demo/sa/curl
 {{< /text >}}
 
 Ця політика може використовуватися як в {{< gloss "sidecar" >}}sidecar режимі{{< /gloss >}}, так і в ambient режимі.
 
-Особливості L4 (TCP) в API `AuthorizationPolicy` Istio мають таку саму функціональну поведінку в ambient режимі, як і в sidecar режимі. Коли політика авторизації не надана, стандартна дія — `ALLOW`. Після того, як політику створено, podʼи, на які вона поширюється, пропускають лише той трафік, який явно дозволено. У наведеному вище прикладі podʼи з міткою `app: httpbin` дозволяють трафік тільки з джерел з ідентичністю принципал `cluster.local/ns/ambient-demo/sa/sleep`. Трафік з усіх інших джерел буде заборонено.
+Особливості L4 (TCP) в API `AuthorizationPolicy` Istio мають таку саму функціональну поведінку в ambient режимі, як і в sidecar режимі. Коли політика авторизації не надана, стандартна дія — `ALLOW`. Після того, як політику створено, podʼи, на які вона поширюється, пропускають лише той трафік, який явно дозволено. У наведеному вище прикладі podʼи з міткою `app: httpbin` дозволяють трафік тільки з джерел з ідентичністю принципал `cluster.local/ns/ambient-demo/sa/curl`. Трафік з усіх інших джерел буде заборонено.
 
 ## Цільова політика {#targeting-policies}
 
@@ -71,7 +71,7 @@ ztunnel не може застосовувати політики L7. Якщо
 apiVersion: security.istio.io/v1
 kind: AuthorizationPolicy
 metadata:
- name: allow-sleep-to-httpbin
+ name: allow-curl-to-httpbin
 spec:
  selector:
    matchLabels:
@@ -81,7 +81,7 @@ spec:
  - from:
    - source:
        principals:
-       - cluster.local/ns/ambient-demo/sa/sleep
+       - cluster.local/ns/ambient-demo/sa/curl
    to:
    - operation:
        methods: ["GET"]

content/uk/docs/ambient/usage/troubleshoot-waypoint/index.md

@@ -10,17 +10,17 @@ test: no
 
 ## Проблеми з маршрутизацією трафіку або політикою безпеки {#problems-with-traffic-routing-or-security-policy}
 
-Щоб надіслати деякі запити до сервісу `reviews` через сервіс `productpage` з podʼа `sleep`:
+Щоб надіслати деякі запити до сервісу `reviews` через сервіс `productpage` з podʼа `curl`:
 
 {{< text bash >}}
-$ kubectl exec deploy/sleep -- curl -s http://productpage:9080/productpage
+$ kubectl exec deploy/curl -- curl -s http://productpage:9080/productpage
 {{< /text >}}
 
-Щоб надіслати деякі запити до podʼа `reviews` `v2` з podʼа `sleep`:
+Щоб надіслати деякі запити до podʼа `reviews` `v2` з podʼа `curl`:
 
 {{< text bash >}}
 $ export REVIEWS_V2_POD_IP=$(kubectl get pod -l version=v2,app=reviews -o jsonpath='{.items[0].status.podIP}')
-$ kubectl exec deploy/sleep -- curl -s http://$REVIEWS_V2_POD_IP:9080/reviews/1
+$ kubectl exec deploy/curl -- curl -s http://$REVIEWS_V2_POD_IP:9080/reviews/1
 {{< /text >}}
 
 Запити до сервісу `reviews` повинні бути оброблені через `reviews-svc-waypoint` для будь-яких політик L7. Запити до podʼа `reviews` `v2` повинні бути оброблені через `reviews-v2-pod-waypoint` для будь-яких політик L7.
@@ -45,7 +45,6 @@ $ kubectl exec deploy/sleep -- curl -s http://$REVIEWS_V2_POD_IP:9080/reviews/1
     default      bookinfo-gateway-istio  10.43.164.194 waypoint
     default      details                 10.43.160.119 waypoint
     default      kubernetes              10.43.0.1     waypoint
-    default      notsleep                10.43.156.147 waypoint
     default      productpage             10.43.172.254 waypoint
     default      ratings                 10.43.71.236  waypoint
     default      reviews                 10.43.162.105 reviews-svc-waypoint
@@ -59,7 +58,6 @@ $ kubectl exec deploy/sleep -- curl -s http://$REVIEWS_V2_POD_IP:9080/reviews/1
     NAMESPACE    POD NAME                                    IP         NODE                     WAYPOINT                PROTOCOL
     default      bookinfo-gateway-istio-7c57fc4647-wjqvm     10.42.2.8  k3d-k3s-default-server-0 None                    TCP
     default      details-v1-698d88b-wwsnv                    10.42.2.4  k3d-k3s-default-server-0 None                    HBONE
-    default      notsleep-685df55c6c-nwhs6                   10.42.0.9  k3d-k3s-default-agent-0  None                    HBONE
     default      productpage-v1-675fc69cf-fp65z              10.42.2.6  k3d-k3s-default-server-0 None                    HBONE
     default      ratings-v1-6484c4d9bb-crjtt                 10.42.0.4  k3d-k3s-default-agent-0  None                    HBONE
     default      reviews-svc-waypoint-c49f9f569-b492t        10.42.2.10 k3d-k3s-default-server-0 None                    TCP

content/uk/docs/ambient/usage/troubleshoot-ztunnel/index.md

@@ -21,13 +21,12 @@ $ istioctl ztunnel-config workloads
 NAMESPACE          POD NAME                                IP          NODE                  WAYPOINT PROTOCOL
 default            bookinfo-gateway-istio-59dd7c96db-q9k6v 10.244.1.11 ambient-worker        None     TCP
 default            details-v1-cf74bb974-5sqkp              10.244.1.5  ambient-worker        None     HBONE
-default            notsleep-5c785bc478-zpg7j               10.244.2.7  ambient-worker2       None     HBONE
 default            productpage-v1-87d54dd59-fn6vw          10.244.1.10 ambient-worker        None     HBONE
 default            ratings-v1-7c4bbf97db-zvkdw             10.244.1.6  ambient-worker        None     HBONE
 default            reviews-v1-5fd6d4f8f8-knbht             10.244.1.16 ambient-worker        None     HBONE
 default            reviews-v2-6f9b55c5db-c94m2             10.244.1.17 ambient-worker        None     HBONE
 default            reviews-v3-7d99fd7978-7rgtd             10.244.1.18 ambient-worker        None     HBONE
-default            sleep-7656cf8794-r7zb9                  10.244.1.12 ambient-worker        None     HBONE
+default            curl-7656cf8794-r7zb9                   10.244.1.12 ambient-worker        None     HBONE
 istio-system       istiod-7ff4959459-qcpvp                 10.244.2.5  ambient-worker2       None     TCP
 istio-system       ztunnel-6hvcw                           10.244.1.4  ambient-worker        None     TCP
 istio-system       ztunnel-mf476                           10.244.2.6  ambient-worker2       None     TCP
@@ -51,8 +50,8 @@ spiffe://cluster.local/ns/default/sa/bookinfo-ratings         Leaf     Available
 spiffe://cluster.local/ns/default/sa/bookinfo-ratings         Root     Available     true           bad086c516cce777645363cb8d731277     2034-04-24T03:31:05Z     2024-04-26T03:31:05Z
 spiffe://cluster.local/ns/default/sa/bookinfo-reviews         Leaf     Available     true           285697fb2cf806852d3293298e300c86     2024-05-05T09:17:47Z     2024-05-04T09:15:47Z
 spiffe://cluster.local/ns/default/sa/bookinfo-reviews         Root     Available     true           bad086c516cce777645363cb8d731277     2034-04-24T03:31:05Z     2024-04-26T03:31:05Z
-spiffe://cluster.local/ns/default/sa/sleep                    Leaf     Available     true           fa33bbb783553a1704866842586e4c0b     2024-05-05T09:25:49Z     2024-05-04T09:23:49Z
-spiffe://cluster.local/ns/default/sa/sleep                    Root     Available     true           bad086c516cce777645363cb8d731277     2034-04-24T03:31:05Z     2024-04-26T03:31:05Z
+spiffe://cluster.local/ns/default/sa/curl                    Leaf     Available     true           fa33bbb783553a1704866842586e4c0b     2024-05-05T09:25:49Z     2024-05-04T09:23:49Z
+spiffe://cluster.local/ns/default/sa/curl                    Root     Available     true           bad086c516cce777645363cb8d731277     2034-04-24T03:31:05Z     2024-04-26T03:31:05Z
 {{< /text >}}
 
 Використовуючи ці команди, ви можете перевірити, що проксі-сервери ztunnel налаштовані з усіма очікуваними робочими навантаженнями та TLS сертифікатом. Крім того, відсутню інформацію можна використовувати для усунення будь-яких помилок мережі.
@@ -83,7 +82,7 @@ $ kubectl debug -it $ISTIOD -n istio-system --image=curlimages/curl -- curl loca
 Логи трафіку ztunnel можна переглядати за допомогою стандартних засобів роботи з логами в Kubernetes.
 
 {{< text bash >}}
-$ kubectl -n default exec deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl -s -I http://productpage:9080/; done'
+$ kubectl -n default exec deploy/curl -- sh -c 'for i in $(seq 1 10); do curl -s -I http://productpage:9080/; done'
 HTTP/1.1 200 OK
 Server: Werkzeug/3.0.1 Python/3.12.1
 --snip--
@@ -93,8 +92,8 @@ Server: Werkzeug/3.0.1 Python/3.12.1
 
 {{< text bash >}}
 $ kubectl -n istio-system logs -l app=ztunnel | grep -E "inbound|outbound"
-2024-05-04T09:59:05.028709Z info    access  connection complete src.addr=10.244.1.12:60059 src.workload="sleep-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/sleep" dst.addr=10.244.1.10:9080 dst.hbone_addr="10.244.1.10:9080" dst.service="productpage.default.svc.cluster.local" dst.workload="productpage-v1-87d54dd59-fn6vw" dst.namespace="productpage" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" direction="inbound" bytes_sent=175 bytes_recv=80 duration="1ms"
-2024-05-04T09:59:05.028771Z info    access  connection complete src.addr=10.244.1.12:58508 src.workload="sleep-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/sleep" dst.addr=10.244.1.10:15008 dst.hbone_addr="10.244.1.10:9080" dst.service="productpage.default.svc.cluster.local" dst.workload="productpage-v1-87d54dd59-fn6vw" dst.namespace="productpage" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" direction="outbound" bytes_sent=80 bytes_recv=175 duration="1ms"
+2024-05-04T09:59:05.028709Z info    access  connection complete src.addr=10.244.1.12:60059 src.workload="curl-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.244.1.10:9080 dst.hbone_addr="10.244.1.10:9080" dst.service="productpage.default.svc.cluster.local" dst.workload="productpage-v1-87d54dd59-fn6vw" dst.namespace="productpage" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" direction="inbound" bytes_sent=175 bytes_recv=80 duration="1ms"
+2024-05-04T09:59:05.028771Z info    access  connection complete src.addr=10.244.1.12:58508 src.workload="curl-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.244.1.10:15008 dst.hbone_addr="10.244.1.10:9080" dst.service="productpage.default.svc.cluster.local" dst.workload="productpage-v1-87d54dd59-fn6vw" dst.namespace="productpage" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-productpage" direction="outbound" bytes_sent=80 bytes_recv=175 duration="1ms"
 --snip--
 {{< /text >}}
 
@@ -115,16 +114,16 @@ $ kubectl -n istio-system logs -l app=ztunnel | grep -E "inbound|outbound"
 Викликаючи сервіс з декількома бекендами, ми можемо перевірити, що трафік клієнтів збалансований між репліками сервісу.
 
 {{< text bash >}}
-$ kubectl -n default exec deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl -s -I http://reviews:9080/; done'
+$ kubectl -n default exec deploy/curl -- sh -c 'for i in $(seq 1 10); do curl -s -I http://reviews:9080/; done'
 {{< /text >}}
 
 {{< text bash >}}
 $ kubectl -n istio-system logs -l app=ztunnel | grep -E "outbound"
 --snip--
-2024-05-04T10:11:04.964851Z info    access  connection complete src.addr=10.244.1.12:35520 src.workload="sleep-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/sleep" dst.addr=10.244.1.9:15008 dst.hbone_addr="10.244.1.9:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v3-7d99fd7978-zznnq" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
-2024-05-04T10:11:04.969578Z info    access  connection complete src.addr=10.244.1.12:35526 src.workload="sleep-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/sleep" dst.addr=10.244.1.9:15008 dst.hbone_addr="10.244.1.9:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v3-7d99fd7978-zznnq" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
-2024-05-04T10:11:04.974720Z info    access  connection complete src.addr=10.244.1.12:35536 src.workload="sleep-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/sleep" dst.addr=10.244.1.7:15008 dst.hbone_addr="10.244.1.7:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v1-5fd6d4f8f8-26j92" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
-2024-05-04T10:11:04.979462Z info    access  connection complete src.addr=10.244.1.12:35552 src.workload="sleep-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/sleep" dst.addr=10.244.1.8:15008 dst.hbone_addr="10.244.1.8:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v2-6f9b55c5db-c2dtw" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
+2024-05-04T10:11:04.964851Z info    access  connection complete src.addr=10.244.1.12:35520 src.workload="curl-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.244.1.9:15008 dst.hbone_addr="10.244.1.9:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v3-7d99fd7978-zznnq" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
+2024-05-04T10:11:04.969578Z info    access  connection complete src.addr=10.244.1.12:35526 src.workload="curl-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.244.1.9:15008 dst.hbone_addr="10.244.1.9:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v3-7d99fd7978-zznnq" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
+2024-05-04T10:11:04.974720Z info    access  connection complete src.addr=10.244.1.12:35536 src.workload="curl-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.244.1.7:15008 dst.hbone_addr="10.244.1.7:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v1-5fd6d4f8f8-26j92" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
+2024-05-04T10:11:04.979462Z info    access  connection complete src.addr=10.244.1.12:35552 src.workload="curl-7656cf8794-r7zb9" src.namespace="default" src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.244.1.8:15008 dst.hbone_addr="10.244.1.8:9080" dst.service="reviews.default.svc.cluster.local" dst.workload="reviews-v2-6f9b55c5db-c2dtw" dst.namespace="reviews" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-reviews" direction="outbound" bytes_sent=84 bytes_recv=169 duration="2ms"
 {{< /text >}}
 
 Це алгоритм балансування навантаження за схемою Round Robin, який відокремлений і незалежний від будь-якого алгоритму балансування навантаження, що може бути налаштований у полі `TrafficPolicy` ресурсу `VirtualService`. Як вже було згадано, усі аспекти обʼєктів API `VirtualService` реалізуються на проксі waypoint, а не на проксі ztunnel.

content/uk/docs/ambient/usage/verify-mtls-enabled/index.md

@@ -45,8 +45,8 @@ istio_tcp_connections_opened_total{
   reporter="source",
   request_protocol="tcp",
   response_flags="-",
-  source_app="sleep",
-  source_principal="spiffe://cluster.local/ns/default/sa/sleep",source_workload_namespace="default",
+  source_app="curl",
+  source_principal="spiffe://cluster.local/ns/default/sa/curl",source_workload_namespace="default",
   ...}
 {{< /text >}}
 
@@ -54,11 +54,11 @@ istio_tcp_connections_opened_total{
 
 ## Перевірка mTLS за допомогою логів {#validate-mtls-from-logs}
 
-Ви також можете переглянути лог ztunnel на стороні джерела або призначення, щоб підтвердити, що mTLS увімкнено, а також перевірити ідентичність учасників. Нижче наведено приклад логу ztunnel на стороні джерела для запиту від сервісу `sleep` до сервісу `details`:
+Ви також можете переглянути лог ztunnel на стороні джерела або призначення, щоб підтвердити, що mTLS увімкнено, а також перевірити ідентичність учасників. Нижче наведено приклад логу ztunnel на стороні джерела для запиту від сервісу `curl` до сервісу `details`:
 
 {{< text syntax=plain >}}
-2024-08-21T15:32:05.754291Z info access connection complete src.addr=10.42.0.9:33772 src.workload="sleep-7656cf8794-6lsm4" src.namespace="default"
-src.identity="spiffe://cluster.local/ns/default/sa/sleep" dst.addr=10.42.0.5:15008 dst.hbone_addr=10.42.0.5:9080 dst.service="details.default.svc.cluster.local"
+2024-08-21T15:32:05.754291Z info access connection complete src.addr=10.42.0.9:33772 src.workload="curl-7656cf8794-6lsm4" src.namespace="default"
+src.identity="spiffe://cluster.local/ns/default/sa/curl" dst.addr=10.42.0.5:15008 dst.hbone_addr=10.42.0.5:9080 dst.service="details.default.svc.cluster.local"
 dst.workload="details-v1-857849f66-ft8wx" dst.namespace="default" dst.identity="spiffe://cluster.local/ns/default/sa/bookinfo-details"
 direction="outbound" bytes_sent=84 bytes_recv=358 duration="15ms"
 {{< /text >}}

content/uk/docs/ambient/usage/waypoint/index.md

@@ -52,6 +52,7 @@ default           Active   24h   ambient
 
 {{< text syntax=bash snip_id=gen_waypoint_resource >}}
 $ istioctl waypoint generate --for service -n default
+apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
   labels:
@@ -79,6 +80,7 @@ waypoint default/waypoint applied
 
 {{< text syntax=bash >}}
 $ kubectl apply -f - <<EOF
+apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
   labels:
@@ -194,7 +196,7 @@ pod/reviews-v2-5b667bcbf8-spnnh labeled
 
 Стандартно проксі waypoint доступний для ресурсів у тому ж просторі імен. Починаючи з Istio 1.23, стало можливим використовувати waypoint в інших просторах імен. У цьому розділі ми розглянемо конфігурацію шлюзу, необхідну для увімкнення використання waypoint у різних просторах імен, а також як налаштувати ваші ресурси для використання waypoint з іншого простору імен.
 
-### Налаштування waypoint для використання у різних просторах імен
+### Налаштування waypoint для використання у різних просторах імен {#configure-a-waypoint-for-cross-namespace-use}
 
 Щоб увімкнути використання waypoint у різних просторах імен, слід налаштувати `Gateway` для [дозволу маршрутів](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.AllowedRoutes) з інших просторів імен.
 

content/uk/docs/concepts/security/index.md

@@ -351,7 +351,7 @@ Istio перевіряє політики на відповідність у ш
   - Поле `to` у `rules` визначає операції запиту.
   - Поле `when` визначає умови, необхідні для застосування правила.
 
-Наступний приклад показує політику авторизації, яка дозволяє двом джерелам, службовому обліковому запису `cluster.local/ns/default/sa/sleep` та простору імен `dev`, доступ до навантажень з мітками `app: httpbin` та `version: v1` у просторі імен `foo`, коли запити містять дійсний JWT токен:
+Наступний приклад показує політику авторизації, яка дозволяє двом джерелам, службовому обліковому запису `cluster.local/ns/default/sa/curl` та простору імен `dev`, доступ до навантажень з мітками `app: httpbin` та `version: v1` у просторі імен `foo`, коли запити містять дійсний JWT токен:
 
 {{< text yaml >}}
 apiVersion: security.istio.io/v1
@@ -368,7 +368,7 @@ spec:
  rules:
 - from:
   - source:
-       principals: ["cluster.local/ns/default/sa/sleep"]
+       principals: ["cluster.local/ns/default/sa/curl"]
   - source:
        namespaces: ["dev"]
    to:
@@ -573,7 +573,7 @@ spec:
  rules:
 - from:
   - source:
-       principals: ["cluster.local/ns/default/sa/sleep"]
+       principals: ["cluster.local/ns/default/sa/curl"]
    to:
   - operation:
        methods: ["GET"]

content/uk/docs/examples/bookinfo/index.md

@@ -65,10 +65,6 @@ test: yes
     $ kubectl label namespace default istio-injection=enabled
     {{< /text >}}
 
-    {{< warning >}}
-    Якщо ви використовуєте OpenShift, переконайтеся, що ви надали відповідні дозволи службовим обліковим записам у просторі імен, як описано на [сторінці налаштування OpenShift](/docs/setup/platform-setup/openshift/#privileged-security-context-constraints-for-application-sidecars).
-    {{< /warning >}}
-
 1. Розгорніть ваш застосунок за допомогою команди `kubectl`:
 
     {{< text bash >}}

content/uk/docs/examples/microservices-istio/add-istio/index.md

@@ -45,7 +45,7 @@ test: no
     reviews-v2-56f6855586-cnrjp       1/1       Running   0          7h
     reviews-v2-56f6855586-lxc49       1/1       Running   0          7h
     reviews-v2-56f6855586-qh84k       1/1       Running   0          7h
-    sleep-88ddbcfdd-cc85s             1/1       Running   0          7h
+    curl-88ddbcfdd-cc85s              1/1       Running   0          7h
     {{< /text >}}
 
 1.  Kubernetes замінив оригінальні podʼи `productpage` на podʼи з увімкненим Istio прозоро і поступово, виконуючи [rolling update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update-intro/). Kubernetes завершив роботу старого podʼа лише після того, як новий pod почав працювати, і прозоро переключив трафік на нові podʼи, один за одним. Тобто, він не завершив роботу більше ніж одного podʼа, поки не запустив новий pod. Це було зроблено для того, щоб уникнути переривання вашого застосунку, щоб він продовжував працювати під час виконання інʼєкції Istio.

content/uk/docs/examples/microservices-istio/add-new-microservice-version/index.md

@@ -29,17 +29,17 @@ test: no
         $ echo $REVIEWS_V2_POD_IP
         {{< /text >}}
 
-    2.  Надішліит запит до podʼа і переконайтеся, що він повертає правильний результат:
+    2.  Надішліть запит до podʼа і переконайтеся, що він повертає правильний результат:
 
         {{< text bash >}}
-        $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -- curl -sS "$REVIEWS_V2_POD_IP:9080/reviews/7"
+        $ kubectl exec $(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- curl -sS "$REVIEWS_V2_POD_IP:9080/reviews/7"
         {"id": "7","reviews": [{  "reviewer": "Reviewer1",  "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!", "rating": {"stars": 5, "color": "black"}},{  "reviewer": "Reviewer2",  "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare.", "rating": {"stars": 4, "color": "black"}}]}
         {{< /text >}}
 
     3.  Виконайте первинне навантажувальне тестування, надіславши запит 10 разів поспіль:
 
         {{< text bash >}}
-        $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -- sh -c "for i in 1 2 3 4 5 6 7 8 9 10; do curl -o /dev/null -s -w '%{http_code}\n' $REVIEWS_V2_POD_IP:9080/reviews/7; done"
+        $ kubectl exec $(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- sh -c "for i in 1 2 3 4 5 6 7 8 9 10; do curl -o /dev/null -s -w '%{http_code}\n' $REVIEWS_V2_POD_IP:9080/reviews/7; done"
         200
         200
         ...

content/uk/docs/examples/microservices-istio/bookinfo-kubernetes/index.md

@@ -81,16 +81,16 @@ test: no
     reviews-v1-77c65dc5c6-r55tl     1/1     Running   0          49s
     {{< /text >}}
 
-7. Після того, як сервіси досягнуть статусу `Running`, розгорніть тестовий pod, [sleep]({{< github_tree >}}/samples/sleep), для надсилання запитів до ваших мікросервісів:
+7. Після того, як сервіси досягнуть статусу `Running`, розгорніть тестовий pod, [curl]({{< github_tree >}}/samples/curl), для надсилання запитів до ваших мікросервісів:
 
     {{< text bash >}}
-    $ kubectl apply -f {{< github_file >}}/samples/sleep/sleep.yaml
+    $ kubectl apply -f {{< github_file >}}/samples/curl/curl.yaml
     {{< /text >}}
 
 8. Щоб підтвердити, що застосунок Bookinfo працює, надішліть запит до нього за допомогою команди curl з вашого тестового podʼа:
 
     {{< text bash >}}
-    $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -c sleep -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>"
+    $ kubectl exec $(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -c curl -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>"
     <title>Simple Bookstore App</title>
     {{< /text >}}
 

content/uk/docs/examples/microservices-istio/enable-istio-all-microservices/index.md

@@ -42,7 +42,7 @@ test: no
     productpage-v1-59b4f9f8d5-d4prx   2/2       Running   0          2m
     ratings-v1-b7b7fbbc9-sggxf        2/2       Running   0          2m
     reviews-v2-dfbcf859c-27dvk        2/2       Running   0          2m
-    sleep-88ddbcfdd-cc85s             1/1       Running   0          7h
+    curl-88ddbcfdd-cc85s              1/1       Running   0          7h
     {{< /text >}}
 
 1.  Зверніться до панелі управління Istio за допомогою власного URL, який ви налаштували у вашому `/etc/hosts` файлі [раніше](/docs/examples/microservices-istio/bookinfo-kubernetes/#update-your-etc-hosts-configuration-file):

content/uk/docs/examples/microservices-istio/production-testing/index.md

@@ -17,7 +17,7 @@ test: no
 1. Виконайте HTTP-запит з тестового podʼа до одного з ваших сервісів:
 
     {{< text bash >}}
-    $ kubectl exec $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -- curl -sS http://ratings:9080/ratings/7
+    $ kubectl exec $(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}') -- curl -sS http://ratings:9080/ratings/7
     {{< /text >}}
 
 ## Хаос-тестування {#chaos-testing}
@@ -47,7 +47,7 @@ test: no
     reviews-v1-77c65dc5c6-5wt8g     1/1     Running   0          47m
     reviews-v1-77c65dc5c6-kjvxs     1/1     Running   0          48m
     reviews-v1-77c65dc5c6-r55tl     1/1     Running   0          47m
-    sleep-88ddbcfdd-l9zq4           1/1     Running   0          47m
+    curl-88ddbcfdd-l9zq4            1/1     Running   0          47m
     {{< /text >}}
 
     Зверніть увагу, що перший pod перезапустився один раз.
@@ -84,7 +84,7 @@ test: no
     reviews-v1-77c65dc5c6-5wt8g     1/1     Running   0          48m
     reviews-v1-77c65dc5c6-kjvxs     1/1     Running   0          49m
     reviews-v1-77c65dc5c6-r55tl     1/1     Running   0          48m
-    sleep-88ddbcfdd-l9zq4           1/1     Running   0          48m
+    curl-88ddbcfdd-l9zq4            1/1     Running   0          48m
     {{< /text >}}
 
     Перший pod перезапустився двічі, а два інших podʼа `details` перезапустилися один раз. Можливо, ви помітите статуси `Error` і `CrashLoopBackOff`, поки podʼи не досягнуть статусу `Running`.

content/uk/docs/ops/common-problems/injection/index.md

@@ -100,11 +100,11 @@ test: n/a
     Наступна мітка перевизначає будь-яку стандартну політику і виконує примусову інʼєкцію sidecar:
 
     {{< text bash yaml >}}
-    $ kubectl get deployment sleep -o yaml | grep "sidecar.istio.io/inject:" -B4
+    $ kubectl get deployment curl -o yaml | grep "sidecar.istio.io/inject:" -B4
     template:
       metadata:
         labels:
-          app: sleep
+          app: curl
           sidecar.istio.io/inject: "true"
     {{< /text >}}
 
@@ -147,10 +147,10 @@ deployment.extensions "istiod" patched
 Наприклад, якщо pod контролера `istiod` не працював, коли ви намагалися розгорнути ваш pod, події покажуть таку помилку:
 
 {{< text bash >}}
-$ kubectl get events -n sleep
+$ kubectl get events -n curl
 ...
-23m Normal   SuccessfulCreate replicaset/sleep-9454cc476  Created pod: sleep-9454cc476-khp45
-22m Warning  FailedCreate     replicaset/sleep-9454cc476  Error creating: Internal error occurred: failed calling webhook "namespace.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": dial tcp 10.96.44.51:443: connect: connection refused
+23m Normal   SuccessfulCreate replicaset/curl-9454cc476  Created pod: curl-9454cc476-khp45
+22m Warning  FailedCreate     replicaset/curl-9454cc476  Error creating: Internal error occurred: failed calling webhook "namespace.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": dial tcp 10.96.44.51:443: connect: connection refused
 {{< /text >}}
 
 {{< text bash >}}

content/uk/docs/ops/common-problems/network-issues/index.md

@@ -244,11 +244,11 @@ spec:
 
 Імʼя порту `http-web` в визначенні Service явно вказує на протокол http для цього порту.
 
-Припустимо, що у нас також є `Deployment` podʼа [sleep]({{< github_tree >}}/samples/sleep) в стандартному просторі. Коли `nginx` доступний з цього podʼа `sleep`, використовуючи його IP-адресу (це один із поширених способів доступу до headless сервісу), запит проходить через `PassthroughCluster` до серверної сторони, але проксі-сервер на стороні сервера не може знайти маршрут до `nginx` і зіпиняється з помилкою `HTTP 503 UC`.
+Припустимо, що у нас також є `Deployment` podʼа [curl]({{< github_tree >}}/samples/curl) в стандартному просторі. Коли `nginx` доступний з цього podʼа `curl`, використовуючи його IP-адресу (це один із поширених способів доступу до headless сервісу), запит проходить через `PassthroughCluster` до серверної сторони, але проксі-сервер на стороні сервера не може знайти маршрут до `nginx` і зіпиняється з помилкою `HTTP 503 UC`.
 
 {{< text bash >}}
-$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath='{.items..metadata.name}')
-$ kubectl exec -it $SOURCE_POD -c sleep -- curl 10.1.1.171 -s -o /dev/null -w "%{http_code}"
+$ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath='{.items..metadata.name}')
+$ kubectl exec -it $SOURCE_POD -c curl -- curl 10.1.1.171 -s -o /dev/null -w "%{http_code}"
   503
 {{< /text >}}
 
@@ -261,8 +261,8 @@ $ kubectl exec -it $SOURCE_POD -c sleep -- curl 10.1.1.171 -s -o /dev/null -w "%
     Заголовок Host у запиті curl стандартно буде IP-адреса Pod. Вказання заголовка Host як `nginx.default` у нашому запиті до `nginx` успішно повертає `HTTP 200 OK`.
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath='{.items..metadata.name}')
-    $ kubectl exec -it $SOURCE_POD -c sleep -- curl -H "Host: nginx.default" 10.1.1.171 -s -o /dev/null -w "%{http_code}"
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath='{.items..metadata.name}')
+    $ kubectl exec -it $SOURCE_POD -c curl -- curl -H "Host: nginx.default" 10.1.1.171 -s -o /dev/null -w "%{http_code}"
       200
     {{< /text >}}
 
@@ -275,13 +275,13 @@ $ kubectl exec -it $SOURCE_POD -c sleep -- curl 10.1.1.171 -s -o /dev/null -w "%
     Це корисно в певних сценаріях, де клієнт може не мати можливості включити інформацію про заголовок у запит.
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath='{.items..metadata.name}')
-    $ kubectl exec -it $SOURCE_POD -c sleep -- curl 10.1.1.171 -s -o /dev/null -w "%{http_code}"
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath='{.items..metadata.name}')
+    $ kubectl exec -it $SOURCE_POD -c curl -- curl 10.1.1.171 -s -o /dev/null -w "%{http_code}"
       200
     {{< /text >}}
 
     {{< text bash >}}
-    $ kubectl exec -it $SOURCE_POD -c sleep -- curl -H "Host: nginx.default" 10.1.1.171 -s -o /dev/null -w "%{http_code}"
+    $ kubectl exec -it $SOURCE_POD -c curl -- curl -H "Host: nginx.default" 10.1.1.171 -s -o /dev/null -w "%{http_code}"
       200
     {{< /text >}}
 
@@ -290,8 +290,8 @@ $ kubectl exec -it $SOURCE_POD -c sleep -- curl 10.1.1.171 -s -o /dev/null -w "%
     До конкретного екземпляру headless сервісу також можна отримати доступ за допомогою доменного імені.
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath='{.items..metadata.name}')
-    $ kubectl exec -it $SOURCE_POD -c sleep -- curl web-0.nginx.default -s -o /dev/null -w "%{http_code}"
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath='{.items..metadata.name}')
+    $ kubectl exec -it $SOURCE_POD -c curl -- curl web-0.nginx.default -s -o /dev/null -w "%{http_code}"
       200
     {{< /text >}}
 

content/uk/docs/ops/common-problems/security-issues/index.md

@@ -159,7 +159,7 @@ Istiod конвертує та розподіляє ваші політики а
     2021-04-23T20:53:29.507641Z info ads XDS: Pushing:2021-04-23T20:53:29Z/23 Services:15 ConnectedEndpoints:2  Version:2021-04-23T20:53:29Z/23
     2021-04-23T20:53:29.507911Z debug authorization Processed authorization policy for httpbin-74fb669cc6-lpscm.foo with details:
         * found 0 CUSTOM actions
-    2021-04-23T20:53:29.508077Z debug authorization Processed authorization policy for sleep-557747455f-6dxbl.foo with details:
+    2021-04-23T20:53:29.508077Z debug authorization Processed authorization policy for curl-557747455f-6dxbl.foo with details:
         * found 0 CUSTOM actions
     2021-04-23T20:53:29.508128Z debug authorization Processed authorization policy for httpbin-74fb669cc6-lpscm.foo with details:
         * found 1 DENY actions, 0 ALLOW actions, 0 AUDIT actions
@@ -167,11 +167,11 @@ Istiod конвертує та розподіляє ваші політики а
         * built 1 HTTP filters for DENY action
         * added 1 HTTP filters to filter chain 0
         * added 1 HTTP filters to filter chain 1
-    2021-04-23T20:53:29.508158Z debug authorization Processed authorization policy for sleep-557747455f-6dxbl.foo with details:
+    2021-04-23T20:53:29.508158Z debug authorization Processed authorization policy for curl-557747455f-6dxbl.foo with details:
         * found 0 DENY actions, 0 ALLOW actions, 0 AUDIT actions
-    2021-04-23T20:53:29.509097Z debug authorization Processed authorization policy for sleep-557747455f-6dxbl.foo with details:
+    2021-04-23T20:53:29.509097Z debug authorization Processed authorization policy for curl-557747455f-6dxbl.foo with details:
         * found 0 CUSTOM actions
-    2021-04-23T20:53:29.509167Z debug authorization Processed authorization policy for sleep-557747455f-6dxbl.foo with details:
+    2021-04-23T20:53:29.509167Z debug authorization Processed authorization policy for curl-557747455f-6dxbl.foo with details:
         * found 0 DENY actions, 0 ALLOW actions, 0 AUDIT actions
     2021-04-23T20:53:29.509501Z debug authorization Processed authorization policy for httpbin-74fb669cc6-lpscm.foo with details:
         * found 0 CUSTOM actions
@@ -186,7 +186,7 @@ Istiod конвертує та розподіляє ваші політики а
         * added 1 TCP filters to filter chain 2
         * added 1 TCP filters to filter chain 3
         * added 1 TCP filters to filter chain 4
-    2021-04-23T20:53:29.510903Z info ads LDS: PUSH for node:sleep-557747455f-6dxbl.foo resources:18 size:85.0kB
+    2021-04-23T20:53:29.510903Z info ads LDS: PUSH for node:curl-557747455f-6dxbl.foo resources:18 size:85.0kB
     2021-04-23T20:53:29.511487Z info ads LDS: PUSH for node:httpbin-74fb669cc6-lpscm.foo resources:18 size:86.4kB
     {{< /text >}}
 
@@ -307,7 +307,7 @@ Istiod розподіляє політики авторизації до про
 
     {{< text plain >}}
     ...
-    2021-04-23T20:43:18.552857Z debug envoy rbac checking request: requestedServerName: outbound_.8000_._.httpbin.foo.svc.cluster.local, sourceIP: 10.44.3.13:46180, directRemoteIP: 10.44.3.13:46180, remoteIP: 10.44.3.13:46180,localAddress: 10.44.1.18:80, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/foo/sa/sleep, dnsSanPeerCertificate: , subjectPeerCertificate: , headers: ':authority', 'httpbin:8000'
+    2021-04-23T20:43:18.552857Z debug envoy rbac checking request: requestedServerName: outbound_.8000_._.httpbin.foo.svc.cluster.local, sourceIP: 10.44.3.13:46180, directRemoteIP: 10.44.3.13:46180, remoteIP: 10.44.3.13:46180,localAddress: 10.44.1.18:80, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/foo/sa/curl, dnsSanPeerCertificate: , subjectPeerCertificate: , headers: ':authority', 'httpbin:8000'
     ':path', '/headers'
     ':method', 'GET'
     ':scheme', 'http'
@@ -319,14 +319,14 @@ Istiod розподіляє політики авторизації до про
     'x-b3-traceid', '8a124905edf4291a21df326729b264e9'
     'x-b3-spanid', '21df326729b264e9'
     'x-b3-sampled', '0'
-    'x-forwarded-client-cert', 'By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=d64cd6750a3af8685defbbe4dd8c467ebe80f6be4bfe9ca718e81cd94129fc1d;Subject="";URI=spiffe://cluster.local/ns/foo/sa/sleep'
+    'x-forwarded-client-cert', 'By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=d64cd6750a3af8685defbbe4dd8c467ebe80f6be4bfe9ca718e81cd94129fc1d;Subject="";URI=spiffe://cluster.local/ns/foo/sa/curl'
     , dynamicMetadata: filter_metadata {
       key: "istio_authn"
       value {
         fields {
           key: "request.auth.principal"
           value {
-            string_value: "cluster.local/ns/foo/sa/sleep"
+            string_value: "cluster.local/ns/foo/sa/curl"
           }
         }
         fields {
@@ -338,13 +338,13 @@ Istiod розподіляє політики авторизації до про
         fields {
           key: "source.principal"
           value {
-            string_value: "cluster.local/ns/foo/sa/sleep"
+            string_value: "cluster.local/ns/foo/sa/curl"
           }
         }
         fields {
           key: "source.user"
           value {
-            string_value: "cluster.local/ns/foo/sa/sleep"
+            string_value: "cluster.local/ns/foo/sa/curl"
           }
         }
       }
@@ -360,7 +360,7 @@ Istiod розподіляє політики авторизації до про
 
     {{< text plain >}}
     ...
-    2021-04-23T20:59:11.838468Z debug envoy rbac checking request: requestedServerName: outbound_.8000_._.httpbin.foo.svc.cluster.local, sourceIP: 10.44.3.13:49826, directRemoteIP: 10.44.3.13:49826, remoteIP: 10.44.3.13:49826,localAddress: 10.44.1.18:80, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/foo/sa/sleep, dnsSanPeerCertificate: , subjectPeerCertificate: , headers: ':authority', 'httpbin:8000'
+    2021-04-23T20:59:11.838468Z debug envoy rbac checking request: requestedServerName: outbound_.8000_._.httpbin.foo.svc.cluster.local, sourceIP: 10.44.3.13:49826, directRemoteIP: 10.44.3.13:49826, remoteIP: 10.44.3.13:49826,localAddress: 10.44.1.18:80, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/foo/sa/curl, dnsSanPeerCertificate: , subjectPeerCertificate: , headers: ':authority', 'httpbin:8000'
     ':path', '/headers'
     ':method', 'GET'
     ':scheme', 'http'
@@ -372,14 +372,14 @@ Istiod розподіляє політики авторизації до про
     'x-b3-traceid', '696607fc4382b50017c1f7017054c751'
     'x-b3-spanid', '17c1f7017054c751'
     'x-b3-sampled', '0'
-    'x-forwarded-client-cert', 'By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=d64cd6750a3af8685defbbe4dd8c467ebe80f6be4bfe9ca718e81cd94129fc1d;Subject="";URI=spiffe://cluster.local/ns/foo/sa/sleep'
+    'x-forwarded-client-cert', 'By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=d64cd6750a3af8685defbbe4dd8c467ebe80f6be4bfe9ca718e81cd94129fc1d;Subject="";URI=spiffe://cluster.local/ns/foo/sa/curl'
     , dynamicMetadata: filter_metadata {
       key: "istio_authn"
       value {
         fields {
           key: "request.auth.principal"
           value {
-            string_value: "cluster.local/ns/foo/sa/sleep"
+            string_value: "cluster.local/ns/foo/sa/curl"
           }
         }
         fields {
@@ -391,13 +391,13 @@ Istiod розподіляє політики авторизації до про
         fields {
           key: "source.principal"
           value {
-            string_value: "cluster.local/ns/foo/sa/sleep"
+            string_value: "cluster.local/ns/foo/sa/curl"
           }
         }
         fields {
           key: "source.user"
           value {
-            string_value: "cluster.local/ns/foo/sa/sleep"
+            string_value: "cluster.local/ns/foo/sa/curl"
           }
         }
       }
@@ -417,7 +417,7 @@ Istiod розподіляє політики авторизації до про
 Якщо ви підозрюєте, що деякі з ключів і/або сертифікатів, що використовуються Istio, є некоректними, ви можете перевірити вміст з будь-якого podʼа:
 
 {{< text bash >}}
-$ istioctl proxy-config secret sleep-8f795f47d-4s4t7
+$ istioctl proxy-config secret curl-8f795f47d-4s4t7
 RESOURCE NAME     TYPE           STATUS     VALID CERT     SERIAL NUMBER                               NOT AFTER                NOT BEFORE
 default           Cert Chain     ACTIVE     true           138092480869518152837211547060273851586     2020-11-11T16:39:48Z     2020-11-10T16:39:48Z
 ROOTCA            CA             ACTIVE     true           288553090258624301170355571152070165215     2030-11-08T16:34:52Z     2020-11-10T16:34:52Z
@@ -426,7 +426,7 @@ ROOTCA            CA             ACTIVE     true           288553090258624301170
 Передавши прапорець `-o json`, ви можете передати повний вміст сертифіката до `openssl` для аналізу його вмісту:
 
 {{< text bash >}}
-$ istioctl proxy-config secret sleep-8f795f47d-4s4t7 -o json | jq '[.dynamicActiveSecrets[] | select(.name == "default")][0].secret.tlsCertificate.certificateChain.inlineBytes' -r | base64 -d | openssl x509 -noout -text
+$ istioctl proxy-config secret curl-8f795f47d-4s4t7 -o json | jq '[.dynamicActiveSecrets[] | select(.name == "default")][0].secret.tlsCertificate.certificateChain.inlineBytes' -r | base64 -d | openssl x509 -noout -text
 Certificate:
     Data:
         Version: 3 (0x2)

content/uk/docs/ops/configuration/traffic-management/dns-proxy/index.md

@@ -37,7 +37,7 @@ EOF
 {{< text syntax=yaml snip_id=none >}}
 kind: Deployment
 metadata:
-  name: sleep
+  name: curl
 spec:
 ...
   template:
@@ -80,13 +80,13 @@ EOF
 
 {{< text bash >}}
 $ kubectl label namespace default istio-injection=enabled --overwrite
-$ kubectl apply -f @samples/sleep/sleep.yaml@
+$ kubectl apply -f @samples/curl/curl.yaml@
 {{< /text >}}
 
 Без перехоплення DNS запит до `address.internal`, ймовірно, не буде успішно розвʼязаний. Після ввімкнення цієї функції ви маєте отримати відповідь на основі налаштованої `address`:
 
 {{< text bash >}}
-$ kubectl exec deploy/sleep -- curl -sS -v address.internal
+$ kubectl exec deploy/curl -- curl -sS -v address.internal
 *   Trying 198.51.100.1:80...
 {{< /text >}}
 
@@ -126,7 +126,7 @@ EOF
 Тепер надішліть запит:
 
 {{< text bash >}}
-$ kubectl exec deploy/sleep -- curl -sS -v auto.internal
+$ kubectl exec deploy/curl -- curl -sS -v auto.internal
 *   Trying 240.240.0.1:80...
 {{< /text >}}
 
@@ -211,7 +211,7 @@ $ kubectl exec deploy/sleep -- curl -sS -v auto.internal
 5. Перевірте, чи слухачі налаштовані окремо для кожного сервісу на стороні клієнта:
 
     {{< text bash >}}
-    $ istioctl pc listener deploy/sleep | grep tcp-echo | awk '{printf "ADDRESS=%s, DESTINATION=%s %s\n", $1, $4, $5}'
+    $ istioctl pc listener deploy/curl | grep tcp-echo | awk '{printf "ADDRESS=%s, DESTINATION=%s %s\n", $1, $4, $5}'
     ADDRESS=240.240.105.94, DESTINATION=Cluster: outbound|9000||tcp-echo.external-2.svc.cluster.local
     ADDRESS=240.240.69.138, DESTINATION=Cluster: outbound|9000||tcp-echo.external-1.svc.cluster.local
     {{< /text >}}
@@ -221,7 +221,7 @@ $ kubectl exec deploy/sleep -- curl -sS -v auto.internal
 {{< text bash >}}
 $ kubectl -n external-1 delete -f @samples/tcp-echo/tcp-echo.yaml@
 $ kubectl -n external-2 delete -f @samples/tcp-echo/tcp-echo.yaml@
-$ kubectl delete -f @samples/sleep/sleep.yaml@
+$ kubectl delete -f @samples/curl/curl.yaml@
 $ istioctl uninstall --purge -y
 $ kubectl delete ns istio-system external-1 external-2
 $ kubectl label namespace default istio-injection-

content/uk/docs/ops/configuration/traffic-management/manage-mesh-certificates/index.md

@@ -93,7 +93,7 @@ meshConfig:
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: sleep
+  name: curl
 spec:
   ...
   template:

content/uk/docs/ops/configuration/traffic-management/network-topologies/index.md

@@ -143,25 +143,8 @@ $ export GATEWAY_URL=$(kubectl get gateways.gateway.networking.k8s.io httpbin-ga
 7. Виконайте наступну команду `curl`, щоб імітувати запит із проксі-адресами в заголовку `X-Forwarded-For`:
 
     {{< text syntax=bash snip_id=curl_xff_headers >}}
-    $ curl -s -H 'X-Forwarded-For: 56.5.6.7, 72.9.5.6, 98.1.2.3' "$GATEWAY_URL/get?show_env=true"
-    {
-    "args": {
-      "show_env": "true"
-    },
-      "headers": {
-      "Accept": ...
-      "Host": ...
-      "User-Agent": ...
-      "X-Envoy-Attempt-Count": ...
-      "X-Envoy-External-Address": "72.9.5.6",
-      "X-Forwarded-Client-Cert": ...
-      "X-Forwarded-For": "56.5.6.7, 72.9.5.6, 98.1.2.3,10.244.0.1",
-      "X-Forwarded-Proto": ...
-      "X-Request-Id": ...
-    },
-      "origin": "56.5.6.7, 72.9.5.6, 98.1.2.3,10.244.0.1",
-      "url": ...
-    }
+    $ curl -s -H 'X-Forwarded-For: 56.5.6.7, 72.9.5.6, 98.1.2.3' "$GATEWAY_URL/get?show_env=true" | jq '.headers["X-Forwarded-For"][0]'
+      "56.5.6.7, 72.9.5.6, 98.1.2.3,10.244.0.1"
     {{< /text >}}
 
 {{< tip >}}

content/uk/docs/ops/deployment/deployment-models/index.md

@@ -91,8 +91,6 @@ Istio використовує віртуальну IP-адресу, повер
 {{< tip >}}
 Є кілька можливостей, що сприяють спрощенню роботи з DNS:
 
-- [DNS sidecar proxy](/blog/2020/dns-proxy/) підтримка доступна для перегляду в Istio 1.8. Це забезпечує перехоплення DNS для всіх робочих навантажень із sidecar, що дозволяє Istio виконувати DNS-запити від імені застосунку.
-
 - [Admiral](https://github.com/istio-ecosystem/admiral) — це проект спільноти Istio, що надає ряд можливостей мультикластеру. Якщо вам потрібно підтримувати топології з кількома мережами, керування цією конфігурацією у кількох кластерах у великому масштабі є складним завданням. Admiral має власний підхід до цієї конфігурації і забезпечує автоматичне постачання та синхронізацію між кластерами.
 
 - [Kubernetes Multi-Cluster Services](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/1645-multi-cluster-services-api) є пропозицією покращення Kubernetes (KEP), яка визначає API для експорту сервісів до кількох кластерів. Це ефективно перекладає відповідальність за видимість сервісу та резолюцію DNS для всього `clusterset` на Kubernetes. Також ведеться робота над інтеграцією підтримки `MCS` в Istio, що дозволить Istio працювати з будь-яким контролером `MCS` хмарного постачальника або навіть діяти як контролер `MCS` для всієї мережі.

content/uk/docs/ops/deployment/performance-and-scalability/index.md

@@ -29,7 +29,7 @@ Istio полегшує створення мережі розгорнутих с
 
 Компоненти панелі даних Istio, проксі Envoy, обробляють дані, що проходять через систему. Компонент панелі управління Istio, Istiod, налаштовує панель даних. Панель даних і панель управління мають окремі питання продуктивності.
 
-## Огляд продуктивності для Istio 1.22 {#performance-summary-for-istio-122}
+## Огляд продуктивності для Istio 1.24 {#performance-summary-for-istio-124}
 
 [Тести навантаження Istio](https://github.com/istio/tools/tree/{{< source_branch_name >}}/perf/load) охоплюють **1000** сервісів і **2000** podʼів у mesh Istio з 70 000 запитами в секунду по всій мережі.
 
@@ -63,44 +63,44 @@ Istiod налаштовує sidecar проксі на основі конфіг
 
 Затримки, пропускна здатність та споживання процесора і памʼяті проксі вимірюються як функція зазначених факторів.
 
-### Використання процесора та пам'яті sidecarʼом {#sidecar-cpu-and-memory-usage}
+### Використання ресурсів sidecarʼом та ztunnel{#sidecar-and-ztunnel-resource-usage}
 
-Оскільки sidecar проксі виконує додаткову роботу на шляху даних, він споживає ресурси процесора та памʼять. У Istio 1.22 sidecar проксі споживає приблизно 0.5 vCPU на 1000 запитів за секунду.
+Оскільки sidecar проксі виконує додаткову роботу на шляху даних, він споживає ресурси процесора та памʼять. В Istio 1.24, при 1000 http-запитів на секунду, що містять 1 КБ корисного навантаження:
 
-Споживання памʼяті проксі залежить від загального стану конфігурації, яку він зберігає. Велика кількість прослуховувачів, кластерів і маршрутів може збільшити споживання памʼяті. У великому просторі імен із ввімкненою [ізоляцією простору імен](/docs/reference/config/networking/sidecar/) проксі споживає приблизно 50 МБ памʼяті.
+- один проксі з двома робочими потоками споживає близько 0,20 vCPU і 60 МБ памʼяті.
+- один проксі waypoint з 2 робочими потоками споживає близько 0,25 vCPU і 60 МБ памʼяті
+- один ztunnel-проксі споживає близько 0,06 vCPU і 12 МБ памʼяті.
 
-Оскільки проксі зазвичай не буферизує дані, що проходять через нього, швидкість запитів не впливає на споживання памʼяті.
+Споживання памʼяті проксі залежить від загального стану конфігурації, яку він зберігає. Велика кількість прослуховувачів, кластерів і маршрутів може збільшити споживання памʼяті.
 
 ### Затримка {#latency}
 
-Оскільки Istio вставляє sidecar проксі на шляху даних, затримка є важливим фактором. Кожна функція, яку додає Istio, також додає до довжини шляху всередині проксі та потенційно впливає на затримку.
+Оскільки Istio додає sidecar проксі чи ztunnel на шляху даних, затримка є важливим фактором. Кожна функція, яку додає Istio, також додає до довжини шляху всередині проксі та потенційно впливає на затримку.
 
 Проксі Envoy збирає необроблені дані телеметрії після надсилання відповіді клієнту. Час, витрачений на збір необробленої телеметрії для запиту, не додається до загального часу виконання цього запиту. Однак, оскільки обробник зайнятий обробкою запиту, він не може негайно почати обробляти наступний запит. Цей процес додає час очікування в черзі для наступного запиту та впливає на середні та крайні затримки. Фактична крайня затримка залежить від шаблону трафіку.
 
-### Затримка для Istio 1.22 {#latency-for-istio-122}
+### Затримка для Istio 1.24 {#latency-for-istio-124}
 
-Всередині сервісної мережі запит проходить через проксі з боку клієнта, а потім через проксі з боку сервера. У стандартній конфігурації в режимі оточення (ambient) (з L4) для Istio 1.22 два проксі ztunnel додають приблизно 0.17 мс і 0.20 мс до 90-го та 99-го процентилю затримки відповідно до базової затримки панелі даних. Ці результати ми отримали, використовуючи [бенчмарки Istio](https://github.com/istio/tools/tree/{{< source_branch_name >}}/perf/benchmark) для протоколу `http/1.1`, з розміром повідомлення 1 кБ при 1000 запитах за секунду з використанням 1,2,4,8,16,32,64 клієнтських підключень, 2 робочих процесах проксі та ввімкнутим mutual TLS.
+В режимі sidecar запит пройде через клієнтський проксі-сервер, а потім через серверний проксі-сервер, перш ніж потрапить на сервер, і навпаки. В режимі ambient запит пройде через клієнтський вузол ztunnel, а потім через серверний вузол ztunnel, перш ніж потрапить на сервер. При налаштованих маршрутних точках запит буде проходити через проксі-маршрутизатор між ztunnel'ами. На наступних графіках показано затримки P90 і P99 для запитів http/1.1, що проходять через різні режими панелі даних. Для проведення тестів ми використовували пустий кластер з 5 машин [M3 Large](https://deploy.equinix.com/product/servers/m3-large/) та [Flannel](https://github.com/flannel-io/flannel) як основний CNI. Ми отримали ці результати за допомогою [Istio benchmarks](https://github.com/istio/tools/tree/{{< source_branch_name >}}/perf/benchmark) для протоколу `http/1.1` з корисним навантаженням 1 КБ при 500, 750, 1000, 1250 і 1500 запитах на секунду з використанням 4 клієнтських зʼєднань, 2 робочих проксі-серверів і включеним взаємним TLS.
 
 Примітка: Це тестування було виконано у [CNCF Community Infrastructure Lab](https://github.com/cncf/cluster). Різне апаратне забезпечення може давати різні значення.
 
-<p><h6 style="text-align: center;"> Затримка P90 для клієнтських підключень </h6></p>
 <img width="90%" style="display: block; margin: auto;"
-    src="istio-1.22.0-fortio-90.png"
+    src="istio-1.24.0-fortio-90.png"
     alt="Затримка P90 для клієнтських підключень"
     caption="Затримка P90 для клієнтських підключень"
 />
 <br><br>
-<p><h6 style="text-align: center;"> Затримка P99 для клієнтських підключень </h6></p>
 <img width="90%" style="display: block; margin: auto;"
-    src="istio-1.22.0-fortio-99.png"
+    src="istio-1.24.0-fortio-99.png"
     alt="Затримка P99 для клієнтських підключень"
     caption="Затримка P99 для клієнтських підключень"
 />
 <br>
 
-- `no_mesh`: Клієнтський pod напряму викликає серверний pod, жодних podʼів у сервісній мережі Istio.
+- `no mesh`: Клієнтський pod напряму викликає серверний pod, жодних podʼів у сервісній мережі Istio.
 - `ambient: L4`: Стандартний режим оточення з {{< gloss "Захищений L4 Overlay" >}}захищеним L4 Overlay{{< /gloss >}}
-- `ambient: L4+L7`: Стандартний режим оточення із захищеним  L4 Overlay та ввімкненими waypoints для простору імен.
+- `ambient: L4+L7`: Стандартний режим оточення із захищеним L4 Overlay та ввімкненими waypoints для простору імен.
 - `sidecar`: Клієнтські та серверні sidecarʼи.
 
 ### Інструменти для тестування {#benchmarking-tools}

content/uk/docs/ops/deployment/platform-requirements/index.md

@@ -31,6 +31,7 @@ aliases: /uk/docs/setup/platform-setup/prerequisites
 | `xt_owner` |  |
 | `xt_tcpudp` |  |
 | `xt_multiport`|  |
+| `ip_set`| Потрібен для режиму ambient панелі даних |
 
 Наведені нижче додаткові модулі використовуються зазначеними вище модулями та також повинні бути завантажені на вузлі кластера:
 
@@ -47,6 +48,7 @@ aliases: /uk/docs/setup/platform-setup/prerequisites
 | `nf_nat_ipv6` | Потрібен лише для кластерів IPv6/подвійний стек |
 | `nf_nat_redirect` |  |
 | `x_tables` |  |
+| `ip_set_hash_ip`| Потрібен для режиму ambient панелі даних |
 
 Хоча це рідкість, використання власних або нестандартних ядер Linux або дистрибутивів Linux може призвести до сценаріїв, коли специфічні модулі, зазначені вище, не доступні на хості або не можуть бути автоматично завантажені `iptables`. Наприклад, ця [`проблема selinux`](https://www.suse.com/support/kb/doc/?id=000020241) описує ситуацію в деяких версіях RHEL, де конфігурація `selinux` може перешкоджати автоматичному завантаженню деяких з вищезазначених модулів ядра.
 

content/uk/docs/ops/deployment/security-model/index.md

@@ -0,0 +1,179 @@
+---
+title: Модель безпеки
+description: Описує модель безпеки Istio.
+weight: 10
+owner: istio/wg-security-maintainers
+test: n/a
+---
+
+Цей документ має на меті описати стан безпеки різних компонентів Istio і те, як можливі атаки можуть вплинути на систему.
+
+## Компоненти {#components}
+
+Istio постачається з різноманітними додатковими компонентами, які будуть розглянуті тут. Для загального огляду перегляньте розділ [Архітектура Istio](/docs/ops/deployment/architecture/). Зазначимо, що розгортання Istio є надзвичайно гнучким; нижче ми здебільшого розглядатимемо найгірші сценарії.
+
+### Istiod {#istiod}
+
+Istiod служить основним компонентом панелі управління Istio, часто виконуючи роль [компонента XDS](/docs/concepts/traffic-management/) та виступаючи як [Центр Сертифікації mТLS](/docs/concepts/security/).
+
+Istiod вважається високопривілейованим компонентом, схожим на сервер API Kubernetes.
+
+* Він має високі привілеї Kubernetes RBAC, зазвичай включаючи доступ для читання `Secret` та запис через webhook.
+* Виконуючи роль CA, він може надавати різні сертифікати.
+* Виконуючи роль панелі управління XDS, він може налаштовувати проксі для виконання довільних дій.
+
+Таким чином, безпека кластера тісно повʼязана з безпекою Istiod. Дотримання [найкращих практик безпеки Kubernetes](https://kubernetes.io/docs/concepts/security/) щодо доступу до Istiod є вкрай важливим.
+
+### Втулок Istio CNI {#istio-cni-plugin}
+
+Istio може бути розгорнуто з [втулком Istio CNI як DaemonSet](/docs/setup/additional-setup/cni/). Цей `DaemonSet` відповідає за налаштування мережевих правил в Istio, забезпечуючи прозоре перенаправлення трафіку за потреби. Це альтернатива контейнеру `istio-init`, про який [нижче](#sidecar-proxies).
+
+Оскільки CNI `DaemonSet` змінює мережеві правила на вузлі, він потребує підвищеного `securityContext`. Однак, на відміну від [Istiod](#istiod), це локальний привілей вузла. Наслідки цього дивись [нижче](#node-compromise).
+
+Оскільки це обʼєднує підвищені привілеї, необхідні для налаштування мережі, в одному podʼі, а не в *всіх* podʼах, цей параметр зазвичай є рекомендованим.
+
+### Проксі sidecar {#sidecar-proxies}
+
+Istio може [опціонально](/docs/overview/dataplane-modes/) розгортати проксі sidecar поруч із застосунком.
+
+Проксі sidecar потребує налаштування мережі для направлення всього трафіку через проксі. Це можна зробити за допомогою [втулка Istio CNI](#istio-cni-plugin) або розгортання `initContainer` (`istio-init`) у podʼі (це відбувається автоматично, якщо втулок CNI не розгорнуто). Контейнер `istio-init` потребує прав `NET_ADMIN` та `NET_RAW`. Однак ці права діють лише під час ініціалізації — основний контейнер sidecar є повністю непривілейованим.
+
+Додатково, проксі sidecar не потребує жодних привілеїв Kubernetes RBAC.
+
+Кожен проксі sidecar має право запитувати сертифікат для повʼязаного Службового облікового запису Podʼа.
+
+### Gateways та Waypoints {#gateways-and-waypoints}
+
+{{< gloss "gateway" >}}Шлюзи{{< /gloss >}} та {{< gloss "waypoint">}}Waypoints{{< /gloss >}} функціонують як автономні розгортання проксі. На відміну від [sidecar](#sidecar-proxies), вони не потребують жодних змін у мережі та, відповідно, не потребують привілеїв.
+
+Ці компоненти працюють з власними службовими обліковими записами, відмінними від ідентифікації застосунків.
+
+### Ztunnel {#ztunnel}
+
+{{< gloss "ztunnel" >}}Ztunnel{{< /gloss >}} виступає як проксі на рівні вузла. Віг вимагає прав `NET_ADMIN`, `SYS_ADMIN` та `NET_RAW`. Як і [втулок Istio CNI](#istio-cni-plugin), він є **локальними привілеями для вузла**. Ztunnel не має жодних повʼязаних привілеїв Kubernetes RBAC.
+
+Ztunnel має право запитувати сертифікати для будь-яких Службових облікових записів podʼів, що працюють на тому ж вузлі. Аналогічно до [kubelet](https://kubernetes.io/docs/reference/access-authn-authz/node/), він явно не дозволяє запитувати довільні сертифікати. Це, знову ж таки, забезпечує, що ці привілеї є **локальними для вузла**.
+
+## Властивості перехоплення трафіку {#traffic-capture-properties}
+
+Коли pod стає частиною мережі, весь вхідний TCP трафік буде перенаправлено до проксі. Це включає як mTLS/{{< gloss >}}HBONE{{< /gloss >}}, так і незашифрований трафік. Будь-які придатні [політики](/docs/tasks/security/authorization/) для робочого навантаження будуть застосовані перед перенаправленням трафіку до робочого навантаження.
+
+Однак, Istio наразі не гарантує, що *вихідний* трафік буде перенаправлено до проксі. Дивіться [обмеження перехоплення трафіку](/docs/ops/best-practices/security/#understand-traffic-capture-limitations). Таким чином, необхідно дотримуватись кроків з [забезпечення безпеки вихідного трафіку](/docs/ops/best-practices/security/#securing-egress-traffic), якщо потрібні політики для вихідного трафіку.
+
+## Властивості mTLS Properties {#mutual-tls-properties}
+
+[mTLS](/docs/concepts/security/#mutual-tls-authentication) забезпечує основу для більшості безпекових позицій Istio. Нижче пояснено різні властивості, які забезпечує mTLS для безпеки Istio.
+
+### Центр Сертифікації {#certificate-authority}
+
+Istio має вбудований Центр Сертифікації.
+
+Стандартно, CA дозволяє автентифікувати клієнтів на основі одного з наступних варіантів:
+
+* Токен JWT Kubernetes з аудиторією `istio-ca`, який перевіряється за допомогою `TokenReview` Kubernetes. Це стандартний метод в podʼах Kubernetes.
+* Наявний сертифікат mTLS.
+* JWT-токени користувачів, перевірені з використанням OIDC (вимагає налаштування).
+
+CA видаватиме лише ті сертифікати, які запитуються для ідентифікаторів, для яких клієнт пройшов автентифікацію.
+
+Istio також може інтегруватися з різними сторонніми CA; будь ласка, зверніться до документації з безпеки відповідних CA для детальнішої інформації.
+
+### Клієнт мTLS {#client-mtls}
+
+{{< tabset category-name="dataplane" >}}
+{{< tab name="Режим sidecar" category-value="sidecar" >}}
+У режимі sidecar клієнтський sidecar буде [автоматично використовувати TLS](/docs/ops/configuration/traffic-management/tls-configuration/#auto-mtls) під час підключення до сервісу, який підтримує mTLS. Це також можна [явно налаштувати](/docs/ops/configuration/traffic-management/tls-configuration/#sidecars). Зверніть увагу, що це автоматичне виявлення залежить від того, як Istio асоціює трафік з Service. [Непідтримувані типи трафіку](/docs/ops/configuration/traffic-management/traffic-routing/#unmatched-traffic) або [обмеження конфігурації](/docs/ops/configuration/mesh/configuration-scoping/) можуть завадити цьому.
+
+Під час [підключення до бекенду](/docs/concepts/security/#secure-naming) набір дозволених ідентифікацій обчислюється на рівні Service, базуючись на обʼєднанні всіх ідентифікацій бекенду.
+{{< /tab >}}
+
+{{< tab name="Режим ambient" category-value="ambient" >}}
+У режимі ambient Istio автоматично використовуватиме mTLS під час підключення до будь-якого бекенду, що підтримує mTLS, і перевірятиме, чи відповідає ідентифікація пункту призначення очікуваній ідентифікації для виконання робочого навантаження.
+
+Ці властивості відрізняються від режиму sidecar тим, що є властивостями окремих робочих навантажень, а не сервісу. Це дозволяє виконувати більш точні перевірки автентифікації та підтримувати ширший спектр робочих навантажень.
+{{< /tab >}}
+{{< /tabset >}}
+
+### Сервер mTLS {#server-mtls}
+
+Стандартно Istio приймає mTLS та не mTLS трафік (що часто називають «дозвільним режимом»). Користувачі можуть вибрати суворий режим, написавши правила `PeerAuthentication` або `AuthorizationPolicy`, що вимагають mTLS.
+
+При встановленні зʼєднання mTLS перевіряється сертифікат учасника. Крім того, перевіряється належність ідентифікаторів до одного домену довіри. Щоб дозволити перевірку лише певних ідентифікаторів, можна використовувати `AuthorizationPolicy`.
+
+## Досліджені типи компрометації {#compromise-types-explored}
+
+На основі наведеного вище огляду ми розглянемо вплив на кластер, якщо різні частини системи будуть скомпрометовані.
+У реальному світі існує безліч різних змінних навколо будь-якої атаки на безпеку:
+
+* Наскільки легко її виконати
+* Які попередні привілеї потрібні
+* Як часто вона може бути використана
+* Які наслідки (повне віддалене виконання, відмова в обслуговуванні і т.д.).
+
+У цьому документі ми розглянемо найгірший сценарій: скомпрометований компонент означає, що зловмисник має повну можливість віддаленого виконання коду.
+
+### Компрометація робочого навантаження {#workload-compromise}
+
+У цьому випадку відбувається компрометація робочого навантаження застосунку (pod).
+
+Pod [*може* мати доступ](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting) до токена службового облікового запису. Якщо це так, компрометація навантаження може поширитися від одного pod, компрометуючи весь службовий обліковий запис.
+
+{{< tabset category-name="dataplane" >}}
+{{< tab name="Режим sidecar" category-value="sidecar" >}}
+У моделі sidecar проксі розташований поруч із pod і працює в межах тієї ж зони довіри. Скомпрометований застосунок може втручатися у роботу проксі через адмін-API або інші інтерфейси, зокрема для вилучення матеріалу приватного ключа, дозволяючи іншому агенту видавати себе за робоче навантаження. Припускається, що компрометація робочого навантаження включає також компрометацію проксі sidecar.
+
+Таким чином, скомпрометоване навантаження може:
+
+* Надсилати довільний трафік, з mTLS або без нього. Воно може обійти будь-яку конфігурацію проксі або навіть сам проксі. Зазначимо, що Istio не пропонує політики авторизації для вихідного трафіку, тому обхід політики авторизації вихідного трафіку не відбувається.
+* Приймати трафік, який вже був призначений для застосунку. Воно може обійти політики, налаштовані в проксі sidecar.
+
+Основний висновок тут полягає в тому, що, хоча скомпрометоване навантаження може поводитися шкідливо, це не дає йому змоги обійти політики в *інших* навантаженнях.
+{{< /tab >}}
+
+{{< tab name="Режим ambient" category-value="ambient" >}}
+У режимі ambient проксі вузла не розміщено в межах podʼа і він працює в іншій зоні довіри як частина окремого podʼа.
+
+Скомпрометований застосунок може надсилати довільний трафік. Однак він не контролює проксі вузла, який визначатиме, як обробляти вхідний і вихідний трафік.
+
+Крім того, оскільки pod не має доступу до токена службового облікового запису для запиту сертифіката mTLS, можливості для латерального переміщення зменшуються.
+{{< /tab >}}
+{{< /tabset >}}
+
+Istio пропонує різноманітні функції, які можуть обмежити наслідки такої компрометації:
+
+* [Функції спостережуваності](/docs/tasks/observability/) можуть бути використані для ідентифікації атаки.
+* [Політики](/docs/tasks/security/authorization/) можуть обмежити типи трафіку, які навантаження може надсилати або отримувати.
+
+### Компрометація проксі - Sidecars {#proxy-compromise---sidecars}
+
+У цьому випадку проксі sidecar є скомпрометованим. Оскільки sidecar і застосунок знаходяться в одній зоні довіри, це функціонально еквівалентно до [компрометації робочого навантаження](#workload-compromise).
+
+### Компрометація проксі - Waypoint {#proxy-compromise---waypoint}
+
+У цьому випадку скомпрометовано [проксі waypoint](#gateways-and-waypoints). Хоча у waypoint немає жодних привілеїв для використання зловмисником, він обслуговує (потенційно) багато різних сервісів та робочих навантажень. Скомпрометований waypoint може отримувати, переглядати, змінювати або відхиляти весь трафік для цих навантажень.
+
+Istio пропонує можливість [налаштування гранулярності розгортання waypoint](/docs/ambient/usage/waypoint/#useawaypoint). Користувачі можуть розглянути можливість розгортання більш ізольованих waypoint для посилення ізоляції.
+
+Оскільки waypoint працює з окремою ідентичністю від застосунків, які він обслуговує, компрометація waypoint не означає, що можна видати себе за застосунки користувача.
+
+### Компрометація проксі - Ztunnel {#proxy-compromise---ztunnel}
+
+У цьому випадку компрометовано проксі [ztunnel](#ztunnel).
+
+Скомпрометований ztunnel надає зловмиснику контроль над мережею вузла.
+
+Ztunnel має доступ до матеріалу приватних ключів для кожного застосунку, який працює на його вузлі. Компрометація ztunnel може призвести до їхнього отримання та використання в інших місцях. Однак латеральний рух до ідентичностей за межами розміщених робочих навантажень неможливий; кожен ztunnel має авторизацію доступу лише до сертифікатів для навантажень, що працюють на його вузлі, обмежуючи радіус ураження скомпрометованого ztunnel.
+
+### Компрометація вузла {#node-compromise}
+
+У цьому випадку скомпрометовано вузол Kubernetes. І [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/node/), і Istio спроєктовані для обмеження масштабу шкоди від компрометації одного вузла, так, щоб компрометація одного вузла не призводила до [компрометації всього кластера](#cluster-api-server-compromise).
+
+Проте атака має повний контроль над будь-якими робочими навантаженнями, що виконуються на цьому вузлі. Наприклад, вона може скомпрометувати будь-які спільно розміщені [waypoint](#proxy-compromise---waypoint), локальний [ztunnel](#proxy-compromise---ztunnel), будь-які [sidecar](#proxy-compromise---sidecars), будь-які спільно розміщені [екземпляри Istiod](#istiod-compromise) тощо.
+
+### Компрометація кластера (API Server) {#cluster-api-server-compromise}
+
+Компрометація API-сервера Kubernetes фактично означає, що весь кластер і mesh скомпрометовані. На відміну від більшості інших векторів атаки, Istio мало що може зробити для обмеження масштабу такої атаки. Скомпрометований API-сервер надає зловмиснику повний контроль над кластером, включно з можливістю виконувати `kubectl exec` на довільних podʼах, видаляти будь-які `AuthorizationPolicies` Istio або навіть повністю видаляти Istio.
+
+### Компрометація Istiod {#istiod-compromise}
+
+Компрометація Istiod зазвичай призводить до такого ж результату, як і [компрометація API-сервера](#cluster-api-server-compromise). Istiod є дуже привілейованим компонентом, який слід ретельно захищати. Дотримання [кращих практик безпеки](/docs/ops/best-practices/security) є важливим для підтримки захисту кластера.

content/uk/docs/ops/diagnostic-tools/multicluster/index.md

@@ -11,10 +11,10 @@ test: no
 
 ## Балансування навантаження між кластерами {#cross-cluster-load-balancing}
 
-Найпоширеніша, але також широкомасштабна проблема з багатомережевими установками — це непрацююче балансування навантаження між кластерами. Зазвичай це проявляється в тому, що ви бачите відповіді тільки від кластерної локального екземпляру сервісу:
+Найпоширеніша, але також широкомасштабна проблема з багатомережевими установками — це непрацююче балансування навантаження між кластерами. Зазвичай це проявляється в тому, що ви бачите відповіді тільки від кластерної локального екземпляра сервісу:
 
 {{< text bash >}}
-$ for i in $(seq 10); do kubectl --context=$CTX_CLUSTER1 -n sample exec sleep-dd98b5f48-djwdw -c sleep -- curl -s helloworld:5000/hello; done
+$ for i in $(seq 10); do kubectl --context=$CTX_CLUSTER1 -n sample exec curl-dd98b5f48-djwdw -c curl -- curl -s helloworld:5000/hello; done
 Hello version: v1, instance: helloworld-v1-578dd69f69-j69pf
 Hello version: v1, instance: helloworld-v1-578dd69f69-j69pf
 Hello version: v1, instance: helloworld-v1-578dd69f69-j69pf
@@ -58,9 +58,9 @@ $ kubectl apply --context="${CTX_CLUSTER2}" \
     -f samples/helloworld/helloworld.yaml \
     -l version=v2 -n uninjected-sample
 $ kubectl apply --context="${CTX_CLUSTER1}" \
-    -f samples/sleep/sleep.yaml -n uninjected-sample
+    -f samples/curl/curl.yaml -n uninjected-sample
 $ kubectl apply --context="${CTX_CLUSTER2}" \
-    -f samples/sleep/sleep.yaml -n uninjected-sample
+    -f samples/curl/curl.yaml -n uninjected-sample
 {{< /text >}}
 
 Перевірте, що є pod helloworld, що працює в `cluster2`, використовуючи прапорець `-o wide`, щоб отримати IP Pod:
@@ -68,8 +68,8 @@ $ kubectl apply --context="${CTX_CLUSTER2}" \
 {{< text bash >}}
 $ kubectl --context="${CTX_CLUSTER2}" -n uninjected-sample get pod -o wide
 NAME                             READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES
+curl-557747455f-jdsd8            1/1     Running   0          41s   10.100.0.2   node-2   <none>           <none>
 helloworld-v2-54df5f84b-z28p5    1/1     Running   0          43s   10.100.0.1   node-1   <none>           <none>
-sleep-557747455f-jdsd8           1/1     Running   0          41s   10.100.0.2   node-2   <none>           <none>
 {{< /text >}}
 
 Занотуйте стовпець `IP` для `helloworld`. У цьому випадку це `10.100.0.1`:
@@ -78,12 +78,12 @@ sleep-557747455f-jdsd8           1/1     Running   0          41s   10.100.0.2
 $ REMOTE_POD_IP=10.100.0.1
 {{< /text >}}
 
-Далі спробуйте надіслати трафік від podʼа `sleep` в `cluster1` безпосередньо на цей IP Pod:
+Далі спробуйте надіслати трафік від podʼа `curl` в `cluster1` безпосередньо на цей IP Pod:
 
 {{< text bash >}}
-$ kubectl exec --context="${CTX_CLUSTER1}" -n uninjected-sample -c sleep \
+$ kubectl exec --context="${CTX_CLUSTER1}" -n uninjected-sample -c curl \
     "$(kubectl get pod --context="${CTX_CLUSTER1}" -n uninjected-sample -l \
-    app=sleep -o jsonpath='{.items[0].metadata.name}')" \
+    app=curl -o jsonpath='{.items[0].metadata.name}')" \
     -- curl -sS $REMOTE_POD_IP:5000/hello
 Hello version: v2, instance: helloworld-v2-54df5f84b-z28p5
 {{< /text >}}
@@ -116,12 +116,12 @@ $ diff \
 
 Якщо ви пройшли через вищезазначені розділи та все ще стикаєтеся з проблемами, то час заглибитися трохи глибше.
 
-Наступні кроки передбачають, що ви дотримуєтеся [перевірки HelloWorld](/docs/setup/install/multicluster/verify/). Перед тим як продовжити, переконайтеся, що як `helloworld`, так і `sleep` розгорнуті в кожному кластері.
+Наступні кроки передбачають, що ви дотримуєтеся [перевірки HelloWorld](/docs/setup/install/multicluster/verify/). Перед тим як продовжити, переконайтеся, що як `helloworld`, так і `curl` розгорнуті в кожному кластері.
 
-З кожного кластера знайдіть точки доступу сервісу `sleep` для `helloworld`:
+З кожного кластера знайдіть точки доступу сервісу `curl` для `helloworld`:
 
 {{< text bash >}}
-$ istioctl --context $CTX_CLUSTER1 proxy-config endpoint sleep-dd98b5f48-djwdw.sample | grep helloworld
+$ istioctl --context $CTX_CLUSTER1 proxy-config endpoint curl-dd98b5f48-djwdw.sample | grep helloworld
 {{< /text >}}
 
 Інформація для усунення неполадок відрізняється залежно від того, який кластер є джерелом трафіку:
@@ -131,7 +131,7 @@ $ istioctl --context $CTX_CLUSTER1 proxy-config endpoint sleep-dd98b5f48-djwdw.s
 {{< tab name="Основний кластер" category-value="primary" >}}
 
 {{< text bash >}}
-$ istioctl --context $CTX_CLUSTER1 proxy-config endpoint sleep-dd98b5f48-djwdw.sample | grep helloworld
+$ istioctl --context $CTX_CLUSTER1 proxy-config endpoint curl-dd98b5f48-djwdw.sample | grep helloworld
 10.0.0.11:5000                   HEALTHY     OK                outbound|5000||helloworld.sample.svc.cluster.local
 {{< /text >}}
 
@@ -151,7 +151,7 @@ $ kubectl get secrets --context=$CTX_CLUSTER1 -n istio-system -l "istio/multiClu
 {{< tab name="Віддалений кластер" category-value="remote" >}}
 
 {{< text bash >}}
-$ istioctl --context $CTX_CLUSTER2 proxy-config endpoint sleep-dd98b5f48-djwdw.sample | grep helloworld
+$ istioctl --context $CTX_CLUSTER2 proxy-config endpoint curl-dd98b5f48-djwdw.sample | grep helloworld
 10.0.1.11:5000                   HEALTHY     OK                outbound|5000||helloworld.sample.svc.cluster.local
 {{< /text >}}
 
@@ -175,7 +175,7 @@ $ kubectl get secrets --context=$CTX_CLUSTER1 -n istio-system -l "istio/multiClu
 Кроки для Основного та Віддаленого кластерів все ще застосовуються для багатомережевих установок, хоча багатомережеве середовище має додатковий випадок:
 
 {{< text bash >}}
-$ istioctl --context $CTX_CLUSTER1 proxy-config endpoint sleep-dd98b5f48-djwdw.sample | grep helloworld
+$ istioctl --context $CTX_CLUSTER1 proxy-config endpoint curl-dd98b5f48-djwdw.sample | grep helloworld
 10.0.5.11:5000                   HEALTHY     OK                outbound|5000||helloworld.sample.svc.cluster.local
 10.0.6.13:5000                   HEALTHY     OK                outbound|5000||helloworld.sample.svc.cluster.local
 {{< /text >}}
@@ -204,7 +204,7 @@ istio-eastwestgateway    LoadBalancer   10.8.17.119   <PENDING>        15021:317
 На podʼі-джерелі перевірте метадані проксі.
 
 {{< text bash >}}
-$ kubectl get pod $SLEEP_POD_NAME \
+$ kubectl get pod $CURL_POD_NAME \
   -o jsonpath="{.spec.containers[*].env[?(@.name=='ISTIO_META_NETWORK')].value}"
 {{< /text >}}
 

content/uk/docs/ops/diagnostic-tools/proxy-cmd/index.md

@@ -380,17 +380,17 @@ $ istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-7d6874b48
 
 Перевірка підключення до Istiod є корисним кроком для усунення проблем. Кожен контейнер проксі в сервісній мережі повинен мати змогу спілкуватися з Istiod. Це можна зробити кількома простими кроками:
 
-1. Створіть под `sleep`:
+1. Створіть под `curl`:
 
     {{< text bash >}}
     $ kubectl create namespace foo
-    $ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
+    $ kubectl apply -f <(istioctl kube-inject -f samples/curl/curl.yaml) -n foo
     {{< /text >}}
 
 2. Перевірте підключення до Istiod за допомогою `curl`. Наступний приклад викликає API реєстрації v1 з використанням стандартних параметрів конфігурації Istiod і увімкненим взаємним TLS:
 
     {{< text bash >}}
-    $ kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl -sS istiod.istio-system:15014/version
+    $ kubectl exec $(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name}) -c curl -n foo -- curl -sS istiod.istio-system:15014/version
     {{< /text >}}
 
 Ви повинні отримати відповідь, яка містить версію Istiod.

content/uk/docs/ops/integrations/spire/index.md

@@ -133,7 +133,7 @@ EOF
     {{< text bash >}}
     $ kubectl exec -n spire "$SPIRE_SERVER_POD" -- \
     /opt/spire/bin/spire-server entry create \
-        -spiffeID spiffe://example.org/ns/default/sa/sleep \
+        -spiffeID spiffe://example.org/ns/default/sa/curl \
         -parentID spiffe://example.org/ns/spire/sa/spire-agent \
         -selector k8s:ns:default \
         -selector k8s:pod-label:spiffe.io/spire-managed-identity:true \
@@ -157,7 +157,6 @@ EOF
       meshConfig:
         trustDomain: example.org
       values:
-        global:
         # Це використовується для налаштування шаблону sidecar.
         # Додає як мітку, щоб вказати, що SPIRE повинен керувати
         # ідентичністю цього pod, так і монтуванням драйвера CSI.
@@ -249,8 +248,8 @@ EOF
 
 1. Розгорніть приклад навантаження:
 
-    {{< text syntax=bash snip_id=apply_sleep >}}
-    $ istioctl kube-inject --filename @samples/security/spire/sleep-spire.yaml@ | kubectl apply -f -
+    {{< text syntax=bash snip_id=apply_curl >}}
+    $ istioctl kube-inject --filename @samples/security/spire/curl-spire.yaml@ | kubectl apply -f -
     {{< /text >}}
 
     Окрім необхідності мітки `spiffe.io/spire-managed-identity`, навантаження потребуватиме тому SPIFFE CSI Driver для доступу до сокета агента SPIRE. Для цього ви можете скористатися шаблоном анотації podʼа `spire` з розділу [Встановлення Istio](#install-istio) або додати том CSI до специфікації розгортання вашого навантаження. Обидва ці варіанти виділені в наступному прикладі:
@@ -259,24 +258,24 @@ EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
-      name: sleep
+      name: curl
     spec:
       replicas: 1
       selector:
           matchLabels:
-            app: sleep
+            app: curl
       template:
           metadata:
             labels:
-              app: sleep
+              app: curl
             # Впроваджує власний шаблон користувача sidecar
             annotations:
                 inject.istio.io/templates: "sidecar,spire"
           spec:
             terminationGracePeriodSeconds: 0
-            serviceAccountName: sleep
+            serviceAccountName: curl
             containers:
-            - name: sleep
+            - name: curl
               image: curlimages/curl
               command: ["/bin/sleep", "3650d"]
               imagePullPolicy: IfNotPresent
@@ -315,7 +314,7 @@ JWT-SVID TTL     : default
 Selector         : k8s:pod-uid:88b71387-4641-4d9c-9a89-989c88f7509d
 
 Entry ID         : af7b53dc-4cc9-40d3-aaeb-08abbddd8e54
-SPIFFE ID        : spiffe://example.org/ns/default/sa/sleep
+SPIFFE ID        : spiffe://example.org/ns/default/sa/curl
 Parent ID        : spiffe://example.org/spire/agent/k8s_psat/demo-cluster/bea19580-ae04-4679-a22e-472e18ca4687
 Revision         : 0
 X509-SVID TTL    : default
@@ -338,14 +337,14 @@ istiod-989f54d9c-sg7sn                  1/1     Running   0          45s
 
 1. Отримайте інформацію про pod:
 
-    {{< text syntax=bash snip_id=set_sleep_pod_var >}}
-    $ SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath="{.items[0].metadata.name}")
+    {{< text syntax=bash snip_id=set_curl_pod_var >}}
+    $ CURL_POD=$(kubectl get pod -l app=curl -o jsonpath="{.items[0].metadata.name}")
     {{< /text >}}
 
-1. Отримайте документ ідентичності SVID для `sleep` за допомогою команди istioctl proxy-config secret:
+1. Отримайте документ ідентичності SVID для `curl` за допомогою команди istioctl proxy-config secret:
 
-    {{< text syntax=bash snip_id=get_sleep_svid >}}
-    $ istioctl proxy-config secret "$SLEEP_POD" -o json | jq -r \
+    {{< text syntax=bash snip_id=get_curl_svid >}}
+    $ istioctl proxy-config secret "$CURL_POD" -o json | jq -r \
     ʼ.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytesʼ | base64 --decode > chain.pem
     {{< /text >}}
 
@@ -353,7 +352,7 @@ istiod-989f54d9c-sg7sn                  1/1     Running   0          45s
 
     {{< text syntax=bash snip_id=get_svid_subject >}}
     $ openssl x509 -in chain.pem -text | grep SPIRE
-        Subject: C = US, O = SPIRE, CN = sleep-5f4d47c948-njvpk
+        Subject: C = US, O = SPIRE, CN = curl-5f4d47c948-njvpk
     {{< /text >}}
 
 ## Федерація SPIFFE {#spiffe-federation}

content/uk/docs/releases/supported-releases/index.md

@@ -56,14 +56,14 @@ test: n/a
 ## Підтримувані релізи без відомих загальних вразливостей (CVE) {#supported-releases-without-known-common-vulnerabilities-and-exposures-cves}
 
 {{< warning >}}
-Istio не гарантує, що мажорні релізи, які виходять за межі вікна підтримки, мають всі відомі CVE виправленими. Будь ласка, дотримуйтеся останніх версій та використовуйте підтримувану версію.
+Istio не гарантує, що мінорні релізи, які виходять за межі вікна підтримки, мають всі відомі CVE виправленими. Будь ласка, дотримуйтеся останніх версій та використовуйте підтримувану версію.
 {{< /warning >}}
 
-| Мажорні релізи | Виправлені версії без відомих CVE |
-|----------------|----------------------------------|
-| 1.23.x         | 1.23.0+                           |
-| 1.22.x         | 1.22.2+                           |
-| 1.21.x         | 1.21.4+                           |
+| Мінорні релізи | Виправлені версії без відомих CVE |
+|----------------|-----------------------------------|
+| 1.24.x         | 1.24.0+                           |
+| 1.23.x         | 1.23.2+                           |
+| 1.22.x         | 1.22.5+                           |
 
 ## Підтримувані версії Envoy {#supported-envoy-versions}
 
@@ -73,8 +73,8 @@ Data plane Istio базується на [Envoy](https://github.com/envoyproxy/e
 
 | Версія Istio | Гілка релізу Envoy |
 |--------------|--------------------|
+| 1.24.x       | release/v1.34      |
 | 1.23.x       | release/v1.31      |
 | 1.22.x       | release/v1.30      |
-| 1.21.x       | release/v1.29      |
 
 Ви можете знайти точний коміт Envoy, який використовується Istio [в репозиторії `istio/proxy`](https://github.com/istio/proxy/blob/{{< source_branch_name >}}/WORKSPACE#L26): шукайте змінну `ENVOY_SHA`.

content/uk/docs/setup/_index.md

@@ -8,6 +8,8 @@ aliases:
     - /uk/docs/setup/kubernetes/quick-start.html
     - /uk/docs/setup/kubernetes/download-release/
     - /uk/docs/setup/kubernetes/download/
+    - /uk/docs/setup/install/operator/
+    - /latest/uk/docs/setup/install/operator/
 keywords: [kubernetes,install,quick-start,setup,installation]
 test: table-of-contents
 ---

content/uk/docs/setup/additional-setup/cni/index.md

@@ -19,7 +19,7 @@ Istio CNI агент на вузлі є **обов’язковим** в {{< glo
 Цей посібник зосереджений на використанні Istio CNI агента на вузлі як необов’язкової частини sidecar режиму панелі даних. Ознайомтеся з [документацією по ambient режиму](/docs/ambient/) для отримання інформації про використання ambient режиму панелі даних.
 
 {{< tip >}}
-Примітка: Istio CNI агент на вузлі _не замінює_ наявний у вашому кластері {{< gloss="cni" >}}CNI{{< /gloss >}}. Серед іншого, він встановлює _ланцюговий_ CNI втулок, який розрахований на накладення на інший, раніше встановлений основний інтерфейс CNI, наприклад, [Calico](https://docs.projectcalico.org), або CNI кластера, який використовує ваш хмарний провайдер. Дивіться [сумісність з іншими CNI]( /docs/setup/additional-setup/cni/#compatibility-with-other-cnis) для отримання додаткової інформації.
+Примітка: Istio CNI агент на вузлі _не замінює_ наявний у вашому кластері {{< gloss="cni" >}}CNI{{< /gloss >}}. Серед іншого, він встановлює _ланцюговий_ CNI втулок, який розрахований на накладення на інший, раніше встановлений основний інтерфейс CNI, наприклад, [Calico](https://docs.projectcalico.org), або CNI кластера, який використовує ваш хмарний провайдер. Дивіться [сумісність з іншими CNI](/docs/setup/additional-setup/cni/#compatibility-with-other-cnis) для отримання додаткової інформації.
 {{< /tip >}}
 
 Слідуйте цьому посібнику, щоб встановити, налаштувати та використовувати Istio CNI агент на вузлі разом з sidecar режимом панелі даних.

content/uk/docs/setup/additional-setup/customize-installation/index.md

@@ -43,7 +43,7 @@ $ istioctl install --set values.pilot.traceSampling=0.1
 Якщо ви хочете налаштувати параметри ресурсів Kubernetes, використовуйте API `IstioOperator`, як описано в розділі [Налаштування параметрів Kubernetes](/docs/setup/additional-setup/customize-installation/#customize-kubernetes-settings).
 {{< /tip >}}
 
-### Визначення компоненту Istio {#identify-istio-component}
+### Визначення компонента Istio {#identify-istio-component}
 
 API `IstioOperator` визначає компоненти, як показано в таблиці нижче:
 

content/uk/docs/setup/additional-setup/dual-stack/index.md

@@ -109,37 +109,37 @@ values:
     $ kubectl apply --namespace ipv6 -f @samples/tcp-echo/tcp-echo-ipv6.yaml@
     {{< /text >}}
 
-1. Розгорніть [sleep]({{< github_tree >}}/samples/sleep) зразок програми для використання як джерела тестових запитів.
+1. Розгорніть [curl]({{< github_tree >}}/samples/curl) зразок програми для використання як джерела тестових запитів.
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
 1. Перевірте, чи трафік досягає podʼів dual-stack:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}')" -- sh -c "echo dualstack | nc tcp-echo.dual-stack 9000"
+    $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}')" -- sh -c "echo dualstack | nc tcp-echo.dual-stack 9000"
     hello dualstack
     {{< /text >}}
 
 1. Перевірте, чи трафік досягає podʼів IPv4:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}')" -- sh -c "echo ipv4 | nc tcp-echo.ipv4 9000"
+    $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}')" -- sh -c "echo ipv4 | nc tcp-echo.ipv4 9000"
     hello ipv4
     {{< /text >}}
 
 1. Перевірте, чи трафік досягає podʼів IPv6:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}')" -- sh -c "echo ipv6 | nc tcp-echo.ipv6 9000"
+    $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}')" -- sh -c "echo ipv6 | nc tcp-echo.ipv6 9000"
     hello ipv6
     {{< /text >}}
 
 1. Перевірте слухачів envoy:
 
     {{< text syntax=bash snip_id=none >}}
-    $ istioctl proxy-config listeners "$(kubectl get pod -n dual-stack -l app=tcp-echo -o jsonpath='{.items[0].metadata.name}')" -n dual-stack --port 9000
+    $ istioctl proxy-config listeners "$(kubectl get pod -n dual-stack -l app=tcp-echo -o jsonpath='{.items[0].metadata.name}')" -n dual-stack --port 9000 -ojson | jq '.[] | {name: .name, address: .address, additionalAddresses: .additionalAddresses}'
     {{< /text >}}
 
     Ви побачите, що слухачі тепер привʼязані до кількох адрес, але тільки для сервісів dual-stack. Інші сервіси будуть слухати тільки на одній IP-адресі.
@@ -166,6 +166,10 @@ values:
 
 1. Перевірте, чи віртуальні вхідні адреси налаштовані на прослуховування як `0.0.0.0`, так і `[::]`.
 
+    {{< text syntax=bash snip_id=none >}}
+    $ istioctl proxy-config listeners "$(kubectl get pod -n dual-stack -l app=tcp-echo -o jsonpath='{.items[0].metadata.name}')" -n dual-stack -o json | jq '.[] | select(.name=="virtualInbound") | {name: .name, address: .address, additionalAddresses: .additionalAddresses}'
+    {{< /text >}}
+
     {{< text syntax=json snip_id=none >}}
     "name": "virtualInbound",
     "address": {
@@ -189,7 +193,7 @@ values:
 2. Перевірте, чи точки доступу envoy налаштовані на маршрутизацію як до IPv4, так і до IPv6:
 
     {{< text syntax=bash snip_id=none >}}
-    $ istioctl proxy-config endpoints "$(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}')" --port 9000
+    $ istioctl proxy-config endpoints "$(kubectl get pod -l app=curl -o jsonpath='{.items[0].metadata.name}')" --port 9000
     ENDPOINT                 STATUS      OUTLIER CHECK     CLUSTER
     10.244.0.19:9000         HEALTHY     OK                outbound|9000||tcp-echo.ipv4.svc.cluster.local
     10.244.0.26:9000         HEALTHY     OK                outbound|9000||tcp-echo.dual-stack.svc.cluster.local
@@ -204,6 +208,6 @@ values:
 1. Очищення просторів імен і розгортання застосунків
 
     {{< text bash >}}
-    $ kubectl delete -f @samples/sleep/sleep.yaml@
+    $ kubectl delete -f @samples/curl/curl.yaml@
     $ kubectl delete ns dual-stack ipv4 ipv6
     {{< /text >}}

content/uk/docs/setup/additional-setup/sidecar-injection/index.md

@@ -37,19 +37,19 @@ Sidecar проксі можна автоматично додавати до в
 
 #### Розгортання застосунку {#deploying-an-app}
 
-Розгорніть застосунок sleep. Переконайтесь, що як deployment, так і pod мають один контейнер.
+Розгорніть застосунок curl. Переконайтесь, що як deployment, так і pod мають один контейнер.
 
 {{< text bash >}}
-$ kubectl apply -f @samples/sleep/sleep.yaml@
+$ kubectl apply -f @samples/curl/curl.yaml@
 $ kubectl get deployment -o wide
 NAME    READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                    SELECTOR
-sleep   1/1     1            1           12s   sleep        curlimages/curl           app=sleep
+curl    1/1     1            1           12s   curl         curlimages/curl           app=curl
 {{< /text >}}
 
 {{< text bash >}}
 $ kubectl get pod
 NAME                    READY   STATUS    RESTARTS   AGE
-sleep-8f795f47d-hdcgs   1/1     Running   0          42s
+curl-8f795f47d-hdcgs    1/1     Running   0          42s
 {{< /text >}}
 
 Позначте простір імен `default` міткою `istio-injection=enabled`.
@@ -65,18 +65,18 @@ default              Active   5m9s    enabled
 Інʼєкція відбувається під час створення podʼа. Вбийте запущений pod і переконайтесь, що новий pod створено з впровадженим sidecar проксі. Початковий pod має `1/1 READY`, а контейнер з доданим sidecar проксі має `2/2 READY`.
 
 {{< text bash >}}
-$ kubectl delete pod -l app=sleep
-$ kubectl get pod -l app=sleep
-pod "sleep-776b7bcdcd-7hpnk" deleted
+$ kubectl delete pod -l app=curl
+$ kubectl get pod -l app=curl
+pod "curl-776b7bcdcd-7hpnk" deleted
 NAME                     READY     STATUS        RESTARTS   AGE
-sleep-776b7bcdcd-7hpnk   1/1       Terminating   0          1m
-sleep-776b7bcdcd-bhn9m   2/2       Running       0          7s
+curl-776b7bcdcd-7hpnk    1/1       Terminating   0          1m
+curl-776b7bcdcd-bhn9m    2/2       Running       0          7s
 {{< /text >}}
 
 Перегляньте детальний стан podʼа з інʼєкцією. Ви повинні побачити доданий контейнер `istio-proxy` та відповідні томи.
 
 {{< text bash >}}
-$ kubectl describe pod -l app=sleep
+$ kubectl describe pod -l app=curl
 ...
 Events:
   Type    Reason     Age   From               Message
@@ -85,8 +85,8 @@ Events:
   Normal  Created    11s   kubelet            Created container istio-init
   Normal  Started    11s   kubelet            Started container istio-init
   ...
-  Normal  Created    10s   kubelet            Created container sleep
-  Normal  Started    10s   kubelet            Started container sleep
+  Normal  Created    10s   kubelet            Created container curl
+  Normal  Started    10s   kubelet            Started container curl
   ...
   Normal  Created    9s    kubelet            Created container istio-proxy
   Normal  Started    8s    kubelet            Started container istio-proxy
@@ -96,13 +96,13 @@ Events:
 
 {{< text bash >}}
 $ kubectl label namespace default istio-injection-
-$ kubectl delete pod -l app=sleep
+$ kubectl delete pod -l app=curl
 $ kubectl get pod
 namespace/default labeled
-pod "sleep-776b7bcdcd-bhn9m" deleted
+pod "curl-776b7bcdcd-bhn9m" deleted
 NAME                     READY     STATUS        RESTARTS   AGE
-sleep-776b7bcdcd-bhn9m   2/2       Terminating   0          2m
-sleep-776b7bcdcd-gmvnr   1/1       Running       0          2s
+curl-776b7bcdcd-bhn9m    2/2       Terminating   0          2m
+curl-776b7bcdcd-gmvnr    1/1       Running       0          2s
 {{< /text >}}
 
 #### Контроль політики інʼєкції {#controlling-the-injection-policy}
@@ -134,10 +134,10 @@ sleep-776b7bcdcd-gmvnr   1/1       Running       0          2s
 Для ручної інʼєкції в deployment використовуйте команду [`istioctl kube-inject`](/docs/reference/commands/istioctl/#istioctl-kube-inject):
 
 {{< text bash >}}
-$ istioctl kube-inject -f @samples/sleep/sleep.yaml@ | kubectl apply -f -
-serviceaccount/sleep created
-service/sleep created
-deployment.apps/sleep created
+$ istioctl kube-inject -f @samples/curl/curl.yaml@ | kubectl apply -f -
+serviceaccount/curl created
+service/curl created
+deployment.apps/curl created
 {{< /text >}}
 
 Стандартно буде використовуватися конфігурація в кластері. Альтернативно інʼєкція може бути виконана з використанням локальних копій конфігурації.
@@ -155,19 +155,19 @@ $ istioctl kube-inject \
     --injectConfigFile inject-config.yaml \
     --meshConfigFile mesh-config.yaml \
     --valuesFile inject-values.yaml \
-    --filename @samples/sleep/sleep.yaml@ \
+    --filename @samples/curl/curl.yaml@ \
     | kubectl apply -f -
-serviceaccount/sleep created
-service/sleep created
-deployment.apps/sleep created
+serviceaccount/curl created
+service/curl created
+deployment.apps/curl created
 {{< /text >}}
 
-Перевірте, що sidecar було додано в pod sleep зі значенням `2/2` у колонці READY.
+Перевірте, що sidecar було додано в pod curl зі значенням `2/2` у колонці READY.
 
 {{< text bash >}}
-$ kubectl get pod -l app=sleep
+$ kubectl get pod -l app=curl
 NAME                     READY   STATUS    RESTARTS   AGE
-sleep-64c6f57bc8-f5n4x   2/2     Running   0          24s
+curl-64c6f57bc8-f5n4x    2/2     Running   0          24s
 {{< /text >}}
 
 ## Налаштування інʼєкції {#customizing-injection}
@@ -198,7 +198,7 @@ spec:
     lifecycle:
       preStop:
         exec:
-          command: ["sleep", "10"]
+          command: ["curl", "10"]
   volumes:
   - name: certs
     secret:

content/uk/docs/setup/install/external-controlplane/index.md

@@ -190,15 +190,16 @@ $ export REMOTE_CLUSTER_NAME=<your remote cluster name>
 
     {{< text bash >}}
     $ kubectl create namespace external-istiod --context="${CTX_REMOTE_CLUSTER}"
-    $ istioctl manifest generate -f remote-config-cluster.yaml --set values.defaultRevision=default | kubectl apply --context="${CTX_REMOTE_CLUSTER}" -f -
+    $ istioctl install -f remote-config-cluster.yaml --set values.defaultRevision=default --context="${CTX_REMOTE_CLUSTER}"
     {{< /text >}}
 
 4. Підтвердіть, що конфігурація вебхука інʼєкції для віддаленого кластера була встановлена:
 
     {{< text bash >}}
     $ kubectl get mutatingwebhookconfiguration --context="${CTX_REMOTE_CLUSTER}"
-    NAME                                     WEBHOOKS   AGE
-    istio-sidecar-injector-external-istiod   4          6m24s
+    NAME                                         WEBHOOKS   AGE
+    istio-revision-tag-default-external-istiod   4          2m2s
+    istio-sidecar-injector-external-istiod       4          2m5s
     {{< /text >}}
 
 5. Підтвердіть, що конфігурації вебхуків для валідації на віддаленому кластері були встановлені:
@@ -289,6 +290,7 @@ $ export REMOTE_CLUSTER_NAME=<your remote cluster name>
               value: istio
       values:
         global:
+          externalIstiod: true
           caAddress: $EXTERNAL_ISTIOD_ADDR:15012
           istioNamespace: external-istiod
           operatorManageWebhooks: true
@@ -448,28 +450,28 @@ $ export REMOTE_CLUSTER_NAME=<your remote cluster name>
     $ kubectl label --context="${CTX_REMOTE_CLUSTER}" namespace sample istio-injection=enabled
     {{< /text >}}
 
-2. Розгорніть зразки `helloworld` (версія `v1`) та `sleep`:
+2. Розгорніть зразки `helloworld` (версія `v1`) та `curl`:
 
     {{< text bash >}}
     $ kubectl apply -f @samples/helloworld/helloworld.yaml@ -l service=helloworld -n sample --context="${CTX_REMOTE_CLUSTER}"
     $ kubectl apply -f @samples/helloworld/helloworld.yaml@ -l version=v1 -n sample --context="${CTX_REMOTE_CLUSTER}"
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n sample --context="${CTX_REMOTE_CLUSTER}"
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n sample --context="${CTX_REMOTE_CLUSTER}"
     {{< /text >}}
 
-3. Зачекайте кілька секунд, поки podʼи `helloworld` та `sleep` запустяться з інтегрованими sidecar контейнерами:
+3. Зачекайте кілька секунд, поки podʼи `helloworld` та `curl` запустяться з інтегрованими sidecar контейнерами:
 
     {{< text bash >}}
     $ kubectl get pod -n sample --context="${CTX_REMOTE_CLUSTER}"
     NAME                             READY   STATUS    RESTARTS   AGE
+    curl-64d7d56698-wqjnm            2/2     Running   0          9s
     helloworld-v1-776f57d5f6-s7zfc   2/2     Running   0          10s
-    sleep-64d7d56698-wqjnm           2/2     Running   0          9s
     {{< /text >}}
 
-4. Надішліть запит з podʼа `sleep` до сервіса `helloworld`:
+4. Надішліть запит з podʼа `curl` до сервіса `helloworld`:
 
     {{< text bash >}}
-    $ kubectl exec --context="${CTX_REMOTE_CLUSTER}" -n sample -c sleep \
-        "$(kubectl get pod --context="${CTX_REMOTE_CLUSTER}" -n sample -l app=sleep -o jsonpath='{.items[0].metadata.name}')" \
+    $ kubectl exec --context="${CTX_REMOTE_CLUSTER}" -n sample -c curl \
+        "$(kubectl get pod --context="${CTX_REMOTE_CLUSTER}" -n sample -l app=curl -o jsonpath='{.items[0].metadata.name}')" \
         -- curl -sS helloworld.sample:5000/hello
     Hello version: v1, instance: helloworld-v1-776f57d5f6-s7zfc
     {{< /text >}}
@@ -715,7 +717,7 @@ $ export SECOND_CLUSTER_NAME=<your second remote cluster name>
 4. Встановіть конфігурацію у віддаленому кластері:
 
     {{< text bash >}}
-    $ istioctl manifest generate -f second-remote-cluster.yaml | kubectl apply --context="${CTX_SECOND_CLUSTER}" -f -
+    $ istioctl install -f second-remote-cluster.yaml --context="${CTX_SECOND_CLUSTER}"
     {{< /text >}}
 
 5. Переконайтеся, що конфігурація веб-хука інʼєкції у віддаленому кластері була встановлена:
@@ -790,28 +792,28 @@ $ export SECOND_CLUSTER_NAME=<your second remote cluster name>
     $ kubectl label --context="${CTX_SECOND_CLUSTER}" namespace sample istio-injection=enabled
     {{< /text >}}
 
-1. Розгорніть зразки `helloworld` (`v2`) та `sleep`:
+1. Розгорніть зразки `helloworld` (`v2`) та `curl`:
 
     {{< text bash >}}
     $ kubectl apply -f @samples/helloworld/helloworld.yaml@ -l service=helloworld -n sample --context="${CTX_SECOND_CLUSTER}"
     $ kubectl apply -f @samples/helloworld/helloworld.yaml@ -l version=v2 -n sample --context="${CTX_SECOND_CLUSTER}"
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n sample --context="${CTX_SECOND_CLUSTER}"
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n sample --context="${CTX_SECOND_CLUSTER}"
     {{< /text >}}
 
-1. Зачекайте кілька секунд, поки контейнери `helloworld` та `sleep` запустяться з впровадженими sidecar контейнерами:
+1. Зачекайте кілька секунд, поки контейнери `helloworld` та `curl` запустяться з впровадженими sidecar контейнерами:
 
     {{< text bash >}}
     $ kubectl get pod -n sample --context="${CTX_SECOND_CLUSTER}"
     NAME                            READY   STATUS    RESTARTS   AGE
+    curl-557747455f-wtdbr           2/2     Running   0          9s
     helloworld-v2-54df5f84b-9hxgw   2/2     Running   0          10s
-    sleep-557747455f-wtdbr          2/2     Running   0          9s
     {{< /text >}}
 
-1. Надішліть запит з контейнера `sleep` до сервісу `helloworld`:
+1. Надішліть запит з контейнера `curl` до сервісу `helloworld`:
 
     {{< text bash >}}
-    $ kubectl exec --context="${CTX_SECOND_CLUSTER}" -n sample -c sleep \
-        "$(kubectl get pod --context="${CTX_SECOND_CLUSTER}" -n sample -l app=sleep -o jsonpath='{.items[0].metadata.name}')" \
+    $ kubectl exec --context="${CTX_SECOND_CLUSTER}" -n sample -c curl \
+        "$(kubectl get pod --context="${CTX_SECOND_CLUSTER}" -n sample -l app=curl -o jsonpath='{.items[0].metadata.name}')" \
         -- curl -sS helloworld.sample:5000/hello
     Hello version: v2, instance: helloworld-v2-54df5f84b-9hxgw
     {{< /text >}}
@@ -833,7 +835,7 @@ $ export SECOND_CLUSTER_NAME=<your second remote cluster name>
 
 {{< text bash >}}
 $ kubectl delete -f external-istiod-gw.yaml --context="${CTX_EXTERNAL_CLUSTER}"
-$ istioctl uninstall -y --purge --context="${CTX_EXTERNAL_CLUSTER}"
+$ istioctl uninstall -y --purge -f external-istiod.yaml --context="${CTX_EXTERNAL_CLUSTER}"
 $ kubectl delete ns istio-system external-istiod --context="${CTX_EXTERNAL_CLUSTER}"
 $ rm controlplane-gateway.yaml external-istiod.yaml external-istiod-gw.yaml
 {{< /text >}}
@@ -842,7 +844,7 @@ $ rm controlplane-gateway.yaml external-istiod.yaml external-istiod-gw.yaml
 
 {{< text bash >}}
 $ kubectl delete ns sample --context="${CTX_REMOTE_CLUSTER}"
-$ istioctl manifest generate -f remote-config-cluster.yaml --set values.defaultRevision=default | kubectl delete --context="${CTX_REMOTE_CLUSTER}" -f -
+$ istioctl uninstall -y --purge -f remote-config-cluster.yaml --set values.defaultRevision=default --context="${CTX_REMOTE_CLUSTER}"
 $ kubectl delete ns external-istiod --context="${CTX_REMOTE_CLUSTER}"
 $ rm remote-config-cluster.yaml istio-ingressgateway.yaml
 $ rm istio-egressgateway.yaml eastwest-gateway-1.yaml || true
@@ -852,7 +854,7 @@ $ rm istio-egressgateway.yaml eastwest-gateway-1.yaml || true
 
 {{< text bash >}}
 $ kubectl delete ns sample --context="${CTX_SECOND_CLUSTER}"
-$ istioctl manifest generate -f second-remote-cluster.yaml | kubectl delete --context="${CTX_SECOND_CLUSTER}" -f -
+$ istioctl uninstall -y --purge -f second-remote-cluster.yaml --context="${CTX_SECOND_CLUSTER}"
 $ kubectl delete ns external-istiod --context="${CTX_SECOND_CLUSTER}"
 $ rm second-remote-cluster.yaml eastwest-gateway-2.yaml
 {{< /text >}}

content/uk/docs/setup/install/helm/index.md

@@ -145,14 +145,13 @@ $ helm install <release> <chart> --namespace <namespace> --create-namespace [--s
 
 ### Міграція з установок без Helm {#migrating-from-non-helm-installations}
 
-Якщо ви переходите з версії Istio, встановленої за допомогою `istioctl` або Operator, на Helm (Istio 1.5 або раніше), вам потрібно видалити ваші поточні ресурси панелі управління Istio та перевстановити Istio за допомогою Helm, як описано вище. При видаленні поточної установки Istio не слід видаляти Custom Resource Definitions (CRDs) Istio, оскільки це може призвести до втрати ваших власних ресурсів Istio.
+Якщо ви переходите з версії Istio, встановленої за допомогою `istioctl`, на Helm (Istio 1.5 або раніше), вам потрібно видалити ваші поточні ресурси панелі управління Istio та перевстановити Istio за допомогою Helm, як описано вище. При видаленні поточної установки Istio не слід видаляти Custom Resource Definitions (CRDs) Istio, оскільки це може призвести до втрати ваших власних ресурсів Istio.
 
 {{< warning >}}
 Рекомендується зробити резервну копію ваших ресурсів Istio за допомогою наведених вище кроків перед видаленням поточної установки Istio у вашому кластері.
 {{< /warning >}}
 
-Ви можете слідувати крокам, наведеним у [посібнику з видалення Istioctl](/docs/setup/install/istioctl#uninstall-istio) або
-[посібнику з видалення Operator](/docs/setup/install/operator/#uninstall) залежно від вашого методу установки.
+Ви можете слідувати крокам, наведеним у [посібнику з видалення Istioctl](/docs/setup/install/istioctl#uninstall-istio).
 
 ### Видалення {#uninstall}
 

content/uk/docs/setup/install/multicluster/primary-remote/index.md

@@ -42,16 +42,17 @@ spec:
       multiCluster:
         clusterName: cluster1
       network: network1
+      externalIstiod: true
 EOF
 {{< /text >}}
 
 Застосуйте конфігурацію до `cluster1`:
 
 {{< text bash >}}
-$ istioctl install --set values.pilot.env.EXTERNAL_ISTIOD=true --context="${CTX_CLUSTER1}" -f cluster1.yaml
+$ istioctl install --context="${CTX_CLUSTER1}" -f cluster1.yaml
 {{< /text >}}
 
-Зверніть увагу, що `values.pilot.env.EXTERNAL_ISTIOD` встановлено на `true`. Це дозволяє панелі управління, встановленій у `cluster1`, також виконувати роль зовнішньої панелі управління для інших віддалених кластерів. Коли цю функцію увімкнено, `istiod` намагатиметься отримати блокування лідерства і, відповідно, керувати [відповідно анотованими](#set-the-control-plane-cluster-for-cluster2) віддаленими кластерами, які будуть до нього приєднані (в цьому випадку, `cluster2`).
+Зверніть увагу, що `values.global.externalIstiod` встановлено на `true`. Це дозволяє панелі управління, встановленій у `cluster1`, також виконувати роль зовнішньої панелі управління для інших віддалених кластерів. Коли цю функцію увімкнено, `istiod` намагатиметься отримати блокування лідерства і, відповідно, керувати [відповідно анотованими](#set-the-control-plane-cluster-for-cluster2) віддаленими кластерами, які будуть до нього приєднані (в цьому випадку, `cluster2`).
 
 ## Встановлення шлюзу схід-захід у `cluster1` {#install-the-east-west-gateway-in-cluster1}
 

content/uk/docs/setup/install/multicluster/primary-remote_multi-network/index.md

@@ -48,16 +48,17 @@ spec:
       multiCluster:
         clusterName: cluster1
       network: network1
+      externalIstiod: true
 EOF
 {{< /text >}}
 
 Застосуйте конфігурацію до `cluster1`:
 
 {{< text bash >}}
-$ istioctl install --set values.pilot.env.EXTERNAL_ISTIOD=true --context="${CTX_CLUSTER1}" -f cluster1.yaml
+$ istioctl install --context="${CTX_CLUSTER1}" -f cluster1.yaml
 {{< /text >}}
 
-Зверніть увагу, що параметр `values.pilot.env.EXTERNAL_ISTIOD` встановлено як `true`. Це дозволяє панелі управління, встановленій в `cluster1`, також слугувати зовнішньою панеллю управління для інших віддалених кластерів. Коли цю функцію увімкнено, `istiod` намагатиметься отримати блокування лідерства і, відповідно, керувати [належним чином позначеними](#set-the-control-plane-cluster-for-cluster2) віддаленими кластерами, які будуть приєднані до нього (у цьому випадку, `cluster2`).
+Зверніть увагу, що параметр `values.global.externalIstiod` встановлено як `true`. Це дозволяє панелі управління, встановленій в `cluster1`, також слугувати зовнішньою панеллю управління для інших віддалених кластерів. Коли цю функцію увімкнено, `istiod` намагатиметься отримати блокування лідерства і, відповідно, керувати [належним чином позначеними](#set-the-control-plane-cluster-for-cluster2) віддаленими кластерами, які будуть приєднані до нього (у цьому випадку, `cluster2`).
 
 ## Встановлення шлюзу схід-захід  в `cluster1` {#install-the-east-west-gateway-in-cluster1}
 

content/uk/docs/setup/install/multicluster/verify/index.md

@@ -12,7 +12,7 @@ owner: istio/wg-environments-maintainers
 
 У цьому посібнику ми розгорнемо застосунок `HelloWorld` `V1` у `cluster1` та `V2` у `cluster2`. При отриманні запиту `HelloWorld` включатиме свою версію у відповідь.
 
-Ми також розгорнемо контейнер `Sleep` в обох кластерах. Ми будемо використовувати ці контейнери як джерело запитів до сервісу `HelloWorld`, імітуючи трафік всередині мережі. Нарешті, після генерації трафіку ми спостерігатимемо, який кластер отримав запити.
+Ми також розгорнемо контейнер `curl` в обох кластерах. Ми будемо використовувати ці контейнери як джерело запитів до сервісу `HelloWorld`, імітуючи трафік всередині мережі. Нарешті, після генерації трафіку ми спостерігатимемо, який кластер отримав запити.
 
 ## Розгортання сервісу `HelloWorld` {#deploy-the-helloworld-service}
 
@@ -85,47 +85,47 @@ helloworld-v2-758dd55874-6x4t8  2/2       Running   0          40s
 
 Дочекайтесь, поки статус `helloworld-v2` буде `Running`.
 
-## Розгортання `Sleep` {#deploy-sleep}
+## Розгортання `curl` {#deploy-curl}
 
-Розгорніть застосунок `Sleep` в обох кластерах:
+Розгорніть застосунок `curl` в обох кластерах:
 
 {{< text bash >}}
 $ kubectl apply --context="${CTX_CLUSTER1}" \
-    -f @samples/sleep/sleep.yaml@ -n sample
+    -f @samples/curl/curl.yaml@ -n sample
 $ kubectl apply --context="${CTX_CLUSTER2}" \
-    -f @samples/sleep/sleep.yaml@ -n sample
+    -f @samples/curl/curl.yaml@ -n sample
 {{< /text >}}
 
-Перевірте статус podʼа `Sleep` в `cluster1`:
+Перевірте статус podʼа `curl` в `cluster1`:
 
 {{< text bash >}}
-$ kubectl get pod --context="${CTX_CLUSTER1}" -n sample -l app=sleep
+$ kubectl get pod --context="${CTX_CLUSTER1}" -n sample -l app=curl
 NAME                             READY   STATUS    RESTARTS   AGE
-sleep-754684654f-n6bzf           2/2     Running   0          5s
+curl-754684654f-n6bzf            2/2     Running   0          5s
 {{< /text >}}
 
-Дочекайтесь, поки статус podʼа `Sleep` буде `Running`.
+Дочекайтесь, поки статус podʼа `curl` буде `Running`.
 
-Перевірте статус podʼа `Sleep` в `cluster2`:
+Перевірте статус podʼа `curl` в `cluster2`:
 
 {{< text bash >}}
-$ kubectl get pod --context="${CTX_CLUSTER2}" -n sample -l app=sleep
+$ kubectl get pod --context="${CTX_CLUSTER2}" -n sample -l app=curl
 NAME                             READY   STATUS    RESTARTS   AGE
-sleep-754684654f-dzl9j           2/2     Running   0          5s
+curl-754684654f-dzl9j            2/2     Running   0          5s
 {{< /text >}}
 
-Дочекайтесь, поки статус podʼа `Sleep` буде `Running`.
+Дочекайтесь, поки статус podʼа `curl` буде `Running`.
 
 ## Перевірка міжкластерного трафіку {#verify-cross-cluster-traffic}
 
-Щоб перевірити, чи працює міжкластерне балансування навантаження як очікується, викликайте сервіс `HelloWorld` кілька разів за допомогою podʼа `Sleep`. Щоб забезпечити правильність балансування навантаження, викликайте сервіс `HelloWorld` з усіх кластерів у вашій установці.
+Щоб перевірити, чи працює міжкластерне балансування навантаження як очікується, викликайте сервіс `HelloWorld` кілька разів за допомогою podʼа `curl`. Щоб забезпечити правильність балансування навантаження, викликайте сервіс `HelloWorld` з усіх кластерів у вашій установці.
 
-Відправте один запит з podʼа `Sleep` в `cluster1` до сервісу `HelloWorld`:
+Відправте один запит з podʼа `curl` в `cluster1` до сервісу `HelloWorld`:
 
 {{< text bash >}}
-$ kubectl exec --context="${CTX_CLUSTER1}" -n sample -c sleep \
+$ kubectl exec --context="${CTX_CLUSTER1}" -n sample -c curl \
     "$(kubectl get pod --context="${CTX_CLUSTER1}" -n sample -l \
-    app=sleep -o jsonpath='{.items[0].metadata.name}')" \
+    app=curl -o jsonpath='{.items[0].metadata.name}')" \
     -- curl -sS helloworld.sample:5000/hello
 {{< /text >}}
 
@@ -137,12 +137,12 @@ Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
 ...
 {{< /text >}}
 
-Тепер повторіть цей процес з podʼа `Sleep` в `cluster2`:
+Тепер повторіть цей процес з podʼа `curl` в `cluster2`:
 
 {{< text bash >}}
-$ kubectl exec --context="${CTX_CLUSTER2}" -n sample -c sleep \
+$ kubectl exec --context="${CTX_CLUSTER2}" -n sample -c curl \
     "$(kubectl get pod --context="${CTX_CLUSTER2}" -n sample -l \
-    app=sleep -o jsonpath='{.items[0].metadata.name}')" \
+    app=curl -o jsonpath='{.items[0].metadata.name}')" \
     -- curl -sS helloworld.sample:5000/hello
 {{< /text >}}
 

content/uk/docs/setup/install/multiple-controlplanes/index.md

@@ -171,38 +171,38 @@ test: yes
     $ kubectl label ns app-ns-3 usergroup=usergroup-2 istio.io/rev=usergroup-2
     {{< /text >}}
 
-3. Розгорніть по одному застосунку `sleep` та `httpbin` для кожного простору імен:
+3. Розгорніть по одному застосунку `curl` та `httpbin` для кожного простору імен:
 
     {{< text bash >}}
-    $ kubectl -n app-ns-1 apply -f samples/sleep/sleep.yaml
+    $ kubectl -n app-ns-1 apply -f samples/curl/curl.yaml
     $ kubectl -n app-ns-1 apply -f samples/httpbin/httpbin.yaml
-    $ kubectl -n app-ns-2 apply -f samples/sleep/sleep.yaml
+    $ kubectl -n app-ns-2 apply -f samples/curl/curl.yaml
     $ kubectl -n app-ns-2 apply -f samples/httpbin/httpbin.yaml
-    $ kubectl -n app-ns-3 apply -f samples/sleep/sleep.yaml
+    $ kubectl -n app-ns-3 apply -f samples/curl/curl.yaml
     $ kubectl -n app-ns-3 apply -f samples/httpbin/httpbin.yaml
     {{< /text >}}
 
-4. Зачекайте кілька секунд, поки контейнери `httpbin` та `sleep` запустяться з доданими sidecar контейнерами:
+4. Зачекайте кілька секунд, поки контейнери `httpbin` та `curl` запустяться з доданими sidecar контейнерами:
 
     {{< text bash >}}
     $ kubectl get pods -n app-ns-1
     NAME                      READY   STATUS    RESTARTS   AGE
     httpbin-9dbd644c7-zc2v4   2/2     Running   0          115m
-    sleep-78ff5975c6-fml7c    2/2     Running   0          115m
+    curl-78ff5975c6-fml7c     2/2     Running   0          115m
     {{< /text >}}
 
     {{< text bash >}}
     $ kubectl get pods -n app-ns-2
     NAME                      READY   STATUS    RESTARTS   AGE
     httpbin-9dbd644c7-sd9ln   2/2     Running   0          115m
-    sleep-78ff5975c6-sz728    2/2     Running   0          115m
+    curl-78ff5975c6-sz728     2/2     Running   0          115m
     {{< /text >}}
 
     {{< text bash >}}
     $ kubectl get pods -n app-ns-3
     NAME                      READY   STATUS    RESTARTS   AGE
     httpbin-9dbd644c7-8ll27   2/2     Running   0          115m
-    sleep-78ff5975c6-sg4tq    2/2     Running   0          115m
+    curl-78ff5975c6-sg4tq     2/2     Running   0          115m
     {{< /text >}}
 
 ### Перевірка відповідності між застосунками та панелями управління {#verify-the-application-to-control-plane-mapping}
@@ -213,7 +213,7 @@ test: yes
 $ istioctl ps -i usergroup-1
 NAME                                 CLUSTER        CDS        LDS        EDS        RDS          ECDS         ISTIOD                                  VERSION
 httpbin-9dbd644c7-hccpf.app-ns-1     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-1-5ccc849b5f-wnqd6     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
-sleep-78ff5975c6-9zb77.app-ns-1      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-1-5ccc849b5f-wnqd6     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
+curl-78ff5975c6-9zb77.app-ns-1       Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-1-5ccc849b5f-wnqd6     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
 {{< /text >}}
 
 {{< text bash >}}
@@ -221,16 +221,16 @@ $ istioctl ps -i usergroup-2
 NAME                                 CLUSTER        CDS        LDS        EDS        RDS          ECDS         ISTIOD                                  VERSION
 httpbin-9dbd644c7-vvcqj.app-ns-3     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-2-658d6458f7-slpd9     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
 httpbin-9dbd644c7-xzgfm.app-ns-2     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-2-658d6458f7-slpd9     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
-sleep-78ff5975c6-fthmt.app-ns-2      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-2-658d6458f7-slpd9     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
-sleep-78ff5975c6-nxtth.app-ns-3      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-2-658d6458f7-slpd9     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
+curl-78ff5975c6-fthmt.app-ns-2       Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-2-658d6458f7-slpd9     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
+curl-78ff5975c6-nxtth.app-ns-3       Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-usergroup-2-658d6458f7-slpd9     1.17-alpha.f5212a6f7df61fd8156f3585154bed2f003c4117
 {{< /text >}}
 
 ### Перевірка доступності pfcnjceyrsd ТІЛЬКИ всередині відповідної групи користувачів {#verify-the-application-connectivity-is-only-within-the-respective-usergroup}
 
-1. Надішліть запит з podʼа `sleep` в `app-ns-1` у `usergroup-1` до сервісу `httpbin` у `app-ns-2` у `usergroup-2`. Такий запит повинен зазнати невдачі:
+1. Надішліть запит з podʼа `curl` в `app-ns-1` у `usergroup-1` до сервісу `httpbin` у `app-ns-2` у `usergroup-2`. Такий запит повинен зазнати невдачі:
 
     {{< text bash >}}
-    $ kubectl -n app-ns-1 exec "$(kubectl -n app-ns-1 get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sIL http://httpbin.app-ns-2.svc.cluster.local:8000
+    $ kubectl -n app-ns-1 exec "$(kubectl -n app-ns-1 get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl -sIL http://httpbin.app-ns-2.svc.cluster.local:8000
     HTTP/1.1 503 Service Unavailable
     content-length: 95
     content-type: text/plain
@@ -238,10 +238,10 @@ sleep-78ff5975c6-nxtth.app-ns-3      Kubernetes     SYNCED     SYNCED     SYNCED
     server: envoy
     {{< /text >}}
 
-2. Надішліть запит з podʼа `sleep` в `app-ns-2` у `usergroup-2` до сервісу `httpbin` у `app-ns-3` у `usergroup-2`. Такий запит повинен бути успішним:
+2. Надішліть запит з podʼа `curl` в `app-ns-2` у `usergroup-2` до сервісу `httpbin` у `app-ns-3` у `usergroup-2`. Такий запит повинен бути успішним:
 
     {{< text bash >}}
-    $ kubectl -n app-ns-2 exec "$(kubectl -n app-ns-2 get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sIL http://httpbin.app-ns-3.svc.cluster.local:8000
+    $ kubectl -n app-ns-2 exec "$(kubectl -n app-ns-2 get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl -sIL http://httpbin.app-ns-3.svc.cluster.local:8000
     HTTP/1.1 200 OK
     server: envoy
     date: Thu, 22 Dec 2022 15:01:36 GMT
@@ -257,14 +257,14 @@ sleep-78ff5975c6-nxtth.app-ns-3      Kubernetes     SYNCED     SYNCED     SYNCED
 1. Вилучить першу групу користувачів:
 
     {{< text bash >}}
-    $ istioctl uninstall --revision usergroup-1
+    $ istioctl uninstall --revision usergroup-1 --set values.global.istioNamespace=usergroup-1
     $ kubectl delete ns app-ns-1 usergroup-1
     {{< /text >}}
 
 2. Вилучить другу групу користувачів:
 
     {{< text bash >}}
-    $ istioctl uninstall --revision usergroup-2
+    $ istioctl uninstall --revision usergroup-2 --set values.global.istioNamespace=usergroup-2
     $ kubectl delete ns app-ns-2 app-ns-3 usergroup-2
     {{< /text >}}
 

content/uk/docs/setup/install/operator/index.md

@@ -1,325 +0,0 @@
----
-title: Встановлення Istio Operator
-description: Інструкції для встановлення Istio в кластері Kubernetes за допомогою Istio operator.
-weight: 99
-keywords: [kubernetes, operator]
-aliases:
-    - /uk/docs/setup/install/standalone-operator
-owner: istio/wg-environments-maintainers
-test: yes
-status: Beta
----
-
-{{< warning >}}
-Використання оператора для нових установок Istio не рекомендується на користь методів установки [Istioctl](/docs/setup/install/istioctl) та [Helm](/docs/setup/install/helm). Хоча оператор буде продовжувати підтримуватися, нові запити на функції не будуть пріоритетними.
-{{< /warning >}}
-
-Замість того, щоб вручну встановлювати, оновлювати та видаляти Istio, ви можете дозволити [оператору](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) Istio управляти установкою за вас. Це знімає з вас навантаження з управління різними версіями `istioctl`. Просто оновіть {{<gloss CRD>}}custom resource (CR){{</gloss>}} оператора, і контролер оператора застосує відповідні зміни конфігурації за вас.
-
-Той самий [`IstioOperator` API](/docs/reference/config/istio.operator.v1alpha1/) використовується для встановлення Istio з оператором, як і при використанні [інструкцій установки istioctl](/docs/setup/install/istioctl). В обох випадках конфігурація перевіряється на відповідність схемі, і виконуються ті ж перевірки.
-
-{{< warning >}}
-Використання оператора має наслідки для безпеки. З командою `istioctl install` операція буде виконуватись у контексті безпеки адміністратора, тоді як з оператором, операцію виконуватиме podʼі в кластері у своєму контексті безпеки. Щоб уникнути вразливості, переконайтеся, що розгортання оператора достатньо захищене.
-{{< /warning >}}
-
-## Передумови {#prerequisites}
-
-1. Виконайте потрібні [платформозалежні налаштування](/docs/setup/platform-setup/).
-
-2. Перевірте [Вимоги до Podʼів та Сервісів](/docs/ops/deployment/application-requirements/).
-
-3. Встановіть [команду {{< istioctl >}}](/docs/ops/diagnostic-tools/istioctl/).
-
-## Встановлення {#install}
-
-### Розгортання Istio Operator {#deploy-the-istio-operator}
-
-Команду `istioctl` можна використовувати для автоматичного розгортання Istio оператора:
-
-{{< text syntax=bash snip_id=deploy_istio_operator >}}
-$ istioctl operator init
-{{< /text >}}
-
-Ця команда запускає оператора, створюючи наступні ресурси в просторі імен `istio-operator`:
-
-- Визначення custom resource для оператора
-- Розгортання контролера оператора
-- Сервіс для доступу до метрик оператора
-- Необхідні правила RBAC для оператора Istio
-
-Ви можете налаштувати, в якому просторі імен буде встановлений контролер оператора, які простори імен оператор буде відстежувати, джерела і версії образів Istio та інше. Наприклад, ви можете передати один або кілька просторів імен для відстеження, використовуючи прапорець `--watchedNamespaces`:
-
-{{< text syntax=bash snip_id=deploy_istio_operator_watch_ns >}}
-$ istioctl operator init --watchedNamespaces=istio-namespace1,istio-namespace2
-{{< /text >}}
-
-Дивіться [довідку команди `istioctl operator init`](/docs/reference/commands/istioctl/#istioctl-operator-init) для отримання деталей.
-
-{{< tip >}}
-Ви також можете розгорнути оператор за допомогою Helm:
-
-1. Створіть простір імен `istio-operator`.
-
-    {{< text syntax=bash snip_id=create_ns_istio_operator >}}
-    $ kubectl create namespace istio-operator
-    {{< /text >}}
-
-2. Встановіть оператор за допомогою Helm.
-
-    {{< text syntax=bash snip_id=deploy_istio_operator_helm >}}
-    $ helm install istio-operator manifests/charts/istio-operator \
-        --set watchedNamespaces="istio-namespace1\,istio-namespace2" \
-        -n istio-operator
-    {{< /text >}}
-
-Зверніть увагу, що вам потрібно [завантажити реліз Istio](/docs/setup/additional-setup/download-istio-release/) для виконання цієї команди.
-{{< /tip >}}
-
-{{< warning >}}
-До версії Istio 1.10.0 потрібно було створювати простір імен `istio-system` до установки оператора. Починаючи з Istio 1.10.0, команда `istioctl operator init` автоматично створить простір імен `istio-system`.
-
-Якщо ви використовуєте щось інше, ніж `istioctl operator init`, то простір імен `istio-system` потрібно створити вручну.
-{{< /warning >}}
-
-### Встановлення Istio за допомогою оператора {#install-istio-with-the-operator}
-
-Після встановлення оператора ви можете створити mesh, розгорнувши ресурс `IstioOperator`. Щоб встановити Istio з конфігураційним профілем `demo` за допомогою оператора, виконайте наступну команду:
-
-{{< text syntax=bash snip_id=install_istio_demo_profile >}}
-$ kubectl apply -f - <<EOF
-apiVersion: install.istio.io/v1alpha1
-kind: IstioOperator
-metadata:
-  namespace: istio-system
-  name: example-istiocontrolplane
-spec:
-  profile: demo
-EOF
-{{< /text >}}
-
-Контролер виявить ресурс `IstioOperator` і встановить компоненти Istio відповідно до вказаної конфігурації (`demo`).
-
-{{< warning >}}
-Якщо ви використовували `--watchedNamespaces` під час ініціалізації Istio оператора, застосуйте ресурс `IstioOperator` в одному з відстежуваних просторів імен, а не в `istio-system`.
-{{< /warning >}}
-
-Стандартно панель управління Istio (istiod) буде встановлена в просторі імен `istio-system`. Щоб встановити її в іншому місці, вкажіть простір імен за допомогою поля `values.global.istioNamespace` наступним чином:
-
-{{< text syntax=yaml snip_id=none >}}
-apiVersion: install.istio.io/v1alpha1
-kind: IstioOperator
-...
-spec:
-  profile: demo
-  values:
-    global:
-      istioNamespace: istio-namespace1
-{{< /text >}}
-
-{{< tip >}}
-Контролер оператора Istio починає процес установки Istio протягом 90 секунд після створення ресурсу `IstioOperator`. Установка Istio завершується протягом 120 секунд.
-{{< /tip >}}
-
-Ви можете підтвердити, що сервіси панелі управління Istio були розгорнуті, за допомогою наступних команд:
-
-{{< text syntax=bash snip_id=kubectl_get_svc >}}
-$ kubectl get services -n istio-system
-NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)   AGE
-istio-egressgateway    ClusterIP      10.96.65.145    <none>           ...       30s
-istio-ingressgateway   LoadBalancer   10.96.189.244   192.168.11.156   ...       30s
-istiod                 ClusterIP      10.96.189.20    <none>           ...       37s
-{{< /text >}}
-
-{{< text syntax=bash snip_id=kubectl_get_pods >}}
-$ kubectl get pods -n istio-system
-NAME                                    READY   STATUS    RESTARTS   AGE
-istio-egressgateway-696cccb5-m8ndk      1/1     Running   0          68s
-istio-ingressgateway-86cb4b6795-9jlrk   1/1     Running   0          68s
-istiod-b47586647-sf6sw                  1/1     Running   0          74s
-{{< /text >}}
-
-### Оновлення {#update}
-
-Тепер, коли контролер працює, ви можете змінювати конфігурацію Istio, редагуючи або замінюючи ресурс `IstioOperator`. Контролер виявить зміни та відповідно оновить установку Istio.
-
-Наприклад, ви можете переключити установку на конфігураційний профіль `default` за допомогою наступної команди:
-
-{{< text syntax=bash snip_id=update_to_default_profile >}}
-$ kubectl apply -f - <<EOF
-apiVersion: install.istio.io/v1alpha1
-kind: IstioOperator
-metadata:
-  namespace: istio-system
-  name: example-istiocontrolplane
-spec:
-  profile: default
-EOF
-{{< /text >}}
-
-Ви також можете увімкнути або вимкнути компоненти та змінити налаштування ресурсів. Наприклад, щоб увімкнути компонент `istio-egressgateway` і збільшити запити памʼяті для `istiod`, використовуйте наступну команду:
-
-{{< text syntax=bash snip_id=update_to_default_profile_egress >}}
-$ kubectl apply -f - <<EOF
-apiVersion: install.istio.io/v1alpha1
-kind: IstioOperator
-metadata:
-  namespace: istio-system
-  name: example-istiocontrolplane
-spec:
-  profile: default
-  components:
-    pilot:
-      k8s:
-        resources:
-          requests:
-            memory: 3072Mi
-    egressGateways:
-    - name: istio-egressgateway
-      enabled: true
-EOF
-{{< /text >}}
-
-Ви можете спостерігати за змінами, які контролер вносить у кластер у відповідь на оновлення CR `IstioOperator`, перевіряючи журнали контролера оператора:
-
-{{< text syntax=bash snip_id=operator_logs >}}
-$ kubectl logs -f -n istio-operator "$(kubectl get pods -n istio-operator -lname=istio-operator -o jsonpath='{.items[0].metadata.name}')"
-{{< /text >}}
-
-Зверніться до [API `IstioOperator`](https://istio.io/latest/docs/reference/config/istio.operator.v1alpha1/#IstioOperatorSpec) для отримання повного списку налаштувань конфігурації.
-
-## Оновлення на місці {#in-place-upgrade}
-
-Завантажте та розпакуйте `istioctl`, що відповідає версії Istio, до якої ви хочете оновитись. Перевстановіть оператор на цільову версію Istio:
-
-{{< text syntax=bash snip_id=inplace_upgrade >}}
-$ <extracted-dir>/bin/istioctl operator init
-{{< /text >}}
-
-Ви повинні побачити, що pod `istio-operator` перезапущено, і його версія змінилася на цільову версію:
-
-{{< text syntax=bash snip_id=inplace_upgrade_get_pods_istio_operator >}}
-$ kubectl get pods --namespace istio-operator \
-  -o=jsonpath='{range .items[*]}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{"\n"}{end}'
-{{< /text >}}
-
-Через хвилину-другу компоненти панелі управління Istio також повинні бути перезапущені на новій версії:
-
-{{< text syntax=bash snip_id=inplace_upgrade_get_pods_istio_system >}}
-$ kubectl get pods --namespace istio-system \
-  -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{"\n"}{end}'
-{{< /text >}}
-
-## Канаркове оновлення {#canary-upgrade}
-
-Процес поетапного оновлення подібний до [поетапного оновлення з `istioctl`](/docs/setup/upgrade/canary/).
-
-Наприклад, щоб оновити Istio з версії {{< istio_previous_version >}}.0 до {{< istio_full_version >}}, спочатку встановіть {{< istio_previous_version >}}.0:
-
-{{< text syntax=bash snip_id=download_istio_previous_version >}}
-$ curl -L https://istio.io/downloadIstio | ISTIO_VERSION={{< istio_previous_version >}}.0 sh -
-{{< /text >}}
-
-Розгорніть оператор, використовуючи версію Istio {{< istio_previous_version >}}.0:
-
-{{< text syntax=bash snip_id=deploy_operator_previous_version >}}
-$ istio-{{< istio_previous_version >}}.0/bin/istioctl operator init
-{{< /text >}}
-
-Встановіть профіль демо панелі управління Istio:
-
-{{< text syntax=bash snip_id=install_istio_previous_version >}}
-$ kubectl apply -f - <<EOF
-apiVersion: install.istio.io/v1alpha1
-kind: IstioOperator
-metadata:
-  namespace: istio-system
-  name: example-istiocontrolplane-{{< istio_previous_version_revision >}}-0
-spec:
-  profile: default
-EOF
-{{< /text >}}
-
-Перевірте, чи існує CR `IstioOperator` з іменем `example-istiocontrolplane` у вашому кластері:
-
-{{< text syntax=bash snip_id=verify_operator_cr >}}
-$ kubectl get iop --all-namespaces
-NAMESPACE      NAME                              REVISION   STATUS    AGE
-istio-system   example-istiocontrolplane{{< istio_previous_version_revision >}}-0              HEALTHY   11m
-{{< /text >}}
-
-Завантажте та розпакуйте `istioctl`, для версії Istio, до якої ви хочете оновитись. Потім виконайте наступну команду, щоб встановити нову цільову ревізію панелі управління Istio на основі CR `IstioOperator` у кластері (тут ми припускаємо, що цільова ревізія — {{< istio_full_version_revision >}}):
-
-{{< text syntax=bash snip_id=canary_upgrade_init >}}
-$ istio-{{< istio_full_version >}}/bin/istioctl operator init --revision {{< istio_full_version_revision >}}
-{{< /text >}}
-
-{{< tip >}}
-Ви також можете використовувати Helm для розгортання іншого оператора з налаштуванням ревізії:
-
-{{< text syntax=bash snip_id=none >}}
-$ helm install istio-operator manifests/charts/istio-operator \
-  --set watchedNamespaces=istio-system \
-  -n istio-operator \
-  --set revision={{< istio_full_version_revision >}}
-{{< /text >}}
-
-Зверніть увагу, що для виконання наведених вище команд потрібно [завантажити реліз Istio](/docs/setup/additional-setup/download-istio-release/).
-{{< /tip >}}
-
-Зробіть копію CR `example-istiocontrolplane` і збережіть її у файлі з іменем `example-istiocontrolplane-{{< istio_full_version_revision >}}.yaml`. Змініть імʼя на `example-istiocontrolplane-{{< istio_full_version_revision >}}` і додайте `revision: {{< istio_full_version_revision >}}` до CR. Ваш оновлений CR `IstioOperator` повинен виглядати приблизно так:
-
-{{< text syntax=bash snip_id=cat_operator_yaml >}}
-$ cat example-istiocontrolplane-{{< istio_full_version_revision >}}.yaml
-apiVersion: install.istio.io/v1alpha1
-kind: IstioOperator
-metadata:
-  namespace: istio-system
-  name: example-istiocontrolplane-{{< istio_full_version_revision >}}
-spec:
-  revision: {{< istio_full_version_revision >}}
-  profile: default
-{{< /text >}}
-
-Застосуйте оновлений CR `IstioOperator` до кластера. Після цього у вас буде два розгортання панелі управління та сервіси, що працюють паралельно:
-
-{{< text syntax=bash snip_id=get_pods_istio_system >}}
-$ kubectl get pod -n istio-system -l app=istiod
-NAME                             READY   STATUS    RESTARTS   AGE
-istiod-{{< istio_full_version_revision >}}-597475f4f6-bgtcz   1/1     Running   0          64s
-istiod-6ffcc65b96-bxzv5          1/1     Running   0          2m11s
-{{< /text >}}
-
-{{< text syntax=bash snip_id=get_svc_istio_system >}}
-$ kubectl get services -n istio-system -l app=istiod
-NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                         AGE
-istiod          ClusterIP   10.104.129.150   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP   2m35s
-istiod-{{< istio_full_version_revision >}}   ClusterIP   10.111.17.49     <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP           88s
-{{< /text >}}
-
-Щоб завершити оновлення, позначте простори імен міткою `istio.io/rev={{< istio_full_version_revision >}}` і перезапустіть робочі навантаження, як описано в документації по [оновленню робочих навантажень](/docs/setup/upgrade/canary/#data-plane).
-
-## Видалення {#uninstall}
-
-Якщо ви використовували оператор для виконання поетапного оновлення панелі управління, ви можете видалити стару панель управління та зберегти нову, видаливши старий `IstioOperator` CR у кластері, що видалить стару версію Istio:
-
-{{< text syntax=bash snip_id=delete_example_istiocontrolplane >}}
-$ kubectl delete istiooperators.install.istio.io -n istio-system example-istiocontrolplane
-{{< /text >}}
-
-Зачекайте, поки Istio буде видалено — це може зайняти деякий час.
-
-Потім ви можете видалити оператор Istio для старої версії, виконавши наступну команду:
-
-{{< text syntax=bash snip_id=none >}}
-$ istioctl operator remove --revision <revision>
-{{< /text >}}
-
-Якщо ви пропустите параметр `revision`, будуть видалені всі версії оператора Istio.
-
-Зверніть увагу, що видалення оператора до того, як `IstioOperator` CR і відповідна версія Istio будуть повністю видалені, може призвести до залишкових ресурсів Istio.
-Щоб очистити все, що не було видалено оператором:
-
-{{< text syntax=bash snip_id=cleanup >}}
-$ istioctl uninstall -y --purge
-$ kubectl delete ns istio-system istio-operator
-{{< /text >}}

content/uk/docs/setup/upgrade/canary/index.md

@@ -75,7 +75,7 @@ istiod-canary-6956db645c-vwhsk
 
 Однак, проста установка нової ревізії не вплине на наявні sidecar проксі. Щоб оновити їх, потрібно налаштувати їх на нову панель управління `istiod-canary`. Це контролюється під час інʼєкції sidecar контейнерів на основі мітки простору імен `istio.io/rev`.
 
-Створіть простір імен `test-ns` з увімкненим `istio-injection`. У просторі імен `test-ns` розгорніть демонстраційний pod `sleep`:
+Створіть простір імен `test-ns` з увімкненим `istio-injection`. У просторі імен `test-ns` розгорніть демонстраційний pod `curl`:
 
 1. Створіть простір імен `test-ns`.
 
@@ -89,10 +89,10 @@ istiod-canary-6956db645c-vwhsk
     $ kubectl label namespace test-ns istio-injection=enabled
     {{< /text >}}
 
-3. Запустіть демонстраційний pod `sleep` у просторі імен `test-ns`.
+3. Запустіть демонстраційний pod `curl` у просторі імен `test-ns`.
 
     {{< text bash >}}
-    $ kubectl apply -n test-ns -f samples/sleep/sleep.yaml
+    $ kubectl apply -n test-ns -f samples/curl/curl.yaml
     {{< /text >}}
 
 Щоб оновити простір імен `test-ns`, видаліть мітку `istio-injection` і додайте мітку `istio.io/rev`, щоб вказати на ревізію `canary`. Мітка `istio-injection` повинна бути видалена, оскільки вона має перевагу над міткою `istio.io/rev` для зворотної сумісності.
@@ -152,12 +152,12 @@ $ istioctl proxy-status | grep "\.test-ns "
     $ kubectl label ns app-ns-3 istio.io/rev=prod-canary
     {{< /text >}}
 
-4. Запустіть демонстраційний pod `sleep` в кожному просторі імен:
+4. Запустіть демонстраційний pod `curl` в кожному просторі імен:
 
     {{< text bash >}}
-    $ kubectl apply -n app-ns-1 -f samples/sleep/sleep.yaml
-    $ kubectl apply -n app-ns-2 -f samples/sleep/sleep.yaml
-    $ kubectl apply -n app-ns-3 -f samples/sleep/sleep.yaml
+    $ kubectl apply -n app-ns-1 -f samples/curl/curl.yaml
+    $ kubectl apply -n app-ns-2 -f samples/curl/curl.yaml
+    $ kubectl apply -n app-ns-3 -f samples/curl/curl.yaml
     {{< /text >}}
 
 5. Перевірте відповідність застосунку до панелі управління за допомогою команди `istioctl proxy-status`:
@@ -165,9 +165,9 @@ $ istioctl proxy-status | grep "\.test-ns "
     {{< text bash >}}
     $ istioctl ps
     NAME                                CLUSTER        CDS        LDS        EDS        RDS        ECDS         ISTIOD                             VERSION
-    sleep-78ff5975c6-62pzf.app-ns-3     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-s8zfg     {{< istio_full_version >}}
-    sleep-78ff5975c6-8kxpl.app-ns-1     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-{{< istio_previous_version_revision >}}-1-bdf5948d5-n72r2      {{< istio_previous_version >}}.1
-    sleep-78ff5975c6-8q7m6.app-ns-2     Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-{{< istio_previous_version_revision >}}-1-bdf5948d5-n72r2      {{< istio_previous_version_revision >}}.1
+    curl-78ff5975c6-62pzf.app-ns-3      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-s8zfg     {{< istio_full_version >}}
+    curl-78ff5975c6-8kxpl.app-ns-1      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-{{< istio_previous_version_revision >}}-1-bdf5948d5-n72r2      {{< istio_previous_version >}}.1
+    curl-78ff5975c6-8q7m6.app-ns-2      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-{{< istio_previous_version_revision >}}-1-bdf5948d5-n72r2      {{< istio_previous_version_revision >}}.1
     {{< /text >}}
 
 {{< boilerplate revision-tags-middle >}}
@@ -188,9 +188,9 @@ $ kubectl rollout restart deployment -n app-ns-2
 {{< text bash >}}
 $ istioctl ps
 NAME                                                   CLUSTER        CDS        LDS        EDS        RDS          ECDS         ISTIOD                             VERSION
-sleep-5984f48bc7-kmj6x.app-ns-1                        Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-jsktb     {{< istio_full_version >}}
-sleep-78ff5975c6-jldk4.app-ns-3                        Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-jsktb     {{< istio_full_version >}}
-sleep-7cdd8dccb9-5bq5n.app-ns-2                        Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-jsktb     {{< istio_full_version >}}
+curl-5984f48bc7-kmj6x.app-ns-1                         Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-jsktb     {{< istio_full_version >}}
+curl-78ff5975c6-jldk4.app-ns-3                         Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-jsktb     {{< istio_full_version >}}
+curl-7cdd8dccb9-5bq5n.app-ns-2                         Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-{{< istio_full_version_revision >}}-7f6fc6cfd6-jsktb     {{< istio_full_version >}}
 {{< /text >}}
 
 ### Стандартний теґ {#default-tag}

content/uk/docs/setup/upgrade/helm/index.md

@@ -24,10 +24,6 @@ $ istioctl x precheck
   To get started, check out <https://istio.io/latest/docs/setup/getting-started/>
 {{< /text >}}
 
-{{< warning >}}
-[Helm не оновлює та не видаляє CRD](/docs/setup/install/helm/#some-caveats-and-explanations) під час виконання оновлення. Через це обмеження потрібно виконати додатковий крок при оновленні Istio за допомогою Helm.
-{{< /warning >}}
-
 ### Оновлення Canary (рекомендовано) {#canary-upgrade-recommended}
 
 Ви можете встановити версію canary панелі управління Istio, щоб перевірити, чи нова версія сумісна з вашою поточною конфігурацією та панеллю даних за допомогою наведених нижче кроків:
@@ -36,10 +32,12 @@ $ istioctl x precheck
 Зверніть увагу, що коли ви встановлюєте версію canary сервісу `istiod`, ресурси кластера з базового чарту спільно використовуються між вашими основними та canary установками.
 {{< /warning >}}
 
+{{< boilerplate crd-upgrade-123 >}}
+
 1. Оновіть визначення власних ресурсів Kubernetes ({{< gloss CRD>}}CRD{{</ gloss >}}):
 
     {{< text bash >}}
-    $ kubectl apply -f manifests/charts/base/crds
+    $ helm upgrade istio-base istio/base -n istio-system
     {{< /text >}}
 
 2. Встановіть канаркову версію чарту виявлення Istio, встановивши ревізію:
@@ -86,10 +84,10 @@ $ istioctl x precheck
     $ helm delete istiod -n istio-system
     {{< /text >}}
 
-8. Оновіть базовий чарт Istio, зробивши нову версію стандартною:
+8. Оновіть знов базовий чарт Istio, цього разу зробивши нову `canary` версію стандартною для всього кластера:
 
     {{< text bash >}}
-    $ helm upgrade istio-base istio/base --set defaultRevision=canary -n istio-system --skip-crds
+    $ helm upgrade istio-base istio/base --set defaultRevision=canary -n istio-system
     {{< /text >}}
 
 ### Мітки стабільної версії {#stable-revision-labels}
@@ -136,25 +134,21 @@ $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisi
 Додайте файл перевизначення значень або власні параметри до наведених нижче команд, щоб зберегти вашу конфігурацію під час оновлення Helm.
 {{< /warning >}}
 
-1. Оновіть визначення власних ресурсів Kubernetes ({{< gloss CRD >}}CRD{{</ gloss >}}):
+{{< boilerplate crd-upgrade-123 >}}
+
+1. Оновіть базовий чарт Istio:
 
     {{< text bash >}}
-    $ kubectl apply -f manifests/charts/base/crds
+    $ helm upgrade istio-base istio/base -n istio-system
     {{< /text >}}
 
-2. Оновіть базовий чарт Istio:
-
-    {{< text bash >}}
-    $ helm upgrade istio-base manifests/charts/base -n istio-system --skip-crds
-    {{< /text >}}
-
-3. Оновіть чарт виявлення Istio:
+1. Оновіть чарт виявлення Istio:
 
     {{< text bash >}}
     $ helm upgrade istiod istio/istiod -n istio-system
     {{< /text >}}
 
-4. (Необовʼязково) Оновіть чарти шлюзів, встановлені у вашому кластері:
+1. (Необовʼязково) Оновіть чарти шлюзів, встановлені у вашому кластері:
 
     {{< text bash >}}
     $ helm upgrade istio-ingress istio/gateway -n istio-ingress

content/uk/docs/tasks/observability/distributed-tracing/mesh-and-proxy-config/index.md

@@ -94,13 +94,13 @@ EOF
 
 ### Використання анотації `proxy.istio.io/config` для налаштування трейсингу {#using-proxyistioioconfig-annotation-for-trace-settings}
 
-Ви можете додати анотацію `proxy.istio.io/config` до специфікації метаданих вашого Podʼа  для перевизначення будь-яких мережевих налаштувань трейсингу. Наприклад, щоб змінити розгортання `sleep`, яке постачається з Istio, ви додасте наступне до `samples/sleep/sleep.yaml`:
+Ви можете додати анотацію `proxy.istio.io/config` до специфікації метаданих вашого Podʼа  для перевизначення будь-яких мережевих налаштувань трейсингу. Наприклад, щоб змінити розгортання `curl`, яке постачається з Istio, ви додасте наступне до `samples/curl/curl.yaml`:
 
 {{< text yaml >}}
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: sleep
+  name: curl
 spec:
   ...
   template:

content/uk/docs/tasks/observability/distributed-tracing/sampling/index.md

@@ -83,7 +83,7 @@ EOF
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: sleep
+  name: curl
 spec:
   ...
   template:

content/uk/docs/tasks/observability/logs/access-log/index.md

@@ -78,10 +78,10 @@ $ istioctl install <flags-you-used-to-install-Istio> --set meshConfig.accessLogF
 \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n
 {{< /text >}}
 
-У таблиці нижче наведено приклад використання формату стандартних логів доступу для запиту від `sleep` до `httpbin`:
+У таблиці нижче наведено приклад використання формату стандартних логів доступу для запиту від `curl` до `httpbin`:
 
-| Оператор логу | логи доступу у sleep | логи доступу у httpbin |
-|---------------|----------------------|------------------------|
+| Оператор логу | логи доступу у curl | логи доступу у httpbin |
+|---------------|---------------------|------------------------|
 | `[%START_TIME%]` | `[2020-11-25T21:26:18.409Z]` | `[2020-11-25T21:26:18.409Z]`
 | `\"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\"` | `"GET /status/418 HTTP/1.1"` | `"GET /status/418 HTTP/1.1"`
 | `%RESPONSE_CODE%` | `418` | `418`
@@ -107,29 +107,23 @@ $ istioctl install <flags-you-used-to-install-Istio> --set meshConfig.accessLogF
 
 ## Тестування логів доступу {#test-the-access-log}
 
-1.  Надішліть запит від `sleep` до `httpbin`:
+1.  Надішліть запит від `curl` до `httpbin`:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS -v httpbin:8000/status/418
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sS -v httpbin:8000/status/418
     ...
     < HTTP/1.1 418 Unknown
+    ...
     < server: envoy
     ...
-        -=[ teapot ]=-
-
-           _...._
-         .'  _ _ `.
-        | ."` ^ `". _,
-        \_;`"---"`|//
-          |       ;/
-          \_     _/
-            `"""`
+    I'm a teapot!
+    ...
     {{< /text >}}
 
-1.  Перевірте логи `sleep`:
+1.  Перевірте логи `curl`:
 
     {{< text bash >}}
-    $ kubectl logs -l app=sleep -c istio-proxy
+    $ kubectl logs -l app=curl -c istio-proxy
     [2020-11-25T21:26:18.409Z] "GET /status/418 HTTP/1.1" 418 - via_upstream - "-" 0 135 4 4 "-" "curl/7.73.0-DEV" "84961386-6d84-929d-98bd-c5aee93b5c88" "httpbin:8000" "10.44.1.27:80" outbound|8000||httpbin.foo.svc.cluster.local 10.44.1.23:37652 10.0.45.184:8000 10.44.1.23:46520 - default
     {{< /text >}}
 
@@ -140,14 +134,14 @@ $ istioctl install <flags-you-used-to-install-Istio> --set meshConfig.accessLogF
     [2020-11-25T21:26:18.409Z] "GET /status/418 HTTP/1.1" 418 - via_upstream - "-" 0 135 3 1 "-" "curl/7.73.0-DEV" "84961386-6d84-929d-98bd-c5aee93b5c88" "httpbin:8000" "127.0.0.1:80" inbound|8000|| 127.0.0.1:41854 10.44.1.27:80 10.44.1.23:37652 outbound_.8000_._.httpbin.foo.svc.cluster.local default
     {{< /text >}}
 
-Зверніть увагу, що повідомлення, повʼязані із запитом, зʼявляються в логах Istio-проксі як на джерелі, так і на пункті призначення — відповідно, `sleep` і `httpbin`. Ви можете побачити в логах HTTP-метод (`GET`), HTTP-шлях (`/status/418`), код відповіді (`418`) та іншу [інформацію про запит](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#format-rules).
+Зверніть увагу, що повідомлення, повʼязані із запитом, зʼявляються в логах Istio-проксі як на джерелі, так і на пункті призначення — відповідно, `curl` і `httpbin`. Ви можете побачити в логах HTTP-метод (`GET`), HTTP-шлях (`/status/418`), код відповіді (`418`) та іншу [інформацію про запит](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#format-rules).
 
 ## Очищення {#cleanup}
 
-Завершіть роботу сервісів [sleep]({{< github_tree >}}/samples/sleep) та [httpbin]({{< github_tree >}}/samples/httpbin):
+Завершіть роботу сервісів [curl]({{< github_tree >}}/samples/curl) та [httpbin]({{< github_tree >}}/samples/httpbin):
 
 {{< text bash >}}
-$ kubectl delete -f @samples/sleep/sleep.yaml@
+$ kubectl delete -f @samples/curl/curl.yaml@
 $ kubectl delete -f @samples/httpbin/httpbin.yaml@
 {{< /text >}}
 

content/uk/docs/tasks/observability/logs/otel-provider/index.md

@@ -64,11 +64,11 @@ $ cat <<EOF | kubectl apply -n default -f -
 apiVersion: telemetry.istio.io/v1
 kind: Telemetry
 metadata:
-  name: sleep-logging
+  name: curl-logging
 spec:
   selector:
     matchLabels:
-      app: sleep
+      app: curl
   accessLogging:
     - providers:
       - name: otel
@@ -116,10 +116,10 @@ Istio використовуватиме наступний стандартни
 \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\" %UPSTREAM_CLUSTER% %UPSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_LOCAL_ADDRESS% %DOWNSTREAM_REMOTE_ADDRESS% %REQUESTED_SERVER_NAME% %ROUTE_NAME%\n
 {{< /text >}}
 
-У таблиці нижче наведено приклад використання стандартного формату логів для запиту від `sleep` до `httpbin`:
+У таблиці нижче наведено приклад використання стандартного формату логів для запиту від `curl` до `httpbin`:
 
-| Оператор логів | лог доступу у sleep | лог доступу у httpbin |
-|----------------|---------------------|-----------------------|
+| Оператор логів | лог доступу у curl | лог доступу у httpbin |
+|----------------|--------------------|-----------------------|
 | `[%START_TIME%]` | `[2020-11-25T21:26:18.409Z]` | `[2020-11-25T21:26:18.409Z]`
 | `\"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\"` | `"GET /status/418 HTTP/1.1"` | `"GET /status/418 HTTP/1.1"`
 | `%RESPONSE_CODE%` | `418` | `418`
@@ -145,23 +145,17 @@ Istio використовуватиме наступний стандартни
 
 ## Тестування журналу доступу {#test-the-access-log}
 
-1.  Надішліть запит з `sleep` до `httpbin`:
+1.  Надішліть запит з `curl` до `httpbin`:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS -v httpbin:8000/status/418
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sS -v httpbin:8000/status/418
     ...
     < HTTP/1.1 418 Unknown
+    ...
     < server: envoy
     ...
-        -=[ teapot ]=-
-
-           _...._
-         .'  _ _ `.
-        | ."` ^ `". _,
-        \_;`"---"`|//
-          |       ;/
-          \_     _/
-            `"""`
+    I'm a teapot!
+    ...
     {{< /text >}}
 
 1.  Перевірте журнал `otel-collector`:
@@ -171,15 +165,15 @@ Istio використовуватиме наступний стандартни
     [2020-11-25T21:26:18.409Z] "GET /status/418 HTTP/1.1" 418 - via_upstream - "-" 0 135 3 1 "-" "curl/7.73.0-DEV" "84961386-6d84-929d-98bd-c5aee93b5c88" "httpbin:8000" "127.0.0.1:80" inbound|8000|| 127.0.0.1:41854 10.44.1.27:80 10.44.1.23:37652 outbound_.8000_._.httpbin.foo.svc.cluster.local default
     {{< /text >}}
 
-Зверніть увагу, що повідомлення, що відповідають запиту, з’являються в журналах Istio проксі як для джерела, так і для місця призначення, відповідно `sleep` і `httpbin`. Ви можете побачити в журналі HTTP-дієслово (`GET`), HTTP-шлях (`/status/418`), код відповіді (`418`) та іншу [інформацію про запит](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#format-rules).
+Зверніть увагу, що повідомлення, що відповідають запиту, з’являються в журналах Istio проксі як для джерела, так і для місця призначення, відповідно `curl` і `httpbin`. Ви можете побачити в журналі HTTP-дієслово (`GET`), HTTP-шлях (`/status/418`), код відповіді (`418`) та іншу [інформацію про запит](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#format-rules).
 
 ## Очищення {#cleanup}
 
-Зупиніть сервіси [sleep]({{< github_tree >}}/samples/sleep) і [httpbin]({{< github_tree >}}/samples/httpbin):
+Зупиніть сервіси [curl]({{< github_tree >}}/samples/curl) і [httpbin]({{< github_tree >}}/samples/httpbin):
 
 {{< text bash >}}
-$ kubectl delete telemetry sleep-logging
-$ kubectl delete -f @samples/sleep/sleep.yaml@
+$ kubectl delete telemetry curl-logging
+$ kubectl delete -f @samples/curl/curl.yaml@
 $ kubectl delete -f @samples/httpbin/httpbin.yaml@
 $ kubectl delete -f @samples/open-telemetry/otel.yaml@ -n istio-system
 $ kubectl delete namespace observability

content/uk/docs/tasks/observability/logs/telemetry-api/index.md

@@ -44,19 +44,19 @@ $ kubectl apply -f @samples/open-telemetry/loki/otel.yaml@ -n istio-system
 
 1. Вимкніть журнал доступу для конкретного робочого навантаження
 
-    Ви можете вимкнути журнал доступу для служби `sleep` за допомогою наступної конфігурації:
+    Ви можете вимкнути журнал доступу для служби `curl` за допомогою наступної конфігурації:
 
     {{< text bash >}}
     $ cat <<EOF | kubectl apply -n default -f -
     apiVersion: telemetry.istio.io/v1
     kind: Telemetry
     metadata:
-      name: disable-sleep-logging
+      name: disable-curl-logging
       namespace: default
     spec:
       selector:
         matchLabels:
-          app: sleep
+          app: curl
       accessLogging:
       - providers:
         - name: otel
@@ -96,11 +96,11 @@ $ kubectl apply -f @samples/open-telemetry/loki/otel.yaml@ -n istio-system
     apiVersion: telemetry.istio.io/v1alpha1
     kind: Telemetry
     metadata:
-      name: filter-sleep-logging
+      name: filter-curl-logging
     spec:
       selector:
         matchLabels:
-          app: sleep
+          app: curl
       accessLogging:
       - providers:
         - name: otel

content/uk/docs/tasks/security/authentication/authn-policy/index.md

@@ -25,43 +25,43 @@ $ istioctl install --set profile=default
 
 ### Налаштування {#setup}
 
-Наші приклади використовують два простори імен: `foo` і `bar`, з двома сервісами, `httpbin` і `sleep`, які обидва працюють з проксі Envoy. Ми також використовуємо інші екземпляри `httpbin` і `sleep`, що працюють без sidecar у просторі імен `legacy`. Якщо ви хочете використовувати ті ж приклади для виконання завдань, виконайте наступне:
+Наші приклади використовують два простори імен: `foo` і `bar`, з двома сервісами, `httpbin` і `curl`, які обидва працюють з проксі Envoy. Ми також використовуємо інші екземпляри `httpbin` і `curl`, що працюють без sidecar у просторі імен `legacy`. Якщо ви хочете використовувати ті ж приклади для виконання завдань, виконайте наступне:
 
 {{< text bash >}}
 $ kubectl create ns foo
 $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
-$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
+$ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n foo
 $ kubectl create ns bar
 $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n bar
-$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n bar
+$ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n bar
 $ kubectl create ns legacy
 $ kubectl apply -f @samples/httpbin/httpbin.yaml@ -n legacy
-$ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy
+$ kubectl apply -f @samples/curl/curl.yaml@ -n legacy
 {{< /text >}}
 
-Ви можете перевірити налаштування, відправивши HTTP-запит за допомогою `curl` з будь-якого podʼа `sleep` у просторі імен `foo`, `bar` або `legacy` на будь-який з `httpbin.foo`,
+Ви можете перевірити налаштування, відправивши HTTP-запит за допомогою `curl` з будь-якого podʼа `curl` у просторі імен `foo`, `bar` або `legacy` на будь-який з `httpbin.foo`,
 `httpbin.bar` або `httpbin.legacy`. Усі запити мають бути успішними з HTTP-кодом 200.
 
-Наприклад, ось команда для перевірки доступності `sleep.bar` до `httpbin.foo`:
+Наприклад, ось команда для перевірки доступності `curl.bar` до `httpbin.foo`:
 
 {{< text bash >}}
-$ kubectl exec "$(kubectl get pod -l app=sleep -n bar -o jsonpath={.items..metadata.name})" -c sleep -n bar -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
+$ kubectl exec "$(kubectl get pod -l app=curl -n bar -o jsonpath={.items..metadata.name})" -c curl -n bar -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
 200
 {{< /text >}}
 
 Ця команда зручно перебирає всі комбінації доступності:
 
 {{< text bash >}}
-$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
-sleep.foo to httpbin.foo: 200
-sleep.foo to httpbin.bar: 200
-sleep.foo to httpbin.legacy: 200
-sleep.bar to httpbin.foo: 200
-sleep.bar to httpbin.bar: 200
-sleep.bar to httpbin.legacy: 200
-sleep.legacy to httpbin.foo: 200
-sleep.legacy to httpbin.bar: 200
-sleep.legacy to httpbin.legacy: 200
+$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
+curl.foo to httpbin.foo: 200
+curl.foo to httpbin.bar: 200
+curl.foo to httpbin.legacy: 200
+curl.bar to httpbin.foo: 200
+curl.bar to httpbin.bar: 200
+curl.bar to httpbin.legacy: 200
+curl.legacy to httpbin.foo: 200
+curl.legacy to httpbin.bar: 200
+curl.legacy to httpbin.legacy: 200
 {{< /text >}}
 
 Переконайтеся, що в системі немає політики однорангової автентифікації за допомогою наступної команди:
@@ -88,14 +88,14 @@ $ kubectl get destinationrules.networking.istio.io --all-namespaces -o yaml | gr
 Таким чином, весь трафік між робочими навантаженнями з проксі використовує взаємний TLS, без додаткових дій з вашого боку. Наприклад, візьміть відповідь на запит до `httpbin/header`. При використанні взаємного TLS проксі вставляє заголовок `X-Forwarded-Client-Cert` у запит до бекенду. Наявність цього заголовка є доказом використання взаємного TLS. Наприклад:
 
 {{< text bash >}}
-$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl -s http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert | sed 's/Hash=[a-z0-9]*;/Hash=<redacted>;/'
-    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=<redacted>;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"
+$ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl -s http://httpbin.foo:8000/headers -s | jq '.headers["X-Forwarded-Client-Cert"][0]' | sed 's/Hash=[a-z0-9]*;/Hash=<redacted>;/'
+  "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=<redacted>;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/curl"
 {{< /text >}}
 
 Коли сервер не має sidecar, заголовок `X-Forwarded-Client-Cert` відсутній, що вказує на те, що запити передаються у звичайному текстовому режимі.
 
 {{< text bash >}}
-$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert
+$ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert
 
 {{< /text >}}
 
@@ -125,21 +125,21 @@ EOF
 Запустіть команду перевірки знову:
 
 {{< text bash >}}
-$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
-sleep.foo to httpbin.foo: 200
-sleep.foo to httpbin.bar: 200
-sleep.foo to httpbin.legacy: 200
-sleep.bar to httpbin.foo: 200
-sleep.bar to httpbin.bar: 200
-sleep.bar to httpbin.legacy: 200
-sleep.legacy to httpbin.foo: 000
+$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
+curl.foo to httpbin.foo: 200
+curl.foo to httpbin.bar: 200
+curl.foo to httpbin.legacy: 200
+curl.bar to httpbin.foo: 200
+curl.bar to httpbin.bar: 200
+curl.bar to httpbin.legacy: 200
+curl.legacy to httpbin.foo: 000
 command terminated with exit code 56
-sleep.legacy to httpbin.bar: 000
+curl.legacy to httpbin.bar: 000
 command terminated with exit code 56
-sleep.legacy to httpbin.legacy: 200
+curl.legacy to httpbin.legacy: 200
 {{< /text >}}
 
-Ви побачите, що запити все ще успішні, за винятком тих, що надходять від клієнта без проксі, `sleep.legacy`, до сервера з проксі, `httpbin.foo` або `httpbin.bar`. Це очікувано, оскільки тепер взаємний TLS є обовʼязковим, але робоче навантаження без sidecar не може відповідати вимогам.
+Ви побачите, що запити все ще успішні, за винятком тих, що надходять від клієнта без проксі, `curl.legacy`, до сервера з проксі, `httpbin.foo` або `httpbin.bar`. Це очікувано, оскільки тепер взаємний TLS є обовʼязковим, але робоче навантаження без sidecar не може відповідати вимогам.
 
 ### Очистка частина 1 {#cleanup-part-1}
 
@@ -168,20 +168,20 @@ spec:
 EOF
 {{< /text >}}
 
-Оскільки ця політика застосовується лише до робочих навантажень у просторі імен `foo`, ви побачите, що тільки запити від клієнта без sidecar (`sleep.legacy`) до `httpbin.foo` почнуть давати збої.
+Оскільки ця політика застосовується лише до робочих навантажень у просторі імен `foo`, ви побачите, що тільки запити від клієнта без sidecar (`curl.legacy`) до `httpbin.foo` почнуть давати збої.
 
 {{< text bash >}}
-$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
-sleep.foo to httpbin.foo: 200
-sleep.foo to httpbin.bar: 200
-sleep.foo to httpbin.legacy: 200
-sleep.bar to httpbin.foo: 200
-sleep.bar to httpbin.bar: 200
-sleep.bar to httpbin.legacy: 200
-sleep.legacy to httpbin.foo: 000
+$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
+curl.foo to httpbin.foo: 200
+curl.foo to httpbin.bar: 200
+curl.foo to httpbin.legacy: 200
+curl.bar to httpbin.foo: 200
+curl.bar to httpbin.bar: 200
+curl.bar to httpbin.legacy: 200
+curl.legacy to httpbin.foo: 000
 command terminated with exit code 56
-sleep.legacy to httpbin.bar: 200
-sleep.legacy to httpbin.legacy: 200
+curl.legacy to httpbin.bar: 200
+curl.legacy to httpbin.legacy: 200
 {{< /text >}}
 
 ### Увімкнення взаємного TLS для робочого навантаження {#enable-mutual-tls-per-workload}
@@ -204,26 +204,26 @@ spec:
 EOF
 {{< /text >}}
 
-Знову запустіть команду probing. Як і очікувалося, запит з ` sleep.legacy` до `httpbin.bar` починає зазнавати невдачі з тих самих причин.
+Знову запустіть команду probing. Як і очікувалося, запит з ` curl.legacy` до `httpbin.bar` починає зазнавати невдачі з тих самих причин.
 
 {{< text bash >}}
-$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
-sleep.foo to httpbin.foo: 200
-sleep.foo to httpbin.bar: 200
-sleep.foo to httpbin.legacy: 200
-sleep.bar to httpbin.foo: 200
-sleep.bar to httpbin.bar: 200
-sleep.bar to httpbin.legacy: 200
-sleep.legacy to httpbin.foo: 000
+$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
+curl.foo to httpbin.foo: 200
+curl.foo to httpbin.bar: 200
+curl.foo to httpbin.legacy: 200
+curl.bar to httpbin.foo: 200
+curl.bar to httpbin.bar: 200
+curl.bar to httpbin.legacy: 200
+curl.legacy to httpbin.foo: 000
 command terminated with exit code 56
-sleep.legacy to httpbin.bar: 000
+curl.legacy to httpbin.bar: 000
 command terminated with exit code 56
-sleep.legacy to httpbin.legacy: 200
+curl.legacy to httpbin.legacy: 200
 {{< /text >}}
 
 {{< text plain >}}
 ...
-sleep.legacy to httpbin.bar: 000
+curl.legacy to httpbin.bar: 000
 command terminated with exit code 56
 {{< /text >}}
 
@@ -252,22 +252,22 @@ EOF
 2. Ви можете використовувати `portLevelMtls` тільки якщо порт привʼязано до сервісу. В іншому випадку Istio ігнорує його.
 
 {{< text bash >}}
-$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
-sleep.foo to httpbin.foo: 200
-sleep.foo to httpbin.bar: 200
-sleep.foo to httpbin.legacy: 200
-sleep.bar to httpbin.foo: 200
-sleep.bar to httpbin.bar: 200
-sleep.bar to httpbin.legacy: 200
-sleep.legacy to httpbin.foo: 000
+$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
+curl.foo to httpbin.foo: 200
+curl.foo to httpbin.bar: 200
+curl.foo to httpbin.legacy: 200
+curl.bar to httpbin.foo: 200
+curl.bar to httpbin.bar: 200
+curl.bar to httpbin.legacy: 200
+curl.legacy to httpbin.foo: 000
 command terminated with exit code 56
-sleep.legacy to httpbin.bar: 200
-sleep.legacy to httpbin.legacy: 200
+curl.legacy to httpbin.bar: 200
+curl.legacy to httpbin.legacy: 200
 {{< /text >}}
 
 ### Пріоритет політики {#policy-precedence}
 
-Політика однорангової автентифікації для конкретного робочого навантаження має пріоритет над політикою для всього простору імен. Ви можете перевірити таку поведінку, додавши політику вимкнення взаємного TLS для робочого навантаження `httpbin.foo`, наприклад. Зверніть увагу, що ви вже створили політику для всього простору імен, яка вмикає взаємне TLS для всіх служб у просторі імен `foo`, і помітили, що запити від `sleep.legacy` до `httpbin.foo` зазнають невдачі (див. вище).
+Політика однорангової автентифікації для конкретного робочого навантаження має пріоритет над політикою для всього простору імен. Ви можете перевірити таку поведінку, додавши політику вимкнення взаємного TLS для робочого навантаження `httpbin.foo`, наприклад. Зверніть увагу, що ви вже створили політику для всього простору імен, яка вмикає взаємне TLS для всіх служб у просторі імен `foo`, і помітили, що запити від `curl.legacy` до `httpbin.foo` зазнають невдачі (див. вище).
 
 {{< text bash >}}
 $ cat <<EOF | kubectl apply -n foo -f -
@@ -285,10 +285,10 @@ spec:
 EOF
 {{< /text >}}
 
-Повторно запустивши запит з `sleep.legacy`, ви знову побачите успішний код повернення (200), що підтверджує перевизначення політики для конкретного сервісу по відношенню до політики для всього простору імен.
+Повторно запустивши запит з `curl.legacy`, ви знову побачите успішний код повернення (200), що підтверджує перевизначення політики для конкретного сервісу по відношенню до політики для всього простору імен.
 
 {{< text bash >}}
-$ kubectl exec "$(kubectl get pod -l app=sleep -n legacy -o jsonpath={.items..metadata.name})" -c sleep -n legacy -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
+$ kubectl exec "$(kubectl get pod -l app=curl -n legacy -o jsonpath={.items..metadata.name})" -c curl -n legacy -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
 200
 {{< /text >}}
 

content/uk/docs/tasks/security/authentication/claim-to-header/index.md

@@ -27,19 +27,19 @@ status: Experimental
 
 * Встановіть Istio за допомогою [посібника з установки Istio](/docs/setup/install/istioctl/).
 
-* Розгорніть навантаження `httpbin` та `sleep` в просторі імен `foo` з увімкненою інʼєкцією sidecar. Розгорніть приклад простору імен і навантаження за допомогою цих команд:
+* Розгорніть навантаження `httpbin` та `curl` в просторі імен `foo` з увімкненою інʼєкцією sidecar. Розгорніть приклад простору імен і навантаження за допомогою цих команд:
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl label namespace foo istio-injection=enabled
     $ kubectl apply -f @samples/httpbin/httpbin.yaml@ -n foo
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n foo
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n foo
     {{< /text >}}
 
-* Переконайтеся, що `sleep` успішно взаємодіє з `httpbin` за допомогою цієї команди:
+* Переконайтеся, що `curl` успішно взаємодіє з `httpbin` за допомогою цієї команди:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -74,7 +74,7 @@ status: Experimental
 1. Переконайтеся, що запит з недійсним JWT відхилено:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer invalidToken" -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer invalidToken" -w "%{http_code}\n"
     401
     {{< /text >}}
 
@@ -88,15 +88,15 @@ status: Experimental
 1. Переконайтеся, що запит з дійсним JWT дозволено:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"
     200
     {{< /text >}}
 
 1. Переконайтеся, що запит містить дійсний HTTP-заголовок зі значенням заявки JWT:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -H "Authorization: Bearer $TOKEN" | grep "X-Jwt-Claim-Foo" | sed -e 's/^[ \t]*//'
-    "X-Jwt-Claim-Foo": "bar"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -H "Authorization: Bearer $TOKEN" | jq '.headers["X-Jwt-Claim-Foo"][0]'
+    "bar"
     {{< /text >}}
 
 ## Очищення {#clean-up}

content/uk/docs/tasks/security/authentication/mtls-migration/index.md

@@ -29,34 +29,34 @@ Istio автоматично конфігурує sidecar-и навантаже
 
 ## Налаштування кластера {#set-up-the-cluster}
 
-* Створіть два простори імен, `foo` та `bar`, і розгорніть [httpbin]({{< github_tree >}}/samples/httpbin) та [sleep]({{< github_tree >}}/samples/sleep) з sidecar-ами в обох:
+* Створіть два простори імен, `foo` та `bar`, і розгорніть [httpbin]({{< github_tree >}}/samples/httpbin) та [curl]({{< github_tree >}}/samples/curl) з sidecar-ами в обох:
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n foo
     $ kubectl create ns bar
     $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n bar
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n bar
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n bar
     {{< /text >}}
 
-* Створіть інший простір імен, `legacy`, і розгорніть [sleep]({{< github_tree >}}/samples/sleep) без sidecar:
+* Створіть інший простір імен, `legacy`, і розгорніть [curl]({{< github_tree >}}/samples/curl) без sidecar:
 
     {{< text bash >}}
     $ kubectl create ns legacy
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n legacy
     {{< /text >}}
 
-* Перевірте налаштування, надіславши HTTP запити (з використанням curl) з podʼів `sleep`, у просторах імен `foo`, `bar` і `legacy`, до `httpbin.foo` і `httpbin.bar`. Всі запити повинні успішно завершитися з кодом повернення 200.
+* Перевірте налаштування, надіславши HTTP запити (з використанням curl) з podʼів `curl`, у просторах імен `foo`, `bar` і `legacy`, до `httpbin.foo` і `httpbin.bar`. Всі запити повинні успішно завершитися з кодом повернення 200.
 
     {{< text bash >}}
-    $ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
-    sleep.foo to httpbin.foo: 200
-    sleep.foo to httpbin.bar: 200
-    sleep.bar to httpbin.foo: 200
-    sleep.bar to httpbin.bar: 200
-    sleep.legacy to httpbin.foo: 200
-    sleep.legacy to httpbin.bar: 200
+    $ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
+    curl.foo to httpbin.foo: 200
+    curl.foo to httpbin.bar: 200
+    curl.bar to httpbin.foo: 200
+    curl.bar to httpbin.bar: 200
+    curl.legacy to httpbin.foo: 200
+    curl.legacy to httpbin.bar: 200
     {{< /text >}}
 
     {{< tip >}}
@@ -90,17 +90,17 @@ spec:
 EOF
 {{< /text >}}
 
-Тепер ви повинні побачити, що запит від `sleep.legacy` до `httpbin.foo` зазнає невдачі.
+Тепер ви повинні побачити, що запит від `curl.legacy` до `httpbin.foo` зазнає невдачі.
 
 {{< text bash >}}
-$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
-sleep.foo to httpbin.foo: 200
-sleep.foo to httpbin.bar: 200
-sleep.bar to httpbin.foo: 200
-sleep.bar to httpbin.bar: 200
-sleep.legacy to httpbin.foo: 000
+$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
+curl.foo to httpbin.foo: 200
+curl.foo to httpbin.bar: 200
+curl.bar to httpbin.foo: 200
+curl.bar to httpbin.bar: 200
+curl.legacy to httpbin.foo: 000
 command terminated with exit code 56
-sleep.legacy to httpbin.bar: 200
+curl.legacy to httpbin.bar: 200
 {{< /text >}}
 
 Якщо ви встановили Istio з `values.global.proxy.privileged=true`, ви можете використовувати `tcpdump` для перевірки, чи зашифровано трафік.
@@ -111,7 +111,7 @@ tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
 {{< /text >}}
 
-Ви побачите як незашифрований, так і зашифрований текст у виводі, коли запити надсилаються з `sleep.legacy` і `sleep.foo` відповідно.
+Ви побачите як незашифрований, так і зашифрований текст у виводі, коли запити надсилаються з `curl.legacy` і `curl.foo` відповідно.
 
 Якщо ви не можете мігрувати всі свої сервіси на Istio (тобто, зробити інʼєкцію sidecar Envoy у всі з них), вам слід продовжити використовувати режим `PERMISSIVE`. Однак у режимі `PERMISSIVE` стандартно жодні перевірки автентифікації чи авторизації не будуть виконані для звичайного трафіку. Рекомендуємо використовувати [Авторизацію Istio](/docs/tasks/security/authorization/authz-http/) для конфігурації різних шляхів з різними політиками авторизації.
 
@@ -131,10 +131,10 @@ spec:
 EOF
 {{< /text >}}
 
-Тепер обидва простори імен `foo` і `bar` забезпечують взаємний трафік тільки з TLS, тому ви повинні бачити, що запити з `sleep.legacy` в обох просторах.
+Тепер обидва простори імен `foo` і `bar` забезпечують взаємний трафік тільки з TLS, тому ви повинні бачити, що запити з `curl.legacy` в обох просторах.
 
 {{< text bash >}}
-$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name})" -c sleep -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
+$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl http://httpbin.${to}:8000/ip -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
 {{< /text >}}
 
 ## Очищення прикладу {#clean-up-the-example}

content/uk/docs/tasks/security/authorization/authz-custom/index.md

@@ -19,19 +19,19 @@ test: yes
 
 * Розгорніть тестові робочі навантаження:
 
-    Це завдання використовує два робочі навантаження, `httpbin` та `sleep`, обидва розгорнуті в просторі імен `foo`. Обидва робочі навантаження працюють з sidecar проксі Envoy. Розгорніть простір імен `foo` і робочі навантаження за допомогою наступної команди:
+    Це завдання використовує два робочі навантаження, `httpbin` та `curl`, обидва розгорнуті в просторі імен `foo`. Обидва робочі навантаження працюють з sidecar проксі Envoy. Розгорніть простір імен `foo` і робочі навантаження за допомогою наступної команди:
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl label ns foo istio-injection=enabled
     $ kubectl apply -f @samples/httpbin/httpbin.yaml@ -n foo
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n foo
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n foo
     {{< /text >}}
 
-* Перевірте, чи `sleep` може отримати доступ до `httpbin` за допомогою наступної команди:
+* Перевірте, чи `curl` може отримати доступ до `httpbin` за допомогою наступної команди:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -167,35 +167,25 @@ spec:
 1. Перевірте, що запит до шляху `/headers` з заголовком `x-ext-authz: deny` відхилено демонстраційним сервером `ext_authz`:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -H "x-ext-authz: deny" -s
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -H "x-ext-authz: deny" -s
     denied by ext_authz for not found header `x-ext-authz: allow` in the request
     {{< /text >}}
 
 1. Перевірте, що запит до шляху `/headers` з заголовком `x-ext-authz: allow` дозволено демонстраційним сервером `ext_authz`:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -H "x-ext-authz: allow" -s
-    {
-      "headers": {
-        "Accept": "*/*",
-        "Host": "httpbin:8000",
-        "User-Agent": "curl/7.76.0-DEV",
-        "X-B3-Parentspanid": "430f770aeb7ef215",
-        "X-B3-Sampled": "0",
-        "X-B3-Spanid": "60ff95c5acdf5288",
-        "X-B3-Traceid": "fba72bb5765daf5a430f770aeb7ef215",
-        "X-Envoy-Attempt-Count": "1",
-        "X-Ext-Authz": "allow",
-        "X-Ext-Authz-Check-Result": "allowed",
-        "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=e5178ee79066bfbafb1d98044fcd0cf80db76be8714c7a4b630c7922df520bf2;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"
-      }
-    }
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -H "x-ext-authz: allow" -s | jq '.headers'
+    ...
+      "X-Ext-Authz-Check-Result": [
+        "allowed"
+      ],
+    ...
     {{< /text >}}
 
 1. Перевірте, що запит до шляху `/ip` є дозволеним і не викликає зовнішню авторизацію:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/ip" -s -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/ip" -s -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -205,11 +195,11 @@ spec:
     $ kubectl logs "$(kubectl get pod -l app=ext-authz -n foo -o jsonpath={.items..metadata.name})" -n foo -c ext-authz
     2021/01/07 22:55:47 Starting HTTP server at [::]:8000
     2021/01/07 22:55:47 Starting gRPC server at [::]:9000
-    2021/01/08 03:25:00 [gRPCv3][denied]: httpbin.foo:8000/headers, attributes: source:{address:{socket_address:{address:"10.44.0.22"  port_value:52088}}  principal:"spiffe://cluster.local/ns/foo/sa/sleep"}  destination:{address:{socket_address:{address:"10.44.3.30"  port_value:80}}  principal:"spiffe://cluster.local/ns/foo/sa/httpbin"}  request:{time:{seconds:1610076306  nanos:473835000}  http:{id:"13869142855783664817"  method:"GET"  headers:{key:":authority"  value:"httpbin.foo:8000"}  headers:{key:":method"  value:"GET"}  headers:{key:":path"  value:"/headers"}  headers:{key:"accept"  value:"*/*"}  headers:{key:"content-length"  value:"0"}  headers:{key:"user-agent"  value:"curl/7.74.0-DEV"}  headers:{key:"x-b3-sampled"  value:"1"}  headers:{key:"x-b3-spanid"  value:"377ba0cdc2334270"}  headers:{key:"x-b3-traceid"  value:"635187cb20d92f62377ba0cdc2334270"}  headers:{key:"x-envoy-attempt-count"  value:"1"}  headers:{key:"x-ext-authz"  value:"deny"}  headers:{key:"x-forwarded-client-cert"  value:"By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=dd14782fa2f439724d271dbed846ef843ff40d3932b615da650d028db655fc8d;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"}  headers:{key:"x-forwarded-proto"  value:"http"}  headers:{key:"x-request-id"  value:"9609691a-4e9b-9545-ac71-3889bc2dffb0"}  path:"/headers"  host:"httpbin.foo:8000"  protocol:"HTTP/1.1"}}  metadata_context:{}
-    2021/01/08 03:25:06 [gRPCv3][allowed]: httpbin.foo:8000/headers, attributes: source:{address:{socket_address:{address:"10.44.0.22"  port_value:52184}}  principal:"spiffe://cluster.local/ns/foo/sa/sleep"}  destination:{address:{socket_address:{address:"10.44.3.30"  port_value:80}}  principal:"spiffe://cluster.local/ns/foo/sa/httpbin"}  request:{time:{seconds:1610076300  nanos:925912000}  http:{id:"17995949296433813435"  method:"GET"  headers:{key:":authority"  value:"httpbin.foo:8000"}  headers:{key:":method"  value:"GET"}  headers:{key:":path"  value:"/headers"}  headers:{key:"accept"  value:"*/*"}  headers:{key:"content-length"  value:"0"}  headers:{key:"user-agent"  value:"curl/7.74.0-DEV"}  headers:{key:"x-b3-sampled"  value:"1"}  headers:{key:"x-b3-spanid"  value:"a66b5470e922fa80"}  headers:{key:"x-b3-traceid"  value:"300c2f2b90a618c8a66b5470e922fa80"}  headers:{key:"x-envoy-attempt-count"  value:"1"}  headers:{key:"x-ext-authz"  value:"allow"}  headers:{key:"x-forwarded-client-cert"  value:"By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=dd14782fa2f439724d271dbed846ef843ff40d3932b615da650d028db655fc8d;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"}  headers:{key:"x-forwarded-proto"  value:"http"}  headers:{key:"x-request-id"  value:"2b62daf1-00b9-97d9-91b8-ba6194ef58a4"}  path:"/headers"  host:"httpbin.foo:8000"  protocol:"HTTP/1.1"}}  metadata_context:{}
+    2021/01/08 03:25:00 [gRPCv3][denied]: httpbin.foo:8000/headers, attributes: source:{address:{socket_address:{address:"10.44.0.22"  port_value:52088}}  principal:"spiffe://cluster.local/ns/foo/sa/curl"}  destination:{address:{socket_address:{address:"10.44.3.30"  port_value:80}}  principal:"spiffe://cluster.local/ns/foo/sa/httpbin"}  request:{time:{seconds:1610076306  nanos:473835000}  http:{id:"13869142855783664817"  method:"GET"  headers:{key:":authority"  value:"httpbin.foo:8000"}  headers:{key:":method"  value:"GET"}  headers:{key:":path"  value:"/headers"}  headers:{key:"accept"  value:"*/*"}  headers:{key:"content-length"  value:"0"}  headers:{key:"user-agent"  value:"curl/7.74.0-DEV"}  headers:{key:"x-b3-sampled"  value:"1"}  headers:{key:"x-b3-spanid"  value:"377ba0cdc2334270"}  headers:{key:"x-b3-traceid"  value:"635187cb20d92f62377ba0cdc2334270"}  headers:{key:"x-envoy-attempt-count"  value:"1"}  headers:{key:"x-ext-authz"  value:"deny"}  headers:{key:"x-forwarded-client-cert"  value:"By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=dd14782fa2f439724d271dbed846ef843ff40d3932b615da650d028db655fc8d;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/curl"}  headers:{key:"x-forwarded-proto"  value:"http"}  headers:{key:"x-request-id"  value:"9609691a-4e9b-9545-ac71-3889bc2dffb0"}  path:"/headers"  host:"httpbin.foo:8000"  protocol:"HTTP/1.1"}}  metadata_context:{}
+    2021/01/08 03:25:06 [gRPCv3][allowed]: httpbin.foo:8000/headers, attributes: source:{address:{socket_address:{address:"10.44.0.22"  port_value:52184}}  principal:"spiffe://cluster.local/ns/foo/sa/curl"}  destination:{address:{socket_address:{address:"10.44.3.30"  port_value:80}}  principal:"spiffe://cluster.local/ns/foo/sa/httpbin"}  request:{time:{seconds:1610076300  nanos:925912000}  http:{id:"17995949296433813435"  method:"GET"  headers:{key:":authority"  value:"httpbin.foo:8000"}  headers:{key:":method"  value:"GET"}  headers:{key:":path"  value:"/headers"}  headers:{key:"accept"  value:"*/*"}  headers:{key:"content-length"  value:"0"}  headers:{key:"user-agent"  value:"curl/7.74.0-DEV"}  headers:{key:"x-b3-sampled"  value:"1"}  headers:{key:"x-b3-spanid"  value:"a66b5470e922fa80"}  headers:{key:"x-b3-traceid"  value:"300c2f2b90a618c8a66b5470e922fa80"}  headers:{key:"x-envoy-attempt-count"  value:"1"}  headers:{key:"x-ext-authz"  value:"allow"}  headers:{key:"x-forwarded-client-cert"  value:"By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=dd14782fa2f439724d271dbed846ef843ff40d3932b615da650d028db655fc8d;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/curl"}  headers:{key:"x-forwarded-proto"  value:"http"}  headers:{key:"x-request-id"  value:"2b62daf1-00b9-97d9-91b8-ba6194ef58a4"}  path:"/headers"  host:"httpbin.foo:8000"  protocol:"HTTP/1.1"}}  metadata_context:{}
     {{< /text >}}
 
-    З журналу також видно, що mTLS увімкнено для з'єднання між фільтром `ext-authz` і демонстраційним сервером `ext-authz`, оскільки принципала джерела заповнено значенням `spiffe://cluster.local/ns/foo/sa/sleep`.
+    З журналу також видно, що mTLS увімкнено для з'єднання між фільтром `ext-authz` і демонстраційним сервером `ext-authz`, оскільки принципала джерела заповнено значенням `spiffe://cluster.local/ns/foo/sa/curl`.
 
     Тепер ви можете застосувати іншу політику авторизації для демонстраційного сервера `ext-authz`, щоб контролювати, кому дозволено доступ до нього.
 

content/uk/docs/tasks/security/authorization/authz-deny/index.md

@@ -19,18 +19,18 @@ test: yes
 
 * Розгорніть навантаження:
 
-    Це завдання використовує два навантаження, `httpbin` та `sleep`, розгорнуті в одному просторі імен, `foo`. Обидва навантаження працюють з проксі Envoy попереду. Розгорніть приклад простору імен та навантаження за допомогою наступної команди:
+    Це завдання використовує два навантаження, `httpbin` та `curl`, розгорнуті в одному просторі імен, `foo`. Обидва навантаження працюють з проксі Envoy попереду. Розгорніть приклад простору імен та навантаження за допомогою наступної команди:
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n foo
     {{< /text >}}
 
-* Перевірте, що `sleep` звертається до `httpbin` за допомогою наступної команди:
+* Перевірте, що `curl` звертається до `httpbin` за допомогою наступної команди:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -64,14 +64,14 @@ test: yes
 2. Перевірте, що запити `GET` відхиляються:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/get" -X GET -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/get" -X GET -sS -o /dev/null -w "%{http_code}\n"
     403
     {{< /text >}}
 
 3. Перевірте, що запити `POST` дозволені:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/post" -X POST -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/post" -X POST -sS -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -102,14 +102,14 @@ test: yes
 5. Перевірте, що запити `GET` з заголовком HTTP `x-token: admin` дозволені:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/get" -X GET -H "x-token: admin" -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/get" -X GET -H "x-token: admin" -sS -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
 6. Перевірте, що запити `GET` з заголовком HTTP `x-token: guest` відхиляються:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/get" -X GET -H "x-token: guest" -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/get" -X GET -H "x-token: guest" -sS -o /dev/null -w "%{http_code}\n"
     403
     {{< /text >}}
 
@@ -137,21 +137,21 @@ test: yes
 8. Перевірте, що запити `GET` з заголовком HTTP `x-token: guest` на шлях `/ip` відхиляються політикою `deny-method-get`. Політики відмови мають пріоритет над політиками дозволу:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/ip" -X GET -H "x-token: guest" -s -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/ip" -X GET -H "x-token: guest" -s -o /dev/null -w "%{http_code}\n"
     403
     {{< /text >}}
 
 9. Перевірте, що запити `GET` з заголовком HTTP `x-token: admin` на шлях `/ip` є дозволеними політикою `allow-path-ip`:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/ip" -X GET -H "x-token: admin" -s -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/ip" -X GET -H "x-token: admin" -s -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
 10. Перевірте, що запити `GET` з заголовком HTTP `x-token: admin` на шлях `/get` є відхиленими, оскільки вони не відповідають політиці `allow-path-ip`:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/get" -X GET -H "x-token: admin" -s -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/get" -X GET -H "x-token: admin" -s -o /dev/null -w "%{http_code}\n"
     403
     {{< /text >}}
 

content/uk/docs/tasks/security/authorization/authz-dry-run/index.md

@@ -20,7 +20,7 @@ status: Alpha
 
 * Ознайомтесь з [поняттями авторизації Istio](/docs/concepts/security/#authorization).
 
-* Дотримуйтесь [інструкції з встановлення Istio](/docs/setup/install/istioctl/) для встановлення.
+* Дотримуйтесь [інструкції з встановлення Istio](/docs/setup/install) для встановлення.
 
 * Розгорніть Zipkin для перевірки результатів симуляції. Дотримуйтесь [завдання Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/) для встановлення Zipkin у кластер.
 
@@ -28,13 +28,13 @@ status: Alpha
 
 * Розгорніть тестові робочі навантаження:
 
-    Ця задача використовує два робочих навантаження, `httpbin` та `sleep`, обидва розгорнуті в просторі імен `foo`. Обидва робочих навантаження працюють з sidecar проксі Envoy. Створіть простір імен `foo` і розгорніть робочі навантаження за допомогою наступної команди:
+    Ця задача використовує два робочих навантаження, `httpbin` та `curl`, обидва розгорнуті в просторі імен `foo`. Обидва робочих навантаження працюють з sidecar проксі Envoy. Створіть простір імен `foo` і розгорніть робочі навантаження за допомогою наступної команди:
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl label ns foo istio-injection=enabled
     $ kubectl apply -f @samples/httpbin/httpbin.yaml@ -n foo
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n foo
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n foo
     {{< /text >}}
 
 * Увімкніть рівень журналів налагодження проксі для перевірки результатів симуляції журналювання:
@@ -44,10 +44,10 @@ status: Alpha
     rbac: debug
     {{< /text >}}
 
-* Перевірте, чи може `sleep` отримати доступ до `httpbin` за допомогою наступної команди:
+* Перевірте, чи може `curl` отримати доступ до `httpbin` за допомогою наступної команди:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -85,10 +85,10 @@ status: Alpha
     $ kubectl annotate --overwrite authorizationpolicies deny-path-headers -n foo istio.io/dry-run='true'
     {{< /text >}}
 
-1. Перевірте, що запити до шляху `/headers` дозволені, оскільки політика створена в режимі симуляції, запустіть наступну команду для надсилання 20 запитів від `sleep` до `httpbin`, запит включає заголовок `X-B3-Sampled: 1`, щоб завжди активувати трасування Zipkin:
+1. Перевірте, що запити до шляху `/headers` дозволені, оскільки політика створена в режимі симуляції, запустіть наступну команду для надсилання 20 запитів від `curl` до `httpbin`, запит включає заголовок `X-B3-Sampled: 1`, щоб завжди активувати трасування Zipkin:
 
     {{< text bash >}}
-    $ for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/headers -H "X-B3-Sampled: 1" -s -o /dev/null -w "%{http_code}\n"; done
+    $ for i in {1..20}; do kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/headers -H "X-B3-Sampled: 1" -s -o /dev/null -w "%{http_code}\n"; done
     200
     200
     200
@@ -143,7 +143,7 @@ $ kubectl logs "$(kubectl -n foo -l app=httpbin get pods -o jsonpath={.items..me
     $ istioctl dashboard zipkin
     {{< /text >}}
 
-2. Знайдіть результат трасування для запиту від `sleep` до `httpbin`. Спробуйте надіслати ще кілька запитів, якщо ви не бачите результат трасування через затримку в Zipkin.
+2. Знайдіть результат трасування для запиту від `curl` до `httpbin`. Спробуйте надіслати ще кілька запитів, якщо ви не бачите результат трасування через затримку в Zipkin.
 
 3. У результаті трасування ви повинні знайти наступні власні теґи, що вказують на те, що запит відхилено політикою симуляції `deny-path-headers` у просторі імен `foo`:
 

content/uk/docs/tasks/security/authorization/authz-jwt/index.md

@@ -22,18 +22,18 @@ test: yes
 
 * Встановіть Istio за допомогою [інструкції з встановлення Istio](/docs/setup/install/istioctl/).
 
-* Розгорніть два навантаження: `httpbin` та `sleep`. Розгорніть їх в одному просторі імен, наприклад, `foo`. Обидва навантаження працюють з проксі Envoy перед кожним. Розгорніть простір імен та навантаження за допомогою цих команд:
+* Розгорніть два навантаження: `httpbin` та `curl`. Розгорніть їх в одному просторі імен, наприклад, `foo`. Обидва навантаження працюють з проксі Envoy перед кожним. Розгорніть простір імен та навантаження за допомогою цих команд:
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n foo
     {{< /text >}}
 
-* Переконайтесь, що `sleep` успішно спілкується з `httpbin`, використовуючи цю команду:
+* Переконайтесь, що `curl` успішно спілкується з `httpbin`, використовуючи цю команду:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -65,14 +65,14 @@ test: yes
 1. Перевірте, що запит з недійсним JWT відхилено:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer invalidToken" -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer invalidToken" -w "%{http_code}\n"
     401
     {{< /text >}}
 
 1. Перевірте, що запит без JWT дозволено, оскільки політики авторизації немає:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -100,21 +100,21 @@ test: yes
 1. Отримайте JWT, що встановлює ключі `iss` і `sub` до однакового значення `testing@secure.istio.io`. Це дозволяє Istio згенерувати атрибут `requestPrincipal` зі значенням `testing@secure.istio.io/testing@secure.istio.io`:
 
     {{< text syntax="bash" expandlinks="false" >}}
-    $ TOKEN=$(curl {{< github_file >}}/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
+    $ TOKEN=$(curl {{< github_file >}}/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode
     {"exp":4685989700,"foo":"bar","iat":1532389700,"iss":"testing@secure.istio.io","sub":"testing@secure.istio.io"}
     {{< /text >}}
 
 1. Перевірте, що запит з дійсним JWT дозволено:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"
     200
     {{< /text >}}
 
 1. Перевірте, що запит без JWT відхилено:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -w "%{http_code}\n"
     403
     {{< /text >}}
 
@@ -150,21 +150,21 @@ test: yes
 1. Отримайте JWT, що додає заявку `groups` у список рядків: `group1` та `group2`:
 
     {{< text syntax="bash" expandlinks="false" >}}
-    $ TOKEN_GROUP=$(curl {{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt -s) && echo "$TOKEN_GROUP" | cut -d '.' -f2 - | base64 --decode -
+    $ TOKEN_GROUP=$(curl {{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt -s) && echo "$TOKEN_GROUP" | cut -d '.' -f2 - | base64 --decode
     {"exp":3537391104,"groups":["group1","group2"],"iat":1537391104,"iss":"testing@secure.istio.io","scope":["scope1","scope2"],"sub":"testing@secure.istio.io"}
     {{< /text >}}
 
 1. Перевірте, що запит з JWT, який містить `group1` у заявці `groups`, дозволено:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN_GROUP" -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN_GROUP" -w "%{http_code}\n"
     200
     {{< /text >}}
 
 1. Переконайтеся, що запит з JWT, який не має заявки `groups`, відхилено:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl "http://httpbin.foo:8000/headers" -sS -o /dev/null -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n"
     403
     {{< /text >}}
 

content/uk/docs/tasks/security/authorization/authz-tcp/index.md

@@ -19,38 +19,38 @@ test: yes
 
 * Встановіть Istio, використовуючи [посібник з установки Istio](/docs/setup/install/istioctl/).
 
-* Розгорніть два навантаження з іменами `sleep` та `tcp-echo` разом у просторі імен, наприклад, `foo`. Обидва навантаження працюють з проксі Envoy попереду кожного з них. Навантаження `tcp-echo` слухає порти 9000, 9001 та 9002 та відповідає будь-якому отриманому трафіку з префіксом `hello`. Наприклад, якщо ви надішлете "world" на `tcp-echo`, він відповість `hello world`. Обʼєкт сервісу Kubernetes `tcp-echo` оголошує тільки порти 9000 і 9001, і не вказує порт 9002. Трафік на порт 9002 буде оброблятися через фільтр прохідного зʼєднання. Розгорніть приклад простору імен та навантаження, використовуючи наступну команду:
+* Розгорніть два навантаження з іменами `curl` та `tcp-echo` разом у просторі імен, наприклад, `foo`. Обидва навантаження працюють з проксі Envoy попереду кожного з них. Навантаження `tcp-echo` слухає порти 9000, 9001 та 9002 та відповідає будь-якому отриманому трафіку з префіксом `hello`. Наприклад, якщо ви надішлете "world" на `tcp-echo`, він відповість `hello world`. Обʼєкт сервісу Kubernetes `tcp-echo` оголошує тільки порти 9000 і 9001, і не вказує порт 9002. Трафік на порт 9002 буде оброблятися через фільтр прохідного зʼєднання. Розгорніть приклад простору імен та навантаження, використовуючи наступну команду:
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl apply -f <(istioctl kube-inject -f @samples/tcp-echo/tcp-echo.yaml@) -n foo
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n foo
     {{< /text >}}
 
-* Перевірте, чи `sleep` успішно комунікує з `tcp-echo` на портах 9000 та 9001, використовуючи наступну команду:
+* Перевірте, чи `curl` успішно комунікує з `tcp-echo` на портах 9000 та 9001, використовуючи наступну команду:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     hello port 9000
     connection succeeded
     {{< /text >}}
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9001" | nc tcp-echo 9001' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     hello port 9001
     connection succeeded
     {{< /text >}}
 
-* Перевірте, чи `sleep` успішно комунікує з `tcp-echo` на порту 9002. Вам потрібно надіслати трафік безпосередньо на IP-адресу pod `tcp-echo`, оскільки порт 9002 не визначений у обʼєкті сервісу Kubernetes `tcp-echo`. Отримайте IP-адресу pod і надішліть запит наступною командою:
+* Перевірте, чи `curl` успішно комунікує з `tcp-echo` на порту 9002. Вам потрібно надіслати трафік безпосередньо на IP-адресу pod `tcp-echo`, оскільки порт 9002 не визначений у обʼєкті сервісу Kubernetes `tcp-echo`. Отримайте IP-адресу pod і надішліть запит наступною командою:
 
     {{< text bash >}}
     $ TCP_ECHO_IP=$(kubectl get pod "$(kubectl get pod -l app=tcp-echo -n foo -o jsonpath={.items..metadata.name})" -n foo -o jsonpath="{.status.podIP}")
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         "echo \"port 9002\" | nc $TCP_ECHO_IP 9002" | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     hello port 9002
     connection succeeded
@@ -86,8 +86,8 @@ test: yes
 1. Перевірте, чи запити на порт 9000 дозволені, використовуючи наступну команду:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     hello port 9000
     connection succeeded
@@ -96,8 +96,8 @@ test: yes
 1. Перевірте, чи запити на порт 9001 дозволені, використовуючи наступну команду:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9001" | nc tcp-echo 9001' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     hello port 9001
     connection succeeded
@@ -106,8 +106,8 @@ test: yes
 1. Перевірте, чи запити на порт 9002 відхилені. Це забезпечується політикою авторизації, яка також застосовується до фільтра прохідного зʼєднання, навіть якщо порт не оголошений явно в обʼєкті сервісу Kubernetes `tcp-echo`. Виконайте наступну команду та перевірте результат:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         "echo \"port 9002\" | nc $TCP_ECHO_IP 9002" | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     connection rejected
     {{< /text >}}
@@ -137,8 +137,8 @@ test: yes
 1. Перевірте, чи запити на порт 9000 відхилені. Це відбувається, тому що правило стає недійсним, коли використовуються поля тільки для HTTP (`methods`) для TCP-трафіку. Istio ігнорує недійсне правило ALLOW. Остаточний результат — запит відхилено, оскільки він не відповідає жодним ALLOW правилам. Виконайте наступну команду та перевірте результат:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     connection rejected
     {{< /text >}}
@@ -146,8 +146,8 @@ test: yes
 1. Перевірте, чи запити на порт 9001 відхилені. Це відбувається, оскільки запити не відповідають жодним ALLOW правилам. Виконайте наступну команду та перевірте результат:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9001" | nc tcp-echo 9001' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     connection rejected
     {{< /text >}}
@@ -178,8 +178,8 @@ test: yes
 1. Перевірте, чи запити на порт 9000 відхилені. Це відбувається тому, що Istio не розуміє поля тільки для HTTP при створенні правила DENY для TCP-порту, і через свою обмежувальну природу він блокує весь трафік до TCP-портів:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     connection rejected
     {{< /text >}}
@@ -187,8 +187,8 @@ test: yes
 1. Перевірте, чи запити на порт 9001 відхилені. Та сама причина, що й вище.
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9001" | nc tcp-echo 9001' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     connection rejected
     {{< /text >}}
@@ -218,8 +218,8 @@ test: yes
 1. Перевірте, чи запити на порт 9000 відхилені. Це відбувається, тому що запит відповідає `ports` у згаданій вище політиці DENY.
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9000" | nc tcp-echo 9000' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     connection rejected
     {{< /text >}}
@@ -227,8 +227,8 @@ test: yes
 1. Перевірте, чи запити на порт 9001 дозволені. Це відбувається, тому що запити не відповідають `ports` у політиці DENY:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" \
-        -c sleep -n foo -- sh -c \
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" \
+        -c curl -n foo -- sh -c \
         'echo "port 9001" | nc tcp-echo 9001' | grep "hello" && echo 'connection succeeded' || echo 'connection rejected'
     hello port 9001
     connection succeeded

content/uk/docs/tasks/security/authorization/authz-td-migration/index.md

@@ -1,5 +1,5 @@
 ---
-title: Міграція домену довіри  
+title: Міграція домену довіри
 description: Показує, як мігрувати з одного домену довіри в інший без зміни політики авторизації.
 weight: 60
 keywords: [security,access-control,rbac,authorization,trust domain, migration]
@@ -23,18 +23,18 @@ test: yes
     $ istioctl install --set profile=demo --set meshConfig.trustDomain=old-td
     {{< /text >}}
 
-1. Розгорніть демонстраційний застосунок [httpbin]({{< github_tree >}}/samples/httpbin) у просторі імен `default`, а [sleep]({{< github_tree >}}/samples/sleep) — у просторах імен `default` та `sleep-allow`:
+1. Розгорніть демонстраційний застосунок [httpbin]({{< github_tree >}}/samples/httpbin) у просторі імен `default`, а [curl]({{< github_tree >}}/samples/curl) — у просторах імен `default` та `curl-allow`:
 
     {{< text bash >}}
     $ kubectl label namespace default istio-injection=enabled
     $ kubectl apply -f @samples/httpbin/httpbin.yaml@
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
-    $ kubectl create namespace sleep-allow
-    $ kubectl label namespace sleep-allow istio-injection=enabled
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n sleep-allow
+    $ kubectl apply -f @samples/curl/curl.yaml@
+    $ kubectl create namespace curl-allow
+    $ kubectl label namespace curl-allow istio-injection=enabled
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n curl-allow
     {{< /text >}}
 
-1. Застосуйте політику авторизації нижче, щоб заборонити всі запити до `httpbin`, крім запитів від `sleep` у просторі імен `sleep-allow`.
+1. Застосуйте політику авторизації нижче, щоб заборонити всі запити до `httpbin`, крім запитів від `curl` у просторі імен `curl-allow`.
 
     {{< text bash >}}
     $ kubectl apply -f - <<EOF
@@ -48,7 +48,7 @@ test: yes
       - from:
         - source:
             principals:
-            - old-td/ns/sleep-allow/sa/sleep
+            - old-td/ns/curl-allow/sa/curl
         to:
         - operation:
             methods:
@@ -64,17 +64,17 @@ test: yes
 
 1. Перевірте, що запити до `httpbin` з:
 
-    * `sleep` в просторі імен `default` відхилені.
+    * `curl` в просторі імен `default` відхилені.
 
         {{< text bash >}}
-        $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+        $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
         403
         {{< /text >}}
 
-    * `sleep` в просторі імен `sleep-allow` дозволені.
+    * `curl` в просторі імен `curl-allow` дозволені.
 
         {{< text bash >}}
-        $ kubectl exec "$(kubectl -n sleep-allow get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -n sleep-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+        $ kubectl exec "$(kubectl -n curl-allow get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -n curl-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
         200
         {{< /text >}}
 
@@ -94,29 +94,29 @@ test: yes
 
     Istio mesh тепер працює з новим доменом довіри, `new-td`.
 
-2. Перезавантажте застосунки `httpbin` і `sleep`, щоб вони отримали зміни від нової панелі управління Istio.
+2. Перезавантажте застосунки `httpbin` і `curl`, щоб вони отримали зміни від нової панелі управління Istio.
 
     {{< text bash >}}
     $ kubectl delete pod --all
     {{< /text >}}
 
     {{< text bash >}}
-    $ kubectl delete pod --all -n sleep-allow
+    $ kubectl delete pod --all -n curl-allow
     {{< /text >}}
 
-3. Перевірте, що запити до `httpbin` з обох просторів імен `sleep` у `default` та `sleep-allow` відхилені.
+3. Перевірте, що запити до `httpbin` з обох просторів імен `curl` у `default` та `curl-allow` відхилені.
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
     403
     {{< /text >}}
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl -n sleep-allow get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -n sleep-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl -n curl-allow get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -n curl-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
     403
     {{< /text >}}
 
-    Це тому, що ми вказали політику авторизації, яка забороняє всі запити до `httpbin`, крім запитів з ідентифікатора `old-td/ns/sleep-allow/sa/sleep`, що є старим ідентифікатором програми `sleep` у просторі імен `sleep-allow`. Коли ми перейшли до нового домену довіри, тобто `new-td`, ідентифікатор цієї програми `sleep` тепер `new-td/ns/sleep-allow/sa/sleep`, що відрізняється від `old-td/ns/sleep-allow/sa/sleep`. Тому запити з програми `sleep` у просторі імен `sleep-allow` до `httpbin`, які раніше були дозволені, тепер відхиляються. До Istio 1.4 єдиний спосіб це виправити — змінити політику авторизації вручну. У Istio 1.4 ми представляємо простий спосіб, як показано нижче.
+    Це тому, що ми вказали політику авторизації, яка забороняє всі запити до `httpbin`, крім запитів з ідентифікатора `old-td/ns/curl-allow/sa/curl`, що є старим ідентифікатором програми `curl` у просторі імен `curl-allow`. Коли ми перейшли до нового домену довіри, тобто `new-td`, ідентифікатор цієї програми `curl` тепер `new-td/ns/curl-allow/sa/curl`, що відрізняється від `old-td/ns/curl-allow/sa/curl`. Тому запити з програми `curl` у просторі імен `curl-allow` до `httpbin`, які раніше були дозволені, тепер відхиляються. До Istio 1.4 єдиний спосіб це виправити — змінити політику авторизації вручну. У Istio 1.4 ми представляємо простий спосіб, як показано нижче.
 
 ## Міграція домену довіри з аліасами домену довіри {#migrate-trust-domain-with-trust-domain-aliases}
 
@@ -137,31 +137,31 @@ test: yes
 
 1. Не змінюючи політику авторизації, перевірте, що запити до `httpbin` з:
 
-    * `sleep` в просторі імен `default` відхилені.
+    * `curl` в просторі імен `default` відхилені.
 
         {{< text bash >}}
-        $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+        $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
         403
         {{< /text >}}
 
-    * `sleep` в просторі імен `sleep-allow` дозволені.
+    * `curl` в просторі імен `curl-allow` дозволені.
 
         {{< text bash >}}
-        $ kubectl exec "$(kubectl -n sleep-allow get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -n sleep-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+        $ kubectl exec "$(kubectl -n curl-allow get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -n curl-allow -- curl http://httpbin.default:8000/ip -sS -o /dev/null -w "%{http_code}\n"
         200
         {{< /text >}}
 
 ## Найкращі практики {#best-practices}
 
-Починаючи з Istio 1.4, при написанні політики авторизації слід розглянути можливість використання значення `cluster.local` як частини домену довіри в політиці. Наприклад, замість `old-td/ns/sleep-allow/sa/sleep`, це має бути `cluster.local/ns/sleep-allow/sa/sleep`. Зверніть увагу, що в цьому випадку `cluster.local` не є доменом довіри Istio mesh (домен довіри залишається `old-td`). Однак, у політиці авторизації `cluster.local` є покажчиком, який вказує на поточний домен довіри, тобто `old-td` (а пізніше `new-td`), а також на його псевдоніми. Використовуючи `cluster.local` у політиці авторизації, коли ви мігруєте до нового домену довіри, Istio виявить це та розгляне новий домен довіри як старий домен довіри без необхідності включення псевдонімів.
+Починаючи з Istio 1.4, при написанні політики авторизації слід розглянути можливість використання значення `cluster.local` як частини домену довіри в політиці. Наприклад, замість `old-td/ns/curl-allow/sa/curl`, це має бути `cluster.local/ns/curl-allow/sa/curl`. Зверніть увагу, що в цьому випадку `cluster.local` не є доменом довіри Istio mesh (домен довіри залишається `old-td`). Однак, у політиці авторизації `cluster.local` є покажчиком, який вказує на поточний домен довіри, тобто `old-td` (а пізніше `new-td`), а також на його псевдоніми. Використовуючи `cluster.local` у політиці авторизації, коли ви мігруєте до нового домену довіри, Istio виявить це та розгляне новий домен довіри як старий домен довіри без необхідності включення псевдонімів.
 
 ## Очищення {#clean-up}
 
 {{< text bash >}}
 $ kubectl delete authorizationpolicy service-httpbin.default.svc.cluster.local
 $ kubectl delete deploy httpbin; kubectl delete service httpbin; kubectl delete serviceaccount httpbin
-$ kubectl delete deploy sleep; kubectl delete service sleep; kubectl delete serviceaccount sleep
+$ kubectl delete deploy curl; kubectl delete service curl; kubectl delete serviceaccount curl
 $ istioctl uninstall --purge -y
-$ kubectl delete namespace sleep-allow istio-system
+$ kubectl delete namespace curl-allow istio-system
 $ rm ./td-installation.yaml
 {{< /text >}}

content/uk/docs/tasks/security/cert-management/custom-ca-k8s/index.md

@@ -243,30 +243,30 @@ $ export BARCA=$(kubectl get clusterissuers bar -o jsonpath='{.spec.ca.secretNam
     $ kubectl apply  -f ./proxyconfig-foo.yaml
     {{< /text >}}
 
-5. Розгорніть демонстраційні застосунки `httpbin` та `leep` у просторах імен `foo` і `bar`.
+5. Розгорніть демонстраційні застосунки `httpbin` та `curl` у просторах імен `foo` і `bar`.
 
     {{< text bash >}}
     $ kubectl label ns foo istio-injection=enabled
     $ kubectl label ns bar istio-injection=enabled
     $ kubectl apply -f samples/httpbin/httpbin.yaml -n foo
-    $ kubectl apply -f samples/sleep/sleep.yaml -n foo
+    $ kubectl apply -f samples/curl/curl.yaml -n foo
     $ kubectl apply -f samples/httpbin/httpbin.yaml -n bar
     {{< /text >}}
 
-## Перевірка мережевої взаємодії між `httpbin` і `sleep` у межах одного простору імен {#verify-the-network-connectivity-between-httpbin-and-sleep-within-the-same-namespace}
+## Перевірка мережевої взаємодії між `httpbin` і `curl` у межах одного простору імен {#verify-the-network-connectivity-between-httpbin-and-curl-within-the-same-namespace}
 
 Коли робочі навантаження розгорнуті, вони надсилають запити CSR з відповідною інформацією про підписувача. Istiod пересилає запит CSR до власного центру сертифікації користувача для підпису. Власний CA використовує відповідного кластерного емітента для підпису сертифіката. Робочі навантаження у просторі імен `foo` використовують кластерних емітентів `foo`, а робочі навантаження у просторі імен `bar` використовують кластерних емітентів `bar`. Щоб перевірити, що сертифікати дійсно підписані правильними кластерними емітентами, можна перевірити, чи можуть робочі навантаження в одному просторі імен спілкуватися між собою, тоді як робочі навантаження з різних просторів імен не можуть.
 
-1. Вкажіть в змінну середовища `SLEEP_POD_FOO` імʼя podʼа `sleep`.
+1. Вкажіть в змінну середовища `CURL_POD_FOO` імʼя podʼа `curl`.
 
     {{< text bash >}}
-    $ export SLEEP_POD_FOO=$(kubectl get pod -n foo -l app=sleep -o jsonpath={.items..metadata.name})
+    $ export CURL_POD_FOO=$(kubectl get pod -n foo -l app=curl -o jsonpath={.items..metadata.name})
     {{< /text >}}
 
-1. Перевірте мережеве зʼєднання між сервісом `sleep` та `httpbin` в просторі імен `foo`.
+1. Перевірте мережеве зʼєднання між сервісом `curl` та `httpbin` в просторі імен `foo`.
 
     {{< text bash >}}
-    $ kubectl exec "$SLEEP_POD_FOO" -n foo -c sleep -- curl http://httpbin.foo:8000/html
+    $ kubectl exec "$CURL_POD_FOO" -n foo -c curl -- curl http://httpbin.foo:8000/html
     <!DOCTYPE html>
     <html>
       <head>
@@ -282,10 +282,10 @@ $ export BARCA=$(kubectl get clusterissuers bar -o jsonpath='{.spec.ca.secretNam
       </body>
      {{< /text >}}
 
-1. Перевірте мережеве зʼєднання між сервісами `sleep` у просторі імен `foo` та `shttpbin` у просторі імен `bar`.
+1. Перевірте мережеве зʼєднання між сервісами `curl` у просторі імен `foo` та `httpbin` у просторі імен `bar`.
 
     {{< text bash >}}
-    $ kubectl exec "$SLEEP_POD_FOO" -n foo -c sleep -- curl http://httpbin.bar:8000/html
+    $ kubectl exec "$CURL_POD_FOO" -n foo -c curl -- curl http://httpbin.bar:8000/html
     upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
     {{< /text >}}
 

content/uk/docs/tasks/security/cert-management/plugin-ca-cert/index.md

@@ -98,12 +98,12 @@ test: yes
 
 ## Розгортання демонстраційних сервісів {#deploying-example-services}
 
-1. Розгорніть демонстраційні сервіси `httpbin` та  `sleep`.
+1. Розгорніть демонстраційні сервіси `httpbin` та  `curl`.
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
-    $ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
+    $ kubectl apply -f <(istioctl kube-inject -f samples/curl/curl.yaml) -n foo
     {{< /text >}}
 
 2. Розгорніть політику для робочих навантажень у просторі імен `foo`, щоб приймати лише взаємний TLS-трафік.
@@ -127,7 +127,7 @@ test: yes
 1.  Почекайте 20 секунд, щоб політика mTLS набула чинності, перш ніж отримати ланцюжок сертифікатів для `httpbin`. Оскільки сертифікат CA, що використовується в цьому прикладі, є самопідписним, помилка `verify error:num=19:self signed certificate in certificate chain`, що повертається командою openssl, є очікуваною.
 
     {{< text bash >}}
-    $ sleep 20; kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -showcerts -connect httpbin.foo:8000 > httpbin-proxy-cert.txt
+    $ sleep 20; kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -showcerts -connect httpbin.foo:8000 > httpbin-proxy-cert.txt
     {{< /text >}}
 
 1.  Проаналізуйте сертифікати в ланцюжку сертифікатів.
@@ -182,10 +182,10 @@ test: yes
     $ kubectl delete peerauthentication -n foo default
     {{< /text >}}
 
-*   Видаліть демонстраційні застосунки `sleep` та `httpbin`:
+*   Видаліть демонстраційні застосунки `curl` та `httpbin`:
 
     {{< text bash >}}
-    $ kubectl delete -f samples/sleep/sleep.yaml -n foo
+    $ kubectl delete -f samples/curl/curl.yaml -n foo
     $ kubectl delete -f samples/httpbin/httpbin.yaml -n foo
     {{< /text >}}
 

content/uk/docs/tasks/security/tls-configuration/workload-min-tls-version/index.md

@@ -32,18 +32,18 @@ test: yes
 
 Після конфігурації мінімальної версії TLS для робочих навантажень Istio, ви можете перевірити, що мінімальна версія TLS налаштована і працює як очікується.
 
-* Розгорніть два робочих навантаження: `httpbin` та `sleep`. Розгорніть їх в одному просторі імен, наприклад, `foo`. Обидва робочих навантаження працюють з проксі Envoy попереду.
+* Розгорніть два робочих навантаження: `httpbin` та `curl`. Розгорніть їх в одному просторі імен, наприклад, `foo`. Обидва робочих навантаження працюють з проксі Envoy попереду.
 
     {{< text bash >}}
     $ kubectl create ns foo
     $ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n foo
     {{< /text >}}
 
-* Перевірте, що `sleep` успішно спілкується з `httpbin`, використовуючи наступну команду:
+* Перевірте, що `curl` успішно спілкується з `httpbin`, використовуючи наступну команду:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
+    $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.foo:8000/ip -sS -o /dev/null -w "%{http_code}\n"
     200
     {{< /text >}}
 
@@ -54,7 +54,7 @@ test: yes
 У цьому прикладі мінімальна версія TLS була налаштована на 1.3. Щоб перевірити, що TLS 1.3 дозволено, виконайте наступну команду:
 
 {{< text bash >}}
-$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -alpn istio -tls1_3 -connect httpbin.foo:8000 | grep "TLSv1.3"
+$ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -alpn istio -tls1_3 -connect httpbin.foo:8000 | grep "TLSv1.3"
 {{< /text >}}
 
 Вивід повинен містити:
@@ -66,7 +66,7 @@ TLSv1.3
 Щоб перевірити, що TLS 1.2 не дозволено, виконайте наступну команду:
 
 {{< text bash >}}
-$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -alpn istio -tls1_2 -connect httpbin.foo:8000 | grep "Cipher is (NONE)"
+$ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c istio-proxy -n foo -- openssl s_client -alpn istio -tls1_2 -connect httpbin.foo:8000 | grep "Cipher is (NONE)"
 {{< /text >}}
 
 Вивід повинен містити:
@@ -77,11 +77,11 @@ Cipher is (NONE)
 
 ## Очищення {#cleanup}
 
-Видаліть застосунки `sleep` і `httpbin` з простору імен `foo`:
+Видаліть застосунки `curl` і `httpbin` з простору імен `foo`:
 
 {{< text bash >}}
 $ kubectl delete -f samples/httpbin/httpbin.yaml -n foo
-$ kubectl delete -f samples/sleep/sleep.yaml -n foo
+$ kubectl delete -f samples/curl/curl.yaml -n foo
 {{< /text >}}
 
 Видаліть Istio з кластера:

content/uk/docs/tasks/traffic-management/egress/egress-control/index.md

@@ -22,16 +22,16 @@ test: yes
 
 *   Налаштуйте Istio, дотримуючись інструкцій з [Посібника з встановлення](/docs/setup/). Використовуйте [профіль конфігурації](/docs/setup/additional-setup/config-profiles/) `demo` або ж [увімкніть реєстрацію доступу Envoy](/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging).
 
-*   Розгорніть демонстраційний застосунок [sleep]({{< github_tree >}}/samples/sleep), щоб використовувати його як тестове джерело для надсилання запитів. Якщо у вас увімкнено [автоматичну інʼєкцію sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду для розгортання демонстраційного застосунку:
+*   Розгорніть демонстраційний застосунок [curl]({{< github_tree >}}/samples/curl), щоб використовувати його як тестове джерело для надсилання запитів. Якщо у вас увімкнено [автоматичну інʼєкцію sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду для розгортання демонстраційного застосунку:
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
-    Або ж вручну виконайте інʼєкцію sidecar перед розгортанням демонстраційного застосунку `sleep` за допомогою наступної команди:
+    Або ж вручну виконайте інʼєкцію sidecar перед розгортанням демонстраційного застосунку `curl` за допомогою наступної команди:
 
     {{< text bash >}}
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@)
     {{< /text >}}
 
     {{< tip >}}
@@ -41,7 +41,7 @@ test: yes
 *   В зміну оточення `SOURCE_POD` встановіть назву вашого podʼа джерела:
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath='{.items..metadata.name}')
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath='{.items..metadata.name}')
     {{< /text >}}
 
 ## Передача трафіку через Envoy до зовнішніх сервісів {#envoy-passthrough-to-external-services}
@@ -71,7 +71,7 @@ Istio має [опцію встановлення](/docs/reference/config/istio.
 2.  Виконайте кілька запитів до зовнішніх HTTPS сервісів з `SOURCE_POD`, щоб підтвердити успішні відповіді `200`:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSI https://www.google.com | grep  "HTTP/"; kubectl exec "$SOURCE_POD" -c sleep -- curl -sI https://edition.cnn.com | grep "HTTP/"
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sSI https://www.google.com | grep  "HTTP/"; kubectl exec "$SOURCE_POD" -c curl -- curl -sI https://edition.cnn.com | grep "HTTP/"
     HTTP/2 200
     HTTP/2 200
     {{< /text >}}
@@ -113,7 +113,7 @@ Istio має [опцію встановлення](/docs/reference/config/istio.
 1.  Виконайте кілька запитів до зовнішніх HTTPS сервісів з `SOURCE_POD`, щоб перевірити, що вони тепер заблоковані:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sI https://www.google.com | grep  "HTTP/"; kubectl exec "$SOURCE_POD" -c sleep -- curl -sI https://edition.cnn.com | grep "HTTP/"
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sI https://www.google.com | grep  "HTTP/"; kubectl exec "$SOURCE_POD" -c curl -- curl -sI https://edition.cnn.com | grep "HTTP/"
     command terminated with exit code 35
     command terminated with exit code 35
     {{< /text >}}
@@ -153,7 +153,7 @@ Istio має [опцію встановлення](/docs/reference/config/istio.
 2.  Виконайте запит до зовнішнього HTTP сервісу з `SOURCE_POD`:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS http://httpbin.org/headers
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sS http://httpbin.org/headers
     {
       "headers": {
         "Accept": "*/*",
@@ -201,7 +201,7 @@ Istio має [опцію встановлення](/docs/reference/config/istio.
 1.  Зробіть запит до зовнішнього HTTPS-сервісу з `SOURCE_POD`:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSI https://www.google.com | grep  "HTTP/"
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sSI https://www.google.com | grep  "HTTP/"
     HTTP/2 200
     {{< /text >}}
 
@@ -223,7 +223,7 @@ Istio має [опцію встановлення](/docs/reference/config/istio.
 1)  Зсередини podʼа, який використовується як тестове джерело, виконайте _curl_ запит до точки доступу `/delay` зовнішнього сервісу httpbin.org:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- time curl -o /dev/null -sS -w "%{http_code}\n" http://httpbin.org/delay/5
+    $ kubectl exec "$SOURCE_POD" -c curl -- time curl -o /dev/null -sS -w "%{http_code}\n" http://httpbin.org/delay/5
     200
     real    0m5.024s
     user    0m0.003s
@@ -291,7 +291,7 @@ EOF
 3)  Зачекайте кілька секунд, а потім повторіть запит _curl_ ще раз:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- time curl -o /dev/null -sS -w "%{http_code}\n" http://httpbin.org/delay/5
+    $ kubectl exec "$SOURCE_POD" -c curl -- time curl -o /dev/null -sS -w "%{http_code}\n" http://httpbin.org/delay/5
     504
     real    0m3.149s
     user    0m0.004s
@@ -453,12 +453,12 @@ $ istioctl install <flags-you-used-to-install-Istio> --set values.global.proxy.i
 
 ### Доступ до зовнішніх сервісів {#access-the-external-services}
 
-Оскільки конфігурація оминання впливає тільки на нові розгортання, вам потрібно завершити роботу та повторно розгорнути застосунок `sleep`, як описано в розділі [Перш ніж розпочати](#before-you-begin).
+Оскільки конфігурація оминання впливає тільки на нові розгортання, вам потрібно завершити роботу та повторно розгорнути застосунок `curl`, як описано в розділі [Перш ніж розпочати](#before-you-begin).
 
-Після оновлення configmap `istio-sidecar-injector` і повторного розгортання застосунку `sleep`, sidecar Istio перехоплюватиме та керуватиме лише внутрішніми запитами всередині кластера. Будь-які зовнішні запити будуть оминати sidecar і направлятися безпосередньо до відповідного пункту призначення. Наприклад:
+Після оновлення configmap `istio-sidecar-injector` і повторного розгортання застосунку `curl`, sidecar Istio перехоплюватиме та керуватиме лише внутрішніми запитами всередині кластера. Будь-які зовнішні запити будуть оминати sidecar і направлятися безпосередньо до відповідного пункту призначення. Наприклад:
 
 {{< text bash >}}
-$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS http://httpbin.org/headers
+$ kubectl exec "$SOURCE_POD" -c curl -- curl -sS http://httpbin.org/headers
 {
   "headers": {
     "Accept": "*/*",
@@ -505,8 +505,8 @@ $ istioctl install <flags-you-used-to-install-Istio>
 
 ## Очищення {#cleanup}
 
-Зупиніть сервіс [sleep]({{< github_tree >}}/samples/sleep):
+Зупиніть сервіс [curl]({{< github_tree >}}/samples/curl):
 
 {{< text bash >}}
-$ kubectl delete -f @samples/sleep/sleep.yaml@
+$ kubectl delete -f @samples/curl/curl.yaml@
 {{< /text >}}

content/uk/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md

@@ -18,26 +18,26 @@ test: yes
 
 * Налаштуйте Istio, дотримуючись інструкцій з [Посібника з встановлення](/docs/setup/).
 
-*   Розгорніть демонстраційний застосунок [sleep]({{< github_tree >}}/samples/sleep), щоб використовувати його як джерело для надсилання тестових запитів.
+*   Розгорніть демонстраційний застосунок [curl]({{< github_tree >}}/samples/curl), щоб використовувати його як джерело для надсилання тестових запитів.
 
-    Якщо у вас увімкнено [автоматичну інʼєкцію sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду, розгорніть застосунок `sleep`:
+    Якщо у вас увімкнено [автоматичну інʼєкцію sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду, розгорніть застосунок `curl`:
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
-    В іншому випадку вам потрібно вручну виконати інʼєкцію sidecar перед розгортанням застосунку `sleep`:
+    В іншому випадку вам потрібно вручну виконати інʼєкцію sidecar перед розгортанням застосунку `curl`:
 
     {{< text bash >}}
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@)
     {{< /text >}}
 
     Зверніть увагу, що будь-який pod, з якого ви можете виконати `exec` та `curl`, підійде для подальших процедур.
 
-*   Створіть змінну оболонки, яка буде містити ім'я вихідного пакунка для надсилання запитів до зовнішніх сервісів. Якщо ви використовували приклад [sleep]({{< github_tree >}}/samples/sleep), запустіть його:
+*   Створіть змінну оболонки, яка буде містити ім'я вихідного пакунка для надсилання запитів до зовнішніх сервісів. Якщо ви використовували приклад [curl]({{< github_tree >}}/samples/curl), запустіть його:
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})
     {{< /text >}}
 
 *   Для користувачів macOS переконайтеся, що ви використовуєте `openssl` версії 1.1 або новішої:
@@ -86,7 +86,7 @@ test: yes
 2.  Переконайтеся, що ваш `ServiceEntry` було застосовано правильно, надіславши запит до [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
 
     {{< text bash >}}
-    $ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
+    $ kubectl exec "${SOURCE_POD}" -c curl -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
     HTTP/1.1 301 Moved Permanently
     ...
     location: https://edition.cnn.com/politics
@@ -298,7 +298,7 @@ EOF
 6)  Надішліть HTTP-запит до [http://edition.cnn.com/politics] (https://edition.cnn.com/politics).
 
     {{< text bash >}}
-    $ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
+    $ kubectl exec "${SOURCE_POD}" -c curl -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
     HTTP/1.1 200 OK
     ...
     {{< /text >}}
@@ -874,6 +874,8 @@ EOF
 
 {{< /tabset >}}
 
+{{< boilerplate auto-san-validation >}}
+
 5)  Переконайтеся, що облікові дані передано на вихідний шлюз і вони активні:
 
 {{< tabset category-name="config-api" >}}
@@ -903,7 +905,7 @@ kubernetes://client-credential-cacert     Cert Chain     ACTIVE     true
 6)  Надішліть HTTP-запит на адресу `http://my-nginx.mesh-external.svc.cluster.local`:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sS http://my-nginx.mesh-external.svc.cluster.local
+    $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl -sS http://my-nginx.mesh-external.svc.cluster.local
     <!DOCTYPE html>
     <html>
     <head>
@@ -1009,8 +1011,8 @@ $ kubectl delete referencegrant my-nginx-reference-grant -n mesh-external
 
 ## Очищення {#cleanup}
 
-Видаліть сервіс та розгортання `sleep`:
+Видаліть сервіс та розгортання `curl`:
 
 {{< text bash >}}
-$ kubectl delete -f @samples/sleep/sleep.yaml@
+$ kubectl delete -f @samples/curl/curl.yaml@
 {{< /text >}}

content/uk/docs/tasks/traffic-management/egress/egress-gateway/index.md

@@ -34,10 +34,10 @@ Istio використовує [ingress та egress gateways](/docs/reference/co
     [профіль конфігурації](/docs/setup/additional-setup/config-profiles/) `demo`.
     {{< /tip >}}
 
-*   Розгорніть демонстраційний застосунок [sleep]({{< github_tree >}}/samples/sleep), щоб використовувати його як джерело для надсилання тестових запитів.
+*   Розгорніть демонстраційний застосунок [curl]({{< github_tree >}}/samples/curl), щоб використовувати його як джерело для надсилання тестових запитів.
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
     {{< tip >}}
@@ -47,7 +47,7 @@ Istio використовує [ingress та egress gateways](/docs/reference/co
 *   Встановіть змінну оточення `SOURCE_POD` на імʼя вашого вихідного podʼа:
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})
     {{< /text >}}
 
     {{< warning >}}
@@ -127,7 +127,7 @@ Egress gateways автоматично [розгортаються](/docs/tasks/
 2.  Переконайтеся, що ваш `ServiceEntry` було застосовано правильно, надіславши HTTP-запит на [http://edition.cnn.com/politics](http://edition.cnn.com/politics).
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
     ...
     HTTP/1.1 301 Moved Permanently
     ...
@@ -296,7 +296,7 @@ EOF
 5)  Повторно надішліть HTTP-запит до [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
     ...
     HTTP/1.1 301 Moved Permanently
     ...
@@ -429,7 +429,7 @@ $ kubectl delete httproute forward-cnn-from-egress-gateway
 1.  Переконайтеся, що ваш `ServiceEntry` було застосовано правильно, надіславши HTTPS-запит на [https://edition.cnn.com/politics](https://edition.cnn.com/politics).
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics
     ...
     HTTP/2 200
     Content-Type: text/html; charset=utf-8
@@ -576,7 +576,7 @@ EOF
 4)  Надішліть HTTPS-запит на адресу [https://edition.cnn.com/politics](https://edition.cnn.com/politics). Результат має бути таким самим, як і раніше.
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics
     ...
     HTTP/2 200
     Content-Type: text/html; charset=utf-8
@@ -661,7 +661,7 @@ Istio *не може безпечно забезпечити* те, щоб ве
 
 ## Застосування мережевих політик Kubernetes {#apply-kubernetes-network-policies}
 
-У цьому розділі описується, як створити [мережеву політику Kubernetes](https://kubernetes.io/docs/concepts/services-networking/network-policies/), щоб запобігти оминання шлюзу вихідного трафіку. Для тестування мережевої політики створюється простір імен `test-egress`, у який розгортається зразок [sleep]({{< github_tree >}}/samples/sleep), а потім виконується спроба надіслати запити до зовнішнього сервісу, захищеного шлюзом.
+У цьому розділі описується, як створити [мережеву політику Kubernetes](https://kubernetes.io/docs/concepts/services-networking/network-policies/), щоб запобігти оминання шлюзу вихідного трафіку. Для тестування мережевої політики створюється простір імен `test-egress`, у який розгортається зразок [curl]({{< github_tree >}}/samples/curl), а потім виконується спроба надіслати запити до зовнішнього сервісу, захищеного шлюзом.
 
 1) Виконайте кроки з розділу [Шлюз вихідного трафіку для HTTPS-трафіку](#egress-gateway-for-https-traffic).
 
@@ -671,24 +671,24 @@ Istio *не може безпечно забезпечити* те, щоб ве
     $ kubectl create namespace test-egress
     {{< /text >}}
 
-3) Розгорніть зразок [sleep]({{< github_tree >}}/samples/sleep) у просторі імен `test-egress`.
+3) Розгорніть зразок [curl]({{< github_tree >}}/samples/curl) у просторі імен `test-egress`.
 
     {{< text bash >}}
-    $ kubectl apply -n test-egress -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -n test-egress -f @samples/curl/curl.yaml@
     {{< /text >}}
 
 4) Перевірте, що розгорнутий pod має лише один контейнер без підключеного sidecar контейнера Istio:
 
     {{< text bash >}}
-    $ kubectl get pod "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress
+    $ kubectl get pod "$(kubectl get pod -n test-egress -l app=curl -o jsonpath={.items..metadata.name})" -n test-egress
     NAME                     READY     STATUS    RESTARTS   AGE
-    sleep-776b7bcdcd-z7mc4   1/1       Running   0          18m
+    curl-776b7bcdcd-z7mc4    1/1       Running   0          18m
     {{< /text >}}
 
-5) Надішліть HTTPS-запит до [https://edition.cnn.com/politics](https://edition.cnn.com/politics) з podʼа `sleep` у просторі імен `test-egress`. Запит буде успішним, оскільки ви ще не визначили жодних обмежувальних політик.
+5) Надішліть HTTPS-запит до [https://edition.cnn.com/politics](https://edition.cnn.com/politics) з podʼа `curl` у просторі імен `test-egress`. Запит буде успішним, оскільки ви ще не визначили жодних обмежувальних політик.
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -c sleep -- curl -s -o /dev/null -w "%{http_code}\n"  https://edition.cnn.com/politics
+    $ kubectl exec "$(kubectl get pod -n test-egress -l app=curl -o jsonpath={.items..metadata.name})" -n test-egress -c curl -- curl -s -o /dev/null -w "%{http_code}\n"  https://edition.cnn.com/politics
     200
     {{< /text >}}
 
@@ -793,10 +793,10 @@ EOF
 
 {{< /tabset >}}
 
-9)  Повторно надішліть HTTPS-запит до [https://edition.cnn.com/politics](https://edition.cnn.com/politics). Тепер він має не виконатися, оскільки трафік заблокований мережевою політикою. Зверніть увагу, що pod `sleep` не може оминути шлюз вихідного трафіку. Єдиний спосіб, яким він може отримати доступ до `edition.cnn.com`, — це використання sudecar проксі Istio та спрямування трафіку через шлюз вихідного трафіку. Це налаштування демонструє, що навіть якщо якийсь шкідливий pod зуміє обійти свій sidecar проксі, він не зможе отримати доступ до зовнішніх сайтів і буде заблокований мережевою політикою.
+9)  Повторно надішліть HTTPS-запит до [https://edition.cnn.com/politics](https://edition.cnn.com/politics). Тепер він має не виконатися, оскільки трафік заблокований мережевою політикою. Зверніть увагу, що pod `curl` не може оминути шлюз вихідного трафіку. Єдиний спосіб, яким він може отримати доступ до `edition.cnn.com`, — це використання sudecar проксі Istio та спрямування трафіку через шлюз вихідного трафіку. Це налаштування демонструє, що навіть якщо якийсь шкідливий pod зуміє обійти свій sidecar проксі, він не зможе отримати доступ до зовнішніх сайтів і буде заблокований мережевою політикою.
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -c sleep -- curl -v -sS https://edition.cnn.com/politics
+    $ kubectl exec "$(kubectl get pod -n test-egress -l app=curl -o jsonpath={.items..metadata.name})" -n test-egress -c curl -- curl -v -sS https://edition.cnn.com/politics
     Hostname was NOT found in DNS cache
       Trying 151.101.65.67...
       Trying 2a04:4e42:200::323...
@@ -810,17 +810,17 @@ EOF
     connect to 151.101.65.67 port 443 failed: Connection timed out
     {{< /text >}}
 
-10)  Тепер додай проксі Istio sidecar у pod `sleep` в просторі імен `test-egress`, спочатку увімкнувши автоматичне додавання sidecar проксі в просторі імен `test-egress`:
+10)  Тепер додай проксі Istio sidecar у pod `curl` в просторі імен `test-egress`, спочатку увімкнувши автоматичне додавання sidecar проксі в просторі імен `test-egress`:
 
     {{< text bash >}}
     $ kubectl label namespace test-egress istio-injection=enabled
     {{< /text >}}
 
-11)  Потім виконайте повторне розгортання `sleep`:
+11)  Потім виконайте повторне розгортання `curl`:
 
     {{< text bash >}}
-    $ kubectl delete deployment sleep -n test-egress
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n test-egress
+    $ kubectl delete deployment curl -n test-egress
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n test-egress
     {{< /text >}}
 
 12)  Перевір, що у розгорнутому pod є два контейнери, включаючи проксі Istio sidecar (`istio-proxy`):
@@ -830,11 +830,11 @@ EOF
 {{< tab name="Istio APIs" category-value="istio-apis" >}}
 
 {{< text bash >}}
-$ kubectl get pod "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -o jsonpath='{.spec.containers[*].name}'
-sleep istio-proxy
+$ kubectl get pod "$(kubectl get pod -n test-egress -l app=curl -o jsonpath={.items..metadata.name})" -n test-egress -o jsonpath='{.spec.containers[*].name}'
+curl istio-proxy
 {{< /text >}}
 
-Перш ніж продовжити, потрібно створити аналогічне правило призначення, як і для pod `sleep` у просторі імен `default`, щоб спрямувати трафік простору імен `test-egress` через шлюз egress:
+Перш ніж продовжити, потрібно створити аналогічне правило призначення, як і для pod `curl` у просторі імен `default`, щоб спрямувати трафік простору імен `test-egress` через шлюз egress:
 
 {{< text bash >}}
 $ kubectl apply -n test-egress -f - <<EOF
@@ -854,8 +854,8 @@ EOF
 {{< tab name="Gateway API" category-value="gateway-api" >}}
 
 {{< text bash >}}
-$ kubectl get pod "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -o jsonpath='{.spec.containers[*].name}'
-sleep istio-proxy
+$ kubectl get pod "$(kubectl get pod -n test-egress -l app=curl -o jsonpath={.items..metadata.name})" -n test-egress -o jsonpath='{.spec.containers[*].name}'
+curl istio-proxy
 {{< /text >}}
 
 {{< /tab >}}
@@ -865,7 +865,7 @@ sleep istio-proxy
 13) Надішліть HTTPS-запит на [https://edition.cnn.com/politics](https://edition.cnn.com/politics). Тепер він повинен успішно пройти, оскільки трафік до шлюзу egress дозволений мережевою політикою, яку ви визначили. Шлюз потім пересилає трафік на `edition.cnn.com`.
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -c sleep -- curl -sS -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics
+    $ kubectl exec "$(kubectl get pod -n test-egress -l app=curl -o jsonpath={.items..metadata.name})" -n test-egress -c curl -- curl -sS -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics
     200
     {{< /text >}}
 
@@ -916,7 +916,7 @@ $ kubectl logs -l gateway.networking.k8s.io/gateway-name=cnn-egress-gateway -c i
 {{< tab name="Istio APIs" category-value="istio-apis" >}}
 
 {{< text bash >}}
-$ kubectl delete -f @samples/sleep/sleep.yaml@ -n test-egress
+$ kubectl delete -f @samples/curl/curl.yaml@ -n test-egress
 $ kubectl delete destinationrule egressgateway-for-cnn -n test-egress
 $ kubectl delete networkpolicy allow-egress-to-istio-system-and-kube-dns -n test-egress
 $ kubectl label namespace kube-system kube-system-
@@ -929,7 +929,7 @@ $ kubectl delete namespace test-egress
 {{< tab name="Gateway API" category-value="gateway-api" >}}
 
 {{< text bash >}}
-$ kubectl delete -f @samples/sleep/sleep.yaml@ -n test-egress
+$ kubectl delete -f @samples/curl/curl.yaml@ -n test-egress
 $ kubectl delete networkpolicy allow-egress-to-istio-system-and-kube-dns -n test-egress
 $ kubectl label namespace kube-system kube-system-
 $ kubectl label namespace istio-system istio-
@@ -945,8 +945,8 @@ $ kubectl delete namespace test-egress
 
 ## Очищення {#cleanup}
 
-Вимкніть сервіс [sleep]({{< github_tree >}}/samples/sleep):
+Вимкніть сервіс [curl]({{< github_tree >}}/samples/curl):
 
 {{< text bash >}}
-$ kubectl delete -f @samples/sleep/sleep.yaml@
+$ kubectl delete -f @samples/curl/curl.yaml@
 {{< /text >}}

content/uk/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md

@@ -25,16 +25,16 @@ Kubernetes-сервіси [ExternalName](https://kubernetes.io/docs/concepts/ser
     $ kubectl create namespace without-istio
     {{< /text >}}
 
-*  Запустіть зразок [sleep]({{< github_tree >}}/samples/sleep) у просторі імен `without-istio`.
+*  Запустіть зразок [curl]({{< github_tree >}}/samples/curl) у просторі імен `without-istio`.
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@ -n without-istio
+    $ kubectl apply -f @samples/curl/curl.yaml@ -n without-istio
     {{< /text >}}
 
 *   Для надсилання запитів створіть змінну оточення `SOURCE_POD_WITHOUT_ISTIO` для зберігання назви джерела podʼа:
 
     {{< text bash >}}
-    $ export SOURCE_POD_WITHOUT_ISTIO="$(kubectl get pod -n without-istio -l app=sleep -o jsonpath={.items..metadata.name})"
+    $ export SOURCE_POD_WITHOUT_ISTIO="$(kubectl get pod -n without-istio -l app=curl -o jsonpath={.items..metadata.name})"
     {{< /text >}}
 
 *   Переконайтеся, що sidecar Istio не була додано, тобто pod має один контейнер:
@@ -42,7 +42,7 @@ Kubernetes-сервіси [ExternalName](https://kubernetes.io/docs/concepts/ser
     {{< text bash >}}
     $ kubectl get pod "$SOURCE_POD_WITHOUT_ISTIO" -n without-istio
     NAME                     READY   STATUS    RESTARTS   AGE
-    sleep-66c8d79ff5-8tqrl   1/1     Running   0          32s
+    curl-66c8d79ff5-8tqrl    1/1     Running   0          32s
     {{< /text >}}
 
 ## Сервіс Kubernetes ExternalName для доступу до зовнішніх сервісів {#kubernetes-externalname-service-to-access-an-external-service}
@@ -76,7 +76,7 @@ Kubernetes-сервіси [ExternalName](https://kubernetes.io/docs/concepts/ser
 1.  Отримайте доступ до `httpbin.org` через імʼя хосту сервісу Kubernetes з вихідного podʼа без Istio sidecar. Зверніть увагу, що команда _curl_ нижче використовує [формат DNS Kubernetes для сервісів](https://v1-13.docs.kubernetes.io/docs/concepts/services-networking/dns-pod-service/#a-records): `<назва сервісу>.<простір імен>.svc.cluster.local`.
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD_WITHOUT_ISTIO" -n without-istio -c sleep -- curl -sS my-httpbin.default.svc.cluster.local/headers
+    $ kubectl exec "$SOURCE_POD_WITHOUT_ISTIO" -n without-istio -c curl -- curl -sS my-httpbin.default.svc.cluster.local/headers
     {
       "headers": {
         "Accept": "*/*",
@@ -102,10 +102,10 @@ Kubernetes-сервіси [ExternalName](https://kubernetes.io/docs/concepts/ser
     EOF
     {{< /text >}}
 
-1.  Отримайте доступ до `httpbin.org` через імʼя хоста Kubernetes-сервісу з вихідного podʼа з Istio sidecar. Зверніть увагу на заголовки, додані Istio sidecar, наприклад, `X-Envoy-Decorator-Operation`. Також зауважте, що заголовок `Host` дорівнює імені хосту вашого сервісу.
+1.  Отримайте доступ до `httpbin.org` через імʼя хоста Kubernetes-сервісу з вихідного podʼа з Istio sidecar. Зверніть увагу на заголовки, додані Istio sidecar, наприклад, `X-Envoy-Peer-Metadata`. Також зауважте, що заголовок `Host` дорівнює імені хосту вашого сервісу.
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS my-httpbin.default.svc.cluster.local/headers
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sS my-httpbin.default.svc.cluster.local/headers
     {
       "headers": {
         "Accept": "*/*",
@@ -115,9 +115,8 @@ Kubernetes-сервіси [ExternalName](https://kubernetes.io/docs/concepts/ser
         "X-B3-Sampled": "0",
         "X-B3-Spanid": "5795fab599dca0b8",
         "X-B3-Traceid": "5079ad3a4af418915795fab599dca0b8",
-        "X-Envoy-Decorator-Operation": "my-httpbin.default.svc.cluster.local:80/*",
         "X-Envoy-Peer-Metadata": "...",
-        "X-Envoy-Peer-Metadata-Id": "sidecar~10.28.1.74~sleep-6bdb595bcb-drr45.default~default.svc.cluster.local"
+        "X-Envoy-Peer-Metadata-Id": "sidecar~10.28.1.74~curl-6bdb595bcb-drr45.default~default.svc.cluster.local"
       }
     }
     {{< /text >}}
@@ -176,7 +175,7 @@ $ kubectl delete service my-httpbin
 4.  Надсилайте HTTPS-запити до `wikipedia.org` за IP кластера вашого сервісу Kubernetes з вихідного podʼа без Istio sidecar. Використовуйте параметр `--resolve` у команді `curl` для доступу до `wikipedia.org` за кластерною IP-адресою:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD_WITHOUT_ISTIO" -n without-istio -c sleep -- curl -sS --resolve en.wikipedia.org:443:"$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}')" https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"
+    $ kubectl exec "$SOURCE_POD_WITHOUT_ISTIO" -n without-istio -c curl -- curl -sS --resolve en.wikipedia.org:443:"$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}')" https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"
     <title>Wikipedia, the free encyclopedia</title>
     {{< /text >}}
 
@@ -199,14 +198,14 @@ $ kubectl delete service my-httpbin
 6.  Отримайте доступ до `wikipedia.org` за IP-адресою кластера вашого сервісу Kubernetes з вихідного podʼа за допомогою sidecar Istio:
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS --resolve en.wikipedia.org:443:"$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}')" https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sS --resolve en.wikipedia.org:443:"$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}')" https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"
     <title>Wikipedia, the free encyclopedia</title>
     {{< /text >}}
 
 7.  Переконайтеся, що доступ дійсно виконується з IP кластера. Зверніть увагу на речення `Connected to en.wikipedia.org (172.21.156.230)` у виводі `curl -v`, в ньому згадується IP, який було надруковано у виводі вашого сервісу як IP кластера.
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- curl -sS -v --resolve en.wikipedia.org:443:"$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}')" https://en.wikipedia.org/wiki/Main_Page -o /dev/null
+    $ kubectl exec "$SOURCE_POD" -c curl -- curl -sS -v --resolve en.wikipedia.org:443:"$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}')" https://en.wikipedia.org/wiki/Main_Page -o /dev/null
     * Added en.wikipedia.org:443:172.21.156.230 to DNS cache
     * Hostname en.wikipedia.org was found in DNS cache
     *   Trying 172.21.156.230...
@@ -225,25 +224,25 @@ $ kubectl delete service my-wikipedia
 
 ## Очищення {#cleanup}
 
-1.  Вимкніть сервіс [sleep]({{< github_tree >}}/samples/sleep):
+1.  Вимкніть сервіс [curl]({{< github_tree >}}/samples/curl):
 
     {{< text bash >}}
-    $ kubectl delete -f @samples/sleep/sleep.yaml@
+    $ kubectl delete -f @samples/curl/curl.yaml@
     {{< /text >}}
 
-1.  Вимкніть сервіс [sleep]({{< github_tree >}}/samples/sleep) у просторі імен `without-istio`:
+1.  Вимкніть сервіс [curl]({{< github_tree >}}/samples/curl) у просторі імен `without-istio`:
 
     {{< text bash >}}
-    $ kubectl delete -f @samples/sleep/sleep.yaml@ -n without-istio
+    $ kubectl delete -f @samples/curl/curl.yaml@ -n without-istio
     {{< /text >}}
 
-2.  Видаліть простір імен `without-istio`:
+1.  Видаліть простір імен `without-istio`:
 
     {{< text bash >}}
     $ kubectl delete namespace without-istio
     {{< /text >}}
 
-3. Скиньте змінні оточення:
+1. Скиньте змінні оточення:
 
     {{< text bash >}}
     $ unset SOURCE_POD SOURCE_POD_WITHOUT_ISTIO

content/uk/docs/tasks/traffic-management/egress/egress-tls-origination/index.md

@@ -21,26 +21,26 @@ aliases:
 
 * Налаштуйте Istio, дотримуючись інструкцій з [Посібника з встановлення](/docs/setup/).
 
-* Запустіть демонстраційний застосунок [sleep]({{< github_tree >}}/samples/sleep), який буде використовуватися як тестове джерело для зовнішніх викликів.
+* Запустіть демонстраційний застосунок [curl]({{< github_tree >}}/samples/curl), який буде використовуватися як тестове джерело для зовнішніх викликів.
 
-    Якщо у вас увімкнено [автоматичну інʼєкцію sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду, розгорніть застосунок `sleep`:
+    Якщо у вас увімкнено [автоматичну інʼєкцію sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду, розгорніть застосунок `curl`:
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
-    В іншому випадку вам потрібно вручну виконати інʼєкцію sidecar перед розгортанням застосунку `sleep`:
+    В іншому випадку вам потрібно вручну виконати інʼєкцію sidecar перед розгортанням застосунку `curl`:
 
     {{< text bash >}}
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@)
     {{< /text >}}
 
     Зверніть увагу, що будь-який pod, з якого ви можете виконати `exec` та `curl`, підійде для подальших процедур.
 
-* Створіть змінну shell для збереження імені podʼа джерела для надсилання запитів до зовнішніх сервісів. Якщо ви використовували [sleep]({{< github_tree >}}/samples/sleep), виконайте:
+* Створіть змінну shell для збереження імені podʼа джерела для надсилання запитів до зовнішніх сервісів. Якщо ви використовували [curl]({{< github_tree >}}/samples/curl), виконайте:
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})
     {{< /text >}}
 
 ## Налаштування доступу до зовнішнього сервісу {#configuring-access-to-an-external-service}
@@ -72,7 +72,7 @@ aliases:
 1.  Зробіть запит до зовнішнього HTTP-сервісу:
 
     {{< text syntax=bash snip_id=curl_simple >}}
-    $ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
+    $ kubectl exec "${SOURCE_POD}" -c curl -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
     HTTP/1.1 301 Moved Permanently
     ...
     location: https://edition.cnn.com/politics
@@ -133,7 +133,7 @@ aliases:
 2. Надішліть HTTP-запит на `http://edition.cnn.com/politics`, як у попередньому розділі:
 
     {{< text syntax=bash snip_id=curl_origination_http >}}
-    $ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
+    $ kubectl exec "${SOURCE_POD}" -c curl -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics
     HTTP/1.1 200 OK
     ...
     {{< /text >}}
@@ -145,7 +145,7 @@ aliases:
 3.  Зверніть увагу, що застосунки, які використовували HTTPS для доступу до зовнішнього сервісу, продовжують працювати як і раніше:
 
     {{< text syntax=bash snip_id=curl_origination_https >}}
-    $ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics
+    $ kubectl exec "${SOURCE_POD}" -c curl -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics
     HTTP/2 200
     ...
     {{< /text >}}
@@ -171,7 +171,7 @@ $ kubectl delete destinationrule edition-cnn-com
 
 1. Створення сертифікатів клієнта та сервера
 1. Розгортання зовнішнього сервісу, який підтримує протокол взаємної автентифікації TLS
-1. Налаштування клієнта (sleep pod) на використання облікових даних, створених на Кроці 1
+1. Налаштування клієнта (curl pod) на використання облікових даних, створених на Кроці 1
 
 Коли ця конфігурація буде завершена, ви зможете налаштувати зовнішній трафік так, щоб він проходив через sidecar, який виконає TLS-автентифікацію.
 
@@ -339,7 +339,7 @@ $ kubectl delete destinationrule edition-cnn-com
     EOF
     {{< /text >}}
 
-### Налаштуйте клієнта (sleep pod) {#configure-the-client-sleep-pod}
+### Налаштуйте клієнта (curl pod) {#configure-the-client-curl-pod}
 
 1.  Створіть Kubernetes [Secrets] (https://kubernetes.io/docs/concepts/configuration/secret/) для зберігання сертифікатів клієнта:
 
@@ -354,11 +354,11 @@ $ kubectl delete destinationrule edition-cnn-com
     {{< boilerplate crl-tip >}}
     {{< /tip >}}
 
-1. Створіть необхідний `RBAC`, щоб переконатися, що секрет, створений на попередньому кроці, доступний клієнтському pod, який ' у цьому випадку — `sleep`.
+1. Створіть необхідний `RBAC`, щоб переконатися, що секрет, створений на попередньому кроці, доступний клієнтському pod, який ' у цьому випадку — `curl`.
 
     {{< text bash >}}
     $ kubectl create role client-credential-role --resource=secret --verb=list
-    $ kubectl create rolebinding client-credential-role-binding --role=client-credential-role --serviceaccount=default:sleep
+    $ kubectl create rolebinding client-credential-role-binding --role=client-credential-role --serviceaccount=default:curl
     {{< /text >}}
 
 ### Налаштування взаємного TLS для вихідного трафіку на sidecar {#configure-mutual-tls-origination-for-egress-traffic-at-sidecar}
@@ -391,7 +391,7 @@ $ kubectl delete destinationrule edition-cnn-com
     spec:
       workloadSelector:
         matchLabels:
-          app: sleep
+          app: curl
       host: my-nginx.mesh-external.svc.cluster.local
       trafficPolicy:
         loadBalancer:
@@ -402,16 +402,20 @@ $ kubectl delete destinationrule edition-cnn-com
           tls:
             mode: MUTUAL
             credentialName: client-credential # це має збігатися з секретом, створеним раніше для зберігання клієнтських сертифікатів, і працює тільки тоді, коли DR має workloadSelector
-            sni: my-nginx.mesh-external.svc.cluster.local # це необовʼязково
+            sni: my-nginx.mesh-external.svc.cluster.local
+            # subjectAltNames: # можна ввімкнути, якщо сертифікат було згенеровано за допомогою SAN, як зазначено в попередньому розділі
+            # - my-nginx.mesh-external.svc.cluster.local
     EOF
     {{< /text >}}
 
     Вищевказане правило `DestinationRule` виконає створення mTLS для HTTP-запитів на порт 80, а `ServiceEntry` буде перенаправляти запити на порт 80 на цільовий порт 443.
 
+    {{< boilerplate auto-san-validation >}}
+
 2.  Переконайтеся, що обліковий запис підʼєднано до sidecar та активовано.
 
     {{< text bash >}}
-    $ istioctl proxy-config secret deploy/sleep | grep client-credential
+    $ istioctl proxy-config secret deploy/curl | grep client-credential
     kubernetes://client-credential            Cert Chain     ACTIVE     true           1                                          2024-06-04T12:15:20Z     2023-06-05T12:15:20Z
     kubernetes://client-credential-cacert     Cert Chain     ACTIVE     true           10792363984292733914                       2024-06-04T12:15:19Z     2023-06-05T12:15:19Z
     {{< /text >}}
@@ -419,7 +423,7 @@ $ kubectl delete destinationrule edition-cnn-com
 3.  Надішліть HTTP-запит до `http://my-nginx.mesh-external.svc.cluster.local`:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})" -c sleep -- curl -sS http://my-nginx.mesh-external.svc.cluster.local
+    $ kubectl exec "$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})" -c curl -- curl -sS http://my-nginx.mesh-external.svc.cluster.local
     <!DOCTYPE html>
     <html>
     <head>
@@ -427,10 +431,10 @@ $ kubectl delete destinationrule edition-cnn-com
     ...
     {{< /text >}}
 
-4.  Перевірте лог podʼа `sleep` на наявність радка, що відповідає вашому запиту.
+4.  Перевірте лог podʼа `curl` на наявність радка, що відповідає вашому запиту.
 
     {{< text bash >}}
-    $ kubectl logs -l app=sleep -c istio-proxy | grep 'my-nginx.mesh-external.svc.cluster.local'
+    $ kubectl logs -l app=curl -c istio-proxy | grep 'my-nginx.mesh-external.svc.cluster.local'
     {{< /text >}}
 
     Ви повинні побачити рядок, схожий на наступний:
@@ -470,9 +474,9 @@ $ kubectl delete destinationrule edition-cnn-com
 
 ## Очищення загальної конфігурації {#cleanup-common-configuration}
 
-Видалити сервіс `sleep` та розгортання:
+Видалити сервіс `curl` та розгортання:
 
 {{< text bash >}}
-$ kubectl delete service sleep
-$ kubectl delete deployment sleep
+$ kubectl delete service curl
+$ kubectl delete deployment curl
 {{< /text >}}

content/uk/docs/tasks/traffic-management/egress/http-proxy/index.md

@@ -8,6 +8,7 @@ aliases:
 owner: istio/wg-networking-maintainers
 test: yes
 ---
+
 Приклад [Налаштування Egress Gateway](/docs/tasks/traffic-management/egress/egress-gateway/) показує, як спрямовувати трафік до зовнішніх сервісів з вашої сервісної мережі через компонент Istio на периметрі мережі, який називається _Egress Gateway_. Однак у деяких випадках необхідно використовувати зовнішній, застарілий (non-Istio) HTTPS-проксі для доступу до зовнішніх сервісів. Наприклад, у вашій компанії може вже бути налаштований такий проксі, і всі застосунки в організації можуть бути зобовʼязані спрямовувати свій трафік через нього.
 
 Цей приклад показує, як забезпечити доступ до зовнішнього HTTPS-проксі. Оскільки застосунки використовують метод HTTP [CONNECT](https://tools.ietf.org/html/rfc7231#section-4.3.6) для встановлення зʼєднань з HTTPS-проксі, конфігурація трафіку до зовнішнього HTTPS-проксі відрізняється від конфігурації трафіку до зовнішніх HTTP та HTTPS-сервісів.
@@ -85,10 +86,10 @@ test: yes
     EOF
     {{< /text >}}
 
-1.  Розгорніть зразок [sleep]({{< github_tree >}}/samples/sleep) у просторі імен `external` для тестування трафіку на проксі без контролю трафіку Istio.
+1.  Розгорніть зразок [curl]({{< github_tree >}}/samples/curl) у просторі імен `external` для тестування трафіку на проксі без контролю трафіку Istio.
 
     {{< text bash >}}
-    $ kubectl apply -n external -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -n external -f @samples/curl/curl.yaml@
     {{< /text >}}
 
 1.  Отримайте IP-адресу проксі-сервера і визначте змінну оточення `PROXY_IP` для її зберігання:
@@ -103,10 +104,10 @@ test: yes
     $ export PROXY_PORT=3128
     {{< /text >}}
 
-1.  Надішліть запит з пода `sleep` в просторі імен `external` до зовнішнього сервіса через проксі:
+1.  Надішліть запит з пода `curl` в просторі імен `external` до зовнішнього сервіса через проксі:
 
     {{< text bash >}}
-    $ kubectl exec "$(kubectl get pod -n external -l app=sleep -o jsonpath={.items..metadata.name})" -n external -- sh -c "HTTPS_PROXY=$PROXY_IP:$PROXY_PORT curl https://en.wikipedia.org/wiki/Main_Page" | grep -o "<title>.*</title>"
+    $ kubectl exec "$(kubectl get pod -n external -l app=curl -o jsonpath={.items..metadata.name})" -n external -- sh -c "HTTPS_PROXY=$PROXY_IP:$PROXY_PORT curl https://en.wikipedia.org/wiki/Main_Page" | grep -o "<title>.*</title>"
     <title>Wikipedia, the free encyclopedia</title>
     {{< /text >}}
 
@@ -144,13 +145,14 @@ test: yes
         name: tcp
         protocol: TCP
       location: MESH_EXTERNAL
+      resolution: NONE
     EOF
     {{< /text >}}
 
-1.  Надішліть запит з пода `sleep` в просторі імен `default`. Оскільки под `sleep` має sidecar, Istio контролює його трафік.
+1.  Надішліть запит з пода `curl` в просторі імен `default`. Оскільки под `curl` має sidecar, Istio контролює його трафік.
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- sh -c "HTTPS_PROXY=$PROXY_IP:$PROXY_PORT curl https://en.wikipedia.org/wiki/Main_Page" | grep -o "<title>.*</title>"
+    $ kubectl exec "$SOURCE_POD" -c curl -- sh -c "HTTPS_PROXY=$PROXY_IP:$PROXY_PORT curl https://en.wikipedia.org/wiki/Main_Page" | grep -o "<title>.*</title>"
     <title>Wikipedia, the free encyclopedia</title>
     {{< /text >}}
 
@@ -179,16 +181,16 @@ test: yes
 
 ## Очищення {#cleanup}
 
-1. Завершіть роботу сервісу [sleep]({{< github_tree >}}/samples/sleep):
+1. Завершіть роботу сервісу [curl]({{< github_tree >}}/samples/curl):
 
     {{< text bash >}}
-    $ kubectl delete -f @samples/sleep/sleep.yaml@
+    $ kubectl delete -f @samples/curl/curl.yaml@
     {{< /text >}}
 
-2. Завершіть роботу сервісу [sleep]({{< github_tree >}}/samples/sleep) в просторі імен `external`:
+2. Завершіть роботу сервісу [curl]({{< github_tree >}}/samples/curl) в просторі імен `external`:
 
     {{< text bash >}}
-    $ kubectl delete -f @samples/sleep/sleep.yaml@ -n external
+    $ kubectl delete -f @samples/curl/curl.yaml@ -n external
     {{< /text >}}
 
 3. Завершіть роботу проксі Squid, видаліть `ConfigMap` і конфігураційний файл:

content/uk/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md

@@ -49,17 +49,17 @@ $ istioctl install --set profile=minimal -y \
 
 {{< /tabset >}}
 
-*   Розгорніть демонстраційний застосунок [sleep]({{< github_tree >}}/samples/sleep) для використання його як джерела тестових запитів.
+*   Розгорніть демонстраційний застосунок [curl]({{< github_tree >}}/samples/curl) для використання його як джерела тестових запитів.
 Якщо у вас увімкнено [автоматична інʼєкія sidecar](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection), виконайте наступну команду для розгортання застосунку:
 
     {{< text bash >}}
-    $ kubectl apply -f @samples/sleep/sleep.yaml@
+    $ kubectl apply -f @samples/curl/curl.yaml@
     {{< /text >}}
 
-    В іншому випадку, вручну додайте sidecar перед розгортанням застосунку `sleep` за допомогою наступної команди:
+    В іншому випадку, вручну додайте sidecar перед розгортанням застосунку `curl` за допомогою наступної команди:
 
     {{< text bash >}}
-    $ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
+    $ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@)
     {{< /text >}}
 
     {{< tip >}}
@@ -69,7 +69,7 @@ $ istioctl install --set profile=minimal -y \
 *   Встановіть змінну оточення `SOURCE_POD` на імʼя вашого тестового podʼа:
 
     {{< text bash >}}
-    $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
+    $ export SOURCE_POD=$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})
     {{< /text >}}
 
 ## Налаштування прямого трафіку до хосту за шаблоном {#direct-traffic-to-wildcard-host}
@@ -105,7 +105,7 @@ $ istioctl install --set profile=minimal -y \
 2.  Надішліть HTTPS-запит до [https://en.wikipedia.org](https://en.wikipedia.org) та [https://uk.wikipedia.org](https://uk.wikipedia.org):
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"; curl -s https://uk.wikipedia.org/wiki/Головна_сторінка | grep -o "<title>.*</title>"'
+    $ kubectl exec "$SOURCE_POD" -c curl -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"; curl -s https://uk.wikipedia.org/wiki/Головна_сторінка | grep -o "<title>.*</title>"'
     <title>Wikipedia, the free encyclopedia</title>
     <title>Вікіпедія</title>
     {{< /text >}}
@@ -289,7 +289,7 @@ EOF
     [https://en.wikipedia.org](https://en.wikipedia.org) та [https://uk.wikipedia.org](https://uk.wikipedia.org):
 
     {{< text bash >}}
-    $ kubectl exec "$SOURCE_POD" -c sleep -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"; curl -s https://uk.wikipedia.org/wiki/Головна_сторінка | grep -o "<title>.*</title>"'
+    $ kubectl exec "$SOURCE_POD" -c curl -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"; curl -s https://uk.wikipedia.org/wiki/Головна_сторінка | grep -o "<title>.*</title>"'
     <title>Wikipedia, the free encyclopedia</title>
     <title>Вікіпедія</title>
     {{< /text >}}
@@ -357,10 +357,10 @@ $ kubectl delete tlsroute forward-wikipedia-from-egress-gateway
 
 ## Очищення {#cleanup}
 
-* Зупиніть сервіс [sleep]({{< github_tree >}}/samples/sleep):
+* Зупиніть сервіс [curl]({{< github_tree >}}/samples/curl):
 
     {{< text bash >}}
-    $ kubectl delete -f @samples/sleep/sleep.yaml@
+    $ kubectl delete -f @samples/curl/curl.yaml@
     {{< /text >}}
 
 * Видаліть Istio з вашого кластера:

content/uk/docs/tasks/traffic-management/ingress/gateway-api/index.md

@@ -108,7 +108,9 @@ API Gateway мають багато спільного з API Istio, таким
 
     {{< text bash >}}
     $ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
+    ...
     HTTP/1.1 200 OK
+    ...
     server: istio-envoy
     ...
     {{< /text >}}
@@ -160,12 +162,9 @@ API Gateway мають багато спільного з API Istio, таким
 7.  Знову зверніться до `/headers` і помітьте, що до запиту було додано заголовок `My-Added-Header`:
 
     {{< text bash >}}
-    $ curl -s -HHost:httpbin.example.com "http://$INGRESS_HOST/headers"
-    {
-      "headers": {
-        "Accept": "*/*",
-        "Host": "httpbin.example.com",
-        "My-Added-Header": "added-value",
+    $ curl -s -HHost:httpbin.example.com "http://$INGRESS_HOST/headers" | jq '.headers["My-Added-Header"][0]'
+    ...
+    "added-value"
     ...
     {{< /text >}}
 

content/uk/docs/tasks/traffic-management/ingress/ingress-control/index.md

@@ -268,7 +268,9 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw my-gateway -o jsonpath='{.spec.li
 
     {{< text bash >}}
     $ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200"
+    ...
     HTTP/1.1 200 OK
+    ...
     server: istio-envoy
     ...
     {{< /text >}}

content/uk/docs/tasks/traffic-management/ingress/ingress-sidecar-tls-termination/index.md

@@ -194,12 +194,12 @@ EOF
 
 Тепер, коли сервер httpbin розгорнуто та налаштовано, запустіть два клієнти для тестування з’єднання як всередині, так і ззовні mesh:
 
-1. Внутрішній клієнт (sleep) в тому ж просторі імен (test), що і сервіс httpbin, з доданим sidecar.
-2. Зовнішній клієнт (sleep) в просторі імен default (тобто, поза сервісною мережею).
+1. Внутрішній клієнт (curl) в тому ж просторі імен (test), що і сервіс httpbin, з доданим sidecar.
+2. Зовнішній клієнт (curl) в просторі імен default (тобто, поза сервісною мережею).
 
 {{< text bash >}}
-$ kubectl apply -f samples/sleep/sleep.yaml
-$ kubectl -n test apply -f samples/sleep/sleep.yaml
+$ kubectl apply -f samples/curl/curl.yaml
+$ kubectl -n test apply -f samples/curl/curl.yaml
 {{< /text >}}
 
 Запустіть наступні команди, щоб перевірити, що все працює і налаштовано правильно.
@@ -207,21 +207,21 @@ $ kubectl -n test apply -f samples/sleep/sleep.yaml
 {{< text bash >}}
 $ kubectl get pods
 NAME                     READY   STATUS    RESTARTS   AGE
-sleep-557747455f-xx88g   1/1     Running   0          4m14s
+curl-557747455f-xx88g    1/1     Running   0          4m14s
 {{< /text >}}
 
 {{< text bash >}}
 $ kubectl get pods -n test
 NAME                       READY   STATUS    RESTARTS   AGE
 httpbin-5bbdbd6588-z9vbs   2/2     Running   0          8m44s
-sleep-557747455f-brzf6     2/2     Running   0          6m57s
+curl-557747455f-brzf6      2/2     Running   0          6m57s
 {{< /text >}}
 
 {{< text bash >}}
 $ kubectl get svc -n test
 NAME      TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
 httpbin   ClusterIP   10.100.78.113   <none>        8443/TCP,8080/TCP   10m
-sleep     ClusterIP   10.110.35.153   <none>        80/TCP              8m49s
+curl      ClusterIP   10.110.35.153   <none>        80/TCP              8m49s
 {{< /text >}}
 
 У наступній команді замініть `httpbin-5bbdbd6588-z9vbs` на назву вашого podʼа httpbin.
@@ -238,8 +238,8 @@ file-root:/etc/istio/tls-ca-certs/ca.crt                                Cert Cha
 ### Перевірка внутрішнього мережевого зʼєднання на порту 8080 {#verify-internal-mesh-connectivity-on-port-8080}
 
 {{< text bash >}}
-$ export INTERNAL_CLIENT=$(kubectl -n test get pod -l app=sleep -o jsonpath={.items..metadata.name})
-$ kubectl -n test exec "${INTERNAL_CLIENT}" -c sleep -- curl -IsS "http://httpbin:8080/status/200"
+$ export INTERNAL_CLIENT=$(kubectl -n test get pod -l app=curl -o jsonpath={.items..metadata.name})
+$ kubectl -n test exec "${INTERNAL_CLIENT}" -c curl -- curl -IsS "http://httpbin:8080/status/200"
 HTTP/1.1 200 OK
 server: envoy
 date: Mon, 24 Oct 2022 09:04:52 GMT
@@ -252,19 +252,19 @@ x-envoy-upstream-service-time: 5
 
 ### Перевірка зʼєднання ззовні в середину mesh на порту 8443 {#verify-external-to-internal-mesh-connectivity-on-port-8443}
 
-Щоб перевірити трафік mTLS від зовнішнього клієнта, спочатку скопіюйте сертифікат центру сертифікації та сертифікат/ключ клієнта в клієнта sleep, який працює у просторі імен default.
+Щоб перевірити трафік mTLS від зовнішнього клієнта, спочатку скопіюйте сертифікат центру сертифікації та сертифікат/ключ клієнта в клієнта curl, який працює у просторі імен default.
 
 {{< text bash >}}
-$ export EXTERNAL_CLIENT=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
+$ export EXTERNAL_CLIENT=$(kubectl get pod -l app=curl -o jsonpath={.items..metadata.name})
 $ kubectl cp client.test.svc.cluster.local.key default/"${EXTERNAL_CLIENT}":/tmp/
 $ kubectl cp client.test.svc.cluster.local.crt default/"${EXTERNAL_CLIENT}":/tmp/
 $ kubectl cp example.com.crt default/"${EXTERNAL_CLIENT}":/tmp/ca.crt
 {{< /text >}}
 
-Тепер, коли сертифікати доступні для зовнішнього клієнта sleep, ви можете перевірити підключення з нього до внутрішнього httpbin-сервісу за допомогою наступної команди.
+Тепер, коли сертифікати доступні для зовнішнього клієнта curl, ви можете перевірити підключення з нього до внутрішнього httpbin-сервісу за допомогою наступної команди.
 
 {{< text bash >}}
-$ kubectl exec "${EXTERNAL_CLIENT}" -c sleep -- curl -IsS --cacert /tmp/ca.crt --key /tmp/client.test.svc.cluster.local.key --cert /tmp/client.test.svc.cluster.local.crt -HHost:httpbin.test.svc.cluster.local "https://httpbin.test.svc.cluster.local:8443/status/200"
+$ kubectl exec "${EXTERNAL_CLIENT}" -c curl -- curl -IsS --cacert /tmp/ca.crt --key /tmp/client.test.svc.cluster.local.key --cert /tmp/client.test.svc.cluster.local.crt -HHost:httpbin.test.svc.cluster.local "https://httpbin.test.svc.cluster.local:8443/status/200"
 server: istio-envoy
 date: Mon, 24 Oct 2022 09:05:31 GMT
 content-type: text/html; charset=utf-8
@@ -278,7 +278,7 @@ x-envoy-decorator-operation: ingress-sidecar.test:9080/*
 Окрім перевірки зовнішнього mTLS-зʼєднання через вхідний порт 8443, важливо також переконатися, що порт 8080 не приймає ніякого зовнішнього mTLS-трафіку.
 
 {{< text bash >}}
-$ kubectl exec "${EXTERNAL_CLIENT}" -c sleep -- curl -IsS --cacert /tmp/ca.crt --key /tmp/client.test.svc.cluster.local.key --cert /tmp/client.test.svc.cluster.local.crt -HHost:httpbin.test.svc.cluster.local "http://httpbin.test.svc.cluster.local:8080/status/200"
+$ kubectl exec "${EXTERNAL_CLIENT}" -c curl -- curl -IsS --cacert /tmp/ca.crt --key /tmp/client.test.svc.cluster.local.key --cert /tmp/client.test.svc.cluster.local.crt -HHost:httpbin.test.svc.cluster.local "http://httpbin.test.svc.cluster.local:8080/status/200"
 curl: (56) Recv failure: Connection reset by peer
 command terminated with exit code 56
 {{< /text >}}
@@ -289,11 +289,11 @@ command terminated with exit code 56
 
     {{< text bash >}}
     $ kubectl delete secret httpbin-mtls-termination httpbin-mtls-termination-cacert -n test
-    $ kubectl delete service httpbin sleep -n test
-    $ kubectl delete deployment httpbin sleep -n test
+    $ kubectl delete service httpbin curl -n test
+    $ kubectl delete deployment httpbin curl -n test
     $ kubectl delete namespace test
-    $ kubectl delete service sleep
-    $ kubectl delete deployment sleep
+    $ kubectl delete service curl
+    $ kubectl delete deployment curl
     {{< /text >}}
 
 1.  Видаліть сертифікати та приватні ключі:

content/uk/docs/tasks/traffic-management/ingress/kubernetes-ingress/index.md

@@ -13,7 +13,7 @@ test: yes
 Рекомендується використовувати [Gateway](/docs/tasks/traffic-management/ingress/ingress-control/), а не Ingress, щоб скористатися повним набором функцій, які пропонує Istio, такими як розширене управління трафіком і функції безпеки.
 {{< /tip >}}
 
-## Перш ніж почати  {#before-you-begin}
+## Перш ніж почати {#before-you-begin}
 
 Дотримуйтесь інструкцій у розділах [Перед початком роботи](/docs/tasks/traffic-management/ingress/ingress-control/#before-you-begin) та [Визначення вхідного IP та портів](/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports) з [завдання Ingress Gateways](/docs/tasks/traffic-management/ingress/ingress-control/).
 
@@ -54,7 +54,9 @@ test: yes
 
     {{< text bash >}}
     $ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200"
+    ...
     HTTP/1.1 200 OK
+    ...
     server: istio-envoy
     ...
     {{< /text >}}

content/uk/docs/tasks/traffic-management/ingress/secure-ingress/index.md

@@ -244,15 +244,8 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw mygateway -n istio-system -o json
     ...
     HTTP/2 418
     ...
-        -=[ teapot ]=-
-
-           _...._
-         .'  _ _ `.
-        | ."` ^ `". _,
-        \_;`"---"`|//
-          |       ;/
-          \_     _/
-            `"""`
+    I'm a teapot!
+    ...
     {{< /text >}}
 
     Сервіс `httpbin` поверне код [418 I'm a Teapot](https://tools.ietf.org/html/rfc7168#section-2.3.3).
@@ -274,15 +267,8 @@ $ export SECURE_INGRESS_PORT=$(kubectl get gtw mygateway -n istio-system -o json
     ...
     HTTP/2 418
     ...
-        -=[ teapot ]=-
-
-           _...._
-         .'  _ _ `.
-        | ."` ^ `". _,
-        \_;`"---"`|//
-          |       ;/
-          \_     _/
-            `"""`
+    I'm a teapot!
+    ...
     {{< /text >}}
 
 4) Якщо ви спробуєте отримати доступ до `httpbin`, використовуючи попередній ланцюжок сертифікатів, спроба завершиться невдачею:
@@ -478,21 +464,16 @@ EOF
     ...
     {{< /text >}}
 
-2) Надішліть запит HTTPS до `httpbin.example.com` і також отримайте відповідь teapot:
+2) Надішліть запит HTTPS до `httpbin.example.com` і також отримайте відповідь [HTTP 418](https://datatracker.ietf.org/doc/html/rfc2324):
 
     {{< text bash >}}
     $ curl -v -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \
       --cacert example_certs1/example.com.crt "https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418"
     ...
-        -=[ teapot ]=-
-
-           _...._
-         .'  _ _ `.
-        | ."` ^ `". _,
-        \_;`"---"`|//
-          |       ;/
-          \_     _/
-            `"""`
+    HTTP/2 418
+    ...
+    server: istio-envoy
+    ...
     {{< /text >}}
 
 ### Налаштуйте взаємний TLS ingress gateway {#configure-a-mutual-tls-ingress-gateway}
@@ -610,15 +591,12 @@ EOF
       --cacert example_certs1/example.com.crt --cert example_certs1/client.example.com.crt --key example_certs1/client.example.com.key \
       "https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418"
     ...
-        -=[ teapot ]=-
-
-           _...._
-         .'  _ _ `.
-        | ."` ^ `". _,
-        \_;`"---"`|//
-          |       ;/
-          \_     _/
-            `"""`
+    HTTP/2 418
+    ...
+    server: istio-envoy
+    ...
+    I'm a teapot!
+    ...
     {{< /text >}}
 
 ## Додаткова інформація {#more-info}

content/uk/docs/tasks/traffic-management/locality-load-balancing/before-you-begin/index.md

@@ -119,13 +119,13 @@ $ kubectl apply --context="${CTX_R3_Z4}" -n sample \
   -f helloworld-region3.zone4.yaml
 {{< /text >}}
 
-## Розгортання `Sleep` {#deploy-sleep}
+## Розгортання `curl` {#deploy-curl}
 
-Розгорніть застосунок `Sleep` в `region1` `zone1`:
+Розгорніть застосунок `curl` в `region1` `zone1`:
 
 {{< text bash >}}
 $ kubectl apply --context="${CTX_R1_Z1}" \
-  -f @samples/sleep/sleep.yaml@ -n sample
+  -f @samples/curl/curl.yaml@ -n sample
 {{< /text >}}
 
 ## Зачекайте на podʼи `HelloWorld` {#wait-for-helloworld-pods}

content/uk/docs/tasks/traffic-management/locality-load-balancing/distribute/index.md

@@ -11,7 +11,7 @@ owner: istio/wg-networking-maintainers
 Перед тим як продовжити, обовʼязково виконайте кроки, описані в розділі
 [перш ніж розпочати](/docs/tasks/traffic-management/locality-load-balancing/before-you-begin).
 
-У цьому завданні ви використаєте pod `Sleep` у `region1` `zone1` як джерело
+У цьому завданні ви використаєте pod `curl` у `region1` `zone1` як джерело
 запитів до сервісу `HelloWorld`. Ви налаштуєте Istio з наступним
 розподілом між локаціями:
 
@@ -57,12 +57,12 @@ EOF
 
 ## Перевірка розподілу {#verify-the-distribution}
 
-Викличте сервіс `HelloWorld` з pod `Sleep`:
+Викличте сервіс `HelloWorld` з pod `curl`:
 
 {{< text bash >}}
-$ kubectl exec --context="${CTX_R1_Z1}" -n sample -c sleep \
+$ kubectl exec --context="${CTX_R1_Z1}" -n sample -c curl \
   "$(kubectl get pod --context="${CTX_R1_Z1}" -n sample -l \
-  app=sleep -o jsonpath='{.items[0].metadata.name}')" \
+  app=curl -o jsonpath='{.items[0].metadata.name}')" \
   -- curl -sSL helloworld.sample:5000/hello
 {{< /text >}}