Технологии и Инфраструктура → 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-чарты — ваш контракт поставки: предсказуемые релизы, тестируемые шаблоны, безопасная работа с секретами и простые откаты. Закрепив эти принципы, вы получите кластера, которые переживают пики, ускоряют релизы и выдерживают требования бизнеса и регуляторов.