Лучшие практики по Kubernetes. Жаль, я не знала о них раньше

Недавно попался очень внятный материал от Pulumi про ключевые Kubernetes‑практики, которые начинаешь ценить, к сожалению, только после первых инцидентов и неприятных сюрпризов. Решила перевести для себя и коллег, а заодно положить на Хабр, добавив к переводу своих мыслей. А оригинальные примеры, которые были завязаны на зарубежные managed-сервисы или внутренние продукты Pulumi, я немножко адаптировала под нашу специфику.

В материале — ключевые практики для 2026 года. Они помогают держать кластеры надежными, безопасными и экономичными: задавать requests и limits для каждого контейнера, изолировать нагрузки через namespaces и NetworkPolicy, автоматизировать health checks и еще много всего. Приглашаю под кат.

20 лучших практик Kubernetes на 2026 год

На случай, если лень читать целиком, положила короткую версию.

1. Задавайте requests и limits для каждого контейнера.

2. Используйте namespaces вместе с ResourceQuota и LimitRange для изоляции ресурсов и контроля потребления.

3. По умолчанию размещайте один контейнер в одном поде. Дополнительные контейнеры добавляйте только тогда, когда они действительно нужны.

4. Управляйте манифестами через Helm, Kustomize или Pulumi, а не через копирование YAML между проектами.

5. Используйте Gateway API для входящего трафика и планируйте отказ от устаревших подходов.

6. Настраивайте liveness, readiness и startup probes для всех приложений, принимающих трафик.

7. С первого дня внедряйте RBAC по принципу минимально необходимых привилегий.

8. Используйте Pod Security Admission с профилем restricted по умолчанию.

9. Ограничивайте внутренний трафик через NetworkPolicy и подход default deny.

10. Храните секреты во внешнем хранилище, а не в обычных Kubernetes Secrets.

11. Используйте HPA, VPA и Cluster Autoscaler или Karpenter для автоматического масштабирования.

12. Следите за состоянием системы через Prometheus, Grafana и OpenTelemetry. Хороший алерт должен сработать раньше, чем проблему заметят пользователи.

13. Используйте GitOps-подход с Argo CD или Flux. Git должен оставаться единственным источником истины.

14. Проверяйте изменения через policy-as-code, например с помощью OPA Gatekeeper или Kyverno.

15. Генерируйте и проверяйте SBOM для каждого образа, а также подписывайте артефакты через Sigstore или cosign.

16. Управляйте затратами с помощью практик FinOps — оптимизируйте выделенные ресурсы, используйте расписания и распределяйте расходы по командам и проектам.

17. Регулярно обновляйте Kubernetes и сопутствующие компоненты по заранее определенному циклу.

18. Используйте labels и annotations последовательно — для управления доступом, учета затрат, мониторинга и отслеживания SLO.

19. Разделяйте dev, staging и prod либо на уровне отдельных кластеров, либо с помощью виртуальных кластеров на базе vCluster.

20. Относитесь к кластерам как к воспроизводимой инфраструктуре — пересоздавайте их из кода и избегайте ручных изменений в работающих окружениях.

Последнее обновление в оригинале статьи — 30 апреля 2026 года. Добавлены разделы про GitOps, policy-as-code, SBOM и цепочку поставок ПО, автоскалирование, NetworkPolicy и FinOps. А также автор добавил таблицу с антипаттернами и пересобрал структуру заголовков вокруг вопросов, которые команды реально задают в работе.

Зачем нужны лучшие практики

Лучшие практики Kubernetes, про которые пойдет речь в статье, помогают держать нагрузки доступными, безопасными, наблюдаемыми и экономически эффективными в Kubernetes-кластере.

Они покрывают четыре области: 

1. Конфигурацию нагрузок — ресурсы, probes, образы. 

2. Безопасность — RBAC, NetworkPolicy, Pod Security, секреты, цепочка поставок ПО. 

3. Поставку изменений — GitOps, policy-as-code, IaC.

4. Эксплуатацию платформы — автоскалирование, мониторинг, обновления, FinOps. 

Дальше разберу каждый пункт через такую структуру: простое правило, краткое определение базового Kubernetes-объекта и типичный антипаттерн, которого стоит избегать.

Типичные антипаттерны в Kubernetes и правильный подход

1. Как задавать resource requests и limits в Kubernetes?

Что такое resource requests и limits?

Request — это объем CPU и памяти, который Kubernetes резервирует для контейнера при планировании.

Limit — максимальный объем ресурсов, который контейнер может использовать. При превышении лимита по CPU начинается троттлинг, а при нехватке памяти контейнер может быть завершен с ошибкой OOMKilled.

Правило. В prod-среде для каждого контейнера должны быть заданы requests по CPU и памяти, а также лимит по памяти. Лимиты по CPU стоит использовать осознанно: в некоторых сценариях они приводят к троттлингу и росту задержек, которые со стороны выглядят как деградация сервиса.

Поэтому несколько советов:

• Для типичного веб-сервиса начните со 100–200 mCPU и 128–512Mi памяти.

• Корректируйте значения на основе реального потребления ресурсов. Для этого можно использовать Vertical Pod Autoscaler в режиме рекомендаций (updateMode: Off) или данные из Prometheus.

• Используйте LimitRange на уровне namespace, чтобы команда физически не могла развернуть контейнер вообще без requests.

2. Как правильно структурировать namespaces в Kubernetes?

Что такое namespace в Kubernetes?

Namespace — это логическая область внутри кластера, которая помогает разделять ресурсы, права доступа и политики между командами, приложениями или окружениями. Она определяет область видимости имен объектов, правил доступа и сетевых политик, но сама по себе не обеспечивает полной изоляции.

Правило. Не размещайте рабочие нагрузки в namespace default. Структуру namespace лучше строить вокруг зон ответственности, например выделять отдельный namespace для команды, окружения или клиента.

Также для каждого namespace сразу задавайте три вещи:

• ResourceQuota, чтобы ограничить суммарные потребления CPU, память и количество создаваемых объектов.

• LimitRange, чтобы задать дефолты и лимиты на уровне контейнеров.

• RoleBinding, дает только те права, которые реально нужны этой команде.

Эта минимальная единица помогает контролировать потребление ресурсов, ограничивать последствия ошибок и выстраивать понятную модель разграничения доступа.

3. Стоит ли запускать несколько контейнеров в одном поде?

Что такое под?

Pod (под) — это минимальная единица запуска в Kubernetes. Он может содержать один или несколько контейнеров, которые используют общую сеть, тома хранения данных и другие ресурсы окружения, а также запускаются и масштабируются как единое целое.

Правило. По умолчанию должен быть один контейнер на под. Добавлять дополнительные контейнеры стоит только тогда, когда им действительно необходимо работать в тесной связке с основным приложением и использовать общие ресурсы.

Например, это может быть sidecar-контейнер service mesh, агент сбора логов или init-контейнер, который подготавливает окружение перед запуском приложения.

Важно помнить, что все контейнеры внутри одного пода разделяют жизненный цикл и масштабируются вместе. Поэтому многоконтейнерные поды стоит использовать осознанно, а не по умолчанию.

4. Стоит ли использовать Helm, Kustomize или Pulumi для Kubernetes-манифестов?

Правило. Не копируйте одни и те же YAML-манифесты между сервисами и окружениями.  Лучше придерживайтесь одного из следующих подходов:

• Helm — пакеты конфигурации на основе Go templates. Это де-факто стандарт для установки и сопровождения популярных решений вроде Prometheus, cert-manager или Argo CD.

• Kustomize — подход на основе наложения конфигураций без использования шаблонов. Идет вместе с kubectl и хорошо работает там, где приложение остается одним и тем же, а различаются только окружения.

• Pulumi — использование языков программирования TypeScript, Python, Go, Java и .NET для управления Kubernetes и связанной с ним облачной инфраструктурой.

Если облачная инфраструктура уже управляется как код, то расширить тот же подход на Kubernetes — логичный шаг. В этом случае кластер, его IAM, DNS и рабочие нагрузки (workloads) живут в одном стеке и проходят через единый ревью-процесс.

5. Как в 2026 году работать с ingress и сетью в Kubernetes?

Что такое Gateway API?

Gateway API — это наследник устаревшего ресурса Ingress. Он разделяет ответственность между инфраструктурной частью (GatewayClass, Gateway) и прикладной частью (HTTPRoute, GRPCRoute, TLSRoute) и считается основным направлением развития входящего трафика в Kubernetes.

Правило. Новые кластеры стоит сразу строить на Gateway API. Широко используемый контроллер ingress-nginx был выведен из эксплуатации в марте 2026 года. Поэтому для оставшихся инсталляций нужно планировать миграцию на Envoy Gateway, Istio, Linkerd Gateway, Kgateway или другой актуальный вариант.

Несколько дополнительных советов:

• Завершайте TLS на уровне gateway и автоматизируйте сертификаты через cert-manager.

