Introducción
Actualización manual de aplicaciones en Kubernetes Casi siempre es una molestia: hay que hacer un seguimiento de las etiquetas de imágenes, aplicar manifiestos a tiempo, recordar las reglas de control de versiones y evitar “detener” la producción. Quilla Resuelve este problema como un Kubernetes Operador: supervisa nuevas versiones de contenedores (y lanzamientos de Helm) y actualiza automáticamente sus cargas de trabajo de acuerdo con una política definida: implementaciones, DaemonSets, StatefulSets y lanzamientos de Helm.
Repositorio oficial: https://github.com/keel-hq/keel
¿Qué es Keel y cómo funciona?
Quilla Es un servicio ligero autoalojado (un solo contenedor, sin base de datos independiente) que se ejecuta dentro de un clúster y actúa como un actualizador automático. La lógica de gestión de actualizaciones se define directamente en los manifiestos de la aplicación (mediante anotaciones) o en los diagramas de Helm:
- Qué actualizar — un Deployment/StatefulSet/DaemonSet específico o una versión de Helm;
- cuándo actualizar — a través de un sondeo de registro (encuesta) o un activador de webhook;
- como actualizar — de acuerdo con una política de versiones (por ejemplo, parche/menor a través de SemVer) o de manera forzada.
La idea es simple: publicas una nueva imagen en el registro, Keel la detecta y actualiza el recurso respetando las reglas definidas.
Tabla: comandos y acciones rápidas
| Task | Comando/acción | Notas |
|---|---|---|
| Crear espacio de nombres | kubectl crea espacio de nombres quilla | Aísla los componentes de la quilla |
| Ver vainas de quilla | kubectl -n quilla obtener pods | Comprueba que Keel se está ejecutando |
| Ver la implementación de la quilla | kubectl -n quilla obtener implementación | Diagnósticos rápidos |
| Aplicar manifiesto de aplicación | kubectl apply -f implementación.yaml | Después de agregar anotaciones de Keel |
| Ver eventos del espacio de nombres | kubectl -n predeterminado obtener eventos --sort-by=.metadata.creationTimestamp | Ayuda a comprender qué se actualizó y cuándo |
| Comprobar el lanzamiento | kubectl -n estado de implementación predeterminado deploy/webhook-demo | Conveniente después de las actualizaciones de imágenes |
| Historial de lanzamiento | kubectl -n historial de implementación predeterminado deploy/webhook-demo | Comprueba qué revisión se aplicó |
Ejemplos de uso práctico
Ejemplo 1. Actualizaciones automáticas de implementación mediante SemVer (menor)
Supongamos que desea extraer automáticamente nuevas versiones de imágenes, pero solo dentro de la menor de edad Ámbito (por ejemplo, 1.3.x → 1.4.x, pero no 2.0.0). Agregue anotaciones de Keel al manifiesto de implementación:
apiVersion: apps/v1
kind: Deployment
metadata:
name: webhook-demo
namespace: default
annotations:
keel.sh/policy: minor
keel.sh/trigger: poll
Example 2. Updating only patch versions (no minor “jumps”)
Suitable for production environments where minimizing risk is critical:
metadata:
annotations:
keel.sh/policy: patch
keel.sh/trigger: poll
Lógica: 1.4.2 → 1.4.3 se actualizará, mientras que 1.4.2 → 1.5.0 no lo hará.
Ejemplo 3. StatefulSet: actualizaciones cuidadosas para servicios con estado
Keel admite StatefulSets. Esto resulta útil cuando se publican nuevas compilaciones de aplicaciones con frecuencia, pero se desea cumplir con políticas de control de versiones estrictas:
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: AlwaysEjemplo 4. DaemonSet: actualización de agentes/registradores en todos los nodos
Un caso de uso clásico: agentes de registro, agentes de seguridad, exportador de nodos y cualquier servicio "uno por nodo":
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: AlwaysEjemplo 5. Helm: actualizaciones automáticas de versiones
Keel también puede funcionar como proveedor de Helm. La lógica práctica es la misma: se definen las reglas de actualización en el gráfico/valores, y Keel actualiza la versión cuando aparece una nueva (ya sea de imágenes o de la propia versión, según el modelo de entrega).
En la práctica, esto es conveniente si tiene muchos entornos similares (desarrollo/etapa) y desea que se actualicen automáticamente según reglas claras, sin ejecutar helm upgrade manualmente cada vez.
Instalación de Keel en un clúster
A continuación se presenta un escenario básico de inicio rápido. Para obtener más información y variantes de instalación (incluido el diagrama de Helm), consulte la documentación y el repositorio de Keel.
Paso 1. Preparar el espacio de nombres
kubectl create namespace keelPaso 2. Instalar la quilla
Opción A (diagrama de timón): Si prefiere la instalación basada en Helm, utilice el diagrama de Keel. La lógica general es la siguiente:
helm repo add keel https://charts.keel.sh
helm repo update
helm install keel keel/keel -n keelNota: La dirección del repositorio o el nombre del gráfico pueden variar según la fuente. Lo más seguro es verificar los comandos más recientes en la documentación oficial o en ArtifactHub.
Opción B (aplica kubectl): Adecuado si desea una dependencia mínima de Helm. En este caso, aplique los manifiestos YAML de Keel del repositorio/documentación oficial.
Paso 3. Verifique que Keel esté ejecutándose
kubectl -n keel get pods
kubectl -n keel get deployPaso 4. Agregue anotaciones a sus cargas de trabajo
Keel empieza a funcionar cuando detecta sus anotaciones (política/disparador, etc.) en los recursos. Después de añadirlas, aplique los cambios:
kubectl apply -f deployment.yamlRecomendaciones operativas
- Empezar con el parche para producción y uso menor para desarrollo/etapa: esto hace que el control de riesgos sea más fácil.
- Utilice etiquetas únicas y predeciblesSi confías en "lo último", las actualizaciones pueden volverse opacas.
- Elige el disparador adecuado:La encuesta es más sencilla para comenzar; los webhooks son más rápidos y reducen las consultas de registro.
- Observabilidad: asegúrese de poder ver los eventos de implementación (eventos/registros) para comprender rápidamente por qué se produjo o se omitió una actualización.
En la práctica: dónde funciona mejor
Keel se adapta especialmente bien a escenarios donde se busca una integración continua y continua (CI/CD) sin pipelines complejos: equipos pequeños, microservicios de producto, ciclos rápidos de desarrollo y preparación, y entornos estandarizados. En estos casos, la simplicidad y las actualizaciones predecibles son más importantes que la complejidad añadida.
Si tu corres Kubernetes usted mismo (kubeadm/k3s) o mantener múltiples entornos para diferentes proyectos, es conveniente tener una infraestructura donde VPS Las instancias se pueden aprovisionar de forma rápida y predecible, por ejemplo, en una región cercana a su público objetivo. Con ServerspacePuede implementar servidores virtuales en la ubicación deseada y crear clústeres de la forma que necesite (desarrollo, ensayo y entornos aislados), luego usar Keel para automatizar las actualizaciones de servicio con políticas basadas en SemVer.
Keel en flujos de trabajo del mundo real: reducción de la fricción operativa
Una de las ventajas menos obvias de Keel es cómo cambia los hábitos operativos diarios. En lugar de tratar las implementaciones como acciones explícitas ("alguien necesita actualizar la imagen"), las actualizaciones se convierten en un proceso en segundo plano predecible, controlado por reglas. Este cambio reduce la carga cognitiva: los ingenieros dejan de pensar en cómo implementar una nueva versión y se centran más en lo que están entregando.
En equipos donde varios servicios se actualizan de forma independiente, este enfoque ayuda a evitar problemas de sincronización. Cada carga de trabajo sigue su propia política de actualización, por lo que un pequeño cambio en un servicio no obliga a realizar acciones manuales coordinadas en todo el clúster. Con el tiempo, esto se traduce en menos correcciones apresuradas, menos momentos de "actualización rápida de la etiqueta" y mayor confianza en el proceso de lanzamiento.
Keel también es útil como herramienta de transición. Para equipos que no están listos para invertir en pipelines complejos de CI/CD o GitLos flujos de trabajo de operaciones ofrecen una solución intermedia práctica. Siguen obteniendo actualizaciones automatizadas basadas en políticas, pero sin añadir componentes de infraestructura adicionales ni modificar significativamente los procesos existentes. Esto hace que Keel sea especialmente atractivo para equipos y proyectos en crecimiento que necesitan automatización inmediata, no después de un rediseño completo de la plataforma.
Conclusión
Keel es un práctico Kubernetes Operador para automatizar actualizaciones de implementaciones, conjuntos con estado, conjuntos de demonios y lanzamientos de Helm. Es ideal para eliminar los flujos de trabajo manuales de tipo "kubectl apply solo para cambiar una etiqueta" y reemplazarlos con políticas administradas (parche/menor) y desencadenadores claros. Como resultado, los equipos ahorran tiempo, los ciclos de entrega se agilizan y se reduce el riesgo de errores humanos durante lanzamientos frecuentes.
Preguntas Frecuentes
¿Es Keel un reemplazo para CI/CD?
No. CI/CD generalmente se encarga de la creación, prueba y publicación de artefactos. Keel resuelve una tarea más específica: actualización automática Kubernetes cargas de trabajo cuando ya hay una nueva imagen/versión disponible, según reglas definidas.
Cual Kubernetes ¿Qué tipos de carga de trabajo son compatibles?
En una configuración típica, Keel puede actualizar Los despliegues, Conjuntos con estadoy el ámbito Conjuntos de demonios, y también puede integrarse con Casco Lanzamientos
¿Cómo decide Keel cuándo actualizar?
Esto se define mediante anotaciones: se elige una política (por ejemplo, parche/menor mediante SemVer) y un tipo de activador (como sondeo). Si la nueva versión coincide con la política, Keel inicia la actualización del recurso.
¿Qué debería elegir: encuesta o webhooks?
Nuca Es más sencillo empezar con: Keel comprueba periódicamente el registro. Webhooks Son útiles cuando necesita una reacción más rápida a los lanzamientos y desea reducir las consultas de registro innecesarias.
¿Se puede utilizar Keel en múltiples entornos?
Sí. Keel normalmente se instala por separado en cada entorno (desarrollo/etapa/producción), con diferentes políticas de actualización: por ejemplo, menor para desarrollo/etapa y parche para producción.
¿Dónde puedo encontrar ejemplos y parámetros actualizados?
Comience con el repositorio oficial y la documentación: GitHub cuartel general de la quilla/quilla además quilla.sh.
Recursos adicionales: el Serverspace base de conocimientos y Kubernetes
Si recién está comenzando con Kubernetes o desea profundizar en temas específicos, desde conceptos centrales hasta operaciones diarias del clúster, el Serverspace La base de conocimientos ya contiene una amplia gama de materiales dedicados a Kubernetes.
En la base de conocimientos, puedes encontrar:
- Guías paso a paso para trabajar con Kubernetes y contenedores;
- Desgloses de tareas comunes de DevOps y administración de clústeres;
- tutoriales sobre implementación de aplicaciones, redes, almacenamiento y seguridad;
- artículos prácticos sobre Kubernetes herramientas del ecosistema, desde utilidades básicas hasta operadores y automatización.
Estos materiales son prácticos para usar como referencia diaria: cuando necesita recordar rápidamente un comando, verificar una configuración o comprender cómo configurar correctamente un componente específico. Combinados con herramientas como Keel, esto ayuda no solo a automatizar las actualizaciones, sino también a crear un entorno más claro y manejable. Kubernetes infraestructura.
