Как использовать Datree CLI для проверки манифестов Kubernetes

Datree — это инструмент для статического анализа Kubernetes-манифестов, который быстро выявляет ошибки конфигурации и нарушения политики прямо в терминале. Установите CLI, сохраните манифест, запустите datree test, исправьте обнаруженные нарушения (например, фиксируйте теги образов, добавляйте liveness/readiness probes, задавайте лимиты ресурсов) и при желании подключите онлайн-дэшборд или webhook для централизованного контроля и блокировки некорректных объектов.

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

• Установка Datree CLI

• Выполнение проверки политики

• Настройка правил

• Сканирование с конкретной политикой

• Сканирование нескольких файлов

• Аутентификация других CLI-инстансов

• Использование Datree без доступа к аккаунту

• Резюме

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

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

В этой статье вы научитесь использовать Datree CLI для оперативного сканирования манифестов. Инструмент бесплатен и с открытым исходным кодом, но поддерживается онлайн-панелью, где можно централизованно управлять политиками для всей команды. Бесплатный план покрывает индивидуальное использование с до двух Nodes; командные планы начинаются от $95/мес и включают базовый набор из пяти Nodes.

Установка Datree CLI

Сначала скачайте и установите Datree CLI с помощью скрипта установки. Скрипт работает на Linux и macOS:

$ curl https://get.datree.io | /bin/bash

Если вы используете Windows или хотите запустить Datree в контейнере Docker, в документации есть альтернативные инструкции.

Проверьте корректность установки, выполнив команду datree без аргументов:

$ datree

Datree — это инструмент статического анализа YAML-файлов Kubernetes. Полный исходный код доступен на https://github.com/datreeio/datree

…

Теперь можно начинать сканирование манифестов на ошибки.

Выполнение проверки политики

Скопируйте следующий YAML и сохраните как datree-demo.yaml в рабочем каталоге:

apiVersion: apps/v1

kind: Deployment

metadata:

name: demo-deployment

namespace: demo

spec:

replicas: 2

selector:

matchLabels:

app: demo-app

template:

metadata:

namespace: demo-deployment

labels:

app: demo-app

spec:

containers:

• name: nginx

image: nginx:latest

readinessProbe:

tcpSocket:

port: 8080

resources:

requests:

memory: “256Mi”

cpu: “100m”

limits:

cpu: “500m”

ports:

• containerPort: 80

  
  Этот YAML описывает объект Deployment для Kubernetes. Kubectl применит его к кластеру без синтаксических ошибок:
  

  $ kubectl apply -f datree-demo.yaml

  
  deployment/demo-deployment created
  
  Но такая конфигурация может содержать скрытые проблемы. Запуск Datree CLI покажет их. Используйте команду `datree test` для анализа манифеста:
  

  $ datree test datree-demo.yaml

  
  >> File: datree-demo.yaml
  
  [V] YAML validation
  
  [V] Kubernetes schema validation
  
  [X] Policy check
  
  ❌ Ensure each container image has a pinned (tag) version [1 occurrence]
  
  - metadata.name: demo-deployment (kind: Deployment)
  
  💡 Incorrect value for key `image` - specify an image version to avoid unpleasant "version surprises" in the future
  
  ❌ Ensure each container has a configured liveness probe [1 occurrence]
  
  - metadata.name: demo-deployment (kind: Deployment)
  
  💡 Missing property object `livenessProbe` - add a properly configured livenessProbe to catch possible deadlocks
  
  ❌ Ensure each container has a configured memory limit [1 occurrence]
  
  - metadata.name: demo-deployment (kind: Deployment)
  
  💡 Missing property object `limits.memory` - value should be within the accepted boundaries recommended by the organization
  
  (Summary)
  
  - Passing YAML validation: 1/1
  
  - Passing Kubernetes (1.20.0) schema validation: 1/1
  
  - Passing policy check: 0/1
  
  +-----------------------------------+-----+
  
  | Enabled rules in policy "Default" | 21 |
  
  | Configs tested against policy | 1 |
  
  | Total rules evaluated | 21 |
  
  | Total rules skipped | 0 |
  
  | Total rules failed | 3 |
  
  | Total rules passed | 18 |
  
  +-----------------------------------+-----+
  
  Datree выявил три нарушения политики, которые могут повлиять на ваш кластер.
  
  ### Как интерпретировать результаты сканирования
  
  Datree проверяет три аспекта каждого манифеста:
  
  - YAML validation — первичная проверка корректности YAML. Если синтаксис неверен, последующие проверки не выполняются.
  - Kubernetes schema validation — проверяет, соответствует ли объект схеме Kubernetes (например, корректность полей и вложенности).
  - Policy checks — тесты на общие ошибки и недостающие оптимизации, которые повышают надёжность кластера.
  
  Каждый отчёт заканчивается таблицей с количеством проверенных конфигураций, использованных правил и найденных ошибок.
  
  ## Исправление ошибок в примере
  
  Анализ примера показал три проблемы: образ контейнера использует тег latest вместо фиксированной версии, отсутствует livenessProbe и не задан лимит памяти.
  
  1) Закрепите версию образа. Вместо `nginx:latest` используйте `nginx:1.23` или другой конкретный тег. Тег latest рискует получить несовместимое обновление.
  
  2) Добавьте livenessProbe. Liveness-проверки позволяют Kubernetes перезапустить контейнер, если он застрял в некорректном состоянии.
  
  Добавьте `livenessProbe` перед `readinessProbe`:
  

  livenessProbe:

  
  tcpSocket:
  
  port: 8080
  
  3) Установите лимит памяти. В примере есть requests и CPU-лимит, но отсутствует memory limit, поэтому контейнер может съесть всю память узла.
  
  Обновлённый YAML должен выглядеть так:
  

  apiVersion: apps/v1

  
  kind: Deployment
  
  metadata:
  
  name: demo-deployment
  
  namespace: demo
  
  spec:
  
  replicas: 2
  
  selector:
  
  matchLabels:
  
  app: demo-app
  
  template:
  
  metadata:
  
  namespace: demo-deployment
  
  labels:
  
  app: demo-app
  
  spec:
  
  containers:
  
  - name: nginx
  
  image: nginx:1.23
  
  livenessProbe:
  
  tcpSocket:
  
  port: 8080
  
  readinessProbe:
  
  tcpSocket:
  
  port: 8080
  
  resources:
  
  requests:
  
  memory: "256Mi"
  
  cpu: "100m"
  
  limits:
  
  memory: "512Mi"
  
  cpu: "500m"
  
  ports:
  
  - containerPort: 80

