Beware of Kubernetes Pets

If we’ve learned anything about IT over the past decades, it’s that it is wise to not get too attached to your IT. You might still get away with calling a server ‘Bowser’ and caring for it like a baby for years, but nowadays we know that it’s wiser not to get emotionally attached to technology. A helpful analogy is ‘Pets versus Cattle’. You name your Pet. You take care of it, and pamper it, and do your utmost to have a long and happy life with it. Cattle, however, is interchangeable. It is purely functional; if it no longer serves its intended purpose, it’s ripe for slaughter and ready to be replaced.

“ Nowadays we know that it’s wiser not to get emotionally attached to technology.”

It may sound a bit heartless, but think about it. We live in a world in which we want to scale up and move quickly. We do everything we can to be as flexible as possible, and to get there we use cloud and agile working methods, DevOps and CI/CD. Our whole work method has become strictly functional, which is essential, as otherwise we’d no longer see the wood for the trees.

No room for Pets

In this fast-paced, complex world there is no place for unique and indispensable: today we want interchangeable units of reliable and consistent quality. And if any changes need to be made to the setup, these changes need not be carried out manually on an individual server basis – instead a change should be made to the desired state, which in turn applies to each server. In setups like that, there is no place for servers we have named “Zeus”, “Trillian” or “Marvin”. You’ll get a lot more out of VM0011, which you can instantly exchange for VM2351, which in turn can be placed next to VM2847 without any hesitation because you know they’re identical.

If you’re working with containers, the Cattle philosophy is absolutely indispensable. In the world of containers there is no room for individual uniqueness. The value of containers lies in the fact that Kubernetes can be herded like cattle: the very fact of their interchangeability is what makes containers so valuable.

However, something strange is going on here. Everyone agrees on the importance of the desired state principles and the immutability of containers, but we often fail to or hardly apply these principles to the systems that manage container herds. Those Kubernetes clusters often turn into Pets again: we may use a blueprint to decorate them, but we end up making individual adjustments to them anyway. For example, in practice we see that different Kubernetes clusters are used for Production, Acceptance and Test – and that they are treated as Pets. That is precisely what we want to stop doing.

Working with Kubernetes means we have to think ahead. There are numerous reasons (such as edge computing) why we will use more and more K8s clusters in the future that we have to manage side by side. At the same time, we have to continue to guarantee security and compliance. Starting by treating our clusters as Cattle too is the foundation for this. There is no room for Pets in a future-proof IT infrastructure – even if the technology is still maturing.