• Используйте маршрутизацию по доменам и URL-путям, а не отдельный gateway на каждый сервис.

• Защищайте каждый gateway через WAF — облачный сервис или Coraza на Envoy.

6. В чем разница между liveness, readiness и startup probes?

Probes помогают kubelet понять, нужно ли перезапустить контейнер, готов ли он принимать трафик, или ему еще требуется время на запуск. Настраивать их нужно с учетом особенностей конкретного приложения.

• Liveness probe — перезапускает зависший контейнер. Поэтому используйте осторожно, так как неудачная liveness probe легко превращается в DoS на самих себя.

• Readiness probe — управляет подачей трафика через Services и Gateway routes. Нужна для каждой сетевой нагрузки.

• Startup probe — дает медленно стартующим приложениям, например JVM-сервисам или ML-моделям, время подняться до запуска liveness-проверки. Особенно полезна, если старт занимает больше 10 секунд.

Параметры failureThreshold, periodSeconds и timeoutSeconds нужно подбирать по реальной латентности, а не оставлять по умолчанию.

7. Как защищать Kubernetes-кластер?

Безопасность Kubernetes строится из нескольких уровней: управления доступом, защиты рабочих нагрузок, сетевой изоляции и работы с секретами. Все четыре слоя нужно настроить правильно.

Что такое RBAC в Kubernetes?

RBAC (Role-Based Access Control) — это модель авторизации Kubernetes, которая сопоставляет субъектов (пользователи, группы и ServiceAccounts) с действиями (get, list, create, delete) над ресурсами в рамках namespace (Role) или всего кластера (ClusterRole).

Правила:

• Выдавайте только минимально необходимые права и никогда не привязывайте людей или рабочие нагрузки к cluster-admin без крайней необходимости.

• По возможности используйте Role и RoleBinding в пределах namespace, а не ClusterRoleBinding.

• Аудируйте доступ через kubectl auth can-i —as=… и инструменты вроде rbac-lookup.

Что такое Pod Security Admission?

Pod Security Admission — это встроенный admission controller. Он применяет три Pod-Security-стандарта — privileged, baseline и restricted — на уровне namespace.

Правила:

• По умолчанию помечайте каждый namespace как pod-security.kubernetes.io/enforce=restricted.

• Отключайте NET_RAW и ненужные capabilities, запускайте контейнеры не от root и используйте файловую систему только для чтения там, где это возможно.

• Используйте seccompProfile: RuntimeDefault и строгий securityContext для каждого контейнера.

Что такое NetworkPolicy?

NetworkPolicy — это объект Kubernetes, который определяет разрешенный ingress и egress трафик для выбранных подов на уровне IP и портов. Без NetworkPolicy поды по умолчанию могут свободно обмениваться трафиком друг с другом.

Правила:

• Применяйте default-deny ingress и egress policy в каждом namespace.

• Разрешайте только тот трафик, который действительно нужен сервису: DNS, база данных, внешний API.

• Если нужен более богатый L7-контроль, например mTLS или JWT auth, добавляйте сверху service mesh.

Отдельно стоит учитывать, что service mesh дает не только дополнительные L7‑возможности, но и шифрование трафика между сервисами через mTLS. Это добавляет еще один уровень защиты поверх сетевых политик. Особенно важно там, где есть Zero Trust и требования к защите внутренних коммуникаций между сервисами. Вот хорошая статья про service mesh.

Как управлять секретами в Kubernetes?

Встроенные Secret-объекты Kubernetes кодируются через base64, а не шифруются. Рассматривайте их как механизм доставки секретов, а не как полноценное хранилище.

• Храните секреты в специализированном внешнем хранилище: Vault, AWS Secrets Manager или аналогичном решении.

• Передавайте секреты в под через External Secrets Operator или Secret Store CSI Driver.

• Включайте etcd encryption-at-rest через KMS provider, чтобы утекшие snapshots etcd оставались бесполезными для злоумышленника.

• Автоматизируйте ротацию секретов и не храните их в Git-репозиториях, даже в зашифрованном виде.

8. Как настроить observability в Kubernetes?

Observability держится на трех столпах: метриках, логах и трассировках. В 2026 году базовый стек по умолчанию строится вокруг подхода OpenTelemetry-first.

Советы по инструментам:

• Метрики — используйте Prometheus или совместимую с ним TSDB, например Mimir, Thanos или VictoriaMetrics, плюс dashboards в Grafana.

