Service (ClusterIP, NodePort, LoadBalancer)
Тема дорожной карты · Kubernetes
Service Kubernetes — стабильная сетевая абстракция, открывающая набор Pod'ов под постоянным виртуальным IP-адресом и DNS-именем, отделяющая клиентские приложения от эфемерных IP-адресов отдельных Pod'ов, которые могут быть перепланированы в любое время. Service выбирает свои бэкенд-Pod'ы с помощью spec.selector по меткам и реализуется kube-proxy, программирующим правила iptables или IPVS на каждом узле для балансировки нагрузки между соответствующими конечными точками Pod'ов. Четыре типа Service обслуживают разные паттерны доступа: ClusterIP (по умолчанию) создаёт только внутренний виртуальный IP, разрешаемый как <service>.<namespace>.svc.cluster.local через CoreDNS; NodePort дополнительно открывает статический порт на каждом узле для внешнего доступа; LoadBalancer провизирует балансировщик нагрузки облачного провайдера для production-входа; а ExternalName создаёт псевдоним для внешнего DNS-хоста через запись CNAME. Service Kubernetes также предоставляет маппинг spec.ports[].targetPort и поддерживает sessionAffinity: ClientIP для sticky-сессий, а также headless-сервисы (clusterIP: None) для обнаружения пиров StatefulSet на основе DNS. Для HTTP/HTTPS-маршрутизации по имени хоста и пути Service Kubernetes используются совместно с ресурсом Ingress или HTTPRoute Gateway API, управляемыми контроллерами ingress-nginx, Traefik или Istio.
Как это работает
Service (ClusterIP, NodePort, LoadBalancer) в Kubernetes работает через CNI (Container Network Interface) на каждой ноде плюс API-ресурсы (Service, Ingress, NetworkPolicy и т.д.), которые декларирует пользователь. CNI выдаёт pod IPs из cluster-wide CIDR, kube-proxy программирует правила iptables/IPVS для Service ClusterIP, ingress-controller (NGINX, Traefik и др.) обрабатывает внешний HTTP-трафик с TLS termination.
Когда применять
Конфигурируйте Service (ClusterIP, NodePort, LoadBalancer) рано в setup кластера — сетевые решения имеют широкие последствия и сложно меняются позже. Выбирайте CNI (Calico, Cilium, Flannel) по нуждам policy и масштаба; выбирайте ingress controller под мешок нагрузок; проектируйте Service и DNS-разметку до деплоя реальных нагрузок. Network observability (kube-state-metrics + Prometheus + Cilium Hubble) экономит часы во время incident response.
Типичные ошибки
Сетевые ловушки: дефолт на NodePort (открывает порты на каждом worker — обычно не то, что вам нужно), когда имели в виду ClusterIP + Ingress; забыли NetworkPolicies (всё общается со всем по умолчанию в K8s — опасно в shared-кластерах); ingress controllers без TLS-стратегии; неправильная конфигурация CoreDNS, вызывающая cluster-wide DNS-failures. Тестируйте network policies на staging до production.