Introdução
Atualizar aplicações no Kubernetes manualmente quase sempre é um problema: é preciso acompanhar tags de imagens, aplicar manifestos no momento certo, não esquecer as regras de versionamento e evitar “derrubar” o ambiente de produção. O Keel resolve essa tarefa como um Kubernetes Operator: ele monitora novas versões de containers (e releases Helm) e atualiza automaticamente seus workloads de acordo com a política definida — Deployments, DaemonSets, StatefulSets e releases Helm.
Repositório oficial: https://github.com/keel-hq/keel
O que é o Keel e como ele funciona
O Keel é um serviço self-hosted leve (um único container, sem banco de dados separado) que roda dentro do cluster e atua como um “auto-updater”. A lógica de controle das atualizações é definida diretamente nos manifestos das aplicações (por meio de annotations) ou nos charts Helm:
- o que atualizar — um Deployment/StatefulSet/DaemonSet específico ou um release Helm;
- quando atualizar — por verificação periódica do registry (poll) ou por gatilho via webhook;
- como atualizar — seguindo uma política de versões (por exemplo, patch/minor via SemVer) ou de forma forçada.
A ideia é simples: você publica uma nova imagem no registry, o Keel detecta isso e atualiza o recurso, respeitando as regras configuradas.
Tabela: comandos e ações rápidas
| Tarefa | Comando / ação | Observação |
|---|---|---|
| Criar namespace | kubectl create namespace keel | Isola os componentes do Keel |
| Ver pods do Keel | kubectl -n keel get pods | Confirma que o Keel está em execução |
| Ver Deployment do Keel | kubectl -n keel get deploy | Diagnóstico rápido |
| Aplicar manifesto da aplicação | kubectl apply -f deployment.yaml | Após adicionar as annotations do Keel |
| Ver eventos no namespace | kubectl -n default get events --sort-by=.metadata.creationTimestamp | Ajuda a entender o que foi atualizado e quando |
| Verificar rollout | kubectl -n default rollout status deploy/webhook-demo | Útil após atualizar a imagem |
| Histórico de rollout | kubectl -n default rollout history deploy/webhook-demo | Verifica qual revisão foi aplicada |
Exemplos práticos de uso
Exemplo 1. Atualização automática de Deployment via SemVer (minor)
Suponha que você queira atualizar automaticamente novas versões da imagem, mas apenas dentro do escopo minor (por exemplo, 1.3.x → 1.4.x, mas não 2.0.0). Adicione as annotations do Keel ao manifesto do Deployment:
apiVersion: apps/v1
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: AlwaysResultado: ao publicar, por exemplo, 1.4.3 ou 1.5.0, o Keel atualiza. Se publicar 2.0.0, o Keel ignora.
Exemplo 2. Atualização apenas de versões patch (sem “saltos” de minor)
Indicado para produção, onde é importante minimizar riscos:
metadata:
annotations:
keel.sh/policy: patch
keel.sh/trigger: pollLógica: 1.4.2 → 1.4.3 será atualizado, 1.4.2 → 1.5.0 não.
Exemplo 3. StatefulSet: atualizações cuidadosas para serviços com estado
O Keel suporta StatefulSets. Isso é útil quando você lança novas builds com frequência, mas quer manter uma política de versões controlada:
apiVersion: apps/v1
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: AlwaysExemplo 4. DaemonSet: atualizações de agentes/loggers em todos os nós
Caso clássico — agentes de log, agentes de segurança, node-exporter e quaisquer serviços “um por nó”:
apiVersion: apps/v1
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: AlwaysExemplo 5. Helm: atualização automática de releases
O Keel também funciona como “provedor” para Helm. A lógica é a mesma: você define as regras de atualização no chart/values e o Keel atualiza o release quando surge uma nova versão (de imagens ou do próprio release, dependendo do seu fluxo).
Na prática, isso é útil quando você tem muitos ambientes semelhantes (dev/stage) e quer que eles se atualizem automaticamente seguindo regras claras, sem executar helm upgrade manualmente a cada vez.
Instalação do Keel no cluster
Abaixo está um cenário básico e rápido. Para detalhes e variações de instalação (incluindo Helm chart), consulte a documentação e o repositório do Keel.
Passo 1. Preparar o namespace
kubectl create namespace keelPasso 2. Instalar o Keel
Opção A (Helm chart): se você prefere instalar via Helm, utilize o chart do Keel. A lógica geral é:
helm repo add keel https://charts.keel.sh
helm repo update
helm install keel keel/keel -n keelObservação: o endereço do repositório/nome do chart pode variar. O mais seguro é verificar os comandos atualizados na documentação oficial ou no ArtifactHub.
Opção B (kubectl apply): adequada se você quer reduzir dependências do Helm. Nesse caso, aplique os manifestos YAML do Keel disponíveis no repositório/documentação oficial.
Passo 3. Verificar se o Keel está em execução
kubectl -n keel get pods
kubectl -n keel get deployPasso 4. Adicionar annotations aos seus workloads
O Keel começa a funcionar quando encontra suas annotations (policy/trigger etc.) nos recursos. Após adicioná-las, aplique as alterações:
kubectl apply -f deployment.yamlRecomendações de operação
- Comece com patch em produção e deixe minor para dev/stage — isso facilita o controle de riscos.
- Use tags únicas e previsíveis. Com “latest”, as atualizações podem se tornar pouco transparentes.
- Escolha bem o trigger: poll é mais simples para começar; webhooks são mais rápidos e reduzem chamadas ao registry.
- Observabilidade: garanta visibilidade dos eventos de rollout (events/logs) para entender por que uma atualização ocorreu ou foi ignorada.
Sobre a prática: onde isso é mais conveniente
O Keel se encaixa muito bem em cenários onde você quer algo “quase CI/CD”, mas sem pipelines pesados: equipes pequenas, microsserviços de produto, dev/stage rápidos e ambientes padronizados. Nesses casos, é mais importante manter atualizações estáveis e previsíveis do que adicionar complexidade.
Se você executa Kubernetes por conta própria (kubeadm/k3s) ou mantém vários ambientes para projetos diferentes, é útil contar com uma infraestrutura onde VPS possam ser criados de forma rápida e previsível — por exemplo, em uma região próxima ao público-alvo. Na Serverspace, é possível implantar servidores virtuais na localização desejada e montar o cluster conforme a sua necessidade (dev/stage/labs), usando o Keel para automatizar atualizações de serviços com políticas SemVer.
Conclusão
O Keel é um Kubernetes Operator prático para automatizar atualizações de Deployments, StatefulSets, DaemonSets e releases Helm. Ele é ideal quando você quer eliminar “kubectl apply só para trocar a tag” e substituí-lo por políticas gerenciadas (patch/minor) e triggers claros. O resultado é economia de tempo da equipe, ciclos de entrega mais rápidos e menor risco de erros humanos em releases frequentes.
FAQ
O Keel substitui um CI/CD?
Não. CI/CD normalmente cuida da build, testes e publicação de artefatos. O Keel resolve uma tarefa mais específica: atualizar automaticamente workloads do Kubernetes quando uma nova imagem/versão já está disponível, seguindo as regras definidas.
Quais recursos do Kubernetes são suportados?
No cenário básico, o Keel funciona com Deployments, StatefulSets e DaemonSets, além de oferecer integração com Helm.
Como o Keel decide quando atualizar?
Isso é definido via annotations: você escolhe a política (por exemplo, patch/minor via SemVer) e o tipo de trigger (como poll). Se a nova versão se enquadra na política, o Keel inicia a atualização do recurso.
O que escolher: poll ou webhooks?
Poll é mais simples para começar: o Keel verifica periodicamente o registry. Webhooks são úteis quando você precisa reagir mais rápido aos releases e reduzir chamadas desnecessárias ao registry.
É possível usar o Keel em vários ambientes?
Sim. Normalmente o Keel é instalado separadamente em cada ambiente (dev/stage/prod), com políticas de atualização diferentes — por exemplo, minor em dev/stage e patch em produção.
Onde encontrar exemplos e parâmetros atualizados?
Comece pelo repositório oficial e pela documentação: GitHub keel-hq/keel e keel.sh.
