Torrent Gear

Docker и Kubernetes в iGaming: стратегії деплоя

1) Контекст iGaming: вимоги до платформи

Реал-тайм (лайв-ігри, ставки, турнірні події) → суворі p95 по API/WS.

Піки трафіку (стріми/промо) → швидкий автоскейл без «холодного старту».

Гроші та комплаєнс → ізольованість контурів, трасування релізів, контроль доступу та аудиту.

Мульти-юрисдикції/бренди → тени (namespaces/projects), політики мережевої та ресурсної ізоляції.

Ключові SLO: логін ≥ 99. 9%, депозит ≥ 99. 85%, p95 API ≤ 250-400 мс, p95 WS RTT ≤ 120 мс.

2) Базова архітектура на Kubernetes

Шари: Ingress/Edge → API/гейтвеї → сервіси (гаманець, профіль, промо, антифрод) → черги/стріми → сховища.

Ізоляція: 'namespace'на brand/market або «осередок» (cell) по регіону; окремі NodePools (public API/batch/ws-реалтайм).

Мережеві політики: 'NetworkPolicy'за принципом «deny by default», окремі egress-політики до PSP/KYC/провайдерам ігор.

Сховища: 'StorageClass'з реплікацією в межах зони/регіону, оператори для БД/кешів (Postgres/MySQL, Redis, Kafka).

3) Контейнерні образи: якість і безпека

Multi-arch (amd64/arm64), distroless або slim-бази, тільки необхідні бінарники.

SBOM і сканування вразливостей, підпис образів (Cosign), політика прийому ('ImagePolicyWebhook').

Immutable-tagging: релізи по'sha256'; «latest» заборонений.

Профілі runtime: `readOnlyRootFilesystem`, `runAsNonRoot`, `seccomp/AppArmor`, минимальные Capabilities.

4) Стратегії випуску: коли і що вибирати

RollingUpdate (за замовчуванням)

Без простою; для більшості API.

Контроль через readiness/liveness/startup probes, maxUnavailable/maxSurge.

Blue-Green

Паралельні стеки Blue і Green; перемикання трафіку на рівні Ingress/Service.

Добре для великих змін схем/конфігів; швидке rollback.

Canary

Поступове включення відсотка трафіку (5→10→25→50→100).

Тригерим SLO-гейти: p95, error-rate, аномалії в депозитах/ставках.

Варіанти: Service Mesh (Istio/Linkerd), Ingress-контролер з канарними анотаціями.

A/B и Shadow

Shadow: дзеркалимо частину трафіку на новий реліз без відповіді користувачеві (чиста телеметрія).

A/B: функціональні експерименти з прапорами (feature-flags) і сегментацією гравців/ринків.

5) GitOps і управління конфігурацією

GitOps (Argo CD/Flux): кластери читають бажаний стан з Git; всі зміни через PR і рев'ю.

Шаблони: Helm/Kustomize, єдина бібліотека чартів.

Секрети: зовнішні менеджери (Vault/Cloud SM),'ExternalSecrets '/' Secrets Store CSI'; KMS-ключі та ротація.

Пайплайн (спрощено):

1. CI збирає підписаний образ → пуш в регістрі.

2. PR змінює версію образу/конфіг → GitOps застосовує.

3. Канарний rollout з SLO-гейтами → автоматичний промоут або авто-rollback.

6) Автоскейлінг під піки і WS-навантаження

HPA за метриками програми (RPS, p95 latency, queue lag), а не тільки CPU/RAM.

KEDA для подієвого скейла (Kafka, RabbitMQ, Redis, HTTP-queue).

VPA для щоденної правки запитів/лімітів.

Cluster Autoscaler + warm-пули нод (pre-provision) на час промо/турнірів.

Специфіка WebSocket:

окремі NodePools (більше мережевих дескрипторів),'PodDisruptionBudget'для м'якого оновлення, sticky-routing (Session Affinity) через Ingress/Mesh.

7) Stateful-контури: гаманець, БД, черги

Оператори (Postgres/MySQL, Redis Sentinel/Cluster, Kafka Operator): декларативна реплікація, «PITR», автоматичні бекапи.

Політика RPO/RTO: синхронна реплікація в межах зони, асинхронна - в DR-регіони.

Idempotency/outbox для депозитів/виплат, inbox-патерн для вебхуків PSP і провайдерів ігор.

StorageClass з швидким IOPS; для гаманця - окремий клас і вузли з локальними SSD (і реплікацією).

8) Мережевий шар і гейтвеї

Ingress (Nginx/Envoy/HAProxy/ALB) з mTLS до бекендів, HTTP/2/3, HSTS, rate-limits.

Service Mesh: канарні маршрути, ретраї/тайм-аути, circuit-breakers, TLS всередині кластера за замовчуванням.

Egress-шлюзи: білі списки до PSP/KYC/провайдерів, контроль DNS і IP.

9) Observability і SLO-гейти релізів

OpenTelemetry: трасування через front→API→platyozh/igrovoy провайдер; 100% помилок і «повільних» спанів.

RED/USE-метрики + бізнес-SLI (успішність депозиту/ставки/виведення).

Логи JSON зі'trace _ id', WORM для аудиту.

Release-gates: промоут тільки якщо SLO зелені на тестовій частці.

10) Безпека: від supply chain до рантайму

Policy as Code: OPA/Gatekeeper/Kyverno (заборона privileged, вимога'runAsNonRoot', лімітів, pull-перевірок підпису).

Секрети та ключі: тільки з Secret Manager;'envFrom'мінімізувати, sidecar-ін'єкція секретів.

Webhooks/вебхуки провайдерів: HMAC-підписи, idempotency, вхід через egress-шлюз.

Compliance: аудит релізів, артефактів, доступів (RBAC/MFA), гео-ізольоване зберігання артефактів КУС/логів.

11) Мульти-регіон, failover і DR

Актив-стендбай по регіонах (мінімум для гаманця/логіна/платежів).

Трафік-роутинг: GSLB/Anycast; health-чеки по SLI (логін/депозит/ставка).

Катастрофічне перемикання: кнопка DR-cutover (freeze writes → promote DB → прогрів кешів → поетапний рулон трафіку).

Навчання: щоквартальні GameDay з «падінням» PSP, зони, провайдера ігор.

12) Управління конфігурацією і фічами

Feature-flags (конфіги в ConfigMap/External Config) - відключення важких функцій при аварії.

Versioned конфіги (хеші, checksum-анотації на Pod), canary конфіг-роллаута.

Runtime overrides на рівні Mesh/Ingress (тайм-аути, retry-політики) без ребілда образів.

13) Економіка і продуктивність

NodePools за призначеннями: RPS-API, WS-реалтайм, batch/ETL.

Spot/Preemptible для batch/ETL с `PodPriority` и `PodDisruptionBudget`.

Пакетна компіляція і прогрів (JIT/кеш шаблонів) для зниження cold-start.

Ресурсні бюджети: requests/limits, VPA рекомендації, ліміти з'єднань до БД/PSP, connection pooling.

14) Шаблони маніфестів (фрагменти)

Deployment з канаркою через анотації Ingress:

yaml apiVersion: apps/v1 kind: Deployment metadata:
name: payments-api spec:
replicas: 6 strategy:
type: RollingUpdate rollingUpdate: {maxSurge: 2, maxUnavailable: 1}
template:
metadata:
labels: {app: payments-api, version: v2}
spec:
securityContext: {runAsNonRoot: true}
containers:
- name: app image: registry/payments@sha256:...
ports: [{containerPort: 8080}]
resources:
requests: {cpu: "300m", memory: "512Mi"}
limits: {cpu: "1",  memory: "1Gi"}
readinessProbe:
httpGet: {path: /healthz, port: 8080}
periodSeconds: 5

HPA з кастомної метрики (RPS/latency через Prometheus Adapter):

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: {name: payments-api}
spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: payments-api}
minReplicas: 6 maxReplicas: 60 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"

NetworkPolicy (тільки Ingress-гейтвей і потрібні egress):

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: {name: payments-restrict}
spec:
podSelector: {matchLabels: {app: payments-api}}
policyTypes: ["Ingress","Egress"]
ingress:
- from: [{namespaceSelector: {matchLabels: {gw: ingress}}}]
egress:
- to: [{ipBlock: {cidr: 10. 0. 0. 0/8}}] # внутрішні сервіси
- to: [{namespaceSelector: {matchLabels: {svc: psp-egress}}}]

15) Чек-лист релізу (prod-ready)

Образ підписаний, SBOM зібрано, уразливості - на допустимому рівні.
Маніфести проходять policy-чек (Kyverno/OPA), мінімум привілеїв.
Readiness/Startup probes коректні;'PDB'і'PodPriority'налаштовані.
Канарковий план: 5%→10%→25%→50%→100% з SLO-гейтами і авто-rollback.
HPA/KEDA + Cluster Autoscaler; warm-пул нод під подію.
Секрети з Vault/SM; конфіги версіоновані; фіч-прапори готові до деградації.
Трасування e2e включена; алерти на SLI (депозит/ставка/вивід).
DR-план і «кнопка» cutover перевірені на стенді; бекапи/PITR тестовані.
Документація: як відкотити, як перемкнути PSP/ігрового провайдера, кого кликати вночі.

16) Анти-регрес і типові пастки

Грейс-період readiness занадто короткий → ранні 5xx при rollout.

Єдиний пул БД без лімітів → при скейлі лавина сполук.

Секрети в змінних оточення без ротації → витік.

Mesh без лімітів/тайм-аутів → зависання на деградуючих провайдерах.

HPA тільки по CPU → WS/API не встигають масштабуватися.

Резюме

Стратегії деплоя в iGaming - це поєднання надійних контейнерних практик (безпечні образи, політика доступу), розумних релізів (canary/blue-green c SLO-гейтами), правильного автоскейлу (HPA/KEDA + warm-ноди для піків), операторів для stateful-контурів, і мульти-регіонального DR.Додайте GitOps, трасування крізь платежі і провайдерів ігор, мережеві політики та економію через профільні NodePools - і ваші релізи стануть передбачуваними, швидкими і безпечними для грошей і гравців.