Введение
Обновлять приложения в Kubernetes вручную — почти всегда боль: нужно следить за тегами образов, вовремя применять манифесты, не забывать про правила версионирования и не “уронить” прод. Keel решает эту задачу как Kubernetes Operator: он отслеживает новые версии контейнеров (и релизов Helm) и автоматически обновляет ваши workload’ы по заданной политике — Deployments, DaemonSets, StatefulSets и Helm-релизы.
Официальный репозиторий: https://github.com/keel-hq/keel
Что такое Keel и как он работает
Keel — лёгкий self-hosted сервис (один контейнер, без отдельной БД), который запускается в кластере и выполняет роль “авто-апдейтера”. Логика управления обновлениями задаётся прямо в манифестах ваших приложений (через annotations) или в Helm-чартах:
- что обновлять — конкретный Deployment/StatefulSet/DaemonSet или Helm release;
- когда обновлять — по опросу реестра (poll) или по webhook-триггеру;
- как обновлять — по политике версий (например, patch/minor по SemVer) или принудительно.
Идея простая: вы публикуете новый образ в registry, Keel это видит и обновляет ресурс, соблюдая заданные правила.
Таблица: быстрые команды и действия
| Задача | Команда / действие | Примечание |
|---|---|---|
| Создать namespace | kubectl create namespace keel | Изолирует компоненты Keel |
| Посмотреть pod’ы Keel | kubectl -n keel get pods | Проверка, что Keel запущен |
| Посмотреть Deployment Keel | kubectl -n keel get deploy | Быстрая диагностика |
| Применить манифест приложения | kubectl apply -f deployment.yaml | После добавления аннотаций Keel |
| Посмотреть события в namespace | kubectl -n default get events –sort-by=.metadata.creationTimestamp | Помогает понять, что и когда обновилось |
| Проверить rollout | kubectl -n default rollout status deploy/webhook-demo | Удобно после обновления образа |
| История rollout | kubectl -n default rollout history deploy/webhook-demo | Проверка, какая ревизия применена |
Практические примеры использования
Пример 1. Автообновление Deployment по SemVer (minor)
Допустим, вы хотите автоматически подтягивать новые версии образа, но только в рамках minor (например, 1.3.x → 1.4.x, но не 2.0.0). В манифест Deployment добавьте аннотации Keel:
kind: Deployment
metadata:
name: webhook-demo
namespace: default
annotations:
keel.sh/policy: minor
keel.sh/trigger: poll
spec:
replicas: 2
selector:
matchLabels:
app: webhook-demo
template:
metadata:
labels:
app: webhook-demo
spec:
containers:
- name: app
image: your-registry.example.com/webhook-demo:1.4.2
imagePullPolicy: Always
Что получится: вы пушите, например, 1.4.3 или 1.5.0 — Keel обновит. Пушите 2.0.0 — Keel пропустит.
Пример 2. Обновление только patch-версий (без “скачков” по minor)
Подходит для продакшена, где важно минимизировать риск:
annotations:
keel.sh/policy: patch
keel.sh/trigger: poll
Логика: 1.4.2 → 1.4.3 обновится, 1.4.2 → 1.5.0 — нет.
Пример 3. StatefulSet: аккуратные обновления сервисов со state
Keel поддерживает StatefulSets. Это удобно, когда вы регулярно выкатываете новые сборки приложения, но хотите оставаться в рамках политики версий:
kind: StatefulSet
metadata:
name: api-stateful
annotations:
keel.sh/policy: patch
keel.sh/trigger: poll
spec:
serviceName: api-stateful
replicas: 3
selector:
matchLabels:
app: api-stateful
template:
metadata:
labels:
app: api-stateful
spec:
containers:
- name: api
image: your-registry.example.com/api:3.2.9
imagePullPolicy: Always
Пример 4. DaemonSet: обновления агентов/логгеров на всех нодах
Классический кейс — лог-агенты, security-агенты, node-exporter и любые сервисы “по одному на ноду”:
kind: DaemonSet
metadata:
name: log-agent
annotations:
keel.sh/policy: minor
keel.sh/trigger: poll
spec:
selector:
matchLabels:
app: log-agent
template:
metadata:
labels:
app: log-agent
spec:
containers:
- name: agent
image: your-registry.example.com/log-agent:0.9.1
imagePullPolicy: Always
Пример 5. Helm: автообновление релиза
Keel умеет работать и как “провайдер” для Helm. Практическая логика та же: вы задаёте правила обновления в чарте/значениях и Keel обновляет релиз, когда появляется новая версия (либо образов, либо релиза — в зависимости от вашей схемы поставки).
На практике это удобно, если у вас много одинаковых окружений (dev/stage), и вы хотите, чтобы они обновлялись сами по понятным правилам, без ручного helm upgrade каждый раз.
Установка Keel в кластер
Ниже — базовый, “быстрый” сценарий. Детали и варианты установки (включая Helm chart) смотрите в документации Keel и репозитории.
Шаг 1. Подготовьте namespace
Шаг 2. Установите Keel
Вариант A (Helm chart): если вы предпочитаете Helm-установку, используйте чарт Keel. Общая логика будет такой:
helm repo update
helm install keel keel/keel -n keel
Примечание: адрес репозитория/имя чарта может отличаться в зависимости от источника. Самый надёжный вариант — проверить актуальные команды в официальной документации/ArtifactHub перед установкой.
Вариант B (kubectl apply): подходит, если хотите минимальную зависимость от Helm. В этом случае вы применяете готовые YAML-манифесты Keel из официального репозитория/доков.
Шаг 3. Проверьте, что Keel запущен
kubectl -n keel get deploy
Шаг 4. Добавьте аннотации в ваши workload’ы
Keel начинает работать, когда видит в ресурсах свои annotations (policy/trigger и т.д.). После добавления аннотаций примените изменения:
Рекомендации по эксплуатации
- Начинайте с patch для production, а minor оставляйте для dev/stage — так проще контролировать риски.
- Используйте уникальные, предсказуемые теги. Если у вас “latest”, обновления могут стать непрозрачными (когда именно и что приехало).
- Продумайте триггер: poll проще стартовать, webhooks — быстрее и экономнее по запросам к registry.
- Наблюдаемость: убедитесь, что вы видите события rollout’ов (events/логирование), чтобы быстро разбирать причины обновления или пропуска.
О практике: где это удобно запускать
Keel особенно хорошо ложится на сценарии, где вы хотите “почти CI/CD”, но без тяжёлого конвейера: небольшие команды, продуктовые микросервисы, быстрое dev/stage, типовые окружения. В таких случаях часто важнее не усложнять, а стабильно обновляться по понятным правилам.
Если вы разворачиваете Kubernetes самостоятельно (kubeadm/k3s) или держите несколько окружений под разные проекты, удобно иметь инфраструктуру, где VPS можно поднять быстро и предсказуемо — например, в локальном регионе под целевую аудиторию. В Serverspace можно развернуть виртуальные серверы в нужной локации и собрать кластер так, как вам удобно (dev/stage/песочницы), а затем использовать Keel для автоматических обновлений сервисов по SemVer-политикам. Для проектов, ориентированных на Узбекистан и соседние рынки, логично смотреть в сторону Serverspace.uz, чтобы размещать инфраструктуру ближе к пользователям и снижать задержки — а Keel уже закрывает рутину с выкладками.
Вывод
Keel — практичный Kubernetes Operator для автоматизации обновлений Deployments/StatefulSets/DaemonSets и Helm-релизов. Он подходит, когда вы хотите убрать ручные “kubectl apply ради нового тега” и заменить это на управляемые политики: patch/minor и понятные триггеры. В результате вы экономите время команды, ускоряете цикл поставки и снижаете риск человеческих ошибок при регулярных релизах.
FAQ
Keel — это замена CI/CD?
Нет. CI/CD обычно отвечает за сборку, тестирование и публикацию артефактов. Keel решает более узкую задачу: автоматически обновляет Kubernetes workload, когда уже появился новый образ/версия (по правилам, которые вы задали).
Какие ресурсы Kubernetes поддерживаются?
В базовом сценарии Keel работает с Deployments, StatefulSets и DaemonSets, а также поддерживает интеграцию с Helm.
Как Keel понимает, что можно обновляться?
Вы задаёте это в annotations: выбираете политику (например, patch/minor по SemVer) и тип триггера (например, poll). Если новая версия подходит под политику — Keel инициирует обновление ресурса.
Что выбрать: poll или webhooks?
Poll проще стартовать: Keel периодически проверяет registry. Webhooks полезны, когда хочется быстрее реагировать на релиз и не делать лишних запросов к registry.
Можно ли использовать Keel в нескольких окружениях?
Да. Обычно Keel ставят отдельно в каждое окружение (dev/stage/prod) и задают разные политики обновления: например, minor для dev/stage и patch для prod.
Где взять примеры и актуальные параметры?
Начните с официального репозитория и документации: GitHub keel-hq/keel и keel.sh.