Как организовать доступ к контейнеру извне в Kubernetes

Организация доступа к контейнеру извне в Kubernetes

В Kubernetes доступ к контейнерам извне организуется не напрямую, а через абстракции Service (Сервис) и Ingress (Вход), которые являются основными компонентами сетевой модели. Прямое подключение к Pod'ам не рекомендуется из-за их динамического, эфемерного характера — они могут перезапускаться, масштабироваться и менять IP-адреса.

Ядро механизма — это Kubernetes Service. Сервис — стабильная сетевая конечная точка, которая абстрагирует группу Pod'ов с общими метками (label selector). Сервису присваивается виртуальный IP-адрес (ClusterIP), который не меняется на протяжении жизни сервиса. Внутри кластера трафик к этому IP балансируется между всеми Pod'ами сервиса.

Основные типы Service для внешнего доступа

Для доступа извне используются два основных типа Service:

1. Service типа NodePort

    *   Сервис, помимо ClusterIP, резервирует один статический порт (в диапазоне 30000-32767) на **каждом узле (Node)** кластера.
    *   Внешние клиенты обращаются к `<IP_любого_узла>:<NodePort>`.
    *   Трафик с этого порта на узле перенаправляется (через kube-proxy) на ClusterIP сервиса и далее на Pod'ы.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-webapp-service
spec:
  type: NodePort
  selector:
    app: my-webapp
  ports:
  - port: 80        # Порт самого Service (ClusterIP)
    targetPort: 8080 # Порт контейнера в Pod
    nodePort: 30007  # (Опционально) Фиксируем порт на Node
```

    После применения этого манифеста приложение будет доступно по `http://<node1-ip>:30007`. **NodePort** прост в настройке, но неудобен для продакшена: требует ручного управления портами и знание IP-адресов узлов.

1. Service типа LoadBalancer

    *   Расширение типа **NodePort**. Kubernetes через Cloud Controller Manager автоматически создает внешний сетевой балансировщик нагрузки в облачном провайдере (AWS ELB, GCP Load Balancer, Azure LB).
    *   Балансировщик получает статический внешний IP-адрес и распределяет трафик по всем узлам на выделенный **NodePort** сервиса.
    *   Идеальный выбор для облачных сред.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-production-service
spec:
  type: LoadBalancer
  selector:
    app: my-production-app
  ports:
  - port: 80
    targetPort: 80
```

    После развертывания в облаке Kubernetes получит внешний IP-адрес (поле `EXTERNAL-IP` в выводе `kubectl get svc`), по которому приложение будет доступно из интернета.

Уровень 7 (HTTP/HTTPS) маршрутизации: Ingress

Типы Service работают на 3-4 уровнях модели OSI (TCP/UDP). Для сложной маршрутизации на уровне приложений (Level 7) — виртуальных хостов, путей, TLS-терминации — используется ресурс Ingress. Ingress не является типом сервиса. Это набор правил маршрутизации, для работы которого требуется контроллер Ingress Controller (например, Nginx, Traefik, HAProxy).

Ingress действует как интеллектуальный маршрутизатор трафика:

• Внешний трафик -> Ingress Controller (отдельный Pod) -> Service (обычно ClusterIP) -> Pod.

Пример манифеста Ingress для маршрутизации по хосту:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: app.mycompany.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-webapp-service  # Ссылка на ClusterIP Service
            port:
              number: 80

Прямой доступ (для отладки): Port-forward

Для задач отладки и разработки можно использовать kubectl port-forward. Эта команда создает безопасный туннель с локальной машины прямо в конкретный Pod или Service внутри кластера.

# Проброс порта к Pod
kubectl port-forward pod/my-webapp-pod 8080:80

# Проброс порта к Service
kubectl port-forward svc/my-webapp-service 8080:80

После этого приложение будет доступно локально по http://localhost:8080. Этот метод не предназначен для продакшен-трафика.

Сводная стратегия выбора

1. Разработка/Отладка: Используйте kubectl port-forward или Service типа NodePort.
2. Продакшен в облаке (простой сервис): Используйте Service типа LoadBalancer. Это быстро и просто.
3. Продакшен (сложные веб-приложения, несколько доменов/путей): Обязательная комбинация Ingress + Ingress Controller + Service (ClusterIP). Service типа LoadBalancer при этом создается только для самого Ingress Controller, чтобы вывести его наружу. Это стандартный и наиболее гибкий промышленный подход, обеспечивающий централизованное управление доступом, TLS и маршрутизацией.

Таким образом, организация внешнего доступа в Kubernetes — многоуровневая архитектура, где выбор инструмента зависит от среды развертывания и требований к маршрутизации. Service абстрагирует Pod'ы, LoadBalancer или NodePort выводят трафик за пределы кластера, а Ingress добавляет интеллектуальную маршрутизацию уровня приложения.