Keel : automate kubernetes workloads update

We have seen how to install our Node - Vue full-stack on a Kubernetes cluster with rancher and Docker Hub in previous articles. We then broached the subject of Let's Encrypt. This set is the right solution for low-cost scaling when launching a project, but it's time to put some DevOps in the middle of it all.

We will, therefore, see how to deliver a new version of a project via rancher automatically. From commit to deployment. Several solutions are available to us for this. I explored tw

Keel: Kubernetes Operator to automate Helm, DaemonSet, StatefulSet & Deployment updates.

Flux: The GitOps Kubernetes operator. Flux is a tool that automatically ensures that the state of a cluster matches the config in git. It uses an operator in the cluster to trigger deployments inside Kubernetes, which means you don't need a separate CD tool. It monitors all relevant image repositories, detects new images, triggers deployments and updates the desired running configuration based on that (and a configurable policy)

According to my tests and my understanding of these two tools, flow is more complete but more complicated to set up, the or keel will remain more limited but with simpler and faster handling. Our goal is always the reduction of 0 to 1 for the launch of projects/startups. We will introduce Keel in this article. I may do the same with Flux later.

We will, therefore, see how to automatically update a workload of our Node stacks on Kubernetes, via Keel. For example, I would also show how to automatically update a ghost blog.

Prerequisite

Everything we set up in the previous article :

• Rancher 2.0 & Kubernetes Cluster
• Kubectl and kube_config_cluster.yml
• Ndd A entry for keel

Install Keel

• Define namespace, user and password

kubectl apply -f https://sunstone.dev/keel\?namespace\=NAMESPACE\&username\=USER\&password\=PASSWORD\&tag\=latest 

This should be started, we will now start by setting up a persistent volume to keep a history and data.

• go in namespace  > workloads > keel > volumes > Add Volume

In my case, I use an existing persistent volume (claim) declared before.

We will now expose it via a load balancer. I do not know why but by default the load balancer installed for keel does not work for me, so we will delete it and put a new one in place.

• go in namespace  > workloads > keel > Port Mapping

• go in namespace  > Load Balancing > Add Ingress

Add a classic load balancer pointing to the workload. Refer to the previous article if you want to set up Let's Encrypt.

Everything should work fine.

Sometimes I have a problem with login, the loading bar remains blocked when this happens I delete the end of the URL and everything work.

The interface is simple, it consists of 4 parts :

• Dashboard: summary of workloads and actions carried out by keel
• Tracked images: list of workloads and configuration implemented on it
• Approvals: the history of approvals if you have implemented validation of deployments by slack for example
• Audit: the history of actions carried out by keel

Setup Keel on our Node stack

We will assume that you are using our stack node as part of a project. It is therefore a fork, in which you have created your own separate modules to keep the stack updates. You have therefore set up a private docker hub build to install workload like this. Now you want each build will be automatically deployed.

• Go in your private docker hub repo > Webhooks > Create one

Now with each successful build keel will be notified. This will trigger the workload update. We just have to configure Keel.

• go in namespace  > workloads
• click on options of workloads concerned and edit YAML
• add these lines in metadata.annotations :

metadata:
  annotations:
    keel.sh/approvals: "0"
    keel.sh/policy: force
    keel.sh/trigger: default

• approvals : all new build will be approved without any actions
• policy :

all: update whenever there is a version bump or a new prerelease created (ie: 1.0.0 -> 1.0.1-rc1)

major: update major & minor & patch versions

minor: update only minor & patch versions (ignores major)

patch: update only patch versions (ignores minor and major versions)

force: force update even if tag is not semver, ie: latest, optional label: keel.sh/match-tag=truewhich will enforce that only the same tag will trigger force update.

glob: use wildcards to match versions

• trigger: default webhook

If you now go to the keel interface, you should see this:

Everything should be ok, you just have to start a new build and check that everything works well :)

Setup Keel on external repo like Ghost

It's the same as for node except that we cannot add a hook to the docker-hub repo. So we are going to force a regular pull every day.

metadata:
  annotations:
    keel.sh/approvals: "0"
    keel.sh/policy: all
    keel.sh/pollSchedule: '@daily'
    keel.sh/trigger: poll

Hope to have helped you to take keel in hand! it is a real additional tool easy to integrate for a good saving of time. Having a good devops chain is a significant time saver. Even if the setup requires work, the ROI will be fast, both in time and in appeasement for the devs.