🏗️ Розділ 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): Загальновизнаний де-факто стандарт (відкритий проєкт під егідою 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, ліміти ресурсів CPU/RAM).
  • 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 templates та параметризація через 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 під час планового оновлення робочих вузлів кластера?

Відповідь: Коли інженери оновлюють ядро ОС чи версію K8s на робочих нодах (kubectl drain node):

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

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, повертаючи кластер до узгодженого стану.

🎯 Шпаргалка для інтерв’ю

Головне:

  • Оркестрація — автоматизоване керування життєвим циклом розподілених контейнерів (деплой, скейлінг, перевірка здоров’я, балансування трафіку).
  • 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).

Пов’язані теми: