Kubernetes minikube kind

Goodbye minikube

I’ve been using minikube as my local cluster since I started to learn Kubernetes. But I’ve decided to let it go in favor of kind. Here’s the story. A couple of weeks ago, I gave my talk on Zero Downtime on Kubernetes. A demo is included in the talk, as with most of my presentations. While rehearsing in the morning, the demo worked, albeit slowly. Two days before that, I had another demo that also uses Kubernetes and it was already slow. But I didn’t take the hint. Duri

Kubernetes controller java GraalVM

Your own Kubernetes controller - Improving and deploying

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? As mentioned in the first post, there’s no re

Kubernetes controller java Fabric8 sidecar

Your own Kubernetes controller - Developing in Java

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. As a use-case, we will implement the sidecar pattern: every time a pod gets scheduled, a sidecar pod w

Kubernetes controller operator

Your own Kubernetes controller - Laying out the work

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. If you’ve been living under the monopoly of Microsoft on the deskt

Kubernetes container initialization configuration

The versatility of Kubernetes' initContainer

There are a lot of different ways to configure containers running on Kubernetes: Environment variablesConfig mapsVolumes shared across multiple podsArguments passed to scheduled podsetc. Those alternatives fit a specific context, with specific requirements. For example, none of them allow you to clone a Git repository before the container starts. It would be possible to design that feature into the image itself. Yet, that would introduce coupling, and defeat the Single Responsibility principl