Что дает NodePort в Kubernetes

Что проверяют

Представляете ли вы путь пакета снаружи до пода и понимаете ли, почему этот тип сервиса редко оставляют голым в продакшене. Вопрос обычно идёт в паре с вопросом про другие типы сервисов, и ждут сравнения, а не определения.

Как отвечать

NodePort открывает один и тот же порт на всех узлах кластера, по умолчанию из диапазона 30000-32767. Обращение на адрес любого узла с этим портом попадает в сервис, а дальше kube-proxy выбирает под. Порт слушают все узлы, в том числе те, где нужного пода нет: пакет уйдёт на подходящий узел.

Важно сказать, что этот тип включает в себя обычный внутрикластерный адрес, то есть по имени сервиса внутри кластера всё продолжает работать.

Где уместен: доступ снаружи там, где нет облачного балансировщика, стенды и отладка, и типовая схема на своём железе, когда перед кластером стоит собственный балансировщик, а узлы подключены к нему как бэкенды по этому порту.

Ограничения тоже стоит назвать: нестандартный порт, адреса узлов нужно знать и обновлять при изменении состава кластера, номер порта занимается на весь кластер, а при политике по умолчанию исходный адрес клиента подменяется адресом узла.

Где спотыкаются

Считают, что порт открыт только там, где работает под. Он открыт на каждом узле, и если сетевые правила пускают трафик, сервис доступен снаружи по любому адресу кластера, о чём забывают в разговоре про безопасность.

Переключают политику на Local и не связывают с этим пропавшую доступность. Так исходный адрес клиента сохраняется, но узлы без пода перестают отвечать, и внешний балансировщик обязан их проверять, а не считать равнозначными.

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