If you want to deploy Kubernetes, there are multiple ways to go about it. You can take a DIY approach on different types of infrastructure. Or, you can opt for managed Kubernetes, a solution that simplifies the process considerably but comes with a set of trade-offs. To offer some guidance in choosing the best Kubernetes deployment mode, this article compares DIY approaches to managed Kubernetes, and explains the pros and cons of each strategy.
DIY Kubernetes Deployment
A DIY Kubernetes deployment is one that you set up and manage yourself.
The particulars of DIY Kubernetes can vary widely. You can deploy Kubernetes in this way using a variety of different distributions, including lightweight distributions, such as K3s and MicroK8s, as well as distributions intended for full-scale production use, like OpenShift and Tanzu. DIY Kubernetes can also be deployed on-premises or on cloud-based infrastructure where you provision and manage clusters yourself.
Because specific approaches to DIY Kubernetes vary widely, the amount of effort that a DIY Kubernetes deployment requires can vary widely, too. A lightweight distribution that you deploy to a cluster of virtual machines hosted on your local PC will be pretty easy to set up (although it won’t offer the production-level reliability and performance of a full-scale Kubernetes cluster). In contrast, setting up something like OpenShift by hand requires a significant amount of effort.
Managed Kubernetes Deployment
Because DIY Kubernetes can be difficult to implement for a production-grade environment, many organizations are now opting for so-called managed Kubernetes services.
At a high level, a managed Kubernetes service is any type of Kubernetes platform where at least some of the work required to set up, monitor and manage Kubernetes clusters is automated for you.
That said, there is considerable variation in the degree to which managed Kubernetes services are actually managed by their providers.
The major public cloud providers--including Amazon AWS, Google and Azure--all offer what they call managed Kubernetes services; however, their value lies mainly in the fact that clusters are automatically provisioned, and that they can be monitored using the basic dashboards included as part of their respective cloud platforms. They don’t provide more advanced management features such as technical support services or custom infrastructure setup.
In contrast, other vendors offer managed Kubernetes services that provide a deeper level of hand-holding and support at all stages of Kubernetes installation and management. For example, Canonical offers a managed Kubernetes service where the vendor does almost everything on behalf of users. Other vendors, such as Platform9, don’t go quite that far, but they do provide more sophisticated tools for provisioning and monitoring Kubernetes clusters than do the managed Kubernetes services running in public clouds.
In short, then, “managed Kubernetes” can mean a variety of different things. And, not surprisingly, the cost of managed Kubernetes is higher for more sophisticated types of managed services. Thus, although basic managed Kubernetes services like Amazon EKS or Azure AKS may seem like the best value, they provide considerably fewer features than a higher-cost service that comes with more automation and support.
Managed Kubernetes Platforms
The managed Kubernetes offerings on the market fall into three main categories:
- Kubernetes platforms from cloud providers that offer managed Kubernetes as one of their service offerings. Amazon EKS, Azure AKS and Digital Ocean’s managed Kubernetes are examples.
- Managed Kubernetes platforms from vendors that are not cloud providers, but that provide tools for managing Kubernetes clusters hosted on anyone else’s infrastructure. Platform9 and Rancher are examples.
- Kubernetes distribution providers that offer SaaS versions of their products hosted on their own infrastructure, such as OpenShift Online. These SaaS Kubernetes platforms are not the only ways to consume Kubernetes from these vendors, but they are one option.
DIY vs. Managed Kubernetes
Is managed Kubernetes better than a DIY solution? The answer obviously varies according to a variety of factors:
- Your team’s Kubernetes experience: If you already know Kubernetes well, and have experimented with lightweight clusters running in local environments, you are likelier to have the expertise necessary to pull off a DIY installation.
- The scale of your deployment: DIY Kubernetes is more feasible if you only have one smallish cluster (consisting of up to a couple dozen servers) than if you have a multi-cluster environment with many dozens of servers or more. In the latter case, the centralized management features of managed Kubernetes are more valuable.
- Which applications you are deploying: Many managed Kubernetes platforms integrate with app marketplaces from which you can deploy common applications in a few steps. This a powerful feature if the apps you need to deploy on Kubernetes are included in the marketplaces. But if you have custom apps that aren’t likely to be included, then managed Kubernetes platforms don’t add value in this respect.
- How much hand-holding you need: Do you want to be able to call professional support when a problem arises, which you can do with some managed Kubernetes platforms? Or are you comfortable using online communities and documentations to troubleshoot issues yourself?
- Kubernetes host infrastructure: Some managed Kubernetes offerings, like Rancher and Platform9, support clusters that are hosted on virtually any type of infrastructure, including private data centers and public clouds. If you don’t want to be locked into a single hosting provider, you should either choose one of these solutions or a DIY approach where you can deploy Kubernetes to an infrastructure of your choosing.
Conclusion
There are many ways to go about deploying and managing Kubernetes. Broadly speaking, the two main approaches are DIY Kubernetes and managed Kubernetes. However, within each of these categories, there is wide variation in terms of which specific processes, tools and value-adds are involved in different implementations.
