Pod IP, ClusterIP или внутренний балансировщик для пользователей VPN
Pod IP маршрутизируется через VPN, пока Pod не будет заменён. Сравните прямой доступ к Pod, ClusterIP и внутренний балансировщик и то, во что каждый из них вам обходится.
С VPC CNI Pod может получить адрес из VPC, и пользователь VPN с правильным маршрутом может обратиться к нему напрямую. Поэтому прямой доступ к Pod кажется самым простым вариантом, и так оно и есть, пока Pod не будет заменён. Адрес, который запоминает пользователь, должен принадлежать приложению, а не реплике. Сравнение трёх входов сводится к тому, какой объект владеет адресом и что должно продолжать работать, когда нагрузка перемещается.
Сначала выбирайте по жизненному циклу, затем по тому, что сеть должна сделать, чтобы вход стал доступен.
Три входа, три жизненных цикла
Pod IP принадлежит Pod: он выделяется вместе с ним и освобождается при его завершении. ClusterIP принадлежит Service и является виртуальным, он имеет смысл только там, где существует маршрутизация сервисов кластера. Внутренним балансировщиком владеет облачный ресурс, который контроллер кластера программирует бэкендами. Эти модели владения предсказывают сбой, который вы получите: устаревший адрес, недоступное имя или устаревший набор бэкендов.
Запишите сравнение до выбора. Когда владелец и сбой названы, выбор обычно делает себя сам.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Прямой доступ к Pod: полезный, временный
Прямой доступ действительно полезен для контролируемой проверки: один администратор, одна короткая сессия, один конкретный порт. Но это плохой контракт для пользователей, потому что адрес — это деталь реализации, которая меняется при каждом развёртывании. А запись его в вики — это путь, которым работающий сервис превращается в слух.
Это также приглашает к широким правилам. Разрешение одному администратору достигать одного Pod не является разрешением для каждого адреса в подсети узла, и обычно пишется именно второе.
ClusterIP: ограничен кластером по замыслу
ClusterIP работает потому, что dataplane кластера программирует для него маршрутизацию внутри кластера. С ноутбука в VPN адрес ничего не значит, если что-то намеренно его не открывает. Имя, заканчивающееся на svc.cluster.local, принадлежит DNS кластера, поэтому копирование его на клиент с другим резолвером даёт не ошибку маршрутизации, а несуществующее имя.
ClusterIP остаётся правильным входом для вызывающих внутри кластера, включая другие рабочие нагрузки. Он просто не является механизмом публикации для пользователей за пределами домена маршрутизации кластера.
Внутренний балансировщик: опубликованный путь
Внутренний балансировщик даёт вам стабильный частный адрес и имя, на которое может указывать ваша зона, а контроллер поддерживает набор бэкендов актуальным, как описывает руководство EKS по балансировке нагрузки. Это тот вход, который переживает обычную замену Pod без правки документа кем-либо. Он стоит облачный ресурс, конфигурацию контроллера и маршрут из VPN, и именно эти части люди недооценивают.
Используйте ту модель контроллера, которую кластер действительно выполняет. Аннотации, написанные для одной интеграции, не применяются к другой.
Кто является адресом источника
Группы безопасности видят источник, который приходит на их границу, и это может быть подключённый клиент или транслированный адрес в зависимости от пути VPN и балансировки нагрузки. На узлах на базе EC2 обычные Pod VPC CNI по умолчанию наследуют группы ENI узла, тогда как поддерживаемые конфигурации могут присоединять группы, специфичные для Pod. Пишите правила для документированного пути, а не для предполагаемого адреса ноутбука.
Держите собственный слушатель и аутентификацию приложения как отдельные средства контроля. Сетевое правило, разрешающее поток, не является решением об авторизации, и его не следует так трактовать.
Что передать пользователям
Дайте пользователям имя сервиса, а не адрес. Опубликуйте имя в приватной зоне, направьте его на внутренний вход и затем проверьте, заменив бэкенд-Pod, пока клиент держит то же имя открытым. Это упражнение проверяет свойство, которое важно: достижение того же приложения после рутинного развёртывания.
Держите прямой доступ к Pod как документированное операционное исключение с собственной областью действия, далеко от инструкций для пользователей.