Master Node
Responsible for the overall management of Kubernetes clusters. It has three components that take care of communication, scheduling, and controllers. These are:
- The API Server
- Scheduler
- Controller Manager
API Server
Allows you to interact with the Kubernetes API its the front end of the Kubernetes control plane.
Scheduler
The scheduler watches created Pods that do not have a Node design yet and designs the Pod run on a specific node
Controller Manager
The controller Manager runs controllers. These are background threads that run tasks in a cluster. The controller actually has a bunch of different roles that are compiled into a single binary. The roles of a controller include:
Node Controller- that is responsible for the worker states.
Replication controller — That is responsible for maintaining the correct number of Pods for replicated controllers.
End-Point Controller — which joins services and Pods together.
Service Account and token Conrillers — handle access management.
etcd
This is a distributed key-value stored. Kubernetes uses etcd as its Achicturedatabase and stores all cluster data here. Some of the information are job scheduling info, Pod details, stage information among others.
Kubectl
You interact with the master node using kubectl application which is the command-line interface for Kubernetes. The kubectl has a config file called a kubeconfig.
kubeconfig
This file has server information as well as authentication information to access the API server.
Worker nodes
These worker Nodes are the Nodes where your application operates. The worker Nodes communicate back with the Master Node.
Node
The node serves as a worker machine in a K8s cluster. One important thing to note is that node can be a physical computer or a virtual machine.
Node Requirements:
- A kubelet running
- Container tooling like Docker
- A Kube-proxy process running
- Supervisord
Kubelet
The kubelet handles communication with a worker node. It’s the agent that communicates with the API server to see if pods have been assigned to the Nodes.
Kubelet tasks:
- It’s executed Pod containers via the container engine.
- It’s mounted and runs pod volume and secrets.
- It’s aware of the Pod of Node states and responses back to the master
If the kubelet is not working correctly on the worker Node issues would arise.
Docker
This is the container-native working within Kubernetes kubelet to run a container on the node. You can use alternate container platforms as well as LXC, Meso, rklet. But it’s not popular among DevOps.
Kube-proxy
This is the network proxy and load balancer for service, on a single Worker Node. It handles the networking routing for TCP and UDP packets and performs connection forwarding.
Three Modes of Kube-proxy
- Userspace mode
- Iptables mode
- Ipvs mode(alpha feature )
Kube-proxy tasks:
- process what runs on all worker nodes.
- Reflect services as defined on each node, and can do simple network steam or round-robin forwarding across a set of backends.
- Service cluster IPS and ports are currently found through Docker—link compatible environment variables specifying ports opened by the service proxy.
Pod
Containers of application are tightly coupled together in a Pod. The Pod is the smallest unit that can be scheduled as deployment in Kubernetes. You can create, deploy, and delete pods, and it represents one running process on your cluster. This group of containers shares storage Linux namespace, IP address, amongst other things. They’re also co-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 Pod from other resources that might be wanting to communicate with them.
Pod Requirements:
- Your Docker application container
- Storage resource
- Unique network IP
- Options that govern how the container(s) should run
Character of Pods
- Ephemeral, disposable, and immutable
- Never self-heal, and not restarted by the scheduler by itself
- Never create pods just by themselves
- Always use higher-level construct
Pod States
Pending — pod has been accepted by the Kubernetes system but the container has not been created yet.
Running — Where pod has been scheduled on a Node and all of its containers are created and least one container is running.
Succeded -Which means that all the containers in the pod have exited with an exit stat of zero. Which indicates successful execution and will not be restarted.
Failed — All containers in the pod have exited and at least one container has failed and returned a non-zero exit status
CrashLoopBackOff -This is where a container fails to start for some reason and Kubernetes tries multiple times to restart the Pod.
Note: don’t use pod directly use a controller
Internet
Work nodes can be exposed to the internet via Kube-proxy. Traffic coming into the Node is also handled by the Kube-proxy which is how an end-user ends up taking to the application.
Recommendation
If your using Kubernetes in production, it is typically recommended to have at least a three-node cluster.
