This is the 6th post in the Start Rust focus series. To teach myself Kubernetes in general and controllers in particular, I previously developed one in Java. This week, I decide to do the same in Rust by following the same steps I did. The guiding principle is the creation of a Kubernetes controller that watches pods' lifecycle and 'binds' a sidecar to them. When the main pod is scheduled, the controller schedules the sidecar; when it’s deleted, it deletes it as well.

In the first post of this series, we described the concept behind a Kubernetes controller. In short, it’s just a plain control loop that reconciles the desired state of the cluster with its current state. In the second post, we implemented a sidecar controller in Java. This third and last post will be focused on where to deploy this Java controller and how to improve it to be on par with a Go one. Running outside the cluster or inside?

In the previous post, we laid out the foundations to create our own custom Kubernetes controller. We detailed what a controller was, and that its only requirement is to be able to communicate with HTTP/JSON. In this post, we are going to finally start developing it. The technology stack can be Python, NodeJS or Ruby. Because this blog is named 'A Java Geek', it’s normal to choose Java.

It’s hard nowadays to ignore Kubernetes. It has become the ubiquitous platform of choice to deploy containerized applications. In a few years, Kubernetes has entrenched itself deeply in the DevOps landscape under the tutelage of the Cloud Native Computing Foundation. One could speculate about the reasons. IMHO, one very compelling argument is that it allows users to be independent of the API of a single cloud provider.