Моделі розгортання

При налаштуванні промислового розгортання Istio вам потрібно відповісти на низку питань. Чи буде мережа обмежена одним кластером або розподілена між кількома кластерами? Чи будуть усі сервіси розташовані в одній повністю зʼєднаній мережі, або буде потрібно використовувати шлюзи для зʼєднання сервісів з кілької мереж? Чи є одна панель управління, можливо, спільна для кількох кластерів, або існує кілька панелей управління, розгорнутих для забезпечення високої доступності (HA)? Чи всі кластери будуть зʼєднані в одну мультикластерну мережу сервісів, або вони будуть федеративно обʼєднані в multi-mesh розгортання?

Усі ці питання, серед інших, представляють незалежні виміри конфігурації для розгортання Istio.

1. один чи кілька кластерів
2. одна чи кілька мереж
3. одна чи кілька панелей управління
4. одна чи кілька мереж

У промисловому середовищі з кількома кластерами ви можете використовувати комбінацію моделей розгортання. Наприклад, для забезпечення високої доступності рекомендується мати більше ніж одну панель управління, але ви можете досягти цього для розгортання з 3 кластерів, розгорнувши 2 кластери з однією спільною панеллю управління, а потім додати третій кластер з другою панеллю управління в іншій мережі. Усі три кластери можна налаштувати так, щоб вони спільно використовували обидві панелі управління, щоб усі кластери мали 2 джерела контролю для забезпечення HA.

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

Моделі кластерів

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

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

У більшості випадків кластери представляють кордони для конфігурації та виявлення точок доступу. Наприклад, кожен кластер Kubernetes має API Server, який керує конфігурацією для кластера, а також обслуговує інформацію про точки доступу сервісу, коли контейнери піднімаються чи припиняють роботу. Оскільки Kubernetes конфігурує цю поведінку на основі кожного кластера, цей підхід допомагає обмежити потенційні проблеми, спричинені неправильними конфігураціями.

В Istio ви можете налаштувати одну сервісну мережу, що охоплює будь-яку кількість кластерів.

Один кластер

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

Розгортання з одним кластером пропонують простоту, але не мають інших можливостей, таких як ізоляція від помилок і аварійне перемикання. Якщо вам потрібна вища доступність, вам слід використовувати кілька кластерів.

Кілька кластерів

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

• Ізоляція від помилок і аварійне перемикання: cluster-1 виходить з ладу, перемикаємося на cluster-2.
• Локаційно обізнана маршрутизація та аварійне перемикання: Надсилання запитів до найближчого сервісу.
• Різні моделі панелей управління: Підтримка різних рівнів доступності.
• Ізоляція команди або проєкту: Кожна команда управляє своїм набором кластерів.

Мультикластерні розгортання надають більший рівень ізоляції та доступності, але збільшують складність. Якщо ваші системи мають високі вимоги до доступності, вам ймовірно потрібні кластери в кількох зонах та регіонах. Ви можете вносити зміни в конфігурацію або нові випуски бінарних файлів в одному кластері, де зміни конфігурації впливають лише на невелику частину користувацького трафіку. Крім того, якщо кластер має проблему, ви можете тимчасово направляти трафік до сусідніх кластерів, поки не вирішите проблему.

Ви можете налаштувати міжкластерну комунікацію на основі мережі і опцій, підтримуваних вашим хмарним постачальником. Наприклад, якщо два кластери розташовані в одній і тій же основній мережі, ви можете увімкнути міжкластерну комунікацію, просто налаштувавши правила брандмауера.

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

DNS з кількома кластерами

Коли клієнтський застосунок робить запит до певного хосту, спочатку потрібно виконати DNS-запит для отримання IP-адреси перед тим, як продовжити запит. В Kubernetes сервер DNS, що знаходиться в кластері, зазвичай обробляє цей DNS-запит на основі налаштованих визначень Service.

Istio використовує віртуальну IP-адресу, повернуту DNS-запитом, для балансування навантаження серед списку активних точок доступу запитаного сервісу, враховуючи будь-які налаштовані правила маршрутизації Istio. Istio використовує або Kubernetes Service/Endpoint, або Istio ServiceEntry для налаштування своєї внутрішньої відповідності між іменем хоста і IP-адресами робочих навантажень.

Ця двошарова система імен стає складнішою, коли у вас є кілька кластерів. Istio в принципі обізнаний про мультикластери, але Kubernetes наразі — ні (не зараз). Через це, клієнтський кластер повинен мати запис DNS для сервісу, щоб DNS-запит успішно виконувся і запит був успішно надісланий. Це вірно навіть якщо в клієнтському кластері немає екземплярів контейнерів цього сервісу.

Щоб забезпечити успішність DNS-запиту, вам потрібно розгорнути Kubernetes Service у кожному кластері, який використовує цей сервіс. Це гарантує, що незалежно від того, звідки походить запит, він пройде DNS-запит і буде переданий Istio для належної маршрутизації. Це також можна досягти за допомогою Istio ServiceEntry, а не Kubernetes Service. Проте, ServiceEntry не налаштовує сервер DNS Kubernetes. Це означає, що DNS потрібно налаштувати або вручну, або за допомогою автоматизованих інструментів, таких як Автоматичний розподіл адрес функції Istio DNS Proxying.

Моделі мереж

Istio використовує спрощене визначення мережі для позначення екземплярів робочих навантажень, що мають прямий доступ. Наприклад, стандартно усі екземпляри робочих навантажень в одному кластері знаходяться в одній мережі.

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

Одна мережа

У найпростішому випадку сервісна мережа працює через одну повністю зʼєднану мережу. У моделі однієї мережі всі екземпляри робочих навантажень можуть безпосередньо взаємодіяти один з одним без шлюза Istio.

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

Кілька мереж

Ви можете розширити одну срвісну мережу на кілька мереж; така конфігурація відома як мульти-мережа.

Кілька мереж надають такі можливості, які відсутні в одній мережі:

• Перекриття IP або VIP діапазонів для точок доступу сервісу
• Перехід через адміністративні кордони
• Терпимість до відмов
• Масштабування мережевих адрес
• Відповідність стандартам, що вимагають сегментації мережі

У цій моделі екземпляри робочих навантажень у різних мережах можуть взаємодіяти один з одним тільки через один або кілька шлюзів Istio. Istio використовує розділене виявлення сервісів для надання споживачам різного уявлення про точки достру сервісу. Це уявлення залежить від мережі споживачів.

Це рішення вимагає наявності всіх сервісів (або їх підмножини) за шлюзом. Хмарні постачальники можуть надавати опції, які не вимагатимуть експонування сервісів в публічний інтернет. Така опція, якщо вона існує і відповідає вашим вимогам, ймовірно буде найкращим вибором.

Моделі панелі управління

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

У найпростішому випадку ви можете запустити свою мережу з панеллю управління на одному кластері.

Кластер, подібний до цього, з власною локальною панеллю управління, називається основним кластером.

Мультикластерні розгортання також можуть ділитися екземплярами панелі управління. У цьому випадку екземпляри панелі управління можуть розміщуватися в одному або кількох основних кластерах. Кластери без власної панелі управління називаються віддаленими кластерами.

Щоб підтримувати віддалені кластери в мультикластерній мережі, панель управління в основному кластері повинна бути доступною через стабільний IP (наприклад, IP кластера). Для кластерів, що охоплюють мережі, це можна досягти, експонуючи панель управління через шлюз Istio. Хмарні постачальники можуть надавати опції, такі як внутрішні балансувальники навантаження, для надання цієї можливості без експонування панелі управління в публічний інтернет. Така опція, якщо вона існує і відповідає вашим вимогам, ймовірно, буде найкращим вибором.

У мультикластерних розгортаннях з більш ніж одним основним кластером кожен основний кластер отримує свою конфігурацію (тобто Service і ServiceEntry, DestinationRule тощо) від API сервера Kubernetes, розташованого в тому ж кластері. Тому кожен основний кластер має незалежне джерело конфігурації. Це дублювання конфігурації між основними кластерами вимагає додаткових кроків при впровадженні змін. Великі промислові системи можуть автоматизувати цей процес за допомогою інструментів, таких як системи CI/CD, для управління розогортання конфігурації.

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

Керована панель управління від хмарного постачальника є типовим прикладом зовнішньої панелі управління.

Для високої доступності слід розгорнути кілька панелей управління в кластерах, зонах або регіонах.

Ця модель надає такі переваги:

• Поліпшена доступність: Якщо панель управління стає недоступною, обсяг відмови обмежується лише робочими навантаженнями в кластерах, керованих цією панеллю управління.

• Ізоляція конфігурації: Ви можете вносити зміни в конфігурацію в одному кластері, зоні або регіоні, не впливаючи на інші.

• Контроль розгортання: У вас є більш детальний контроль над розгортанням конфігурації (наприклад, один кластер за раз). Ви також можете використовувати canary для змін конфігурації в підсистемі мережі, контрольованій певним основним кластером.

• Вибіркова видимість сервісів: Ви можете обмежити видимість сервісів на частину мережі, що допомагає встановити ізоляцію на рівні сервісів. Наприклад, адміністратор може вибрати розгортання сервісу HelloWorld в кластері A, але не в кластері B. Будь-яка спроба виклику HelloWorld з кластера B зазнає невдачі через помилку DNS.

Ось список прикладів розгортання панелей управління за рівнем доступності:

• Один кластер на регіон (найнижча доступність)
• Кілька кластерів на регіон
• Один кластер на зону
• Кілька кластерів на зону
• Кожен кластер (найвища доступність)

Виявлення точок доступу за допомогою декількох панелей управління

Панель управління Istio керує трафіком у межах мережі, надаючи кожному проксі список точок доступу сервісів. Щоб це працювало в мультикластерному сценарії, кожна панель управління повинна спостерігати за точки доступ з API сервера в кожному кластері.

Для увімкнення виявлення точок доступу для кластера адміністратор генерує віддалений секрет і розгортає його в кожному основному кластері мережі. Віддалений секрет містить облікові дані, що надають доступ до API сервера в кластері. Панелі управління потім підключаються та виявляють точки доступу сервісів для кластера, забезпечуючи балансування навантаження між кластерами для цих сервісів.

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

У деяких складних сценаріях балансування навантаження між кластерами може не знадобитися. Наприклад, у розгортанні blue/green ви можете розгортати різні версії системи в різних кластерах. У такому випадку кожен кластер фактично функціонує як незалежна мережа. Цю поведінку можна досягти кількома способами:

• Не обмінюватися віддаленими секретами між кластерами. Це забезпечить найсильнішу ізоляцію між кластерами.

• Використовувати VirtualService і DestinationRule, щоб заборонити маршрутизацію між двома версіями сервісів.

У будь-якому з цих випадків балансування навантаження між кластерами буде відключене. Зовнішній трафік можна маршрутизувати до одного або іншого кластера за допомогою зовнішнього балансувальника навантаження.

Моделі ідентичності та довіри

Коли екземпляр робочого навантаження створюється в межах мережі сервісів, Istio призначає йому ідентичність.

Центр сертифікації (CA, Certificate Authority) створює та підписує сертифікати, що використовуються для підтвердження ідентичностей у межах мережі. Ви можете перевірити ідентичність відправника повідомлення за допомогою відкритого ключа CA, який створив і підписав сертифікат для цієї ідентичності. Пакет довіри (trust bundle) — це набір усіх відкритих ключів CA, що використовуються мережею Istio. Маючи пакет довіри мережі, будь-хто може перевірити відправника будь-якого повідомлення, що надходить з цієї мережі.

Довіра в межах мережі

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

Довіра між мережами

Для забезпечення спілкування між двома мережами з різними CA потрібно обмінятися пакетами довіри цих мереж. Istio не надає інструментів для автоматичного обміну пакетами довіри між мережами. Ви можете обмінюватися пакетами довіри вручну або автоматично за допомогою таких протоколів, як SPIFFE Trust Domain Federation. Після імпортування пакета довіри в мережу ви можете налаштувати локальні політики для цих ідентичностей.

Моделі мережі

Istio підтримує розміщення всіх ваших сервісів у сервісній мережі, або обʼєднання кількох мереж разом, що також називається мульти-мережею.

Одна мережа

Найпростіше розгортання Istio — це одна мережа. У межах мережі назви сервісів є унікальними. Наприклад, лише один сервіс може мати назву mysvc у просторі імен foo. Крім того, екземпляри робочого навантаження мають спільну ідентичність, оскільки назви облікових записів сервісів є унікальними в просторі імен, як і назви сервісів.

Одна мережа може охоплювати один або кілька кластерів і одну або кілька мереж. У межах однієї мережі простори імен використовуються для орендного управління.

Кілька мереж

Розгортання кількох мереж відбувається через федерацію мереж.

Кілька мереж надають наступні можливості, які виходять за межі однієї мережі:

• Організаційні межі: розподіл по підрозділах
• Повторне використання імен сервісів або просторів імен: кілька незалежних випадків використання простору імен default
• Сильніша ізоляція: ізоляція тестових робочих навантажень від операційних

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

Щоб уникнути конфліктів у назвах сервісів, ви можете присвоїти кожній мережі глобально унікальний mesh ID, щоб гарантувати, що повністю кваліфіковане доменне ім’я (FQDN) кожного сервісу буде унікальним.

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

Моделі орендного управління

В Istio орендар (tenant) — це група користувачів, які мають спільний доступ і привілеї для набору розгорнутих робочих навантажень. Орендарі можуть бути використані для забезпечення певного рівня ізоляції між різними командами.

Моделі орендного управління можна налаштувати відповідно до таких організаційних вимог до ізоляції:

• Безпека
• Політики
• Ємність
• Вартість
• Продуктивність

Istio підтримує три типи моделей орендного управління:

• Оренда на рівні просторів імен
• Оренда на рівні кластерів
• Оренда на рівні мережі

Оренда на рівні просторів імен

Кластер може використовуватись кількома командами, кожна з яких працює в різних просторах імен. Можна надати команді дозвіл розгортати робочі навантаження лише в зазначеному просторі імен або наборі просторів імен.

Стандартно, сервіси з різних просторів імен можуть взаємодіяти між собою, але для посилення ізоляції можна вибірково обирати, які сервіси будуть доступні іншим просторам імен. Для експонованих сервісів можна налаштувати політики авторизації, щоб обмежити доступ лише до відповідних абонентів.

Оренда на рівні просторів імен може поширюватися на кілька кластерів. Під час використання декількох кластерів простори імен у кожному кластері з однаковими назвами стандартно вважаються одним і тим самим простором імен. Наприклад, Service B у просторі імен Team-1 кластера West і Service B у просторі імен Team-1 кластера East вважаються одним і тим самим сервісом, і Istio об’єднує їхні точки доступу для експонування сервісів і балансування навантаження.

Оренда на рівні кластера

Istio підтримує використання кластерів як одиниці оренди. У цьому випадку кожна команда отримує власний кластер або набір кластерів для розгортання своїх робочих навантажень. Дозволи на доступ до кластера зазвичай обмежуються членами команди, яка ним володіє. Можна налаштувати різні ролі для більш точного контролю, наприклад:

• Адміністратор кластера
• Розробник

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

Оренда на рівні мережі

У мульти-мережевому розгортанні з федерацією мереж кожна мережа може використовуватись як одиниця ізоляції.

Оскільки кожною мережею керує власна команда або організація, назви сервісів рідко є унікальними. Наприклад, Service C у просторі імен foo кластера Team-1 і сервіс Service C у просторі імен foo кластера Team-2 не будуть означати один і той самий сервіс. Найпоширеніший приклад — це сценарій у Kubernetes, коли багато команд розгортають свої робочі навантаження в просторі імен default.

Коли кожна команда має свою мережу, міжмережеве спілкування слідує концепціям, описаним у моделі кількох мереж.