Kubernetes is an open-source platform with features like resource maximization, automatic deployment process and updation, auto-scaling, self-healing, automated rollbacks and rollouts, and container orchestrators load balancing, and service discovery, auto-restart, auto-placement, and auto-replication, etc. Kubernetes is not only a container orchestrator; it is also an OS for cloud-based applications.
It is like a platform for running an application similar to other applications that run on Windows, MacOS, or Linux with greater flexibility. It reduces the load of orchestrating and allows developers to completely focus on container-centric workflows for the purpose of the self-service operation. Developers have the advantage of a very high- level automation in deployment and application management. It can be integrated with any environment to enhance capabilities.
Kubernetes architecture consists of layers: Higher and lower layers. In this individual, physical or virtual machines are brought together into a cluster. A shared network is used for communication between each server. Kubernetes has one master (at least) acting as a control plane, a distributed storage system. The multiple cluster nodes are also known as Kubelets.
- The master of Kubernetes, control plane, schedules the deployments, exposes the API and manages the overall Kubernetes cluster.
- The cluster node runs a container runtime, agent for communicating with the master, and other monitoring components, logging, etc.
The Kubernetes architecture and Kubernetes components are illustrated in the image below.
Let’s have a look at the Kubernetes components.
Master: Kubernetes Control Plane
The master maintains the data of every object in Kubernetes. As it manages the whole cluster, hence it is called as Master. It controls object states, maintains the matching of the system’s real state with the required state, responds to changes, etc.
It contains the following three important components:
- Kube- API server: Kubernetes API server
- Kube- Scheduler: Pod scheduling in worker nodes
- Kube- Controller: Manages pod replication
If there are multiple master nodes, then these components are replicated across all master nodes.
The lifecycle orchestration for various applications that include updates, scaling, etc. are done by API Server. It works as a gateway for the clients that are not within the cluster. The API server does the authentication. It also acts like an intermediary to pods and nodes.
The Controller performs the following tasks:
- Running the core control loops
- Making changes for driving status towards the required state.
- Watching the cluster state
It also offers routing, storage services, load balancing, DNS network services, VM instances by integrating into public clouds. The different controllers that drive state for autoscaling, nodes, services and pods, namespaces.
The container scheduling throughout the nodes is done by Scheduler within the cluster; considering different resource limitations/guarantees, or anti-affinity/affinity specifications.
The Kubernetes Control Plane taxonomy is shown below:
Cluster Nodes: Kubelets
Kubelets are different machines that are responsible for running containers. The master does the management of cluster nodes. It is also called Minion. The cluster nodes are considered as the primary controller of Kubernetes. It drives Docker, the execution layer of containers.
It contains the following components:
- Pod: Group of containers
- Docker: Container-based technology, user space of OS
- Kubelet: Container agents that are responsible for maintaining the set of pods.
- Kube-proxy: Routes traffic coming into a node from the service.
The Kubernetes Cluster Node taxonomy is shown below:
Pods and Services
Pods are an important concept in Kubernetes with which developers interact. It represents the running process. It can host application stacks that are vertically-integrated such as WordPress LAMP applications. Given below are different pod types:
|ReplicaSet||Simple Pod type
Ensures the running of fixed pods
|Deployment||A declarative way pod management via ReplicaSet
Rolling updates and rollback mechanisms are included.
|StatefulSet||Manages pods that should persist|
|Daemonset||Ensures each node runs a pod instance.
Manages cluster services such as log forwarding and health monitoring.
|CronJob and Job||Runs jobs that are short-lived as a scheduler|
A pod can consist of a number of containers and external volumes. The taxonomy of pod is shown in the below diagram:
Services do the tracking of Pods. For defining pod and service associations, selectors or labels are used instead of IP address assignments. This simplifies the addition of pods to service and releasing of new versions. Following are the different service types:
|ClusterIP||Default Type; Exposes the service on an internal IP and makes the service reachable|
|NodePort||Allows developers to set up their own load balancers|
|LoadBalancer||Automates their configuration|
|ExternalName||Commonly used for creating service within Kubernetes.|
The typical cloud deployment used is the LoadBalancer type. Kubernetes supports the abstraction of high-level Ingress to solve complexity. Users can display different services within the same IP address by making the use of the same load balancers.
Mostly CNI (Container Network Interface) is used for obscuring the basic network. Calico, a fully-routed option, can also be used. In both options, the communication is done on a cluster-wide pod network and controlled by Calico or Flannel (CNI provider). Containers can communicate within a pod over the localhost without any restriction. Movement from external sources to services or pods to services is done via Kube-proxy.
A directory having some data is referred to as Volumes in Kubernetes. The directories are accessible to pods. There are many storage types in Kubernetes. Containers within the pod can consume any storage. The public cloud services such as NFS, Amazon Elastic Block Store, Iscsi, CephFS, etc. are used for mounting files and block storage to a pod. PVs (PersistentVolumes) are cluster-wide objects that are tied to the existing storage resources.
Within a namespace, the request for a storage consumption is initiated by PersistentVolumeClaim. The different states of PV are available, bound, released, and failed. The StorageClasses are the abstraction layer. It differentiates the underlying storage quality and separates out various characteristics. The pod can request new storage dynamically with the help of StorageClasses and PersistentVolumeClaim.
Discovering and Publishing Services
Depending on the cluster’s version, Kubernetes depends on either Kube-DNS or CoreDNS for discovering the services. These integrated DNS services create, update, and remove DNS records. It helps applications to target other pods and services through a consistent and simple naming scheme.
For a Kubernetes service, the DNS record can be service.namespace.svc.cluster.local
DNS record, a pod can have: 10.32.0.125.namespace.pod.cluster.local
The Physical cluster containing virtual clusters are called Namespaces. It provides a separate virtual environment to multiple users along with respective access rights for Kubernetes objects.
Labels are used to differentiate resources present in a single namespace. The attributes are defined by key or value pairs. Labels are used for mapping organization structures over Kubernetes objects. It can describe the environment, release state, app tier, or identification of customers. It prevents the hard linking of objects.
Annotations are used for adding arbitrary unidentified baggage or metadata to objects. It is used as a declarative configuration tooling.
The technology of Kubernetes is developing fast, and it is a cost-effective solution for the future. It offers great stability to applications.
All the basic concepts of Kubernetes architecture and Kubernetes components are explained in this article.
If you’re interested to learn more about kubernetes, big data, check out upGrad & IIIT-B’s PG Diploma in Full-stack Software Development which is designed for working professionals and offers 500+ hours of rigorous training, 9+ projects, and assignments, IIIT-B Alumni status, practical hands-on capstone projects & job assistance with top firms.