Managed Kubernetes: 3 Things to Know
The adoption of Kubernetes continues to increase across small businesses all the way up to large enterprises, and as it does so, the idea of managed Kubernetes service becomes more and more attractive to folks. In this article, I’ll describe what a managed service gets you and talk a bit about what you’ll need above and beyond what the managed services provide. The things that are not part of a managed Kubernetes offering I’ll call “fully managed”—this means managed either by your in-house engineering team or an external third party.
Let’s dive in..
Kubernetes Is the Foundation, Not the Platform
First of all, Kubernetes is not the platform your infrastructure is built on; Kubernetes is the foundation that you will use to build your platform.
The cloud providers offering managed Kubernetes (GKE, EKS, or AKS) can sell you that foundation, but a foundation alone is not a full house—you still need walls, floors, electrical, finishings, etc., to create a functional dwelling. So why do these providers offer just the foundation? Part of the reason is that for a long time, the problem of just standing up Kubernetes clusters was extremely difficult. Thanks to these services that is no longer the case; nowadays, anyone can stand up a cluster with just a few clicks. The problem is, where do you go from there? How do you take that foundation and build it into a platform your whole company can leverage?
The answer is, you probably need some help. Most companies find they need guidance on everything from where to put their clusters (what regions or availability zones) to how many clusters they should have. While the typical managed Kubernetes offering gets you from an empty plot of land to a poured and solid foundation in a hurry, a fully managed offering asks how big your family is, what color walls you want and where to put the kitchen—so it can help you build out the rest to a move-in-ready abode.
Everything Is Ephemeral, Even the Cluster
Everything about Kubernetes is a new paradigm for how to think about cloud infrastructure. It’s a shift to APIs for everything and away from having to worry about individual servers—this is why it’s so beloved by so many engineers. But because it’s such a paradigm shift, it’s also a world that very few have deep experience with.
In this new world, everything is ephemeral—something that must be considered all the way down to the cluster level. I’ve talked with organizations that were able to get to a comfortable configuration over a few months only to find out they had no way to upgrade what they had in place and were incapable of tearing it down to be replaced with a new version. This new world means you should document everything as code (infrastructure as code) with the assumption that it will have to be re-created at some point (preferably easily). This ephemerality seems like a minor issue until there is a notable security risk found and an update is essential for business continuity.
The decisions you make today about where and how to build require expertise and hard-learned experience that the cloud managed services do not provide. These best practices for what to build above and beyond the foundation start with engineering everything for ephemerality.
Configuration As Far As the Eye Can See
In the cloud world ephemerality is king because it’s no longer about maintaining long-running servers, it’s about simplifying everything down to an API. In a sense, interacting with the infrastructure is like calling a function in code (something engineers are very familiar with). When engineers have an API with Kubernetes that makes sense to them and workflows for deployments that they can understand, they can own the services they build all the way through to production. The old way of shipping software required an operations team to take a service and ship it through to production, making sure it was up and running. We’ve moved away from this paradigm with the shift to DevOps culture. But the wrong configuration with Kubernetes can add enough complexity to require you to maintain that old paradigm.
Getting configuration right requires considering how different environments will be set up, how namespaces will be divided, and how services will communicate with and discover one another. You’ll need security at the VPC level, cluster level and pod level. Consider what networking needs you have that the default CNI might not support and make sure you have an upgrade and DR plan.
Finally, your team (or a fully managed Kubernetes offering) needs to ensure you have the right plugins to manage automatic TLS certificates, DNS, monitoring, logging, authorization and more. The right add-ons above and beyond vanilla Kubernetes make a huge difference in ease of management—and your on-call engineers will thank you for getting this right.
There is a difference between a great framework for infrastructure (managed Kubernetes), and a fully built Kubernetes-based customized PaaS (fully managed Kubernetes). If you want to build the necessary expertise in-house, you can do that, but if you are like most people, you’ll want some help with the details of getting everything move-in-ready before relaxing on the sofa and kicking off your shoes.