• Логи — Fluent Bit или OpenTelemetry Collector, которые отправляют структурированные JSON-логи в Loki, Elastic/OpenSearch или managed-сервис. Полагаться на kubectl logs во время инцидентов нельзя: поды временны.

• Трассировка — OpenTelemetry SDK в приложениях, отправляющие данные в Tempo, Jaeger или vendor backend. Trace ID нужно коррелировать с логами.

• Алерты — «алертить» лучше по SLO burn rate, а не по каждому упавшему поду, чтобы реагировать на происшествия, оказывающие реальное влияние на пользователей, а не на любой рестарт.

9. Как автоматизировать деплой Kubernetes через GitOps?

Что такое GitOps?

GitOps — это подход к управлению инфраструктурой и развертываниями, при котором целевое состояние кластера хранится в Git-репозитории, а специальный контроллер постоянно сверяет фактическое состояние с описанным в коде и при необходимости приводит их в соответствие. Все изменения проходят через pull request, а не вносятся руками через kubectl apply.

Правило. У каждого кластера должен быть контроллер: Argo CD, Flux. Люди не должны выполнять kubectl apply в проде вручную.

Несколько советов:

• Используйте подход app-of-apps в Argo CD или дерево Kustomization во Flux, чтобы развернуть весь кластер из единой точки управления.

• Храните манифесты, значения Helm и ссылки на инфраструктурные стеки в Git, а продвижение изменений между окружениями выполняйте через pull request.

• Комбинируйте GitOps с Pulumi Deployments, чтобы облачная инфраструктура и приложения проходили через единый процесс согласования и проверки изменений.

• Настройте автоматический откат при сбоях проверок работоспособности и уведомления о расхождениях между фактическим и целевым состоянием кластера, если кто-то все же внес изменения вручную.

10. Как часто нужно обновлять Kubernetes?

Kubernetes выпускает минорные версии примерно раз в четыре месяца и поддерживает каждую ветку около 14 месяцев. Поэтому обновления стоит воспринимать как регулярное обслуживание платформы, а не как отдельный большой проект.

Поэтому:

• Старайтесь не отставать от актуальной версии Kubernetes больше чем на два минорных релиза, иначе возрастает риск пропустить важные исправления безопасности и поддержки.

• Сначала проверяйте обновления в тестовом кластере, прогоняйте необходимые проверки и только потом раскатывайте изменения на остальные окружения.

• Перед обновлением control plane создавайте резервную копию etcd. В управляемых Kubernetes-сервисах часть этой работы обычно берет на себя облачный провайдер.

• Обновляйте сопутствующие компоненты (CNI, CSI, gateway controller, cert-manager и metrics-server) примерно в том же ритме и фиксируйте используемые версии в коде.

• Регулярно проверяйте Kubernetes Deprecation Guide и используйте Pluto или Kubent, чтобы заранее выявлять устаревшие API и избежать проблем при обновлении.

11. Как правильно использовать labels и annotations в Kubernetes?

Labels (метки) и annotations — это метаданные, которые используют сервисы Kubernetes, сетевые политики, системы мониторинга, инструменты учета затрат и GitOps-процессы.

Поэтому здесь важнее придерживаться единых правил именования и разметки, чем придумывать собственные схемы.

Советы:

• Используйте рекомендованные метки: app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/version, app.kubernetes.io/component, app.kubernetes.io/part-of, app.kubernetes.io/managed-by.

• Добавьте служебные метки для владельца сервиса, центра затрат, окружения и уровня критичности (SLO tier), потому что они понадобятся и для FinOps-, и для on-call-процессов.

• Annotations используйте для служебных метаданных, которые не участвуют в идентификации ресурсов: SHA коммита, номер заявки на изменение, время последнего деплоя, параметры для ingress-controller.

12. Как разделять окружения в Kubernetes?

Правило. Продакшен должен быть в отдельном кластере. Dev и staging иногда могут делить среду между собой. Но смешивать прод с чем-то еще — значит связывать blast radius, ритм обновлений и квоты.

Правила:

• Отдельный кластер на окружение — дефолтный и безопасный вариант.

• Virtual clusters через vCluster дают каждой команде свой Kubernetes API без полной операционной цены отдельного реального кластера.

• Разделение только через namespaces допустимо для dev/staging, если жестко настроены NetworkPolicy, RBAC и ResourceQuota.

• Все эти окружения стоит поднимать из одной и той же IaC-программы с разными stack-конфигурациями — dev, staging, prod.

13. Как оптимизировать контейнерные образы для Kubernetes?

