Які інструменти використовуються для оркестрації мікросервісів
Kubernetes — де-факто стандарт завдяки: відкритість (CNCF), підтримка усіма хмарними провайдерами (GKE, EKS, AKS), величезна спільнота, стандартний API.
🟢 Junior Level
Оркестрація — це управління життєвим циклом мікросервісів: запуск, зупинка, масштабування, оновлення.
Kubernetes — де-факто стандарт завдяки: відкритість (CNCF), підтримка усіма хмарними провайдерами (GKE, EKS, AKS), величезна спільнота, стандартний API.
Основні інструменти
| Інструмент | Що робить |
|---|---|
| Kubernetes (K8s) | Оркестрація контейнерів (де-факто стандарт) |
| Docker Compose | Локальна оркестрація для розробки |
| Docker Swarm | Проста оркестрація контейнерів |
| Apache Mesos | Оркестрація кластерів |
| HashiCorp Nomad | Проста альтернатива Kubernetes |
Docker Compose (для розробки)
version: '3.8'
services:
api-gateway:
build: ./gateway
ports:
- "8080:8080"
depends_on:
- user-service
- order-service
user-service:
build: ./user-service
environment:
- DB_HOST=postgres
- KAFKA_BROKERS=kafka:9092
order-service:
build: ./order-service
environment:
- DB_HOST=postgres
- KAFKA_BROKERS=kafka:9092
postgres:
image: postgres:15
# Версії образів (cp-kafka:7.5.0, postgres:15) — приклади на момент написання.
# У production використовуйте останні стабільні версії.
environment:
POSTGRES_PASSWORD: secret
kafka:
image: confluentinc/cp-kafka:7.5.0
ports:
- "9092:9092"
Kubernetes — базовий Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: user-service
spec:
replicas: 3
selector:
matchLabels:
app: user-service
template:
metadata:
labels:
app: user-service
spec:
containers:
- name: user-service
image: registry.example.com/user-service:1.2.0
ports:
- containerPort: 8080
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
Коли НЕ використовувати Kubernetes
- Маленька команда (1-3 dev) — операційна складність невиправдана
- Прості додатки — Docker Compose достатньо
- Строгі budget обмеження — K8s вимагає мінімум 3 нод
🟡 Middle Level
Kubernetes — основні ресурси
# Service — мережевий доступ до подів
apiVersion: v1
kind: Service
metadata:
name: user-service
spec:
selector:
app: user-service
ports:
- port: 80
targetPort: 8080
type: ClusterIP # внутрішній доступ
---
# Ingress — зовнішній доступ через API Gateway
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-gateway
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
- path: /orders
pathType: Prefix
backend:
service:
name: order-service
port:
number: 80
Helm — пакетний менеджер для K8s
# Chart.yaml
apiVersion: v2
name: microservices-stack
version: 1.0.0
dependencies:
- name: user-service
version: 1.0.0
- name: order-service
version: 1.0.0
- name: kafka
version: 22.0.0
repository: https://charts.bitnami.com/bitnami
Rolling Update — оновлення без downtime
# Оновлення версії
kubectl set image deployment/user-service \
user-service=registry.example.com/user-service:1.3.0
# Відкат при проблемах
kubectl rollout undo deployment/user-service
# Перевірка статусу
kubectl rollout status deployment/user-service
Service Mesh — Istio
# VirtualService — управління трафіком
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: user-service
spec:
hosts:
- user-service
http:
- route:
- destination:
host: user-service
subset: v1
weight: 90
- destination:
host: user-service
subset: v2
weight: 10 # Canary deployment — 10% трафіку на v2
---
# DestinationRule — підмножини
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: user-service
spec:
host: user-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
Порівняння інструментів
| Інструмент | Складність | Масштаб | Use Case |
|---|---|---|---|
| Docker Compose | Низька | 1 хост | Локальна розробка |
| Docker Swarm | Середня | Кілька хостов | Малі кластери |
| Kubernetes | Висока | Будь-яке | Production (де-факто стандарт) |
| Nomad | Середня | Будь-яке | Проста альтернатива K8s |
| OpenShift | Висока | Enterprise | Kubernetes + додаткові інструменти |
🔴 Senior Level
Архітектура оркестрації
┌─────────────────────────────────────────┐
│ API Gateway / Ingress │
│ (Nginx, Traefik, Istio) │
└────────────┬────────────────────────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌─────────▼────┐ ┌────────▼──────┐ ┌───────▼──────┐
│ User Service │ │Order Service │ │Notify Service│
│ (3 replicas) │ │ (5 replicas) │ │ (2 replicas) │
└─────────┬────┘ └────────┬──────┘ └───────┬──────┘
│ │ │
┌─────────▼────┐ ┌────────▼──────┐ ┌───────▼──────┐
│ PostgreSQL │ │ PostgreSQL │ │ Kafka │
│ (Primary + │ │ (Primary + │ │ Cluster │
│ Replica) │ │ Replica) │ │ │
└──────────────┘ └───────────────┘ └──────────────┘
HPA — Horizontal Pod Autoscaler
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: user-service-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: user-service
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: "1000"
behavior:
scaleUp:
stabilizationWindowSeconds: 60
// stabilizationWindowSeconds: період «остивання» після масштабування.
// scaleDown: 300s — повільне зменшення (уникаємо flapping).
// scaleUp: 60s — швидке додавання (реагуємо на піки).
policies:
- type: Pods
value: 4
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300 # Не зменшувати різко
policies:
- type: Pods
value: 1
periodSeconds: 120
PodDisruptionBudget — захист від cascading failures
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: user-service-pdb
spec:
minAvailable: 2 # Мінімум 2 пода завжди працюють
selector:
matchLabels:
app: user-service
GitOps — ArgoCD / Flux
# ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: user-service
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/company/k8s-manifests
targetRevision: HEAD
path: k8s/user-service
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
Kustomize — управління конфігураціями для різних середовищ
# kustomization.yaml (base)
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml
- ingress.yaml
# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patches:
- target:
kind: Deployment
name: user-service
patch: |-
- op: replace
path: /spec/replicas
value: 5
Service Mesh Patterns
# Fault Injection — тестування стійкості
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: user-service-fault
spec:
hosts:
- user-service
http:
- fault:
delay:
percentage:
value: 10
fixedDelay: 5s
abort:
percentage:
value: 5
httpStatus: 503
route:
- destination:
host: user-service
# Rate Limiting
apiVersion: networking.istio.io/v1beta1
kind: EnvoyFilter
metadata:
name: rate-limit
spec:
configPatches:
- applyTo: HTTP_FILTER
match:
context: SIDECAR_INBOUND
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.local_ratelimit
Production Checklist
✅ Helm Charts для пакування
✅ GitOps (ArgoCD/Flux) для деплою
✅ HPA для автоскейлінгу
✅ PDB для захисту від cascading failures
✅ Pod Anti-Affinity для розподілу по нодах
✅ Resource Limits для запобігання noisy neighbor
✅ Liveness/Readiness/Startup Probes
✅ Service Mesh (Istio/Linkerd) для observability
✅ Canary/Blue-Green deployments
✅ Network Policies для ізоляції
✅ Secrets Management (Vault, Sealed Secrets)
✅ Pod Security Standards
🎯 Шпаргалка для співбесіди
Обов’язково знати:
- Kubernetes — де-факто стандарт для production оркестрації (CNCF, усі хмарні провайдери)
- Docker Compose — локальна розробка, не production
- Основні ресурси K8s: Deployment, Service, Ingress, HPA, PDB
- HPA — автоматичне масштабування за CPU/memory/custom metrics
- Helm — пакетний менеджер для K8s, dependency management
- Rolling Update — оновлення без downtime, rollback однією командою
- Service Mesh (Istio) — canary deployment, fault injection, rate limiting
- GitOps (ArgoCD/Flux) — автоматичний деплой з git-репозиторію
- НЕ використовувати K8s для маленьких команд (1-3 dev), простих додатків
Часті уточнюючі питання:
- HPA stabilizationWindowSeconds? Період «остивання» після масштабування. scaleUp: 60s (швидко), scaleDown: 300s (повільно, уникаємо flapping).
- PodDisruptionBudget навіщо? Гарантує мінімум працюючих подів при maintenance — minAvailable: 2.
- Istio fault injection? Навмисно додає delay/abort для тестування стійкості — chaos engineering.
- GitOps переваги? Audit trail (git history), rollback = git revert, self-healing (ArgoCD синхронізує).
Червоні прапорці (НЕ говорити):
- “Docker Compose для production” — ні, тільки для розробки
- “K8s потрібен для кожного проекту” — ні, операційна складність невиправдана для маленьких команд
- “HPA з 95% CPU — ефективно” — ні, не встигне масштабуватися
- “Istio = заміна Kubernetes” — ні, Istio працює поверх K8s (service mesh)
Пов’язані теми:
- [[12. Як реалізувати горизонтальне масштабування мікросервісів]]
- [[7. Що таке Service Discovery і навіщо він потрібен]]
- [[9. Що таке API Gateway і які завдання він вирішує]]
- [[21. Як моніторити розподілену систему мікросервісів]]
- [[17. Як забезпечити відмовостійкість мікросервісів]]