Kubernetes is a great option in a project when we want high resilience, availability, and scalability.
Therefore, before starting to use it, it's important to know the main components that make up this technology and their responsibilities.
A Kubernetes cluster consists of a set of machines and each machine on the cluster can take on two roles, the control plane or the worker node.
Control plane
The control plane - it’s the orchestra conductor and it consists of:
- API server
- generate the endpoint communication
- it is through it that we communicate with the cluster
- ex: kubectl command
- Etcd
- key-value database
- store all data about the kubernetes cluster like data of the deploy, pod, node, service
- just the API server can access the etcd
- Kube scheduler
- receive the information of the container and determine in which worker node it will run on
- Kube controller manager
- all in Kubernetes works based in controllers and the controller manager is responsible for dealing with the different types of controllers like node controller, replica set, authorization controller, etc
Worker node
The worker node - executes the process and it consists of:
- Kubelet
- manage, supervise and ensure the execution of containers on the cluster
- communicate the API server about the states and health of the containers
- inside it has the container runtime which is responsible for executing the containers
- container runtime examples are docker and containerd
- Kube proxy
- network communication on cluster
Deployment, replica set and pods
The basic elements to execute the containers are deployment, replica set, and pods
- Deployment
- manage the actualizations of the versions
- create a new replica set to manage the new version, remove the deprecated pods and keep the old replica set for eventual rollback
- Replica set
- manage pods
- controller replica of the pods, if a pod die other is initialized and executed
- turn the application more resilient
- Pods
- the smallest object in the kubernetes cluster
- where the containers are executed
- one container in one pod is good cause we want scale parts of the application and only the container that needs to be scaled
- many containers in one pod are bad cause we do not want to scale all applications at once
- side car pattern - one main container and other with non-functional requirements like collect logs
Top comments (0)