Updated: Jan 6, 2020
At Quortex, we install our solution on a Kubernetes cluster. OK, but what does that mean in concrete terms?
The architecture of the Quortex solution is composed of micro-services, each of these micro-services is composed of a set of Kubernetes resources in order to define the configuration, the secrets, the deployments of the applications, the way of exposing their APIs ...
These resources are traditionally described in yaml manifest files in order to interact with the APIs of Kubernetes. Anyone that has tried to manage Kubernetes resources manually knows that this can be very painful to write, share and maintain … We have lots of micro-services in our solution and this can easily turns into hundreds of Yaml Kubernetes files ...
From this postulate we wanted to answer two problems.
The kubernetes resources will necessarily differ according to several parameters, environment, client needs, the cluster on which the application will be deployed (and its cloud provider).
How to describe these resources while keeping them configurable?How to manage the life cycle of these resources, deployment, updates, history management, rollback ?
At Quortex, we chose Helm (and more particularly helm 3, just available in production). Helm3 brings in some new very interesting features compared to Helm2:
Tiller, the server-side component of Helm2, has been removed: this removes the need for an additional daemon-set running on the cluster
Helm now takes into account potential “manual” modifications of the cluster before applying any operations. You can now “kubectl edit” your deployments made with Helm, and still be able to update/rollback. This is what is called “3-way merge patches”
Greatly improved chart re-usability with “Library Chart”. These charts do not generate any release artefacts on their own, but can be shared with other charts, avoiding code duplication and redundancy. We make extensive use of such library charts!
Some more info can be found on the helm3 FAQ: https://helm.sh/docs/faq/#changes-since-helm-2
Helm is a tool that could be described as a package manager for Kubernetes.
It uses a packaging format called Charts which are a collection of files that describe a related set of Kubernetes resources.
It provides templates which, combined with values, will generate Kubernetes manifest files.
This allows us to define the structure common to all of our micro-services and to overload the singular values for each of these bricks.
We have therefore developed our Quortex chart. Let's see how we can override its default values during installation.
Here is an example of values provided by a yaml file to setup a micro-service configuration like app version, ingress rules, secrets reference required to pull application image or resources required for this micro-service.
Here we install a release called quortex of the quortex chart version 0.11.0 in a previously created quortex namespace (yes, that's a lot of quortex).
For this we override the values used by the chart, these values being either listed in files in yaml format and passed via the values flags, or individually via the set flag (for values we don't want to version such as secrets).
OK, great, but now that we have successfully deployed our chart on the cluster, let's say that we want to integrate the super features brought by a new version.
Very simple, use the helm upgrade command ... uh wait, I would like to be able to visualize the changes brought by this new version to be sure not to break the existing one.
Helm supports adding third-party plugins. Among those available we use diff, this one allows you to visualize the changes brought by an upgrade.
Everything seems ok… so let's upgrade it!
This upgrade went well, let's look at the release history, we are seeing a new revision of our release.
Well, finally this revision did not go so well (it obviously never happens, it's just for the exercise).
Let's rollback on the previous version !
To finish the exercise, let's delete the release !
Helm is now the preferred way to deploy our application on a kubernetes cluster. This helps us to maintain consistency in the structure of our different micro-services, allows us to deploy more reliably and therefore more frequently.
Vincent Marguerie, Devops Architect at Quortex