Learn about the Kubernetes architecture, and see its different pieces, including etcd, the API server, scheduler, and nodes.
- [Instructor] Let's take a look at the entire Kubernetes Cluster Architecture. As you can tell, its got a lot of boxes, and even more arrows. Let's break this down and build it back up. First up, we have the Master Node. This guy is responsible for the overall management of the Kubernetes Cluster. Its got three components that take care of communication, scheduling, and controllers. These are the API Server, Scheduler, and Cluster Manager. The Kube API Server, as the name states, allows you to interact with the Kubernetes API.
It's the front end of the Kubernetes control plane. Next up, we have the Scheduler. The Scheduler watches created Pods, who do not have a Node design yet, and designs the Pod to run on a specific Node. The Controller Manager runs controllers. These are background threads that run tasks in a cluster. The controller actually has a bunch of different roles, but that's all compiled into a single binary. The roles include, the Node Controller, who's responsible for the worker states, the Replication Controller, which is responsible for maintaining the correct number of Pods for the replicated controllers, the End-Point Controller, which joins services and Pods together.
Service account and token controllers that handle access management. Finally, there's that CD, which is a simple distributed key value stored. Kubernetes uses etcd as its database and stores all cluster data here. Some of the information that might be stored, is job scheduling info, Pod details, stage information, etc. And, that's the Master Node. You interact with the Master Node using the Kubectl application, which is the command line interface for Kubernetes. Kubectl is also also called Kubectl, in some instances, but I'm going to say Kubectl for the rest of the course.
Kubectl has a config file called a Kubeconfig. This file has server information, as well as authentication information to access the API Server. We wouldn't get anywhere without Worker Nodes, though. These Worker Nodes are the Nodes where your applications operate. The Worker Nodes communicate back with the Master Node. Communication to a Worker Node is handled by the Kubelet Process. It's an agent that communicates with the API Server to see if Pods have been designed to the Nodes. It executes Pod containers via the container engine.
It mounts and runs Pod volume and secrets. And finally, is aware of Pod of Node states and responds back to the Master. It's safe to say that if the Kubelet isn't working correctly on the Worker Node, you're going to have issues. As I mentioned before, Kubernetes is an container orchestrator, so the expectation is that you have a container native platform running on your Worker Nodes. This is where Docker comes in and works together with Kubelet to run containers on the Node. You could use alternate container platforms, as well, like (mumbles), but not a lot of folks do this anymore.
The next process I'll talk about is the Kube-proxy. This process is the Network Proxy and load balancer for the service, on a single Worker Node. It handles the network routing for TCP and UDP Packets, and performs connection forwarding. Alright, we're in homestretch. Having the Docker Demon allows you to run containers. Containers of an application are tightly coupled together in a Pod. By definition, a Pod is the smallest unit that can be scheduled as a deployment in Kubernetes. This group of containers share storage, Linux name space, IP addresses, amongst other things.
They're also call located and share resources that are always scheduled together. Once Pods have been deployed, and are running, the Kubelet process communicates with the Pods to check on state and health, and the Kube-proxy routes any packets to the Pods from other resources that might be wanting to communicate with them. Worker Nodes can be exposed to the internet via load balancer. And, traffic coming into the Nodes is also handled by the Kube-proxy, which is how an End-user ends up talking to a Kubernetes application. That's the entire Kubernetes architecture.
We'll go into more detail on these components in the coming section. But, from a high level, you know how everything works together.
- What is containerization?
- Kubernetes features
- Clusters, nodes, and pods
- Deployments, jobs, and services
- Getting an application up and running
- Working with labels
- Handling application upgrades
- Dealing with configuration data
- Running jobs
- Production deployments
- Monitoring and logging
- Security in Kubernetes