Оновлення з Helm

6 хвилин(и) перевірка сторінки

Слідуйте цьому посібнику для оновлення та налаштування сервісної мережі Istio за допомогою Helm. Цей посібник передбачає, що ви вже виконали встановлення за допомогою Helm для попередньої незначної або патч-версії Istio.

Helm-чарти для base та istiod, які використовуються в цьому посібнику, такі ж самі, як і ті, що використовуються при встановленні Istio через Istioctl. Однак під час встановлення через Istioctl використовується інший чарт шлюзу, ніж чарт, описаний у цьому посібнику

Попередні вимоги

Виконайте будь-яке необхідне налаштування для вашої платформи.
Перевірте Вимоги до Podʼів та Сервісів.
Встановіть клієнт Helm, версії 3.6 або вище.
Налаштуйте репозиторій Helm:

$ helm repo add istio https://istio-release.storage.googleapis.com/charts
$ helm repo update

Кроки для оновлення

Перед оновленням Istio рекомендується виконати команду istioctl x 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/>

Оновлення Canary (рекомендовано)

Ви можете встановити версію canary панелі управління Istio, щоб перевірити, чи нова версія сумісна з вашою поточною конфігурацією та панеллю даних за допомогою наведених нижче кроків:

Якщо ви оновлюєте CRD за допомогою Helm з версії Istio 1.23 або старішої, ви можете зіткнутися з такою помилкою

Error: rendered manifests contain a resource that already exists. Unable to continue with update: CustomResourceDefinition "wasmplugins.extensions.istio.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata

Ви можете розвʼязати цю проблему за допомогою одноразової міграції за допомогою наступних команд kubectl:

$ for crd in $(kubectl get crds -l chart=istio -o name && kubectl get crds -l app.kubernetes.io/part-of=istio -o name)
$ do
$    kubectl label "$crd" "app.kubernetes.io/managed-by=Helm"
$    kubectl annotate "$crd" "meta.helm.sh/release-name=istio-base" # замініть на актуальну назву релізу Helm, якщо вона відрізняється від стандартної у документації.
$    kubectl annotate "$crd" "meta.helm.sh/release-namespace=istio-system" # замінити на актуальний простір імен istio
$ done

Оновіть визначення власних ресурсів Kubernetes (CRD):
```
$ helm upgrade istio-base istio/base -n istio-system
```
Встановіть канаркову версію чарту виявлення Istio, встановивши ревізію:
```
$ helm install istiod-canary istio/istiod \
    --set revision=canary \
    -n istio-system
```

Перевірте, що у вашому кластері встановлено дві версії istiod:

$ kubectl get pods -l app=istiod -L istio.io/rev -n istio-system
  NAME                            READY   STATUS    RESTARTS   AGE   REV
  istiod-5649c48ddc-dlkh8         1/1     Running   0          71m   default
  istiod-canary-9cc9fd96f-jpc7n   1/1     Running   0          34m   canary

Якщо ви використовуєте шлюзи Istio, встановіть версію canary чарту шлюзу, встановивши значення revision:
```
$ helm install istio-ingress-canary istio/gateway \
    --set revision=canary \
    -n istio-ingress
```

Перевірте, що у вашому кластері встановлено дві версії шлюзу istio-ingress:

$ kubectl get pods -L istio.io/rev -n istio-ingress
  NAME                                    READY   STATUS    RESTARTS   AGE     REV
  istio-ingress-754f55f7f6-6zg8n          1/1     Running   0          5m22s   default
  istio-ingress-canary-5d649bd644-4m8lp   1/1     Running   0          3m24s   canary

Ознайомтеся з Оновленням шлюзів для докладної документації про оновлення canary шлюзів.

Слідуйте крокам тут, щоб протестувати або перенести поточні робочі навантаження для використання canary панелі управління.
Коли ви підтвердите та перенесете свої робочі навантаження для використання canary панелі управління, ви можете видалити стару панель управління:
```
$ helm delete istiod -n istio-system
```
Оновіть знов базовий чарт Istio, цього разу зробивши нову canary версію стандартною для всього кластера:
```
$ helm upgrade istio-base istio/base --set defaultRevision=canary -n istio-system
```

Мітки стабільної версії

Переназивання просторів назв вручну під час перенесення їх до нової ревізії може бути нудним і повʼязаним з помилками. Теґи ревізій вирішують цю проблему. Мітки ревізій є стабільними ідентифікаторами, які вказують на ревізії і можуть бути використані для уникнення переназивання просторів імен. Замість того, щоб переназивати простір імен, оператор сервісної мереді може просто змінити теґ, щоб він вказував на нову ревізію. Усі простори імен, позначені цією міткою, буде оновлено одночасно.

Використання

Розглянемо кластер з двома встановленими ревізіями 1-23-1 та 1-24-3. Оператор кластера створює теґ ревізії prod-stable, який вказує на стару, стабільну 1-23-1 версію, і теґ ревізії prod-canary, який вказує на новішу 1-24-3 ревізію. Цього стану можна досягти за допомогою наступних команд:

$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-stable}" --set revision=1-23-1 -n istio-system | kubectl apply -f -
$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-canary}" --set revision=1-24-3 -n istio-system | kubectl apply -f -

Отримане зіставлення між ревізіями, теґами та просторами імен виглядає наступним чином:

Два простори імен вказані на prod-stable, і один на prod-canary

Оператор кластера може переглядати це зіставлення разом із протеґованими просторами імен за допомогою команди istioctl tag list:

$ istioctl tag list
TAG         REVISION NAMESPACES
default     1-23-1   ...
prod-canary 1-24-3   ...
prod-stable 1-23-1   ...

Після того як оператор кластера впевнений у стабільності панелі управління з теґом prod-canary, простори імен, помічені як istio.io/rev=prod-stable, можна оновити однією дією, змінивши теґ ревізії prod-stable, щоб вказувати на новішу ревізію 1-24-3.

$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-stable}" --set revision=1-24-3 -n istio-system | kubectl apply -f -

Тепер оновлене зіставлення між ревізіями, теґами та просторами імен виглядає наступним чином:

Мітки просторів імен не змінилися, але тепер усі простори імен вказують на {{< istio_full_version_revision >}}

Перезавантаження робочих навантажень з інʼєкціями у просторах імен, позначених як prod-stable, тепер призведе до використання цими робочими навантаженнями панелі управління 1-24-3. Зверніть увагу, що перепризначення просторів імен не вимагалося для міграції робочих навантажень на нову ревізію.

Стандартний теґ

Ревізія, на яку вказує теґ default, вважається стандартною ревізією і має додаткове семантичне значення. Стандартна ревізія виконує такі функції:

Додає sidecar контейнери для селектора простору імен istio-injection=enabled, селектора обʼєкта sidecar.istio.io/inject=true та селекторів istio.io/rev=default
Валідує ресурси Istio
Перехоплює блокування лідера у нестандартних ревізій і виконує обовʼязки синглтонів mesh (наприклад, оновлення статусів ресурсів).

Щоб зробити ревізію 1-24-3 стандартною, виконайте:

$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{default}" --set revision=1-24-3 -n istio-system | kubectl apply -f -

При використанні теґу default разом з існуючою неопрацьованою інсталяцією Istio рекомендується видалити стару MutatingWebhookConfiguration (зазвичай називається istio-sidecar-injector), щоб уникнути спроб інʼєкції як у старій, так і у новій панелях управління.

Оновлення на місці

Ви можете виконати оновлення на місці Istio у вашому кластері за допомогою робочого процесу оновлення Helm.

Якщо ви оновлюєте CRD за допомогою Helm з версії Istio 1.23 або старішої, ви можете зіткнутися з такою помилкою

Ви можете розвʼязати цю проблему за допомогою одноразової міграції за допомогою наступних команд kubectl:

$ for crd in $(kubectl get crds -l chart=istio -o name && kubectl get crds -l app.kubernetes.io/part-of=istio -o name)
$ do
$    kubectl label "$crd" "app.kubernetes.io/managed-by=Helm"
$    kubectl annotate "$crd" "meta.helm.sh/release-name=istio-base" # замініть на актуальну назву релізу Helm, якщо вона відрізняється від стандартної у документації.
$    kubectl annotate "$crd" "meta.helm.sh/release-namespace=istio-system" # замінити на актуальний простір імен istio
$ done

Оновіть базовий чарт Istio:

$ helm upgrade istio-base istio/base -n istio-system

Оновіть чарт виявлення Istio:

$ helm upgrade istiod istio/istiod -n istio-system

(Необовʼязково) Оновіть чарти шлюзів, встановлені у вашому кластері:
```
$ helm upgrade istio-ingress istio/gateway -n istio-ingress
```

Видалення

Будь ласка, ознайомтеся з розділом видалення в нашому посібнику з встановлення Helm.

Дивіться також

Встановлення за допомогою Helm

Інструкція по встановленню та налаштуванню Istio в кластері Kubernetes за допомогою Helm.

Docker Desktop

Інструкції для налаштування Docker Desktop для Istio.

Google Kubernetes Engine

Інструкції для налаштування кластера Google Kubernetes Engine для Istio.

Kops

Інструкції для налаштування Kops для використання з Istio.

KubeSphere Container Platform

Інструкції для налаштування платформи KubeSphere Container для Istio.

Kubernetes Gardener

Інструкції для налаштування кластера Gardener для використання з Istio.