As you saw earlier, containers allow you to break up applications into modules with hardware, software, and operating system requirements. You can run them on the same or even different machines and start and stop them quickly, but you can't specify how many machines or containers to keep running, what to do if they fail, or how to connect them to other containers and persistent storage? For that, you need a container orchestration system like Kubernetes. Kubernetes adds the ability to define how many machines to run, how many containers to deploy, how to scale them, where persistent disks reside, and how to deploy a group of containers as a unit. In this module, you'll learn how to set up and use Kubernetes and Container Engine to manage a set of machines and containers, and group them into services for hosting real world applications. Kubernetes Basics: Clusters, nodes, and pods. So, let's give you a 10,000-foot view of Kubernetes itself. You have the users on the left hand side, then you have this master cluster server. Kubernetes and the way it really runs and Dockers and containers, it's in a cluster environment. And then you have all these nodes out there which are running kubelets. The kubelet is a Kubernetes agent itself. And the master, what it does it controls all the jobs, it controls the scheduling, it controls the etcd, the apiserver itself. Just to be very clear. Kubernetes is an open source orchestrator for a container environment. And what does it really do? What does it provide those developer? So, developers only really care about access to the API. That's all they really care. And Kubernetes and containers provide them that access to that open API so they can program. And like I said, a cluster is a set of computers that works as an instance that manages all these nodes. Everything is managed by Kubernetes which is an orchestrator again. And really if you get to the meat of the matter, Kubernetes manages jobs. It knows how to delegate these jobs to these multiple nodes and this is a better example of a real Kubernetes ecosystem. It's not usually one, two, or three nodes, it's thousands of nodes and many multiple masters. But the whole beauty of the system is, it knows how to allocate jobs to these nodes, which are free on resources, or remove the task from nodes, which are high on resources. So, let's talk about a pod. A pod is analogous to a VM, sort of, in a group of containers sharing a network and storage that are separated from the nodes themselves. Underneath, you have the OS, you have the hardware, you have the NIC, you have an IP outside, inside you have the pod, and then inside the pod, you have the actual containers, and then the network interfaces for the containers. You can define a pod with a YAML file. Here's an example. It'll give you the version of the YAML file, it gave you the metadata, the name is going to be my-app, the containers, the images, it'll tell you what image it's going to use, and then obviously how you're going to access that containerPort 80 and port 443. You'll upload the YAML file to the master cluster server, and then it will create pods on the nodes that you have dedicated within the YAML file. A pod is composed of several parts. For example, number one, the API version, the pod resource, the pod name, also two containers, and then finally, the frontend. What's it going to use? What application will it be running? And then, the ports that application will be running on. The deployment also ensures that N pods are running in a cluster at any given time. Basically, automatic fail over. If anything happens, if any one of the pod goes down, Kubernetes has the ability to spin up another pod and replace it. You could define in a YAML file also how many replicas you want. You could identify the pods, the rolls, also the labels, and labels are important. We'll talk about those later on in the course, but also, what is it. Container equals pod. Again, you upload the new YAML file and upload the master, the master then schedules and decides. Remember, the master is running Kubernetes. It is deciding these jobs and these tasks when they're going to be run. So, scheduling it depending on the master and depending on the workload and everything else happening, including CPU utilization.
