The pods are run here, so the worker node contains all the necessary services to manage the networking between the containers, communicate with the master node, and assign resources to the containers scheduled. Other examples of controllers are endpoints controller, namespace controller, and serviceaccounts controller, but we will not dive into details here. The replication factor is configured by the user, and it's the controller’s responsibility to recreate a failed pod or remove an extra-scheduled one. controller-manager is a daemon embedding those.Ī controller uses apiserver to watch the shared state of the cluster and makes corrective changes to the current state to change it to the desired one.Īn example of such a controller is the Replication controller, which takes care of the number of pods in the system. Optionally you can run different kinds of controllers inside the master node. The scheduler has the information regarding resources available on the members of the cluster, as well as the ones required for the configured service to run and hence is able to decide where to deploy a specific service. The deployment of configured pods and services onto the nodes happens thanks to the scheduler component. It provides a REST API for CRUD operations as well as an interface to register watchers on specific nodes, which enables a reliable way to notify the rest of the cluster about configuration changes.Īn example of data stored by Kubernetes in etcd is jobs being scheduled, created and deployed, pod/service details and state, namespaces and replication information, etc. It’s mainly used for shared configuration and service discovery. etcd storageĮtcd is a simple, distributed, consistent key-value store. The result state has to be persisted somewhere, and that brings us to the next component of the master node. It processes the REST requests, validates them, and executes the bound business logic. The API server is the entry points for all the REST commands used to control the cluster. Let's dive into each of the components of the master node. The master node is the one taking care of orchestrating the worker nodes, where the actual services are running. This is the entry point of all administrative tasks. The master node is responsible for the management of Kubernetes cluster. Let’s have a look into each of the component’s responsibilities. This is a high-level diagram of the architecture Kubernetes componentsĪ K8s setup consists of several parts, some of them optional, some mandatory for the whole system to function. This is where you can configure load balancing for your numerous pods and expose them via a service.
Hence K8s has introduced the concept of a service, which is an abstraction on top of a number of pods, typically requiring to run a proxy on top, for other services to communicate with it via a Virtual IP address.
Imagine a typical Frontend communication with Backend services. This could make the communication of microservices hard. ServiceĪs pods have a short lifetime, there is not guarantee about the IP address they are served on. They are created, destroyed and re-created on demand, based on the state of the server and the service itself. These are co-located, hence share resources and are always scheduled together. This group of containers would share storage, Linux namespaces, cgroups, IP addresses. This group, the smallest unit that can be scheduled to be deployed through K8s is called a pod. Often those microservices are tightly coupled forming a group of containers that would typically, in a non-containerized setup run together on one server. Kubernetes targets the management of elastic applications that consist of multiple microservices communicating with each other. Glossaryīefore we dive into setting up the components, you should get comfortable with some Kubernetes glossary. We will then have them all installed using the docker container provided as a playground by K8s team, and review the components deployed. In this article, we will look into the moving parts of Kubernetes – what are the key elements, what are they responsible for and what is the typical usage of them. Google has given a combined solution for that which is Kubernetes, or how it’s shortly called – K8s. Nearly all applications nowadays need to have answers for things like One still needs to take care of scheduling the deployment of a certain number of containers to a specific node, managing networking between the containers, following the resource allocation, moving them around as they grow and much more. However, the more granular the application is, the more components it consists of and hence requires some sort of management for those. Containerisation has brought a lot of flexibility for developers in terms of managing the deployment of the applications.
0 kommentar(er)
