Проверка пересечения подсетей при создании кластера

При развёртывании кластера задаются несколько разных сетевых диапазонов. Если они пересекаются с уже занятыми сетями или между собой неправильно, создание кластера может завершиться ошибкой.

При создании кластера в мастере на шаге «Основные данные» задаются адреса API и Ingress, подсеть подов и подсеть сервисов.

Что именно может конфликтовать #

Пересечение диапазонов IP — это ситуация, когда два разных объекта «претендуют» на одни и те же адреса по правилам маршрутизации. Ниже — разные слои, которые при создании кластера задаются отдельно и их нельзя путать.

Сеть узлов (инфраструктура) #

Узлы кластера получают адреса в сети вашего провайдера (ВМ, VPC и т.д.). Если эта подсеть совпадает или пересекается с уже занятой сетью (другой кластер, сегмент офиса и т.п.), возможны ошибки при развёртывании. Для нескольких кластеров рекомендуется выделять непересекающиеся подсети; для пулов IP это также снижает риск конфликтов — см. рекомендации по пулам.

Подсеть подов (Pod CIDR) и подсеть сервисов (Service CIDR) #

По умолчанию при создании кластера задаются:

• подсеть подов: 172.16.0.0/16;
• подсеть сервисов: 10.96.0.0/12.

Диапазоны можно изменить; до создания кластера их нужно проверить на пересечения.

Требования зависят от сценария:

• для VMware vSphere: подсеть подов не должна пересекаться с сетью узлов и сервисов — см. таблицу в инструкции по vSphere;
• для Yandex Cloud: подсети подов и сервисов не должны пересекаться с подсетями VPC и с другими кластерами — см. особенности Yandex Cloud.

На шаге мастера явно указано: диапазоны не должны пересекаться с корпоративными сетями и другими кластерами — см. описание шага «Основные данные» в документации по вашему провайдеру.

Пул IP-адресов (см. ниже) — это не адреса подов и не ClusterIP сервисов; это отдельный механизм для VIP.

VIP для KubeAPI и VIP для Ingress #

Для KubeAPI и Ingress нужны виртуальные IP (VIP). Если используется пул IP-адресов, адреса выбираются из диапазона пула. Требования к VIP из пула:

• VIP для KubeAPI и VIP для Ingress должны быть в той же подсети, что и узлы Control Plane;
• VIP не должны совпадать с IP-адресами узлов кластера.

Подробнее — в разделе «Требования к адресам в пуле» и на шаге «Основные данные» в документации по вашему провайдеру. Для Yandex Cloud пулы не используются — адреса задаются через внешние балансировщики (особенности Yandex Cloud).

Схема «Используемые подсети» #

Рисунок 1. Используемые подсети по умолчанию.

На схеме показано, какие диапазоны по умолчанию относятся к сервисам кластера (10.96.0.0/12, с пояснением в духе рекомендаций Kubernetes) и к подам (172.16.0.0/16), и какие нижняя и верхняя границы у этих пространств на примере конкретных адресов. Отдельным блоком отмечено, что диапазон 192.168.0.0/16 по умолчанию не используется для показанных на схеме слоёв кластера (сервисы и поды). Это подчёркивает, что инфраструктурные адреса узлов и виртуальные диапазоны Pod/Service — разные плоскости; их нужно согласовывать при заполнении полей мастера, чтобы не получить пересечение.

Схема «Пример использования подсетей в overlay-сети кластера и корпоративной сети» #

На схеме изображены:

• Overlay-сеть кластера — подсеть сервисов (10.96.0.0/12), подсеть подов (172.16.0.0/16), примеры адресов сервисов и подов, а также узлы с адресами во внешней по отношению к Pod/Service сети подсети (на примере 192.168.4.x) и фрагменты pod-сети, выделенные на каждый узел.
• Корпоративная сеть — условные сегменты (рабочие станции, серверы, шлюз, хранилище и т.д.) со своими подсетями.

Если в корпоративной инфраструктуре уже используются те же адресные пространства, что вы задали как Pod CIDR и Service CIDR, трафик из подов не будет доходить до нужных корпоративных сервисов в этих диапазонах: запрос «остаётся» внутри логики overlay-кластера. Поэтому при создании кластера важно заранее проверить пересечения с корпоративными и облачными сетями — см. шаг «Основные данные» в документации по вашему провайдеру и блок «Что именно может конфликтовать» выше на этой странице.

Типичные ошибки #

• Указана подсеть узлов или другой инфраструктурный диапазон, который уже используется другими ресурсами.
• Подсеть подов и/или подсеть сервисов пересекаются с недопустимыми для выбранного провайдера сетями (например, с сетью узлов или с VPC — см. ссылки выше) или между собой так, что кластер с такой конфигурацией не сможет быть развёрнут (подробнее — «Диагностика пересечения подсетей в кластере»).
• Несколько кластеров используют одни и те же сетевые диапазоны там, где нужны разведённые подсети.
• Для VIP: адрес совпадает с IP узла, не попадает в нужную подсеть или занят к моменту запуска (механизм резервирования из пула отсутствует — см. важные ограничения пула и примечание для VMware vSphere).

Как проверить перед созданием кластера #

1. На шаге «Основные данные» мастера (описание в документации по вашему провайдеру) сверьте подсеть подов и подсеть сервисов с корпоративными сетями и с другими кластерами; при нестандартных CIDR проверьте диапазоны на пересечение (калькулятор подсетей).
2. Убедитесь, что для вашего провайдера соблюдены ограничения: например, для vSphere — отсутствие пересечения подсети подов с сетью узлов и сервисов; для Yandex Cloud — отсутствие пересечения с VPC (ссылки в разделе «Что именно может конфликтовать»).
3. Если используется пул IP, проверьте, что диапазон пула согласован с подсетями узлов и что выбранные VIP удовлетворяют требованиям к адресам.
4. Заложите отдельные непересекающиеся подсети для разных кластеров, если они разворачиваются в одной зоне ответственности.

См. также #

• Детализация шагов мастера — ссылки на описание полей по провайдерам, включая шаг «Основные данные».
• Архитектурные схемы сетей кластера — как устроены overlay подсети подов и сервисов.
• Пул IP-адресов — только VIP KubeAPI и Ingress.
• Диагностика пересечения подсетей в кластере — после инициализации кластера, с командами kubectl.