Основные понятия сети контейнеров
Область применения: 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, настраивает внешний IP-адрес и подключает запрошенные модули pod к внутреннему пулу подсистемы балансировки нагрузки. Чтобы разрешить трафику пользователей достичь приложения, необходимо создать правила балансировки загрузки для конкретных портов.
Для другого управления и маршрутизации входящего трафика можно использовать контроллер входящего трафика.
Примечание.
При развертывании целевого кластера, который использует сеть с другим целевым кластером, существует возможность конфликта IP-адресов подсистемы балансировки нагрузки.
Это может произойти при развертывании двух рабочих нагрузок, использующих разные порты в целевых кластерах, которые совместно используют один и тот же AksHciClusterNetwork объект. Из-за того, как IP-адреса и сопоставления портов выделяются внутри прокси-сервера высокого уровня доступности, это может привести к дубликату назначения IP-адресов. Если это происходит, одна или обе рабочие нагрузки могут столкнуться с проблемами случайного сетевого подключения, пока не будет повторно развернуты рабочие нагрузки. При повторном развертывании рабочих нагрузок можно использовать один и тот же порт, который приводит к получению каждого из рабочих нагрузок отдельного IP-адреса службы или повторно развернуть рабочие нагрузки в целевых кластерах, использующих разные AksHciClusterNetwork объекты.
ExternalName: создает определенную запись DNS для упрощения доступа к приложению. IP-адреса для подсистем балансировки нагрузки и служб могут быть внутренними или внешними в зависимости от общей настройки сети и могут быть динамически назначены. Кроме того, можно указать существующий статический IP-адрес для использования. Существующий статический IP-адрес часто привязан к записи DNS. Внутренние средства балансировки нагрузки назначаются только для частных IP-адресов, поэтому они не доступны из сети Интернет.
Основы сети Kubernetes в локальной среде Azure
Чтобы предоставить доступ к приложениям или разрешить компонентам приложений взаимодействовать друг с другом, Kubernetes предоставляет уровень абстракции для виртуальной сети. Узлы Kubernetes подключены к виртуальной сети и могут предоставлять входящие и исходящие подключения для модулей pod. Компонент kube-proxy , работающий на каждом узле, предоставляет эти сетевые функции.
В Kubernetes службы логически группирует модули pod, чтобы разрешить:
- Прямой доступ через один IP-адрес или DNS-имя и определенный порт.
- Распределяйте трафик с помощью подсистемы балансировки нагрузки между несколькими модулями pod, на котором размещена одна служба или приложение.
Локальная платформа Azure также помогает упростить виртуальные сети для AKS в локальных кластерах Azure, предоставляя сеть "подложки" высокодоступной.
При создании кластера 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, дополнительные сведения см . в разделе "Основные понятия сети узлов".
- Службы Kubernetes: в Kubernetes службы логически группируйте IP-адреса pod, чтобы разрешить прямой доступ через один IP-адрес или DNS-имя на определенном порту. Службы также могут распределять трафик с помощью подсистемы балансировки нагрузки. Статические IP-адреса всегда выделяются службам Kubernetes независимо от базовой сетевой модели.
- Подсистемы балансировки нагрузки HAProxy: HAProxy — это подсистема балансировки нагрузки TCP/HTTP и прокси-сервер, который распределяет входящие запросы по нескольким конечным точкам. Каждый кластер рабочей нагрузки в развертывании AKS в локальном развертывании Azure имеет подсистему балансировки нагрузки HAProxy, развернутую и настроенную в качестве специализированной виртуальной машины.
- Локальная облачная служба Майкрософт: это локальный поставщик облачных служб Azure, который позволяет создавать и управлять виртуализированной средой, в которой размещается Kubernetes в локальном кластере Azure или кластере Windows Server. Сетевая модель, за которой следует кластер Azure Local или Windows Server, определяет метод выделения IP-адресов, используемый локальной облачной службой Майкрософт. Дополнительные сведения о сетевых концепциях, реализованных локальной облачной службой Майкрософт, см . в разделе "Основные понятия сети узлов".
Сети Kubernetes
В AKS в Локальной среде Azure можно развернуть кластер, использующий одну из следующих сетевых моделей:
- Сеть наложения flannel — сетевые ресурсы обычно создаются и настраиваются при развертывании кластера.
- Сеть Project Calico . Эта модель предлагает дополнительные сетевые функции, такие как политики сети и управление потоками.
Обе реализации сети используют модель конфигурации сети наложения, которая предоставляет назначение IP-адресов, отключаемое от остальной части сети центра обработки данных.
Дополнительные сведения о наложении сетей см. в статье "Введение в kubernetes Overlay Networking для Windows".
Дополнительные сведения о подключаемом модуле и политиках сети Calico см. в разделе о начале работы с политикой сети Calico.
Сравнение сетевых моделей
Фланель
Примечание.
Фланнелл CNI был снят в отставку в декабре 2023 года.
Flannel — это уровень виртуальной сети, разработанный специально для контейнеров. Flannel создает плоскую сеть, которая накладывает сеть узла. Все контейнеры и модули pod назначаются одним IP-адресом в этой сети наложения и взаимодействуют напрямую, подключаясь к IP-адресу друг друга.
Calico
Calico — это решение для сети с открытым исходным кодом и сетевой безопасности для контейнеров, виртуальных машин и собственных рабочих нагрузок на основе узлов. Calico поддерживает несколько плоскостей данных, включая плоскость данных Linux eBPF, сетевую плоскость Linux и плоскость данных Windows HNS.
Возможности
| Возможность | Фланель | Calico |
|---|---|---|
| Политики сети | No | Да |
| IPv6 | No | Да |
| Используемые слои | L2 (VxLAN) | L2 (VxLAN) |
| Развертывание кластера в существующей или новой виртуальной сети | Да | Да |
| Поддержка Windows | Да | Да |
| Подключение Pod-Pod | Да | Да |
| Подключение pod-VM, виртуальная машина в той же сети | No | Да |
| Подключение 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. Дополнительные сведения об AKS в локальных концепциях Azure см. в следующих статьях: