Архитектура сети приложений Azure Kubernetes (предварительная версия)

Это важно

Предварительные версии функций AKS доступны на условиях самообслуживания и добровольного выбора. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии AKS сопровождаются частичной поддержкой клиентов на основе принципа лучших усилий. Как таковые, эти функции не предназначены для использования в производстве. Для получения дополнительной информации ознакомьтесь со следующими статьями поддержки:

Архитектура сети приложений Azure Kubernetes организована на три уровня: плоскость управления, плоскость управления и плоскость данных. Каждый уровень имеет отдельные обязанности, которые вместе предоставляют полностью управляемое, основанное на Ambient сетевое решение для службы Azure Kubernetes Service (AKS). Эта архитектура обеспечивает безопасный обмен данными между службами, управляемый политиками, без необходимости использования sidecars или внесения изменений в ваши приложения.

В этой статье представлен обзор архитектурных слоев сети приложений Azure Kubernetes, способа их взаимодействия и модели обнаружения служб с несколькими кластерами, которая обеспечивает масштабируемое взаимодействие между кластерами. Дополнительные сведения о сети приложений Azure Kubernetes см. в статье "Обзор сети приложений Azure Kubernetes для AKS".

Обзор уровней архитектуры сети приложений

Архитектурные слои управляют следующими обязанностями:

Плоскость управления. Обрабатывает такие операции ресурсов Azure, как создание, обновление и удаление сетевых ресурсов приложений и управление членством в кластере.
Плоскость управления: управляет конфигурацией сетки, жизненным циклом сертификатов и обнаружением служб для каждого кластера-члена.
Плоскость данных: обеспечивает безопасность трафика между службами непосредственно в кластере-члене с помощью режима без боковиков, для которого не требуются побочные модули или изменения в приложениях.

Для развертываний с несколькими кластерами сеть приложений синхронизирует сведения об обнаружении служб между кластерами членов, чтобы службы могли прозрачно взаимодействовать между границами кластера.

На следующей схеме показаны архитектурные слои сети приложений Azure Kubernetes и взаимодействие между ними и с кластерами AKS:

Управляющий уровень

Плоскость управления — это поставщик ресурсов Azure, который обрабатывает все операции с сетевыми ресурсами приложений. При создании ресурса "Сеть приложений" или присоединении к кластеру-члену плоскость управления проверяет запрос, подготавливает вспомогательные ресурсы Azure, такие как Azure Key Vault для хранилища сертификатов, и управляет созданием региональной плоскости управления для члена.

Вы взаимодействуете с плоскостем управления с помощью Azure CLI (az appnet) или API ARM. Плоскость управления координирует все процессы подчиненной автоматизации, чтобы компоненты плоскости контроля и плоскости данных развертывались без ручного вмешательства.

Контрольная плоскость

Контрольная плоскость — это полностью управляемая инфраструктура, которая работает за пределами вашего кластера AKS. Когда кластер-член присоединяется к сети приложений, выделенная плоскость управления подготавливается в том же регионе Azure, что и кластер-член, сохраняя задержку между компонентами уровня управления и плоскости данных.

Замечание

Участники в различных регионах Azure имеют развернутые в этих же регионах плоскости управления.

Плоскость управления включает следующие компоненты:

Istiod: подключается к серверу API Kubernetes кластера-члена для обнаружения служб и отслеживания изменений конфигурации. Отправляет конфигурацию xDS в ztunnel и прокси серверы waypoint на плоскости передачи данных. В развертываниях с несколькими кластерами Istiod также подключается к серверам API Kubernetes других кластеров-членов для получения сведений об обнаружении служб, что позволяет обнаруживать службы между кластерами.
Управление сертификатами: Подготавливает и обновляет сертификаты ЦС с поддержкой Azure Key Vault. Корневой ЦС устанавливает границу общего доверия во всех кластерах-членах, и каждый член получает промежуточный ЦС, который выдает сертификаты рабочей нагрузки с коротким сроком действия. Дополнительные сведения см. в статье "Общие сведения о безопасности сети приложений Azure Kubernetes".
Управление жизненным циклом: развертывает и обновляет все компоненты плоскости данных в кластере-члене, включая ztunnel, Istio CNI, прокси-серверы waypoint и пользовательские определения ресурсов (CRD). Дополнительные сведения см. в статье "Настройка обновлений для членов сети приложений Azure Kubernetes".

Плоскость данных

Плоскость данных состоит из компонентов, развернутых в пространстве имен кластера-члена applink-system . Сеть приложений использует режим окружения Istio, поэтому в ваши нагрузки не внедряются сайдкары.

Плоскость данных включает следующие компоненты:

Ztunnel: прокси-сервер уровня узла L4, развернутый как DaemonSet. Ztunnel перехватывает трафик между службами на узле, устанавливает подключения mTLS прозрачно и применяет политики авторизации L4.
Прокси-серверы контрольной точки: необязательные прокси-серверы пространства имен L7, обеспечивающие маршрутизацию HTTP, перераспределение трафика, инъекцию сбоев и авторизацию L7. Прокси-точки маршрута разворачиваются только в том случае, если политики L7 настроены для пространства имен.
Шлюз на востоке: обрабатывает трафик между кластерами в развертываниях с несколькими кластерами. Вы несете ответственность за предоставление сетевого подключения между шлюзами на востоке и западе в каждом кластере-члене. Для получения дополнительной информации см. раздел Обнаружение служб в нескольких кластерах.
Istio CNI: DaemonSet, который настраивает сети pod для перехвата трафика внешней сетки.
CRDs: пользовательские определения ресурсов Kubernetes для настройки политик управления трафиком и безопасности.

Когда запрос выполняется между службами, ztunnel перехватывает трафик, устанавливает подключение mTLS с ztunnel назначения и отправляет запрос в целевую рабочую нагрузку. Если настроены политики L7, трафик перед достижением своей цели направляется через проксисервер. Для межкластерного трафика ztunnel маршрутизируется через шлюз east-west, чтобы достичь нагрузок в удаленных кластерах-участниках.

Обнаружение служб в многокластерной среде

Сеть приложений поддерживает подключение нескольких кластеров AKS к единой сетке служб. Службы в одном кластере-члене могут взаимодействовать со службами в других кластерах-членах, при этом обеспечение сквозной безопасности через границы кластеров осуществляется с помощью mTLS.

В развертываниях с открытым исходным кодом Istio с несколькими кластерами плоскости управления обычно подключаются к серверам API Kubernetes других кластеров для обнаружения служб и изменений конфигурации. Сеть приложений следует аналогичной модели обнаружения служб, где плоскости управления получают сведения о службе из кластеров членов, чтобы службы можно было обнаруживать по границам кластера. Этот подход позволяет рабочим нагрузкам в одном кластере-члене разрешать и взаимодействовать со службами, работающими в других кластерах, не требуя изменений в приложении. Добавление нового кластера-члена расширяет членство в сетке, чтобы службы в новом кластере стали обнаруживаемыми другими членами.

Трафик между кластерами проходит через шлюзы восточного запада, развернутые в каждом кластере-члене. Вы несете ответственность за обеспечение доступности сети между шлюзами на востоке и западом кластеров членов, например через пиринг виртуальных сетей, VPN или другие решения для подключения. Весь трафик между кластерами шифруется с помощью MTLS.

Взаимодействие компонентов

Контрольная плоскость подключается к серверу API Kubernetes кластеров-членов, наблюдает за изменениями служб и конфигурации, а также отправляет обновления xDS в ztunnel и waypoint-прокси. При наличии нескольких участников, каждая контрольная плоскость также обменивается служебной информацией посредством управляемой передачи сообщений, чтобы каждый участник имел согласованный вид всех служб в сетке.

Управление сертификатами подготавливает корневой ЦС при создании ресурса "Сеть приложений" и выдает промежуточные ЦС для каждого кластера-члена. Сертификаты рабочей нагрузки выдаются с периодом действия 24-часового срока и автоматически поворачиваются каждые 12 часов. Весь жизненный цикл сертификатов, от корневого удостоверяющего центра до промежуточных сертификатов и сертификатов рабочих нагрузок, управляется автоматически.

Сведения о полной иерархии сертификатов и расписании смены см. в разделе "Обзор безопасности сети приложений Azure Kubernetes".

Дополнительные сведения о сети приложений Azure Kubernetes см. в следующих статьях:

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-03-23