So what exactly is Kubernetes? Kubernetes (also known as K8s) is open-source software for deploying, scaling and managing containerized applications.
As an automation solution, Kubernetes handles the work of deploying and managing the workloads to ensure they run as you intended.
Then where does Docker comes from?
Docker is a containerization platform, and Kubernetes is a container orchestrator for container platforms like Docker.
Docker = Container
Kubernetes = To Automate Containers ?
Just to keep things simple – consider the analogy of “VMWare Solution and Kubernetes”
Both are different products and have different offerings, but in case you have worked with VMWare suit or even Hyper-V, this will make things simpler.
In VMWare, we have a vCentre Server that manages VMWare ESXi hosts and these hosts are then responsible for managing./hosting the VM’s. In case you want to deploy a VM on host # 3, you login to the vCentre and do some magic (via UI or command line) and deploy whatever is needed (Simple?)
So, vCentre is basically the interface or the main contact point to interact with the VMWare hosts or the VM’s.
Coming on to Kubernetes, which is the next level of virtualization, we can assume a similar scenario.
The master can be your vCentre Server which is responsible for the management of the work nodes (think about ESXi hosts). So, in case you want to deploy a new worker node, you do it via the master node or you want to deploy a container (a docker container), you do it via master. Pretty similar to doing things via vCentre sever but not doing anything on vCentre server itself but on the hosts.
The concept of vCentre vs Kubernetes helps us to understand things easily, however, these are two different things that have completely different underlying technology.
So let’s get started with the Kubernetes Components:
Control Plane Components (Master Node)
- Api Server: Acts as frontend for Kubernetes – interaction via UI, command line etc. The API server is responsible for tasks like: Request Validation, Data Retrieval, Update ETCD, Scheduler, Authenticating Users and Kubelet.
- Etcd: Key-Value storage for cluster configuration. Consistent and highly available key value store used as Kubernetes’ backing store for all cluster data. If your Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for those data
- Scheduler: Managing containers across nodes. Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on. Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines
- Controller: Control plane component that runs controller processes. It’s the brain behind working of containers and acts accordingly. Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.
Node Components (Worker Node):
- Kubelet: An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod. Ensure that containers are running on nodes as expected.
- Container runtime: The container runtime is the software that is responsible for running containers. Like docker, rkt etc.
Pods:
- The smallest unit in Kubernetes.
- 1:1 relation with container
- The pod is a single instance of an application.
- Pod usually contains one application.
- Or may have more applications as well – like a helper container.
Additional components:
Replica Sets (old name: Replication Controller)
- Used for High Availability
- Used Load balancing and Scaling of pods.
Services:
- Help connecting apps with each other.
- Helps connect users externally with apps.
Service Types:
- Node Port (External Access to Apps)
- Cluster IP (Virtual IP of the cluster)
- Load Balancer. (Multiple Instances behind an LB – cloud concept)
Namespace:
- A way to segregate the environments.
- Help to isolate the services – Prod, Dev, Test etc.
- Switching can be done from the default namespace.
Scheduling:
- Allocate pods to nodes.
- Can be done manually by assigning the node name.
- The exiting pod can’t be assigned to the node.
Labels and Selectors:
- Labels are properties attached to each item.
- Group objects by type (pod, replica sets etc) or by application (app1, app2 etc)
- Definition file à Under metadata à create labels à add key-value paid
- Can also be used to connect services together (like pods attached to replica sets)
Taint and Tolerations:
- Taint can be used to specify what pods can be deployed on a specific node.
- Pods will accept the pods with certain tolerations.
- Specified by using key-value pair.
Node Selectors and Affinity
- To run a pod on a specific node.
- First, label the node and use that label in the definition file to deploy pod in specific node.
- Add a nodeSelector property in the specs section and then
- Selectors are limited to key-value pair – so affinity helps here to have “or” and “and” rules.
- Example for Affinity – to place the pod on either medium or small node.
Daemon Sets:
- Similar to Replica Sets
- DS ensure that one copy of pods is always available in all the available nodes.
- Uses cases – Monitoring solution or logging agent or kube proxy.