Kube-Score: анализ манифестов Kubernetes

Иконка Kube-Score на графическом фоне

Быстрые ссылки

Установка и запуск
Что проверяет Kube-Score
Опциональные правила
Управление версиями Kubernetes
Практическое руководство и чек-листы
Краткое резюме

Установка и запуск

Kube-Score доступен в нескольких форматах: готовые бинарники для Windows, macOS и Linux на GitHub, пакет через Brew на macOS и как плагин kubectl через krew.

Примеры установки:

brew install kube-score/tap/kube-score

Или как плагин kubectl:

kubectl krew install score

Запускайте Kube-Score из терминала командой kube-score. Укажите путь к YAML-манифесту Kubernetes. Поддерживаются шаблоны (wildcards) и директории — удобно сканировать сразу несколько файлов.

Kube-Score также принимает входящие данные через стандартный ввод, что позволяет анализировать манифесты из live-кластера или отрендеренные Helm-чарты.

Пример сканирования всего кластера (рекомендуемый паттерн):

kubectl api-resources --verbs=list --namespaced -o name | xargs -n1 -I{} bash -c "kubectl get {} --all-namespaces -oyaml && echo ---" | kube-score score -

Для Helm-чартов используйте рендеринг и пайпинг:

helm template example-manifest | kube-score score -

Скриншот вывода Kube-Score в терминале с цветной разметкой

Цветной вывод удобен при ручной проверке: каждый провал сопровождается описанием и рекомендациями. По умолчанию проверки помечаются как WARNING или CRITICAL. Критические ошибки обычно требуют немедленной правки; предупреждения зависят от контекста и политики вашей команды.

Если нужен машинно-читаемый результат, используйте флаг --output-format со значением json или ci.

ci формат удобен для CI/CD-систем.
json возвращает JSON-представление обычного консольного вывода.

При обнаружении ошибок Kube-Score завершает работу с кодом возврата 1 — удобно интегрировать в пайплайны, где нужно фейлить сборку при проблемах.

Важно: локальный запуск и CI-интеграция дают разный уровень защиты. Локальная проверка помогает разработчикам, CI — защищает ветки и релизы.

Что проверяет Kube-Score

Kube-Score содержит более 20 встроенных проверок, фокусируясь на безопасности и надёжности. Коротко — он проверяет общие ошибки конфигурации, которые часто приводят к инцидентам.

Основные проверки:

Запрет на использование тега latest для контейнерных образов.
Проверка imagePullPolicy: рекомендуется Always, чтобы проверять pull-секреты при каждом запуске.
Наличие корректных readiness и liveness probes у Pod’ов.
Корректность сетевых политик и маршрутов ingress/egress.
Валидность и полнота меток (labels) у ресурсов.
Проверка Pod anti-affinity, чтобы не мешать планировщику узла.
Проверка соответствия Service существующим Pod’ам.
Рекомендация readonly root filesystem и запрет privileged, где это не нужно.

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

Когда проверки могут дать ложные срабатывания

Особенности вашей инфраструктуры (например, приватный реестр) могут требовать отличных настроек imagePullPolicy.
Beta- или deprecated-API могут присутствовать намеренно (при миграциях) — в этом случае Kube-Score покажет ошибку, но она может быть плановой.
Контейнеры с динамическим доступом могут не иметь статичных лимитов — Kube-Score пометит это как предупреждение.

Опциональные правила

Некоторые проверки отключены по умолчанию, потому что они слишком субъективны или нарушают практики отдельных команд. Включайте их целенаправленно.

Пример включения опционального теста:

kube-score --enable-optional-test container-security-context-user-group-id

Этот тест проверяет, что контейнер запускается с явными UID/GID >= 1000. Множественные опции подключаются повторами флага.

Отключение проверок:

kube-score --ignore-test

Есть также флаги --ignore-container-cpu-limit и --ignore-container-memory-limit, которые отключают требование ручной установки лимитов CPU/памяти.

Управление версиями Kubernetes

По умолчанию Kube-Score ориентируется на Kubernetes v1.18. Если ваш кластер другой версии, указывайте её явно:

kube-score --kubernetes-version 1.24

Это помогает избежать ложных срабатываний, когда проверка зависит от конкретного API-уровня. Kube-Score ожидает, что ресурсы используют стабильные API; ссылки на устаревшие beta-API пометятся как ошибки.

Практическое руководство: интеграция в разработку и CI

Ниже — набор полезных артефактов для внедрения Kube-Score в рабочий процесс организации.

Мини-методология сканирования

Локальная проверка при сохранении файла (pre-commit hook).
Проверка при открытии Pull Request (CI step) с --output-format ci.
Еженедельный скан всего кластера (cron job) для поиска разрывов конфигурации.
Ручной аудит после миграции API или обновления кластера.

Шаблон шага CI (плейбук)

Шаг 1: checkout кода.
Шаг 2: рендер Helm в YAML (если используется Helm).
Шаг 3: запуск kube-score с --output-format ci.
Шаг 4: фейлить сборку при обнаружении критических ошибок, добавлять комментарий к PR с результатами.

Чек-листы по ролям

Разделение ответственности ускоряет реакцию и уменьшает шум.

Разработчик:
- Проверил свой Pod на readiness/liveness.
- Указал image tag (не latest).
- Добавил базовые ресурсы (requests/limits) или отключил проверку явно.
SRE/Платформенная команда:
- Настроила сетевые политики.
- Контролирует правилку anti-affinity для критичных рабочих нагрузок.
- Проводит регулярные полные сканы namespace’ов.
Команда безопасности:
- Включает опциональные проверки security-context.
- Анализирует наличие privileged и writable root filesystem.

Быстрые советы по исправлению типичных проблем

Если Kube-Score жалуется на latest, переключитесь на конкретный тег с семантической версией.
Для проблем с probes — добавьте простые liveness/readiness probes средствами HTTP или tcpSocket с низкой задержкой.
Для контейнеров без лимитов — задайте conservative requests и limits, даже минимальные, чтобы планировщик мог работать.
Для сетевых ошибок — опишите NetworkPolicy, ограничив ingress/egress по необходимости.

Дополнительные материалы и альтернативы

Kube-Score — быстрое средство статического анализа. Альтернативы и дополнения:

kube-linter — похожий инструмент с набором правил и конфигурацией.
Polaris — фокус на best practices и отчётах для команд.
OPA / Gatekeeper — для политики и блокировок на уровне admission.

Комбинация Kube-Score (быстрая проверка) + OPA/Gatekeeper (политики блокировки) даёт баланс между ранним обнаружением и принудительным соблюдением политики.

Модель принятия решений (Mermaid)

graph TD
  A[Запустить kube-score] --> B{Есть CRITICAL?}
  B -- Да --> C[Остановить деплой, уведомить разработчика]
  B -- Нет --> D{Есть WARNING?}
  D -- Да --> E[Оценить риск, назначить тикет]
  D -- Нет --> F[Развернуть]
  C --> G[Повторный запуск после исправлений]
  E --> G

Краткая таблица совместимости и советы по миграции

Указывайте флаг --kubernetes-version при работе с кластерами v1.19 и выше.
При миграции API: сначала прогоните скан с текущей версии, затем с целевой — сравните разницу и составьте план исправлений.
Если ресурс использует beta-API по причинам обратной совместимости, зафиксируйте это в документации и добавьте задачу по миграции.

Безопасность и приватность

Kube-Score анализирует только манифесты. Тем не менее:

Не отправляйте секреты в открытый веб-анализатор.
Для публичного live-анализатора используйте редактирование тестовых манифестов без чувствительных данных.
В CI храните выводы в защищённом хранилище и ограничьте доступ к логам, содержащим потенциально чувствительные имена и пути.

1‑строчный глоссарий

Probe: механизм для проверки здоровья контейнера (liveness/readiness).
imagePullPolicy: политика загрузки образа (Always/IfNotPresent/Never).
CRITICAL/WARNING: уровни серьёзности проверок в Kube-Score.

Критерии приёмки

CI шаг с Kube-Score выполняется для всех PR.
Ветка нельзя смержить при наличии CRITICAL ошибок.
Команда регистрирует и решает WARNINGs в срок, определённый внутренней политикой.

Итог

Kube-Score — простой и эффективный инструмент для раннего обнаружения проблем в Kubernetes-манифестах. Он не заменяет полноценный аудит или runtime-мониторинг, но заметно снижает риск типичных ошибок конфигурации. Интеграция Kube-Score в локальные проверки и CI повышает надёжность и безопасность деплоев.

Ключевые действия: внедрите Kube-Score в pre-commit и CI, включите опциональные проверки по потребности, и держите версию Kubernetes согласованной между инструментом и кластером.

Kube-Score: статический анализ манифестов Kubernetes