Основные понятия сети для приложений в Служба Azure Kubernetes (AKS)
В процессе разработки, опирающемся на использование контейнеров и микрослужб, компоненты приложения должны слаженно работать вместе для обработки задач. Kubernetes предоставляет различные ресурсы для обеспечения этой слаженной работы:
- К приложениям можно подключиться и предоставить внутренний или внешний доступ.
- Имеется возможность создавать приложения с высоким уровнем доступности путем распределения нагрузки.
- Вы можете ограничить поток сетевого трафика в модули pod и узлы, чтобы повысить безопасность.
- Вы можете настроить трафик входящего трафика для завершения SSL/TLS или маршрутизации нескольких компонентов для более сложных приложений.
В этой статье приводится обзор ключевых понятий сети в приложениях в AKS.
Основы сети Kubernetes
Kubernetes использует виртуальный сетевой уровень для управления доступом внутри и между приложениями или их компонентами:
Узлы Kubernetes и виртуальная сеть: узлы Kubernetes подключены к виртуальной сети. Эта настройка позволяет модулям pod (базовым единицам развертывания в Kubernetes) иметь как входящие, так и исходящие подключения.
Компонент Kube-proxy: kube-proxy выполняется на каждом узле и отвечает за предоставление необходимых сетевых функций.
Что касается конкретных функциональных возможностей Kubernetes:
- Подсистема балансировки нагрузки. Для равномерного распределения сетевого трафика между различными ресурсами можно использовать подсистему балансировки нагрузки.
- Контроллеры входящего трафика: это упрощает маршрутизацию уровня 7, что является важным для направления трафика приложения.
- Управление трафиком исходящего трафика: Kubernetes позволяет управлять исходящим трафиком с узлов кластера и управлять ими.
- Политики сети: эти политики обеспечивают меры безопасности и фильтрацию сетевого трафика в модулях pod.
В контексте платформы Azure:
- Azure упрощает виртуальные сети для кластеров AKS (Служба Azure Kubernetes).
- Создание подсистемы балансировки нагрузки Kubernetes в Azure одновременно настраивает соответствующий ресурс подсистемы балансировки нагрузки Azure.
- При открытии сетевых портов для модулей pod Azure автоматически настраивает необходимые правила группы безопасности сети.
- Azure также может управлять внешними конфигурациями DNS для маршрутизации приложений HTTP, так как устанавливаются новые маршруты входящего трафика.
Виртуальные сети Azure
В AKS можно развернуть кластер, использующий одну из следующих сетевых моделей:
- Наложенная сетевая модель: наложение сети — это наиболее распространенная сетевая модель, используемая в Kubernetes. Модули Pod получают IP-адрес из частной, логически отделяемой CIDR от подсети виртуальной сети Azure, в которой развертываются узлы AKS. Эта модель обеспечивает более простую, улучшенную масштабируемость по сравнению с плоской сетевой моделью.
- Модель неструктурированных сетей: модель плоской сети в AKS назначает IP-адреса модулям pod из подсети из той же виртуальной сети Azure, что и узлы AKS. Любой трафик, покидающий кластеры, не является SNAT, и IP-адрес pod напрямую предоставляется для назначения. Эта модель может быть полезна для таких сценариев, как предоставление IP-адресов pod внешним службам.
Дополнительные сведения о сетевых моделях в AKS см. в статье CNI Networking in AKS.
Контроллеры входящего трафика
При создании службы типа LoadBalancer (распределитель нагрузки) создается базовый ресурс распределителя нагрузки Azure. Подсистема балансировки нагрузки настраивается для распределения трафика к модулям pod, содержащихся в службе на данном порте.
LoadBalancer работает только на уровне 4. На уровне 4 служба не знает о приложениях и не может вносить любые дополнительные рекомендации относительно маршрутизации.
Контроллеры входящего трафика работают на уровне 7 и могут использовать более интеллектуальные правила для распределения трафика приложения. Контроллер входящего трафика обычно используется для передачи трафика HTTP для различных приложений, в зависимости от входящего URL-адреса.
Сравнение параметров входящего трафика
В следующей таблице перечислены различия функций между разными параметрами контроллера входящего трафика:
| Функция | Надстройка маршрутизации приложений | Шлюз приложений для контейнеров | Сетка службы Azure или сетка службы на основе Istio |
|---|---|---|---|
| Контроллер входящего трафика или шлюза | Контроллер входящего трафика NGINX | Шлюз приложений Azure для контейнеров | Шлюз входящего трафика Istio |
| API | API входящего трафика | API входящего трафика и API шлюза | API шлюза |
| Размещение | В кластере | Размещено в Azure | В кластере |
| Масштабирование | Автомасштабирование | Автомасштабирование | Автомасштабирование |
| Балансировка нагрузки | Внутренний или внешний | Внешняя. | Внутренний или внешний |
| Завершение SSL | В кластере | Да: разгрузка и SSL E2E | В кластере |
| Mtls | Н/П | Да для серверной части | Н/П |
| Статический IP-адрес | Н/П | Полное доменное имя | Н/П |
| Хранимые SSL-сертификаты Azure Key Vault | Да | Да | Н/П |
| Интеграция Azure DNS для управления зонами DNS | Да | Да | Н/П |
В следующей таблице перечислены различные сценарии, в которых можно использовать каждый контроллер входящего трафика:
| Параметр входящего трафика | Когда использовать |
|---|---|
| Управляемый NGINX — надстройка маршрутизации приложений | • Размещенные, настраиваемые и масштабируемые контроллеры входящего трафика NGINX в кластере. • Основные возможности балансировки нагрузки и маршрутизации. • Внутренняя и внешняя конфигурация подсистемы балансировки нагрузки. • Конфигурация статических IP-адресов. • Интеграция с Azure Key Vault для управления сертификатами. • Интеграция с зонами Azure DNS для общедоступного и частного управления DNS. • Поддерживает API входящего трафика. |
| Шлюз приложений для контейнеров | • Размещенный шлюз входящего трафика Azure. • Гибкие стратегии развертывания, управляемые контроллером или собственные Шлюз приложений для контейнеров. • Расширенные функции управления трафиком, такие как автоматическая повторная попытка, устойчивость зоны доступности, взаимная проверка подлинности (mTLS) для целевого сервера, разделение трафика или взвешенная циклическая робина и автомасштабирование. • Интеграция с Azure Key Vault для управления сертификатами. • Интеграция с зонами Azure DNS для общедоступного и частного управления DNS. • Поддерживает API-интерфейсы входящего трафика и шлюза. |
| Шлюз входящего трафика Istio | • На основе Envoy при использовании с Istio для сетки служб. • Расширенные функции управления трафиком, такие как ограничение скорости и нарушение цепи. • Поддержка MTLS • поддерживает API шлюза. |
Создание ресурса входящего трафика
Надстройка маршрутизации приложений — это рекомендуемый способ настройки контроллера входящего трафика в AKS. Надстройка маршрутизации приложений — это полностью управляемый контроллер входящего трафика для Служба Azure Kubernetes (AKS), предоставляющий следующие функции:
Простая настройка управляемых контроллеров Ingress NGINX на основе контроллера входящего трафика Kubernetes NGINX.
Интеграция с Azure DNS для управления общедоступными и частными зонами.
Завершение SSL с сертификатами, хранящимися в Azure Key Vault.
Дополнительные сведения о надстройке маршрутизации приложений см. в разделе "Управляемый входящий трафик NGINX" с надстройкой маршрутизации приложений.
Сохранение исходного IP-адреса клиента
Вы также можете настроить контроллер входящего трафика так, чтобы он сохранял исходный IP-адрес клиента в запросах к контейнерам в кластере AKS. Когда клиентский запрос направляется в контейнер в кластере AKS через входной контроллер, исходный IP-адрес этого запроса не будет доступен для целевого контейнера. При включении сохранения IP-адресов источника клиента исходный IP-адрес клиента доступен в заголовке запроса в разделе X-Forwarded-For.
Если вы используете сохранение IP-адресов источника клиента на контроллере входящего трафика, вы не сможете использовать сквозной TLS-трафик. IP-адрес источника клиента и сквозной трафик TLS можно использовать с другими службами, такими как типLoadBalancer (балансировщика нагрузки).
Дополнительные сведения о сохранении IP-адресов источника клиента см. в статье о том, как работает сохранение исходного IP-адреса клиента для служб LoadBalancer в AKS.
Управление исходящим трафиком (исходящего трафика)
Кластеры AKS развертываются в виртуальной сети и имеют исходящие зависимости от служб за пределами этой виртуальной сети. Эти исходящие зависимости почти полностью определены с полными доменными именами (FQDN). По умолчанию кластеры AKS имеют неограниченный исходящий (исходящий) доступ к Интернету, что позволяет узлам и службам, которые вы запускаете для доступа к внешним ресурсам по мере необходимости. При желании можно ограничить исходящий трафик.
Дополнительные сведения см. в разделе "Управление исходящим трафиком" для узлов кластера в AKS.
Группы безопасности сети
Группа безопасности сети фильтрует трафик для виртуальных машин, например для узлов AKS. При создании служб, таких как LoadBalancer, платформа Azure автоматически настраивает все необходимые правила группы безопасности сети.
Для фильтрации трафика для модулей pod в кластере AKS нет необходимости настраивать групповые правила безопасности сети вручную. Вы можете определить все необходимые порты и переадресацию в рамках манифестов службы Kubernetes и позволить платформе Azure создавать или обновлять соответствующие правила.
Чтобы автоматически применять правила фильтрации трафика к модулям pod, вы также можете использовать политики сети.
Дополнительные сведения см. в статье "Фильтрация сетевого трафика групп безопасности сети".
Политики сети
По умолчанию все контейнеры pod в кластере AKS могут отправлять и получать трафик без ограничений. Для повышения безопасности вы можете определить правила, управляющие потоком трафика, например:
- Внутренние приложения предоставляются только для необходимых интерфейсных служб.
- Компоненты базы данных доступны только для уровней приложений, которые к ним подключаются.
Политика сети — это функция Kubernetes, которая позволяет контролировать поток трафика между контейнерами pod. Вы можете разрешить или запретить трафик в pod на основе параметров, таких как назначенные метки, пространство имен или порт трафика. Несмотря на то что группы безопасности сети лучше подходят для узлов AKS, сетевые политики — это более подходящий и более тесно связанный с облаком способ управления потоком трафика для модулей Pod. Поскольку контейнеры pod динамически создаются в кластере AKS, необходимые политики сети могут применяться автоматически.
Дополнительные сведения см. в статье Secure traffic between pods using network policies in Azure Kubernetes Service (AKS) (Защита трафика между контейнерами pod с использованием политик сети в Azure Kubernetes Service (AKS)).
Следующие шаги
Чтобы начать работу с сетью AKS, создайте и настройте кластер AKS с собственными диапазонами IP-адресов, используя kubenet или Azure CNI.
Рекомендации и описания лучших практик представлены в статье Рекомендации по сетевому подключению и безопасности в AKS.
Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях: