Skip to content

Latest commit

 

History

History
68 lines (44 loc) · 7.18 KB

day50.md

File metadata and controls

68 lines (44 loc) · 7.18 KB
Raw

Choosing your Kubernetes platform

I wanted to use this session to breakdown some of the platforms or maybe distributions is a better term to use here, one thing that has been a challenge in the Kubernetes world is removing complexity.

Kubernetes the hard way walks through how to build out from nothing to a full blown functional Kubernetes cluster, obviously this is to the extreme but more and more at least the people I am speaking to are wanting to remove that complexity and run a managed Kubernetes cluster. The issue there is that it costs more money but the benefits could be if you use a managed service do you really need to know the underpinning node architecture and what is happening from a Control Plane node point of view when generally you do not have access to this.

Then we have the local development distributions that enable us to use our own systems and run a local version of Kubernetes so developers can have the full working environment to run their apps in the platform they are intended for.

The general basis of all of these concepts is that they are all a flavour of Kubernetes which means we should be able to freely migrate and move our workloads where we need them to suit our requirements.

A lot of our choice will also depend on what investments have been made. I mentioned the developer experience as well but some of those local Kubernetes environments that run our laptops are great for getting to grips with the technology without spending any money.

Bare-Metal Clusters

An option for many could be running your Linux OS straight onto a number of physical servers to create our cluster, it could also be Windows but I have not heard much about the adoption rate around Windows, Containers and Kubernetes. Obviously if you are a business and you have made a CAPEX decision to buy your physical servers then this might be the way in which you go when building out your Kubernetes cluster, the management and admin side here means you are going to have to build yourself and manage everything from the ground up.

Virtualisation

Regardless of test and learning environments or enterprise ready Kubernetes clusters virtualisation is a great way to go, typically the ability to spin up virtual machines to act as your nodes and then cluster those together. You have the underpinning architecture, effciency and speed of virtualisation as well as leveraging that existing spend. VMware for example offers a great solution for both Virtual Machines and Kubernetes in various different flavours.

My first ever Kubernetes cluster was build based on Virtualisation using Microsoft Hyper-V on an old server that I had which was capable of running a few VMs as my nodes.

Local Desktop options

There are a number of options when it comes to running a local Kubernetes cluster on your desktop or laptop. This as previously said gives developers the ability to see what their app will look like without having to have multiple costly or complex clusters. Personally this has been one that I have used a lot and in particular I have been using minikube. It has some great functionality and add ons which changes the way you get something up and running.

Kubernetes Managed Services

I have mentioned virtualisation, and this can be achieved with hypervisors locally but we know from previous sections we could also leverage VMs in the public cloud to act as our nodes. What I am talking about here with Kubernetes managed services are the offerings we see from the large hyperscalers but also from MSPs removing layers of management and control away from the end user, this could be removing the control plane from the end user this is what happens with Amazon EKS, Microsoft AKS and Google Kubernetes Engine. (GKE)

Overwhelming choice

I mean choice is great but there is a point where things become overwhelming and this is really not an depth look into all options within each catagory listed above. On top of the above we also have OpenShift which is from Red Hat and this option can really be ran across the options above in all the major cloud providers and probably today gives the best overall useability to the admins regardless where clusters are deployed.

So where do you start from your learning perspective, as I said I started with the virtualisation route but that was because I had access to a physical server which I could use for the purpose, I appreciate and in fact since then I no longer have this option.

My actual advice now would be to use Minikube as a first option or Kind (Kubernetes in Docker) but Minikube gives us some additional benefits which almost abstracts the complexity out as we can just use add ons and get things built out really quickly and we can then blow it away when we are finished, we can run multiple clusters, we can run it almost anywhere, cross platform and hardware agnostic.

I have been through a bit of a journey with my learning around Kubernetes so I am going to leave the platform choice and specifics here to list out the options that i have tried to give me a better understanding around Kubernetes the platform and where it can run. What I might do with the below blog posts is take another look at these update them and bring them more into here vs them being links to blog posts.

What we will cover in the series on Kubernetes

  • Kubernetes Architecture
  • Kubectl Commands
  • Kubernetes YAML
  • Kubernetes Ingress
  • Kubernetes Services
  • Helm Package Manager
  • Persistant Storage
  • Stateful Apps

Resources

See you on Day 51