Впровадження підтримки мультикластерів для режиму ambient (альфа)

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

Потужність і складність мультикластерів

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

У межах одного кластера Kubernetes кожен pod може безпосередньо підключатися до іншого pod через унікальний IP podʼа або VIP-сервісу. Ці гарантії зникають в архітектурах мультикластерів; IP-адреси різних кластерів можуть перекриватися, і навіть без перекриття базова інфраструктура потребуватиме налаштування для маршрутизації трафіку між кластерами.

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

Рішення для мультикластерів повинно надійно зʼєднувати кластери та робити це через прості, декларативні API, які відповідають динамічним середовищам, де кластери часто додаються та видаляються.

Ключові компоненти

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

Шлюзи схід-захід

Кожен кластер має шлюз схід-захід з глобально маршрутизованою IP-адресою, яка виступає точкою входу для міжкластерної комунікації. Ztunnel підключається до шлюзу схід-захід віддаленого кластера, ідентифікуючи сервіс призначення за її іменем у просторі імен. Шлюз схід-захід потім розподіляє навантаження зʼєднання на локальний под. Використання маршрутизованої IP-адреси шлюзу схід-захід усуває необхідність конфігурації міжкластерної маршрутизації, а адресація подів за іменем простору імен, а не за IP-адресою, усуває проблеми з перекриттям IP-просторів. Разом ці конструктивні рішення забезпечують міжкластерну звʼязність без зміни мережевої конфігурації кластерів або перезапуску робочих навантажень, навіть при додаванні або видаленні кластерів.

Подвійний HBONE

Ambient multicluster використовує вкладені зʼєднання HBONE для ефективного захисту трафіку, що проходить через межі кластера. Зовнішнє зʼєднання HBONE шифрує трафік до шлюзу схід-захід і дозволяє вихідному ztunnel та шлюзу схід-захід перевіряти ідентичність один одного. Внутрішнє зʼєднання HBONE наскрізно шифрує трафік, що дозволяє вихідному ztunnel та кінцевому ztunnel перевіряти ідентичність один одного. Водночас шари HBONE дозволяють ztunnel ефективно повторно використовувати міжкластерні зʼєднання, мінімізуючи TLS-рукостискання.

Виявлення Service та Scope

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

Адміністратори Mesh визначають критерії на основі міток для глобальних сервісів за допомогою API ServiceScope, а розробники застосунків відповідно позначають свої сервіси мітками. Типово ServiceScope є

serviceScopeConfigs:
  - servicesSelector:
      matchExpressions:
        - key: istio.io/global
          operator: In
          values: ["true"]
    scope: GLOBAL

що означає, що будь-який сервіс з міткою istio.io/global=true є глобальним. Хоча стандартні значення є простими, API ServiceScope може виражати складні умови за допомогою комбінації операторів AND та OR.

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

Обмеження та плани

Хоча поточна реалізація ambient multicluster має основні функції для рішення з кількома кластерами, ще багато роботи попереду. Ми прагнемо поліпшити наступні області

• Конфігурація Service та waypoint повинна бути єдиною для всіх кластерів.
• Відсутність перехресної L7 відмовостійкості (політика L7 застосовується в кластері призначення).
• Відсутня підтримка прямого адресації подів або headless services.
• Підтримка лише моделі розгортання з кількома основними вузлами.
• Підтримка лише однієї мережі на кластер.

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

Якщо ви хочете спробувати ambient multicluster, будь ласка, дотримуйтесь цього посібника. Памʼятайте, що ця функція знаходиться на стадії альфа-версії і не готова до використання в продуктивному середовищі. Ми вітаємо ваші звіти про помилки, думки, коментарі та випадки використання — ви можете звʼязатися з нами на GitHub або Slack.