Go to file
Karolis Rusenas b7d614562c trigger name 2017-06-14 23:04:30 +01:00
hack cleanup, changed keel.io to keel.observer 2017-06-11 23:33:14 +01:00
provider deploying multiple images in single deployment 2017-06-14 19:15:17 +01:00
trigger added dockerhub trigger 2017-06-14 23:04:18 +01:00
types trigger name 2017-06-14 23:04:30 +01:00
util/version name getter 2017-06-11 11:29:48 +01:00
vendor updated vendor deps 2017-06-14 18:10:45 +01:00
.gitignore cleanup 2017-06-11 22:52:51 +01:00
Dockerfile multi stage dockerfile 2017-06-14 18:09:24 +01:00
LICENSE license, readme 2017-06-11 23:44:13 +01:00
Makefile license, readme 2017-06-11 23:44:13 +01:00
glide.lock removed context from vendor 2017-06-11 23:32:50 +01:00
glide.yaml k8s tests 2017-06-14 18:09:40 +01:00
main.go updated struct name 2017-06-14 20:03:37 +01:00
readme.md updated struct name 2017-06-14 20:03:37 +01:00

readme.md

Keel - automated Kubernetes deployments for the rest of us

Lightweight (uses ~10MB RAM when running) Kubernetes controller for automating deployment updates when new image is available. Keel uses semantic versioning to determine whether deployment needs an update or not. Currently keel has several types of triggers:

Upcomming integrations:

  • DockerHub webhooks

Keel overview

  • Stateless, runs as a single container in kube-system namespace
  • Automatically detects images that you have in your Kubernetes environment and configures relevant Google Cloud pubsub topic, subscriptions.
  • Updates deployment if you have set Keel policy and newer image is available.

Why?

I have built Keel since I have a relatively small Golang project which doesn't use a lot of memory and introducing an antique, heavy weight CI solution with lots dependencies seemed like a terrible idea.

You should consider using Keel if:

  • You don't want your "Continous Delivery" tool to consume more resources than your actual deployment does.
  • You are not Netflix, Google, Amazon, {insert big company here} that already has something like Spinnaker that has too many dependencies such as "JDK8, Redis, Cassandra, Packer".
  • You want simple, automated Kubernetes deployment updates.

Getting started

Keel operates as a background service, you don't need to interact with it directly, just add labels to your deployments.

Example deployment

Here is an example deployment which specifies that keel should always update image if a new version is available:

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata: 
  name: wd
  namespace: default
  labels: 
      name: "wd"
      keel.observer/policy: all
spec:
  replicas: 1
  template:
    metadata:
      name: wd
      labels:
        app: wd        

    spec:
      containers:                    
        - image: karolisr/webhook-demo:0.0.2
          imagePullPolicy: Always            
          name: wd
          command: ["/bin/webhook-demo"]
          ports:
            - containerPort: 8090       
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8090
            initialDelaySeconds: 30
            timeoutSeconds: 10
          securityContext:
            privileged: true      

Available policy options:

  • all - update whenever there is a version bump
  • major - update major versions
  • minor - update only minor versions (ignores major)
  • patch - update only patch versions (ignores minor and major versions)

Deployment

Step 1: GCE Kubernetes + GCR pubsub configuration

Since access to pubsub is required in GCE Kubernetes - your cluster node pools need to have permissions. If you are creating new cluster - just enable pubsub from the start. If you have existing cluster - currently the only way is create new node-pool through the gcloud CLI (more info in the docs:

gcloud container node-pools create new-pool --cluster CLUSTER_NAME --scopes https://www.googleapis.com/auth/pubsub

Step 2: Kubernetes

Keel will be updating deployments, let's create a new service account in kube-system namespace:

kubectl create serviceaccount keel --namespace=kube-system

Now, edit deployment file that is supplied with the repository (basically point to the newest Keel release and set your PROJECT_ID to the actual project ID that you have):

kubectl create -f hack/deployment.yml

Once Keel is deployed in your Kubernetes cluster - it occasionally scans your current deployments and looks for ones that have label keel.observer/policy. It then checks whether appropriate subscriptions and topics are set for GCR registries, if not - auto-creates them.