Kubernetes best practices, которые я хотел бы знать заранее

Перевод и адаптация статьи «Kubernetes Best Practices I Wish I Had Known Before» Engin Diri (Pulumi). Авторские права на оригинал принадлежат автору; здесь — пересказ для русскоязычных читателей.

Best practices в Kubernetes — это проверенные на проде паттерны для управления ресурсами, изоляции, RBAC, сети, наблюдаемости и инфраструктуры-как-кода. Успех в Kubernetes — это не «выбрать правильный CNI», а дисциплина в этих паттернах.

TL;DR — 20 практик на 2026

1. Задавайте requests и limits для каждого контейнера.
2. Используйте namespace + ResourceQuota + LimitRange для изоляции.
3. Один контейнер в Pod — пока действительно не нужен sidecar.
4. Манифесты — через Helm, Kustomize или Pulumi. Никогда — голый copy-paste YAML.
5. Gateway API для north-south трафика (ingress-nginx уходит на покой).
6. liveness + readiness + startup пробы для каждого workload’а.
7. RBAC по принципу least-privilege с первого дня.
8. Pod Security Admission в режиме restricted по умолчанию.
9. Сжимайте east-west трафик через NetworkPolicy (default-deny).
10. Секреты — во внешних менеджерах, а не в plain Kubernetes Secret.
11. Автоскейлинг: HPA + VPA + Cluster Autoscaler / Karpenter.
12. Мониторинг: Prometheus, Grafana, OpenTelemetry.
13. Деплой — через GitOps (Argo CD или Flux). Git — единственный source of truth.
14. Каждое изменение проходит через policy-as-code.
15. SBOM на каждый образ; подпись через Sigstore/cosign.
16. FinOps — управляйте расходами осознанно.
17. Регулярно обновляйте кластеры и аддоны по документированному графику.
18. Единые labels и annotations.
19. Разделяйте dev / staging / prod кластеры (или используйте vCluster).
20. Кластеры — cattle, а не pets. Пересоздаваемы из кода. Никаких ручных правок «вживую».

Anti-pattern → правильный подход

Подробно

1. Resource requests и limits

requests — минимум CPU/RAM, который scheduler гарантирует поду. limits — максимум. На каждом prod-контейнере должны быть:

• CPU и memory requests;
• memory limit (CPU limit — спорно, часто лучше без него);
• стартовые значения: 100–200m CPU, 128–512Mi RAM;
• тюнинг через VPA в режиме рекомендаций;
• LimitRange в namespace для дефолтов.

2. Структура namespaces

Namespace = логическая граница. Маппится на владельца: команда или окружение. К каждому namespace:

• ResourceQuota — кэп по CPU/RAM/количеству объектов;
• LimitRange — дефолтные requests/limits для контейнеров;
• RoleBinding с минимальными правами.

3. Дизайн Pod

Один контейнер на Pod — это дефолт. Второй добавляйте, только если действительно нужно общее сетевое пространство или volume (service-mesh sidecar, log shipper, init-контейнер). Multi-container поды связывают lifecycle и масштабирование — это редко удобно.

4. Управление манифестами

Никогда не копипастите YAML вручную. Один из:

• Helm — Go-шаблоны, де-факто стандарт для off-the-shelf софта;
• Kustomize — overlays, встроен в kubectl;
• Pulumi — настоящие языки (TypeScript, Python, Go, Java, .NET) с типами и тестами.

5. Ingress и сеть в 2026

Gateway API заменяет legacy Ingress. План действий:

• Уходить с ingress-nginx (retired в марте 2026) на Envoy Gateway, Istio, Linkerd Gateway или Kgateway.
• TLS — на gateway, через cert-manager.
• Маршрутизация по path и host.
• WAF поверх gateway (managed cloud WAF или Coraza на Envoy).

6. Health probes

Три типа проб:

• liveness — рестартит зависшие контейнеры. Используйте сдержанно.
• readiness — пропускает трафик из Service / Gateway. Обязательна для каждого network-facing workload’а.
• startup — даёт время медленно поднимающимся приложениям, прежде чем включится liveness.

См. также серию по пробам в CloudNativePG: Рецепт 19, Рецепт 20, Рецепт 21.

7. RBAC

RBAC связывает subject (user, group, ServiceAccount) с verb + resource. Правила:

• Least privilege — никаких bind’ов на cluster-admin.
• Per-namespace Role + RoleBinding вместо ClusterRole.
• Аудит через kubectl auth can-i --as=... и инструменты вроде rbac-lookup.

8. Pod Security Admission

Pod Security Admission применяет три уровня Pod Security Standards. Базовый сетап:

• На каждом namespace label pod-security.kubernetes.io/enforce=restricted.
• Дропайте NET_RAW и все capabilities.
• Запуск non-root, read-only root filesystem.
• seccompProfile: RuntimeDefault.

9. Network Policies

NetworkPolicy фильтрует ingress/egress на уровне IP/port:

• В каждом namespace — default-deny policy.
• Открывайте только нужные потоки (DNS, БД, upstream API).
• Сверху — service mesh для L7-контроля.

10. Управление секретами

Встроенные Secret в Kubernetes — это base64, а не шифрование.

• Источник истины — внешний менеджер: Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Pulumi ESC.
• Прокидывание через External Secrets Operator или Secret Store CSI Driver.
• Включите encryption-at-rest для etcd через KMS.
• Автоматическая ротация. Никогда не коммитьте секреты в Git.

11. Observability

Дефолтный стек на 2026 — OpenTelemetry-first:

• Метрики — Prometheus + Grafana.
• Логи — Fluent Bit или OTel Collector → Loki, Elastic/OpenSearch или managed.
• Трейсы — OTel SDK в приложениях, корреляция с логами.
• Алерты — на SLO burn rate, а не на каждый упавший Pod.

12. GitOps-деплой

Git — единственный source of truth.

• В каждом кластере — reconciliation-контроллер: Argo CD, Flux или Pulumi Kubernetes Operator.
• Люди не делают kubectl apply в прод.
• App-of-apps / Kustomization-деревья для bootstrap’а целых кластеров.
• Manifests — в Git, продвижение между окружениями через PR.
• Автоматический rollback по health-check’ам.

13. Апгрейды Kubernetes

Минорный релиз раз в ~4 месяца, поддержка ~14 месяцев.

• Не отставайте больше чем на две минорные версии.
• Сначала тест в non-prod, conformance-тесты.
• Бэкап etcd перед каждым изменением control-plane.
• Аддоны обновляйте в том же ритме; пинните версии в коде.
• Используйте pluto или kubent для поиска deprecated API.

14. Labels и annotations

Метаданные — основа для Service, NetworkPolicy, мониторинга и cost-инструментов.

• Стандартные labels: app.kubernetes.io/name, instance, version, component, part-of, managed-by.
• Организационные labels: owner, cost-center, environment, slo-tier.
• Annotations — для не-identifying данных: build SHA, change-ticket, deployment timestamp.

15. Разделение окружений

Прод — отдельный кластер.

• Отдельный кластер на окружение — безопасный дефолт.
• vCluster — изоляция без полной операционной нагрузки на отдельный кластер.
• Только namespace-сегрегация работает для dev/staging — но требует жёстких NetworkPolicy + RBAC + ResourceQuota.
• Провижените всё одной программой Pulumi с разными stack’ами.

16. Container images

• Базовый образ — distroless (gcr.io/distroless) или chainguard/static.
• Multi-stage Dockerfile.
• Пин по digest (@sha256:...), а не по тегу.
• Сканирование через Trivy / Grype / scanner’ы реестра. Блокируйте на Critical/High CVE.
• Маленький образ = быстрый pull, быстрый scale-up, меньше attack surface.

17. Стратегия логов

• Централизация в Loki / Elastic / OpenSearch / managed.
• Структурированные JSON-логи с консистентными именами полей.
• Retention по уровням: hot 7 дней, warm 30–90 дней, архив для compliance.
• Редактирование секретов и PII на стороне коллектора.

18. Autoscaling

Три компонента работают вместе:

• HPA — масштабирует число replica по CPU/RAM/custom-метрикам.
• VPA — корректирует requests подов со временем.
• Cluster Autoscaler / Karpenter — добавляет/убирает ноды.

Каждый prod workload должен иметь HPA. У кластера — node-level autoscaling с разумным min/max и PodDisruptionBudget.

19. Policy-as-code

Policy-as-code = governance в коде, блокирует non-compliant изменения.

• До деплоя — валидация выхода через Pulumi CrossGuard или Conftest в CI.
• На admission — OPA Gatekeeper или Kyverno: подписанные образы, обязательные labels, non-root securityContext.
• Постоянно — сканирование живых кластеров на drift через Pulumi Insights или kubescape.

20. Supply chain security

SBOM (Software Bill of Materials) — машинно-читаемая инвентаризация компонентов образа.

• Генерация SBOM на этапе build через Syft или docker sbom.
• Подпись образов и SBOM через Sigstore/cosign (keyless через GitHub OIDC).
• Верификация подписей на admission через Kyverno или Connaisseur.
• SLSA provenance attestations.
• Пин base-образа по digest + регулярная пересборка.

21. FinOps в Kubernetes

Управление расходами — это про labeling и right-sizing:

• Right-size через рекомендации VPA или Goldilocks .
• Расписание — non-prod кластеры на ночь и выходные в ноль.
• Spot / preemptible ноды для отказоустойчивых workload’ов; consolidation через Karpenter.
• Show back / charge back по namespace через OpenCost / Kubecost.
• Кластеры — через IaC: типы нод и autoscaling видно в коде.

22. Cattle, not pets

Ручные правки на живом кластере либо «съедаются» reconciliation’ом, либо приводят к drift’у.

• Фиксы — в коде (YAML / Helm / Pulumi).
• Если кластер нельзя пересобрать из Git за час — это pet, а не cattle.
• Ephemeral preview-окружения для PR.
• Прод-релизы через blue/green или progressive delivery (Argo Rollouts, Flagger).

23. Pulumi для Kubernetes (от автора)

Это секция-реклама от Pulumi из оригинальной статьи — оставлена для полноты.

Native YAML масштабируется до пары сервисов; дальше начинаются boilerplate и копипаст. Pulumi предлагает:

• Настоящие языки (TS/Python/Go/Java/.NET) — типы и тесты.
• Один stack — вся топология (облако + workload).
• Переиспользуемые компоненты через пакеты.
• GitOps reconciliation через Pulumi Kubernetes Operator.
• Policy-as-code через CrossGuard «из коробки».
• Секреты через Pulumi ESC с federation.

Итог

«Kubernetes вознаграждает дисциплину. 20+ практик выше — это и есть тот набор настроек, который отличает кластеры, поднимающие пейджер каждую неделю, от тех, которые не поднимают.»

Совет автора: возьмите три самых слабых места в вашей среде и закройте их в первую очередь. И помните — фиксы должны идти через код, а не через kubectl.