Обзор сети CNI Служба Azure Kubernetes (AKS)
Kubernetes использует подключаемые модули интерфейса сети контейнеров (CNI) для управления сетями в кластерах Kubernetes. ЦНС отвечают за назначение IP-адресов модулям pod, маршрутизацию сети между модулями pod, маршрутизацию служб Kubernetes и многое другое.
AKS предоставляет несколько подключаемых модулей CNI, которые можно использовать в кластерах в зависимости от требований к сети.
Сетевые модели в AKS
Выбор подключаемого модуля CNI для кластера AKS в значительной степени зависит от оптимальной сетевой модели. Каждая модель имеет свои собственные преимущества и недостатки, которые следует учитывать при планировании кластера AKS.
AKS использует две основные сетевые модели: наложение сети и плоскую сеть.
Обе сетевые модели имеют несколько поддерживаемых параметров подключаемого модуля CNI. Основными различиями между моделями являются назначение IP-адресов pod и способ выхода трафика из кластера.
Наложение сетей
Наложение сети — это наиболее распространенная сетевая модель, используемая в Kubernetes. В сетях наложения модули pod получают IP-адрес из частного, логически отделяя CIDR от подсети виртуальной сети Azure, в которой развертываются узлы AKS. Это позволяет упростить и часто лучше масштабируемость, чем модель плоской сети.
В сетях наложения модули pod могут напрямую взаимодействовать друг с другом. Трафик, покидающий кластер, — исходный сетевой адрес, преобразованный (SNAT-d) на IP-адрес узла, и входящий IP-трафик pod направляется через определенную службу, например подсистему балансировки нагрузки. Это означает, что IP-адрес pod скрыт за IP-адресом узла. Этот подход сокращает количество IP-адресов виртуальной сети, необходимых для кластеров.
Служба Azure Kubernetes предоставляет следующие подключаемые модули CNI для наложения сети:
- Azure CNI Overlay — рекомендуемый подключаемый модуль CNI для большинства сценариев.
- kubenet, устаревшая модель наложения CNI.
Неструктурированные сети
В отличие от сети наложения, модель неструктурированных сетей в AKS назначает IP-адреса модулям pod из подсети из той же виртуальной сети Azure, что и узлы AKS. Это означает, что трафик, покидающий кластеры, не является SNAT, а IP-адрес pod напрямую предоставляется для назначения. Это может быть полезно для некоторых сценариев, таких как при необходимости предоставлять IP-адреса pod внешним службам.
Служба Azure Kubernetes предоставляет два подключаемых модуля CNI для неструктурированных сетей. Эта статья не содержит подробных сведений о каждом параметре подключаемого модуля. Дополнительные сведения см. в связанной документации:
- Подсеть Pod Pod Azure CNI— рекомендуемый подключаемый модуль CNI для сценариев с неструктурированными сетями.
- Подсеть узла CNI Azure, устаревшая модель сети CNI обычно рекомендует использовать только в том случае, если для кластера требуется управляемая виртуальная сеть.
Выбор CNI
При выборе CNI следует учитывать несколько факторов. Каждая сетевая модель имеет свои собственные преимущества и недостатки, и лучший выбор для вашего кластера будет зависеть от ваших конкретных требований.
Выбор сетевой модели
Две основные сетевые модели в AKS — наложение и плоские сети.
Наложение сетей:
- Экономия пространства IP-адресов виртуальной сети с помощью логически отдельных диапазонов CIDR для модулей pod.
- Максимальная поддержка масштабирования кластера.
- Простое управление IP-адресами.
Неструктурированные сети:
- Модули Pod получают полное подключение к виртуальной сети и могут быть напрямую доступны через частный IP-адрес из подключенных сетей.
- Требует большого, не фрагментированного IP-адреса виртуальной сети.
Сравнение вариантов использования
При выборе сетевой модели рассмотрите варианты использования для каждого подключаемого модуля CNI и тип используемой сетевой модели:
| Подключаемый модуль CNI | Сетевая модель | Основные моменты вариантов использования |
|---|---|---|
| Наложение Azure CNI | Наложение | — Лучше всего подходит для сохранения IP-адресов виртуальной сети. — максимальное количество узлов, поддерживаемое API Server + 250 модулей pod на узел — упрощенная конфигурация -Нет прямого доступа к IP-адресу внешнего pod |
| Подсеть Pod Pod Azure CNI | Фиксированная | — прямой доступ к внешнему модулем pod — режимы эффективного использования IP-адресов виртуальной сети или поддержки больших масштабируемых кластеров (предварительная версия) |
| Kubenet (устаревшая версия) | Наложение | — Приоритеты сохранения IP-адресов — ограниченное масштабирование — ручное управление маршрутами |
| Подсеть узла CNI Azure (устаревшая версия) | Фиксированная | — прямой доступ к внешнему модулем pod — упрощенная конфигурация — ограниченное масштабирование — неэффективное использование IP-адресов виртуальной сети |
Сравнение возможностей
Вы также можете сравнить функции каждого подключаемого модуля CNI. В следующей таблице представлено высокоуровневое сравнение функций, поддерживаемых каждым подключаемым модулем CNI:
| Функция | Наложение Azure CNI | Подсеть Pod Pod Azure CNI | Подсеть узла CNI Azure (устаревшая версия) | Kubenet |
|---|---|---|---|---|
| Развертывание кластера в существующей или новой виртуальной сети | Поддерживается | Поддерживаемые | Поддерживается | Поддерживается— UDR вручную |
| Подключение pod-VM с виртуальной машиной в одной или одноранговой виртуальной сети | Модуль Pod, инициированный | Оба способа | Оба способа | Модуль Pod, инициированный |
| Локальный доступ через VPN/Express Route | Модуль Pod, инициированный | Оба способа | Оба способа | Модуль Pod, инициированный |
| Доступ к конечным точкам службы | Поддерживается | Поддерживаемые | Поддерживаемые | Поддерживается |
| Предоставление служб с помощью подсистемы балансировки нагрузки | Поддерживается | Поддерживаемые | Поддерживаемые | Поддерживается |
| Предоставление служб с помощью шлюза приложений | Сейчас не поддерживаются: | Поддерживается | Поддерживаемые | Поддерживается |
| Предоставление служб с помощью контроллера входящего трафика | Поддерживается | Поддерживаемые | Поддерживаемые | Поддерживается |
| пулы узлов Windows; | Поддерживается | Поддерживаемые | Поддерживается | Не поддерживается |
| Azure DNS по умолчанию и частные зоны | Поддерживается | Поддерживаемые | Поддерживаемые | Поддерживается |
| Общий доступ к подсети виртуальной сети в нескольких кластерах | Поддерживается | Поддерживаемые | Поддерживается | Не поддерживается |
Область поддержки между сетевыми моделями
В зависимости от используемого CNI ресурсы виртуальной сети кластера можно развернуть одним из следующих способов:
- Платформа Azure может автоматически создавать и настраивать ресурсы виртуальной сети при создании кластера AKS. например, в наложении Azure CNI, подсети узла CNI Azure и Kubenet.
- Вы можете вручную создать и настроить ресурсы виртуальной сети и присоединить их к этим ресурсам при создании кластера AKS.
Хотя поддерживаются такие возможности, как конечные точки службы или определяемые пользователем ресурсы, политики поддержки ДЛЯ AKS определяют, какие изменения можно внести. Например:
- Если вы вручную создаете ресурсы виртуальной сети для кластера AKS, вы получите поддержку при настройке собственных UDRs или служебных конечных точек.
- Если платформа Azure автоматически создает ресурсы виртуальной сети для кластера AKS, то невозможно будет вручную изменить ресурсы, управляемые AKS, чтобы настроить собственные UDR и служебные конечные точки.
Необходимые компоненты
При планировании конфигурации сети для AKS следует учитывать несколько требований и рекомендаций.
- Виртуальная сеть для кластера AKS должна разрешать исходящее подключение к Интернету.
- Кластеры AKS не могут использовать
169.254.0.0/16,172.30.0.0/16172.31.0.0/16или192.0.2.0/24для диапазона адресов службы Kubernetes, диапазона адресов pod или диапазона адресов виртуальной сети кластера. - В сценариях виртуальной сети BYO удостоверение кластера, используемое кластером AKS, должно иметь по крайней мере разрешения участника сети в подсети в виртуальной сети. Если вы хотите определить пользовательскую роль вместо использования встроенной роли участника сети, требуются следующие разрешения:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(требуется только в том случае, если вы определяете собственные подсети и идентификаторы CIDR)
- Подсеть, назначенная пулу узлов AKS, не может быть делегированной подсетью.
- AKS не применяет группы безопасности сети (NSG) к своей подсети и не изменяет ни одну из групп безопасности сети, связанных с этой подсетью. Если вы предоставляете свою собственную подсеть и добавляете группы безопасности сети, связанные с этой подсетью, необходимо убедиться, что правила безопасности в группах безопасности сети разрешают трафик в пределах диапазона CIDR узла. Дополнительные сведения см. в разделе Группы безопасности сети.
Next Steps
Azure Kubernetes Service