mirror of https://github.com/istio/istio.io.git
[uk] Sync Ukrainian translation with upstream documentation (#16203)
* Add Ukrainian language support * [uk] operations * [uk] setup * Update Ukrainian content for ambient mode and fix logo paths * [uk] Sync Ukrainian translation with upstream documentation * [uk] Re GKE platform profile #16035 * [uk] Sync Ukrainian translation with upstream documentation
This commit is contained in:
Andrii Holovin
GitHub
parent
4dac6f0aaa
commit
60ba2a356a
|
|
@ -3,7 +3,7 @@ title: Приклади використання
|
|||
aliases:
|
||||
- /uk/case-studies
|
||||
- /uk/about/community/customers
|
||||
- /uk/latest/about/community/customers
|
||||
- /latest/uk/about/community/customers
|
||||
doc_type: about
|
||||
type: case-studies
|
||||
sidebar_none: true
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ skip_byline: true
|
|||
skip_pagenav: true
|
||||
aliases:
|
||||
- /uk/about/community/partners/
|
||||
- /uk/latest/about/community/partners/
|
||||
- /latest/uk/about/community/partners/
|
||||
doc_type: about
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -19,22 +19,7 @@ weight: 10
|
|||
- Необхідно керувати кількома бінарними файлами, по одному для кожної мінорної версії Istio.
|
||||
- Команда `istioctl` може встановлювати значення автоматично на основі вашого робочого середовища, що може призводити до різних установок в різних Kubernetes-середовищах.
|
||||
|
||||
2. [Генерація маніфесту за допомогою istioctl](/docs/setup/install/istioctl/#generate-a-manifest-before-installation)
|
||||
|
||||
Генерація Kubernetes-маніфесту, а потім застосування команди `kubectl apply --prune`. Цей метод підходить у випадках, коли потрібен суворий аудит або доопрацювання отриманих маніфестів.
|
||||
|
||||
Переваги:
|
||||
|
||||
- Ресурси генеруються з того ж API `IstioOperator`, що й у `istioctl install`.
|
||||
- Використовує API `IstioOperator`, який надає широкі можливості конфігурації/кастомізації.
|
||||
|
||||
Недоліки:
|
||||
|
||||
- Деякі перевірки, які виконуються в `istioctl install`, не виконуються.
|
||||
- Цей тип використання з погляду користувача менш оптимізований у порівнянні з `istioctl install`.
|
||||
- Повідомлення про помилки менш інформативні, ніж у `istioctl install` на етапі застосування.
|
||||
|
||||
3. [Установка за допомогою Helm](/docs/setup/install/helm/)
|
||||
1. [Установка за допомогою Helm](/docs/setup/install/helm/)
|
||||
|
||||
Використання Helm-чартів дозволяє легко інтегруватися з робочими процесами на основі Helm і автоматично видаляти ресурси під час оновлень.
|
||||
|
||||
|
|
@ -48,4 +33,23 @@ weight: 10
|
|||
- Менше перевірок і валідацій порівняно з `istioctl install`.
|
||||
- Деякі адміністративні завдання потребують більше кроків та мають вищу складність.
|
||||
|
||||
1. Застосування згенерованого маніфесту Kubernetes
|
||||
|
||||
- [Генерація маніфестів Kubernetes за допомогою `istioctl`](/docs/setup/install/istioctl/#generate-a-manifest-before-installation)
|
||||
- [Генерація Kubernetes маніфестів за допомогою `helm`](/docs/setup/install/helm/#generate-a-manifest-before-installation)
|
||||
|
||||
Цей метод підходить, коли потрібен суворий аудит або доповнення отриманих маніфестів, або існують обмеження сторонніх інструментів.
|
||||
|
||||
Переваги:
|
||||
|
||||
- Легше інтегрувати з інструментами, які не використовують `helm` або `istioctl`.
|
||||
- Не потрібні інструменти для установки, окрім `kubectl`.
|
||||
|
||||
Недоліки:
|
||||
|
||||
- Не виконуються перевірки під час установки, виявлення середовища або валідації, які підтримуються будь-яким з вищезазначених методів.
|
||||
- Не підтримується управління установкою або можливість оновлення.
|
||||
- Менш зручний інтерфейс користувача.
|
||||
- Звітування про помилки під час установки менш надійне.
|
||||
|
||||
Інструкції з установки для всіх цих методів доступні на [сторінці установки Istio](/docs/setup/install).
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ aliases:
|
|||
- /uk/docs/concepts/what-is-istio/goals
|
||||
- /uk/about/intro
|
||||
- /uk/docs/concepts/what-is-istio/
|
||||
- /uk/latest/docs/concepts/what-is-istio/
|
||||
- /latest/uk/docs/concepts/what-is-istio/
|
||||
doc_type: about
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
---
|
||||
---
|
||||
Helm-чарти для `base` та `istiod`, які використовуються в цьому посібнику, такі ж самі, як і ті, що використовуються при встановленні Istio через [Istioctl](/docs/setup/install/istioctl/). Однак під час встановлення через Istioctl використовується інший [чарт шлюзу]({{< github_tree >}}/manifests/charts/gateways/istio-ingress), ніж [чарт]({{< github_tree >}}/manifests/charts/gateway), описаний у цьому посібнику
|
||||
Helm-чарти які використовуються в цьому посібнику, такі ж самі, як і ті, що використовуються при встановленні Istio через [Istioctl](/docs/setup/install/istioctl/), за винятком чарту `gateway`.
|
||||
|
||||
Istioctl використовується інший [чарт шлюзу]({{< github_tree >}}/manifests/charts/gateways/istio-ingress), ніж [чарт шлюзу]({{< github_tree >}}/manifests/charts/gateway), описаний у цьому посібнику
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
|
||||
1. Перевірте [Вимоги до Podʼів та Сервісів](/docs/ops/deployment/application-requirements/).
|
||||
|
||||
1. [Встановіть клієнт Helm](https://helm.sh/docs/intro/install/), версії 3.6 або вище.
|
||||
1. [Встановіть останню версію клієнта Helm](https://helm.sh/docs/intro/install/). Версії Helm, випущені до [найстарішого поточного підтримуваного випуску Istio](docs/releases/supported-releases/#support-status-of-istio-releases), не тестуються, не підтримуються і не рекомендуються.
|
||||
|
||||
1. Налаштуйте репозиторій Helm:
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Інформація для налаштування та експ
|
|||
weight: 17
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient
|
||||
- /uk/latest/docs/ops/ambient
|
||||
- /latest/uk/docs/ops/ambient
|
||||
keywords: [ambient]
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Докладний огляд архітектури режиму
|
|||
weight: 20
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/architecture
|
||||
- /uk/latest/docs/ops/ambient/architecture
|
||||
- /latest/uk/docs/ops/ambient/architecture
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: table-of-contents
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Зрозумійте, як трафік перенаправляє
|
|||
weight: 5
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/usage/traffic-redirection
|
||||
- /uk/latest/docs/ops/ambient/usage/traffic-redirection
|
||||
- /latest/uk/docs/ops/ambient/usage/traffic-redirection
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: no
|
||||
---
|
||||
|
|
@ -35,7 +35,7 @@ alt="Pod додано до flow ambient mesh"
|
|||
- Вузловий агент `istio-cni` потім інформує проксі ztunnel через сокет Unix-домену, що йому потрібно встановити локальні порти прослуховування проксі всередині мережевого простору імен podʼа (на портах 15008, 15006 і 15001), і надає ztunnel низькорівневий [файловий дескриптор](https://en.wikipedia.org/wiki/File_descriptor), що представляє мережевий простір імен podʼа.
|
||||
- Хоча зазвичай сокети створюються всередині мережевого простору імен Linux процесом, що фактично працює всередині цього простору імен, цілком можливо використовувати низькорівневий API сокетів Linux, щоб дозволити процесу, що працює в одному мережевому просторі імен, створювати порти прослуховування в іншому мережевому просторі імен, за умови, що цільовий мережевий простір імен відомий на момент створення.
|
||||
|
||||
- Локальний ztunnel всередині вузла створює новий екземпляр проксі та набір портів прослуховування, спеціально для нового доданого podʼа.
|
||||
- Локальний ztunnel на вузлі створює новий логічний екземпляр проксі-сервера і набір портів для прослуховування, призначених для щойно доданого podʼа. Зауважте, що це все ще виконується у межах того самого процесу і є лише окремим завданням для цього podʼа.
|
||||
|
||||
- Коли правила перенаправлення всередині podʼа встановлені і ztunnel створив порти прослуховування, pod додається в mesh, і трафік починає текти через локальний ztunnel.
|
||||
|
||||
|
|
@ -129,4 +129,4 @@ COMMIT
|
|||
COMMIT
|
||||
{{< /text >}}
|
||||
|
||||
Вивід команди показує, що до таблиць NAT та Mangle у netfilter/iptables у мережевому просторі імен podʼа додано додаткові специфічні для Istio ланцюги. Весь TCP трафік, що надходить до podʼа, перенаправляється до проксі ztunnel для обробки входу. Якщо трафік є незашифрованим (порт джерела != 15008), він буде перенаправлений до порту прослуховування plaintext проксі ztunnel всередині podʼа на порту 15006. Якщо трафік є HBONE (порт джерела == 15008), він буде перенаправлений до порту прослуховування HBONE проксі ztunnel всередині podʼа на порту 15008. Будь-який TCP трафік, що виходить з podʼа, перенаправляється на порт 15001 проксі ztunnel для обробки виходу перед відправленням через ztunnel з використанням інкапсуляції HBONE.
|
||||
Вивід команди показує, що до таблиць NAT та Mangle у netfilter/iptables у мережевому просторі імен podʼа додано додаткові специфічні для Istio ланцюги. Весь TCP трафік, що надходить до podʼа, перенаправляється до проксі ztunnel для обробки входу. Якщо трафік є незашифрованим (порт призначення != 15008), він буде перенаправлений до порту прослуховування plaintext проксі ztunnel всередині podʼа на порту 15006. Якщо трафік є HBONE (порт призначення == 15008), він буде перенаправлений до порту прослуховування HBONE проксі ztunnel всередині podʼа на порту 15008. Будь-який TCP трафік, що виходить з podʼа, перенаправляється на порт 15001 проксі ztunnel для обробки виходу перед відправленням через ztunnel з використанням інкапсуляції HBONE.
|
||||
|
|
|
|||
|
|
@ -4,10 +4,11 @@ description: Як розгорнути та встановити Istio в реж
|
|||
weight: 2
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/getting-started
|
||||
- /uk/latest/docs/ops/ambient/getting-started
|
||||
- /latest/uk/docs/ops/ambient/getting-started
|
||||
owner: istio/wg-networking-maintainers
|
||||
skip_list: true
|
||||
test: yes
|
||||
skip_list: true
|
||||
next: /docs/ambient/getting-started/deploy-sample-app
|
||||
---
|
||||
|
||||
Цей посібник дозволяє швидко оцінити режим {{< gloss "ambient" >}}ambient{{< /gloss >}} в Istio. Для продовження вам знадобиться кластер Kubernetes. Якщо у вас немає кластера, ви можете використовувати [kind](/docs/setup/platform-setup/kind) або будь-яку іншу [підтримувану платформу Kubernetes](/docs/setup/platform-setup).
|
||||
|
|
|
|||
|
|
@ -4,6 +4,7 @@ description: Видаліть Istio та повʼязані з ним ресур
|
|||
weight: 6
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: yes
|
||||
next: /docs/ambient/install
|
||||
---
|
||||
|
||||
Якщо вам більше не потрібні Istio та повʼязані ресурси, ви можете видалити їх, дотримуючись цих кроків.
|
||||
|
|
@ -34,10 +35,10 @@ $ kubectl label namespace default istio.io/dataplane-mode-
|
|||
{{< text bash >}}
|
||||
$ kubectl delete httproute reviews
|
||||
$ kubectl delete authorizationpolicy productpage-viewer
|
||||
$ kubectl delete -f samples/curl/curl.yaml
|
||||
$ kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml
|
||||
$ kubectl delete -f samples/bookinfo/platform/kube/bookinfo-versions.yaml
|
||||
$ kubectl delete -f samples/bookinfo/gateway-api/bookinfo-gateway.yaml
|
||||
$ kubectl delete -f @samples/curl/curl.yaml@
|
||||
$ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo.yaml@
|
||||
$ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo-versions.yaml@
|
||||
$ kubectl delete -f @samples/bookinfo/gateway-api/bookinfo-gateway.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
## Видалення Istio {#uninstall-istio}
|
||||
|
|
|
|||
|
|
@ -4,6 +4,7 @@ description: Розротання демонстраційного застос
|
|||
weight: 2
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: yes
|
||||
prev: /docs/ambient/getting-started
|
||||
---
|
||||
|
||||
Щоб дослідити Istio, ви встановите демонстраційний [застосунок Bookinfo](/docs/examples/bookinfo/), що складається з чотирьох окремих мікросервісів, які використовуються для демонстрації різних функцій Istio.
|
||||
|
|
@ -17,8 +18,8 @@ test: yes
|
|||
Розпочніть з розгортання застосунку:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f {{< github_file >}}/samples/bookinfo/platform/kube/bookinfo.yaml
|
||||
$ kubectl apply -f {{< github_file >}}/samples/bookinfo/platform/kube/bookinfo-versions.yaml
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-versions.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Щоб перевірити, що застосунок працює, перевірте статус podʼів:
|
||||
|
|
@ -41,7 +42,7 @@ reviews-v3-7d99fd7978-dm6mx 1/1 Running 0 42s
|
|||
Ви будете використовувати Kubernetes Gateway API для розгортання шлюзу з назвою `bookinfo-gateway`:
|
||||
|
||||
{{< text syntax=bash snip_id=deploy_bookinfo_gateway >}}
|
||||
$ kubectl apply -f {{< github_file >}}/samples/bookinfo/gateway-api/bookinfo-gateway.yaml
|
||||
$ kubectl apply -f @samples/bookinfo/gateway-api/bookinfo-gateway.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Стандартно Istio створює сервіс `LoadBalancer` для шлюзу. Оскільки ми будемо отримувати доступ до цього шлюзу через тунель, нам не потрібен балансувальник навантаження. Змініть тип сервісу на `ClusterIP`, додавши анотацію до шлюзу:
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ $ kubectl apply -f - <<EOF
|
|||
apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: productpage-viewer
|
||||
name: productpage-ztunnel
|
||||
namespace: default
|
||||
spec:
|
||||
selector:
|
||||
|
|
@ -39,7 +39,7 @@ EOF
|
|||
Спробуйте отримати доступ до застосунку Bookinfo з іншого клієнта в кластері:
|
||||
|
||||
{{< text syntax=bash snip_id=deploy_curl >}}
|
||||
$ kubectl apply -f samples/curl/curl.yaml
|
||||
$ kubectl apply -f @samples/curl/curl.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Оскільки pod `curl` використовує інший службовий обліковий запис, він не матиме доступу до сервісу `productpage`:
|
||||
|
|
@ -74,7 +74,7 @@ $ kubectl apply -f - <<EOF
|
|||
apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: productpage-viewer
|
||||
name: productpage-waypoint
|
||||
namespace: default
|
||||
spec:
|
||||
targetRefs:
|
||||
|
|
@ -95,6 +95,29 @@ EOF
|
|||
|
||||
Зверніть увагу, що поле `targetRefs` використовується для вказання цільового сервісу для політики авторизації проксі waypoint. Розділ `rules` подібний до попереднього, але тепер ми додали розділ `to`, щоб вказати дозволену операцію.
|
||||
|
||||
Памʼятаєте, що наша політика L4 вказувала ztunnel дозволяти зʼєднання тільки зі шлюзу? Тепер нам потрібно оновити її, щоб дозволити зʼєднання і з waypoint.
|
||||
|
||||
{{< text syntax=bash snip_id=update_l4_policy >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: productpage-ztunnel
|
||||
namespace: default
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: productpage
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals:
|
||||
- cluster.local/ns/default/sa/bookinfo-gateway-istio
|
||||
- cluster.local/ns/default/sa/waypoint
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
{{< tip >}}
|
||||
Щоб дізнатися більше про те, як увімкнути інші функції Istio, прочитайте [посібник з використання функцій Layer 7](/docs/ambient/usage/l7-features/).
|
||||
{{< /tip >}}
|
||||
|
|
|
|||
|
|
@ -27,11 +27,11 @@ namespace/default labeled
|
|||
|
||||
## Візуалізація застосунку та метрик {#visualize-the-application-and-metrics}
|
||||
|
||||
Використовуючи панель інструментів Istio, Kiali та систему метрик Prometheus, ви можете візуалізувати застосунок Bookinfo. Розгорніть їх обидва:
|
||||
Використовуючи інфопанель Istio Kiali та систему метрик Prometheus, ви можете візуалізувати застосунок Bookinfo. Розгорніть їх обидва:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ kubectl apply -f {{< github_file >}}/samples/addons/prometheus.yaml
|
||||
$ kubectl apply -f {{< github_file >}}/samples/addons/kiali.yaml
|
||||
$ kubectl apply -f @samples/addons/prometheus.yaml@
|
||||
$ kubectl apply -f @samples/addons/kiali.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Ви можете отримати доступ до дашборду Kiali, запустивши наступну команду:
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Посібник зі встановлення Istio в режим
|
|||
weight: 5
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/install
|
||||
- /uk/latest/docs/ops/ambient/install
|
||||
- /latest/uk/docs/ops/ambient/install
|
||||
owner: istio/wg-environment-maintainers
|
||||
test: n/a
|
||||
list_below: yes
|
||||
|
|
|
|||
|
|
@ -0,0 +1,163 @@
|
|||
---
|
||||
title: Встановлення за допомогою Helm (просте)
|
||||
description: Встановлення Istio з підтримкою ambient mode за допомогою Helm, використовуючи єдиний чарт.
|
||||
weight: 4
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: yes
|
||||
draft: true
|
||||
---
|
||||
|
||||
{{< tip >}}
|
||||
Слідуйте цьому керівництву для встановлення та налаштування Istio mesh з підтримкою ambient mode. Якщо ви новачок в Istio і просто хочете спробувати його, дотримуйтесь інструкцій для [швидкого старту](/docs/ambient/getting-started) замість цього.
|
||||
{{< /tip >}}
|
||||
|
||||
Ми рекомендуємо використовувати Helm для встановлення Istio для промислового використання в ambient mode. Для контрольованих оновлень компоненти панелі управління та панелі даних упаковані та встановлюються окремо. (Оскільки панель даних ambient розділена на [два компоненти](/docs/ambient/architecture/data-plane), ztunnel та waypoints, оновлення включають окремі кроки для цих компонентів.)
|
||||
|
||||
## Передумови {#prerequisites}
|
||||
|
||||
1. Перевірте [Платформо-специфічні передумови](/docs/ambient/install/platform-prerequisites).
|
||||
|
||||
1. [Встановіть клієнт Helm](https://helm.sh/docs/intro/install/), версії 3.6 або вище.
|
||||
|
||||
1. Налаштуйте репозиторій Helm:
|
||||
|
||||
{{< text syntax=bash snip_id=configure_helm >}}
|
||||
$ helm repo add istio https://istio-release.storage.googleapis.com/charts
|
||||
$ helm repo update
|
||||
{{< /text >}}
|
||||
|
||||
<!-- ### Base components -->
|
||||
|
||||
<!-- The `base` chart contains the basic CRDs and cluster roles required to set up Istio. -->
|
||||
<!-- This should be installed prior to any other Istio component. -->
|
||||
|
||||
<!-- {{< text syntax=bash snip_id=install_base >}} -->
|
||||
<!-- $ helm install istio-base istio/base -n istio-system --create-namespace --wait -->
|
||||
<!-- {{< /text >}} -->
|
||||
|
||||
### Install or upgrade the Kubernetes Gateway API CRDs {#install-or-upgrade-the-kubernetes-gateway-api-crds}
|
||||
|
||||
{{< boilerplate gateway-api-install-crds >}}
|
||||
|
||||
### Встановлення панелі управління та панелі даних для Istio ambient {#install-the-isito-ambient-control-plane-and-data-plane}
|
||||
|
||||
Чарт `ambient` встановлює всі компоненти панелі даних та панелі управління Istio, необхідні для ambient, використовуючи Helm wrapper chart, який складається з чартів окремих компонентів.
|
||||
|
||||
{{< warning >}}
|
||||
Зверніть увагу, що якщо ви встановлюєте все як частину цього wrapper chart, ви можете оновлювати або видаляти ambient тільки через цей wrapper chart; ви не можете оновлювати або видаляти компоненти окремо.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text syntax=bash snip_id=install_ambient_aio >}}
|
||||
$ helm install istio-ambient istio/ambient --namespace istio-system --create-namespace --wait
|
||||
{{< /text >}}
|
||||
|
||||
### Вхідний шлюз (опціонально) {#ingress-gateway-optional}
|
||||
|
||||
{{< tip >}}
|
||||
{{< boilerplate gateway-api-future >}}
|
||||
Якщо ви використовуєте Gateway API, вам не потрібно встановлювати та керувати чартом вхідного шлюзу Helm, як описано нижче. Зверніться до [завдання Gateway API](/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment) за подробицями.
|
||||
{{< /tip >}}
|
||||
|
||||
Щоб встановити вхідний шлюз, виконайте наступну команду:
|
||||
|
||||
{{< text syntax=bash snip_id=install_ingress >}}
|
||||
$ helm install istio-ingress istio/gateway -n istio-ingress --create-namespace --wait
|
||||
{{< /text >}}
|
||||
|
||||
Якщо ваш кластер Kubernetes не підтримує тип сервісу `LoadBalancer` (`type: LoadBalancer`) з належним зовнішнім IP, виконайте команду вище без параметра `--wait`, щоб уникнути нескінченного очікування. Дивіться [Встановлення шлюзів](/docs/setup/additional-setup/gateway/) для детальної документації щодо встановлення шлюзів.
|
||||
|
||||
## Налаштування {#configuration}
|
||||
|
||||
Wrapper chart ambient складається з наступних чартів Helm компонентів:
|
||||
|
||||
- base
|
||||
- istiod
|
||||
- istio-cni
|
||||
- ztunnel
|
||||
|
||||
Значення стандартної конфігурації можна змінити, використовуючи один або більше аргументів `--set <parameter>=<value>`. Альтернативно, ви можете вказати кілька параметрів у файлі власних значень, використовуючи аргумент `--values <file>`.
|
||||
|
||||
Ви можете перевизначити налаштування на рівні компонентів через wrapper chart так само як і при встановленні компонентів окремо, додаючи префікс до шляху значення з назвою компонента.
|
||||
|
||||
Приклад:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ helm install istiod istio/istiod --set hub=gcr.io/istio-testing
|
||||
{{< /text >}}
|
||||
|
||||
Стає:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ helm install istio-ambient istio/ambient --set istiod.hub=gcr.io/istio-testing
|
||||
{{< /text >}}
|
||||
|
||||
при встановленні через wrapper chart.
|
||||
|
||||
Щоб переглянути підтримувані параметри конфігурації та документацію для кожного компонента, виконайте:
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ helm show values istio/istiod
|
||||
{{< /text >}}
|
||||
|
||||
для кожного компонента, який вас цікавить.
|
||||
|
||||
Повні деталі щодо використання та налаштування встановлень Helm доступні в [документації з встановлення sidecar](/docs/setup/install/helm/).
|
||||
|
||||
## Перевірка встановлення {#verify-the-installation}
|
||||
|
||||
### Перевірка статусу робочого навантаження {#verify-the-workload-status}
|
||||
|
||||
Після встановлення всіх компонентів ви можете перевірити статус розгортання Helm за допомогою:
|
||||
|
||||
{{< text syntax=bash snip_id=show_components >}}
|
||||
$ helm ls -n istio-system
|
||||
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
|
||||
istio-ambient istio-system 1 2024-04-17 22:14:45.964722028 +0000 UTC deployed ambient-{{< istio_full_version >}} {{< istio_full_version >}}
|
||||
{{< /text >}}
|
||||
|
||||
Ви можете перевірити статус розгорнутих podʼів за допомогою:
|
||||
|
||||
{{< text syntax=bash snip_id=check_pods >}}
|
||||
$ kubectl get pods -n istio-system
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
istio-cni-node-g97z5 1/1 Running 0 10m
|
||||
istiod-5f4c75464f-gskxf 1/1 Running 0 10m
|
||||
ztunnel-c2z4s 1/1 Running 0 10m
|
||||
{{< /text >}}
|
||||
|
||||
### Перевірка за допомогою демонстраційного застосунку {#verify-with-the-sample-application}
|
||||
|
||||
Після встановлення ambient mode за допомогою Helm, ви можете слідувати [керівництву з розгортання демонстраційного застосунку](/docs/ambient/getting-started/deploy-sample-app/), щоб розгорнути демонстраційний застосунок та вхідні шлюзи, а потім ви можете [додати ваш застосунок до ambient mesh](/docs/ambient/getting-started/secure-and-visualize/#add-bookinfo-to-the-mesh).
|
||||
|
||||
## Видалення {#uninstall}
|
||||
|
||||
Ви можете видалити Istio та його компоненти, видаливши чарт встановлений вище.
|
||||
|
||||
1. Видаліть всі компоненти Istio
|
||||
|
||||
{{< text syntax=bash snip_id=delete_ambient_aio >}}
|
||||
$ helm delete istio-ambient -n istio-system
|
||||
{{< /text >}}
|
||||
|
||||
1. (Опціонально) Видаліть будь-які встановлення чарту шлюзу Istio:
|
||||
|
||||
{{< text syntax=bash snip_id=delete_ingress >}}
|
||||
$ helm delete istio-ingress -n istio-ingress
|
||||
$ kubectl delete namespace istio-ingress
|
||||
{{< /text >}}
|
||||
|
||||
1. Видаліть CRD, встановлені Istio (опціонально)
|
||||
|
||||
{{< warning >}}
|
||||
Це видалить всі створені ресурси Istio.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text syntax=bash snip_id=delete_crds >}}
|
||||
$ kubectl get crd -oname | grep --color=never 'istio.io' | xargs kubectl delete
|
||||
{{< /text >}}
|
||||
|
||||
1. Видаліть простір імен `istio-system`:
|
||||
|
||||
{{< text syntax=bash snip_id=delete_system_namespace >}}
|
||||
$ kubectl delete namespace istio-system
|
||||
{{< /text >}}
|
||||
|
|
@ -4,9 +4,9 @@ description: Встановіть Istio з підтримкою режиму о
|
|||
weight: 4
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/install/helm-installation
|
||||
- /uk/latest/docs/ops/ambient/install/helm-installation
|
||||
- /latest/uk/docs/ops/ambient/install/helm-installation
|
||||
- /uk/docs/ambient/install/helm-installation
|
||||
- /uk/latest/docs/ambient/install/helm-installation
|
||||
- /latest/uk/docs/ambient/install/helm-installation
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: yes
|
||||
---
|
||||
|
|
@ -82,6 +82,11 @@ $ helm install ztunnel istio/ztunnel -n istio-system --wait
|
|||
|
||||
### Ingress gateway (додатково) {#ingress-gateway-optional}
|
||||
|
||||
{{< tip >}}
|
||||
{{< boilerplate gateway-api-future >}}
|
||||
Якщо ви використовуєте Gateway API, вам не потрібно встановлювати і керувати чартом Helm вхідного шлюзу, як описано нижче. Зверніться до [Завдання Gateway API](/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment) для отримання детальної інформації.
|
||||
{{< /tip >}}
|
||||
|
||||
Щоб встановити ingress gateway, виконайте команду нижче:
|
||||
|
||||
{{< text syntax=bash snip_id=install_ingress >}}
|
||||
|
|
@ -193,3 +198,40 @@ ztunnel-c2z4s 1/1 Running 0 10m
|
|||
{{< text syntax=bash snip_id=delete_system_namespace >}}
|
||||
$ kubectl delete namespace istio-system
|
||||
{{< /text >}}
|
||||
|
||||
## Генерація маніфесту перед встановленням {#generate-a-manifest-before-installation}
|
||||
|
||||
Ви можете згенерувати маніфести для кожного компонента перед встановленням Istio, використовуючи команду `helm template`. Наприклад, щоб згенерувати маніфест, який можна встановити за допомогою `kubectl` для компонента `istiod`:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ helm template istiod istio/istiod -n istio-system --kube-version {версія Kubernetes цільового кластера} > istiod.yaml
|
||||
{{< /text >}}
|
||||
|
||||
Згенерований маніфест можна використовувати для перевірки того, що саме встановлюється, а також для відстеження змін у маніфесті з часом.
|
||||
|
||||
{{< tip >}}
|
||||
Будь-які додаткові прапорці або перевизначення значень, які ви зазвичай використовуєте для встановлення, також повинні бути передані команді `helm template`.
|
||||
{{< /tip >}}
|
||||
|
||||
Щоб встановити маніфест, згенерований вище, який створить компонент `istiod` у цільовому кластері:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ kubectl apply -f istiod.yaml
|
||||
{{< /text >}}
|
||||
|
||||
{{< warning >}}
|
||||
Якщо ви намагаєтеся встановити та керувати Istio за допомогою `helm template`, зверніть увагу на наступні застереження:
|
||||
|
||||
1. Простір імен Istio (стандартно `istio-system`) повинен бути створений вручну.
|
||||
|
||||
1. Ресурси можуть не встановлюватися з тією ж послідовністю залежностей, як `helm install`.
|
||||
|
||||
1. Цей метод не тестується як частина випусків Istio.
|
||||
|
||||
1. Хоча `helm install` автоматично виявляє налаштування середовища з вашого контексту Kubernetes, `helm template` не може це робити, оскільки він працює офлайн, що може призвести до несподіваних результатів. Зокрема, ви повинні переконатися, що ви дотримуєтеся [цих кроків](/docs/ops/best-practices/security/#configure-third-party-service-account-tokens), якщо ваше середовище Kubernetes не підтримує токени сторонніх службових облікових записів.
|
||||
|
||||
1. Виконання `kubectl apply` для згенерованого маніфесту може показувати тимчасові помилки через те, що ресурси не доступні в кластері в правильному порядку.
|
||||
|
||||
1. `helm install` автоматично видаляє будь-які ресурси, які повинні бути видалені при зміні конфігурації (наприклад, якщо ви видаляєте шлюз). Це не відбувається, коли ви використовуєте `helm template` з `kubectl`, і ці ресурси повинні бути видалені вручну.
|
||||
|
||||
{{< /warning >}}
|
||||
|
|
|
|||
|
|
@ -70,3 +70,40 @@ $ istioctl uninstall <ваші оригінальні параметри уст
|
|||
{{< text syntax=bash snip_id=remove_namespace >}}
|
||||
$ kubectl delete namespace istio-system
|
||||
{{< /text >}}
|
||||
|
||||
## Генерація маніфесту перед встановленням {#generate-a-manifest-before-installation}
|
||||
|
||||
Ви можете згенерувати маніфест перед встановленням Istio, використовуючи команду `manifest generate`. Наприклад, використовуйте наступну команду, щоб згенерувати маніфест для профілю `default`, який можна встановити за допомогою `kubectl`:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ istioctl manifest generate > $HOME/generated-manifest.yaml
|
||||
{{< /text >}}
|
||||
|
||||
Згенерований маніфест можна використовувати для перевірки того, що саме встановлюється, а також для відстеження змін у маніфесті з часом. Хоча CR `IstioOperator` представляє повну конфігурацію користувача і є достатнім для її відстеження, вихідні дані з `manifest generate` також фіксують можливі зміни в основних чартах і тому можуть бути використані для відстеження фактично встановлених ресурсів.
|
||||
|
||||
{{< tip >}}
|
||||
Будь-які додаткові прапорці або перевизначення значень, які ви зазвичай використовуєте для встановлення, також повинні бути передані команді `istioctl manifest generate`.
|
||||
{{< /tip >}}
|
||||
|
||||
{{< warning >}}
|
||||
Якщо ви намагаєтеся встановити та керувати Istio за допомогою `istioctl manifest generate`, зверніть увагу на наступні застереження:
|
||||
|
||||
1. Простір імен Istio (стандартно `istio-system`) повинен бути створений вручну.
|
||||
|
||||
2. Валідація Istio не буде стандартно увімкнена. На відміну від `istioctl install`, команда `manifest generate` не створить конфігурацію вебхука валідації`istiod-default-validator`, якщо не встановлено `values.defaultRevision`:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ istioctl manifest generate --set values.defaultRevision=default
|
||||
{{< /text >}}
|
||||
|
||||
1. Ресурси можуть не встановлюватися з тією ж послідовністю залежностей, як `istioctl install`.
|
||||
|
||||
1. Цей метод не тестується як частина випусків Istio.
|
||||
|
||||
1. Хоча `istioctl install` автоматично виявляє налаштування середовища з вашого контексту Kubernetes, `manifest generate` не може це робити, оскільки він працює офлайн, що може призвести до несподіваних результатів. Зокрема, ви повинні переконатися, що ви дотримуєтеся [цих кроків](/docs/ops/best-practices/security/#configure-third-party-service-account-tokens), якщо ваше середовище Kubernetes не підтримує токени сторонніх службових облікових записів. Рекомендується додати `--cluster-specific` до вашої команди `istio manifest generate`, щоб виявити середовище цільового кластера, що вбудує ці налаштування середовища кластера в згенеровані маніфести. Це вимагає мережевого доступу до вашого працюючого кластера.
|
||||
|
||||
1. Виконання `kubectl apply` для згенерованого маніфесту може показувати тимчасові помилки через те, що ресурси не доступні в кластері в правильному порядку.
|
||||
|
||||
1. `istioctl install` автоматично видаляє будь-які ресурси, які повинні бути видалені при зміні конфігурації (наприклад, якщо ви видаляєте шлюз). Це не відбувається, коли ви використовуєте `istio manifest generate` з `kubectl`, і ці ресурси повинні бути видалені вручну.
|
||||
|
||||
{{< /warning >}}
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Передумови для встановлення Istio в ре
|
|||
weight: 2
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/install/platform-prerequisites
|
||||
- /uk/latest/docs/ops/ambient/install/platform-prerequisites
|
||||
- /latest/uk/docs/ops/ambient/install/platform-prerequisites
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: no
|
||||
---
|
||||
|
|
@ -17,7 +17,9 @@ test: no
|
|||
|
||||
### Google Kubernetes Engine (GKE) {#google-kubernetes-engine-gke}
|
||||
|
||||
У GKE компоненти Istio з `priorityClassName` [system-node-critical](https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) можуть бути встановлені лише в просторах імен, в яких визначено [ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/). Стандартно у GKE лише `kube-system` має визначений ResourceQuota для класу `node-critical`. Історичний агент CNI та `ztunnel` обидва потребують класу `node-critical`, тому в GKE обидва компоненти повинні бути:
|
||||
#### Обмеження простору імен {#namespace-restrictions}
|
||||
|
||||
У GKE будь-які podʼи з `priorityClassName` [system-node-critical](https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) можуть бути встановлені лише в просторах імен, в яких визначено [ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/). Стандартно у GKE лише `kube-system` має визначений ResourceQuota для класу `node-critical`. Історичний агент CNI та `ztunnel` обидва потребують класу `node-critical`, тому в GKE обидва компоненти повинні бути:
|
||||
|
||||
- Встановлені в `kube-system` (_не_ в `istio-system`)
|
||||
- Встановлені в інший простір імен (наприклад, `istio-system`), в якому вручну створено ResourceQuota, наприклад:
|
||||
|
|
@ -39,7 +41,31 @@ spec:
|
|||
- system-node-critical
|
||||
{{< /text >}}
|
||||
|
||||
### Amazon Elastic Kubernetes Service (EKS)
|
||||
#### Профіль платформи {#platform-profile}
|
||||
|
||||
Під час використання GKE ви повинні додавати правильне значення `platform` до команд встановлення, оскільки GKE використовує нестандартне розташування двійкових файлів CNI, що вимагає перевизначення змінних в Helm.
|
||||
|
||||
{{< tabset category-name="install-method" >}}
|
||||
|
||||
{{< tab name="Helm" category-value="helm" >}}
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ helm install istio-cni istio/cni -n istio-system --set profile=ambient --set global.platform=gke --wait
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="istioctl" category-value="istioctl" >}}
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ istioctl install --set profile=ambient --set values.global.platform=gke
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
### Amazon Elastic Kubernetes Service (EKS) {#amazon-elastic-kubernetes-service-eks}
|
||||
|
||||
Якщо ви використовуєте EKS:
|
||||
|
||||
|
|
@ -47,7 +73,9 @@ spec:
|
|||
- з увімкненим Pod ENI trunking
|
||||
- **та** використовуєте прикріплені до подів SecurityGroups через [SecurityGroupPolicy](https://aws.github.io/aws-eks-best-practices/networking/sgpp/#enforcing-mode-use-strict-mode-for-isolating-pod-and-node-traffic)
|
||||
|
||||
[`POD_SECURITY_GROUP_ENFORCING_MODE` має бути явно встановлено в значення `standard`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md#pod_security_group_enforcing_mode-v1110), інакше проби справності подів (які за стандартно автоматично виключені з політики VPC CNI) будуть провалені. Це повʼязано з тим, що Istio використовує локальну SNAT-адресу для проб справності kubelet, яку Amazon VPC CNI не розпізнає, а VPC CNI не має опції для виключення локальних адрес з політики.
|
||||
[`POD_SECURITY_GROUP_ENFORCING_MODE` має бути явно встановлено у `standard`](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md#pod_security_group_enforcing_mode-v1110), інакше перевірка стану podʼів не вдасться. Це тому, що Istio використовує локальну SNAT-адресу для ідентифікації перевірок стану kubelet, а VPC CNI наразі неправильно маршрутизує локальні пакети в режимі `strict` Pod Security Group. Явне додавання виключення CIDR для локальної адреси до вашої SecurityGroup не працюватиме, оскільки режим Pod Security Group VPC CNI працює шляхом тихої маршрутизації трафіку через зʼєднання, пропускаючи їх через trunked `pod ENI` для забезпечення політики SecurityGroup. Оскільки [локальний трафік не маршрутизується через зʼєднання](https://datatracker.ietf.org/doc/html/rfc3927#section-2.6.2), функція Pod Security Group не може забезпечити політику для них як обмеження дизайну і відкидає пакети в режимі `strict`.
|
||||
|
||||
Існує [відкритий тікет в компоненті VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s/issues/2797) для цього обмеження. Поточна рекомендація від команди VPC CNI — вимкнути режим `strict`, щоб обійти це, якщо ви використовуєте Pod Security Groups, або використовувати Kubernetes перевірки на основі `exec` для ваших podʼів замість перевірок на основі kubelet.
|
||||
|
||||
Ви можете перевірити, чи увімкнено pod ENI trunking, виконавши наступну команду:
|
||||
|
||||
|
|
@ -145,7 +173,7 @@ $ kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING
|
|||
|
||||
{{< /tabset >}}
|
||||
|
||||
### MicroK8s
|
||||
### MicroK8s {#microk8s}
|
||||
|
||||
Якщо ви встановлюєте Istio на [MicroK8s](https://microk8s.io/), вам потрібно додати коректне значення `platform` до вашої команди встановлення, оскільки MicroK8s [використовує нестандартні розташування для конфігурації CNI та двійкових файлів](https://microk8s.io/docs/change-cidr). Наприклад:
|
||||
|
||||
|
|
@ -170,7 +198,7 @@ $ kubectl set env daemonset aws-node -n kube-system POD_SECURITY_GROUP_ENFORCING
|
|||
|
||||
{{< /tabset >}}
|
||||
|
||||
### minikube
|
||||
### minikube {#minikube}
|
||||
|
||||
Якщо ви використовуєте [minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/) з [Docker-драйвером](https://minikube.sigs.k8s.io/docs/drivers/docker/), вам потрібно додати коректне значення `platform` до вашої команди встановлення, оскільки minikube з Docker використовує нестандартні привʼязки монтування шляхів для контейнерів. Наприклад:
|
||||
|
||||
|
|
@ -211,7 +239,7 @@ OpenShift вимагає, щоб компоненти `ztunnel` та `istio-cni`
|
|||
На додачу, ви маєте встановити `istio-cni` та `ztunnel` в простір імен `kube-system`, наприклад:
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ helm install istio-cni istio/istio-cni -n kube-system --set profile=ambient --set global.platform=openshift --wait
|
||||
$ helm install istio-cni istio/-cni -n kube-system --set profile=ambient --set global.platform=openshift --wait
|
||||
$ helm install ztunnel istio/ztunnel -n kube-system --set profile=ambient --set global.platform=openshift --wait
|
||||
{{< /text >}}
|
||||
|
||||
|
|
@ -231,7 +259,7 @@ OpenShift вимагає, щоб компоненти `ztunnel` та `istio-cni`
|
|||
|
||||
Наведені нижче конфігурації застосовуються до всіх платформ, якщо використовуються певні {{< gloss "CNI" >}}втулки CNI{{< /gloss >}}:
|
||||
|
||||
### Cilium
|
||||
### Cilium {#cilium}
|
||||
|
||||
1. Cilium наразі стандартно проактивно видаляє інші втулки CNI та їх конфігурацію, і його потрібно налаштувати з `cni.exclusive = false`, щоб правильно підтримувати ланцюжки. Див. [документацію Cilium](https://docs.cilium.io/en/stable/helm-reference/) для більш детальної інформації.
|
||||
2. BPF маскування в Cilium наразі стандартно вимкнено і має проблеми з використанням локальних IP-адрес Istio для перевірки справності Kubernetes. Увімкнення BPF маскування через `bpf.masquerade=true` наразі не підтримується і призводить до того, що в Istio ambient зʼявляються нефункціональні перевірки стану справності podʼів. Стандартна реалізація маскування iptables Cilium повинна продовжувати функціонувати правильно.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Посібники з оновлення для Istio в режим
|
|||
weight: 10
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/upgrade
|
||||
- /uk/latest/docs/ops/ambient/upgrade
|
||||
- /latest/uk/docs/ops/ambient/upgrade
|
||||
owner: istio/wg-environment-maintainers
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
|||
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
title: Оновлення за допомогою Helm (просте)
|
||||
description: Оновлення інсталяції в режимі ambient за допомогою Helm з використанням одного чарту
|
||||
weight: 5
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: yes
|
||||
draft: true
|
||||
---
|
||||
|
||||
Слідуйте цьому керівництву, щоб оновити та налаштувати інсталяцію в режимі ambient за допомогою [Helm](https://helm.sh/docs/). Це керівництво передбачає, що ви вже виконали [встановлення в режимі ambient за допомогою Helm та чарту обгортки ambient](/docs/ambient/install/helm/all-in-one) з попередньою версією Istio.
|
||||
|
||||
{{< warning >}}
|
||||
Зверніть увагу, що ці інструкції з оновлення застосовуються лише у випадку, якщо ви оновлюєте інсталяцію Helm, створену за допомогою чарту обгортки ambient. Якщо ви встановили за допомогою окремих компонентних чартів Helm, дивіться [відповідні документи з оновлення](docs/ambient/upgrade/helm)
|
||||
{{< /warning >}}
|
||||
|
||||
## Розуміння оновлень в режимі ambient {#understanding-ambient-mode-upgrades}
|
||||
|
||||
{{< warning >}}
|
||||
Зверніть увагу, що якщо ви встановлюєте все як частину цього чарту обгортки, ви можете лише оновити або видалити ambient за допомогою цього чарту обгортки; ви не можете оновити або видалити компоненти окремо.
|
||||
{{< /warning >}}
|
||||
|
||||
## Передумови {#prerequisites}
|
||||
|
||||
### Підготовка до оновлення {#prepare-for-the-upgrade}
|
||||
|
||||
Перед оновленням Istio ми рекомендуємо завантажити нову версію istioctl та запустити `istioctl x precheck`, щоб переконатися, що оновлення сумісне з вашим середовищем. Вивід повинен виглядати приблизно так:
|
||||
|
||||
{{< text syntax=bash snip_id=istioctl_precheck >}}
|
||||
$ istioctl x precheck
|
||||
✔ No issues found when checking the cluster. Istio is safe to install or upgrade!
|
||||
To get started, check out <https://istio.io/latest/docs/setup/getting-started/>
|
||||
{{< /text >}}
|
||||
|
||||
Тепер оновіть репозиторій Helm:
|
||||
|
||||
{{< text syntax=bash snip_id=update_helm >}}
|
||||
$ helm repo update istio
|
||||
{{< /text >}}
|
||||
|
||||
### Оновлення панелі управління та панелі даних Istio в режимі ambient {#upgrade-the-istio-ambient-control-plane-and-data-plane}
|
||||
|
||||
{{< warning >}}
|
||||
Оновлення за допомогою чарту обгортки на місці короткочасно порушить весь трафік в ambient mesh на вузлі, **навіть з використанням ревізій**. На практиці період порушення є дуже коротким вікном, що в основному впливає на довготривалі зʼєднання.
|
||||
|
||||
Рекомендується використовувати кордонування вузлів та синьо-зелені пули вузлів для зменшення ризику під час оновлень у промисловому середовищі. Дивіться документацію вашого постачальника Kubernetes для деталей.
|
||||
{{< /warning >}}
|
||||
|
||||
Чарт `ambient` оновлює всі компоненти панелі даних та панелі управління Istio, необхідні для ambient, використовуючи чарт обгортку Helm, який складається з окремих чартів компонентів.
|
||||
|
||||
Якщо ви налаштували свою інсталяцію istiod, ви можете повторно використовувати файл `values.yaml` з попередніх оновлень або інсталяцій, щоб зберегти налаштування.
|
||||
|
||||
{{< text syntax=bash snip_id=upgrade_ambient_aio >}}
|
||||
$ helm upgrade istio-ambient istio/ambient -n istio-system --wait
|
||||
{{< /text >}}
|
||||
|
||||
### Оновлення вручну розгорнутого чарту шлюзу (опціонально) {#upgrade-manually-deployed-gateway-chart}
|
||||
|
||||
`Gateway`, які були [розгорнуті вручну](/docs/tasks/traffic-management/ingress/gateway-api/#manual-deployment), повинні бути оновлені окремо за допомогою Helm:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ helm upgrade istio-ingress istio/gateway -n istio-ingress
|
||||
{{< /text >}}
|
||||
|
|
@ -4,9 +4,9 @@ description: Модернізація встановлення в режимі
|
|||
weight: 5
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/upgrade/helm-upgrade
|
||||
- /uk/latest/docs/ops/ambient/upgrade/helm-upgrade
|
||||
- /latest/uk/docs/ops/ambient/upgrade/helm-upgrade
|
||||
- /uk/docs/ambient/upgrade/helm
|
||||
- /uk/latest/docs/ambient/upgrade/helm
|
||||
- /latest/uk/docs/ambient/upgrade/helm
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: yes
|
||||
---
|
||||
|
|
@ -121,9 +121,9 @@ $ helm install istiod-"$REVISION" istio/istiod -n istio-system --set revision="$
|
|||
CNI версії 1.x сумісний із панеллю управління версії 1.x+1 і 1.x. Це означає, що спочатку потрібно оновити панелі управління перед оновленням Istio CNI, якщо різниця між їхніми версіями не перевищує одну мінорну версію.
|
||||
|
||||
{{< warning >}}
|
||||
Istio зараз не підтримує канаркове оновлення istio-cni, **навіть з використанням ревізій**
|
||||
Istio зараз не підтримує канаркове оновлення istio-cni, **навіть з використанням ревізій**. Якщо це є значною проблемою для вашого середовища, або потрібен суворіший контроль за радіусом впливу під час оновлень CNI, рекомендується відкласти оновлення `istio-cni` до тих пір, поки вузли не будуть очищені та оновлені, або використовувати taints вузлів і вручну оркеструвати оновлення цього компонента.
|
||||
|
||||
Оновлення агента вузла Istio CNI до сумісної версії на місці не призведе до порушення роботи мережі для вже успішно доданих до ambient мережі podʼів, але не слід планувати додавання нових podʼів на вузол, поки оновлення не буде завершено та оновлений агент Istio CNI на вузлі не пройде перевірку готовності. Якщо це може спричинити значні перебої, або якщо потрібен суворіший контроль над зоною впливу під час оновлення CNI, рекомендується застосувати taints вузла та/або cordons вузла.
|
||||
Агент вузла Istio CNI є [system-node-critical](https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) DaemonSet. Він **повинен** працювати на кожному вузлі, щоб забезпечити безпеку трафіку та операційні гарантії Istio на цьому вузлі. Стандартно, DaemonSet агента вузла Istio CNI підтримує безпечні оновлення на місці, і під час оновлення або перезапуску запобігає запуску нових podʼів на цьому вузлі, поки екземпляр агента не буде доступний на вузлі для їх обробки, щоб запобігти витоку незахищеного трафіку. Наявні podʼи, які вже були успішно додані до ambient mesh до оновлення, продовжуватимуть працювати відповідно до вимог безпеки трафіку Istio під час оновлення.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text syntax=bash snip_id=upgrade_cni >}}
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Як налаштувати сервісну мережу для в
|
|||
weight: 15
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/usage
|
||||
- /uk/latest/docs/ops/ambient/usage
|
||||
- /latest/uk/docs/ops/ambient/usage
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
|||
|
|
@ -56,12 +56,11 @@ Ztunnel не може забезпечувати політики L7. Якщо
|
|||
|
||||
## Розширення {#extension}
|
||||
|
||||
Оскільки waypoint-проксі є розгортанням {{< gloss >}}Envoy{{< /gloss >}}, механізми розширення, доступні для Envoy у {{< gloss "sidecar">}}режимі sidecar{{< /gloss >}}, також доступні для waypoint-проксі.
|
||||
Оскільки waypoint-проксі є розгортанням {{< gloss >}}Envoy{{< /gloss >}}, деякі механізми розширення, доступні для Envoy у {{< gloss "sidecar">}}режимі sidecar{{< /gloss >}}, також доступні для waypoint-проксі.
|
||||
|
||||
| Назва | Статус функції | Привʼязка |
|
||||
| --- | --- | --- |
|
||||
| `WasmPlugin` † | Альфа | `targetRefs` |
|
||||
| `EnvoyFilter` | Альфа | `targetRefs` |
|
||||
|
||||
† [Детальніше про те, як розширити waypoint за допомогою WebAssembly втулків](/docs/ambient/usage/extend-waypoint-wasm/).
|
||||
|
||||
|
|
|
|||
|
|
@ -23,14 +23,16 @@ Kubernetes [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networki
|
|||
{{< text syntax=yaml snip_id=none >}}
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: my-app-allow-ingress-web
|
||||
spec:
|
||||
ingress:
|
||||
- ports:
|
||||
- port: 9090
|
||||
protocol: TCP
|
||||
podSelector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: my-app
|
||||
ingress:
|
||||
- ports:
|
||||
- port: 8080
|
||||
protocol: TCP
|
||||
{{< /text >}}
|
||||
|
||||
і його слід змінити на
|
||||
|
|
@ -38,16 +40,18 @@ spec:
|
|||
{{< text syntax=yaml snip_id=none >}}
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: my-app-allow-ingress-web
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: my-app
|
||||
ingress:
|
||||
- ports:
|
||||
- port: 8080
|
||||
protocol: TCP
|
||||
- port: 15008
|
||||
protocol: TCP
|
||||
podSelector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: my-app
|
||||
{{< /text >}}
|
||||
|
||||
якщо `my-app` доданий до ambient mesh.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Отримайте повний набір функцій Istio з
|
|||
weight: 30
|
||||
aliases:
|
||||
- /uk/docs/ops/ambient/usage/waypoint
|
||||
- /uk/latest/docs/ops/ambient/usage/waypoint
|
||||
- /latest/uk/docs/ops/ambient/usage/waypoint
|
||||
owner: istio/wg-networking-maintainers
|
||||
test: yes
|
||||
---
|
||||
|
|
@ -67,7 +67,7 @@ spec:
|
|||
protocol: HBONE
|
||||
{{< /text >}}
|
||||
|
||||
Зверніть увагу, що ресурс Gateway має мітку `istio-waypoint`, встановлену на `gatewayClassName`, що вказує на те, що це waypoint, надано Istio. Ресурс Gateway позначений міткою `istio.io/waypoint-for: service`, що вказує на те, що waypoint може обробляти трафік для сервісів, що є стандартним налаштуванням.
|
||||
Зверніть увагу, що ресурс Gateway має `gatewayClassName` з `istio-waypoint`, який є екземпляром waypoint, керованого Istio. Ресурс Gateway позначено як `istio.io/waypoint-for: service`, що вказує на те, що waypoint може обробляти трафік для сервісів, що є стандартним значенням.
|
||||
|
||||
Для безпосереднього розгортання waypoint-проксі використовуйте `apply` замість `generate`:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: Додавання нової версії відгуків
|
||||
overview: Розгорніть нову версію мікросервісу.
|
||||
|
||||
weight: 50
|
||||
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: no
|
||||
---
|
||||
|
|
|
|||
|
|
@ -68,6 +68,7 @@ Istio надає широкі функціональні можливості з
|
|||
|----|----|----|----|
|
||||
| 15000 | TCP | Адмін-порт Envoy (команди/діагностика) | Так |
|
||||
| 15001 | TCP | Вихідний трафік Envoy | Ні |
|
||||
| 15002 | TCP | Порт прослуховування для виявлення збоїв | Yes |
|
||||
| 15004 | HTTP | Порт налагодження | Так |
|
||||
| 15006 | TCP | Вхідний трафік Envoy | Ні |
|
||||
| 15008 | HTTP2 | Порт тунелю {{< gloss >}}HBONE{{</ gloss >}} mTLS | Ні |
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ aliases:
|
|||
- /uk/bugs/index.html
|
||||
- /uk/help/bugs/
|
||||
- /uk/about/bugs
|
||||
- /uk/latest/about/bugs
|
||||
- /latest/uk/about/bugs
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ aliases:
|
|||
- /uk/about/contribute/creating-and-editing-pages
|
||||
- /uk/create
|
||||
- /uk/about/contribute
|
||||
- /uk/latest/about/contribute
|
||||
- /latest/uk/about/contribute
|
||||
keywords: [contribute, github, docs, shortcodes, code-blocks, website]
|
||||
list_below: true
|
||||
owner: istio/wg-docs-maintainers
|
||||
|
|
@ -26,4 +26,4 @@ test: n/a
|
|||
- Переклад португальською мовою (Бразилія) знаходиться в теці `pt-br`.
|
||||
- Переклад українською знаходиться в теці `uk`.
|
||||
|
||||
Дізнайтеся більше у наступних посібниках:
|
||||
Дізнайтеся більше у наступних посібниках:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ aliases:
|
|||
- /uk/about/contribute/writing-a-new-topic.html
|
||||
- /uk/create
|
||||
- /uk/about/contribute/add-content
|
||||
- /uk/latest/about/contribute/add-content
|
||||
- /latest/uk/about/contribute/add-content
|
||||
keywords: [contribute]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Пояснює, як локально побудувати, про
|
|||
weight: 5
|
||||
aliases:
|
||||
- /uk/about/contribute/build
|
||||
- /uk/latest/about/contribute/build
|
||||
- /latest/uk/about/contribute/build
|
||||
keywords: [внесок, обслуговування, Docker, Hugo, побудова]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Пояснює, як включати код у вашу докум
|
|||
weight: 8
|
||||
aliases:
|
||||
- /uk/about/contribute/code-blocks
|
||||
- /uk/latest/about/contribute/code-blocks
|
||||
- /latest/uk/about/contribute/code-blocks
|
||||
keywords: [внесок, документація, посібник, блоки-коду]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Надає ресурси та інструкції для ство
|
|||
weight: 13
|
||||
aliases:
|
||||
- /uk/about/contribute/diagrams
|
||||
- /uk/latest/about/contribute/diagrams
|
||||
- /latest/uk/about/contribute/diagrams
|
||||
keywords: [contribute, diagram, documentation, guide]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Пояснює стандартну розмітку, що вико
|
|||
weight: 10
|
||||
aliases:
|
||||
- /uk/about/contribute/formatting
|
||||
- /uk/latest/about/contribute/formatting
|
||||
- /latest/uk/about/contribute/formatting
|
||||
keywords: [contribute]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Пояснює front matter, що використовується
|
|||
weight: 6
|
||||
aliases:
|
||||
- /uk/about/contribute/front-matter
|
||||
- /uk/latest/about/contribute/front-matter
|
||||
- /latest/uk/about/contribute/front-matter
|
||||
keywords: [metadata,navigation,table-of-contents]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ aliases:
|
|||
- /uk/about/contribute/editing
|
||||
- /uk/about/contribute/staging-your-changes
|
||||
- /uk/about/contribute/github
|
||||
- /uk/latest/about/contribute/github
|
||||
- /latest/uk/about/contribute/github
|
||||
keywords: [contribute,community,github,pr]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Деталі про те, як видалити застарілу
|
|||
weight: 4
|
||||
aliases:
|
||||
- /uk/about/contribute/remove-content
|
||||
- /uk/latest/about/contribute/remove-content
|
||||
- /latest/uk/about/contribute/remove-content
|
||||
keywords: [внесок]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Показує, як зміни до документації та
|
|||
weight: 7
|
||||
aliases:
|
||||
- /uk/about/contribute/review
|
||||
- /uk/latest/about/contribute/review
|
||||
- /latest/uk/about/contribute/review
|
||||
keywords: [contribute,community,github,pr,documentation,review, approval]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ aliases:
|
|||
- /uk/about/contribute/writing-a-new-topic.html
|
||||
- /uk/create
|
||||
- /uk/about/contribute/shortcodes
|
||||
- /uk/latest/about/contribute/shortcodes
|
||||
- /latest/uk/about/contribute/shortcodes
|
||||
keywords: [contribute]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ aliases:
|
|||
- /uk/docs/welcome/contribute/style-guide.html
|
||||
- /uk/docs/reference/contribute/style-guide.html
|
||||
- /uk/about/contribute/style-guide
|
||||
- /uk/latest/about/contribute/style-guide
|
||||
- /latest/uk/about/contribute/style-guide
|
||||
keywords: [contribute]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ aliases:
|
|||
- /uk/docs/welcome/contribute/style-guide.html
|
||||
- /uk/docs/reference/contribute/style-guide.html
|
||||
- /uk/about/contribute/terminology
|
||||
- /uk/latest/about/contribute/terminology
|
||||
- /latest/uk/about/contribute/terminology
|
||||
keywords: [contribute, documentation, guide, code-block]
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ aliases:
|
|||
- /uk/docs/welcome/feature-stages.html
|
||||
- /uk/docs/home/roadmap.html
|
||||
- /uk/about/feature-stages
|
||||
- /uk/latest/about/feature-stages
|
||||
- /latest/uk/about/feature-stages
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Список останніх змін на цьому вебсай
|
|||
weight: 110
|
||||
aliases:
|
||||
- /uk/about/log
|
||||
- /uk/latest/about/log
|
||||
- /latest/uk/about/log
|
||||
skip_seealso: true
|
||||
skip_byline: true
|
||||
owner: istio/wg-docs-maintainers
|
||||
|
|
@ -13,4 +13,4 @@ test: n/a
|
|||
|
||||
Ця сторінка показує вам найостанніші зміни в контенті цього вебсайту.
|
||||
|
||||
{{< change_log >}}
|
||||
{{< change_log >}}
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Як ми обробляємо вразливості безпек
|
|||
weight: 35
|
||||
aliases:
|
||||
- /uk/about/security-vulnerabilities
|
||||
- /uk/latest/about/security-vulnerabilities
|
||||
- /latest/uk/about/security-vulnerabilities
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Поточні підтримувані релізи Istio.
|
|||
weight: 36
|
||||
aliases:
|
||||
- /uk/about/supported-releases
|
||||
- /uk/latest/about/supported-releases
|
||||
- /latest/uk/about/supported-releases
|
||||
owner: istio/wg-docs-maintainers
|
||||
test: n/a
|
||||
---
|
||||
|
|
|
|||
|
|
@ -9,9 +9,58 @@ owner: istio/wg-environments-maintainers
|
|||
test: n/a
|
||||
---
|
||||
|
||||
Ця сторінка описує вбудовані конфігураційні профілі, які можна використовувати під час [встановлення Istio](/docs/setup/install/istioctl/). Профілі надають можливість налаштування панелі управління Istio та sidecarʼів для панелі даних Istio.
|
||||
Ця сторінка описує вбудовані конфігураційні профілі, які можна використовувати для [встановлення Istio](/docs/setup/install).
|
||||
|
||||
Ви можете почати з одного з [вбудованих конфігураційних профілів Istio]({{< github_tree >}}/manifests/profiles), а потім додатково [налаштувати конфігурацію](/docs/setup/additional-setup/customize-installation/) відповідно до ваших специфічних потреб. Зараз доступні такі вбудовані конфігураційні профілі:
|
||||
Конфігураційні профілі — це просто іменовані групи перевизначень значень чартів Helm, які вбудовані в чарти та можуть бути використані при встановленні з `helm` або `istioctl`.
|
||||
|
||||
Профілі забезпечують високий рівень налаштування панелі управління та панелі даних Istio для загальних топологій розгортання та цільових платформ.
|
||||
|
||||
{{< tip >}}
|
||||
Конфігураційні профілі поєднуються з іншими перевизначеннями значень або прапорцями, тому будь-яке окреме значення, встановлене конфігураційним профілем, може бути вручну перевизначене шляхом вказівки прапорця `--set` після нього в команді.
|
||||
{{< /tip >}}
|
||||
|
||||
Існує 2 види конфігураційних профілів: _профілі розгортання_ та _профілі платформи_, і рекомендується використовувати обидва.
|
||||
|
||||
- _профілі розгортання_ призначені для забезпечення гартних стандартних значень для даної топології розгортання (`default`, `remote`, `ambient` тощо).
|
||||
- _профілі платформи_ призначені для забезпечення необхідних стандартних значень для даної цільової платформи (`eks`, `gke`, `openshift` тощо).
|
||||
|
||||
Наприклад, якщо ви встановлюєте `default` sidecar dataplane на GKE, ми рекомендуємо використовувати наступні профілі розгортання та платформи для початку:
|
||||
|
||||
{{< tabset category-name="install-method" >}}
|
||||
|
||||
{{< tab name="Helm" category-value="helm" >}}
|
||||
|
||||
Для Helm, вкажіть той самий `profile` та `platform` для кожного чарту, який ви встановлюєте, наприклад `istiod`:
|
||||
|
||||
{{< text syntax=bash snip_id=install_istiod_helm_platform >}}
|
||||
$ helm install istiod istio/istiod -n istio-system --set profile=default --set global.platform=gke --wait
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab name="istioctl" category-value="istioctl" >}}
|
||||
|
||||
Для `istioctl`, вкажіть той самий `profile` та `platform` як аргументи:
|
||||
|
||||
{{< text syntax=bash snip_id=install_istiod_istioctl_platform >}}
|
||||
$ istioctl install --set profile=default --set values.global.platform=gke
|
||||
{{< /text >}}
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabset >}}
|
||||
|
||||
{{< warning >}}
|
||||
Зверніть увагу, що ключова різниця між механізмами встановлення `helm` та `istioctl` полягає в тому, що конфігураційні профілі `istioctl` також включають список компонентів Istio, які будуть автоматично встановлені `istioctl`.
|
||||
|
||||
З `helm` це не так, користувачі повинні встановлювати кожен необхідний компонент Istio окремо через `helm install` і вручну вказувати бажані прапорці конфігураційного профілю для кожного компонента.
|
||||
|
||||
Ви можете думати про це як про те, що `istioctl` та `helm` використовують однакові конфігураційні профілі з однаковими назвами, але коли ви використовуєте `istioctl`, він додатково вибирає, які компоненти встановити для вас на основі обраного конфігураційного профілю, тому для досягнення того ж результату потрібна лише одна команда.
|
||||
{{< /warning >}}
|
||||
|
||||
## Профілі розгортання {#deployment-profiles}
|
||||
|
||||
Наступні вбудовані профілі розгортання наразі доступні для механізмів встановлення як `istioctl`, так і `helm`. Зверніть увагу, що оскільки це просто набори перевизначень значень Helm, їх використання не є обовʼязковим для встановлення Istio, але вони забезпечують зручну базу і рекомендуються для нових встановлень. Крім того, ви можете [налаштувати конфігурацію](/docs/setup/additional-setup/customize-installation/) понад те, що включає профіль розгортання, для ваших конкретних потреб. Наразі доступні наступні вбудовані профілі розгортання наразі доступні:
|
||||
|
||||
1. **default**: включає компоненти відповідно до стандартних налаштувань [API IstioOperator](/docs/reference/config/istio.operator.v1alpha1/). Цей профіль рекомендується для розгортання в операційному оточені та для {{< gloss "основний кластер" >}}primary кластерів{{< /gloss >}} у [мультикластерній мережі](/docs/ops/deployment/deployment-models/#multiple-clusters). Ви можете переглянути стандартні налаштування, виконавши команду `istioctl profile dump`.
|
||||
|
||||
|
|
@ -25,18 +74,15 @@ test: n/a
|
|||
|
||||
4. **remote**: використовується для налаштування {{< gloss "віддалений кластер" >}}віддаленого кластера{{< /gloss >}}, який управляється {{< gloss "зовнішня панель управління" >}}зовнішньою панеллю управління{{< /gloss >}} або панеллю управління в {{< gloss "основний кластер" >}}основному кластері{{< /gloss >}} [мультикластерної мережі](/docs/ops/deployment/deployment-models/#multiple-clusters).
|
||||
|
||||
5. **empty**: не розгортає нічого. Це може бути корисним як базовий профіль для власної конфігурації.
|
||||
5. **ambient**: профіль ambient призначений для того, щоб допомогти вам почати роботу з [режимом ambient] (/docs/ambient).
|
||||
|
||||
6. **preview**: профіль preview містить експериментальні функції. Він призначений для ознайомлення з новими функціями Istio. Стабільність, безпека та продуктивність не гарантуються — використовуйте на свій ризик.
|
||||
6. **empty**: не розгортає нічого. Це може бути корисним як базовий профіль для власної конфігурації.
|
||||
|
||||
7. **ambient**: профіль ambient розроблений, щоб допомогти вам почати роботу з [режимом ambient](/docs/ambient).
|
||||
7. **preview**: профіль preview містить експериментальні функції. Він призначений для ознайомлення з новими функціями Istio. Стабільність, безпека та продуктивність не гарантуються — використовуйте на свій ризик.
|
||||
|
||||
{{< tip >}}
|
||||
Деякі додаткові конфігураційні профілі, специфічні для постачальників, також доступні.
|
||||
Для отримання додаткової інформації зверніться до [інструкцій з налаштування](/docs/setup/platform-setup) для вашої платформи.
|
||||
{{< /tip >}}
|
||||
Набори значень профілів встановлення Istio [визначено тут]({{< github_tree >}}/manifests/helm-profiles), як для `istioctl`, так і для `helm`.
|
||||
|
||||
Компоненти, позначені як ✔, встановлюються в кожному профілі:
|
||||
Тільки для `istioctl` вказівка профілів конфігурації додатково автоматично вибирає певні компоненти Istio для встановлення, які позначено ✔ нижче:
|
||||
|
||||
| | default | demo | minimal | remote | empty | preview | ambient |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
|
|
@ -47,4 +93,26 @@ test: n/a
|
|||
| `CNI` | | | | | | | ✔ |
|
||||
| `Ztunnel` | | | | | | | ✔ |
|
||||
|
||||
{{< tip >}}
|
||||
Для подальшого налаштування Istio також можна встановити кілька додаткових компонентів. Дивіться [інтеграції](/docs/ops/integrations) для отримання додаткової інформації.
|
||||
{{< /tip >}}
|
||||
|
||||
## Профілі платформи {#platform-profiles}
|
||||
|
||||
Наступні вбудовані профілі платформи наразі доступні для механізмів встановлення як `istioctl`, так і `helm`. Зверніть увагу, що оскільки це просто набори перевизначень значень Helm, їх використання не є обовʼязковим для встановлення Istio, але вони забезпечують зручну базу і рекомендуються для нових встановлень:
|
||||
|
||||
1. **gke**: Встановлює параметри чарту, необхідні або рекомендовані для встановлення Istio в середовищах Google Kubernetes Engine (GKE).
|
||||
|
||||
1. **eks**: Встановлює параметри чарту, необхідні або рекомендовані для встановлення Istio в середовищах Amazon Elastic Kubernetes Service (EKS).
|
||||
|
||||
1. **openshift**: Встановлює параметри чарту, необхідні або рекомендовані для встановлення Istio в середовищах OpenShift.
|
||||
|
||||
1. **k3d**: Встановлює параметри чарту, необхідні або рекомендовані для встановлення Istio в середовищах [k3d](https://k3d.io/).
|
||||
|
||||
1. **k3s**: Встановлює параметри чарту, необхідні або рекомендовані для встановлення Istio в середовищах [K3s](https://k3s.io/).
|
||||
|
||||
1. **microk8s**: Встановлює параметри чарту, необхідні або рекомендовані для встановлення Istio в середовищах [MicroK8s](https://microk8s.io/).
|
||||
|
||||
1. **minikube**: Встановлює параметри чарту, необхідні або рекомендовані для встановлення Istio в середовищах [minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/).
|
||||
|
||||
Профілі платформ Istio [визначено тут]({{< github_tree >}}/manifests/helm-profiles), як для `istioctl`, так і для `helm`.
|
||||
|
|
|
|||
|
|
@ -211,6 +211,10 @@ spec:
|
|||
- Деякі поля в `Pod` залежать від повʼязаних налаштувань. Наприклад, запит на ЦП має бути меншим за обмеження ЦП. Якщо обидва поля не налаштовані разом, pod може не запуститися.
|
||||
- Поля `securityContext.RunAsUser` і `securityContext.RunAsGroup` можуть не бути прийняті в деяких випадках, наприклад, коли використовується режим `TPROXY`, оскільки він вимагає запуску sidecar від імені користувача `0`. Неправильне перевизначення цих полів може призвести до втрати трафіку, і повинно виконуватися з особливою обережністю.
|
||||
|
||||
{{< warning >}}
|
||||
Інші контролери доступу можуть виконувати специфікацію Pod до інʼєкції Istio, що може змінити або відхилити конфігурацію. Наприклад, `LimitRange` може автоматично вставляти запити на ресурси до того, як Istio додасть свої налаштовані ресурси, що може призвести до неочікуваних результатів.
|
||||
{{< /warning >}}
|
||||
|
||||
Крім того, деякі поля налаштовуються за допомогою [анотацій](/docs/reference/config/annotations/) на podʼі, хоча рекомендується використовувати наведений вище підхід до налаштування параметрів. Додатково потрібно бути обережним з деякими анотаціями:
|
||||
|
||||
- Якщо встановлено `sidecar.istio.io/proxyCPU`, обовʼязково встановіть `sidecar.istio.io/proxyCPULimit`. Інакше обмеження на `cpu` для sidecar буде встановлено як необмежене.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Спробуйте функції Istio швидко та легк
|
|||
weight: 5
|
||||
aliases:
|
||||
- /uk/docs/setup/additional-setup/getting-started/
|
||||
- /uk/latest/docs/setup/additional-setup/getting-started/
|
||||
- /latest/uk/docs/setup/additional-setup/getting-started/
|
||||
keywords: [getting-started, install, bookinfo, quick-start, kubernetes, gateway-api]
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: yes
|
||||
|
|
@ -92,7 +92,7 @@ CRD Kubernetes Gateway API не встановлені стандартно у
|
|||
1. Розгорніть [демонстраційний застосунок `Bookinfo`](/docs/examples/bookinfo/):
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f {{< github_file >}}/samples/bookinfo/platform/kube/bookinfo.yaml
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@
|
||||
service/details created
|
||||
serviceaccount/bookinfo-details created
|
||||
deployment.apps/details-v1 created
|
||||
|
|
@ -194,7 +194,7 @@ Istio інтегрується з [різними застосунками дл
|
|||
1. Встановіть [Kiali та інші надбудови]({{< github_tree >}}/samples/addons) та дочекайтесь їх розгортання.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f samples/addons
|
||||
$ kubectl apply -f @samples/addons@
|
||||
$ kubectl rollout status deployment/kiali -n istio-system
|
||||
Waiting for deployment "kiali" rollout to finish: 0 of 1 updated replicas are available...
|
||||
deployment "kiali" successfully rolled out
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: Встановіть Istio із зовнішньою панеллю
|
|||
weight: 50
|
||||
aliases:
|
||||
- /uk/docs/setup/additional-setup/external-controlplane/
|
||||
- /uk/latest/docs/setup/additional-setup/external-controlplane/
|
||||
- /latest/uk/docs/setup/additional-setup/external-controlplane/
|
||||
keywords: [external,control,istiod,remote]
|
||||
owner: istio/wg-environments-maintainers
|
||||
test: yes
|
||||
|
|
@ -222,7 +222,6 @@ $ export REMOTE_CLUSTER_NAME=<your remote cluster name>
|
|||
2. Панелі управління в зовнішньому кластері потрібен доступ до віддаленого кластера для виявлення сервісів, точок доступу та атрибутів podʼів. Створіть секрет із обліковими даними для доступу до `kube-apiserver` віддаленого кластера та встановіть його у зовнішньому кластері:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create sa istiod-service-account -n external-istiod --context="${CTX_EXTERNAL_CLUSTER}"
|
||||
$ istioctl create-remote-secret \
|
||||
--context="${CTX_REMOTE_CLUSTER}" \
|
||||
--type=config \
|
||||
|
|
|
|||
|
|
@ -34,26 +34,17 @@ $ helm install <release> <chart> --namespace <namespace> --create-namespace [--s
|
|||
Ви можете показати стандатні значення конфігураційних параметрів, використовуючи команду `helm show values <chart>`, або звернутися до документації чарту на `artifacthub` за посиланнями [Custom Resource Definition parameters](https://artifacthub.io/packages/helm/istio-official/base?modal=values), [Istiod chart configuration parameters](https://artifacthub.io/packages/helm/istio-official/istiod?modal=values) та [Gateway chart configuration parameters](https://artifacthub.io/packages/helm/istio-official/gateway?modal=values).
|
||||
{{< /tip >}}
|
||||
|
||||
1. Створіть простір імен `istio-system` для компонентів Istio:
|
||||
{{< tip >}}
|
||||
Цей крок можна пропустити, якщо використовувати аргумент `--create-namespace` у кроці 2.
|
||||
{{< /tip >}}
|
||||
|
||||
{{< text syntax=bash snip_id=create_istio_system_namespace >}}
|
||||
$ kubectl create namespace istio-system
|
||||
{{< /text >}}
|
||||
|
||||
2. Встановіть базовий чарт Istio, який містить кластерні Custom Resource Definitions (CRDs), які повинні бути встановлені перед розгортанням панелі управління Istio:
|
||||
1. Встановіть базовий чарт Istio, який містить кластерні Custom Resource Definitions (CRDs), які повинні бути встановлені перед розгортанням панелі управління Istio:
|
||||
|
||||
{{< warning >}}
|
||||
При виконанні встановлення з ревізією базовий чарт вимагає вказання значення `--set defaultRevision=<revision>` для функціонування перевірки ресурсів. Нижче ми встановлюємо ревізію `default`, тому вказуємо `--set defaultRevision=default`.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text syntax=bash snip_id=install_base >}}
|
||||
$ helm install istio-base istio/base -n istio-system --set defaultRevision=default
|
||||
$ helm install istio-base istio/base -n istio-system --set defaultRevision=default --create-namespace
|
||||
{{< /text >}}
|
||||
|
||||
3. Перевірте установку CRD за допомогою команди `helm ls`:
|
||||
1. Перевірте установку CRD за допомогою команди `helm ls`:
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ helm ls -n istio-system
|
||||
|
|
@ -63,15 +54,15 @@ $ helm install <release> <chart> --namespace <namespace> --create-namespace [--s
|
|||
|
||||
У виводі знайдіть запис для `istio-base` і переконайтесь, що статус встановлений на `deployed`.
|
||||
|
||||
4. Якщо ви плануєте використовувати чарт Istio CNI, зробіть це зараз. Див. [Встановлення Istio за допомогою втулка CNI](/docs/setup/additional-setup/cni/#installing-with-helm) для отримання додаткової інформації.
|
||||
1. Якщо ви плануєте використовувати чарт Istio CNI, зробіть це зараз. Див. [Встановлення Istio за допомогою втулка CNI](/docs/setup/additional-setup/cni/#installing-with-helm) для отримання додаткової інформації.
|
||||
|
||||
5. Встановіть чарт виявлення Istio, який розгортає сервіс `istiod`:
|
||||
1. Встановіть чарт виявлення Istio, який розгортає сервіс `istiod`:
|
||||
|
||||
{{< text syntax=bash snip_id=install_discovery >}}
|
||||
$ helm install istiod istio/istiod -n istio-system --wait
|
||||
{{< /text >}}
|
||||
|
||||
6. Перевірте установку чарту виявлення Istio:
|
||||
1. Перевірте установку чарту виявлення Istio:
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ helm ls -n istio-system
|
||||
|
|
@ -80,7 +71,7 @@ $ helm install <release> <chart> --namespace <namespace> --create-namespace [--s
|
|||
istiod istio-system 1 2024-04-17 22:14:45.964722028 +0000 UTC deployed istiod-{{< istio_full_version >}} {{< istio_full_version >}}
|
||||
{{< /text >}}
|
||||
|
||||
7. Отримайте статус встановленого Helm-чарту, щоб переконатися, що він розгорнутий:
|
||||
1. Отримайте статус встановленого Helm-чарту, щоб переконатися, що він розгорнутий:
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ helm status istiod -n istio-system
|
||||
|
|
@ -114,7 +105,7 @@ $ helm install <release> <chart> --namespace <namespace> --create-namespace [--s
|
|||
Tell us how your install/upgrade experience went at https://forms.gle/99uiMML96AmsXY5d6
|
||||
{{< /text >}}
|
||||
|
||||
8. Перевірте, чи успішно встановлено сервіс `istiod` та чи працюють його podʼи:
|
||||
1. Перевірте, чи успішно встановлено сервіс `istiod` та чи працюють його podʼи:
|
||||
|
||||
{{< text syntax=bash >}}
|
||||
$ kubectl get deployments -n istio-system --output wide
|
||||
|
|
@ -122,7 +113,7 @@ $ helm install <release> <chart> --namespace <namespace> --create-namespace [--s
|
|||
istiod 1/1 1 1 10m discovery docker.io/istio/pilot:{{< istio_full_version >}} istio=pilot
|
||||
{{< /text >}}
|
||||
|
||||
9. (Додатково) Встановіть ingress gateway:
|
||||
1. (Додатково) Встановіть ingress gateway:
|
||||
|
||||
{{< text syntax=bash snip_id=install_ingressgateway >}}
|
||||
$ kubectl create namespace istio-ingress
|
||||
|
|
@ -214,3 +205,40 @@ $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisi
|
|||
{{< text syntax=bash >}}
|
||||
$ kubectl get crd -oname | grep --color=never 'istio.io' | xargs kubectl delete
|
||||
{{< /text >}}
|
||||
|
||||
## Генерація маніфесту перед встановленням {#generate-a-manifest-before-installation}
|
||||
|
||||
Ви можете згенерувати маніфести для кожного компонента перед встановленням Istio, використовуючи команду `helm template`. Наприклад, щоб згенерувати маніфест, який можна встановити за допомогою `kubectl` для компонента `istiod`:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ helm template istiod istio/istiod -n istio-system --kube-version {версія Kubernetes цільового кластера} > istiod.yaml
|
||||
{{< /text >}}
|
||||
|
||||
Згенерований маніфест можна використовувати для перевірки того, що саме встановлюється, а також для відстеження змін у маніфесті з часом.
|
||||
|
||||
{{< tip >}}
|
||||
Будь-які додаткові прапорці або перевизначення значень, які ви зазвичай використовуєте для встановлення, також повинні бути передані команді `helm template`.
|
||||
{{< /tip >}}
|
||||
|
||||
Щоб встановити маніфест, згенерований вище, який створить компонент `istiod` у цільовому кластері:
|
||||
|
||||
{{< text syntax=bash snip_id=none >}}
|
||||
$ kubectl apply -f istiod.yaml
|
||||
{{< /text >}}
|
||||
|
||||
{{< warning >}}
|
||||
Якщо ви намагаєтеся встановити та керувати Istio за допомогою `helm template`, зверніть увагу на наступні застереження:
|
||||
|
||||
1. Простір імен Istio (стандартно `istio-system`) повинен бути створений вручну.
|
||||
|
||||
1. Ресурси можуть не встановлюватися з тією ж послідовністю залежностей, як при `helm install`.
|
||||
|
||||
1. Цей метод не тестується як частина випусків Istio.
|
||||
|
||||
1. Хоча `helm install` автоматично виявляє налаштування середовища з вашого контексту Kubernetes, `helm template` не може це робити, оскільки він працює офлайн, що може призвести до несподіваних результатів. Зокрема, ви повинні переконатися, що ви дотримуєтеся [цих кроків](/docs/ops/best-practices/security/#configure-third-party-service-account-tokens), якщо ваше середовище Kubernetes не підтримує токени сторонніх службових облікових записів.
|
||||
|
||||
1. `kubectl apply` згенерованого маніфесту може показувати тимчасові помилки через те, що ресурси не доступні в кластері в правильному порядку.
|
||||
|
||||
1. `helm install` автоматично видаляє будь-які ресурси, які повинні бути видалені при зміні конфігурації (наприклад, якщо ви видаляєте шлюз). Це не відбувається, коли ви використовуєте `helm template` з `kubectl`, і ці ресурси повинні бути видалені вручну.
|
||||
|
||||
{{< /warning >}}
|
||||
|
|
|
|||
|
|
@ -88,72 +88,33 @@ $ istioctl manifest generate > $HOME/generated-manifest.yaml
|
|||
|
||||
Згенерований маніфест можна використовувати для перевірки того, що саме буде встановлено, а також для відстеження змін у маніфесті з часом. Хоча `IstioOperator` CR представляє повну конфігурацію користувача і достатній для її відстеження, вихідні дані з `manifest generate` також відображають можливі зміни в основних чартах і тому можуть бути використані для відстеження фактично встановлених ресурсів.
|
||||
|
||||
Вихідні дані з `manifest generate` також можуть бути використані для встановлення Istio за допомогою `kubectl apply` або еквіваленту. Однак ці альтернативні методи встановлення можуть не застосовувати ресурси в тому ж порядку залежностей, як `istioctl install`, і не тестуються в релізі Istio.
|
||||
{{< tip >}}
|
||||
Будь-які додаткові прапорці або перевизначення власних значень, які ви зазвичай використовуєте для встановлення, також слід вказати у команді `istioctl manifest generate`.
|
||||
{{< /tip >}}
|
||||
|
||||
{{< warning >}}
|
||||
Якщо ви намагаєтеся встановити та управляти Istio за допомогою `istioctl manifest generate`, зверніть увагу на наступні застереження:
|
||||
|
||||
1. Простір імен Istio (`istio-system` стандартний) повинен бути створений вручну.
|
||||
|
||||
2. Перевірка Istio не буде стандартно увімкнена. На відміну від `istioctl install`, команда `manifest generate` не створює конфігурацію валідуючого вебхука `istiod-default-validator`, якщо не встановлено `values.defaultRevision`:
|
||||
1. Перевірка Istio не буде стандартно увімкнена. На відміну від `istioctl install`, команда `manifest generate` не створює конфігурацію валідуючого вебхука `istiod-default-validator`, якщо не встановлено `values.defaultRevision`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl manifest generate --set values.defaultRevision=default
|
||||
{{< /text >}}
|
||||
|
||||
3. Хоча `istioctl install` автоматично виявляє специфічні налаштування середовища з вашого контексту Kubernetes, `manifest generate` не може цього зробити, оскільки вона працює офлайн, що може призвести до неочікуваних результатів. Особливо, ви повинні переконатися, що дотримуєтеся [цих кроків](/docs/ops/best-practices/security/#configure-third-party-service-account-tokens), якщо ваше середовище Kubernetes не підтримує токени облікових записів сервісів третьої сторони.
|
||||
1. Ресурси можуть не встановлюватися з тією ж послідовністю залежностей, як в `istioctl install`.
|
||||
|
||||
4. `kubectl apply` зі згенерованим маніфестом може показувати тимчасові помилки через недоступність ресурсів у кластері в правильному порядку.
|
||||
1. Цей метод не тестується як частина випусків Istio.
|
||||
|
||||
5. `istioctl install` автоматично очищає будь-які ресурси, які повинні бути видалені при зміні конфігурації (наприклад, якщо ви видаляєте шлюз). Це не відбувається при використанні `istio manifest generate` з `kubectl`, і ці ресурси повинні бути видалені вручну.
|
||||
1. Хоча `istioctl install` автоматично виявляє специфічні налаштування середовища з вашого контексту Kubernetes, `manifest generate` не може цього зробити, оскільки вона працює офлайн, що може призвести до неочікуваних результатів. Особливо, ви повинні переконатися, що дотримуєтеся [цих кроків](/docs/ops/best-practices/security/#configure-third-party-service-account-tokens), якщо ваше середовище Kubernetes не підтримує токени облікових записів сервісів третьої сторони. Рекомендується додати `--cluster-specific` до команди `istio manifest generate` для визначення середовища цільового кластера, що дозволить вбудувати ці налаштування середовища до згенерованих маніфестів. Для цього потрібен мережевий доступ до кластера, на якому ви працюєте.
|
||||
|
||||
1. `kubectl apply` зі згенерованим маніфестом може показувати тимчасові помилки через недоступність ресурсів у кластері в правильному порядку.
|
||||
|
||||
1. `istioctl install` автоматично очищає будь-які ресурси, які повинні бути видалені при зміні конфігурації (наприклад, якщо ви видаляєте шлюз). Це не відбувається при використанні `istio manifest generate` з `kubectl`, і ці ресурси повинні бути видалені вручну.
|
||||
|
||||
{{< /warning >}}
|
||||
|
||||
## Показати відмінності в маніфестах {#show-differences-in-manifests}
|
||||
|
||||
Ви можете показати відмінності в згенерованих маніфестах у форматі YAML, порівнюючи стандартний профіль і власне встановлення, використовуючи ці команди:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl manifest generate > 1.yaml
|
||||
$ istioctl manifest generate -f samples/operator/pilot-k8s.yaml > 2.yaml
|
||||
$ istioctl manifest diff 1.yaml 2.yaml
|
||||
Відмінності в маніфестах:
|
||||
|
||||
Обʼєкт Deployment:istio-system:istiod має відмінності:
|
||||
|
||||
spec:
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
'[#0]':
|
||||
resources:
|
||||
requests:
|
||||
cpu: 500m -> 1000m
|
||||
memory: 2048Mi -> 4096Mi
|
||||
|
||||
Обʼєкт HorizontalPodAutoscaler:istio-system:istiod має відмінності:
|
||||
|
||||
spec:
|
||||
maxReplicas: 5 -> 10
|
||||
minReplicas: 1 -> 2
|
||||
{{< /text >}}
|
||||
|
||||
## Перевірка успішності встановлення {#verify-a-successful-installation}
|
||||
|
||||
Ви можете перевірити, чи вдалася установка Istio, використовуючи команду `verify-install`, яка порівнює встановлення у вашому кластері з маніфестом, який ви вказали.
|
||||
|
||||
Якщо ви не згенерували свій маніфест перед розгортанням, виконайте наступну команду, щоб згенерувати його зараз:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl manifest generate <ваші початкові параметри встановлення> > $HOME/generated-manifest.yaml
|
||||
{{< /text >}}
|
||||
|
||||
Потім виконайте наступну команду `verify-install`, щоб перевірити, чи було встановлення успішним:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl verify-install -f $HOME/generated-manifest.yaml
|
||||
{{< /text >}}
|
||||
|
||||
Дивіться [Налаштування конфігурації встановлення](/docs/setup/additional-setup/customize-installation/) для отримання додаткової інформації про налаштування встановлення.
|
||||
|
||||
## Видалення Istio {#uninstall-istio}
|
||||
|
|
|
|||
|
|
@ -206,11 +206,10 @@ API Gateway мають багато спільного з API Istio, таким
|
|||
|
||||
#### Прикріплення ресурсів і масштабування {#resource-attachment-and-scaling}
|
||||
|
||||
{{< warning >}}
|
||||
Прикріплення ресурсів наразі є експериментальним.
|
||||
{{< /warning >}}
|
||||
Ресурси можуть бути *прикріплені* до `Gateway` для його налаштування. Однак більшість ресурсів Kubernetes наразі не підтримують пряме прикріплення до `Gateway`, але їх можна прикріпити до відповідних згенерованих `Deployment` і `Service` замість цього. Це легко зробити, оскільки [ресурси генеруються з відомими мітками](https://gateway-api.sigs.k8s.io/geps/gep-1762/#resource-attachment) (`gateway.networking.k8s.io/gateway-name: <імʼя шлюзу>`) та іменами:
|
||||
|
||||
Ресурси можуть бути *прикріплені* до `Gateway` для його налаштування. Однак більшість ресурсів Kubernetes наразі не підтримують пряме прикріплення до `Gateway`, але їх можна прикріпити до відповідних згенерованих `Deployment` і `Service` замість цього. Це легко здійснити, оскільки обидва ці ресурси створюються з іменем `<gateway name>-<gateway class name>` і з міткою `gateway.networking.k8s.io/gateway-name: <gateway name>`.
|
||||
* Gateway: `<gateway name>-<gateway class name>`
|
||||
* Waypoint: `<gateway name>`
|
||||
|
||||
Наприклад, щоб розгорнути `Gateway` з `HorizontalPodAutoscaler` і `PodDisruptionBudget`:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,9 +12,9 @@ skip_breadcrumb: true
|
|||
aliases:
|
||||
- /uk/community
|
||||
- /uk/about/community
|
||||
- /uk/latest/about/community
|
||||
- /latest/uk/about/community
|
||||
- /uk/about/community/join
|
||||
- /uk/latest/about/community/join
|
||||
- /latest/uk/about/community/join
|
||||
doc_type: get-involved
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: Анонс Istio 1.23.4
|
||||
linktitle: 1.23.4
|
||||
subtitle: Патч-реліз
|
||||
description: Патч-реліз Istio 1.23.4.
|
||||
publishdate: 2024-12-18
|
||||
release: 1.23.4
|
||||
---
|
||||
|
||||
Цей реліз містить виправлення помилок для підвищення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.23.3 та Istio 1.23.4.
|
||||
|
||||
Цей реліз реалізує оновлення безпеки, описані в нашому пості від 18 грудня, [`ISTIO-SECURITY-2024-007`](/news/security/istio-security-2024-007).
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
## Зміни {#changes}
|
||||
|
||||
- **Додано** підтримку надання довільних змінних середовища до чарту `istio-cni`.
|
||||
|
||||
- **Виправлено** проблему, коли злиття `Duration` з `EnvoyFilter` могло призвести до несподіваної зміни всіх атрибутів, повʼязаних зі слухачем, оскільки всі слухачі використовували один і той самий вказівник типу `listener_filters_timeout`.
|
||||
|
||||
- **Виправлено** рендеринг Helm для правильного застосування анотацій до `ServiceAccount` Pilot.
|
||||
([Issue #51289](https://github.com/istio/istio/issues/51289))
|
||||
|
||||
- **Виправлено** проблему, коли помилки конфігурації інʼєкції замовчувалися (тобто записувалися в журнал і не поверталися), коли інжектор sidecar не міг обробити конфігурацію sidecar. Ця зміна тепер передаватиме помилку користувачеві замість продовження обробки помилкової конфігурації. ([Issue #53357](https://github.com/istio/istio/issues/53357))
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
title: Анонс Istio 1.24.2
|
||||
linktitle: 1.24.2
|
||||
subtitle: Патч-реліз
|
||||
description: Патч-реліз Istio 1.24.2.
|
||||
publishdate: 2024-12-18
|
||||
release: 1.24.2
|
||||
---
|
||||
|
||||
Цей реліз містить виправлення помилок для покращення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.24.1 та Istio 1.24.2.
|
||||
|
||||
Цей реліз реалізує оновлення безпеки, описані в нашому пості від 18 грудня, [`ISTIO-SECURITY-2024-007`](/news/security/istio-security-2024-007).
|
||||
|
||||
{{< relnote >}}
|
||||
|
||||
## Зміни {#changes}
|
||||
|
||||
- **Додано** можливість `DAC_OVERRIDE` до DaemonSet `istio-cni-node`. Це виправляє проблеми при роботі в середовищах, де певні файли належать користувачам, які не є root.Примітка: до Istio 1.24, `istio-cni-node` працював як `privileged`. Istio 1.24 видалив це, але видалив деякі необхідні привілеї, які тепер додані назад. Порівняно з Istio 1.23, `istio-cni-node` все ще має менше привілеїв, ніж з цією зміною.
|
||||
|
||||
- **Виправлено** рендеринг Helm для правильного застосування анотацій до `ServiceAccount` Pilot.
|
||||
([Issue #51289](https://github.com/istio/istio/issues/51289))
|
||||
|
||||
- **Виправлено** проблему, коли `istiod` неправильно обробляв `RequestAuthentication` для проксі waypoint між просторами імен.
|
||||
([Issue #54051](https://github.com/istio/istio/issues/54051))
|
||||
|
||||
- **Виправлено** проблему, коли на шлюзах, що керуються ревізіями, що не є стандартними, не було міток `istio.io/rev`.
|
||||
([Issue #54280](https://github.com/istio/istio/issues/54280))
|
||||
|
||||
- **Виправлено** проблему, коли служби `ExternalName` не могли вирішуватися при використанні режиму ambient та проксі DNS.
|
||||
|
||||
- **Виправлено** проблему, яка заважала налаштуванню поля `maxUnavailable` в `PodDisruptionBudget`.
|
||||
([Issue #54087](https://github.com/istio/istio/issues/54087))
|
||||
|
||||
- **Виправлено** проблему, коли помилки конфігурації інʼєкції замовчувалися (тобто записувалися в журнал і не поверталися), коли інжектор sidecar не міг обробити конфігурацію sidecar. Ця зміна тепер передаватиме помилку користувачеві замість продовження обробки некоректної конфігурації. ([Issue #53357](https://github.com/istio/istio/issues/53357))
|
||||
|
|
@ -53,11 +53,11 @@ BYPASS_OVERLOAD_MANAGER_FOR_STATIC_LISTENERS: "false"
|
|||
|
||||
Раніше це працювало лише за певних умов, і при використанні певних прапорців встановлення могло призводити до генерації CRD, які не можна було оновити через Helm і потребували ручного втручання для виправлення.
|
||||
|
||||
Як наслідок цього, мітки на CRD змінено для відповідності іншим ресурсам, встановленим через Helm.
|
||||
Завдяки цій зміні позасмугове встановлення та оновлення Istio CRD за допомогою команди `kubectl` під час використання Helm **більше не потрібне**.
|
||||
|
||||
Якщо ви раніше встановлювали або оновлювали CRD за допомогою `kubectl apply`, а не Helm, ви можете продовжити робити це.
|
||||
Якщо ви не використовуєте Helm для встановлення, шаблонування або керування ресурсами Istio, ви можете продовжити робити це і встановити CRD вручну за допомогою `kubectl apply -f manifests/charts/base/files/crd-all.gen.yaml`.
|
||||
|
||||
Якщо ви раніше встановлювали CRD за допомогою `helm install istio-base` АБО `kubectl apply`, ви можете почати безпечно оновлювати Istio CRD за допомогою `helm upgrade istio-base` з цієї та всіх наступних версій, після того як ви виконаєте нижче вказані команди kubectl для одноразової міграції:
|
||||
Якщо ви раніше встановлювали CRD за допомогою `helm install istio-base` АБО `kubectl apply`, ви можете почати безпечно оновлювати Istio CRD тільки за допомогою `helm upgrade istio-base` з цієї та всіх наступних версій, після того, як ви виконаєте нижче вказані команди kubectl для одноразової міграції:
|
||||
|
||||
- `kubectl label $(kubectl get crds -l chart=istio -o name && kubectl get crds -l app.kubernetes.io/part-of=istio -o name) "app.kubernetes.io/managed-by=Helm"`
|
||||
- `kubectl annotate $(kubectl get crds -l chart=istio -o name && kubectl get crds -l app.kubernetes.io/part-of=istio -o name) "meta.helm.sh/release-name=istio-base"` (замініть на фактичну назву релізу `istio-base`)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: ISTIO-SECURITY-2024-007
|
||||
subtitle: Бюлетень безпеки
|
||||
description: CVE, про які повідомляє Envoy.
|
||||
cves: [CVE-2024-53269, CVE-2024-53270, CVE-2024-53271]
|
||||
cvss: "7.5"
|
||||
vector: "AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
|
||||
releases: ["1.22.0 to 1.22.6", "1.23.0 to 1.23.3", "1.24.0 to 1.24.1"]
|
||||
publishdate: 2024-12-18
|
||||
keywords: [CVE]
|
||||
skip_seealso: true
|
||||
---
|
||||
|
||||
{{< security_bulletin >}}
|
||||
|
||||
## CVE {#cve}
|
||||
|
||||
### CVE Envoy {#envoy-cves}
|
||||
|
||||
- __[CVE-2024-53269](https://github.com/envoyproxy/envoy/security/advisories/GHSA-mfqp-7mmj-rm53)__: (CVSS Score 4.5, Помірний): Happy Eyeballs: Перевірте, що `additional_address` є IP-адресами, замість того, щоб аварійно завершувати роботу при сортуванні.
|
||||
- __[CVE-2024-53270](https://github.com/envoyproxy/envoy/security/advisories/GHSA-q9qv-8j52-77p3)__: (CVSS Score 7.5, Високий): HTTP/1: перевантаження надсилання призводить до аварійного завершення роботи, коли запит скидається заздалегідь.
|
||||
- __[CVE-2024-53271](https://github.com/envoyproxy/envoy/security/advisories/GHSA-rmm5-h2wv-mg4f)__: (CVSS Score 7.1, Високий): HTTP/1.1: кілька проблем з `envoy.reloadable_features.http1_balsa_delay_reset`.
|
||||
|
||||
## Чи це впливає на мене? {#am-i-impacted}
|
||||
|
||||
Це впливає на вас, якщо використовуєте Istio 1.22.0 до 1.22.6, 1.23.0 до 1.23.3 або 1.24 до 1.24.1, будь ласка, оновіться негайно. Якщо ви створили власний `EnvoyFilter` для увімкнення менеджера перевантаження, уникайте використання точки скидання навантаження `http1_server_abort_dispatch`.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
title: Підтримка Istio 1.22 завершена
|
||||
subtitle: Оголошення про підтримку
|
||||
description: Оголошення про завершення підтримки Istio 1.22.
|
||||
publishdate: 2025-01-22
|
||||
---
|
||||
|
||||
Як [було оголошено раніше](/news/support/announcing-1.22-eol/), підтримка Istio 1.22 офіційно завершена.
|
||||
|
||||
На цей момент ми більше не будемо випускати виправлення для проблем безпеки та критичних помилок для версії 1.22. Ми наполегливо рекомендуємо оновитися до останньої версії Istio ({{<istio_release_name>}}), якщо ви ще цього не зробили.
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: Підтримка Istio 1.22 закінчується 21 січня 2025 року
|
||||
subtitle: Оголошення про закінчення підтримки
|
||||
description: Оголошення про закінчення терміну підтримки Istio 1.22.
|
||||
publishdate: 2024-12-21
|
||||
---
|
||||
|
||||
Згідно з [політикою підтримки](/docs/releases/supported-releases#support-policy) Istio, мінорні релізи, такі як 1.22, підтримуються до шести тижнів після релізу N+2 мінорної версії (в цьому випадку 1.24). [Istio 1.24 був випущений 7 листопада 2024 року](/news/releases/1.24.x/announcing-1.24/), і підтримка 1.22 закінчиться 21 січня 2025 року.
|
||||
|
||||
На цей момент ми припинимо випускати виправлення для проблем безпеки та критичних помилок для 1.22, тому ми рекомендуємо вам оновитися до останньої версії Istio ({{<istio_release_name>}}). Якщо ви цього не зробите, ви можете опинитися в ситуації, коли вам доведеться робити велике оновлення в короткий термін, щоб отримати критичне виправлення.
|
||||
|
||||
Ми піклуємося про вас і ваші кластери, тому, будь ласка, подбайте про себе та оновіться.
|
||||
Loading…
Reference in New Issue