Kubectl allows communication with the API server and run commands on a Kubernetes cluster. Kubernetes comes with a set of tools that allow us to communicate with the API server and test a cluster. It also runs controllers that are specific to a cloud vendor. It receives requests from the API Server and performs specific actions, like creating an instance in AWS. cloud-controller-managerĬloud-controller-manager implements the logic and API of a cloud provider. The decision is made based on several criteria, like the resource requirements for the pod.
When a new pod is created, kube-scheduler decides which node should host it. It is a good idea to take regular backups of etcd data. etcdĮtcd contains all data used by a Kubernetes cluster. It is able to scale horizontally and to balance the load between its instances. The default implementation of the API Server is kube-apiserver. It is essential to coordinate Kubernetes components so that they react to node's change of state, and it allows the user to send commands. API ServerĪn API Server exposes API functions both internally and externally. The control plane consists of the following components.įor more information about the control plane, see Control Plane Components in Kubernetes documentation. Custom controllers are usually part of operators.įor more information, see Controllers in the Kubernetes documentation. This logic is specific to the way MariaDB works, and can only be implemented in a customer controller. For example, a MariaDB custom controller may want to check if replication is working by issuing SHOW REPLICA STATUS commands. It is possible to write custom controllers to perform checks that require knowledge about a specific technology. For example, if some nodes crashed, adding new nodes involves taking actions outside of the Kubernetes cluster, and controllers will have to do this themselves. Also, some actions cannot be performed via the Control Plane. However, this is not necessarily true for custom controllers. Most of the actions taken by the controllers user the API server in the Control Plane. Several types of controllers are needed to run a cluster. Each node type controls one or more resource types. When differences are found, controllers try to fix them. ControllersĬontrollers constantly check if there are differences between the pod's current state and their desired state. This was later deprecated, but Docker images can still be used using any container runtime. Originally, Kubernetes used Docker as a container runtime. More information about the Container Runtime Interface can be found on GitHub.
Container runtimes that meet this requisite are listed in the Container runtimes page in the Kubernetes documentation. Kubernetes manages the containers in a pod via a container runtime, or container manager, that supports the Kubernetes Container Runtime Interface (CRI). kube-proxy will receive the request and will redirect it to a running MariaDB container in the same pod. When an application needs to connect to MariaDB, it will connect to the MariaDB service. The main purpose of kube-proxy is to implement the concept of Kubernetes services. For example, an application server may need to connect to MariaDB, but the MariaDB IP will be different for every pod. Therefore, when we develop and deploy an application, we can't know in advance the IPs of the containers to which it will have to connect. In a typical Kubernetes cluster, several containers located in different pods need to connect to other containers, located in the same pods (for performance and fault tolerance reasons). It especially takes care that containers don't crash. It checks that the current state of the pods matches the desired state. Kubelet has a set of PodSpecs which describe the desired state of pods. Usually identical pods run on different nodes for fault tolerance.įor more details, see Nodes in the Kubernetes documentation.Įvery node must necessarily have the following components: All containers that run in the same pod are also located on the same node. A pod is a set of containers that run a Kubernetes workload or part of it. NodesĪ node is a system that is responsible to run one or more pods. The Control Plane provides an API that is used by the controllers.įor more information on Kubernetes architecture, see Concepts and Kubernetes Components in Kubernetes documentation. A Control Plane is a set of different components that store the cluster desired state and take decisions about the nodes.