Networking 20/80, уровень 6: Балансировка нагрузки и сети Kubernetes

L4 (Transport):
  Решение на основе: IP + порт
  Не знает: HTTP, URL, заголовки, cookies
  Скорость: очень быстрая (просто перенаправляет пакеты)
  Примеры: HAProxy (mode tcp), AWS NLB, K8s Service (ClusterIP)

L7 (Application):
  Решение на основе: URL path, Host header, cookies, HTTP method
  Знает: весь HTTP-запрос
  Скорость: медленнее (разбирает HTTP)
  Примеры: nginx, HAProxy (mode http), AWS ALB, K8s Ingress

Интернет
    │
    ▼
┌──────────────────────┐
│  Ingress Controller  │  L7: маршрутизация по Host/Path
│  (nginx-ingress)     │  терминация TLS
└──────────┬───────────┘
           │
    ┌──────▼──────┐
    │   Service    │  L4: ClusterIP, стабильный виртуальный IP
    │ (ClusterIP)  │  правила iptables/IPVS для распределения
    └──────┬──────┘
           │
    ┌──────┼──────┐
    │      │      │
  ┌─▼─┐ ┌─▼─┐ ┌─▼─┐
  │Pod│ │Pod│ │Pod│  Реальные контейнеры
  │ 1 │ │ 2 │ │ 3 │  Каждый с уникальным IP
  └───┘ └───┘ └───┘

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

kubectl get svc api
# NAME  TYPE        CLUSTER-IP    PORT(S)
# api   ClusterIP   10.96.45.12   8080/TCP

# Доступен ТОЛЬКО внутри кластера:
# curl http://10.96.45.12:8080  (из pod-а)
# curl http://api:8080          (DNS резолвит в ClusterIP)

spec:
  type: NodePort
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 30080          # 30000–32767

Снаружи: curl http://<любая-нода>:30080
  → DNAT → ClusterIP → Pod

spec:
  type: LoadBalancer           # облачный LB (AWS ELB, GCP LB)
  ports:
    - port: 80
      targetPort: 8080

Снаружи: curl http://<cloud-lb-ip>:80
  → Cloud LB → NodePort → ClusterIP → Pod

spec:
  type: ExternalName
  externalName: rds.amazonaws.com    # CNAME → внешний сервис

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls-cert        # TLS-сертификат в Secret
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 3000

1. DNS: api.example.com → IP Ingress Controller
2. TLS: Ingress Controller терминирует TLS (расшифровывает)
3. HTTP: Host=api.example.com, Path=/api
4. Routing: Ingress Controller → Service api-service:8080 → Pod

# /etc/nginx/conf.d/api.conf

upstream api_backend {
    server 10.0.0.10:8080 weight=3;    # 3 из 4 запросов
    server 10.0.0.11:8080 weight=1;    # 1 из 4 запросов
    server 10.0.0.12:8080 backup;      # только если первые два упали

    # Health check (nginx plus) или passive:
    # server 10.0.0.10:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_read_timeout 60s;    # + остальные timeouts и security headers в проде
    }

    location / {
        proxy_pass http://frontend:3000;
    }
}

# Метод балансировки задаётся ОДНОЙ директивой на upstream
# (по умолчанию – Round Robin). Раскомментируй НУЖНЫЙ –
# методы нельзя смешивать в одном upstream:
upstream backend {
    # least_conn;          # к серверу с наименьшим числом активных соединений
    # ip_hash;             # закрепить клиента по его IP (sticky без cookie)
    # hash $request_uri consistent;   # consistent hashing (ketama) по ключу – удобно для кеширования

    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

Без mesh:              С mesh (Istio/Linkerd):
Pod → Pod              Pod → Sidecar → Sidecar → Pod
                           (Envoy)    (Envoy)

Что даёт sidecar:
- mTLS между сервисами (автоматическое шифрование)
- Retries, timeouts, circuit breaking
- Traffic splitting (canary: 5% → новая версия)
- Observability (метрики, traces) без изменения кода

# 1. Pod → Pod (в одном namespace):
kubectl exec pod-a -- curl http://pod-b-ip:8080
# Работает? → сеть между pod-ами ОК

# 2. Pod → Service:
kubectl exec pod-a -- curl http://service-name:8080
# Не работает? → проблема с DNS или Service selector

# 3. DNS внутри pod-а:
kubectl exec pod-a -- nslookup service-name
# NXDOMAIN? → Service не существует или неправильный namespace
# Timeout? → CoreDNS не отвечает

# 4. Service selector совпадает с pod labels?
kubectl get svc api -o yaml | grep -A3 selector
kubectl get pods -l app=api
# Если pod-ов нет → Endpoints пустые → Service не знает, куда слать

# 5. Endpoints:
kubectl get endpoints api
# Если пустые → selector не матчит ни один pod

# 6. Ingress → Service:
kubectl describe ingress app-ingress
# Проверить: backend service существует? Порт правильный?
# Events: "error obtaining endpoints" → Service/Endpoints проблема

# 7. Извне → Ingress:
curl -v https://api.example.com
# Проверить: DNS → IP Ingress Controller? TLS-сертификат валидный?

# Pod CIDR ноды:
kubectl get node worker-1 -o jsonpath='{.spec.podCIDR}'
# 10.244.1.0/24

# Pod IP:
kubectl get pod api-xxx -o jsonpath='{.status.podIP}'
# 10.244.1.15

# На ноде – veth pair:
ip link show | grep veth
# vethc49c832@if3: <BROADCAST,MULTICAST,UP>

# kube-proxy создаёт правила вроде:
# Если dst = 10.96.45.12:8080 (ClusterIP)
# → DNAT к одному из: 10.244.1.15:8080, 10.244.2.8:8080, 10.244.3.22:8080

# Пакет идёт НАПРЯМУЮ от pod к pod, через iptables DNAT
# kube-proxy не участвует в пути данных!

Пользователь вводит: https://api.example.com/users