Основные понятия сети для приложений в Служба 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 можно развернуть кластер, использующий одну из следующих сетевых моделей:
Сеть Kubenet
Ресурсы сети обычно создаются и настраиваются при развертывании кластера AKS.
Сетевые интерфейсы контейнеров Azure (CNI)
кластер AKS подключен к существующим ресурсам и конфигурациям виртуальной сети.
Сетевое взаимодействие с kubenet (базовое)
Сетевой параметр kubenet — это конфигурация сети по умолчанию для создания кластера AKS. С kubenet:
- Узлы получают IP-адрес из подсети виртуальной сети Azure.
- Объекты pod получают IP-адрес из адресного пространства, логически отличного от подсети узлов виртуальной сети Azure.
- Преобразование сетевых адресов (NAT) настраивается таким образом, чтобы модули pod могли получить доступ к ресурсам в виртуальной сети Azure.
- Исходный IP-адрес трафика преобразуется в первичный IP-адрес узла.
Узлы используют подключаемый модуль Kubernetes kubenet. Вы можете предоставить платформе Azure разрешение на создание и настройку виртуальных сетей или выполнить развертывание кластера AKS в имеющуюся подсеть виртуальной сети.
Только узлы получают маршрутизируемый IP-адрес. В модулях pod NAT используется для связи с другими ресурсами за пределами кластера AKS. Такой подход уменьшает количество IP-адресов, которые необходимо зарезервировать в пространстве сети для модулей pod.
Примечание.
Хотя kubenet является параметром сети по умолчанию для кластера AKS для создания виртуальной сети и подсети, для рабочих развертываний не рекомендуется. Для большинства рабочих развертываний следует планировать и использовать сеть Azure CNI из-за ее превосходных характеристик масштабируемости и производительности.
Дополнительные сведения см. в статье Использование сети kubenet с собственными диапазонами IP-адресов в Службе Azure Kubernetes (AKS).
Сетевое взаимодействие с Azure CNI (расширенное)
Благодаря Azure CNI каждый модуль pod получает IP-адрес из подсети, и к нему можно получить доступ напрямую. Эти IP-адреса должны быть уникальными во всей сети, и их следует планировать заранее. Для каждого узла предусмотрен параметр конфигурации, в котором указывается максимальное число поддерживаемых объектов pod. Затем на каждом узле заранее резервируется соответствующее число IP-адресов. Такой подход может привести к исчерпанию IP-адресов или необходимости перестроить кластеры в более крупной подсети по мере роста требований приложения, поэтому важно правильно планировать. Чтобы избежать этих проблем планирования, можно включить функцию сети Azure CNI для динамического распределения IP-адресов и расширенной поддержки подсети.
Примечание.
Из-за ограничений Kubernetes имя группы ресурсов, имя виртуальная сеть и имя подсети должно быть 63 символами или меньше.
В отличие от kubenet, трафик к конечным точкам в той же виртуальной сети не преобразуется (NAT) в основной IP-адрес узла. Адресом источника для трафика в виртуальной сети является IP-адрес модуля pod. Трафик, который является внешним по отношению к виртуальной сети, по-прежнему преобразуется через NAT в основной IP-адрес узла.
Узлы используют подключаемый модуль Kubernetes для Azure CNI.
Дополнительные сведения см. в статье о настройке Azure CNI для кластера AKS.
Сеть наложения Azure CNI
Наложение Azure CNI представляет собой эволюцию Azure CNI, решение проблем масштабируемости и планирования, возникающих из-за назначения IP-адресов виртуальной сети модулям pod. Наложение Azure CNI назначает частные IP-адреса CIDR модулям pod. Частные IP-адреса отделены от виртуальной сети и могут использоваться повторно в нескольких кластерах. Наложения Azure CNI могут масштабироваться за пределы 400 узлов, примененных в кластерах Kubenet. Для большинства кластеров рекомендуется использовать наложение Azure CNI.
Azure CNI под управлением Cilium
Azure CNI powered by Cilium использует Cilium для обеспечения высокопроизводительной сети, наблюдаемости и применения политик сети. Он интегрируется изначально с azure CNI Overlay для управления масштабируемыми IP-адресами (IPAM).
Кроме того, Cilium применяет политики сети по умолчанию, не требуя отдельной подсистемы сетевой политики. Azure CNI Powered by Cilium может масштабироваться за пределы диспетчера сетевых политик Azure 250 узлов / 20-K pod с помощью программ eBPF и более эффективной структуры объектов API.
Azure CNI Powered by Cilium — это рекомендуемый вариант для кластеров, требующих применения политики сети.
Использование собственного CNI
Можно установить в AKS не Microsoft CNI с помощью собственной функции CNI .
Сравнение сетевых моделей
Обе модели (kubenet и Azure CNI) обеспечивают сетевое подключение к кластерам AKS. Каждая из этих моделей имеет свои преимущества и недостатки. На высоком уровне следует учитывать следующие соображения.
kubenet
- Экономит пространство IP-адресов.
- Использует внутренние или внешние подсистемы балансировки нагрузки Kubernetes для доступа к модулям pod извне кластера.
- Необходимо вручную управлять определяемыми пользователем маршрутами (UDR) и поддерживать их.
- Не более 400 узлов на кластер.
Azure CNI
- Модули Pod получают полное подключение к виртуальной сети и могут быть достижимы напрямую через их частный IP-адрес из подключенных сетей.
- Требуется больше пространства для IP-адресов.
| Сетевая модель | Когда использовать |
|---|---|
| Kubenet | • Беседа в пространстве IP-адресов является приоритетом. • Простая конфигурация. • Менее 400 узлов на кластер. • Внутренние или внешние подсистемы балансировки нагрузки Kubernetes достаточно для достижения модулей pod извне кластера. • Допустимо управлять и поддерживать определяемые пользователем маршруты вручную. |
| Azure CNI | • Для модулей pod требуется полное подключение к виртуальной сети. • Требуются дополнительные функции AKS (например, виртуальные узлы). • Доступно достаточное пространство IP-адресов. • Требуется подключение pod и pod к виртуальной машине. • Внешние ресурсы должны напрямую обращаться к модулям pod. • Требуются политики сети AKS. |
| Наложение Azure CNI | • Нехватка IP-адресов является проблемой. • Достаточно масштабирование до 1000 узлов и 250 модулей pod на узел. • Дополнительный прыжок для подключения pod является приемлемым. • Упрощенная конфигурация сети. • Требования исходящего трафика AKS можно выполнить. |
Между kubenet и Azure CNI существуют следующие различия в работе.
| Возможность | Kubenet | Azure CNI | Наложение Azure CNI | Azure CNI под управлением Cilium |
|---|---|---|---|---|
| Развертывание кластера в существующей или новой виртуальной сети | Поддерживается — UDR применяются вручную | Поддерживается | Поддерживаемые | Поддерживается |
| Соединение Pod — Pod | Поддерживается | Поддерживаемые | Поддерживаемые | Поддерживается |
| Соединение Pod — виртуальная машина; виртуальная машина в той же виртуальной сети | Работает при инициации модулем pod | Работает обоими способами | Работает при инициации модулем pod | Работает при инициации модулем pod |
| Соединение Pod — виртуальная машина; виртуальная машина в одноранговой виртуальной сети | Работает при инициации модулем pod | Работает обоими способами | Работает при инициации модулем pod | Работает при инициации модулем pod |
| Локальный доступ с использованием VPN или Express Route | Работает при инициации модулем pod | Работает обоими способами | Работает при инициации модулем pod | Работает при инициации модулем pod |
| Доступ к ресурсам, защищенным конечными точками службы | Поддерживается | Поддерживаемые | Поддерживается | |
| Предоставление служб Kubernetes с помощью балансировщика нагрузки, Шлюза приложений или контроллера входящего трафика | Поддерживается | Поддерживаемые | Поддерживается | Те же ограничения при использовании режима наложения |
| Поддержка пулов узлов Windows | Не поддерживается | Поддерживается | Поддерживается | Доступно только для Linux, а не для Windows. |
| Azure DNS по умолчанию и частные зоны | Поддерживается | Поддерживаемые | Поддерживается |
Дополнительные сведения о Azure CNI и kubenet, а также о том, какой вариант лучше всего подходит для вас, см. в статье Настройка сети Azure CNI в AKS и использование сети kubenet в AKS.
Область поддержки между сетевыми моделями
Независимо от используемой модели сети, как kubenet, так и Azure CNI можно развернуть одним из следующих способов.
- Платформа Azure может автоматически создавать и настраивать ресурсы виртуальной сети при создании кластера AKS.
- Вы можете вручную создать и настроить ресурсы виртуальной сети и присоединить их к этим ресурсам при создании кластера AKS.
Хотя такие возможности, как конечные точки службы или определяемые пользователем маршруты, поддерживаются как в kubenet, так и в Azure CNI, политики поддержки для AKS определяют возможности выполнения изменений. Например:
- Если вы вручную создаете ресурсы виртуальной сети для кластера AKS, вы получите поддержку при настройке собственных UDRs или служебных конечных точек.
- Если платформа Azure автоматически создает ресурсы виртуальной сети для кластера AKS, то невозможно будет вручную изменить ресурсы, управляемые AKS, чтобы настроить собственные UDR и служебные конечные точки.
Контроллеры входящего трафика
При создании службы типа 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 приведены в следующих статьях: