Технології та Інфраструктура → Kubernetes-кластери та Helm-чарти

Kubernetes-кластери та Helm-чарти

1) Роль Kubernetes і Helm

Kubernetes - основа платформи додатків: стандартизує розкатку, мережу, конфіги, секрети і самовідновлення. Helm - менеджер пакетів/шаблонів, який перетворює декларативні маніфести в повторювані релізи з управлінням версіями і залежностями. Разом вони дають передбачувані деплої, швидкі відкати і єдину мову інфраструктури.

2) Дизайн кластера

2. 1 Топологія і відмовостійкість

Multi-AZ: control plane і вузли робочих пулів розподілені по зонах; PDB/TopologySpreadConstraints для рівномірності.
Мультирегіон/DR: незалежні кластери per-region; міжрегіональні виклики - тільки по «холодних» шляхах (каталоги/телеметрія), «гарячі» (гаманець) - локально.
Worker-пули за профілями: 'general','compute','io','spot'( для фонових завдань). Призначення через nodeSelector/affinity/taints.

2. 2 Простори імен і багатокористувацька модель

Namespace-ізоляція по доменах/командах: `payments`, `wallet`, `games`, `reporting`.
ResourceQuota + LimitRange: базові ліміти CPU/RAM і максимум реплік; захист кластера від «пилососів».
RBAC: ролі read-only за замовчуванням, write - тільки CI/CD і on-call.

2. 3 Мережа

CNI з підтримкою NetworkPolicy (Calico/Cilium): L3/L4 політики щодо namespace/label.
Ingress → Gateway API: перехід на модель'GatewayClass/Gateway/HTTPRoute'для канарок і багато-тенантності.
Service Mesh (опціонально): mTLS, retry/breaker, locality-aware; включати точково для міжсервісної надійності.

3) Надійність і масштабування

3. 1 Скейлінг

HPA за призначеними для користувача метриками (RPS/latency/queue depth), а не тільки CPU.
VPA на фоновому класі навантажень; в проді - «recommendation only» або спільно з HPA за різними метриками.
Cluster Autoscaler: окремі node groups під чутливі сервіси; warm-pool до піків (турніри/матчі).

3. 2 Ресурси і QoS

Кожен Pod має requests/limits; уникати':latest'і «безлімітних» контейнерів.
PriorityClass: критичні сервіси («wallet», «payments») витісняють некритичні.
PDB: не даємо кластеру «вистрілити собі в ногу» при оновленні нод.

3. 3 Оновлення без простоїв

RollingUpdate c maxUnavailable = 0 на критичних шляхах.
PodDisruptionBudget + ReadinessProbes (не `startupProbe` вместо readiness).
Surge-ємність для швидких релізів під час піків - з обережністю.

4) Безпека платформи

Pod Security (Baseline/Restricted) на рівні namespace; заборона'privileged', hostPath, root.
NetworkPolicy: default-deny і білі списки по портах/label.
Seccomp/AppArmor, non-root users, read-only rootfs.
Secrets: KMS/Vault провайдер (CSI), не тримаємо секрети в'values. yaml'у відкритому вигляді.
RBAC-мінімум: сервісним акаунтам видаємо тільки необхідні права; токени короткоживучі.
Admission-контроль: OPA/Gatekeeper/Kyverno - enforce лейблів, лімітів, policy-порушень.

5) Observability

OpenTelemetry: трасинг від Ingress/Gateway → сервіс → БД/кеш, обов'язкові лейбли'service','version','region','partner','api _ version'.
Логи: структуровані, без PII/PAN; маршрутизація в централізоване сховище.
Метрики: RED/USE, SLO-дашборди, burn-rate алерти.
Синтетика: проби з потрібних країн/ASN; периметр і внутрішні health-checks.

6) GitOps и progressive delivery

Argo CD/Flux: бажаний стан зберігається в Git; кожен namespace - свій репозиторій/папка.
Промоція артефактів: 'dev → stage → prod'через PR, а не «kubectl apply».
Canary/Blue-Green: Argo Rollouts/Gateway API; метрики успіху - P95/P99, error-rate, бізнес-SLI (CR депозитів).
Відкати: в Helm/Argo - по кнопці; в чартах - версії фіксовані.

