»Always up-to-date - Dissecting A Kubernetes Upgrade«
2019-05-19, 16:35–17:05, Main Hall
The Cloud Native community pushes updates very frequently, sometimes for security reasons other times to deliver new features. This means we need to continuously upgrade Kubernetes and the related Cloud Native Stack.
Kubernetes has created a nice way to roll out new application versions, but what about the upgrade of the orchestrator itself, the core addons running on the cluster, or even the infrastructure holding it.
Thanks to running clusters for multiple customers all over the world Giant Swarm has created a system to roll out any piece of the infrastructure stack without impact to the customer’s workloads. Our approach is relying on a set of operators to gracefully control the entire process making it reliable and reproducible.
The audience will see the different decisions that have been taken and which problems have been faced over time.
Giant Swarm manages cloud infrastructure for enterprises. It means we are in charge of providing Kubernetes clusters to our customers, as well as managing them so they are always running and up to date.
Since Cloud Native environments are composed of a mixture of different components, people usually struggle to have everything up to date. In order to make it safe and robust, we have created a versioned system where all components of the platform are tracked under a bundle. It brings some benefits like immutability and testability.
A bundle is made of a list of components like the VM, underlying operative system, the Kubernetes release, container runtime, load balancers, VPC peerings, DNS server, etc. Every component defines the version and the changelog since the last occurrence.
Behind the curtain, a control plane in the form of a Kubernetes cluster holds a system of interconnected operators in charge of ensuring the desired state of the tenant clusters. A custom resource holds the entire configuration of the clusters including the version bundle. Every time there is a component(s) released we create a new bundle. After it is tested, it is promoted to the end user who can trigger the upgrade in her existing clusters.
As this approach is similar to upstream cluster API efforts, we believe that the community can benefit from our learnings after two years of building and running this architecture. The audience will see which decisions we made, and why using Kubernetes to manage Kubernetes clusters is a great approach in order to keep the clusters up to date in such a dynamic environment.