Kubernetes – We’ve all heard of it – It orchestrates our docker containers, it’s the next big thing that will run all our software more flexibly, sharing hardware more effectively than virtual machines, but when it comes down to it, unless you want to run on someone else’s cluster (which may not play nicely with corporately sensitive data, personally identifiable information privacy etc), then suddenly there’s very little help. How, exactly, do you install a “standard” build? Or even a “non-standard” build? What is “standard” anyway? Once you have your cluster, what then? How do you run applications? How do you make them available? What happens when they aren’t available? How do you scale out – that’s a big feature of Kubernetes but it’s not always obvious how to make use of it, or even what it means in the context of a given workload?
I can’t promise to answer every question that might be asked about Kubernetes here, but I intend to try to give the pointers to as many answers as I can, and a flavour of what running resource constrained Kubernetes is actually like and how it could just be the answer you didn’t know you were looking for.
And there we have the rub – Hardware costs money, whether it is physical hardware that you have to buy, pay for rack space, power and connectivity for, or virtual hardware that is provided to you by a cloud services provider (Like Rackspace, Amazon Web Services, Google Cloud Platform, Microsoft Azure or any of the many others that are springing up), it all costs money, and the more you need, the more it costs. That’s all pretty simple and obvious, right, but what if you could make the hardware work harder for you? Or even what if you could get the same work from less hardware? After all, every employer wants more “efficiency” (which tends to equate to “get more from less”), and every company wants to have the flexibility to grow without the pain of finding large sums of money to do so.
So that’s where I’m coming from in this book – Less is definitely more!
My aim is to demonstrate that Kubernetes doesn’t mean six figure hosting budgets, that scale doesn’t equate to hardware upgrades, and that enterprise doesn’t mean server. This last point is perhaps a stretch for some, especially CTO’s who know that buying the latest range of enterprise server kit from their company’s preferred supplier is how they provide performance, security and reliability guarantees, but what if that wasn’t the only answer?
In this second edition I include information about some of the changes in Kubernetes 1.26 that might otherwise come as a surprise to you.