Канаркові оновлення

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

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

При установці Istio можна використовувати параметр revision для розгортання кількох незалежних панелей управління одночасно. Канаркову версію оновлення можна запустити, встановивши панель управління нової версії Istio поряд з попередньою, використовуючи інший параметр revision. Кожна ревізія є повною реалізацією панелі управління Istio з власним Deployment, Service тощо.

Перед оновленням

Перед оновленням 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, потрібно встановити поле revision наступним чином:

$ istioctl install --set revision=canary

Після виконання команди у вас буде два розгортання панелей управління і сервіси, що працюють поруч:

$ kubectl get pods -n istio-system -l app=istiod
NAME                             READY   STATUS    RESTARTS   AGE
istiod-1-27-1-bdf5948d5-htddg    1/1     Running   0          47s
istiod-canary-84c8d4dcfb-skcfv   1/1     Running   0          25s
$ kubectl get svc -n istio-system -l app=istiod
NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod-1-27-1   ClusterIP   10.96.93.151     <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   109s
istiod-canary   ClusterIP   10.104.186.250   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   87s

Ви також побачите, що є дві конфігурації інжектора sidecar контейнерів, включаючи нову ревізію.

$ kubectl get mutatingwebhookconfigurations
NAME                            WEBHOOKS   AGE
istio-sidecar-injector-1-27-1   2          2m16s
istio-sidecar-injector-canary   2          114s

Панель даних

Ознайомтеся з Канарковим оновленням Gateway, щоб дізнатися, як запускати ревізійно специфічні екземпляри шлюзу Istio. У цьому прикладі, оскільки ми використовуємо профіль Istio default, шлюзи Istio не запускають ревізійно специфічні екземпляри, а замість цього оновлюються на місці для використання нової ревізії панелі управління. Ви можете перевірити, що шлюз istio-ingress використовує ревізію canary, виконавши наступну команду:

$ istioctl proxy-status | grep "$(kubectl -n istio-system get pod -l app=istio-ingressgateway -o jsonpath='{.items..metadata.name}')" | awk -F '[[:space:]][[:space:]]+' '{print $8}'
istiod-canary-6956db645c-vwhsk

Однак, проста установка нової ревізії не вплине на наявні sidecar проксі. Щоб оновити їх, потрібно налаштувати їх на нову панель управління istiod-canary. Це контролюється під час інʼєкції sidecar контейнерів на основі мітки простору імен istio.io/rev.

Створіть простір імен test-ns з увімкненим istio-injection. У просторі імен test-ns розгорніть демонстраційний pod curl:

  1. Створіть простір імен test-ns.

    $ kubectl create ns test-ns

  2. Позначте простір імен за допомогою мітки istio-injection.

    $ kubectl label namespace test-ns istio-injection=enabled

  3. Запустіть демонстраційний pod curl у просторі імен test-ns.

    $ kubectl apply -n test-ns -f samples/curl/curl.yaml

Щоб оновити простір імен test-ns, видаліть мітку istio-injection і додайте мітку istio.io/rev, щоб вказати на ревізію canary. Мітка istio-injection повинна бути видалена, оскільки вона має перевагу над міткою istio.io/rev для зворотної сумісності.

$ kubectl label namespace test-ns istio-injection- istio.io/rev=canary

Після оновлення простору імен вам потрібно перезапустити podʼи, щоб запустити повторну ін’єкцію. Один зі способів перезапустити всі podʼи у просторі імен test-ns — це використання:

$ kubectl rollout restart deployment -n test-ns

Коли інʼєкції будуть повторно додані до podʼів, podʼи будуть налаштовані на використання панелі управління istiod-canary. Ви можете перевірити це за допомогою istioctl proxy-status.

$ istioctl proxy-status | grep "\.test-ns "

Вивід покаже всі podʼи у просторі імен, які використовують ревізію canary.

Мітки стабільних ревізій

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

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

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

  1. Встановіть дві ревізії панелі управління:

    $ istioctl install --revision=1-27-1 --set profile=minimal --skip-confirmation
$ istioctl install --revision=1-28-1 --set profile=minimal --skip-confirmation

  2. Створіть мітки stable та canary ревізій і асоціюйте їх з відповідними ревізіями:

    $ istioctl tag set prod-stable --revision 1-27-1
$ istioctl tag set prod-canary --revision 1-28-1

  3. Позначте простори імен для застосунків мітками, щоб вони відповідали відповідним міткам ревізій:

    $ kubectl create ns app-ns-1
