Как идут запросы извне к микросервису в Kubernetes

Архитектура входящих запросов в Kubernetes

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

1. Входная точка: Ingress Controller или Service типа LoadBalancer

Запросы из внешнего мира сначала достигают контроллера входящего трафика или сервиса с внешним IP:

# Пример Ingress ресурса для маршрутизации трафика
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80

Ingress Controller (Nginx, Traefik, HAProxy) анализирует заголовок Host и путь запроса, затем направляет его на соответствующий Kubernetes Service.

2. Service: абстракция доступа к подам

Сервис обеспечивает стабильную точку доступа к динамически меняющемуся набору подов:

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-api
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP  # Внутренний IP, доступен только внутри кластера

Service не обрабатывает трафик самостоятельно, а использует kube-proxy для настройки правил iptables/ipvs, которые перенаправляют трафик на конкретные поды.

3. kube-proxy и сетевые правила

На каждом узле Kubernetes работает kube-proxy, который отслеживает изменения Service и Pod через API-сервер:

# Просмотр iptables правил, созданных kube-proxy
sudo iptables-save | grep user-service

Для каждого Service kube-proxy создает правила, которые:

• Выполняют random load balancing между всеми доступными подами
• Поддерживают session affinity при необходимости
• Обеспечивают health checking через readiness probes

4. Доставка до Pod и контейнера

Запрос достигает конкретного пода, где обрабатывается контейнером приложения:

# Конфигурация контейнера в поде
spec:
  containers:
  - name: user-api
    image: myregistry/user-api:v1.2
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

Важные аспекты:

• Network Policies могут блокировать нежелательный трафик
• Readiness Probes исключают неготовые поды из балансировки нагрузки
• Resource Limits предотвращают исчерпание ресурсов узла

5. Современные подходы: Service Mesh

В сложных микросервисных архитектурах часто внедряют service mesh (Istio, Linkerd):

# Istio VirtualService для расширенной маршрутизации
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - match:
    - headers:
        version:
          exact: "v2"
    route:
    - destination:
        host: user-service
        subset: v2

Service mesh добавляет:

• Трафик management: canary deployments, A/B-тестирование
• Безопасность: взаимная TLS аутентификация, авторизация
• Наблюдаемость: распределенное трассирование, метрики

Критические моменты для DevOps инженера

1. Производительность: Мониторинг задержек на каждом этапе

   # Мониторинг latency через Prometheus метрики
   histogram_quantile(0.95, rate(nginx_ingress_request_duration_seconds_bucket[5m]))
   

2. Безопасность:

   • TLS termination на уровне Ingress
   • Network Policies для сегментации трафика
   • WAF (Web Application Firewall) интеграция

3. Надежность:

   • Retry policies и circuit breakers
   • Graceful shutdown при обновлениях
   • Межзональная балансировка для HA

4. Масштабирование:

   • Horizontal Pod Autoscaler на основе метрик
   • Cluster Autoscaler для добавления узлов
   • Подготовка к внезапным скачкам нагрузки

Полный путь запроса: Внешний клиент → DNS → Cloud Load Balancer → Ingress Controller → Service → kube-proxy (iptables/ipvs) → Pod (контейнер) → Приложение.

Для production-сред необходимо предусмотреть multi-layer redundancy, comprehensive monitoring и automated disaster recovery процедуры. Современные практики также включают использование API Gateways для агрегации запросов и eBPF для ускорения сетевых операций.