mirror of https://github.com/istio/istio.io.git
Add Ukrainian language support (#15677)
This commit is contained in:
Andrii Holovin
GitHub
parent
2e453e8da1
commit
a13ef3832d
|
|
@ -0,0 +1,114 @@
|
|||
---
|
||||
title: Istio
|
||||
description: Сервісна мережа для спостережуваності, поглибленої безпеки та управління, що прискорює процеси розгортання.
|
||||
---
|
||||
<!-- these script blocks are only for the primary English home page -->
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "http://schema.org",
|
||||
"@type": "Organization",
|
||||
"url": "https://istio.io",
|
||||
"logo": "https://istio.io/img/logo.png",
|
||||
"sameAs": [
|
||||
"https://twitter.com/IstioMesh",
|
||||
]
|
||||
}
|
||||
</script>
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "http://schema.org",
|
||||
"@type": "WebSite",
|
||||
"url": "https://istio.io/",
|
||||
"potentialAction": {
|
||||
"@type": "SearchAction",
|
||||
"target": "https://istio.io/search?q={search_term_string}",
|
||||
"query-input": "required name=search_term_string"
|
||||
}
|
||||
}
|
||||
</script>
|
||||
|
||||
<main class="landing">
|
||||
<section id="hero">
|
||||
<h1 id="title">
|
||||
Сервісна мережа. Це просто.
|
||||
</h1>
|
||||
<p class="subtitle">Легко створюйте хмарні робочі навантаження безпечно та надійно за допомогою Istio, з sidecar контейнерами чи без.</p>
|
||||
</section>
|
||||
|
||||
<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="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>
|
||||
</section>
|
||||
|
||||
<section id="service-mesh" class="container">
|
||||
<h1>Що таке Istio?</h1>
|
||||
|
||||
<p>
|
||||
Istio розширює Kubernetes для створення програмованої мережі, що адаптується до конкретних потреб. Працюючи як з Kubernetes, так і з традиційними робочими навантаженнями, Istio забезпечує стандартне, універсальне управління трафіком, телеметрію та безпеку для складних розгортань.
|
||||
<br/><br/>
|
||||
Виберіть потрібні вам функції, і Istio розгорне проксі-інфраструктуру відповідно до ваших потреб. Використовуйте тунель zero-trust для покращення продуктивності 4-го рівня та безпеки, або додайте потужний проксі-сервер служби Envoy для функцій рівня 7.
|
||||
</p>
|
||||
|
||||
<div class="cta-container">
|
||||
<a class="btn" href="/uk/about/service-mesh">Дізнайтесь більше</a>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="case-studies" class="container">
|
||||
<h1>Нам довіряють</h1>
|
||||
|
||||
{{< logo_carousel >}}
|
||||
|
||||
<div class="cta-container">
|
||||
<a class="btn" href="/uk/about/case-studies">Дізнайтесь про приклади використання</a>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="features" class="container">
|
||||
<h1>Можливості</h1>
|
||||
|
||||
<div class="panels">
|
||||
{{< content_panel type="transparent" title="security" text="Проста реалізація безпеки між сервісами, включаючи автентифікацію, авторизацію та шифрування за допомогою mTLS." button="learn_more" image="security.svg" url="/uk/docs/concepts/security/" >}}
|
||||
{{< content_panel type="transparent" title="observability" text="Оптимізація найкращих практик за допомогою повної видимості застосунків і визначення того, на чому слід зосередитися для підвищення продуктивності." button="learn_more" image="observability.svg" url="/uk/docs/concepts/observability/" >}}
|
||||
{{< content_panel type="transparent" title="traffic_management" text="Керуйте мережею для сервісів послідовно, без додаткових складнощів для розробників." button="learn_more" image="management.svg" url="/uk/docs/concepts/traffic-management/" >}}
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
<section id="providers" class="container">
|
||||
<h1>Провайдери Istio</h1>
|
||||
|
||||
<p>
|
||||
Istio підтримується та впроваджується екосистемою провідних провайдерів та консультантів. Ви можете встановити та керувати Istio самостійно або скористатися функцією встановлення в один дотик від вашого провайдера Kubernetes чи хмарного сервісу. Інший варіант — звернутися до провайдера за повністю автоматизованою системою обслуговування на базі Istio. Виберіть спосіб, який підходить саме вам.
|
||||
</p>
|
||||
|
||||
<div class="companies-grid">
|
||||
{{< 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://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" >}}
|
||||
{{< company_logo link="https://tanzu.vmware.com/service-mesh" logo="/logos/vmware.svg" alt="VMware" >}}
|
||||
</div>
|
||||
|
||||
<div class="cta-container">
|
||||
<a class="btn" href="/uk/about/ecosystem#providers">Переглянути всіх провайдерів</a>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="cncf" class="container">
|
||||
<div class="cncf-logo">
|
||||
<figure>
|
||||
<img src="/img/cncf-color.svg" alt="Cloud Native Computing Foundation logo"/>
|
||||
<figcaption>
|
||||
<p>Ми є дипломованим проєктом Cloud Native Computing Foundation.</p>
|
||||
</figcaption>
|
||||
</figure>
|
||||
</div>
|
||||
</section>
|
||||
</main>
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
title: Про Istio
|
||||
linktitle: Про Istio
|
||||
description: Дізнайтеся більше про проєкт Istio.
|
||||
sidebar_none: true
|
||||
weight: 15
|
||||
doc_type: about
|
||||
cascade:
|
||||
_build:
|
||||
render: always
|
||||
list: always
|
||||
_build:
|
||||
render: never
|
||||
list: never
|
||||
---
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: Приклади використання
|
||||
aliases:
|
||||
- /uk/case-studies
|
||||
- /uk/about/community/customers
|
||||
- /uk/latest/about/community/customers
|
||||
doc_type: about
|
||||
type: case-studies
|
||||
sidebar_none: true
|
||||
---
|
||||
|
||||
[comment]: <> (Щоб додати себе як користувача Istio, будь ласка, перегляньте https://github.com/istio/community/blob/master/CONTRIBUTING.md#tell-the-world-youre-using-istio.)
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
---
|
||||
title: Розгортання
|
||||
description: Розгортання.
|
||||
subtitle: Прочитайте про найкращі практики, які забезпечують швидку та ефективну реалізацію для першого дня, другого дня та тисячного дня.
|
||||
weight: 34
|
||||
skip_toc: true
|
||||
skip_byline: true
|
||||
skip_pagenav: true
|
||||
aliases:
|
||||
- /deployment.html
|
||||
doc_type: about
|
||||
---
|
||||
|
||||
{{< centered_block >}}
|
||||
|
||||
Ви вирішили використовувати Istio. Ласкаво просимо у світ сервісних мереж. Вітаємо, ви в чудовій компанії!
|
||||
|
||||
Якщо ви ще не зробили цього, вам може бути цікаво спробувати Istio в тестовому середовищі та ознайомитися з нашим [посібником щодо початку роботи](/docs/setup/getting-started/). Це дасть вам уявлення про функції **керування трафіком**, **безпеки** та **спостережуваності**.
|
||||
|
||||
## Робити самостійно чи звертатися до гіда? {#do-it-yourself-or-bring-a-guide}
|
||||
|
||||
Istio — це програмне забезпечення з відкритим кодом, яке ви можете завантажити та встановити самостійно. Встановити мережу в кластері Kubernetes так само просто, як виконати одну команду:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl install
|
||||
{{< /text >}}
|
||||
|
||||
Коли випускаються нові версії, ви можете тестувати їх і поступово розгортати на своїх кластерах.
|
||||
|
||||
Багато постачальників послуг Kubernetes пропонують опцію автоматичної установки та керування Istio для вас. Ознайомтеся з нашою [сторінкою дистрибʼюторів](/about/ecosystem/), щоб дізнатися, чи підтримує ваш постачальник Istio.
|
||||
|
||||
Istio також є рушієм багатьох комерційних продуктів для керування сервісами, з командами експертів, готовими допомогти вам на початку роботи.
|
||||
|
||||
Зростає спільнота консультантів з хмарних технологій, які можуть допомогти вам на шляху до Istio. Якщо ви плануєте співпрацювати з учасником екосистеми Istio, ми рекомендуємо залучити їх на ранніх етапах. Багато наших партнерів і дистрибʼюторів працюють з проєктом вже дуже довгий час і будуть цінними помічниками для вас у цій подорожі.
|
||||
|
||||
## Що варто увімкнути в першу чергу? {#what-should-you-enable-first}
|
||||
|
||||
Є багато вагомих причин для впровадження Istio: від додавання безпеки до ваших мікросервісів до підвищення надійності ваших застосунків. Незалежно від ваших цілей, найуспішніші впровадження Istio починаються з визначення одного випадку використання та його вирішення. Після налаштування мережі для вирішення однієї проблеми ви можете легко увімкнути інші функції, підвищуючи корисність вашого розгортання.
|
||||
|
||||
## Як звʼязати мережу з вашою архітектурою? {#how-do-i-map-the-mesh-to-my-architecture}
|
||||
|
||||
Поступово підключайте свої сервіси до мережі, додаючи один простір імен за раз. Стандартно сервіси з кількох просторів імен можуть спілкуватися між собою, але ви можете легко збільшити ізоляцію, вибірково визначаючи, які сервіси відкривати для інших просторів імен. Використання просторів імен також покращує продуктивність, оскільки конфігурація зменшується.
|
||||
|
||||
Istio є гнучким для налаштування відповідно до конфігурації вашого кластера Kubernetes та архітектури мережі. Ви можете захотіти запустити окремі мережі та панелі управління в окремих кластерах або мати одну.
|
||||
|
||||
Поки Podʼи можуть спілкуватись один з одним в мережі, Istio працюватиме; ви навіть можете налаштувати Istio Gateways для виконання ролі бастіонних хостів між мережами.
|
||||
|
||||
Дізнайтеся більше про [повний спектр моделей розгортання](/docs/ops/deployment/deployment-models/) у нашій документації.
|
||||
|
||||
Зараз також чудовий час подумати про те, які інтеграції ви хочете використовувати: ми рекомендуємо [налаштувати Prometheus](/docs/ops/integrations/prometheus/#Configuration) для моніторингу сервісів з [ієрархічною федерацією на зовнішній сервер](/docs/ops/best-practices/observability/). Якщо стек спостережуваності вашої компанії управляється іншою командою, зараз саме час їх долучити.
|
||||
|
||||
## Додавання сервісів до мережі, День 1 {#adding-services-to-the-mesh-on-day-1}
|
||||
|
||||
Ваша мережа тепер налаштована і готова приймати сервіси. Для цього вам потрібно позначити простори імен у Kubernetes, і коли ці сервіси будуть перевстановлені, вони тепер матимуть проксі Envoy, налаштований для звʼязку з панеллю управління Istio.
|
||||
|
||||
### Налаштування сервісів {#configuring-services}
|
||||
|
||||
Багато сервісів будуть працювати з коробки, але додавши трохи інформації до ваших маніфестів Kubernetes, ви можете зробити Istio набагато розумнішим. Наприклад, встановлення міток для `app` і `version` допоможе з подальшими запитами метрик.
|
||||
|
||||
Для звичайних портів і протоколів Istio визначить тип трафіку. Якщо тип трафіку не можна визначити, він вважатиметься як трафік TCP, але ви можете легко [додати анотацію до сервісу](/docs/ops/configuration/traffic-management/protocol-selection/) з типом трафіку.
|
||||
|
||||
Дізнайтеся більше про [увімкнення застосунків для використання з Istio](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
### Увімкнення безпеки {#enabling-security}
|
||||
|
||||
Istio налаштує сервіси в мережі для використання mTLS при взаємодії між собою, коли це можливо. Стандартно Istio працює в режимі "дозвільного mTLS", що означає, що сервіси прийматимуть як зашифрований, так і незашифрований трафік, щоб дозволити трафіку від сервісів, не налаштованих у мережі, залишатися функціональним. Після підключення всіх ваших сервісів до мережі, ви можете [змінити політику автентифікації, щоб дозволити лише зашифрований трафік](/docs/tasks/security/authentication/mtls-migration/). Це дозволить вам бути впевненими, що весь ваш трафік зашифрований.
|
||||
|
||||
### Два типи API в Istio {#istios-two-types-of-api}
|
||||
|
||||
Istio має API для власників платформи та власників сервісів. Залежно від вашої ролі, вам потрібно розглянути лише певний набір. Наприклад, власники платформи будуть відповідати за ресурси встановлення, автентифікації та авторизації. Ресурси керування трафіком будуть оброблятися власниками сервісів. [Дізнайтеся, які API будуть корисні вам.](/docs/reference/config/)
|
||||
|
||||
### Підключення сервісів на віртуальних машинах {#connect-services-on-virtual-machines}
|
||||
|
||||
Istio не тільки для Kubernetes; можливо [додати сервіси на віртуальних машинах](/docs/setup/install/virtual-machine/) (або на фізичних серверах) до мережі, щоб отримати всі переваги, які надає Istio, такі як взаємне TLS, повноцінна телеметрія та розширені можливості керування трафіком.
|
||||
|
||||
### Моніторинг ваших сервісів {#monitor-your-services}
|
||||
|
||||
Переглядайте трафік, що проходить через вашу мережу, за допомогою [Kiali](/docs/ops/integrations/kiali/), або відстежуйте запити за допомогою [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/) або [Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/).
|
||||
|
||||
Використовуйте стандартні інфопанелі [Grafana](/docs/ops/integrations/grafana/) для Istio, щоб автоматично отримувати звіти про золоті сигнали для сервісів, що працюють у мережі.
|
||||
|
||||
## Операційні міркування та День 2 {#operational-considerations-and-day-2}
|
||||
|
||||
Як власник платформи, ви відповідаєте за встановлення та підтримку мережі в актуальному стані з мінімальним впливом на команди, що займаються сервісами.
|
||||
|
||||
### Встановлення {#installation}
|
||||
|
||||
З istioctl ви можете легко встановити Istio, використовуючи один із вбудованих профілів. У міру налаштування вашої установки для задоволення ваших вимог рекомендується визначити конфігурацію за допомогою спеціального ресурсу IstioOperator (CR). Це дає вам можливість повністю делегувати завдання управління встановленням оператору Istio, замість того, щоб робити це вручну за допомогою istioctl. Використовуйте CR IstioOperator лише для панелі управління та додаткові CR IstioOperator для шлюзів для підвищення гнучкості під час оновлення.
|
||||
|
||||
### Оновлення без ризику {#update-safely}
|
||||
|
||||
Коли виходить нова версія, Istio дозволяє виконувати як оновлення на місці, так і канаркові оновлення. Вибір між ними — це компроміс між простотою та потенційним простоєм. Для промислових середовищ рекомендується використовувати [канарковий метод оновлення](/docs/setup/upgrade/canary/). Після того, як нові версії панелі управління та панелі даних будуть перевірені на працездатність, ви можете оновити свої шлюзи.
|
||||
|
||||
### Моніторинг мережі {#monitor-the-mesh}
|
||||
|
||||
Istio генерує детальну телеметрію для всіх комунікацій сервісів в мережі. Ці метрики, трасування та журнали доступу є важливими для розуміння того, як ваші застосунки взаємодіють між собою та для виявлення будь-яких вузьких місць продуктивності. Використовуйте цю інформацію, щоб допомогти вам налаштувати запобіжники, тайм-аути та повторні спроби, і зробити ваші застосунки більш стійкими.
|
||||
|
||||
Так само як і ваші застосунки, що працюють у мережі, компоненти панелі управління Istio також експортують метрики. Використовуйте ці метрики та попередньо налаштовані інфопанелі Grafana для налаштування запитів ресурсів, лімітів та масштабування.
|
||||
|
||||
## Приєднуйтесь до спільноти Istio {#join-the-istio-community}
|
||||
|
||||
Як тільки ви почнете використовувати Istio, ви станете членом великої глобальної спільноти. Ви можете ставити питання на [нашому форумі](https://discuss.istio.io/), або [приєднатися до Slack](https://slack.istio.io/). І якщо ви хочете щось покращити, або маєте запит на нову функцію, ви можете звернутися прямо в [GitHub](https://github.com/istio/istio).
|
||||
|
||||
Бажаємо успішного використання мережі!
|
||||
|
||||
{{< /centered_block >}}
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
title: Екосистема
|
||||
description: Список постачальників Istio, компаній, що надають професійні послуги, та інтеграцій.
|
||||
subtitle: Різноманітність постачальників, які встановлюють та керують Istio, професійні послуги та інтеграції допоможуть вам максимально використати вашу сервісну мережу.
|
||||
weight: 34
|
||||
skip_toc: true
|
||||
skip_byline: true
|
||||
skip_pagenav: true
|
||||
aliases:
|
||||
- /uk/about/community/partners/
|
||||
- /uk/latest/about/community/partners/
|
||||
doc_type: about
|
||||
---
|
||||
|
||||
[comment]: <> (Щоб додати постачальника Istio, компанію з надання професійних послуг або інтеграцію, будь ласка, перегляньте https://github.com/istio/community/blob/master/CONTRIBUTING.md#promote-your-company-on-istioio.)
|
||||
|
||||
{{< tabset category-name="ecosystem-type" class="tabset--ecosystem" forget-tab=true >}}
|
||||
|
||||
{{< tab
|
||||
name="постачальники"
|
||||
category-value="providers"
|
||||
description="Багато компаній створюють платформи та сервіси, що встановлюють, керують та впроваджують Istio для вас. Насправді реалізації Istio вбудовані в багато Kubernetes сервісів, що надаються їх постачальниками."
|
||||
>}}
|
||||
|
||||
{{< companies items="providers">}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab
|
||||
name="професійні послуги"
|
||||
category-value="services"
|
||||
description="Є багато фахівців, які можуть допомогти вам налаштувати конфігурацію Istio. Ось деякі експерти, які можуть впровадити Istio для вас, адаптуючи його можливості до ваших вимог."
|
||||
>}}
|
||||
|
||||
{{< interactive_panels items="pro_services" >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab
|
||||
name="інтеграції"
|
||||
category-value="integrations"
|
||||
description="Istio є активною частиною стека cloud native. Це деякі проєкти та програмне забезпечення, що інтегруються з Istio для розширення функціональності."
|
||||
>}}
|
||||
|
||||
{{< interactive_panels items="integrations" >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
{{< interactive_panel_modal >}}
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Часті запитання
|
||||
description: Часті запитання про Istio.
|
||||
subtitle: Ми сподіваємося, що ці поширені запитання допоможуть вам у пошуку інформації про технологію Istio та сервісні мережі!
|
||||
weight: 1
|
||||
layout: faq-landing
|
||||
aliases:
|
||||
- /uk/docs/welcome/faq.html
|
||||
- /uk/docs/reference/faq.html
|
||||
- /uk/help/faq/
|
||||
- /uk/faq.html
|
||||
skip_toc: false
|
||||
skip_byline: true
|
||||
skip_pagenav: true
|
||||
sidebar_none: true
|
||||
doc_type: about has-toc
|
||||
---
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Режим оточення, ЧаПи
|
||||
linktitle: Режим оточення
|
||||
description: Питання та відповіді про режим оточення.
|
||||
weight: 30
|
||||
layout: faq
|
||||
aliases:
|
||||
- /uk/help/faq/ambient-mode
|
||||
---
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи є ztunnel єдиною точкою відмови?
|
||||
weight: 25
|
||||
---
|
||||
|
||||
ztunnel в Istio не вводить єдину точку відмови (SPOF) у кластер Kubernetes. Відмови ztunnel обмежені окремим вузлом, який є вразливим компонентом у кластері. Він поводиться так само як і інша критична інфраструктура вузлів, що працює в кожному кластері, така як ядро Linux, середовище виконання контейнерів тощо. У правильно спроєктованій системі відмови вузлів не призводять до відмови кластера. [Дізнайтеся більше](https://blog.howardjohn.info/posts/ambient-spof/).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Як я можу контролювати обсяги тресів?
|
||||
weight: 40
|
||||
---
|
||||
|
||||
Istio через Envoy зараз підтримує стратегію вибірки на основі відсотків для генерації трейсів. Будь ласка, ознайомтеся з [цією секцією](/docs/tasks/observability/distributed-tracing/mesh-and-proxy-config/#customizing-trace-sampling) для отримання інформації про те, як налаштувати цей рівень вибірки.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Як вимкнути трейсинг?
|
||||
weight: 50
|
||||
---
|
||||
|
||||
Якщо ви вже встановили Istio з увімкненим трейсингом, ви можете вимкнути його наступним чином:
|
||||
|
||||
{{< text plain >}}
|
||||
# Заповніть <istio namespace> простором імен вашої mesh Istio. Наприклад: istio-system
|
||||
TRACING_POD=`kubectl get po -n <istio namespace> | grep istio-tracing | awk '{print $1}'`
|
||||
$ kubectl delete pod $TRACING_POD -n <istio namespace>
|
||||
$ kubectl delete services tracing zipkin -n <istio namespace>
|
||||
# Тепер вручну видаліть всі екземпляри trace_zipkin_url з файлу та збережіть його.
|
||||
{{< /text >}}
|
||||
|
||||
Потім дотримуйтесь кроків [розділу очищення завдання Розподілений трейсинг](/docs/tasks/observability/distributed-tracing/zipkin/#cleanup).
|
||||
|
||||
Якщо вам взагалі не потрібна функціональність трейсинг, тоді [вимкніть трейсинг](/docs/tasks/observability/distributed-tracing/zipkin/#before-you-begin) під час встановлення Istio.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи може Istio відправляти інформацію про трейсинг на зовнішній сервер сумісний з Zipkin?
|
||||
weight: 70
|
||||
---
|
||||
|
||||
Так, для цього потрібно використовувати повне доменне імʼя сумісного з Zipkin екземпляру. Наприклад: `zipkin.mynamespace.svc.cluster.local`.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: Як працює розподілений трейсинг з Istio?
|
||||
weight: 0
|
||||
---
|
||||
|
||||
Istio інтегрується з системами розподіленого трейсингу, використовуючи [Envoy-based](#how-envoy-based-tracing-works) трейсинг. Завдяки інтеграції трейсингу на основі Envoy, [застосунки відповідають за перенаправлення заголовків трейсів](#istio-copy-headers) для наступних вихідних запитів.
|
||||
|
||||
Додаткову інформацію можна знайти в завданнях Розподілений трейсинг в Istio ([Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/), [Lightstep](/docs/tasks/observability/distributed-tracing/lightstep/), [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/)) та у [документації Envoy щодо трейсів](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing).
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
---
|
||||
title: Як працює трейсинг на основі Envoy?
|
||||
weight: 11
|
||||
---
|
||||
|
||||
Для інтеграцій трейсингу на основі Envoy, Envoy (sidecar проксі) надсилає інформацію про трейсинг безпосередньо до бекендів трейсингу від імені застосунків, що проходять через проксі.
|
||||
|
||||
Envoy:
|
||||
|
||||
- генерує ID запитів та заголовки трейсингу (наприклад, `X-B3-TraceId`) для запитів, коли вони проходять через проксі
|
||||
- генерує трейс-відрізки (span) для кожного запиту на основі метаданих запиту та відповіді (наприклад, час відповіді)
|
||||
- надсилає згенеровані трейс-відрізки (span) до бекендів трейсингу
|
||||
- передає заголовки трейсингу до застосунку, який проходить через проксі
|
||||
|
||||
Istio підтримує інтеграції трейсингу на основі Envoy для [Lightstep](/docs/tasks/observability/distributed-tracing/lightstep/) та [Zipkin](/docs/tasks/observability/distributed-tracing/zipkin/), а також усіх сумісних з API Zipkin бекендів, включаючи [Jaeger](/docs/tasks/observability/distributed-tracing/jaeger/).
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
title: Що потрібно для розподіленого трейсингу на основі Istio?
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Istio дозволяє звітувати про трейс-відрізки (span) для комунікацій між робочими навантаженнями всередині мережі. Проте, щоб різні трейс-відрізки (span) могли бути зшиті разом для повного огляду потоку трафіку, застосунки повинні пропагувати контекст трейсингу між вхідними та вихідними запитами.
|
||||
|
||||
Зокрема, Istio покладається на застосунки для [пропагування заголовків B3 трейсингу](https://github.com/openzipkin/b3-propagation), а також згенерованого Envoy ID запиту. Ці заголовки включають:
|
||||
|
||||
- `x-request-id`
|
||||
- `x-b3-traceid`
|
||||
- `x-b3-spanid`
|
||||
- `x-b3-parentspanid`
|
||||
- `x-b3-sampled`
|
||||
- `x-b3-flags`
|
||||
- `b3`
|
||||
|
||||
Якщо ви використовуєте Lightstep, вам також потрібно буде передавати наступні заголовки:
|
||||
|
||||
- `x-ot-span-context`
|
||||
|
||||
Якщо ви використовуєте OpenTelemetry або Stackdriver, вам також потрібно буде передавати наступні заголовки:
|
||||
|
||||
- `traceparent`
|
||||
- `tracestate`
|
||||
|
||||
Пропагування заголовків може бути здійснене за допомогою бібліотек клієнтів, таких як [Zipkin](https://zipkin.io/pages/tracers_instrumentation.html) або [Jaeger](https://github.com/jaegertracing/jaeger-client-java/tree/master/jaeger-core#b3-propagation). Також це можна зробити вручну, як документовано в [Завданні з трейсингу](/docs/tasks/observability/distributed-tracing/overview/#trace-context-propagation).
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Розподілений трейсинг, ЧаПи
|
||||
linktitle: Розподілений трейсинг
|
||||
description: Розподілений трейсинг, часті питання.
|
||||
weight: 46
|
||||
layout: faq
|
||||
aliases:
|
||||
- /uk/help/faq/distributed-tracing
|
||||
---
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Хто генерує початкові HTTP заголовки Zipkin (B3)?
|
||||
weight: 15
|
||||
---
|
||||
|
||||
Початкові [заголовки](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-request-id) Zipkin (B3) генерує sidecar проксі Istio (Envoy), якщо вони не надаються запитом.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чому Istio не може передавати заголовки замість застосунку?
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Хоча sidecar Istio обробляє як вхідні, так і вихідні запити для асоційованого екземпляра застосунку, він не має явного способу корелювати вихідні запити з вхідним запитом, який їх спричинив. Єдиний спосіб досягти такої кореляції — це якщо застосунок передає відповідну інформацію (наприклад, заголовки) з вхідного запиту до вихідних запитів. Передача заголовків може бути здійснена через клієнтські бібліотеки або вручну. Подальше обговорення представлено в [Що потрібно для розподіленого трейсингу з Istio?](/about/faq/#how-to-support-tracing).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Яка мінімальна конфігурація Istio потрібна для розподіленого трейсингу?
|
||||
weight: 13
|
||||
---
|
||||
|
||||
Для інтеграції з бекендами, сумісними з Zipkin, достатньо встановити [мінімальний профіль Istio](/docs/setup/install/helm/) з увімкненим трейсингом.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Чому мої запити не відстежуються?
|
||||
weight: 30
|
||||
---
|
||||
|
||||
З початку версії Istio 1.0.3 швидкість вибірки для трейсингу була зменшена до 1% в [конфігураційному профілі `default`](/docs/setup/additional-setup/config-profiles/). Це означає, що лише 1 з 100 трейсів, захоплених Istio, буде надіслано до бекенда для трейсингу. Швидкість вибірки в профілі `demo` все ще встановлена на 100%. Дивіться [цей розділ секцію](/docs/tasks/observability/distributed-tracing/mesh-and-proxy-config/#customizing-trace-sampling) для отримання додаткової інформації про те, як налаштувати швидкість вибірки.
|
||||
|
||||
Якщо ви все ще не бачите дані трейсингу, будь ласка, переконайтесь, що ваші порти відповідають [конвенціям іменування портів](/about/faq/#naming-port-convention) в Istio і що відповідний порт контейнера відкритий (наприклад, через специфікацію podʼа), щоб дозволити захоплення трафіку sidecar проксі (Envoy).
|
||||
|
||||
Якщо ви бачите дані трейсингу тільки для egress-проксі, але не для ingress-проксі, це також може бути повʼязано з [конвенціями іменування портів](/about/faq/#naming-port-convention). Починаючи з [Istio 1.3](/news/releases/1.3.x/announcing-1.3/#intelligent-protocol-detection-experimental), протокол для **вихідного** трафіку визначається автоматично.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи підтримує Istio трейсинг запитів для повідомлень на event bus у vert.x?
|
||||
weight: 80
|
||||
---
|
||||
|
||||
Зараз Istio не підтримує протоколи pub/sub та event bus. Будь-яке використання цих технологій є використанням навмання і може призвести до збоїв в будь-який момент.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Як я можу долучитися?
|
||||
weight: 70
|
||||
---
|
||||
|
||||
Ваша участь вітається. Ми з нетерпінням чекаємо відгуків, доповнень і повідомлень про помилки від спільноти.
|
||||
|
||||
Репозиторії коду розміщені на [GitHub](https://github.com/istio). Будь ласка, ознайомтеся з нашими [правилами участі](https://github.com/istio/community/blob/master/CONTRIBUTING.md), щоб дізнатися, як долучитися.
|
||||
|
||||
Окрім коду, існують [інші способи долучитися до спільноти Istio](/get-involved/), зокрема на нашому [форумі](https://discuss.istio.io), [Slack](https://slack.istio.io) та [Stack Overflow](https://stackoverflow.com/questions/tagged/istio).
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: Як почати використовувати Istio?
|
||||
weight: 30
|
||||
---
|
||||
|
||||
Рекомендуємо слідувати інструкціям на [сторінці початку роботи](/docs/setup/getting-started/), яка встановлює демонстраційну конфігурацію разом з зразком застосунку Istio, [Bookinfo](/docs/examples/bookinfo/). Ви можете використовувати цю установку для [перегляду різних посібників Istio](/docs/setup/getting-started/#next-steps), які демонструють розумну маршрутизацію, примусове дотримання політик, безпеку, телеметрію тощо, у формі навчального посібника.
|
||||
|
||||
Щоб почати використовувати Istio з промисловими розгортаннями Kubernetes, будь ласка, ознайомтеся з нашими [моделями розгортання](/docs/ops/deployment/deployment-models/) і сторінкою FAQ [який метод установки Istio слід використовувати?](/about/faq/#install-method-selection).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Як я можу приєднатися до простору Istio в Slack?
|
||||
weight: 180
|
||||
---
|
||||
|
||||
Якщо ви хочете мати можливість спілкуватися з членами нашої спільноти в реальному часі, ви можете приєднатися до нашого простору Istio в [Slack](https://slack.istio.io).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Як було започатковано Istio?
|
||||
weight: 50
|
||||
---
|
||||
|
||||
Проєкт Istio був розпочатий командами Google та IBM у партнерстві з командою Envoy від Lyft. Розробка ведеться повністю відкрито на GitHub.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Загальні питання
|
||||
linktitle: Загальні
|
||||
description: Загальні питання та відповіді.
|
||||
weight: 10
|
||||
layout: faq
|
||||
aliases:
|
||||
- /uk/help/faq/general
|
||||
---
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Istio не працює — що робити?
|
||||
weight: 90
|
||||
---
|
||||
|
||||
Ознайомтеся з [довідником з операційної діяльності](/docs/ops/) для пошуку рішень та нашою [сторінкою для повідомлення про помилки](/docs/releases/bugs/) для подання помилок.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Який план розвитку Istio?
|
||||
weight: 140
|
||||
---
|
||||
|
||||
Перегляньте нашу [сторінку з етапами випуску функцій](/docs/releases/feature-stages/) та [новини](/news) для отримання останніх новин.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Які середовища розгортання підтримуються?
|
||||
weight: 60
|
||||
---
|
||||
|
||||
Istio розроблений як платформонезалежний інструмент, спочатку зосереджений на Kubernetes. Для нашого релізу {{< istio_version >}} Istio підтримує середовища, що працюють на Kubernetes ({{< supported_kubernetes_versions >}}).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Що означає слово «Istio»?
|
||||
weight: 160
|
||||
---
|
||||
|
||||
Це грецьке слово ιστίο, яке означає «вітрило».
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
title: Що таке Istio?
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Istio — це незалежна від платформи відкрита сервісна мережа, яка забезпечує управління трафіком, виконання політик і збір телеметрії.
|
||||
|
||||
*Відкрита*: Istio розробляється та підтримується як програмне забезпечення з відкритим вихідним кодом. Ми заохочуємо участь та відгуки від спільноти в цілому.
|
||||
|
||||
*Незалежна від платформи*: Проєкт Istio не орієнтований на будь-яке конкретне середовище розгортання. На початкових етапах розробки Istio підтримуватиме розгортання на основі Kubernetes. Однак, Istio створюється для того, щоб забезпечити швидку та легку адаптацію до інших середовищ.
|
||||
|
||||
*Сервісна мережа*: Istio призначений для управління комунікацією між мікросервісами та застосунками. Без потреби вносити зміни до основних сервісів, Istio забезпечує автоматичну базову стійкість до збоїв трафіку, збір метрик сервісів, розподілене трасування, шифрування трафіку, оновлення протоколів і розширену функціональність маршрутизації для всіх комунікацій між сервісами.
|
||||
|
||||
Для більш детальної інформації, будь ласка, дивіться [Сервісна мережа Istio](/about/service-mesh/)
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Яка ліцензія?
|
||||
weight: 40
|
||||
---
|
||||
|
||||
Istio використовує [ліцензію Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0.html).
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: Де знаходиться документація?
|
||||
weight: 80
|
||||
---
|
||||
|
||||
Ознайомтеся з [документацією](/docs/) прямо тут на istio.io. Документація включає [огляди концепцій](/docs/concepts/), [інструкції по завданням](/docs/tasks/), [приклади](/docs/examples/), та [повну довідкову документацію](/docs/reference/).
|
||||
|
||||
Докладна документація для розробників зберігається у нашій [Wiki](https://github.com/istio/istio/wiki) на GitHub.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Чому мені варто використовувати Istio?
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Традиційно більшість логіки, яку обробляє Istio, була інтегрована безпосередньо в застосунки. Управління оновленнями цієї логіки звʼязку може бути дуже складним завданням для цілої низки сервісів. Istio надає рішення на рівні інфраструктури для управління комунікаціями між сервісами.
|
||||
|
||||
*Розробники застосунків*: Завдяки тому, що Istio керує потоками трафіку через їхні сервіси, розробники можуть зосередитися виключно на бізнес-логіці та швидко впроваджувати нові функції.
|
||||
|
||||
*Оператори сервісів*: Istio дозволяє впроваджувати політики та здійснювати моніторинг мережі з єдиної централізованої точки управління, незалежно від еволюції застосунків. В результаті оператори можуть забезпечити безперервне дотримання політик за допомогою спрощеної системи управління.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи можна отримати метрики Istio через REST?
|
||||
weight: 0
|
||||
---
|
||||
|
||||
Ви можете збирати дані телеметрії Istio, використовуючи [Prometheus](/docs/tasks/observability/metrics/querying-metrics/). А потім використовувати [HTTP API Prometheus](https://prometheus.io/docs/prometheus/latest/querying/api/) для запитів до цих даних.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Метрики та логи, ЧаПи
|
||||
linktitle: Метрики та логи
|
||||
description: Метрики та логи, часті питання.
|
||||
weight: 45
|
||||
layout: faq
|
||||
aliases:
|
||||
- /uk/help/faq/telemetry
|
||||
- /uk/help/faq/metrics-and-logs
|
||||
---
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
title: Як дізнатися, що сталося з запитом в Istio?
|
||||
weight: 80
|
||||
---
|
||||
|
||||
Ви можете включити [трейсинг](/docs/tasks/observability/distributed-tracing/), щоб визначити маршрут запиту в Istio.
|
||||
|
||||
Додатково, ви можете використовувати такі команди, щоб дізнатися більше про стан мережі:
|
||||
|
||||
* [`istioctl proxy-config`](/docs/reference/commands/istioctl/#istioctl-proxy-config): Отримати інформацію про конфігурацію проксі, коли ви працюєте в Kubernetes:
|
||||
|
||||
{{< text plain >}}
|
||||
# Отримати інформацію про конфігурацію bootstrap для екземпляра Envoy у вказаному podʼі.
|
||||
$ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
|
||||
|
||||
# Отримати інформацію про конфігурацію кластера для екземпляра Envoy у вказаному podʼі.
|
||||
$ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
|
||||
|
||||
# Отримати інформацію про конфігурацію прослуховувача для екземпляра Envoy у вказаному podʼі.
|
||||
$ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
|
||||
|
||||
# Отримати інформацію про конфігурацію маршрутизації для екземпляра Envoy у вказаному podʼі.
|
||||
$ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
|
||||
|
||||
# Отримати інформацію про конфігурацію точок доступу для екземпляра Envoy у вказаному podʼі.
|
||||
$ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
|
||||
|
||||
# Спробуйте наступне, щоб дізнатися більше про команди proxy-config
|
||||
$ istioctl proxy-config --help
|
||||
{{< /text >}}
|
||||
|
||||
* `kubectl get`: Отримує інформацію про різні ресурси в мережі разом з конфігурацією маршрутизації:
|
||||
|
||||
{{< text plain >}}
|
||||
# Показати всі віртуальні сервіси
|
||||
$ kubectl get virtualservices
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Як управляти метриками з коротким терміном життя?
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Метрики з коротким терміном життя можуть впливати на продуктивність Prometheus, оскільки вони часто є великою джерелом кардинальності міток. Кардинальність — це міра кількості унікальних значень для міток. Щоб управляти впливом ваших метрик з коротким терміном життя в Prometheus, спочатку потрібно визначити метрики та мітки з високою кардинальністю. Prometheus надає інформацію про кардинальність на своїй сторінці `/status`. Додаткову інформацію можна отримати [через PromQL](https://www.robustperception.io/which-are-my-biggest-metrics). Є кілька способів зменшити кардинальність метрик Istio:
|
||||
|
||||
* Вимкніть резервне використання заголовка хосту. Мітка `destination_service` є одним з потенційних джерел високої кардинальності. Значення для `destination_service` стандартно використовують заголовок хосту, якщо проксі Istio не може визначити службу призначення з інших метаданих запиту. Якщо клієнти використовують різні заголовки хостів, це може призвести до великої кількості значень для `destination_service`. В цьому випадку слідуйте [керівництву з налаштування метрик](/docs/tasks/observability/metrics/customize-metrics/), щоб вимкнути резервне використання заголовка хосту на рівні мережі. Щоб вимкнути резервне використання заголовка хосту для конкретного робочого навантаження або простору імен, потрібно скопіювати конфігурацію `EnvoyFilter` статистики, оновити її, щоб вимкнути резервне використання заголовка хосту, і застосувати її з більш специфічним селектором. [Цей тікет](https://github.com/istio/istio/issues/25963#issuecomment-666037411) має більше деталей про те, як цього досягти.
|
||||
* Викиньте непотрібні мітки зі збору. Якщо мітка з високою кардинальністю не потрібна, ви можете викинути її зі збору метрик через [налаштування метрик](/docs/tasks/observability/metrics/customize-metrics/) за допомогою `tags_to_remove`.
|
||||
* Нормалізуйте значення міток, через федерацію або класифікацію. Якщо інформація, надана міткою, потрібна, ви можете використовувати [федерацію Prometheus](/docs/ops/best-practices/observability/#using-prometheus-for-production-scale-monitoring) або [класифікацію запитів](/docs/tasks/observability/metrics/classify-metrics/) для нормалізації мітки.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
title: Як мігрувати існуючу функціональність Mixer?
|
||||
weight: 30
|
||||
---
|
||||
|
||||
Mixer був [видалений у випуску Istio 1.8](/news/releases/1.8.x/announcing-1.8/#deprecations). Міграція необхідна, якщо ви все ще покладаєтеся на вбудовані адаптери Mixer або будь-які зовнішні адаптери для розширення мережі.
|
||||
|
||||
Для вбудованих адаптерів надано кілька альтернатив:
|
||||
|
||||
* Інтеграції `Prometheus` і `Stackdriver` реалізовані як [розширення проксі](/docs/reference/config/proxy_extensions/). Налаштування телеметрії, створеної цими двома розширеннями, може бути досягнута через [класифікацію запитів](/docs/tasks/observability/metrics/classify-metrics/) та [налаштування метрик Prometheus](/docs/tasks/observability/metrics/customize-metrics/).
|
||||
* Функціональність глобального та локального обмеження швидкості (`memquota` і `redisquota` адаптери) надається через [розвʼязання на основі Envoy для обмеження швидкості](/docs/tasks/policy-enforcement/rate-limit/).
|
||||
* Адаптер `OPA` замінений на [розвʼязання на основі Envoy ext-authz](/docs/tasks/security/authorization/authz-custom/), яке підтримує [інтеграцію з агентом політики OPA](https://www.openpolicyagent.org/docs/latest/envoy-introduction/).
|
||||
|
||||
Для власних зовнішніх адаптерів рекомендується міграція до розширень на основі Wasm. Будь ласка, ознайомтеся з посібниками по [розробці модуля Wasm](https://github.com/istio-ecosystem/wasm-extensions/blob/master/doc/write-a-wasm-extension-with-cpp.md) та [розповсюдженню розширень](/docs/tasks/extensibility/wasm-module-distribution/). Як тимчасове рішення, ви можете [увімкнути підтримку Envoy ext-authz та gRPC доступу до API логів у Mixer](https://github.com/istio/istio/wiki/Enabling-Envoy-Authorization-Service-and-gRPC-Access-Log-Service-With-Mixer), що дозволяє вам оновити Istio до версій після 1.7, одночасно використовуючи 1.7 Mixer з зовнішніми адаптерами. Це дасть вам більше часу для міграції на розширення на основі Wasm. Зверніть увагу, що це тимчасове рішення не протестовано в бойових умовах і навряд чи отримає виправлення помилок, оскільки воно доступне тільки у гілці Istio 1.7, яка вийшла з терміну підтримки після лютого 2021 року.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: Чи можу я використовувати Prometheus для збору метрик застосунків з Istio?
|
||||
weight: 90
|
||||
---
|
||||
|
||||
Так. [Prometheus](https://prometheus.io/) — це система моніторингу з відкритим кодом та база даних часових рядів. Ви можете використовувати Prometheus з Istio для запису метрик, які відстежують справність Istio та застосунків у сервісній мережі. Ви можете візуалізувати метрики за допомогою інструментів, таких як [Grafana](/docs/ops/integrations/grafana/) та [Kiali](/docs/tasks/observability/kiali/). Перегляньте [Конфігурацію для Prometheus](/docs/ops/integrations/prometheus/#Configuration), щоб зрозуміти, як увімкнути збір метрик.
|
||||
|
||||
Кілька приміток:
|
||||
|
||||
- Якщо pod Prometheus запустився до того, як pod istiod встиг створити необхідні сертифікати та надіслати їх до Prometheus, pod Prometheus потрібно перезапустити, щоб зібрати дані з цілей, захищених взаємним TLS.
|
||||
- Якщо ваш застосунок надає метрики Prometheus на окремому порту, цей порт слід додати до специфікацій сервісу та розгортання.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи можна використовувати адаптер Prometheus у середовищах, що не є Kubernetes?
|
||||
weight: 60
|
||||
---
|
||||
|
||||
Ви можете використовувати docker-compose для встановлення Prometheus.
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Які відмінності в телеметрії між телеметрією у проксі (відомою як v2) та телеметрією на основі Mixer (відомою як v1)?
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Телеметрія у проксі (відомою як v2) знижує використання ресурсів і покращує продуктивність проксі в порівнянні з телеметрією на основі Mixer (відомою як v1) і є переважним механізмом для телеметрії в Istio. Однак є кілька відмінностей у телеметрії між v1 і v2, які наведені нижче:
|
||||
|
||||
* **Відсутні мітки для трафіку поза мережею**
|
||||
Телеметрія у проксі покладається на обмін метаданими між проксі Envoy для збору інформації, такої як імʼя робочого навантаження, простір імен і мітки. У телеметрії на основі Mixer ця функціональність виконувалася Mixer як частина комбінування атрибутів запитів з даними платформи. Цей обмін метаданими виконується проксі Envoy, додаючи конкретний HTTP заголовок для протоколу HTTP або доповнюючи протокол ALPN для протоколу TCP, як описано [тут](/docs/tasks/observability/metrics/tcp-metrics/#understanding-tcp-telemetry-collection). Такий підхід вимагає, щоб проксі Envoy були впроваджені як у клієнтських, так і в серверних робочих навантаженнях, що передбачає, що телеметрія, що збирається, коли один з партнерів не знаходиться в мережі, буде без атрибутів партнера, таких як імʼя робочого навантаження, простір імен і мітки. Однак, якщо обидва партнери мають впроваджені проксі, всі мітки, згадані [тут](/docs/reference/config/metrics/), доступні в згенерованих метриках. Коли серверне робоче навантаження знаходиться поза мережею, метадані робочого навантаження сервера все ще передаються клієнтському sidecar, що призводить до того, що клієнтські метрики мають заповнені мітки метаданих робочого навантаження сервера.
|
||||
|
||||
* **Обмін метаданими TCP вимагає mTLS**
|
||||
Обмін метаданими TCP покладається на [протокол ALPN Istio](/docs/tasks/observability/metrics/tcp-metrics/#understanding-tcp-telemetry-collection), який вимагає, щоб mutual TLS (mTLS) був увімкнений для успішного обміну метаданими між проксі Envoy. Це означає, що якщо mTLS не увімкнено у вашому кластері, телеметрія для протоколу TCP не включатиме інформацію про партнера, таку як імʼя робочого навантаження, простір імен і мітки.
|
||||
|
||||
* **Відсутність механізму для конфігурації власних кошиків для гістограмних метрик**
|
||||
Телеметрія на основі Mixer підтримувала налаштування кошиків для метрик типу гістограми, таких як тривалість запиту та розміри байтів TCP. Телеметрія у проксі не має такого механізму. Крім того, кошики для метрик затримки в телеметрії у проксі вимірюються в мілісекундах, в порівнянні з секундами в телеметрії на основі Mixer. Однак, в телеметрії у проксі доступно стандартно більше кошиків для метрик затримки на нижчих рівнях затримки.
|
||||
|
||||
* **Відсутність термінації метрик для метрик з коротким часом існування**
|
||||
Телеметрія на основі Mixer підтримувала термінацію метрик, за якої метрики, що не були згенеровані протягом встановленого часу, були видалені з колекції Prometheus. Це корисно в сценаріях, таких як одноразові завдання, які генерують метрики з коротким часом існування. Видалення метрик запобігає звітуванню про метрики, які більше не змінюватимуться в майбутньому, тим самим зменшуючи мережевий трафік і зберігання в Prometheus. Цей механізм термінації не доступний у телеметрії у проксі. Робоче рішення для цього можна знайти [тут](/about/faq/#metric-expiry).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи можна ввімкнути взаємний TLS для деяких сервісів, залишивши його вимкненим для інших сервісів в одному кластері?
|
||||
weight: 20
|
||||
---
|
||||
|
||||
[Політика автентифікації](/docs/concepts/security/#authentication-policies) може діяти на рівні всієї мережі (що впливає на всі сервіси в мережі), на рівні простору імен (усі сервіси в тому ж просторі імен) або бути специфічною для конкретного сервісу. Ви можете мати політику або політики для налаштування взаємного TLS для сервісів у кластері будь-яким чином, як вам зручно.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи не включає автоматичний взаємний TLS порти, встановлені за допомогою анотації "excludeInboundPorts"?
|
||||
weight: 80
|
||||
---
|
||||
|
||||
Ні. Коли на серверних робочих навантаженнях використовується `traffic.sidecar.istio.io/excludeInboundPorts`, Istio все одно налаштовує клієнтський Envoy для стандартного надсилання взаємного TLS. Щоб змінити це, потрібно налаштувати правило Destination Rule з режимом взаємного TLS, встановленим на `DISABLE`, щоб клієнти надсилали звичайний текст на ці порти.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
title: Як налаштувати тривалість дії сертифікатів Istio?
|
||||
weight: 70
|
||||
---
|
||||
|
||||
Для робочих навантажень, що виконуються в Kubernetes, термін дії їх сертифікатів Istio стандартно становить 24 години.
|
||||
|
||||
Цю конфігурацію можна змінити, налаштувавши поле `proxyMetadata` у [конфігурації проксі](/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig). Наприклад:
|
||||
|
||||
{{< text yaml >}}
|
||||
proxyMetadata:
|
||||
SECRET_TTL: 48h
|
||||
{{< /text >}}
|
||||
|
||||
{{< tip >}}
|
||||
Значення більше 90 днів не приймаються.
|
||||
{{< /tip >}}
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи підтримує Istio авторизацію?
|
||||
weight: 110
|
||||
---
|
||||
|
||||
Так. Istio надає можливості авторизації як для HTTP, так і для простих TCP сервісів у mesh. [Дізнатися більше](/docs/concepts/security/#authorization).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Як можна ввімкнути/вимкнути взаємний TLS після встановлення Istio?
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Ви можете змінити налаштування взаємного TLS для ваших сервісів у будь-який час, використовуючи [політику автентифікації](/docs/concepts/security/#authentication-policies) та [правило призначення](/docs/concepts/traffic-management/#destination-rules). Детальніше дивіться в [завданні](/docs/tasks/security/authentication/authn-policy).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи можу я встановити Istio sidecar для HTTPS сервісів?
|
||||
weight: 170
|
||||
---
|
||||
|
||||
Так, можна. Це працює як з увімкненим, так і з вимкненим взаємним TLS.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Безпека, ЧаПи
|
||||
linktitle: Безпека
|
||||
description: Безпека, часті питання.
|
||||
weight: 31
|
||||
layout: faq
|
||||
aliases:
|
||||
- /uk/help/faq/security
|
||||
---
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
title: Як я можу використовувати перевірки працездатності Kubernetes (liveness і readiness) для podʼів, коли взаємний TLS увімкнено?
|
||||
weight: 50
|
||||
---
|
||||
|
||||
Якщо взаємний TLS увімкнено, перевірки працездатності HTTP та TCP від kubelet не працюватимуть без змін, оскільки kubelet не має сертифікатів, виданих Istio.
|
||||
|
||||
Є кілька варіантів:
|
||||
|
||||
1. Використання перезапису перевірок для перенаправлення запитів liveness і readiness безпосередньо до сервісу. Дивіться більше інформації в розділі [Перезапис перевірок](/docs/ops/configuration/mesh/app-health-check/#probe-rewrite). Ця опція стандартно увімкнена і рекомендована.
|
||||
|
||||
2. Використання окремого порту для перевірок працездатності та ввімкнення взаємного TLS лише на звичайному сервісному порті. Докладніше читайте в розділі [Перевірка працездатності сервісів Istio](/docs/ops/configuration/mesh/app-health-check/#separate-port).
|
||||
|
||||
3. Використання режиму [`PERMISSIVE`](/docs/tasks/security/authentication/mtls-migration) для сервісу, щоб він міг приймати як відкритий, так і взаємний TLS трафік. Зверніть увагу, що взаємний TLS не буде примусовим при використанні цієї опції.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Усунення проблем з підключенням до MySQL
|
||||
description: Усунення проблем з підключенням до MySQL через режим PERMISSIVE.
|
||||
weight: 95
|
||||
keywords: [mysql,mtls]
|
||||
---
|
||||
|
||||
Ви можете зіткнутися з тим, що MySQL не може підключитися після встановлення Istio. Це відбувається через те, що MySQL використовує протокол [server first](/docs/ops/deployment/application-requirements/#server-first-protocols), який може заважати виявленню протоколу Istio. Зокрема, використання режиму `PERMISSIVE` для mTLS може спричиняти проблеми. Ви можете побачити повідомлення про помилки, такі як `ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0`.
|
||||
|
||||
Цю проблему можна вирішити, увімкнувши режим `STRICT` або `DISABLE`, або ж налаштувавши всіх клієнтів на надсилання mTLS. Дивіться більше інформації в розділі [server first protocols](/docs/ops/deployment/application-requirements/#server-first-protocols).
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Якщо глобально увімкнено взаємний TLS, чи можуть не-Istio сервіси доступатися до Istio сервісів?
|
||||
weight: 30
|
||||
---
|
||||
Коли включено `STRICT` режим взаємного TLS, не-Istio робочі навантаження не можуть взаємодіяти з Istio сервісами, оскільки у них не буде відповідного сертифікату клієнта Istio.
|
||||
|
||||
Якщо вам потрібно дозволити таким клієнтам доступ, режим взаємного TLS можна налаштувати на `PERMISSIVE`, що дозволить як незашифровану, так і зашифровану передачу даних. Це можна зробити для окремих робочих навантажень або для всієї мережі.
|
||||
|
||||
Дивіться [Правила автентифікації](/docs/tasks/security/authentication/authn-policy) для отримання додаткової інформації.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Як налаштувати Istio Ingress для приймання лише TLS трафіку?
|
||||
weight: 130
|
||||
---
|
||||
|
||||
Дотримуючися інструкцій в завданні [Захищений трафік Ingress](/docs/tasks/traffic-management/ingress/secure-ingress), можна забезпечити безпеку Istio Ingress так, щоб він приймав лише TLS трафік.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Як я можу перевірити, що трафік використовує взаємне шифрування TLS?
|
||||
weight: 25
|
||||
---
|
||||
|
||||
Якщо ви встановили Istio з `values.global.proxy.privileged=true`, ви можете використовувати `tcpdump`, щоб визначити статус шифрування. Також, з Kubernetes 1.23 і пізніших версій, як альтернатива встановленню Istio як привілейованого сервісу, ви можете використовувати `kubectl debug` для запуску `tcpdump` в [тимчасовому контейнері](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container). Дивіться [міграцію на взаємний TLS в Istio](/docs/tasks/security/authentication/mtls-migration) для інструкцій.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Встановлення, ЧаПи
|
||||
linktitle: Встановлення
|
||||
description: Встановлення, питання та відповіді.
|
||||
weight: 20
|
||||
layout: faq
|
||||
aliases:
|
||||
- /uk/help/faq/setup
|
||||
---
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
title: Який метод установки Istio мені слід використовувати?
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Окрім простої [початкової установки](/docs/setup/getting-started) для оцінки, існує декілька різних методів установки Istio. Який з них слід використовувати, залежить від ваших вимог до продуктивного середовища. Нижче наведені деякі плюси та мінуси кожного з доступних методів:
|
||||
|
||||
1. [Установка за допомогою istioctl](/docs/setup/install/istioctl/)
|
||||
|
||||
Найпростіший і найбільш надійний метод установки та керування з високим рівнем безпеки. Це рекомендований метод для більшості сценаріїв використання спільнотою.
|
||||
|
||||
Переваги:
|
||||
|
||||
- Повна перевірка конфігурації та верифікація стану.
|
||||
- Використовує API `IstioOperator`, який надає широкі можливості конфігурації/кастомізації.
|
||||
- Не потрібні привілейовані podʼи в кластері. Зміни виконуються шляхом запуску команди `istioctl`.
|
||||
|
||||
Недоліки:
|
||||
|
||||
- Необхідно керувати кількома бінарними файлами, по одному для кожної мінорної версії Istio.
|
||||
- Команда `istioctl` може встановлювати значення, як-от `JWT_POLICY`, на основі вашого робочого середовища, що може призводити до різних установок в різних Kubernetes-середовищах.
|
||||
|
||||
1. [Генерація маніфесту за допомогою istioctl](/docs/setup/install/istioctl/#generate-a-manifest-before-installation)
|
||||
|
||||
Генерація Kubernetes-маніфесту, а потім застосування команди `kubectl apply --prune`. Цей метод підходить у випадках, коли потрібен суворий аудит або доопрацювання отриманих маніфестів.
|
||||
|
||||
Переваги:
|
||||
|
||||
- Ресурси генеруються з того ж API `IstioOperator`, що й у `istioctl install` і Operator.
|
||||
- Використовує API `IstioOperator`, який надає широкі можливості конфігурації/кастомізації.
|
||||
|
||||
Недоліки:
|
||||
|
||||
- Деякі перевірки, які виконуються в `istioctl install` і Operator, не виконуються.
|
||||
- Цей тип використання з погляду користувача менш оптимізований у порівнянні з `istioctl install`.
|
||||
- Повідомлення про помилки менш інформативні, ніж у `istioctl install` на етапі застосування.
|
||||
|
||||
1. [Установка за допомогою Helm](/docs/setup/install/helm/)
|
||||
|
||||
Використання Helm-чартів дозволяє легко інтегруватися з робочими процесами на основі Helm і автоматично видаляти ресурси під час оновлень.
|
||||
|
||||
Переваги:
|
||||
|
||||
- Знайомий підхід з використанням стандартних інструментів індустрії.
|
||||
- Вбудоване управління релізами та оновленнями Helm.
|
||||
|
||||
Недоліки:
|
||||
|
||||
- Менше перевірок і валідацій порівняно з `istioctl install` і Operator.
|
||||
- Деякі адміністративні завдання потребують більше кроків та мають вищу складність.
|
||||
|
||||
1. [Istio Operator](/docs/setup/install/operator/)
|
||||
|
||||
{{< warning >}}
|
||||
Використання оператора не рекомендується для нових установок. Хоча підтримка оператора триватиме, нові запити на функції не будуть мати високого пріоритету.
|
||||
{{< /warning >}}
|
||||
|
||||
Istio operator забезпечує шлях установки без необхідності використовувати бінарний файл `istioctl`. Його можна використовувати для спрощених робочих процесів оновлення, якщо робота привілейованого контролера в кластері не є проблемою. Цей метод підходить, коли не потрібен суворий аудит або доопрацювання отриманих маніфестів.
|
||||
|
||||
Переваги:
|
||||
|
||||
- Такий самий API, як у `istioctl install`, але реалізація відбувається через контролер у кластері з повністю декларативною операцією.
|
||||
- Використовує API `IstioOperator`, який надає широкі можливості конфігурації/кастомізації.
|
||||
- Не потрібно керувати кількома бінарними файлами `istioctl`.
|
||||
|
||||
Недоліки:
|
||||
|
||||
- Робота привілейованого контролера в кластері має певні ризики з погляду безпеки.
|
||||
|
||||
Інструкції з установки для всіх цих методів доступні на [сторінці установки Istio](/docs/setup/install).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Kubernetes — як можна відстежити проблеми з автоматичними інʼєкціями sidecar?
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Переконайтеся, що ваш кластер відповідає [вимогам](/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection) для автоматичної інʼєкції sidecar. Якщо ваш мікросервіс розгорнутий у просторах імен `kube-system`, `kube-public` або `istio-system`, вони виключені з автоматичної інʼєкції sidecar. Будь ласка, використовуйте інший простір імен.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: На яких портах sidecar проксі захоплює вхідний трафік?
|
||||
weight: 20
|
||||
---
|
||||
|
||||
Стандартно Istio захоплює вхідний трафік на всіх портах. Ви можете змінити цю поведінку, використовуючи анотацію `traffic.sidecar.istio.io/includeInboundPorts` у podʼі, щоб вказати явний список портів для захоплення, або використовуючи `traffic.sidecar.istio.io/excludeOutboundPorts` для вказівки списку портів, які потрібно пропустити.
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
title: Чому моя конфігурація CORS не працює?
|
||||
weight: 40
|
||||
---
|
||||
|
||||
Після застосування [конфігурації CORS](/docs/reference/config/networking/virtual-service/#CorsPolicy) ви можете помітити, що ніби нічого не змінилося, і запитати, що пішло не так. CORS є часто неправильно зрозумілим HTTP-концептом, що часто призводить до плутанини при конфігурації.
|
||||
|
||||
Щоб зрозуміти це, корисно зробити крок назад і подивитися на [що таке CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) і коли його слід використовувати. Стандартно оглядачі мають обмеження на "кросдоменні" запити, ініційовані скриптами. Це заважає, наприклад, вебсайту `attack.example.com` здійснити JavaScript-запит до `bank.example.com` і вкрасти чутливу інформацію користувача.
|
||||
|
||||
Щоб дозволити цей запит, `bank.example.com` має дозволити `attack.example.com` здійснювати кросдоменні запити. Ось де і зʼявляється CORS. Якби ми обслуговували `bank.example.com` у кластері з увімкненим Istio, ми могли б налаштувати `corsPolicy`, щоб дозволити це:
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bank
|
||||
spec:
|
||||
hosts:
|
||||
- bank.example.com
|
||||
http:
|
||||
- corsPolicy:
|
||||
allowOrigins:
|
||||
- exact: https://attack.example.com
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
У цьому випадку ми явно дозволяємо один орієнтир; маски часто використовуються для не чутливих сторінок.
|
||||
|
||||
Після цього поширена помилка — це надсилання запиту, наприклад `curl bank.example.com -H "Origin: https://attack.example.com"`, і очікування, що запит буде відхилено. Однак curl і багато інших клієнтів не побачать відхилення запиту, оскільки CORS є обмеженням оглядача. Конфігурація CORS просто додає заголовки `Access-Control-*` у відповідь; клієнт (оглядач) вирішує відхилити запит, якщо відповідь не є задовільною. В оглядачах це робиться за допомогою [Preflight запиту](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Яка різниця між режимами TLS MUTUAL та ISTIO_MUTUAL?
|
||||
weight: 30
|
||||
---
|
||||
|
||||
Обидва ці налаштування `DestinationRule` дозволяють передавати трафік з взаємним TLS. За допомогою `ISTIO_MUTUAL` сертифікати Istio будуть використовуватися автоматично. Для `MUTUAL` потрібно налаштувати ключ, сертифікат і довірений CA. Це дозволяє ініціювати взаємний TLS з застосунками, які не є частиною Istio.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Керування трафіком, ЧаПи
|
||||
linktitle: Керування трафіком
|
||||
description: Керування трафіком, часті питання.
|
||||
weight: 50
|
||||
layout: faq
|
||||
aliases:
|
||||
- /uk/help/faq/traffic-management
|
||||
---
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
title: Чи можу я використовувати стандартну специфікацію Ingress без будь-яких правил маршрутизації?
|
||||
weight: 40
|
||||
---
|
||||
|
||||
Прості специфікації ingress, що включають хост, TLS і точні відповідності шляхів, будуть працювати без потреби в правилах маршрутизації. Однак зверніть увагу, що шлях, використаний у ресурсі ingress, не повинен містити символи `.`.
|
||||
|
||||
Наприклад, наступний ресурс ingress відповідає запитам для хосту example.com з URL /helloworld.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create -f - <<EOF
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: simple-ingress
|
||||
annotations:
|
||||
kubernetes.io/ingress.class: istio
|
||||
spec:
|
||||
rules:
|
||||
- host: example.com
|
||||
http:
|
||||
paths:
|
||||
- path: /helloworld
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: myservice
|
||||
port:
|
||||
number: 8000
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
Однак наступні правила не працюватимуть, оскільки вони використовують регулярні вирази в шляху та анотації `ingress.kubernetes.io`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create -f - <<EOF
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
name: this-will-not-work
|
||||
annotations:
|
||||
kubernetes.io/ingress.class: istio
|
||||
# Анотації Ingress, інші, ніж клас Ingress, не будуть враховані
|
||||
ingress.kubernetes.io/rewrite-target: /
|
||||
spec:
|
||||
rules:
|
||||
- host: example.com
|
||||
http:
|
||||
paths:
|
||||
- path: /hello(.*?)world/
|
||||
pathType: Prefix
|
||||
backend:
|
||||
service:
|
||||
name: myservice
|
||||
port:
|
||||
number: 8000
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
title: Які протоколи підтримує Istio?
|
||||
weight: 50
|
||||
---
|
||||
|
||||
Наразі Istio підтримує протоколи на основі TCP. Крім того, Istio надає функціональність, таку як маршрутизація та метрики, для інших протоколів, таких як `http` та `mysql`.
|
||||
|
||||
Для перегляду списку всіх протоколів та інформації про налаштування протоколів перегляньте документацію з [Вибору протоколів](/docs/ops/configuration/traffic-management/protocol-selection/).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Чи можна використовувати Istio з StatefulSets та headless сервісами?
|
||||
weight: 35
|
||||
---
|
||||
|
||||
Так, Istio повністю підтримує ці типи завантажень починаючи з [Istio 1.10](/blog/2021/statefulsets-made-easier/).
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Як переглянути поточні правила маршрутизації, які я налаштував з Istio?
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Правила можна переглянути за допомогою команди `kubectl get virtualservice -o yaml`
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
---
|
||||
title: Сервісна мережа Istio
|
||||
description: Сервісна мережа.
|
||||
subtitle: Istio вирішує проблеми, з якими стикаються розробники та оператори при роботі з розподіленою або мікросервісною архітектурою. Чи будуєте ви з нуля, переносите існуючі застосунки в хмару або захищаєте наявне середовище, Istio стане в пригоді.
|
||||
weight: 34
|
||||
skip_toc: true
|
||||
skip_byline: true
|
||||
skip_pagenav: true
|
||||
aliases:
|
||||
- /uk/service-mesh.html
|
||||
- /uk/docs/concepts/what-is-istio/overview
|
||||
- /uk/docs/concepts/what-is-istio/goals
|
||||
- /uk/about/intro
|
||||
- /uk/docs/concepts/what-is-istio/
|
||||
- /uk/latest/docs/concepts/what-is-istio/
|
||||
doc_type: about
|
||||
---
|
||||
|
||||
{{< centered_block >}}
|
||||
{{< figure src="/img/service-mesh.svg" alt="Мережева структура" title="Завдяки використанню проксі-серверів застосунків Istio дозволяє програмувати управління трафіком, спостереження та безпеку на рівні застосунків у вашій мережі." >}}
|
||||
{{< /centered_block >}}
|
||||
|
||||
{{< centered_block >}}
|
||||
|
||||
[comment]: <> (Нижче наведений заголовок тільки через те, що lint вимагає, щоб перший заголовок був <h2>, а далі ми хочемо використовувати <h1>.)
|
||||
|
||||
## Що таке Istio? {#what-is-istio}
|
||||
|
||||
**Сервісна мережа (service mesh)** — це шар інфраструктури, який надає застосункам такі можливості, як безпека з нульовою довірою, спостережуваність і вдосконалене управління трафіком, без внесення змін в код. **Istio** — найпопулярніша, потужна та надійна сервісна мережа. Заснована Google, IBM та Lyft у 2016 році, Istio є дипломованим проєктом Cloud Native Computing Foundation поряд з такими проєктами, як Kubernetes та Prometheus.
|
||||
|
||||
Istio забезпечує стійкість хмарних та розподілених систем, допомагаючи сучасним підприємствам підтримувати свої навантаження на різних платформах, зберігаючи при цьому звʼязок і захист. Вона [дозволяє реалізувати контроль безпеки та управління](/docs/concepts/observability/), включаючи шифрування mTLS, управління політиками та контроль доступу, [підтримує мережеві функції](/docs/concepts/traffic-management/), такі як канаркові розгортання, A/B тестування, балансування навантаження, відновлення після збоїв, і [додає спостережуваність](/docs/concepts/observability/) трафіку у вашому середовищі.
|
||||
|
||||
Istio не обмежується межами одного кластера, мережі або середовища виконання — сервіси, що працюють на Kubernetes або віртуальних машинах, у мультихмарному, гібридному або локальному середовищі, можуть бути обʼєднані в одну мережу.
|
||||
|
||||
Розширювана за дизайном і підтримувана [широкою екосистемою](/about/ecosystem) учасників і партнерів, Istio пропонує готові інтеграції та дистрибутиви для різних сценаріїв використання. Ви можете встановити Istio самостійно або скористатися підтримкою комерційних постачальників, які надають рішення на основі Istio.
|
||||
|
||||
<div class="cta-container">
|
||||
<a class="btn" href="/uk/docs/overview/">Дізнатися більше про Istio</a>
|
||||
</div>
|
||||
|
||||
{{< /centered_block >}}
|
||||
|
||||
<br/><br/>
|
||||
|
||||
# Можливості {#features}
|
||||
|
||||
{{< feature_block header="Безпека по стандарту" image="security.svg" >}}
|
||||
Istio забезпечує провідне рішення для забезпечення безпеки з нульовою довірою, засноване на ідентифікації навантажень, взаємному TLS та жорсткому контролі політик. Istio реалізує цінності [BeyondProd](https://cloud.google.com/security/beyondprod/) у відкритому коді, уникаючи привʼязки до постачальників або єдиних точок відмови.
|
||||
|
||||
<a class="btn" href="/uk/docs/concepts/security/">Дізнатися про безпеку</a>
|
||||
{{< /feature_block>}}
|
||||
|
||||
{{< feature_block header="Покращення спостережуваності" image="observability.svg" >}}
|
||||
Istio генерує телеметрію всередині мережевої структури, забезпечуючи спостереження за поведінкою сервісів. Вона інтегрується з системами APM, такими як Grafana та Prometheus, для надання інформативних метрик, які дозволяють операторам усувати несправності, підтримувати та оптимізувати застосунки.
|
||||
|
||||
<a class="btn" href="/uk/docs/concepts/observability/">Дізнатися про спостережуваність</a>
|
||||
{{< /feature_block>}}
|
||||
|
||||
{{< feature_block header="Управління трафіком" image="management.svg" >}}
|
||||
Istio спрощує маршрутизацію трафіку та налаштування рівня обслуговування, дозволяючи легко контролювати потік між сервісами та налаштовувати такі завдання, як A/B тестування, канаркові розгортання та поетапні розгортання з розподілом трафіку на основі відсотків.
|
||||
|
||||
<a class="btn" href="/uk/docs/concepts/traffic-management/">Дізнатися про управління трафіком</a>
|
||||
{{< /feature_block>}}
|
||||
|
||||
<br/><br/>
|
||||
|
||||
# Чому Istio? {#why-istio}
|
||||
|
||||
{{< feature_block header="Кілька режимів розгортання" image="deployment-modes.svg" >}}
|
||||
Istio пропонує два режими роботи панелі даних, які можна вибрати. Розгортайте з новим режимом оточення (ambient mode) для спрощення життєвого циклу застосунків або з традиційними sidecar-контейнерами для складних конфігурацій.
|
||||
|
||||
<a class="btn" href="/uk/docs/overview/dataplane-modes/">Дізнатися про режими роботи панелі даних</a>
|
||||
{{< /feature_block>}}
|
||||
|
||||
{{< feature_block header="Працює на Envoy" image="envoy.svg" >}}
|
||||
Побудована на основі стандартного проксі-шлюзу для хмарних застосунків, Istio має високу продуктивність і розширюваність за дизайном. Додайте власні функції управління трафіком за допомогою WebAssembly або інтегруйте сторонні системи управління політиками.
|
||||
|
||||
<a class="btn" href="/uk/docs/overview/why-choose-istio/#envoy">Дізнатися про Istio та Envoy</a>
|
||||
{{< /feature_block>}}
|
||||
|
||||
{{< feature_block header="Справжній проєкт спільноти" image="community-project.svg" >}}
|
||||
Istio розроблена для сучасних навантажень і створена великою спільнотою новаторів у хмарному середовищі.
|
||||
|
||||
<a class="btn" href="/uk/docs/overview/why-choose-istio/#community">Дізнатися про учасників Istio</a>
|
||||
{{< /feature_block>}}
|
||||
|
||||
{{< feature_block header="Стабільні випуски бінарних файлів" image="stable-releases.svg" >}}
|
||||
Впевнено розгортайте Istio у виробничих робочих навантаженнях. Всі випуски повністю доступні безкоштовно.
|
||||
|
||||
<a class="btn" href="/uk/docs/overview/why-choose-istio/#packages">Дізнатися про пакети Istio</a>
|
||||
{{< /feature_block>}}
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: Рішення
|
||||
description: Рішення.
|
||||
subtitle: Дізнайтеся, як досягти успіху в ініціативах щодо безпеки, спостережуваності та управління трафіком, використовуючи Istio.
|
||||
aliases:
|
||||
- /uk/solutions
|
||||
doc_type: about
|
||||
type: solutions
|
||||
sidebar_none: true
|
||||
---
|
||||
[comment]: <> (TODO: Заміни заповнювачі)
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: "Забезпечення глибокого захисту для корпоративних застосунків"
|
||||
opening_paragraph: "З урахуванням міжсервісного та міжвузлового спілкування в мікросервісах, схеми безпеки повинні діяти з мисленням нульової довіри. Ключовою вразливістю є комунікація між сервісами. Шифрування всіх комунікацій за допомогою mTLS є важливим для безпеки та відповідності вимогам. Istio автоматизує mTLS всюди."
|
||||
image: "defense.svg"
|
||||
skip_toc: true
|
||||
doc_type: article
|
||||
sidebar_force: sidebar_solution
|
||||
type: solutions
|
||||
---
|
||||
|
||||
Ми активно працюємо над публікацією посібників з рішень, щоб допомогти вам зрозуміти, що ви можете зробити з Istio. А поки, будь ласка, ознайомтеся з нашою документацією з [безпеки](/docs/tasks/security/) та [застосування політик](/docs/tasks/policy-enforcement/).
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: "Підвищення ефективності розгортання та управління Kubernetes"
|
||||
opening_paragraph: "Мікросервіси, такі як Kubernetes, мають виклики, щодо управління та керування трафіком. Istio розроблена для швидкого та ефективного розгортання та управління. Дізнайтеся, як це досягається на прикладі реалізації Kubernetes."
|
||||
image: "increasing-efficiency.svg"
|
||||
skip_toc: true
|
||||
doc_type: article
|
||||
sidebar_force: sidebar_solution
|
||||
type: solutions
|
||||
---
|
||||
|
||||
Ми активно працюємо над публікацією посібників з рішень, щоб допомогти вам зрозуміти, що ви можете зробити з Istio. А поки, будь ласка, ознайомтеся з нашою документацією з [управління трафіком](/docs/tasks/traffic-management/).
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
title: "Запровадження спостережуваності та найкращих практик SRE"
|
||||
opening_paragraph: "Як інструмент для інженерії сервісів та надійності, Istio надає інформативні метрики на рівні сервісу та проксі, а також стандартні інформаційні панелі (дашбоарди). Налаштуйте їх для ключових завдань у вашій організації, таких як виявлення проблем та проєктування для високої надійності."
|
||||
image: "microservice-best-practices.svg"
|
||||
skip_toc: true
|
||||
doc_type: article
|
||||
sidebar_force: sidebar_solution
|
||||
type: solutions
|
||||
---
|
||||
|
||||
Ми активно працюємо над публікацією посібників з рішень, щоб допомогти вам зрозуміти, що ви можете зробити з Istio. А поки, будь ласка, ознайомтеся з нашою документацією зі [спостережуваності](/docs/tasks/observability/).
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
title: Навчання та Сертифікація
|
||||
description: Список постачальників професійного навчання та сертифікації Istio.
|
||||
subtitle: Різноманітність постачальників, які можуть допомогти вам з професійним навчанням та сертифікацією Istio.
|
||||
weight: 34
|
||||
skip_toc: true
|
||||
skip_byline: true
|
||||
skip_pagenav: true
|
||||
doc_type: about
|
||||
---
|
||||
|
||||
[comment]: <> (Щоб додати сертифікацію або навчання з Istio, будь ласка, зверніться до https://github.com/istio/community/blob/master/CONTRIBUTING.md#promote-your-company-on-istioio.)
|
||||
|
||||
{{< tabset category-name="ecosystem-type" class="tabset--ecosystem" forget-tab=true >}}
|
||||
|
||||
{{< tab
|
||||
name="Навчання"
|
||||
category-value="Навчання"
|
||||
description="Дізнайтеся, як Istio Service Mesh може покращити вашу платформу, з добре підготовленими, професійними курсами."
|
||||
>}}
|
||||
|
||||
{{< interactive_panels items="training" >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab
|
||||
name="Сертифікація"
|
||||
category-value="Сертифікація"
|
||||
description="Ось деякі відомі сертифікаційні іспити, доступні для підтвердження ваших навичок Istio."
|
||||
>}}
|
||||
|
||||
{{< interactive_panels items="certification" >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
{{< interactive_panel_modal >}}
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
---
|
||||
title: "Прощавай, sidecar: Ambient режим Istio досяг бета-версії в v1.22"
|
||||
description: Функції Layer 4 та Layer 7 тепер готові до промислового використання.
|
||||
publishdate: 2024-05-13
|
||||
attribution: "Lin Sun (Solo.io), для Комітетів з керівництва та технічного нагляду Istio"
|
||||
keywords: [ambient,sidecars]
|
||||
---
|
||||
|
||||
Сьогодні революційний новий режим Ambient {{< gloss "панель даних" >}}панелі даних{{< /gloss >}} в Istio досяг бета-версії. Ambient режим розроблений для спрощення операцій, розширення сумісності з застосунками та зменшення витрат на інфраструктуру. Він забезпечує панель даних без sidecar, інтегровану у вашу інфраструктуру, залишаючи основні функції Istio, такі як безпека нульового рівня довіри, телеметрія та управління трафіком.
|
||||
|
||||
Ambient режим [був оголошений у вересні 2022 року](/blog/2022/introducing-ambient-mesh/). З того часу наша спільнота впродовж 20 місяців важкої роботи та співпраці, з участю від Solo.io, Google, Microsoft, Intel, Aviatrix, Huawei, IBM, Red Hat та багатьох інших, зробила значний внесок. Статус бета-версії в 1.22 вказує на те, що функції ambient режиму тепер готові до промислового використання з відповідними запобіжними заходами. Це величезна подія для Istio, що забезпечує як функції рівня 4, так і рівня 7 для готовності до використання без sidecar контейнерів.
|
||||
|
||||
## Чому режим Ambient? {#why-ambient-mode}
|
||||
|
||||
Дослухаючись до відгуків користувачів Istio, ми спостерігали зростаючий попит на можливості мережі для застосунків — але почули, що багато з вас вважали витрати ресурсів та операційну складність sidecar важкими для подолання. Проблеми, якими користувачі sidecar ділилися з нами, включають те, як Istio може зламати застосунки після додавання sidecar контейнерів, велике споживання CPU та памʼяті sidecar контейнерами та незручність вимоги перезапуску застосунків з кожним новим випуском проксі.
|
||||
|
||||
Як спільнота, ми спроєктували режим ambient для усунення цих проблем, прибираючи попередні барʼєри складності, з якими стикалися користувачі, які намагалися впровадити сервісну мережу. Новий набір функцій був названий "ambient режим" (режим оточення) оскільки він був призначений бути прозорим для вашого застосунку, забезпечуючи відсутність необхідності додаткової конфігурації для його прийняття, і не вимагав перезапуску застосунків користувачами.
|
||||
|
||||
У режимі ambient додати чи видалити застосунки з мережі дуже просто. Тепер ви можете просто [позначити простір імен](/docs/ambient/usage/add-workloads/), і всі застосунки в цьому просторі імен будуть додані до мережі. Це негайно забезпечує весь трафік з mTLS, все без sidecar контейнерів чи потреби перезапуску застосунків.
|
||||
|
||||
Перегляньте [блог про представлення Ambient Mesh](/blog/2022/introducing-ambient-mesh/) для отримання додаткової інформації про те, чому ми створили режим ambient.
|
||||
|
||||
## Як режим Ambient полегшує адаптацію? {#how-does-ambient-mode-make-adoption-easier}
|
||||
|
||||
Режим ambient Istio вводить легкі, спільні проксі рівня 4 (L4) та необовʼязкові проксі рівня 7 (L7), усуваючи необхідність традиційних sidecar проксі з панелі даних. Основна інновація за режимом ambient полягає в тому, що він розділяє обробку L4 і L7 на два окремі шари. Такий шаровий підхід дозволяє вам поступово впроваджувати Istio, забезпечуючи плавний перехід від відсутності мережі до безпечного накладення (L4), до необовʼязкової повної обробки L7, в основі простору імен, за необхідності, по всьому вашому флоту.
|
||||
|
||||
Режим ambient працює без будь-яких модифікацій ваших поточних розгортань Kubernetes. Ви можете позначити простір імен, щоб додати всі його навантаження до мережі або вибрати певні розгортання за потреби. Використовуючи режим ambient, користувачі оминають деякі з попередніх обмежувальних елементів моделі sidecar контейнерів. Протоколи "server-send-first" тепер працюють, більшість зарезервованих портів тепер доступні, і можливість для контейнерів оминати sidecar контейнер, або зловмисно, або ні, — усунена.
|
||||
|
||||
Легкий спільний L4 проксі називається *[ztunnel](/docs/ambient/overview/#ztunnel)* (тунель нульової довіри). Ztunnel радикально зменшує витрати на запуск мережі, усуваючи потребу в потенційному перевиділенню памʼяті та CPU в кластері для обробки очікуваних навантажень. У деяких випадках економія може перевищувати 90% і більше, при цьому забезпечуючи безпеку нульового рівня довіри за допомогою мTLS з криптографічною ідентичністю, простими політиками авторизації L4 та телеметрією.
|
||||
|
||||
Проксі L7 називаються *[waypoints](/docs/ambient/overview/#waypoint-proxies)*. Waypoints обробляють функції L7 такі як маршрутизація трафіку, докладний контроль політики авторизації та стійкість на промисловому рівні. Waypoints працюють поза вашими розгортаннями застосунків і можуть масштабуватися незалежно від ваших потреб, хай то для всього простору імен або для кількох сервісів у просторі імен. В порівнянні з sidecar, вам не потрібен waypoint на кожен pod застосунку, і ви можете ефективно масштабувати свій waypoint залежно від його обсягу, таким чином зберігаючи значні кількості CPU і памʼяті у більшості випадків.
|
||||
|
||||
Розділення між рівнем безпеки L4 і рівнем обробки L7 дозволяє поступову адаптацію панелі даних до режиму ambient, на відміну від ранньої бінарної "все-разом" інʼєкції sidecar контейнерів. Користувачі можуть почати з рівня безпеки L4, який пропонує більшість функцій, для яких люди впроваджують Istio (mTLS, політика авторизації та телеметрія). Складна обробка L7, така як повторні спроби, розподіл трафіку, балансування навантаження та збір спостережень, можна додати поступово у разі потреби в кожному конкретному випадку.
|
||||
|
||||
## Що в рамках бета-версії? {#what-is-in-the-scope-of-the-beta}
|
||||
|
||||
Ми рекомендуємо вам дослідити наступні функції бета-версії режиму ambient у промисловому застосуванні з відповідними запобіжними заходами, після перевірки їх у тестових середовищах:
|
||||
|
||||
- [Інсталяція Istio з підтримкою режиму ambient](/docs/ambient/install/).
|
||||
- [Додавання ваших навантажень до мережі](/docs/ambient/usage/add-workloads/) для отримання мTLS з криптографічною ідентичністю, [політик авторизації L4](/docs/ambient/usage/l4-policy/) та телеметрії.
|
||||
- [Конфігурація waypoints](/docs/ambient/usage/waypoint/) для [використання функцій L7](/docs/ambient/usage/l7-features/) таких як перемикання трафіку, маршрутизація запитів та контроль докладної політики авторизації.
|
||||
- Підключення шлюзу вхідного трафіку Istio до навантажень у режимі ambient, підтримуючи всі наявні API Istio.
|
||||
- Використання `istioctl` для управління waypoint'ами та усунення несправностей ztunnel і waypoint'ів.
|
||||
|
||||
### Альфа-функції {#alpha-features}
|
||||
|
||||
Багато інших функцій, які ми хочемо включити в режим ambient, були реалізовані, але залишаються в статусі альфа у цьому випуску. Будь ласка, допоможіть перевірити їх, щоб вони могли бути підвищені до бета-версії в 1.23 або пізніше:
|
||||
|
||||
- Мільтикластерні встановлення
|
||||
- Проксіювання DNS
|
||||
- Взаємодія з sidecar
|
||||
- Підтримка IPv6/Двох стеків
|
||||
- Підтримка SOCKS5 (для виводу)
|
||||
- Класичні API Istio (`VirtualService` та `DestinationRule`)
|
||||
|
||||
### Плани {#roadmap}
|
||||
|
||||
У нас є кілька функцій, які ще не реалізовані в режимі ambient, але заплановані для майбутніх випусків:
|
||||
|
||||
- Контрольований вихідний трафік
|
||||
- Підтримка мультимереж
|
||||
- Покращення повідомлень `status` на ресурсах для допомоги в усуненні несправностей та розумінні мережі
|
||||
- Підтримка віртуальних машин
|
||||
|
||||
## Що з sidecar? {#what-about-sidecars}
|
||||
|
||||
Sidecar контейнери не зникають і залишаються в Istio. Ви можете продовжувати використовувати sidecar контейнери, і вони залишаться повністю підтримуваними. Для будь-якої функції поза межами альфа- або бета-версії режиму ambient, слід розглянути використання sidecar режиму до того, як функція буде додана до режиму ambient. Деякі випадки використання, такі як перемикання трафіку на основі міток джерел, все ще краще реалізовані за допомогою режиму sidecar. Хоча ми вважаємо, що більшість випадків використання будуть найкраще обслужені мережею в режимі ambient, проєкт Istio залишається відданим постійній підтримці sidecar режиму.
|
||||
|
||||
## Спробуйте режим ambient сьогодні {#try-ambient-mode-today}
|
||||
|
||||
З випуском 1.22 Istio та бета-версією режиму ambient, тепер простіше ніж будь-коли спробувати Istio на ваших власних навантаженнях. Слідуйте [інструкції з початку роботи](/docs/ambient/getting-started/), щоб дослідити режим ambient, або прочитайте наші нові [посібники користувача](/docs/ambient/usage/), щоб дізнатися, як поступово впроваджувати ambient для mTLS та політики авторизації L4, управління трафіком, розширеної політики авторизації L7 та іншого. Ви можете спілкуватися з розробниками в каналі #ambient на [Istio Slack](https://slack.istio.io), або скористатися форумом discussion на [GitHub](https://github.com/istio/istio/discussions) для будь-яких запитань, які можуть у вас виникнути.
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
---
|
||||
title: "Istio оголошує про визнання застарілим In-Cluster Operator"
|
||||
description: Що потрібно знати, якщо ви використовуєте контролер оператора у вашому кластері.
|
||||
publishdate: 2024-08-14
|
||||
attribution: "Mitch Connors (Microsoft), для Технічного наглядового комітету Istio"
|
||||
keywords: [operator,deprecation]
|
||||
---
|
||||
|
||||
In-Cluster Operator Istio було визнано застарілим в Istio 1.23. Користувачам, які використовують оператор, кількість яких ми оцінюємо менше ніж 10% від нашої бази користувачів, потрібно буде мігрувати до інших механізмів інсталяції та оновлення, щоб оновитися до Istio 1.24 або вище. Читайте далі, щоб дізнатися, чому ми прийняли це рішення та що потрібно зробити користувачам оператора.
|
||||
|
||||
## Чи це вплине на вас? {#does-this-affect-you}
|
||||
|
||||
Це застарівання стосується лише користувачів [In-Cluster Operator](/docs/setup/install/operator/). **Користувачі, які встановлюють Istio за допомогою команди <code>istioctl install</code> і YAML файлу `IstioOperator`, не постраждають**.
|
||||
|
||||
Щоб визначити, чи це вплине на вас, виконайте команди `kubectl get deployment -n istio-system istio-operator` і `kubectl get IstioOperator`. Якщо обидві команди повертають непорожні значення, ваш кластер знаходиться під впливом цього застарівання. Згідно з останніми опитуваннями, ми очікуємо, що це вплине на менше ніж 10% користувачів Istio.
|
||||
|
||||
Інсталяції Istio на основі оператора продовжать працювати безстроково, але не зможуть бути оновлені вище 1.23.x.
|
||||
|
||||
## Коли потрібно мігрувати? {#when-do-i-need-to-migrate}
|
||||
|
||||
Відповідно до політики визнання функцій застарілими в Istio для бета-функцій, In-Cluster Operator Istio буде видалено з релізом Istio 1.24, приблизно через три місяці після цього оголошення. Istio 1.23 буде підтримуватись до березня 2025 року, після чого користувачам оператора потрібно буде мігрувати до іншого механізму інсталяції для збереження підтримки.
|
||||
|
||||
## Як мігрувати? {#how-do-i-migrate}
|
||||
|
||||
Проєкт Istio продовжить підтримувати інсталяцію та оновлення через команду `istioctl`, а також з допомогою Helm. Через популярність Helm в екосистемі розробки платформ, ми рекомендуємо більшості користувачів мігрувати на Helm. `istioctl install` базується на шаблонах Helm, і в майбутніх версіях можливе глибше інтегрування з Helm.
|
||||
|
||||
Інсталяції Helm також можуть бути керовані з допомогою GitOps інструментів, таких як [Flux](https://fluxcd.io/) або [Argo CD](https://argo-cd.readthedocs.io/).
|
||||
|
||||
Користувачі, які віддають перевагу шаблону оператора для запуску Istio, можуть мігрувати до одного з двох нових проєктів екосистеми Istio: Classic Operator Controller або Sail Operator.
|
||||
|
||||
### Міграція на Helm {#migrating-to-helm}
|
||||
|
||||
Міграція на Helm вимагає переведення вашого YAML файлу `IstioOperator` у Helm `values.yaml`. Інструменти для підтримки цієї міграції будуть надані разом з релізом Istio 1.24.
|
||||
|
||||
### Міграція на istioctl {#migrating-to-istioctl}
|
||||
|
||||
Визначте ваш ресурс `IstioOperator`: має бути лише один результат.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get IstioOperator
|
||||
{{< /text >}}
|
||||
|
||||
Використовуючи імʼя вашого ресурсу, завантажте конфігурацію вашого оператора у форматі YAML:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get IstioOperator <name> > istio.yaml
|
||||
{{< /text >}}
|
||||
|
||||
Вимкніть In-Cluster Operator. Це не вимкне вашу панель управління або порушить ваш поточний трафік мережі.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl scale deployment -n istio-system istio-operator –replicas 0
|
||||
{{< /text >}}
|
||||
|
||||
Коли ви будете готові оновити Istio до версії 1.24 або пізнішої, дотримуйтесь [інструкцій з оновлення](/docs/setup/upgrade/canary/), використовуючи файл `istio.yaml`, який ви завантажили вище.
|
||||
|
||||
Після завершення та перевірки вашої міграції виконайте наступні команди для очищення ресурсів оператора:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete deployment -n istio-system istio-operator
|
||||
$ kubectl delete customresourcedefinition istiooperator
|
||||
{{< / text >}}
|
||||
|
||||
### Міграція на Classic Operator Controller {#migrating-to-the-classic-operator-controller}
|
||||
|
||||
Новий проєкт екосистеми, [Classic Operator Controller](https://github.com/istio-ecosystem/classic-operator-controller), є форком оригінального контролера, вбудованого в Istio. Цей проєкт підтримує той самий API та кодову базу, що й оригінальний оператор, але підтримується поза основним проєктом Istio.
|
||||
|
||||
Оскільки API є таким самим, міграція є прямолінійною: потрібно лише інсталювати новий оператор.
|
||||
|
||||
Classic Operator Controller не підтримується проєктом Istio.
|
||||
|
||||
### Міграція на Sail Operator {#migrating-to-sail-operator}
|
||||
|
||||
Новий проєкт екосистеми, [Sail Operator](https://github.com/istio-ecosystem/sail-operator), може інсталювати та керувати життєвим циклом панелі управління Istio у Kubernetes або OpenShift кластері.
|
||||
|
||||
API Sail Operator побудовані навколо API Helm charts Istio. Усі параметри інсталяції та конфігурації, які надаються через Helm charts Istio, доступні через поля `values:` CRD Sail Operator.
|
||||
|
||||
Sail Operator не підтримується проєктом Istio.
|
||||
|
||||
## Що таке оператор і чому Istio його мав? {#what-is-an-operator-and-why-did-istio-have-one}
|
||||
|
||||
[Шаблон оператора](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) був популяризований CoreOS у 2016 році метод кодифікації людського інтелекту в код. Найбільш поширене використання — це оператор бази даних, де користувач може мати кілька екземплярів бази даних в одному кластері з кількома поточними операційними завданнями (резервні копії, вакуумування, розподіл).
|
||||
|
||||
Istio вперше представив istioctl і In-Cluster Operator у версії 1.4, у відповідь на проблеми з Helm v2. Того ж часу було представлено Helm v3, який вирішив проблеми спільноти і є переважним методом інсталяції програмного забезпечення в Kubernetes сьогодні. Підтримка Helm v3 була додана в Istio 1.8.
|
||||
|
||||
In-Cluster Operator Istio обробляв інсталяцію компонентів сервісної мережі — операцію, яку зазвичай виконуєте один раз і для одного екземпляра на кластер. Можна вважати це способом запуску istioctl всередині вашого кластера. Однак це означало, що у вас є контролер з високими привілеями всередині вашого кластера, що послаблює вашу безпеку. Він не обробляє жодних поточних адміністративних завдань (резервні копії, знімки тощо, не є вимогами для запуску Istio).
|
||||
|
||||
Istio оператор є чимось, що потрібно встановити в кластер, що означає, що ви вже повинні управляти інсталяцією чогось. Використання його для оновлення кластера також спочатку вимагало завантаження та запуску нової версії istioctl.
|
||||
|
||||
Використання оператора означає, що ви створили рівень абстракції, де вам потрібно мати параметри у вашому власному ресурсі для налаштування всього, що ви можете бажати змінити в інсталяції. Istio обійшов це, пропонуючи API `IstioOperator`, яке дозволяє конфігурувати параметри інсталяції. Цей ресурс використовується як In-Cluster Operator, так і istioctl install, тому є тривіальний шлях міграції для користувачів оператора.
|
||||
|
||||
Три роки тому, приблизно в часі Istio 1.12, ми оновили нашу документацію, щоб сказати, що використання оператора для нових інсталяцій Istio не рекомендується, і що користувачі повинні використовувати istioctl або Helm для інсталяції Istio.
|
||||
|
||||
[Наявність трьох різних методів інсталяції викликало плутанину](https://blog.howardjohn.info/posts/istio-install/), і для того, щоб забезпечити найкращий досвід для людей, які використовують Helm або istioctl, понад 90\% нашої бази установок, ми вирішили офіційно визнати застарілим In-Cluster Operator в Istio 1.23.
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
title: "Представляємо Sail Operator: новий спосіб керування Istio"
|
||||
description: Представляємо Sail Operator для керування Istio, проект від організації istio-ecosystem.
|
||||
publishdate: 2024-08-19
|
||||
attribution: "Francisco Herrera — Red Hat"
|
||||
keywords: [istio,operator,sail,incluster,deprecation]
|
||||
---
|
||||
|
||||
З нещодавнім оголошенням про [застарівання](/blog/2024/in-cluster-operator-deprecation-announcement/) In-Cluster IstioOperator в Istio 1.23 та його подальше видалення в Istio 1.24, ми хочемо підвищити обізнаність про [новий оператор](https://github.com/istio-ecosystem/sail-operator), який команда Red Hat розробляє для керування Istio в рамках організації [istio-ecosystem](https://github.com/istio-ecosystem).
|
||||
|
||||
Sail Operator керує життєвим циклом панелей управління Istio, що спрощує й робить ефективнішим процес розгортання, налаштування та оновлення Istio для адміністраторів кластерів у великих виробничих середовищах. Замість того, щоб створювати нову схему конфігурації та "вигадувати велосипед", API Sail Operator побудовані навколо API Helm charts Istio. Усі параметри інсталяції та конфігурації, які надаються через Helm charts Istio, доступні через поля значень CRD Sail Operator. Це означає, що ви можете легко керувати та налаштовувати Istio за допомогою знайомих конфігурацій без необхідності вивчати додаткові елементи.
|
||||
|
||||
Sail Operator має три основні концепції ресурсів:
|
||||
|
||||
* [Istio](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md#istio-resource): використовується для керування панелями управління Istio.
|
||||
* [Istio Revision](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md#istiorevision-resource): представляє ревізію панелі управління, що є інстанцією Istio з певною версією та імʼям ревізії.
|
||||
* [Istio CNI](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md#istiocni-resource): використовується для керування ресурсами та життєвим циклом втулка Istio CNI. Для інсталяції втулка Istio CNI створюється ресурс `IstioCNI`.
|
||||
|
||||
Наразі основна функція Sail Operator — це стратегія оновлення. Оператор надає інтерфейс для керування оновленням панелей управління Istio. Він підтримує дві стратегії оновлення:
|
||||
|
||||
* [In Place](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md#inplace): зі стратегією `InPlace`, наявна панель управління Istio замінюється новою версією, і sidecarʼи навантажень одразу підключаються до нової панелі управління. Це означає, що навантаження не потрібно переносити з однієї панелі управління на іншу.
|
||||
* [Revision Based](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md#revisionbased): зі стратегією `RevisionBased`, новий екземпляр панелі управління Istio створюється для кожної зміни поля `Istio.spec.version`. Стара панель управління залишається на місці, доки всі навантаження не будуть перенесені на новий екземпляр. Додатково, прапорець `updateWorkloads` може бути встановлений для автоматичного переміщення навантажень на нову панель управління після її готовності.
|
||||
|
||||
Ми розуміємо, що оновлення панелі управління Istio повʼязане з ризиками та може вимагати значних зусиль для великих розгортань, тому це є нашим основним фокусом на цей момент. У майбутньому ми розглядаємо можливості покращення Sail Operator для підтримки таких випадків використання, як мультиоренда та ізоляція, федерація між кластерами та спрощена інтеграція зі сторонніми проєктами.
|
||||
|
||||
Проєкт Sail Operator ще на стадії alpha і знаходиться у стадії активної розробки. Зазначимо, що як проєкт з організації istio-ecosystem, він не підтримується в рамках основного проєкту Istio. Ми активно шукаємо відгуки та внески від спільноти. Якщо ви бажаєте взяти участь у проєкті, зверніться до [документації](https://github.com/istio-ecosystem/sail-operator/blob/main/README.md) та [інструкцій для внесків](https://github.com/istio-ecosystem/sail-operator/blob/main/CONTRIBUTING.md). Також ви можете випробувати новий оператор, дотримуючись вказівок у [документації для користувачів](https://github.com/istio-ecosystem/sail-operator/blob/main/docs/README.md).
|
||||
|
||||
Для додаткової інформації звʼяжіться з нами:
|
||||
|
||||
* [Обговорення](https://github.com/istio-ecosystem/sail-operator/discussions)
|
||||
* [Питання](https://github.com/istio-ecosystem/sail-operator/issues)
|
||||
* [Slack](https://istio.slack.com/archives/C06SE9XCK3Q)
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: Блог
|
||||
description: Читайте статті від авторів та користувачів про все, що стосується Istio.
|
||||
linktitle: Blog
|
||||
sidebar_multicard: true
|
||||
decoration: pill
|
||||
aliases:
|
||||
- /uk/blog/posts/index.html
|
||||
outputs:
|
||||
- html
|
||||
- rss
|
||||
---
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
---
|
||||
{{< warning >}}
|
||||
Ця функція орієнтована на розробників/кваліфікованих користувачів і вважається [Alpha](https://github.com/istio/community/blob/master/FEATURE-LIFECYCLE.md).
|
||||
{{< /warning >}}
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
---
|
||||
|
||||
{{< text syntax=plain snip_id=gateway_api_version >}}
|
||||
{{< k8s_gateway_api_version >}}
|
||||
{{< /text >}}
|
||||
|
||||
---
|
||||
---
|
||||
|
||||
{{< text syntax=plain snip_id=istio_previous_version >}}
|
||||
{{< istio_previous_version >}}
|
||||
{{< /text >}}
|
||||
|
||||
---
|
||||
---
|
||||
|
||||
{{< text syntax=plain snip_id=istio_full_version >}}
|
||||
{{< istio_full_version >}}
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
---
|
||||
---
|
||||
## Перш ніж розпочати {#before-you-begin}
|
||||
|
||||
* Налаштуйте Istio, дотримуючися інструкцій у [посібнику з встановлення](/docs/setup/).
|
||||
|
||||
{{< tip >}}
|
||||
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), виконайте наступну команду для розгортання демонстраційного застосунку:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f @samples/sleep/sleep.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Інакше, вручну додайте sidecar перед розгортанням застосунку `sleep` за допомогою наступної команди:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
|
||||
{{< /text >}}
|
||||
|
||||
{{< tip >}}
|
||||
Ви можете використовувати будь-який pod з встановленим `curl` як джерело тестів.
|
||||
{{< /tip >}}
|
||||
|
||||
* Встановіть змінну середовища `SOURCE_POD` на імʼя вашого podʼа:
|
||||
|
||||
{{< text bash >}}
|
||||
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
---
|
||||
---
|
||||
За бажанням, обліковий запис може містити [список відкликання сертифікатів (CRL)](https://datatracker.ietf.org/doc/html/rfc5280) за допомогою ключа `ca.crl`. Якщо так, додайте ще один аргумент до наведеного вище прикладу, щоб надати CRL: `--from-file=ca.crl=/some/path/to/your-crl.pem`.
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
---
|
||||
1. Створіть config map, завантаживши [custom-bootstrap-runtime.yaml](/news/security/istio-security-2020-007/custom-bootstrap-runtime.yaml). Оновіть `global_downstream_max_connections` у config map відповідно до кількості одночасних зʼєднань, необхідних для окремих екземплярів шлюзу у вашому розгортанні. Як тільки ліміт буде досягнуто, Envoy почне відхиляти TCP зʼєднання.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl -n istio-system apply -f custom-bootstrap-runtime.yaml
|
||||
{{< /text >}}
|
||||
|
||||
2. Застосуйте патч до розгортання ingress gateway для використання вище зазначеної конфігурації. Завантажте [gateway-patch.yaml](/news/security/istio-security-2020-007/gateway-patch.yaml) та застосуйте його за допомогою наступної команди.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl --namespace istio-system patch deployment istio-ingressgateway --patch "$(cat gateway-patch.yaml)"
|
||||
{{< /text >}}
|
||||
|
||||
3. Переконайтесь, що нові ліміти застосовані.
|
||||
|
||||
{{< text bash >}}
|
||||
$ ISTIO_INGRESS_PODNAME=$(kubectl get pods -l app=istio-ingressgateway -n istio-system -o jsonpath="{.items[0].metadata.name}")
|
||||
$ kubectl --namespace istio-system exec -i -t "${ISTIO_INGRESS_PODNAME}" -c istio-proxy -- curl -sS http://localhost:15000/runtime
|
||||
|
||||
{
|
||||
"entries": {
|
||||
"overload.global_downstream_max_connections": {
|
||||
"layer_values": [
|
||||
"",
|
||||
"250000",
|
||||
""
|
||||
],
|
||||
"final_value": "250000"
|
||||
}
|
||||
},
|
||||
"layers": [
|
||||
"static_layer_0",
|
||||
"admin"
|
||||
]
|
||||
}
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
---
|
||||
|
||||
Це деякий шаблонний **markdown** _текст_.
|
||||
|
||||
{{< text plain >}}
|
||||
Приклад вкладеного текстового блоку в шаблоні.
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
---
|
||||
{{< warning >}}
|
||||
Наступна інформація описує експериментальну функцію, яка призначена лише для ознайомлення.
|
||||
{{< /warning >}}
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
---
|
||||
{{< warning >}}
|
||||
Ця функція активно розвивається і вважається
|
||||
[експериментальною](https://github.com/istio/community/blob/master/FEATURE-LIFECYCLE.md).
|
||||
{{< /warning >}}
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
---
|
||||
{{< warning >}}
|
||||
Ці інструкції передбачають, що ваш кластер Kubernetes підтримує зовнішні балансувальники навантаження (тобто сервіси типу `LoadBalancer`). Ознайомтеся з [керуванням ingress](/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports) для отримання деталей.
|
||||
{{< /warning >}}
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
---
|
||||
---
|
||||
Наступні інструкції дозволяють вам вибрати використання або Gateway API, або API конфігурації Istio при налаштуванні управління трафіком в mesh. Дотримуйтесь інструкцій на вкладці `Gateway API` або `Istio APIs`, відповідно до ваших уподобань.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
---
|
||||
---
|
||||
Istio підтримує Kubernetes [Gateway API](/blog/2024/gateway-mesh-ga/) і має намір зробити його стандартним API для управління трафіком в майбутньому.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
---
|
||||
{{< tip >}}
|
||||
{{< boilerplate gateway-api-future >}}
|
||||
{{< boilerplate gateway-api-choose >}}
|
||||
{{< /tip >}}
|
||||
|
||||
{{< warning >}}
|
||||
Цей документ конфігурує Istio, використовуючи функції Gateway API, які є [експериментальними](https://gateway-api.sigs.k8s.io/geps/overview/#status). Перед використанням інструкцій Gateway API переконайтеся, що:
|
||||
|
||||
1) Ви встановили **експериментальну версію** CRD Gateway API:
|
||||
|
||||
{{< text syntax=bash snip_id=install_experimental_crds >}}
|
||||
$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref={{< k8s_gateway_api_version >}}" | kubectl apply -f -
|
||||
{{< /text >}}
|
||||
|
||||
2) Налаштуйте Istio для читання альфа-ресурсів Gateway API, встановивши змінну середовища `PILOT_ENABLE_ALPHA_GATEWAY_API` на `true` під час інсталяції Istio:
|
||||
|
||||
{{< text syntax=bash snip_id=enable_alpha_crds >}}
|
||||
$ istioctl install --set values.pilot.env.PILOT_ENABLE_ALPHA_GATEWAY_API=true --set profile=minimal -y
|
||||
{{< /text >}}
|
||||
|
||||
{{< /warning >}}
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
---
|
||||
Зверніть увагу, що CRD Kubernetes Gateway API стандартно не встановлені в більшості кластерів Kubernetes, тому переконайтеся, що вони встановлені перед використанням Gateway API:
|
||||
|
||||
{{< text syntax=bash snip_id=install_crds >}}
|
||||
$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
|
||||
{ kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/{{< k8s_gateway_api_version >}}/standard-install.yaml; }
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
---
|
||||
---
|
||||
Вилучіть CRD Kubernetes Gateway API:
|
||||
|
||||
{{< text syntax=bash snip_id=remove_crds >}}
|
||||
$ kubectl delete -f https://github.com/kubernetes-sigs/gateway-api/releases/download/{{< k8s_gateway_api_version >}}/standard-install.yaml
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
---
|
||||
{{< tip >}}
|
||||
{{< boilerplate gateway-api-future >}}
|
||||
{{< boilerplate gateway-api-choose >}}
|
||||
|
||||
{{< boilerplate gateway-api-install-crds >}}
|
||||
|
||||
{{< /tip >}}
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
---
|
||||
Перед оновленням Istio у вашому кластері ми рекомендуємо створити резервну копію ваших власних конфігурацій і відновити їх з резервної копії за необхідності:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get istio-io --all-namespaces -oyaml > "$HOME"/istio_resource_backup.yaml
|
||||
{{< /text >}}
|
||||
|
||||
Ви можете відновити вашу власну конфігурацію так:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f "$HOME"/istio_resource_backup.yaml
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
---
|
||||
{{< warning >}}
|
||||
Стандартно конфігурація чарта використовує захищені сторонні токени для проєкцій токенів службових облікових записів, які використовуються проксі-серверами Istio для автентифікації панеллю управління Istio. Перед тим як перейти до інсталяції будь-якого з наведених нижче чартів, вам слід перевірити, чи увімкнені сторонні токени у вашому кластері, дотримуючись інструкцій, описаних [тут](/docs/ops/best-practices/security/#configure-third-party-service-account-tokens). Якщо сторонні токени не увімкнені, ви повинні додати параметр `--set global.jwtPolicy=first-party-jwt` до команд інсталяції Helm. Якщо `jwtPolicy` не налаштований правильно, контейнери, повʼязані з `istiod`, шлюзами або навантаженнями з впровадженими проксі-серверами Envoy, не будуть розгорнуті через відсутність тому `istio-token`.
|
||||
{{< /warning >}}
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
---
|
||||
|
||||
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), описаний у цьому посібнику.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
---
|
||||
## Попередні вимоги {#prerequisites}
|
||||
|
||||
1. Виконайте будь-яке необхідне [налаштування для вашої платформи](/docs/setup/platform-setup/).
|
||||
|
||||
1. Перевірте [Вимоги до Podʼів та Сервісів](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
1. [Встановіть клієнт Helm](https://helm.sh/docs/intro/install/), версії 3.6 або вище.
|
||||
|
||||
1. Налаштуйте репозиторій Helm:
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm repo add istio https://istio-release.storage.googleapis.com/charts
|
||||
$ helm repo update
|
||||
{{< /text >}}
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
headless: true
|
||||
---
|
||||
|
||||
Цей файл повідомляє Hugo, що файли в цьому дереві тек не повинні відображатися на сайті як звичайні сторінки.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
---
|
||||
* Ви можете використовувати команду `kubectl` для доступу до обох кластерів `cluster1` та `cluster2`, використовуючи прапорець `--context`, наприклад, `kubectl get pods --context cluster1`. Використовуйте наступну команду, щоб отримати ваші контексти:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config get-contexts
|
||||
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
|
||||
* cluster1 cluster1 user@foo.com default
|
||||
cluster2 cluster2 user@foo.com default
|
||||
{{< /text >}}
|
||||
|
||||
* Збережіть імена контекстів ваших кластерів у змінних середовища:
|
||||
|
||||
{{< text bash >}}
|
||||
$ export CTX_CLUSTER1=$(kubectl config view -o jsonpath='{.contexts[0].name}')
|
||||
$ export CTX_CLUSTER2=$(kubectl config view -o jsonpath='{.contexts[1].name}')
|
||||
$ echo "CTX_CLUSTER1 = ${CTX_CLUSTER1}, CTX_CLUSTER2 = ${CTX_CLUSTER2}"
|
||||
CTX_CLUSTER1 = cluster1, CTX_CLUSTER2 = cluster2
|
||||
{{< /text >}}
|
||||
|
||||
{{< tip >}}
|
||||
Якщо у вас більше ніж два кластери у списку контекстів і ви хочете налаштувати свою мережу, використовуючи інші кластери, ніж перші два, вам потрібно буде вручну встановити змінні середовища на відповідні імена контекстів.
|
||||
{{< /tip >}}
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
---
|
||||
{{< tip >}}
|
||||
Якщо ви тестуєте налаштування мультикластерів на `kind`, ви можете використовувати [MetalLB](https://metallb.universe.tf/installation/), щоб скористатися `EXTERNAL-IP` для сервісів типу `LoadBalancer`.
|
||||
{{< /tip >}}
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
---
|
||||
Ревізія, на яку вказує теґ `default`, вважається ***стандартною ревізією*** і має додаткове семантичне значення. Стандартна ревізія виконує такі функції:
|
||||
|
||||
- Додає sidecar контейнери для селектора простору імен `istio-injection=enabled`, селектора обʼєкта `sidecar.istio.io/inject=true` та селекторів `istio.io/rev=default`
|
||||
- Валідує ресурси Istio
|
||||
- Перехоплює блокування лідера у нестандартних ревізій і виконує обовʼязки синглтонів mesh (наприклад, оновлення статусів ресурсів).
|
||||
|
||||
Щоб зробити ревізію `{{< istio_full_version_revision >}}` стандартною, виконайте:
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
---
|
||||
---
|
||||
При використанні теґу `default` разом з існуючою неопрацьованою інсталяцією Istio рекомендується видалити стару `MutatingWebhookConfiguration` (зазвичай називається `istio-sidecar-injector`), щоб уникнути спроб інʼєкції як у старій, так і у новій панелях управління.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
---
|
||||
Отримане зіставлення між ревізіями, теґами та просторами імен виглядає наступним чином:
|
||||
|
||||
{{< image width="90%"
|
||||
link="/uk/docs/setup/upgrade/canary/revision-tags-before.svg"
|
||||
caption="Два простори імен вказані на prod-stable, і один на prod-canary"
|
||||
>}}
|
||||
|
||||
Оператор кластера може переглядати це зіставлення разом із протеґованими просторами імен за допомогою команди `istioctl tag list`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl tag list
|
||||
TAG REVISION NAMESPACES
|
||||
default {{< istio_previous_version_revision >}}-1 ...
|
||||
prod-canary {{< istio_full_version_revision >}} ...
|
||||
prod-stable {{< istio_previous_version_revision >}}-1 ...
|
||||
{{< /text >}}
|
||||
|
||||
Після того як оператор кластера впевнений у стабільності панелі управління з теґом `prod-canary`, простори імен, помічені як `istio.io/rev=prod-stable`, можна оновити однією дією, змінивши теґ ревізії `prod-stable`, щоб вказувати на новішу ревізію `{{< istio_full_version_revision >}}`.
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
---
|
||||
---
|
||||
Переназивання просторів назв вручну під час перенесення їх до нової ревізії може бути нудним і повʼязаним з помилками. [Теґи ревізій](/docs/reference/commands/istioctl/#istioctl-tag) вирішують цю проблему. [Мітки ревізій](/docs/reference/commands/istioctl/#istioctl-tag) є стабільними ідентифікаторами, які вказують на ревізії і можуть бути використані для уникнення переназивання просторів імен. Замість того, щоб переназивати простір імен, оператор сервісної мереді може просто змінити теґ, щоб він вказував на нову ревізію. Усі простори імен, позначені цією міткою, буде оновлено одночасно.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue