Требования к планированию IP-адресов
Область применения: Локальная версия Azure, версия 23H2
Планирование IP-адресов для AKS, включенное Azure Arc, включает проектирование сети, которая поддерживает приложения, пулы узлов, сети pod, обмен данными о службах и внешний доступ. В этой статье рассматриваются некоторые ключевые аспекты эффективного планирования IP-адресов и минимальное количество IP-адресов, необходимых для развертывания AKS в рабочей среде. Перед чтением этой статьи ознакомьтесь с основными понятиями и требованиями к сети AKS.
Планирование простых IP-адресов для кластеров и приложений Kubernetes
В следующем сценарии вы зарезервируете IP-адреса из одной сети для кластеров и служб Kubernetes. Этот пример является самым простым и простым сценарием назначения IP-адресов.
| Требование IP-адреса | Минимальное количество IP-адресов | Как и где сделать это резервирование |
|---|---|---|
| IP-адреса виртуальных машин AKS Arc | Зарезервируйте один IP-адрес для каждого рабочего узла в кластере Kubernetes. Например, если вы хотите создать 3 пула узлов с 3 узлами в каждом пуле узлов, вам потребуется 9 IP-адресов в пуле IP-адресов. | Резервируйте IP-адреса через пулы IP-адресов в логической сети виртуальной машины Arc. |
| IP-адреса обновления версии AKS Arc K8s | Так как AKS Arc выполняет последовательное обновление, зарезервировать один IP-адрес для каждого кластера AKS Arc для операций обновления версий Kubernetes. | Резервируйте IP-адреса через пулы IP-адресов в логической сети виртуальной машины Arc. |
| IP-адрес плоскости управления | Зарезервируйте один IP-адрес для каждого кластера Kubernetes в вашей среде. Например, если вы хотите создать 5 кластеров в общей сложности, зарезервировать 5 IP-адресов, по одному для каждого кластера Kubernetes. | Резервируйте IP-адреса через пулы IP-адресов в логической сети виртуальной машины Arc. |
| IP-адреса подсистемы балансировки нагрузки | Количество зарезервированных IP-адресов зависит от модели развертывания приложения. В качестве отправной точки можно зарезервировать один IP-адрес для каждой службы Kubernetes. | Резервируйте IP-адреса в той же подсети, что и логическая сеть виртуальной машины Arc, но за пределами пула IP-адресов. |
Пример пошагового руководства по резервированию IP-адресов для кластеров и приложений Kubernetes
Джейн — это ИТ-администратор, который только начинается с AKS, включенного в Azure Arc. Джейн хочет развернуть два кластера Kubernetes: кластер Kubernetes A и кластер Kubernetes B в локальном кластере Azure. Джейн также хочет запустить приложение для голосования поверх кластера A. Это приложение содержит три экземпляра интерфейсного пользовательского интерфейса, работающего в двух кластерах и одном экземпляре серверной базы данных. Все кластеры и службы AKS выполняются в одной сети с одной подсетью.
- Кластер Kubernetes A имеет 3 узла уровня управления и 5 рабочих узлов.
- Кластер Kubernetes B имеет 1 узел уровня управления и 3 рабочих узла.
- 3 экземпляра интерфейсного пользовательского интерфейса (порт 443).
- 1 экземпляр серверной базы данных (порт 80).
На основе предыдущей таблицы Джейн должна зарезервировать 19 IP-адресов в подсети Джейн:
- 8 IP-адресов для виртуальных машин узла AKS Arc в кластере A (один IP-адрес на виртуальную машину узла K8s).
- 4 IP-адреса для виртуальных машин узла AKS Arc в кластере B (один IP-адрес на виртуальную машину узла K8s).
- 2 IP-адреса для выполнения операции обновления AKS Arc (один IP-адрес для кластера AKS Arc).
- 2 IP-адреса для плоскости управления AKS Arc (один IP-адрес для кластера AKS Arc)
- 3 IP-адреса для службы Kubernetes (один IP-адрес для каждого экземпляра внешнего пользовательского интерфейса, так как все они используют один и тот же порт. Серверная база данных может использовать любой из трех IP-адресов, если он использует другой порт).
Продолжая использовать этот пример и добавив его в следующую таблицу, вы получите следующее:
| Параметр | Число IP-адресов | Как и где сделать это резервирование |
|---|---|---|
| Виртуальные машины AKS Arc, обновления версий K8s и IP-адрес плоскости управления | Резервировать 16 IP-адресов | Сделайте это резервирование с помощью пулов IP-адресов в локальной логической сети Azure. |
| IP-адреса подсистемы балансировки нагрузки | 3 IP-адрес для служб Kubernetes для приложения для голосования Джейн. | Эти IP-адреса используются при установке подсистемы балансировки нагрузки в кластерЕ A. Вы можете использовать расширение MetalLB Arc или использовать собственный сторонний балансировщик нагрузки. Убедитесь, что этот IP-адрес находится в той же подсети, что и логическая сеть Arc, но за пределами пула IP-адресов, определенного в логической сети виртуальной машины Arc. |
Примеры команд CLI для резервирования IP-адресов для кластеров и приложений Kubernetes
В этом разделе описывается набор команд Джейн для ее сценария. Сначала создайте логическую сеть с пулом IP-адресов с не менее 16 IP-адресов. Мы создали пул IP-адресов с 20 IP-адресами, чтобы предоставить возможность масштабирования в день N. Подробные сведения о параметрах в логических сетях см. в следующем разделе az stack-hci-vm network lnet create:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
Затем создайте кластер AKS Arc с предыдущей логической сетью:
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
Теперь вы можете включить подсистему балансировки нагрузки MetalLB с пулом IP-адресов из 3 IP-адресов в той же подсети, что и логическая сеть виртуальной машины Arc. Вы можете добавить дополнительные пулы IP-адресов позже, если приложению требуется увеличение. Подробные требования см. в обзоре расширения MetalLB Arc.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Рекомендации по LNETs для кластеров AKS и виртуальных машин Arc
Логические сети в локальной среде Azure используются кластерами AKS и виртуальными машинами Arc. Логические сети можно настроить одним из следующих способов:
- Совместное использование логической сети между ВИРТУАЛЬНЫми машинами AKS и Arc.
- Определите отдельные логические сети для кластеров AKS и виртуальных машин Arc.
Совместное использование логической сети между виртуальными машинами AKS и Arc в Azure Local обеспечивает упрощенное взаимодействие, экономию затрат и упрощенное управление сетями. Однако этот подход также представляет потенциальные проблемы, такие как состязание ресурсов, риски безопасности и сложность устранения неполадок.
| Критерии | Общий доступ к логической сети | Определение отдельных логических сетей |
|---|---|---|
| Сложность конфигурации | Упрощенная конфигурация с одной сетью, что снижает сложность настройки. | Более сложная настройка, так как необходимо настроить несколько логических сетей для виртуальных машин и кластеров AKS. |
| Масштабируемость | Возможные ограничения масштабируемости, так как виртуальные машины Arc и кластеры AKS используют сетевые ресурсы. | Более масштабируемый, так как сетевые ресурсы разделены и могут масштабироваться независимо. |
| Управление политиками сети | Проще управлять одним набором политик сети, но труднее изолировать рабочие нагрузки. | Проще изолировать рабочие нагрузки, так как отдельные политики можно применять для каждой логической сети. |
| Вопросы безопасности | Повышенный риск междоменийных уязвимостей, если он не был должным образом сегментирован. | Повышение безопасности по мере того, как каждая сеть может быть сегментирована и изолирована более строго. |
| Влияние сбоев сети | Сбой в общей сети может повлиять одновременно на виртуальные машины AKS и Arc. | Сбой в одной сети влияет только на рабочие нагрузки в этой сети, что снижает общий риск. |
Выделение диапазона IP-адресов для POD CIDR и CIDR службы
В этом разделе описываются диапазоны IP-адресов, используемые Kubernetes для обмена данными pod и служб в кластере. Эти диапазоны IP-адресов определяются во время процесса создания кластера AKS и используются для назначения уникальных IP-адресов модулям pod и службам в кластере.
CiDR сети Pod
CiDR сети Pod — это диапазон IP-адресов, используемых Kubernetes для назначения уникальных IP-адресов отдельным модулям pod, работающим в кластере Kubernetes. Каждый модуль pod получает собственный IP-адрес в этом диапазоне, позволяя модулям pod взаимодействовать друг с другом и службами в кластере. В AKS IP-адреса pod назначаются через CNI Calico в режиме VXLAN. VXLAN Calico помогает создавать сети наложения, где IP-адреса модулей pod (из сети CIDR pod) виртуализированы и туннелизируются через физическую сеть. В этом режиме каждый модуль pod назначает IP-адрес из CIDR сети pod, но этот IP-адрес не может быть напрямую routable в физической сети. Вместо этого он инкапсулируется в сетевых пакетах и отправляется через базовую физическую сеть для достижения целевого модуля pod на другом узле.
AKS предоставляет значение по умолчанию 10.244.0.0/16 для ciDR сети pod. AKS поддерживает настройки для CIDR сети pod. При создании кластера AKS можно задать собственное значение с помощью --pod-cidr параметра. Убедитесь, что диапазон IP-адресов CIDR достаточно велик, чтобы разместить максимальное количество модулей pod на узел и в кластере Kubernetes.
CIDR сети служб
CiDR сети служб — это диапазон IP-адресов, зарезервированных для служб Kubernetes, таких как LoadBalancers, ClusterIP и NodePort в кластере. Kubernetes поддерживает следующие типы служб:
- ClusterIP: тип службы по умолчанию, предоставляющий службу в кластере. IP-адрес, назначенный из сети CIDR службы, доступен только в кластере Kubernetes.
- NodePort: предоставляет службу по определенному порту на IP-адресе каждого узла. ClusterIP по-прежнему используется внутренне, но внешний доступ осуществляется через IP-адреса узлов и определенный порт.
- LoadBalancer: этот тип создает подсистему балансировки нагрузки, управляемой поставщиком облачных поставщиков, и предоставляет службу внешним образом. Поставщик облачных служб обычно управляет внешним назначением IP-адресов, а внутренний ClusterIP остается в сети CIDR службы.
AKS предоставляет значение по умолчанию 10.96.0.0/12 для CIDR сети служб. AKS не поддерживает настройки для ciDR сети служб сегодня.
Следующие шаги
Создание логических сетей для кластеров Kubernetes в Локальной среде Azure версии 23H2