$ kubectl label ns app-ns-1 istio.io/rev=prod-stable
$ kubectl create ns app-ns-2
$ kubectl label ns app-ns-2 istio.io/rev=prod-stable
$ kubectl create ns app-ns-3
$ kubectl label ns app-ns-3 istio.io/rev=prod-canary

  4. Запустіть демонстраційний pod curl в кожному просторі імен:

    $ kubectl apply -n app-ns-1 -f samples/curl/curl.yaml
$ kubectl apply -n app-ns-2 -f samples/curl/curl.yaml
$ kubectl apply -n app-ns-3 -f samples/curl/curl.yaml

  5. Перевірте відповідність застосунку до панелі управління за допомогою команди istioctl proxy-status:

    $ istioctl ps
NAME                                CLUSTER        CDS        LDS        EDS        RDS        ECDS         ISTIOD                             VERSION
curl-78ff5975c6-62pzf.app-ns-3      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-1-28-1-7f6fc6cfd6-s8zfg     1.28.1
curl-78ff5975c6-8kxpl.app-ns-1      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-1-27-1-bdf5948d5-n72r2      1.27.1
curl-78ff5975c6-8q7m6.app-ns-2      Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-1-27-1-bdf5948d5-n72r2      1-27.1

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

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

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

$ istioctl tag list
TAG         REVISION NAMESPACES
default     1-27-1   ...
prod-canary 1-28-1   ...
prod-stable 1-27-1   ...

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

$ istioctl tag set prod-stable --revision 1-28-1 --overwrite

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

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

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

$ kubectl rollout restart deployment -n app-ns-1
$ kubectl rollout restart deployment -n app-ns-2

Перевірте відповідність застосунку до панелі управління за допомогою команди istioctl proxy-status:

$ istioctl ps
NAME                                                   CLUSTER        CDS        LDS        EDS        RDS          ECDS         ISTIOD                             VERSION
curl-5984f48bc7-kmj6x.app-ns-1                         Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-1-28-1-7f6fc6cfd6-jsktb     1.28.1
curl-78ff5975c6-jldk4.app-ns-3                         Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-1-28-1-7f6fc6cfd6-jsktb     1.28.1
curl-7cdd8dccb9-5bq5n.app-ns-2                         Kubernetes     SYNCED     SYNCED     SYNCED     SYNCED       NOT SENT     istiod-1-28-1-7f6fc6cfd6-jsktb     1.28.1

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

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

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

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

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

Видалення старої панелі управління

Після оновлення як панелі управління, так і панелі даних, ви можете видалити стару панель управління. Наприклад, наступна команда видаляє панель управління ревізії 1-27-1:

$ istioctl uninstall --revision 1-27-1 -y

Якщо стара панель управління не має мітки ревізії, видаліть її, використовуючи оригінальні параметри установки, наприклад:

$ istioctl uninstall -f manifests/profiles/default.yaml -y

Перевірте, що стара панель управління була видалена, і в кластері залишилася тільки нова:

$ kubectl get pods -n istio-system -l app=istiod
NAME                             READY   STATUS    RESTARTS   AGE
istiod-canary-55887f699c-t8bh8   1/1     Running   0          27m

Зверніть увагу, що наведені вище інструкції видалили лише ресурси для вказаної ревізії панелі управління, але не ресурси, що використовуються у кластері, які використовуються разом іншими панелямі управління. Щоб повністю видалити Istio, ознайомтеся з посібником з видалення.

Видалення панелі управління Canary

Якщо ви вирішите повернутися до старої панелі управління, замість завершення оновлення Canary, ви можете видалити ревізію Canary, використовуючи:

$ istioctl uninstall --revision=canary -y

Однак у цьому випадку вам спочатку потрібно вручну перевстановити шлюзи для попередньої ревізії, оскільки команда видалення не відновить автоматично оновлені шлюзи.

Очищення

  1. Видаліть створені мітки ревізій:

    $ istioctl tag remove prod-stable
$ istioctl tag remove prod-canary

  2. Видаліть простори імен, що використовувалися для оновлення Canary з мітками ревізій:

    $ kubectl delete ns istio-system test-ns

  3. Видаліть простори імен, що використовувалися для оновлення Canary з мітками ревізій:

    $ kubectl delete ns istio-system app-ns-1 app-ns-2 app-ns-3
Чи була ця інформація корисною?
Чи є у вас пропозиції щодо покращення?

Дякуємо за ваш відгук!