Now that we know what Kubernetes is, let’s see what options we have to create our own Kubernetes cluster.
Rolling your own
When you write software rather than use an existing off the shelf product, you define its form and functionality. The same goes for infrastructure: when you build it from the ground up, you gain a better understanding of how the parts fit.
Kubernetes’ managed services are a relatively new option when it comes to provisioning a Kubernetes cluster, but they have stemmed from customers needs. Setting up Kubernetes from scratch is not easy. In the introduction, you’ll recall there are a lot of moving parts.
To get a feel for the level of complexity we’ll cite Kelsey Hightower’s now legendary “Kubernetes The Hard Way” tutorial for creating a non-production Kubernetes cluster. The tutorial consists of lab sessions whose topics range from:
- Setting up client tools to create your cluster
- Provision the network resources i.e. VPCs, firewalls and public IP address
- Provision compute instances
- Provisioning Certificates to facilitate secure comms between clients and the
- clusters. Also, most services that form the cluster will also need their own certificates
- Bootstrapping services and servers in the cluster
The chances are that you may know several of these areas extremely well, but not all of them.
Can you afford to take on the risk of knowledge gaps in Production?
There is help in the form of Kubernetes Operations (kops) which is a tool created by the Kubernetes group to provision and maintain Production grade Kubernetes clusters. There are some caveats to consider.
Firstly the tool level of complexity varies between providers, in order of easiness:
- Setup state storage (required by kops)
- Provision your cluster through kops
- Set up an IAM user
- Choose a DNS strategy (there are at least four options to choose from)
- Setup state storage (required by kops)
- Provisioning your cluster through kops
- Prepare local environment
- Create and customise cluster configuration
- Build the cluster
Whilst this automates the provisioning and maintenance of Kubernetes clusters, you’re still accountable for all the moving parts that we mentioned earlier.
If you’re still interested in learning the ins and outs, there is a reward for this effort, by passing an exam to become a Certified Kubernetes Administrator (CKA). If your organisation has three CKAs and have met additional requirements you can apply to become Kubernetes Certified Service Provider.
Just like other managed services (databases, DNS, mail, etc) we can also free ourselves from the implementation details and on-going maintenance of a Kubernetes cluster.
The big three cloud vendors (AWS, Azure and Google) all have their own Kubernetes managed service offerings:
- Amazon Elastic Container Service for Kubernetes (Amazon EKS)
- Azure Kubernetes Service (AKS)
- Google Kubernetes Engine (GKE)
Given the number of smaller cloud vendors who are also providing their own managed service, it would be fair to say that this is a good opportunity for vendors to upsell computing power and services.
With the process of provisioning a managed Kubernetes cluster being very similar between the main cloud providers, it can be hard to know when to choose one over another.
The most obvious decision is to stick with your existing cloud vendor if you already have an existing infrastructure in place.
Beyond this, there are a few differentiators between the vendors and their managed service offerings:
- If you need specialised computing power (machine learning, high-performance computing, etc) then both AWS and Google’s can provide GPU capability.
- If there’s software that can only run on the Windows platform, Azure can provide a virtual node where Windows specific workloads can be allocated against. This same technology can also be used to provide a node that has burstable capacity rather than have to recreate the cluster with higher specification nodes.
- If you’re interested in evaluating new ARM-based servers, then AWS can provide clusters based around their new A1 ec2 instances.
Whilst there are a lot of compelling reasons to use a managed service, there are of course some detractors
- Your Kubernetes cluster will be provisioned utilising services (compute instances, storage, load balancers, security groups, routers, etc) provided by your cloud vendor rather than the “best of breed” in the industry.
- Whilst it looks like most offerings are similar, you may find hidden costs, in particular, some cloud vendors will in addition to the infrastructure required to provision the cluster, will also charge you for running the cluster.
We’ve given a brief introduction to Kubernetes, the components that make it up and also the two routes you can choose to provision a Kubernetes cluster.
We’ve highlighted the pros and cons of both approaches.
Finally, we have this simple guidance:
- If you want cloud portability, use Kubernetes full stop.
- If you have the time (to set up and maintain) and inclination to gain a deeper understanding: build it yourself.
- If you don’t have the time, don’t want a larger area of responsibility or need specialised workloads: go with a managed service.