Основные понятия сети контейнеров

Статья
04/27/2023

Область применения: AKS в Azure Stack HCI 22H2, AKS в Windows Server

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

Более сложные приложения требуют настройку входящего трафика для маршрутизации из нескольких компонентов и подключений SSL/TLS. Для обеспечения безопасности также может потребоваться ограничить поток сетевого трафика в модули pod и узлы или между ними.

В этой статье рассматриваются основные понятия, обеспечивающие сеть для приложений в AKS, включенных с помощью Arc:

Службы Kubernetes
Контроллер входящего трафика
Политики сети

Службы Kubernetes

Чтобы упростить конфигурацию сети для рабочих нагрузок приложений, Kubernetes использует службы для логического объединения набора модулей pod и обеспечения сетевого подключения. Доступны следующие типы служб:

IP-адрес кластера: создает внутренний IP-адрес для использования в кластере Kubernetes. Используйте IP-адрес кластера для внутренних приложений, которые поддерживают другие рабочие нагрузки в кластере.

NodePort: создает сопоставление портов на базовом узле, которое позволяет напрямую обращаться к приложению с помощью IP-адреса и порта узла.

LoadBalancer. Создает ресурс Azure Load Balancer, настраивает внешний IP-адрес и подключает запрошенные модули pod к внутреннему пулу подсистемы балансировки нагрузки. Чтобы разрешить трафику пользователей достичь приложения, необходимо создать правила балансировки загрузки для конкретных портов.

Для другого контроля и маршрутизации входящего трафика можно использовать контроллер входящего трафика.

Примечание

При развертывании целевого кластера, который совместно использует сеть с другим целевым кластером, существует вероятность конфликта IP-адресов подсистемы балансировки нагрузки. Это может произойти, если развернуть две рабочие нагрузки, использующие разные порты, в целевых кластерах, использующих один и тот же AksHciClusterNetwork объект. Из-за того, как IP-адреса и сопоставления портов выделяются внутри прокси-сервера высокой доступности, это может привести к дублированию назначения IP-адресов. В этом случае одна или обе рабочие нагрузки могут столкнуться с проблемами с случайным сетевым подключением до повторного развертывания рабочих нагрузок. При повторном развертывании рабочих нагрузок можно либо использовать один и тот же порт, который приводит к тому, что каждая рабочая нагрузка получает отдельный IP-адрес службы, либо повторно развернуть рабочие нагрузки в целевых кластерах, использующих разные AksHciClusterNetwork объекты.

ExternalName: создает определенную запись DNS для упрощения доступа к приложению. IP-адреса для подсистем балансировки нагрузки и служб могут быть внутренними или внешними в зависимости от общей конфигурации сети и могут быть динамически назначены. Или можно указать существующий статический IP-адрес для использования. Существующий статический IP-адрес часто привязывается к записи DNS. Внутренние средства балансировки нагрузки назначаются только для частных IP-адресов, поэтому они не доступны из сети Интернет.

Основы работы с сетью Kubernetes в Azure Stack HCI

Чтобы предоставить доступ к приложениям или разрешить компонентам приложений взаимодействовать друг с другом, Kubernetes предоставляет уровень абстракции для виртуальной сети. Узлы Kubernetes подключены к виртуальной сети и могут обеспечить входящее и исходящее подключение для модулей pod. Компонент kube-proxy , работающий на каждом узле, предоставляет эти сетевые функции.

В Kubernetes службы логически группировать модули pod, чтобы разрешить:

Прямой доступ через один IP-адрес или DNS-имя и конкретный порт.
Распределите трафик с помощью подсистемы балансировки нагрузки между несколькими модулями pod, в котором размещена та же служба или приложение.

Платформа Azure Stack HCI также помогает упростить виртуальные сети для AKS в кластерах Azure Stack HCI, предоставляя "подложную" сеть с высоким уровнем доступности. При создании кластера AKS мы также создаем и настраиваем базовый HAProxy ресурс подсистемы балансировки нагрузки. При развертывании приложений в кластере Kubernetes IP-адреса настраиваются для модулей pod и служб Kubernetes в качестве конечных точек в этой подсистеме балансировки нагрузки.

Ресурсы IP-адресов

Чтобы упростить конфигурацию сети для рабочих нагрузок приложений, AKS Arc назначает IP-адреса следующим объектам в развертывании:

Сервер API кластера Kubernetes. Сервер API является компонентом уровня управления Kubernetes, который предоставляет API Kubernetes. Сервер API — это интерфейс для уровня управления Kubernetes. Статические IP-адреса всегда выделяются серверам API независимо от базовой сетевой модели.
Узлы Kubernetes (виртуальные машины): кластер Kubernetes состоит из набора рабочих машин, называемых узлами, и на узлах размещаются контейнерные приложения. В дополнение к узлам уровня управления каждый кластер имеет по крайней мере один рабочий узел. Для кластера AKS узлы Kubernetes настраиваются как виртуальные машины. Эти виртуальные машины создаются как высокодоступные виртуальные машины в Azure Stack HCI. Дополнительные сведения см. в статье Основные понятия сети узлов.
Службы Kubernetes: в Kubernetes службы логически группировать IP-адреса pod, чтобы обеспечить прямой доступ через один IP-адрес или DNS-имя к определенному порту. Службы также могут распределять трафик с помощью подсистемы балансировки нагрузки. Статические IP-адреса всегда выделяются службам Kubernetes независимо от базовой сетевой модели.
Подсистемы балансировки нагрузки HAProxy. HAProxy — это подсистема балансировки нагрузки TCP/HTTP и прокси-сервер, который распределяет входящие запросы между несколькими конечными точками. Каждый кластер рабочей нагрузки в развертывании AKS в Azure Stack HCI имеет подсистему балансировки нагрузки HAProxy, развернутую и настроенную в качестве специализированной виртуальной машины.
Локальная облачная служба Майкрософт. Это поставщик облачных служб Azure Stack HCI, который позволяет создавать и управлять виртуализированной средой, в которой размещается Kubernetes в локальном кластере Azure Stack HCI или кластере Windows Server. Сетевая модель, за которой следует кластер Azure Stack HCI или Windows Server, определяет метод выделения IP-адресов, используемый локальной облачной службой Майкрософт. Дополнительные сведения о сетевых концепциях, реализованных локальной облачной службой Майкрософт, см. в статье Основные понятия сети узлов.

Сети Kubernetes

В AKS в Azure Stack HCI можно развернуть кластер, использующий одну из следующих моделей сети:

Фланелевые сети наложения. Сетевые ресурсы обычно создаются и настраиваются при развертывании кластера.
Сеть Project Calico. Эта модель предлагает дополнительные сетевые функции, такие как сетевые политики и управление потоками.

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

Дополнительные сведения о наложении сети см. в статье Общие сведения о наложении сети Kubernetes для Windows.

Дополнительные сведения о подключаемом модуле и политиках сети Calico проверка о начале работы с политикой сети Calico.

Сравнение сетевых моделей

Фланель

Flannel — это уровень виртуальной сети, разработанный специально для контейнеров. Flannel создает плоскую сеть, которая перекрывает сеть узлов. Всем контейнерам и модулям pod назначается один IP-адрес в этой сети наложения, и они взаимодействуют напрямую, подключаясь к IP-адресу друг друга.

Calico

Calico — это сетевое решение с открытым кодом и сетевой безопасности для контейнеров, виртуальных машин и собственных рабочих нагрузок на основе узлов. Calico поддерживает несколько плоскостей данных, включая плоскость данных Linux eBPF, плоскость сетевых данных Linux и плоскость данных Windows HNS.

Характеристики

Возможности	Фланель	Calico
Политики сети	Нет	Да
IPv6	Нет	Да
Используемые слои	L2 (VxLAN)	L2 (VxLAN)
Развертывание кластера в существующей или новой виртуальной сети	Да	Да
Поддержка Windows	Да	Да
подключение Pod-Pod	Да	Да
Подключение pod-VM, виртуальная машина в той же сети	Нет	Да
Подключение pod-VM, виртуальная машина в другой сети	Да	Да
Службы Kubernetes	Да	Да
Предоставление доступа через Подсистему балансировки нагрузки	Да	Да
Сети	Множество сетей в одном кластере с несколькими управляющей программы	Множество сетей в одном кластере
Развертывание	Linux: DaemonSet	Linux: DaemonSet
	Windows: служба	Windows: служба
Командная строка	нет	calicoctl

Важно!

В настоящее время по умолчанию используется Calico в сетевом режиме наложения. Чтобы включить Flannel, используйте -primaryNetworkPlugin параметр New-AksHciCluster команды PowerShell и укажите flannel в качестве значения . Это значение нельзя изменить после развертывания кластера и применяется к узлам кластера Windows и Linux.

Ниже приведен пример:

New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'

Дальнейшие действия

В этой статье рассматриваются основные понятия сети для контейнеров в узлах AKS в Azure Stack HCI. Дополнительные сведения о концепциях AKS в Azure Stack HCI см. в следующих статьях: