Kubernetes: сеть
Типы Service и маршрутизация к Pod, Ingress и контроллеры, kube-proxy и CNI, кластерный DNS и NetworkPolicy.
9 вопросов
JuniorТеорияОчень частоЧто такое Service в Kubernetes и как он даёт Pod стабильный адрес?
Что такое Service в Kubernetes и как он даёт Pod стабильный адрес?
Service — это стабильный виртуальный IP и DNS-имя перед Pod, отобранными по меткам. Pod эфемерны и их IP меняются, но адрес Service остаётся постоянным и балансирует запросы по готовым Pod, поэтому клиенты не обращаются к IP Pod напрямую.
Типичные ошибки
- ✗Считать Service отдельным Pod или запущенным прокси-процессом, а не виртуальным IP
- ✗Думать, что IP Service меняется при замене его бэкенд-Pod
- ✗Полагать, что клиенты должны подключаться к IP отдельных Pod напрямую
Уточняющие вопросы
- →Как Service узнаёт, какие Pod сейчас готовы принимать трафик?
- →Что происходит с активными соединениями, когда бэкенд-Pod удаляют?
JuniorТеорияЧастоЧто такое Ingress и чем он отличается от Service?
Что такое Ingress и чем он отличается от Service?
Ingress — это L7-маршрутизатор HTTP/HTTPS: он направляет хосты и URL-пути к бэкенд-Service и терминирует TLS. Service работает на L4 (TCP/UDP) и лишь балансирует к Pod. Ingress требует ingress-контроллера, чтобы правила применялись.
Типичные ошибки
- ✗Думать, что Ingress работает без установленного ingress-контроллера
- ✗Путать L7-маршрутизацию по путям/хостам (Ingress) с L4-балансировкой (Service)
- ✗Считать, что Ingress заменяет Service, а не маршрутизирует к нему
Уточняющие вопросы
- →Какой компонент реально исполняет правила Ingress и как он ставится?
- →Для не-HTTP TCP-сервиса вы возьмёте Ingress или тип Service?
JuniorТеорияЧастоЧто такое NetworkPolicy и как ведёт себя трафик, если Pod не выбран ни одной политикой?
Что такое NetworkPolicy и как ведёт себя трафик, если Pod не выбран ни одной политикой?
NetworkPolicy — это firewall для трафика Pod по меткам. По умолчанию он НЕ deny-by-default: Pod, не выбранный ни одной политикой, разрешает весь трафик. Изоляция начинается лишь когда политика выбирает Pod — тогда проходят только явно разрешённые направления, и её применяет CNI.
Типичные ошибки
- ✗Считать, что пустой namespace — deny-by-default, а не allow-all
- ✗Думать, что одна политика запирает весь кластер, а не только выбранные Pod
- ✗Полагать, что политики работают без CNI (Container Network Interface), который их применяет
Уточняющие вопросы
- →Как получить настоящий default-deny для namespace?
- →Если две политики выбрали один Pod, как складываются их allow-правила?
MiddleТеорияЧастоЧто делает kube-proxy и чем различаются его режимы iptables и IPVS?
Что делает kube-proxy и чем различаются его режимы iptables и IPVS?
kube-proxy работает на каждом узле и программирует правила за виртуальным IP Service, направляя каждое соединение к готовому бэкенд-Pod. Режим iptables пишет последовательные правила, чья стоимость растёт с числом Service; режим IPVS берёт хеш-таблицы в ядре и тянет куда больше.
Типичные ошибки
- ✗Считать kube-proxy L7/HTTP-прокси, а не L4-механикой Service
- ✗Думать, что kube-proxy резолвит DNS вместо CoreDNS
- ✗Полагать, что режимы iptables и IPVS масштабируются одинаково с числом Service
Уточняющие вопросы
- →Почему кластер с тысячами Service часто переходит на режим IPVS?
- →Какой компонент выдаёт IP Pod, если kube-proxy ведёт лишь VIP Service?
MiddleДебаггингЧастоКлиенты получают таймауты к Service web, хотя Pod работают — разберитесь.
Клиенты получают таймауты к Service web, хотя Pod работают — разберитесь.
Список endpoints пуст, поэтому у Service нет бэкендов и запросы отваливаются по таймауту. Pod в Ready, но их метка app=webapp не совпадает с селектором Service app=web, поэтому ни один не включён. Чините выравниванием селектора или переметкой Pod.
Типичные ошибки
- ✗Винить kube-proxy или DNS вместо чтения пустого Endpoints
- ✗Считать, что Service матчит Pod по префиксу имени, а не по селектору меток
- ✗Полагать, что больше реплик или ожидание заполнят пустой Endpoints
Уточняющие вопросы
- →Как выглядел бы пустой Endpoints, если бы падала readiness?
- →Какая команда быстро проверит, матчит ли селектор хоть какие-то Pod?
MiddleТеорияЧастоСравните типы Service — ClusterIP, NodePort и LoadBalancer.
Сравните типы Service — ClusterIP, NodePort и LoadBalancer.
ClusterIP (по умолчанию) — внутренний виртуальный IP только внутри кластера. NodePort дополнительно открывает Service на фиксированном порту на каждом узле, так что внешние клиенты достучатся через IP любого узла. LoadBalancer строится поверх и просит у облака внешний балансировщик.
Типичные ошибки
- ✗Считать, что ClusterIP доступен снаружи по умолчанию
- ✗Упускать, что LoadBalancer строится поверх NodePort
- ✗Думать, что NodePort открывает порт лишь на одном узле, а не на всех
Уточняющие вопросы
- →Что такое headless Service (
clusterIP: None) и когда его берут StatefulSet? - →Почему один Ingress лучше многих Service типа
LoadBalancer?
MiddleТеорияИногдаКак внутрикластерный DNS разрешает имя вида svc.namespace.svc.cluster.local?
Как внутрикластерный DNS разрешает имя вида svc.namespace.svc.cluster.local?
CoreDNS обслуживает внутреннюю зону cluster.local. У каждого Service есть A-запись service.namespace.svc.cluster.local, резолвящаяся в его ClusterIP. search-домен Pod охватывает его namespace, поэтому короткое svc резолвится локально, а svc.ns достаёт другой namespace.
Типичные ошибки
- ✗Считать, что DNS возвращает IP Pod, а не ClusterIP Service
- ✗Думать, что разрешение идёт через /etc/hosts, а не CoreDNS
- ✗Упускать сегмент namespace, из-за чего имена между namespace не работают
Уточняющие вопросы
- →Почему короткое имя Service резолвится без полного FQDN?
- →Как разрешить headless Service, у которого нет ClusterIP?
MiddleКодИногдаДопишите NetworkPolicy, чтобы Pod api принимали трафик только от role=frontend.
Допишите NetworkPolicy, чтобы Pod api принимали трафик только от role=frontend.
Задайте policyTypes в Ingress и одно правило ingress, чьё from — podSelector по role=frontend, с ограничением на TCP-порт 8080. Выбор Pod api переводит их в deny-by-default по ingress, поэтому проходит только это правило. Работает лишь если CNI применяет NetworkPolicy.
Типичные ошибки
- ✗Ограничивать отправителя через egress вместо выбора Pod api
- ✗Забыть блок ports, из-за чего открыты все порты
- ✗Считать, что политика работает без CNI (Container Network Interface), применяющего NetworkPolicy
Уточняющие вопросы
- →Как дополнительно пустить ingress из namespace мониторинга по метке?
- →Что случится с текущими соединениями в момент применения политики?
SeniorДизайнИногдаУ вас трёхслойное приложение в одном namespace: публичный frontend, внутренний API backend и база postgres. Безопасность требует default-deny — ни один Pod не принимает трафик, если он не разрешён явно. Разрешены ровно такие пути: внешние пользователи достигают frontend по HTTPS; frontend ходит к backend на порт 8080; backend ходит к postgres на 5432. Больше ничто соединяться не должно — frontend не должен доставать базу напрямую, а внешний клиент не должен доставать backend или postgres. Опишите дизайн: как вы выставляете frontend наружу и как применяете Kubernetes NetworkPolicy для этих east-west путей, сохраняя гарантию default-deny.
У вас трёхслойное приложение в одном namespace: публичный frontend, внутренний API backend и база postgres. Безопасность требует default-deny — ни один Pod не принимает трафик, если он не разрешён явно. Разрешены ровно такие пути: внешние пользователи достигают frontend по HTTPS; frontend ходит к backend на порт 8080; backend ходит к postgres на 5432. Больше ничто соединяться не должно — frontend не должен доставать базу напрямую, а внешний клиент не должен доставать backend или postgres. Опишите дизайн: как вы выставляете frontend наружу и как применяете Kubernetes NetworkPolicy для этих east-west путей, сохраняя гарантию default-deny.
Примените default-deny NetworkPolicy по всем Pod, чтобы ничто не соединялось само. Затем разрешите три ingress-пути: backend от frontend на 8080, postgres от backend на 5432 и внешний трафик к frontend. backend/postgres держите ClusterIP-only, наружу — только frontend. frontend к БД ничто не пускает, поэтому этот east-west путь закрыт.
Типичные ошибки
- ✗Считать Kubernetes default-deny без явной deny-all политики
- ✗Выставлять backend или postgres наружу вместо ClusterIP-only
- ✗Изолировать слои через Ingress вместо NetworkPolicy
Уточняющие вопросы
- →Как расширить это на второй namespace, которому тоже нужна БД?
- →Как проверить, что путь frontend→БД действительно закрыт?
