Kubernetes: The architecture
This article will introduce Kubernetes’s architectures that include components and definitions in Kubernetes to help you more comprehend Kubernetes.
1. Kubernetes Processes
There is a set of Kubernetes core processes that make up the cluster. Cluster is divided into Master components (also known as Control Plane) and Node components (called Worker Nodes or Minion before).
Note: Since Kubernetes 1.14 there is a feature that allows adding more Masters to the Cluster at the alpha stage, contributing to higher availability of the Master (Control Plane) when initializing the Kubernetes Cluster using the kubeadm engine.
1.1. Master components
kube-apiserver plays a role as an API Server, provides access to Kubernetes API, where Kubernetes Resources are published.
kube-controller-manager is a process of running controllers to handle Cluster’s background tasks and help align the cluster to the declare in Resource.
kube-scheduler is responsible for allocating Pods at Nodes based on certain criteria, the criteria can be resource availability, how resources are required, workload policies, etc.
cloud-controller-manager runs controllers to communicate with default cloud services providers, such as Google Cloud, Azure, AWS, or Digital Ocean.
etcd is a distributed key-value store. etcd in a Kubernetes Cluster is quite important, it is compared to the heart of Kubernetes Cluster, all Cluster data is stored here (it's like a database of Kubernetes Master). So to be safe, we should always have a backup plan for etcd when running a Kubernetes Cluster.
1.2. Node components
kubelet runs on each node and is responsible for managing the Pods on that node, including connecting to the container runtime (eg Docker) to create and manage the containers in the Pod. It also communicates with the Master via API.
kube-proxy helps to route connections to Pods correctly, it also performs load balancing on Pods.
2. Kubernetes: Core concepts
2.1. Label and Selector
Label is one of the most basic Kubernetes concepts. Label is a key-value pair attached to a Kubernetes Resource. Each Kubernetes Resource can have one or more labels. Label serves as a means to identify a particular Resource or set of Resources.
Label Selectors are also key-value pairs. They are used to select a certain label or a set of labels. Under this mechanism, a Resource type can select one or more Resources of another type. Label is also used with kubectl to query certain types of resources.
2.2. Types of Kubernetes Resources
The resource is a high-level abstraction that contains the declarative state for an infrastructure component. Resources in Kubernetes are published to the kube-apiserver and it is the responsibility of the Kubernetes Controllers to put the cluster in the correct states.
There are many different types of Resources in Kubernetes, a full list of Resources can be found in the Kubernetes API documentation. The following sections introduce only the important Resource types.
2.2.1. Resource group Workloads in Kubernetes
The Pod is the smallest and basic unit of execution in Kubernetes. Pods can have one or more containers. The following image illustrates the 3 types of containers a Pod can have:
|Types of containers||
|Application||This is the core container of an application, a Pod must have this type of container, common Pod models usually only have application containers.|
|Sidecar||Pods can have containers of the Sidecar that do some useful work to support application containers. Containers of this type often take on roles such as collecting logs or acting as a reverse proxy. One Pod can have multiple Sidecar containers.|
|Init||Sometimes it is necessary to do some initialization before launching the application container, for example initializing the database. A Pod can have many Init containers, which are run one by one in order.|
Like other Resource types, Pods can also have Labels and these Labels are used by other Resources to allow the management of Pods.
B. Deployment and ReplicaSet
Deployment in Kubernetes allows managing the lifecycle of Pods and an associated Resource called a ReplicaSet. The Deployment contains the specification for a Pod and additional information, such as the number of Pods to run. If you need to run a stateless app that will run continuously, like an HTTP Server, you definitely need Deployment.
Deployment in Kubernetes allows updating a running application without downtime. Deployment also specifies a strategy to restart Pods when they die or crash.
The ReplicaSet is created when the Deployment is created or modified and actually the ReplicaSet is used as the definition to create the Pod.
A DaemonSet in Kubernetes ensures that a Pod running on all or a small set of Kubernetes Nodes is ready. As soon as a new Node is added to the Kubernetes Cluster, the Pod will be added immediately.
As soon as the Node is removed from the Kubernetes Cluster, the associated Pod is also collected by the garbage collector. Deleting a DaemonSet will delete all the Pods it has created.
Examples of DaemonSet use cases in Kubernetes:
- Run cluster storage daemons like glusterd or ceph on each node.
- Run log collector daemon on each node like fluentd or logstash.
- Run monitoring daemon on each node like Prometheus Node Exporter or Datadog agent.
In Kubernetes, a StatefulSet manages a collection of Pods for deployment and scaling, a StatefulSet provides guarantees about the ordering and uniqueness of the Pods it manages. Regarding the order, it guarantees the order in which Pods are created and deleted. Regarding uniqueness, it guarantees uniqueness of the name of the Pod and the separate storage volume attached to the Pod.
StatefulSet use cases in practice are often found in distributed database clusters based on cluster members having their own names and associated data that must be created separately at the cluster member's boostrap. ElasticSearch is a prime example.
In Kubernetes, a Job creates one or more Pods ensuring that at least a certain number of them run to completion. Unlike ReplicaSet, once the process in the container completes successfully, the container will not be restarted. Use Job in Kubernetes when you want to run a process once.
In Kubernetes, CronJob simply runs the Job on a predefined schedule, formatting a predefined schedule in the format of Cron on Linux.
Note: The appointment time is calculated according to the Master time where the Job is started.
2.2.2. Resource Pool Discovery and Load Balancing in Kubernetes
In Kubernetes, Service is used to group one or more Pods using Label Selector. Service provides ClusterIP and DNS Name for Pods.
The Kube Proxy process uses the information contained in the Service to configure the appropriate iptables rules on each Node so that client traffic that needs to access the Service is routed to the correct Pod.
Ingress is used to configure the Ingress Controller so that the Service can be accessed from outside the Cluster, usually via the HTTP protocol. Ingress also offers Load Balancing, SSL termination and virtual hosting in a name-based format.
The Ingress Controller is a reverse proxy that monitors Ingress Resource continuously through the Kubernetes API Server and configures the appropriate rule for each Ingress.
2.2.3. Resource groups Config, Storage and Cluster in Kubernetes
ConfigMap allows saving config files independently and independent of the container image. Files saved with ConfigMap can be mounted to the container in the Pod at runtime.
Secret allows storing sensitive information such as passwords, tokens, keys. Similar to ConfigMap, however Secret is accessible as an environment variable.
C. Volume, PersistentVolume và PersistentVolumeClaim
Trong Kubernetes, Volume là một thư mục có thể chứa dữ liệu. Volume là một thành phần của Pod và không độc lập với nó. Một Volume được tạo trong đặc tả của Pod. Một Volume không thể tự xóa. Một Volume được truy cập bởi tất cả các container trong Pod. Mỗi container mà muốn truy cập vào Volume phải mount riêng lẻ.
In Kubernetes, a Volume is a directory that can hold data. Volume is a component of the Pod and is not independent of it. A Volume is created in the Pod specification, accessed by all containers in the Pod, and can't be deleted by itself. Each container that wants to access the Volume must mount it individually.
A Kubernetes Volume lasts longer than any container, but when the attached Pod is lost, the Volume is lost as well. However, files of some types of Volumes continue to exist in local or cloud storage, even after the Volume is gone.
Kubernetes Volumes have more functionality than Docker Volumes. Volumes can provide access to local disk storage or cloud storage. A Pod can use a combination of them at the same time. Volumes in Kubernetes include empty directories, Node's filesystem or cloud service provider-specific storage such as awsEleasticBlockStore or gcePersistentDisk for long-term storage, which can be found here.
To help abstract away the infrastructure details, the Kubernetes developers created PersistentVolume and PersistentVolumeClaim. Unfortunately, the name is a bit misleading, because pure volumes can still have persistent storage. PersisententVolume (PV) and PersisentVolumeClaims (PVC) add complexity compared to just using pure Volume. However, PV is useful for managing storage resources for large projects.
With PV, Kubernetes users still use Volumes, but first there are two steps:
- A PersistentVolume is provided by the Cluster Admin (or it is dynamically provisioned).
- An individual Cluster user who needs to host the Pod creates a PersistentVolumeClaim manifest. It specifies the amount and type of storage they need. Kubernetes then finds and reserves the required capacity.
Then the user creates a Pod with a Volume using PVC. PersistentVolume has a lifecycle independent of any Pod. In fact, the Pod doesn't even know about PV, just PVC. PVC consumes PV resources, similar to how Pods consume Node.
NameSpace is where we put it all together. A NameSpace can be thought of like an environment. Collections of Resources can be deployed to NameSpace to form a group of related components.
An example of using NameSpace might be to create a DEV environment or to share a set of services used by other NameSpaces, e.g. Ingress Controller.
If you are considering offshore development, please feel free to contact us.
※Here is our contact information.
Account Manager: Quan (Japanese/English available)
Phone number: (+84) 2462 900 388
Please feel free to contact us for consultation/application by phone.