GoogleContainerTools' distroless base images are often mentioned as one of the ways to produce small(er), fast(er), and secure(r) containers. But what are these distroless images, really? Why are they needed? What's the difference between a container built from a distroless base and a container built from scratch? Let's take a deeper look.
"How to start programming in Go and for Kubernetes?" - the question I often get from fellow DevOps people. This is a tricky one. And I don't have a universal answer to it. However, I do have some thoughts to share.
But first, let me tell you my own story.
In my case, it was rather an evolutionary step - I'd been developing software for almost 10 years by the time I started coding for Kubernetes. I'd also been (sporadically) using Go for some of my server-side projects since probably 2015. And around 2019, I started my transition to, first, SRE and, then, Platform Engineering. So, when I decided to get my hands dirty with Kubernetes controllers, it was just a matter of joining the right team and picking up the Kubernetes domain. Luckily, I had a good candidate on my radar, and that required just an internal transition from one team to another.
However, based on my observations, for many contemporary DevOps engineers, the direction of the desired transformation is often inverse. From Ops to Dev (preferably, for Ops).
Since your background and experience may vary, instead of giving a concrete piece of advice here, I'll try to explain how I'd approach the problem given different levels of proficiency with the technologies.
A short one today. Just wanted you to meet my new favorite Go library to work with Kubernetes - k8s.io/cli-runtime. It's probably the most underappreciated package in the whole k8s.io/* family based on its value to the number of stars ratio.
Here is what the README file says about it:
Set of helpers for creating kubectl commands, as well as kubectl plugins. This library is a shared dependency for clients to work with Kubernetes API infrastructure which allows to maintain kubectl compatible behavior.
If the above description didn't sound too impressive, let me try to decipher it for you - with the cli-runtime library, you can write CLI tools that behave like and are as potent as the mighty kubectl!
Here is what you actually can achieve with just a few lines of code using the cli-runtime library:
--kubeconfig|--context|--namespace|--server|--token|... and pass their values to one or more client-go instances.deploy for deployments or po for pods.Interested? Then have a look at the usage examples below 😉
I strive to produce concise but readable code. One of my favorite tactics - minimizing the number of local variables - usually can be achieved through minting or discovering higher-level abstractions and joining them together in a more or less declarative way.
Thus, when writing Go code, I often utilize io.Reader and io.Writer interfaces and the related io machinery. A function like io.Copy(w io.Writer, r io.Reader) can be a perfect example of such a higher-level abstraction - it's a succinct at devtime and efficient at runtime way to move some bytes from the origin r to the destination w.
But conciseness often comes at a price, especially in the case of I/O handling - getting a sneak peek at the data that's being passed around becomes much trickier in the code that relies on the Reader and Writer abstractions.
So, is there an easy way to see the data that comes out of readers or goes into writers without a significant code restructure or an introduction of temporary variables?
The official Kubernetes Go client comes loaded with high-level abstractions - Clientset, Informers, Cache, Scheme, Discovery, oh my! When I tried to use it without learning the moving parts first, I ran into an overwhelming amount of new concepts. It was an unpleasant experience, but more importantly, it worsened my ability to make informed decisions in the code.
So, I decided to unravel client-go for myself by taking a thorough look at its components.
But where to start? Before dissecting client-go itself, it's probably a good idea to understand its two main dependencies - k8s.io/api and k8s.io/apimachinery modules. It'll simplify the main task, but that's not the only benefit. These two modules were factored out for a reason - they can be used not only by clients but also on the server-side or by any other piece of software dealing with Kubernetes objects.
