Главная СтатьиЧеклист аудита Kubernetes

Kubernetes

Чеклист аудита Kubernetes-кластера перед production

Аудит Kubernetes нужен не для красивого отчёта. Он показывает, где кластер может сорвать релиз, потерять данные или долго восстанавливаться после сбоя. Ниже — практичный список проверок для production-контура.

Обновлено 01 июня 2026 г.8 минут

Когда стоит проверять Kubernetes

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

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

production-релизы регулярно откладываются из-за инфраструктурных рисков;

непонятно, какие сервисы критичны и от каких компонентов они зависят;

backup есть, но restore давно не проверяли;

кластер, ingress controller или storage driver давно не обновлялись;

алерты приходят, но по ним трудно понять причину и следующий шаг.

1. Доступы и RBAC

Сначала проверяем, кто может менять кластер и от чьего имени работают automation-задачи. В production опасны лишние права людей и service account с доступом шире своей задачи.

у кого есть cluster-admin и почему этот доступ нужен постоянно;

разделены ли права разработчиков, DevOps/SRE и CI/CD;

какие service account используются pipeline и операторами;

где лежат kubeconfig, токены и секреты для доступа к кластеру;

кто выдаёт временные доступы и как они отзываются.

2. Ресурсы и устойчивость workload

Если у приложений нет requests, limits и probes, кластер работает на удаче. Scheduler не видит реальную потребность, kubelet поздно понимает, что pod нездоров, а один сервис может забрать ресурсы у соседей.

заданы ли CPU/memory requests и limits для основных workload;

есть ли namespace quotas и limit ranges;

настроены ли readiness, liveness и startup probes;

есть ли PodDisruptionBudget для сервисов, которые нельзя потерять при обновлении node;

разнесены ли важные replicas по node через affinity/anti-affinity или topology spread constraints.

3. Ingress, TLS и сетевые правила

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

какие ingress/routes доступны извне и кто владелец каждого endpoint;

как выпускаются и продлеваются TLS-сертификаты;

настроены ли timeouts, body limits и базовые ограничения на ingress/controller;

есть ли NetworkPolicy там, где namespace не должен видеть всю внутреннюю сеть;

разделены ли публичные и внутренние endpoints.

4. Storage, backup и restore

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

какие storage class используются и кто отвечает за их настройки;

у каких stateful-сервисов есть регулярный backup;

когда последний раз проверяли restore и чем он закончился;

описан ли порядок восстановления после ошибки релиза, удаления данных или сбоя storage;

попадают ли в backup конфигурация, secrets и критичные Kubernetes-объекты.

5. Мониторинг, алерты и runbook

Мониторинг должен помогать дежурному инженеру принять решение. Если алерт не говорит, какой сервис страдает, где смотреть и кого подключать, он быстро становится фоном.

есть ли метрики по nodes, pods, ingress, storage и бизнес-критичным приложениям;

настроены ли алерты на availability, latency, error rate и saturation;

есть ли отдельные dashboards для дежурства, разработки и инфраструктурной команды;

есть ли runbook для частых инцидентов;

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

6. CI/CD, релизы и rollback

Kubernetes не делает релизы безопасными автоматически. Нужны проверки до deploy, контроль rollout и понятный rollback. Иначе команда узнаёт о проблеме уже после того, как пользователи попали на сломанную версию.

какие stages проходят изменения от build до production;

кто подтверждает production deploy и где это фиксируется;

есть ли smoke-checks после rollout;

понятно ли, как откатить релиз и какие данные нельзя откатить простым rollback;

разделены ли secrets, variables и доступы для разных окружений.

Что должно быть на выходе

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

карта рисков с влиянием на релизы, доступность, данные и восстановление;

быстрые исправления на 7–14 дней;

план 30/60/90 по изменениям в кластере и процессах;

список работ, которые требуют release window или отдельного согласования;

рекомендации по доступам, мониторингу, backup, CI/CD и обновлениям.

FAQ

Сколько длится аудит Kubernetes-кластера?

Первичный аудит обычно занимает 7–10 дней. За это время можно собрать факты, проверить конфигурацию, поговорить с командой и подготовить карту рисков.

Можно ли начать без доступа на изменение?

Да. Нормальный старт — read-only доступ, схемы инфраструктуры, описание релизного процесса, monitoring, incidents и backup-процедуры. Изменения в production согласуются отдельно.

Что проверить в Kubernetes перед production в первую очередь?

Права доступа, requests/limits, probes, ingress/TLS, storage, backup/restore, мониторинг, CI/CD и rollback. Эти зоны чаще всего влияют на релизы, доступность и восстановление.

Чем аудит отличается от поддержки Kubernetes?

Аудит фиксирует текущее состояние и план исправлений. Поддержка — это регулярная работа с кластером: обновления, инциденты, capacity, monitoring, релизы и инфраструктурный backlog.