Повторите datree test, чтобы убедиться, что развертывание проходит проверку политики:

$ datree test datree-demo.yaml

(Summary)

• Passing YAML validation: 1/1

• Passing Kubernetes (1.20.0) schema validation: 1/1

• Passing policy check: 1/1

Настройка правил

Примеры выше использовали стандартный набор правил Datree. Встроенные правила покрывают общие практики Kubernetes: probes, resource limits, избегание устаревших API и т.д.

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

Проще всего войти в Datree по ссылке в конце вывода CLI:

| See all rules in policy | https://app.datree.io/login?t=bbY... |

CLI автоматически генерирует уникальный токен для аккаунта. Перейдите по ссылке и войдите через GitHub или Google.

Вы попадёте в дашборд Policies, где видны активные политики вашего аккаунта. Переключатели в колонке “Status” включают или отключают отдельные правила — изменения применяются сразу к новым сканированиям. CLI загружает список политик перед запуском каждого теста.

Дэшборд также хранит историю сканов. Откройте вкладку “History” в левой боковой панели, чтобы посмотреть предыдущие результаты.

Сканирование с конкретной политикой

В Datree есть 60 встроенных правил, объединённых в политики. Политика Default включена по умолчанию и содержит 21 правило. Также доступны преднастроенные политики для Argo и NSA Kubernetes.

Создать собственную политику можно через кнопку Create Policy в дашборде: задайте имя и включите необходимые правила.

Чтобы запустить скан с конкретной политикой, используйте флаг --policy и укажите имя политики:

$ datree test --policy NSA datree-demo.yaml

Datree позволяет создавать полностью новые правила. Это выходит за рамки вводного руководства, но кратко: правила описываются в JSON или YAML и используют логику JSON Schema. С помощью пользовательских правил можно требовать конкретные метки, минимальное количество реплик или ограничивать регистры образов.

Сканирование нескольких файлов

Команда datree test принимает путь к файлу или glob-паттерн. Сканирование директории выполняется так:

