This content originally appeared on DEV Community and was authored by Jution Candra Kirana
Master
The Master is the central controller responsible for managing all Nodes in the Kubernetes cluster. It consists of several components working together to orchestrate and manage applications in the form of containers.
ETCD
The first component is etcd, which can be thought of as the "heart" of Kubernetes. etcd serves as a database where all essential information about the cluster is stored. It keeps the configuration and status of applications and nodes in the cluster. If any changes occur, etcd logs them, ensuring that the system is always aware of what’s happening.
API Server
The second component is the API Server, which acts as the main gateway for communication with Kubernetes. All commands and interactions with the Kubernetes cluster go through the API Server. You can interact with Kubernetes via:
- Dashboard: A web-based interface.
- CLI (Command Line Interface): Such as kubectl to run commands.
- API: Allows other programs to control the cluster automatically.
The API Server processes commands, such as creating a pod or modifying configurations, and informs other components to execute the task.
Scheduler
The third component is the Scheduler, which is the "brain" responsible for deciding where a pod (the unit of containers running the application) should be placed in the cluster. The scheduler considers each node’s capacity, like CPU and memory usage, and selects the best node to run the pod.
Controller Manager
The fourth component is the Controller Manager, which ensures that the Kubernetes cluster functions as intended. For example, if a pod dies, the Controller Manager is responsible for creating a new one to ensure the application keeps running.
Node
Nodes are the computers or machines where the application containers are running. Each node has several crucial components that help run and monitor applications.
Container Runtime
The Container Runtime is the engine that runs the containers, such as Docker, containerd, or CRI-O. It is the container runtime that runs the application containers inside the pods. Kubernetes supports multiple container runtimes, enabling the flexibility to run applications inside containers.
Kubelet
The Kubelet is an agent running on every node. Its job is to ensure that all the pods scheduled by the scheduler are running properly on the node. Kubelet regularly checks the pods and reports their status back to the API Server. If there are issues, like a failed pod, Kubelet will either try to fix it or notify the master.
Kube-Proxy
Kube-Proxy is responsible for managing network traffic within the cluster. It ensures that the pods can communicate with each other, whether within the same node or across different nodes. Additionally, Kube-Proxy helps route traffic from outside the cluster to the correct pods.
Kubernetes Master-Node
| Worker Node 1 | Worker Node 2 | Worker Node 3 |
|---|---|---|
| Kubelet | Kubelet | Kubelet |
| Kube-Proxy | Kube-Proxy | Kube-Proxy |
| Container Runtime | Container Runtime | Container Runtime |
| Pods | Pods | Pods |
POD
Pod is the smallest unit in Kubernetes, where one pod can contain more than one container. Each pod has its own IP address, and pods are ephemeral. Ephemeral means that they are not permanent and can be recreated by Kubernetes if needed.
This content originally appeared on DEV Community and was authored by Jution Candra Kirana
Jution Candra Kirana | Sciencx (2024-10-18T04:14:20+00:00) Kubernetes: Architecture. Retrieved from https://www.scien.cx/2024/10/18/kubernetes-architecture/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.