Ingress и Ingress Controllers
Тема дорожной карты · Kubernetes
Ingress Kubernetes — объект API в группе networking.k8s.io/v1, определяющий правила HTTP- и HTTPS-маршрутизации для направления внешнего трафика к Service внутри K8s-кластера, выступая в роли балансировщика нагрузки уровня 7 и шлюза виртуального хостинга. Ресурс Ingress задаёт spec.rules с записями host и http.paths, отображающими URL-пути на backend.service.name и backend.service.port, и блоки spec.tls, ссылающиеся на Secret'ы Kubernetes с TLS-сертификатами — как правило, автоматически выдаваемыми Cert-Manager. Ingress-контроллер — ingress-nginx, Traefik, HAProxy Ingress или нативные облачные контроллеры, такие как AWS ALB Ingress Controller, — отслеживает ресурсы Ingress и конфигурирует нижележащий прокси соответственно; класс контроллера задаётся через поле spec.ingressClassName, ссылающееся на ресурс IngressClass. Хотя Ingress Kubernetes охватывает большинство сценариев HTTP-маршрутизации, более новый Gateway API предоставляет более выразительную и ролеориентированную альтернативу с нативной поддержкой разделения трафика, манипуляций с заголовками и многопротокольной маршрутизации.
Как это работает
Ingress и Ingress Controllers в 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.
Когда применять
Конфигурируйте Ingress и Ingress Controllers рано в 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.