🏗️ Раздел 17 · Вопрос #26

Какие инструменты используются для оркестрации микросервисов

4. Docker Swarm: Встроенный в Docker простой кластерный оркестратор для небольших проектов с низкой сложностью.

🏗️ Микросервисы 📄 Исходный Markdown

🟢 Junior Level

Оркестрация микросервисов — это автоматизированное управление жизненным циклом сотен и тысяч контейнеризованных приложений: их развертывание (deployment), распределение по физическим серверам (scheduling), мониторинг жизнеспособности (health checks), автоматическое масштабирование (autoscaling) и балансировка сетевого трафика.

Кластер оркестрации (Kubernetes / Nomad):
                       ┌──────────────────────────────┐
                       │   Master Node / Control Plane│
                       │   (API Server, etcd, Shed.)  │
                       └──────────────┬───────────────┘
                                      │ Назначение задач
          ┌───────────────────────────┼───────────────────────────┐
          ▼                           ▼                           ▼
    [Worker Node 1]             [Worker Node 2]             [Worker Node 3]
  ├── Order Pod #1            ├── Order Pod #2            ├── Order Pod #3
  └── User Pod #1             └── Payment Pod #1          └── User Pod #2

Основные инструменты индустрии:

  1. Kubernetes (K8s): Общепризнанный стандарт де-факто (Open Source проект под эгидой CNCF). Поддерживается всеми ведущими облачными провайдерами (AWS EKS, Google GKE, Azure AKS).
  2. Docker Compose: Инструмент для запуска мультиконтейнерных приложений на одной локальной машине. Используется исключительно для разработки и локального тестирования, но не в Production.
  3. HashiCorp Nomad: Легковесный оркестратор от HashiCorp. Проще в настройке, чем Kubernetes, и умеет оркестровать не только Docker-контейнеры, но и сырые бинарные файлы, Java JAR и виртуальные машины.
  4. Docker Swarm: Встроенный в Docker простой кластерный оркестратор для небольших проектов с низкой сложностью.

🟡 Middle Level

1. Архитектура и основные объекты Kubernetes

В Kubernetes управление строится на декларативных манифестах YAML:

[ Ingress (Точка входа) ] ──► [ Service (Стабильный DNS / IP) ] ──► [ Deployment (ReplicaSet) ] ──► [ Pods (Контейнеры) ]
  • Pod (Под): Минимальная единица развертывания, состоящая из одного или нескольких тесно связанных контейнеров, разделяющих общую сеть (localhost) и дисковые тома (Volumes).
  • Deployment: Декларативное описание желаемого состояния подов (количество реплик, стратегия обновления RollingUpdate, лимиты ресурсов).
  • Service (ClusterIP, NodePort, LoadBalancer): Сетевая абстракция, предоставляющая стабильный виртуальный IP-адрес и DNS-имя для группы подов.
  • Ingress / Gateway API: Маршрутизатор внешнего HTTP(S) трафика на внутренние сервисы кластера.

2. Манифест промышленного Deployment в K8s

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels:
    app: order-service
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Создать максимум 1 дополнительный под при обновлении
      maxUnavailable: 0  # Ни один под не должен быть недоступен во время релиза
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: registry.example.com/order-service:2.1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
          limits:
            cpu: 1000m
            memory: 1024Mi
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 5

🔴 Senior Level

1. Экосистема оркестрации современного Enterprise

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

[Git-репозиторий с манифестами]
       │
       ▼ (Pull-модель: непрерывная сверка)
[ArgoCD / Flux (GitOps)] ──► Применение в [Kubernetes Cluster]
                                    │
                                    ├── Управление пакетами: [Helm / Kustomize]
                                    ├── Управление сетью/mTLS: [Istio / Linkerd Service Mesh]
                                    ├── Хранение секретов: [HashiCorp Vault / External Secrets]
                                    └── Автомасштабирование: [HPA v2 / KEDA]
  1. Пакетные менеджеры (Helm vs Kustomize):
    • Helm: Шаблонизация через Go-шаблоны и параметризация через values.yaml. Идеален для пакетирования сторонних компонентов (Kafka, Redis, Postgres).
    • Kustomize: Декларативное наложение патчей (Overlays) без шаблонов: базовый манифест (base) модифицируется под разные окружения (dev, stage, prod).
  2. GitOps (ArgoCD / Flux):
    • Единственным источником истины (Single Source of Truth) для кластера является Git-репозиторий.
    • Прямой вызов kubectl apply с компьютеров разработчиков запрещен.
    • Агент ArgoCD в кластере периодически опрашивает Git и автоматически устраняет рассинхронизацию (Self-Healing & Drift Detection).

2. Service Mesh: Умная сетевая оркестрация (Istio / Envoy)

Когда оркестратор поднимает тысячи подов, управление сетевыми связями перекладывается на Service Mesh:

  • Canary Deployments (Канареечные релизы): Маршрутизация 5% пользовательского трафика на новую версию v2 и 95% на стабильную v1 через конфигурацию VirtualService.
  • Zero-Trust mTLS: Автоматическое взаимное шифрование всего трафика между контейнерами без изменения Java-кода.
  • Fault Injection: Искусственная проверка надежности: указание Envoy симулировать 10% ответов с задержкой 5 сек или ошибкой HTTP 503.

4 Tricky Questions

1. В чем разница между K8s Deployment и StatefulSet, и почему базы данных (PostgreSQL, Kafka) нельзя разворачивать через обычный Deployment?

Ответ:

  • Deployment предназначен для приложений Stateless: поды абсолютно взаимозаменяемы, получают случайные имена (order-service-7f4c9b9-x8j2k) и случайные IP. При рестарте под может подняться на другой ноде и потерять связь с локальным диском.
  • StatefulSet предназначен для Stateful-нагрузок (СУБД, кластеры брокеров):
    1. Поды получают строго детерминированные имена: postgres-0, postgres-1, postgres-2.
    2. Каждый под привязывается к своему персональному диску через volumeClaimTemplates (PersistentVolumeClaim). При перезапуске под гарантированно подключается к своим историческим данным.
    3. Поды запускаются и останавливаются строго по порядку (0 $\to$ 1 $\to$ 2), что критично для инициализации кворума кластера (Raft/Zookeeper/Patroni).

2. Зачем нужен PodDisruptionBudget (PDB) и TopologySpreadConstraints при плановом обновлении рабочих узлов кластера?

Ответ: Когда DevOps-инженеры обновляют операционную систему рабочих нод кластера (kubectl drain node):

  1. PodDisruptionBudget (PDB): Устанавливает жесткий инвариант доступности приложения (например, minAvailable: 2). Kubernetes откажется выводить ноду на обслуживание до тех пор, пока на других нодах не поднимутся и не станут готовыми (Ready) минимум 2 реплики сервиса. Это исключает каскадное отключение сервиса.
  2. TopologySpreadConstraints: Принудительно размазывает поды сервиса по разным физическим зонам доступности (AWS Availability Zones: az-a, az-b, az-c) или серверным стойкам. Если молния ударит в один дата-центр, система продолжит работу.

3. В каких сценариях HashiCorp Nomad является более оправданным выбором, чем Kubernetes?

Ответ:

  1. Ограниченная команда и дефицит DevOps-ресурсов: Nomad распространяется в виде одного легковесного бинарного файла (Zero-Dependency), потребляющего десятки мегабайт памяти, в то время как кластер K8s требует сложного control plane, etcd и высокой квалификации инженеров.
  2. Гетерогенные нагрузки (Non-Container Workloads): Nomad из коробки запускает не только Docker-контейнеры, но и нативные Java JAR приложения (java драйвер), бинарники Go/C++ (exec драйвер) и виртуальные машины QEMU.
  3. Интеграция в экосистему HashiCorp: бесшовная связка с Consul (Service Discovery/Mesh) и Vault (Secrets Management).

4. Что такое «Configuration Drift» в GitOps и как ArgoCD предотвращает саботаж инфраструктуры?

Ответ: Configuration Drift возникает, когда кто-то из инженеров вручную выполняет в кластере команду типа kubectl scale deployment order-service --replicas=10 или меняет переменные окружения в обход репозитория Git. В традиционном CI/CD такое изменение может оставаться незамеченным месяцами. В GitOps (ArgoCD) агент непрерывно сравнивает желаемое состояние (Desired State в Git) с фактическим состоянием (Actual State в кластере K8s). При обнаружении ручного вмешательства ArgoCD немедленно поднимает статус OutOfSync и, если включен режим Self-Healing, автоматически перезаписывает ручные изменения манифестами из Git, возвращая кластер к согласованному состоянию.

🎯 Шпаргалка для интервью

Главное:

  • Оркестрация — автоматизированное управление жизненным циклом распределённых контейнеров (деплой, скейлинг, health checks, роутинг).
  • Kubernetes (K8s) — де-факто стандарт индустрии для Production.
  • Docker Compose — инструмент исключительно для локальной разработки, но не для продакшена.
  • Основные объекты K8s: Pod, Deployment (Stateless), StatefulSet (Stateful / БД), Service (сеть), Ingress (входная точка).
  • Helm (пакетный менеджер с шаблонами) и Kustomize (оверлеи без шаблонов) — стандарт управления манифестами.
  • GitOps (ArgoCD / Flux): Единственный источник правды — Git. Все изменения применяются через автоматическую синхронизацию.
  • Service Mesh (Istio / Linkerd): Добавляет умную маршрутизацию (Canary), mTLS и наблюдаемость на уровне сетевых sidecar-прокси Envoy.

Красные флаги (Чего говорить НЕЛЬЗЯ):

  • ❌ «Мы используем Docker Compose для оркестрации микросервисов в продакшене на 10 серверах» (Docker Compose не умеет балансировать между нодами кластера и лечить упавшие узлы).
  • ❌ «Базы данных разворачиваются в Kubernetes через обычный Deployment» (Базы требуют StatefulSet с гарантией порядка имен и привязки дисков).
  • ❌ «Разработчики деплоят код в Kubernetes напрямую командой kubectl apply со своего ноутбука» (Нарушает аудит и безопасность; деплой должен идти строго через GitOps / ArgoCD).

Связанные темы: