Keel - automated Kubernetes updates
Synopsis
If you are using Kubernetes for dev/test/production - you need a way to automate deployment updates once new images are available. Keel is a lightweight service to take care of that.
You can find more on its website: https://keel.sh and Github repository https://github.com/keel-hq/keel.
While Container Builder and Google Container Engine (Kubernetes) make a great pair and building images and running your workloads - there is a missing gap: who/what updates deployments when new images are available? maybe it’s you:
- update image tag in
deployment.yaml
- run
kubectl apply -f deployment.yaml
It does feel good to do that rolling update for the first few times, but what if you don’t have access to kubectl or simply you are making lots of releases?
These updates feel too repetitive and simply not necessary. This is what Keel solves: pluggable trigger system (webhooks, pubsub, polling) and pluggable provider system (Kubernetes, Helm).
Keel overview
Keel acts as a native Kubernetes service, main features:
- Runs silently and doesn’t require direct interactions from the user (users label deployments that are eligible for updates)
- Automatically creates topic & subscriptions for your GCR images (GCR uses pubsub instead of webhooks to notify regarding push/delete events in registry) so you don’t have to
- Accepts webhooks from DockerHub, Quay, JFrog (because not everyone runs on Google Cloud)
- Schedules regular image SHA digest checks if you don’t have access to webhooks (ie: repository is not yours) and scans for new tags
So, once you have deployed Keel in your Kubernetes cluster, the workflow looks like this:
- Tag a release in GitHub
- Cloudbuild/{insert your favorite builder here} starts building an image
- Keel gets new image event, looks for impacted deployments marked with keel update policy and starts rolling update
Easy! Sounds like a PaaS, right?
If you have any questions - you can often find me on k8s Slack channel: kubernetes.slack.com look for @karolis