Managed Kubernetes Service

Setting up a simple cluster on an existing Linux server is not particularly complicated. You need to get a master node that acts as the control plane, and worker nodes where your actual cluster will run. Then you can use the official documentation to set up a basic cluster using the Kube API server, Kube proxy, and a Docker runtime. If you were in a development environment, you could go ahead and use something like Minikube to set up a one-node cluster with a single command. However, none of this will work with enterprise-level clusters due to several reasons. First of all, one of the biggest disadvantages of microservices is that there is a higher probability of a security breach, and companies go to the extent of hiring a full security team to handle that part alone. If you’re interested in seeing the amount of work that goes into securing clusters, head over to the Security101 section. However, even if you were a freelance developer creating a cluster for a small client, an on-prem cluster will still restrict you. If you have a database, you would need to configure data persistence and fault tolerance. You need to back up your own clusters, scale your clusters by adding servers, and do all the management of the cluster yourself.

On the other hand, a managed Kubernetes service does all this for you. First of all, let’s consider the master node.

In most managed Kubernetes services, the master node is completely handled by the service. This means that you won’t even see or note that the master node exists. It gets created when you create your worker nodes and run in the background with no interference from you. Also, in the case of services such as Microsoft’s AKS or Linode’s LKE, the master node is free. This means you no longer have to maintain the resources to run or manage this master node.

Secondly, when it comes to the worker nodes, you don’t have to bother with setting up the docker runtime, Kube-api server, Kube proxy, etc… You only have to specify how many worker nodes you want and how powerful they need to be via either the CLI or the cloud portal of the relevant service. You can also specify the region you want the nodes to be spun up in, meaning that you can spin up nodes close to your clients so that they have minimal latency. This is a huge advantage if your clients are in different regions in the world, meaning that you can start the clusters close to them which would not have been possible with an unmanaged Kubernetes service.

For all this, you don’t lose any power that running an ordinary Kubernetes service would provide you. You get to connect using kubectl as usual, and you get the full array of resources to deploy, such as deployments, services, PVCs, Ingresses, etc… It is a lot easier in terms of hardware requirements as well. For instance, take data persistence. Kubernetes does not manage storage for you, and you will have to configure it yourself. You need to have a disk and make it available for the cluster, after which you have to create a PV before attaching the volume to the database. On the other hand, Linode, for example, which has its own storage in the cloud that is readily available to you, has the Linode storage class, which does all this for you.

When we consider Ingress, you would generally have to set up the ingress on your cluster manually and configure routing rules so that incoming requests would be able to reach the appropriate services. You also have to think of how you can handle high ingress/egress levels, load balancing strategies, etc… On the other hand, cloud providers usually have their own advanced load balancer that stands in front of your cluster’s entry point, thereby balancing the load by itself. Setting up SSL certification is equally easy since each cloud provider has its own, easily configurable certificate management tool.

Another major point is the flexibility you get to move between cloud providers. While some cloud providers have their own specific way of doing things and related resources, the actual function remains the same. This means that if, for example, your cluster went down due to an attack, you could have the entire cluster up and running in a completely different cloud provider that the attacker would be unable to predict. This is something that you cannot do if you managed all your clusters on-premise.

The next major advantage is integration. Let’s take Microsoft AKS. Microsoft also has a bunch of other services such as Azure DevOps which allows you to run pipelines on the cloud. You could then integrate those pipelines to your AKS cluster so that you have a CI/CD pipeline. Of course, you can also do this with any other cluster/pipeline scenarios, including on-premise clusters and servers running Jenkins pipelines. However, this level of integration is easy to set up, and very useful for start-ups that have a very fast release cadence.

Automation is yet another thing that managed Kubernetes clusters provide. If you were to set up your own cluster, then it would get set up in a specific way that vendors of automation software such as Terraform are unable to predict how their application would hook into your cluster. However, cloud providers have built-in support for these automation tools. For example, connecting Terraform to Azure has a detailed process that can be followed.

Finally, there is a whole bunch of things that managed Kubernetes services simply do better. You can get a cluster up and running within around 5 minutes, regardless of the platform you use. This is because these platforms have been custom built around cluster speed, and streamline things such as provisioning the master nodes, creating resources, and applying configurations. These would be things that, if done manually, could take hours. Depending on the cloud platform you are using, you could even ssh into your worker nodes to get the individual logs that these worker nodes have. This is because the worker nodes are essentially VMs (EKS uses EC2 instances, and LKE uses their compute VMs), meaning that you don’t have a loss of functionality over your unmanaged Kubernetes service.

So those are all good reasons for you to start using managed Kubernetes services. But if managed Kubernetes services are so great, then why would anyone want to use an unmanaged service? Well, if you were an individual developer or a small startup, then it would not make sense. You would be able to get clusters up and running in the same way a large organization would, for a fraction of the price. However, if you are part of a large organization, it may actually save the organization to have their own clusters running on their own hardware. While being locked on to one vendor is not necessarily a problem for a start-up, large organizations have to be able to switch between cloud vendors depending on several factors, including their client base, services offered, and price. Having additional clusters on the premise also means that they have the hardware they are fully in control of. Since these companies don’t have an issue with hiring entire teams to manage this hardware for them, this is a valid option. Finally, while small developers save money by only paying for what they use, large organisations use a lot, meaning that they pay the cloud providers a lot. They can actually save money by moving some of the workloads onto their on-premise servers.

Nevertheless, you would hardly be able to find any organizations, large or small, that don’t use managed Kubernetes services to at least a small extent. Now, let’s move on to discussing various managed Kubernetes services in detail. You may choose which section to jump to depending on your preference for Kubernetes service.

Next: Linode Kubernetes Engine OR Next: Amazon Elastic Kubernetes Service OR Next: Azure Kubernetes Service