Какая сущность занимается перераспределением запросов в Kubernetes?

Question

deepseek-v3.2 · Accepted Answer

## Распределение запросов в Kubernetes: Ingress, Service и Service Mesh

В Kubernetes нет единой "сущности", которая монопольно занимается перераспределением запросов. Это распределённая задача, которую выполняют несколько ключевых компонентов в зависимости от уровня и типа трафика. Основными "дирижёрами" трафика являются: **Service**, **Ingress Controller** и **Service Mesh**.

### 1. Service: балансировка на L4 (транспортный уровень)

**Service** — это базовая и основная абстракция для балансировки нагрузки внутри кластера. Когда вы создаёте Pod'ы (например, Deployment), Service действует как стабильная конечная точка (виртуальный IP-адрес и DNS-имя), которая автоматически распределяет входящие запросы между всеми здоровыми Pod'ами, соответствующими селекторам Service.

*   **Как это работает:** Kube-proxy, работающий на каждом узле кластера, настраивает правила iptables или IPVS, которые перенаправляют трафик, пришедший на виртуальный IP (ClusterIP) сервиса, на реальные IP-адреса Pod'ов. Алгоритм балансировки по умолчанию — случайный выбор.
*   **Уровень:** Транспортный (TCP/UDP). Service не смотрит на содержимое HTTP-запроса (пути, заголовки).

```yaml
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app # Селектор для поиска Pod'ов
  ports:
    - protocol: TCP
      port: 80 # Порт, на котором Service принимает запросы
      targetPort: 8080 # Порт на Pod'ах, куда перенаправлять
  type: ClusterIP # Самый распространённый тип, виден только внутри кластера
```

### 2. Ingress Controller: маршрутизация на L7 (уровень приложений, HTTP/HTTPS)

**Ingress** — это набор правил для входящего внешнего HTTP(S)-трафика. Однако сами по себе ресурсы Ingress ничего не делают. Для их исполнения необходим **Ingress Controller** — это реальный работающий Pod (например, Nginx, Traefik, HAProxy), который отслеживает объекты Ingress в API Kubernetes и динамически переконфигурирует балансировщик нагрузки.

*   **Как это работает:** Внешний трафик поступает на LoadBalancer (облачный или аппаратный) или NodePort сервис Ingress Controller'а. Контроллер анализирует правила Ingress (например, хост `api.example.com` и путь `/v1/users`) и перенаправляет запрос на соответствующий внутренний Kubernetes Service.
*   **Уровень:** Прикладной (HTTP/HTTPS). Позволяет маршрутизировать на основе хоста, пути, заголовков, производить TLS-терминацию.

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service # Запросы идут в этот Service
            port:
              number: 80
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service # А запросы с другим путём — в другой
            port:
              number: 8080
```

### 3. Service Mesh (e.g., Istio, Linkerd): интеллектуальное управление трафиком и безопасностью

**Service Mesh** — это отдельный инфраструктурный слой для коммуникации "сервис-сервис" внутри кластера. Он вводит концепцию **sidecar-прокси** (например, Envoy), который внедряется в каждый Pod и перехватывает весь входящий и исходящий трафик.

*   **Как это работает:** Service Mesh позволяет декларативно (через CRD, например, **VirtualService** и **DestinationRule** в Istio) управлять трафиком с высочайшей гранулярностью: **canary-развёртывания**, **A/B-тестирование**, разделение трафика по процентам, задержки, повторные попытки, ограничители скорости, аварийные выключатели (circuit breaker).
*   **Уровень:** Транспортный и прикладной. Действует как "умная" надстройка над стандартным Kubernetes Service.

```yaml
# Пример Istio VirtualService для canary-развёртывания
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews.prod.svc.cluster.local
  http:
  - route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v1 # Старая версия
      weight: 90 # 90% трафика
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v2 # Новая версия
      weight: 10 # 10% трафика на канареечное развёртывание
```

### Сводка и взаимодействие компонентов

В типичном сценарии внешний запрос проходит следующую цепочку:

1.  **Внешний балансировщик облака** (или аналоги) получает запрос и направляет его на один из Pod'ов **Ingress Controller**.
2.  **Ingress Controller** (например, Nginx) анализирует HTTP-заголовки, находит подходящее правило **Ingress** и перенаправляет запрос на виртуальный IP-адрес (ClusterIP) нужного **Service**.
3.  **Service** (через `kube-proxy`) балансирует запрос на уровне TCP/UDP, выбирая один из множества Pod'ов приложения.
4.  Если установлен **Service Mesh**, sidecar-прокси в Pod'е приложения перехватывает запрос ещё до того, как он попадёт в контейнер приложения, и может применить сложные правила маршрутизации, политики безопасности и сбора телеметрии.

Таким образом, **перераспределение запросов в Kubernetes — это кооперативная работа нескольких сущностей:** **Service** обеспечивает базовую внутреннюю балансировку, **Ingress Controller** — входную точку и маршрутизацию на уровне HTTP, а **Service Mesh** — наиболее продвинутое, безопасное и наблюдаемое управление трафиком между сервисами.

Какая сущность занимается перераспределением запросов в Kubernetes?

Комментарии (1)

Распределение запросов в Kubernetes: Ingress, Service и Service Mesh

1. Service: балансировка на L4 (транспортный уровень)

2. Ingress Controller: маршрутизация на L7 (уровень приложений, HTTP/HTTPS)

3. Service Mesh (e.g., Istio, Linkerd): интеллектуальное управление трафиком и безопасностью

Сводка и взаимодействие компонентов