Что отвечает за сеть, кроме Ingress

Отличный вопрос, который позволяет сразу оценить глубину понимания сетевой модели Kubernetes. Помимо Ingress, который является абстракцией для управления входящим HTTP/HTTPS трафиком, сеть в Kubernetes является комплексной, многослойной системой, состоящей из нескольких ключевых компонентов.

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

Основные компоненты сети Kubernetes (помимо Ingress)

1. CNI (Container Network Interface) - Фундамент

Это не конкретный компонент, а стандарт, который реализуют сетевые плагины (Calico, Cilium, Flannel, Weave Net). Именно CNI-плагин отвечает за самое главное:

• Выделение IP-адресов каждому Pod'у.
• Обеспечение связности между Pod'ами на разных узлах (overlay- или underlay-сети).
• Реализацию сетевой политимы (если поддерживается).

Без работающего CNI кластер Kubernetes не функционирует, так как Pod'ы не могут общаться.

# Пример: проверка сетевых интерфейсов Pod'а (выполняется на узле)
kubectl exec <pod-name> -- ip addr show
# Вы увидите `eth0` с IP из диапазона CNI плагина (например, 10.244.1.5 для Flannel)

2. Service - Базовая абстракция для доступа к приложениям

Service - это абстракция, определяющая стабильную точку доступа к группе динамических Pod'ов.

• ClusterIP (по умолчанию): Виртуальный IP, доступный только внутри кластера. Основной механизм сервис-сервисного взаимодействия (backend -> database).
• NodePort: Открывает статический порт на каждом узле кластера, пробрасывая трафик на Service. Используется для прямого доступа извне без LoadBalancer или как основа для Ingress.
• LoadBalancer: Интегрируется с облачным провайдером (AWS ELB, GCP Load Balancer) для создания внешней балансировки нагрузки. Часто является "нижним слоем" для Ingress Controller'а.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80        # Порт, на котором Service доступен
      targetPort: 8080 # Порт контейнера в Pod
  type: ClusterIP

3. DNS - Система имен для Service и Pod

Внутренний CoreDNS (или kube-dns) отвечает за преобразование имен в IP-адреса внутри кластера.

• Сервису my-app-service в namespace default соответствует полное доменное имя (FQDN): my-app-service.default.svc.cluster.local.
• Это позволяет микросервисам обращаться друг к другу по именам, не заботясь об изменяющихся IP-адресах Pod'ов.

4. NetworkPolicy - Фаервол на уровне Pod

Если CNI-плагин поддерживает эту функцию (например, Calico, Cilium), NetworkPolicy позволяет определять правила входящего (ingress) и исходящего (egress) трафика для Pod'ов на уровне L3/L4 (IP/порт). Это критически важный инструмент для модели "микросервисы с нулевым доверием".

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

5. Egress и специализированные шлюзы для исходящего трафика

Для контроля исходящего трафика из кластера во внешний мир используются:

• Egress NetworkPolicies: Ограничивают, к каким внешним IP/портам могут обращаться Pod'ы.
• Egress Gateways / NAT Gateways (в Istio): Централизованные точки для исходящего трафика, обеспечивающие единую политику маршрутизации, безопасность и мониторинг.
• Конфигурация CNI-плагина и таблиц маршрутизации на узлах.

6. Gateway API - Эволюция Ingress и Service Mesh

Gateway API - это современная, расширяемая и более богатая с точки зрения возможностей замена Ingress API. Он четко разделяет роли:

• GatewayClass: Тип шлюза (например, "nginx", "istio").
• Gateway: Развертывание шлюза, определяет сетевую точку входа (Listener'ы на портах).
• HTTPRoute, TCPRoute: Привязывают правила маршрутизации трафика от Gateway к конкретным Service.

Это позволяет реализовать сложные сценарии (кросс-неймспейсная маршрутизация, балансировка на уровне L4) более декларативно.

Краткое сравнение ролей

Таким образом, Ingress — это лишь верхушка айсберга, решающая конкретную задачу маршрутизации HTTP(S). Настоящую "тяжелую" сетевую работу выполняют CNI, Service, DNS и NetworkPolicy. Современные экосистемы, такие как Service Mesh (Istio, Linkerd), добавляют еще один мощный слой, беря на себя управление трафиком (canary-развертывания, retry, circuit breaking), безопасностью (mTLS) и наблюдаемостью поверх этой базовой сетевой инфраструктуры. Понимание роли каждого компонента и их взаимодействия — ключ к построению надежных, безопасных и производительных приложений в Kubernetes.