7) Helm: Кращі практики

7. 1 Структура чарту

my-service/
Chart. yaml     # name, version (SemVer), appVersion values. yaml # base values (no secrets)
values-prod. yaml # prod overrides (no secrets)
templates/
_helpers. tpl # naming, common deployment templates. yaml service. yaml hpa. yaml pdb. yaml networkpolicy. yaml serviceaccount. yaml ingress_or_gateway. yaml charts/# dependencies (opcional)

• 'version'- версія чарту (SemVer),'appVersion'- версія програми (іміджу).
• Суворі імена ресурсів: `{{ include "svc. fullname".}}'+ лейбли'app. kubernetes. io/`.
• Обов'язкові маніфести: Deployment/StatefulSet, Service, ServiceAccount, HPA (якщо застосовується), PDB, NetworkPolicy.

7. 2 Values-стратегія

Базовий'values. yaml'- дефолти, без секретів і оточення-специфіки.
Оверрайди: `values-{stage|prod}.yaml` + per-region файлы.
Секрети: SOPS (`values-prod. sops. yaml') або Vault-ін'єкція через CSI.
Параметри ресурсів і проб - в values з «розумними» дефолтами.

7. 3 Залежності та загальний код

Загальні чарти-бібліотеки для патернів (probes, annotations, NetworkPolicy).
Залежності ('requirements '/' Chart. yaml') фіксуйте за версією; уникайте глибоких «матрьошок».

7. 4 Шаблони та перевірки

Використовуйте'required'і'fail'в'_ helpers. tpl'для критичних значень.
Валідація схеми values -'values. schema. json`.
Юніт-тести чарту -'helm unittest'; статичний аналіз - kubeconform/kubeval.
Локальне налагодження -'helm template'+'--values'+'kubeconform'.

7. 5 Релізи та зберігання

Пуш чарту в OCI-регістри контейнерів; теги по SemVer.
Helmfile/`helmfile. d'для оркестрації багаточартових розкаток.
Артефакти CI: згенеровані маніфести + lockfile залежностей.

8) Приклад: Deployment (фрагмент Helm-шаблону)

yaml apiVersion: apps/v1 kind: Deployment metadata:
name: {{ include "svc. fullname". }}
labels: {{ include "svc. labels". nindent 4 }}
spec:
replicas: {{.Values. replicas      default 3 }}
strategy:
type: RollingUpdate rollingUpdate:
maxSurge: 1 maxUnavailable: 0 selector:
matchLabels: {{ include "svc. selectorLabels". nindent 6 }}
template:
metadata:
labels: {{ include "svc. selectorLabels". nindent 8 }}
annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}
spec:
serviceAccountName: {{ include "svc. serviceAccountName". }}
securityContext:
runAsNonRoot: true containers:
- name: app image: "{{.Values. image. repository }}:{{.Values. image. tag }}"
imagePullPolicy: IfNotPresent ports:
- name: http containerPort: {{.Values. ports. http }}
resources:
requests:
cpu: {{.Values. resources. requests. cpu }}
memory: {{.Values. resources. requests. memory }}
limits:
cpu: {{.Values. resources. limits. cpu }}
memory: {{.Values. resources. limits. memory }}
readinessProbe:
httpGet:
path: /healthz port: http periodSeconds: 5 envFrom:
- secretRef:
name: {{ include "svc. secretsName". }}

9) Секрети та конфігурації

Secrets через CSI (Vault/KMS) або SOPS в Git-репозиторії (GPG/KMS ключі; заборона'kubectl edit').
ConfigMap/Secret checksum анотації для тригера rolling-релізу.
Не зберігати PAN/PII; використовувати токенізацію.
Sealed Secrets допускається, але краще SOPS або прямий CSI.

10) Мережа і периметр

Gateway API для L7-роутингу, канарок і blue-green; sticky-сесії тільки коли необхідно.
mTLS між сервісами через mesh/sidecar-less (Cilium) - точково для платіжного ядра.
Egress: контрольований список зовнішніх вузлів (PSP/KYC), фіксовані NAT-IP, таймаути і бюджет ретраїв.

11) Stateful-сервіси та дані

Для OLTP-БД використовуйте керовані сервіси хмари або оператори (Postgres/MySQL) в окремих кластерах.
PVC/CSI з політикою снапшотів і бекапів;'PodAntiAffinity'для реплік.
Для черг/стрімінгу - керовані рішення або виділені кластери; в «загальному» додатковому кластері тримати мінімум стану.

12) CI/CD конвеєр (референс)

1. Build & test → 2) SCA/лінт → 3) Образ в регістрі (SBOM, підпис) →

2. Генерація Helm-чарту +'helm unittest'+ kubeconform →

3. SOPS-декрипт в рантаймі CD → 6) PR в GitOps-репозиторій →

4. Argo/Flux застосовує → 8) Argo Rollouts canary → 9) Авто-вердикт по SLO → 10) Промоція/відкат.

13) Метрики зрілості платформи

Частка релізів через GitOps (мета: 100%).
Час розкатки (P95) до готовності, MTTR відкату.
Покриття Namespace'ів Pod Security і NetworkPolicy (мета: 100%).
% сервісів з HPA і коректними requests/limits.
% чарту з'values. schema. json'і юніт-тестами.
Інциденти, викликані «ручними» змінами (мета: 0).

14) Чек-лист впровадження

1. Кластера по зонах, пул вузлів за профілями; PDB/TopologySpreadConstraints.
2. Namespace-модель, ResourceQuota/LimitRange, RBAC мінімум.
3. Pod Security (Restricted) и default-deny NetworkPolicy.
4. Gateway API/Ingress; egress-контроль і NAT-фіксація до провайдерів.
5. Observability: OTel трейси, RED/USE, синтетика по гео; SLO-дашборди.
6. GitOps (Argo/Flux), canary/blue-green, автопромоція за метриками.
7. Helm-стандарти: структура, schema. json, тести, SOPS/Vault, OCI-регістри.
8. HPA/VPA, Cluster Autoscaler, warm-pool до піків.
9. Операції з даними: CSI снапшоти, бекапи, оператори/managed БД.
10. Регулярні DR/chaos-тести і game-days.

15) Анти-патерни

Один «гігантський» кластер для всього без ізоляції і квот.
Контейнери без обмежень ресурсів,'latest'теги, відсутність probes.
Секрети в'values. yaml'у відкритому вигляді,'kubectl edit'у проді.
Релізи повз GitOps, ручні правки маніфестів на живому кластері.
Відсутність NetworkPolicy/Pod Security - «плоска» мережа.
Єдиний загальний HPA-сигнал по CPU для різнотипних навантажень.
Зберігання OLTP-БД всередині «загального» кластера програми без оператора і бекапів.

16) Контекст iGaming/фінтех: Практичні ноти

Платіжні вебхуки: виділений ingress/gateway і вузький egress до PSP; строгі таймаути/ретраї; окремий пул вузлів.
VIP-трафік: пріоритизація та окремі маршрути; PDB і topology spread для стабільності.
Турніри/піки: warm-pool вузлів + предиктивний HPA; прогрів кешів/з'єднань.
Звітність/CDC: окремий кластер/пул, щоб ETL не впливав на прод.
Регуляторика: незмінні логи (WORM), токенізація PII, сегментація мереж.

Підсумок

Сильна Kubernetes-платформа - це не «купа YAML», а стандарти: ізоляція, політика безпеки, керовані ресурси, спостережуваність і GitOps-дисципліна. Helm-чарти - ваш контракт поставки: передбачувані релізи, тестовані шаблони, безпечна робота з секретами і прості відкати. Закріпивши ці принципи, ви отримаєте кластери, які переживають піки, прискорюють релізи і витримують вимоги бізнесу і регуляторів.