Как спланировать смену сетевых диапазонов Kubernetes

Пересечение Pod CIDR с корпоративной или домашней сетью быстро превращается в эксплуатационную проблему: часть трафика уходит в неверный сегмент, сервисы становятся недоступны, а диагностика выглядит как случайный набор сетевых сбоев. Исправление требует сменить адресное пространство кластера. Для Cilium 1.20 эта задача упрощается режимом Multi-Pool, который позволяет подготовить новый пул и переносить рабочие нагрузки постепенно.

Работы стоит разделить на два независимых этапа. Сначала меняются адреса Pod, затем — ClusterIP сервисов. У этих этапов разные точки отказа, порядок перезапусков и способ отката. Объединять их в одно действие рискованно: проблемы DNS и сервисной сети будет трудно отличить от ошибок CNI.

Инвентаризация и резервные копии

До технического окна зафиксируйте текущие диапазоны Pod и Service, схему control plane, число worker-узлов, статические привязки и внешние зависимости. Полезно отдельно проверить:

• маршрутизацию до существующих Pod CIDR и отсутствие пересечений с LAN, VPN и сетями других кластеров;
• настройки kube-apiserver, kube-controller-manager и kubelet;
• Service типа ClusterIP, DNS-компоненты и приложения, которые держат долгие исходящие соединения;
• особенности NodeLocal DNSCache, ingress, Argo CD и сервисов, закреплённых за определёнными узлами.

Перед изменениями нужны резервная копия etcd и копии /etc/kubernetes и /var/lib/kubelet/config.yaml. Резервная копия особенно важна для ServiceCIDR: в процессе меняются параметры control plane и записи реестра сервисных диапазонов.

Новый диапазон следует рассчитать с запасом. Например, пул /20 можно нарезать на /24 для отдельных узлов. Шаг третьего октета для масок от /16 до /24 вычисляется как 2^(24 - N), где N — длина маски. Для /20 он равен 16. В Cluster Mesh адресные планы соседних кластеров нужно учитывать заранее, иначе конфликт лишь переместится в следующий сегмент.

Подготовка Multi-Pool

В Cilium 1.20 режим IPAM Multi-Pool включается при обновлении Helm-релиза. Новый CiliumPodIPPool желательно применить до обновления: агенту потребуется этот CRD при запуске. На этапе подготовки в конфигурации сохраняют прежний Pod CIDR и добавляют будущий диапазон. Аналогично можно заранее указать старый и новый Service CIDR.

Пример определения пула Pod:

apiVersion: cilium.io/v2alpha1
kind: CiliumPodIPPool
metadata:
  name: default
spec:
  ipv4:
    cidrs:
      - 172.24.0.0/20
    maskSize: 24

При обновлении важны параметры, которые запрещают массовый rollout Cilium agent, operator и Envoy. Иначе обновление перезапустит контейнеры одновременно и лишит оператора возможности контролировать очередность. Конкретные значения Helm-параметров зависят от используемого chart и должны быть сверены с документацией для выбранной версии.

Для DNS стоит заранее задать PodDisruptionBudget для CoreDNS. Он удержит количество одновременно недоступных реплик в приемлемых границах и позволит переносить узлы последовательно.

Поэтапный перенос Pod

После установки версии с Multi-Pool перезапускайте Cilium agent на одном worker-узле, наблюдайте за состоянием узла, DNS и сетевой связностью, затем переходите к следующему. Каждый такой шаг затрагивает Pod на конкретном узле: активные соединения к внешним системам могут потребовать перезапуска приложения, чтобы оно получило обновлённые сетевые настройки и DNS endpoints.

Удобная последовательность выглядит так:

1. вывести с узла переносимые нагрузки или закрепить критичные Pod на узлах без работ;
2. перезапустить Cilium agent на одном узле и убедиться, что новые Pod получают адреса из нового диапазона;
3. перезапустить CoreDNS в контролируемом порядке;
4. перезапустить зависящие от DNS и внешних соединений workloads;
5. проверить маршруты, readiness, логи Cilium и прикладные health-check;
6. повторить процедуру для остальных worker-узлов.

Argo CD и похожие контроллеры полезно учитывать отдельно: после смены сети их репозитории и синхронизация могут кратковременно потерять связь. Для таких компонентов заранее определите допустимое окно и способ проверки восстановления.

NodeLocal DNSCache заслуживает отдельного теста. После переезда может исчезнуть доступность link-local адреса DNS, например 169.254.20.10. Простого рестарта workloads иногда недостаточно; на практике может понадобиться временно вернуть CoreDNS как основной путь резолвинга и исследовать конфигурацию NodeLocal DNSCache отдельно. Это ещё одна причина не совмещать перенос Pod и Service CIDR.

Перенос Service CIDR

Изменение сети сервисов затрагивает control plane. На master-узлах обновляют CIDR в /etc/kubernetes/manifests/kube-controller-manager.yaml и /etc/kubernetes/manifests/kube-apiserver.yaml; на master и worker-узлах меняют настройки kubelet в /var/lib/kubelet/config.yaml. После изменения статических манифестов компоненты control plane перезапустятся, поэтому доступ к API на короткое время пропадёт.

Перед работами полезно перевести доступные внешние точки входа на NodePort или заранее подготовить маршрут на worker-узлы. Это уменьшит влияние краткой недоступности API на пользователей, но не отменяет необходимости проверки приложения после каждого шага.

Для нового диапазона создаётся объект ServiceCIDR:

apiVersion: networking.k8s.io/v1
kind: ServiceCIDR
metadata:
  name: kubernetes
spec:
  cidrs:
    - 172.24.0.0/20

При смене ServiceCIDR требуется аккуратно обработать записи в etcd, связанные с сервисными диапазонами. Если только удалить и создать объект, Cilium может продолжить получать прежнее значение из-за гонки между компонентами. Операцию нужно выполнить синхронно на всех узлах по подготовленному runbook, затем сразу перезапустить kubelet и применить новый ServiceCIDR на одном из master-узлов.

После этого сервисы переносятся постепенно: старый Service удаляется, а контроллер развёртывания создаёт его с адресом нового диапазона. Альтернатива для критичных маршрутов — второй Service, направленный на тот же Deployment, и плавное переключение трафика через Gateway API с весами. Этот вариант требует больше объектов, зато даёт контролируемую канареечную схему.

CoreDNS лучше переносить последним. Его пересоздание меняет адрес, поэтому все зависимые контейнеры стоит перезапустить на соответствующем узле. Сервис kubernetes в namespace default требует особой осторожности: его ручное пересоздание может нарушить подключение CoreDNS к API.

Проверки после миграции

После завершения убедитесь, что в конфигурации Cilium больше нет старых подсетей. Проверьте выдачу IP для новых Pod и Service, DNS-резолвинг, межсервисные запросы, внешнюю связность и состояние системных компонентов. Hubble помогает увидеть dropped-пакеты и направление трафика во время диагностики.

Multi-Pool делает перенос адресов управляемой процедурой, однако это режим, который следует предварительно проверить на стенде. Пошаговый rollout, резервные копии и отдельное техническое окно для Service CIDR снижают вероятность долгого простоя и оставляют команде ясный путь диагностики на каждом этапе.