Welcome to our next video. In this video, we're going to take a look at different Kubernetes distributions. In our previous video, we took a look at the problems that Kubernetes solves, and at this point, you might think about the discrete. Let's try to install this Kubernetes. If you search for Kubernetes, you might find that there are actually many different Kubernetes versions. You might come across OpenShift, which is a version of Kubernetes. You might come across the Google Container Engine, which is Kubernetes deployed on the Google Cloud. You might come across Amazon EKS, which is again Kubernetes deployed on the Amazon cloud as well as something like VMWare Tanzu or Rancher, Kubernetes by open source. Then we might also come across something like minikube, which is Kubernetes that you can deploy on your local machine, right on your laptop. Docker Kubernetes, CodeReady Containers, etc., etc. This poses a question, why is there so many different versions of Kubernetes? The answer is quite simple. There are different distributions of Kubernetes that have different mindsets and they solve slightly different problems. They provide slightly different feature sets. We look at Kubernetes and we pose a question of do we want to, for example, run it on-premise or do we want to use Kubernetes as a service in the Cloud? If we want to run Kubernetes on-prem, which means that I download Kubernetes from somebody, for example, from Red Hat and I want to install it on my local data center at work. That means that I can't do that with Amazon EKS, for example. Amazon EKS runs in the Amazon cloud. If I want to install Amazon EKS in my data center, well, I'm out of luck. I can only do that with certain distributions of Kubernetes such as Red Hat OpenShift. Well, it turns out that Red Hat OpenShift also provides OpenShift Dedicated, which if you don't like that, if you don't want to install OpenShift on your local data center, you want to use OpenShift from the Cloud, well, you can use something like OpenShift Dedicated or if you want to use Kubernetes from the Cloud, you can use something like Google Cloud Engine. That means that you get username and password and OpenShift just works. It's in the Cloud and you just pay monthly as you go. All of these solutions are aimed at big scale. What this means is these are production-ready solutions. What we want to do throughout this course is essentially small-scale. These are learning solutions and in essence, for our learning purposes, all we need is a single cluster Kubernetes. At home, we probably don't have a three-node cluster or five node cluster and so for that, all we need is for example something like minikube or CodeReady Containers. However, we also have a small scale on small-scale Kubernetes as a service solution, which is the Developer Sandbox. That's OpenShift in the Cloud where you don't have to install anything locally. You only get your username and password and OpenShift works and it is free, but it is small-scale you cannot rely on it for your production purposes. Let me clean this up. One thing that you will notice if you actually work with Kubernetes and you start researching all of these distributions is that they work slightly differently. For example, Amazon EKS might work slightly differently from the Amazon Container Engine. The reason for that is that these distributions might have different philosophy about how some certain operations should work or better yet, something like Amazon EKS might work differently from OpenShift Dedicated. What we wanted to do is take a look at some of the OpenShift extensions and see how they differ between different Kubernetes distributions. Again, I encourage you to download the PDF, grab it, take a look, read through this for yourself. I'll skip quite a few of these. I'll focus on just a few for now. I definitely wanted to focus on the DNS extension. I wanted to focus on this because the DNS extension is very similar throughout a number of the Kubernetes distributions. The reason for that is that the DNS extension is Core through the Kubernetes platform. Let me back up a little. When we talk about DNS, what do we mean? DNS, essentially. The role of DNS is name resolution. When you enter something like example.com, what the DNS does is translate that domain name resolution, example.com, to IP address. For example, when we want to reach www.example.com DNS translates that to 1, 1, 1, 1, which is IPv for address. This functionality is extremely essential to the whole Kubernetes cluster. Therefore, the Kubernetes community centralize on CoreDNS as the DNS provider and a number of Kubernetes distributions use CoreDNS as the DNS provider. Well, this is where a lot of the similarities end. Dashboard for example, just very briefly, dashboard is the graphical user interface to Kubernetes. Kubernetes is part of this specialization. We will not use the graphical user interface. For OpenShift, we will. But I would definitely encourage you, if you are interested to enable this extension, for minikube for example, well, minikube uses the dashboard extension. OpenShift uses the console extension, which looks very different, feels very different, offers a very different functionality. Same with Ingress. Ingress is the way that you get traffic into your Kubernetes cluster. External traffic into your Kubernetes cluster. Well, upstream Kubernetes distributions use different controllers for the Ingress extension. For example, minikube uses a minikube add on, is based on the Ingress NGINX controller whereas the OpenShift distribution uses an Ingress controller based on HAProxy, and it's controlled by the ingress operator. Again, the functionality is the same. The implementation differs. Storage, again, very different. OpenShift offers something that is called Red Hat OpenShift Data Foundation, whereas, for example, minikube offers something that is called storage provisioner add-on and we also have the storage provisioner GlusterFS add-on. Authentication and authorization, huge difference. One thing that I would definitely note here and one of the main differences between, for example, Red Hat OpenShift and Kubernetes, is that when you deploy your minikube cluster, what you get is an administrator account on your minikube. With this minikube cluster, you can do whatever you wish, whereas on OpenShift, your OpenShift cluster has a number of security restrictions. If you spawn, for example, your own OpenShift cluster, by default, this OpenShift cluster cannot run workloads that require administrator privileges, so containers that run as administrators. The mindset behind this decision is that these workloads are potentially dangerous. You, as the administrator user, can change that. If you wish to, you should, but by default, you shouldn't. Of course, if you run on the Developer Sandbox or if you use the Developer Sandbox, then you are not an administrator user at all, you're just a regular user, and then you are even more limited because you can't change a number of things. Last but not least, operators are a bit of an advanced topic, advanced subject on minikube. Operators are not enabled at all. Operators are essentially custom controllers that control an additional functionality within Kubernetes. On minikube they are not enabled by default. OpenShift relies on operator for a lot of it's functionality. Just to recap the DNS. The DNS is core to Kubernetes, and so that's why, for example, the minikube as well as the Red Hat Developer Sandbox and OpenShift both use the CoreDNS provider. But this is where the similarities end. For all of the other Kubernetes' features, it seems like the end functionality is similar, but the implementation differs. This was just an introduction to various distributions of Kubernetes and the comparison and contrast of those. Let's take a look at how we can actually install and use our Kubernetes on our local machine.