datree test demo-dir/*.yaml

Любые неверные файлы, совпавшие с паттерном, покажут ошибку в YAML validation.

Аутентификация других CLI-инстансов

Datree CLI подключается к аккаунту через токен. При установке создаётся новый токен и настраивается новый аккаунт при первом использовании.

Если вы хотите использовать один и тот же аккаунт на другой машине, вручную передайте существующий токен. Найдите значение в поле token в ~/.datree/config.yaml, либо откройте дашборд, выберите Settings → Token Management.

В новом инстансе CLI добавьте токен так:

$ datree config set token 

CLI начнёт использовать политики вашего аккаунта, а результаты появятся в истории сканов.

Использование Datree без доступа к аккаунту

Если вам достаточно стандартного набора правил и вы не хотите, чтобы CLI общался с серверами Datree, отключите подключение к аккаунту:

$ datree config set offline local

В офлайновом режиме поддержка Kubernetes schema validation отключается.

Чтобы не отправлять отдельный скан в историю аккаунта, используйте флаг --no-record:

$ datree test datree-demo.yaml --no-record

Интеграция Datree в CI: мини-SOP

Ниже — упрощённая последовательность шагов для интеграции Datree в CI-пайплайн:

1. Установите datree в контейнере CI или образе сборки (скрипт установки или пакет).
2. Загрузите токен аккаунта или настройте офлайн-политику для reproducible-проверок.
3. Добавьте шаг datree test перед стадией деплоя. Используйте --policy если нужно специфическое правило.
4. На этапе fail-fast завершайте сборку при ненулевом коде возврата команды.
5. Логируйте вывод в артефакты сборки и при необходимости отправляйте уведомления в Slack/Teams при ошибках.

Пример шага в GitHub Actions:

- name: Run Datree policy check
  run: |
    curl https://get.datree.io | /bin/bash
    datree test --policy Default ./manifests/*.yaml

Важно: храните токен с помощью секретов CI и не выводите его в логах.

Когда Datree может не подходить

• Требуется рантайм-валидация зависимостей между объектами (например, взаимозависимые Custom Resources), Datree — статический анализ и не видит состояние кластера.
• Необходимы сложные динамические проверки, основанные на метриках или поведении приложений — для этого нужны инструменты monitoring/observability.
• Если вы строго ограничены офлайном и при этом нуждаетесь в Kubernetes schema validation, учтите, что в офлайн-режиме схема может недоступна.

Альтернативные подходы и инструменты

• kubeval — валидирует объект против схемы Kubernetes.
• kube-score — статические рекомендации по best practices.
• OPA/Gatekeeper — политики в виде правил, встроенные в кластер.

Datree дополняет эти инструменты удобным CLI + дашбордом и готовыми набором правил.

Важно: Datree не заменяет комплексный процесс ревью кода и CI/CD, но помогает автоматизировать обнаружение распространённых ошибок.

Роль‑ориентированные чек-листы

Разделены по ролям для быстрого применения в команде.

Разработчик:

• Проверить, что образ использует фиксированный тег.
• Добавить readiness и liveness probes.
• Описать requests и limits для CPU и памяти.
• Запустить datree test локально перед PR.

SRE / инженер по платформе:

• Настроить общую политику в дашборде.
• Подключить Datree в CI и admission webhook.
• Проверять историю ошибок и настраивать оповещения.

Инженер безопасности:

• Добавить правила для разрешённых регистров образов.
• Требовать конкретные метки и аннотации для контроля доступа.
• Включить аудит неудачных попыток и интегрировать с SIEM.

Методология проверки конфигурации (мини-метод)

1. Локальная проверка: datree test на машине разработчика.
2. CI-проверка: fail-fast шаг перед деплоем.
3. Принудительная защита: admission webhook, который блокирует нарушения в кластере.
4. Мониторинг: отслеживание истории сканов и трендов ошибок.

Decision tree для выбора режима работы Datree

flowchart TD
  A[Нужна централизованная политика?] -->|Да| B[Использовать онлайн-дэшборд]
  A -->|Нет| C[Работа в офлайн режиме]
  B --> D[Подключить токен в CLI и настроить политики]
  D --> E{Нужно блокировать некорректные объекты в кластере?}
  E -->|Да| F[Включить admission webhook]
  E -->|Нет| G[Интегрировать в CI и мониторить историю]
  C --> H{Нужна схема валидации?}
  H -->|Да| I[Оставить online подключение или использовать kubeval локально]
  H -->|Нет| J[Полагаться на дефолтные правила и локальные проверки]

Примеры правил и когда они срабатывают

• Фиксированный тег образа — предотвращает неожиданные обновления.
• Liveness probe — снижает риск постоянного состояния «зависания» контейнера.
• Memory limit — защищает узлы от OOM-ситуаций.

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

Факты и ключевые числа

• Встроенных правил: 60
• Правил в Default policy: 21
• Бесплатный режим: индивидуальное использование до 2 Nodes
• Командные планы: от $95/мес с базовым лимитом 5 Nodes

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

• Все манифесты проходят YAML validation.
• Все объекты соответствуют Kubernetes schema.
• Политики команды применены и не дают критических нарушений.
• CI падает при найденных нарушениях, если правило помечено как blocking.

Глоссарий (одна строка на термин)

• Liveness probe — проверка, определяющая, что контейнер жив и не требуется перезапуск.
• Readiness probe — проверка, указывающая, что контейнер готов принимать трафик.
• Admission webhook — сервер, который принимает решение о разрешении создания/обновления объекта.
• Policy — набор правил Datree, объединяющих отдельные проверки.

Итог

Datree CLI — удобный инструмент для автоматической проверки Kubernetes-манифестов с возможностью централизованного управления правилами через онлайн-дэшборд и опциями интеграции в CI/CD и admission webhook. Используйте локальную проверку для быстрого feedback, интеграцию в CI для предотвращения регрессий и webhook для гарантированной блокировки некорректных ресурсов в кластере.

Ключевые рекомендации:

• Фиксируйте теги образов.
• Всегда задавайте liveness и readiness probes.
• Устанавливайте requests и limits, особенно для памяти.
• Интегрируйте Datree в CI и/или включите webhook для защиты кластера.

Спасибо за чтение. Если нужна помощь с конкретной интеграцией или шаблонами политик — опишите ваш сценарий, и мы подготовим пошаговый план.