Keel

Keel aims to be a simple, robust, background service that automatically updates Kubernetes workloads so users can focus on important things like writing code, testing and admiring their creation.

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 is you:

• update image tag in deployment.yaml
• run kubectl apply -f deployment.yaml
• These updates can be repetitive, lacking control (user needs access to the cluster) and simply not necessary. This is what Keel solves: pluggable trigger system
• (webhooks, pubsub, polling) and pluggable provider system (Kubernetes, Helm).

Keel provides several key features:

• Kubernetes and Helm providers – Keel has direct integrations with Kubernetes and Helm.
• No CLI/API – tired of ***ctl for everything? Keel doesn’t have one. Gets job done through labels, annotations, charts.
• Semver policies – specify update policy for each deployment/Helm release individually.
• Automatic Google Container Registry configuration – Keel automatically sets up topic and subscriptions for your deployment images by periodically scanning your
  environment.
• Native, DockerHub and Quay webhooks support – once webhook is received impacted deployments will be identified and updated.
• Polling – when webhooks and pubsub aren’t available – Keel can still be useful by checking Docker Registry for new tags (if current tag is semver) or same tag SHA
  digest change (ie: latest).
• Notifications – out of the box Keel has Slack and standard webhook notifications, more info here

Note: For now Keel gets installed into kube-system namespace by default as where Helm’s Tiller is installed.

Overview

Keel acts as a native Kubernetes service, main features:

• Runs silently and doesn’t1 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 (this triggers CI to build a new image).
• Cloudbuild/{insert your favorite builder here} starts building an image and pushes to the image registry.
• Keel gets new image event, looks for impacted deployments marked with keel update policy and starts rolling update.