• Используйте distroless-образы или другие минималистичные базовые образы.

• Собирайте образы через multi-stage Dockerfiles, чтобы инструменты сборки не попадали в итоговый образ.

• Фиксируйте базовый образ по digest (@sha256:…), а не по тегу: теги latest и даже версии вроде 1.21 со временем могут указывать на другой образ.

• Проверяйте образы с помощью Trivy, Grype или встроенных сканеров реестра контейнеров и блокируйте сборку при обнаружении критических и высокоуровневых уязвимостей.

• Чем меньше размер образа, тем быстрее он загружается на узлы кластера, тем быстрее масштабируются приложения и тем меньше потенциальная поверхность атаки.

14. Какая стратегия логирования в Kubernetes считается надежной?

Даю несколько обязательных, на мой взгляд, пунктов:

• Собирайте логи централизованно в Loki, Elastic/OpenSearch или управляемый сервис логирования с помощью Fluent Bit либо OpenTelemetry Collector, развернутого как DaemonSet.

• Используйте структурированные логи в формате JSON с единым набором полей, например trace_id, span_id, service и level.

• Разделяйте хранение логов по срокам и стоимости доступа: оперативное хранилище на 7 дней, основное хранилище на 30–90 дней и архив в объектном хранилище для выполнения требований по хранению данных и аудиту.

• Удаляйте или маскируйте секреты и персональные данные на этапе сбора логов, а не после их записи в систему хранения.

15. Как правильно настраивать автоскалирование в Kubernetes?

Что такое Horizontal Pod Autoscaler?

HPA автоматически увеличивает или уменьшает количество реплик Deployment или StatefulSet на основе загрузки CPU, памяти или пользовательских метрик.

Что такое Vertical Pod Autoscaler?

VPA анализирует фактическое потребление ресурсов и со временем корректирует значения CPU и памяти, запрашиваемые подом. В рабочей среде его часто используют в режиме рекомендаций (updateMode: Off), а изменения вносят через инфраструктурный код.

Что такое Cluster Autoscaler и Karpenter?

Cluster Autoscaler добавляет и убирает ноды под спрос со стороны пода. 

Karpenter — более быстрый инструмент автоматического масштабирования узлов без привязки к заранее созданным группам. Он широко используется в EKS и постепенно появляется в других облачных платформах.

Правило. У каждой production-нагрузки должен быть HPA, а для каждого кластера — автоматическое масштабирование узлов. Задавайте разумные минимальные и максимальные значения числа реплик, используйте PodDisruptionBudget и настраивайте параметры уменьшения масштаба так, чтобы снижение нагрузки не совпадало с массовым перезапуском пода.

Для событийного масштабирования (например, по длине очередей, отставанию потребителей Kafka или расписанию) используйте KEDA.

В управляемых Kubernetes‑средах KEDA часто работает как встроенный или поддерживаемый компонент. Например, у нас он доступен как плагин с готовыми сценариями использования и документацией.

16. Как применять policy-as-code в Kubernetes?

Что такое policy-as-code?

Policy-as-code — это подход, при котором требования к инфраструктуре описываются в виде кода и автоматически проверяются на этапе CI/CD, а также при применении изменений в кластере. Он помогает заранее контролировать требования безопасности, стандарты конфигурации, правила маркировки ресурсов и другие организационные ограничения.

Правило. Каждое изменение инфраструктуры должно проходить проверку хотя бы одним инструментом контроля политик.

До деплоя — проверяйте Pulumi или Helm output через Pulumi CrossGuard / Conftest в CI.

На этапе применения изменений (admission) — ставьте OPA Gatekeeper или Kyverno и требуйте подписанные контейнерные образы, наличие обязательных labels и запуск контейнеров без привилегий root.

Постоянно — сканируйте уже работающие кластеры на отклонения относительно политики через подходящие инструменты безопасности и комплаенса.

Для упрощения работы с политиками в управляемых платформах часто есть готовые решения. Например, Evolution Container Security помогает не только писать собственные политики Kyverno, но и выбирать из набора преднастроенных. А еще — получать отчеты по их применению и нарушениям.

Также упомяну, что в новых версиях Kubernetes механизм ValidatingAdmissionPolicy перешел в статус General Availability. Это нативный способ описания политик без установки сторонних контроллеров.

17. Как защищать безопасность цепочки поставки ПО в Kubernetes?

Что такое SBOM?

Software Bill of Materials — это машиночитаемый перечень компонентов, входящих в контейнерный образ: пакетов, их версий, лицензий и контрольных сумм. Обычно SBOM формируется в формате SPDX или CycloneDX.

Правило. У каждого образа, который запускается в продакшене, должен быть проверенный SBOM и подтвержденная цифровая подпись.

Несколько обязательных шагов:

• Генерируйте SBOM на этапе сборки через Syft или docker sbom.

• Подписывайте образы и SBOM через Sigstore/cosign.

• Проверяйте подписи на admission-этапе через Kyverno, Connaisseur или аналогичный механизм.

• Генерируйте provenance attestations (аттестация происхождения сборки) по требованиям SLSA, чтобы можно было доказать, какой пайплайн собрал конкретный образ.

• Фиксируйте базовые образы по digest и регулярно пересобирайте производные образы, чтобы исправления уязвимостей действительно попадали в поставку.

Это не экзотика, а практики, которые уже становятся стандартным требованием со стороны регуляторов, крупных корпоративных заказчиков и служб информационной безопасности.

18. Как управлять стоимостью Kubernetes (FinOps)?

Правило. Расходы на Kubernetes чаще всего растут не из-за тарифов облака, а из-за неправильно выделенных ресурсов и отсутствия прозрачности. Поэтому начинать стоит не с поиска скидок, а с наведения порядка в кластере.

Советы:

1. Регулярно проверяйте, сколько ресурсов приложения потребляют на самом деле. В этом помогут VPA, Goldilocks или рекомендации вашей системы мониторинга. На практике многие сервисы запрашивают заметно больше CPU и памяти, чем используют, поэтому корректировка запросов часто дает самый ощутимый эффект по экономии.

2. Выключайте non-prod-кластеры по ночам и в выходные, если возможно.

3. Для отказоустойчивых нагрузок используйте spot- или preemptible-инстансы. Они стоят дешевле и хорошо подходят для задач, которые могут пережить потерю отдельного узла.

4. Распределяйте затраты по командам и проектам через namespace и labels. Для этого можно использовать OpenCost, Kubecost или собственную аналитику поверх данных биллинга и метрик.

5. Описывайте кластер через IaC. Тогда типы узлов, параметры автоскейлинга и зарезервированные мощности будут храниться в коде, проходить ревью и не потеряются после очередного ручного изменения.

19. Почему кластеры Kubernetes нужно считать cattle, а не pets?

Старый принцип «Cattle, not pets» к Kubernetes применим даже строже, чем к виртуальным машинам. Любые ручные изменения в работающем кластере рано или поздно создают проблемы: их может перезаписать контроллер, они могут привести к расхождениям между окружениями или просто исчезнуть после пересоздания пода.

Поэтому:

• Чините проблемы в коде — в YAML, Helm chart или Pulumi program — и дайте контроллеру все заново развернуть.

• Если кластер нельзя заново поднять из Git меньше чем за час, значит, это уже pet, а не cattle.

• Для проверки изменений создавайте временные окружения под pull request, а для выкладки в продакшен используйте blue/green-развертывания или поэтапный rollout через Argo Rollouts, Flagger и аналогичные инструменты.

20. Почему стоит использовать Pulumi для управления Kubernetes?

Нативный YAML хорошо работает на старте, но по мере роста инфраструктуры его становится все сложнее поддерживать. Когда появляются десятки сервисов, несколько кластеров и связи между облачными ресурсами и объектами Kubernetes, подход infrastructure as code на полноценном языке программирования начинает заметно упрощать жизнь.

В чем преимущества инструмента:

• Поддержка популярных языков программирования. TypeScript, Python, Go, Java и .NET позволяют описывать инфраструктуру с использованием типизации, тестов и привычных инженерных практик.

• Единая точка управления инфраструктурой. В одном проекте можно описывать как облачные ресурсы, так и приложения, работающие внутри Kubernetes.

• Переиспользуемые компоненты. Типовые платформенные решения можно оформить в виде модулей и использовать в разных проектах без копирования конфигурации.

• Интеграция с GitOps-подходом. Pulumi Kubernetes Operator автоматически приводит кластер к состоянию, описанному в коде, после внесения изменений в репозиторий.

• Встроенная поддержка policy-as-code. CrossGuard позволяет проверять инфраструктурные изменения на соответствие принятым правилам еще до применения.

• Управление секретами и конфигурацией. Pulumi ESC помогает централизованно работать с секретами, настройками окружений и конфигурацией нескольких кластеров.

В оригинале это рекламный блок сервиса, это понятно — но вдруг вам будет полезно, решила оставить.

Финальные мысли

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

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