Services, ingress & DNS

Услуги Kubernetes и Ingress необходимы для управления сетевым трафиком внутри и до вашего кластера Kubernetes. Используйте services, чтобы представить набор подов как сетевую службу, и ingress, чтобы управлять внешним доступом к службам в кластере, обычно это HTTP.

Как это работает

Services, ingress & DNS — де-факто платформа оркестрации: шедулит контейнеры (Pods) на флот worker-нод, гарантирует объявленное количество реплик, маршрутизирует трафик через Services и Ingress, монтирует persistent-хранилище через PVC и непрерывно reconcile-ит desired state. Control plane (api-server, etcd, scheduler, controller-manager) принимает решения о шедулинге; kubelet на каждой ноде запускает контейнеры через containerd/CRI-O. DevOps-инженеры взаимодействуют через kubectl, Helm-чарты, GitOps-инструменты (Argo CD, Flux) и observability-стеки (Prometheus, Grafana, Loki).

Когда применять

Применяйте Services, ingress & DNS при наличии 10+ сервисов с нетривиальным масштабированием, частотой деплоев или HA-требованиями. Для 1–3 сервисов Docker Compose на одной VM проще, дешевле и надёжнее. Managed Kubernetes (EKS, GKE, Yandex MKS) — дефолт для новых кластеров; self-managed Kubernetes на bare metal оправдан только при cost-оптимизации на большом масштабе или требованиях data-localisation. Сопровождайте Kubernetes GitOps'ом с первого дня; никогда не позволяйте людям делать kubectl apply против prod напрямую.

Типичные ошибки

Ловушки Kubernetes: over-engineering (запуск k8s ради 2 stateless-сервисов, которые отлично работают на VM); недо-ресурсенный control plane на self-managed кластерах; нет resource requests/limits (один runaway Pod выселяет всё остальное); игнорирование NetworkPolicies (всё общается со всем по умолчанию); ручные kubectl edit против prod, которые никто не фиксирует обратно в Git; stateful-нагрузки на Kubernetes без понимания trade-offs (БД требуют тщательной настройки PVC, backup и node affinity).

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы