Four out of ten enterprise companies included in the Cloud Native Computing Foundation’s biannual survey reported that they’re running Kubernetes in production environments.
As more and more organizations move to microservice and cloud-native architectures that make use of containers, they’re looking for strong, proven platforms. Practitioners are moving to Kubernetes. With Kubernetes, you can take real steps towards better IT security.
There is no denying that Kubernetes has swept the board and is taking the world by storm. But, as a dilettante exploring the ever-expanding field of cloud computing, have you ever wondered what Kubernetes is? What does it do, and how is it architectured? This article seeks to briefly answer the aforementioned questions and develop a solid foundation for the diverse components of a Kubernetes cluster. It also encompasses Kubernetes services provided by popular Cloud Service Providers like Amazon Web Services (EKS).
What are containers?
Traditionally, physical containers which are made up of tin or plastic store cookies, dry fruit, and a melange of other edible paraphernalia. They isolate the food from the extrinsic milieu and lock it in an air-tight, waterproof environment. This prevents them from going stale and soft.
DevOps containers differ in the latter functionality. They are standardized packages of software that zip the application’s code along with its environment-specific dependencies like runtime, system tools, and settings so that the application has a smooth and reliable cross-platform execution. While conventional, tangible containers insulate the contents from the external atmosphere, cloud-based containers replicate the platform-centric dependencies to enable multi-platform implementation and reduce cross-platform contrariety. The OS is thus virtualized and can optimize solutions for multiple workloads on just one OS instance.
What is Kubernetes?
Kubernetes is an open-source orchestration system for containers and containerized applications. It facilitates their automated deployment, scaling, and management. It was created by Google and is now owned by the Cloud Native Computing Foundation.
In layman’s terms, Kubernetes is like a manager who supervises the computerization of container operations by eliminating manual methods initially leveraged in scaling and deployment. An important point to be noted is that Kubernetes is not just an ordinary orchestration system adhering to the execution of a prescribed, machinated workflow. It is a constitution of intelligible, independent control processes driving the existing state of the system to the predefined desired state. Various public cloud providers like Amazon Web Services provide Elastic Kubernetes Services (EKS)with the dynamic flexibility to start, run and scale Kubernetes applications in the cloud or on-premise.
Another tit-bit is that when we talk about Kubernetes(K8s), we are semaphoring towards a Kubernetes Cluster. A Kubernetes Cluster is a set of working and management units(nodes) running and directing the containerized applications. Within clusters, containers can run across multiple environments. AWS EKS Distro can be used to create powerful and sound Kubernetes Clusters. We will now be discussing the architectural framework of a Kubernetes Cluster and the components within it.
The Framework of a Kubernetes Cluster
Upon inspecting the aforementioned infographic, you can deduce that a typical K8s cluster is segregated into 2 main units: a control plane and a data plane. Let us delve into the specifics of each unit and the various components embedded within each of them.
The Control Plane
The control plane functions as the brain of the K8s cluster. It takes global decisions for the cluster and responds to cluster events. It is also known as the Master Node. This is because, in cloud service providers like AWS EKS, the control plane regulates the workflow of the various worker nodes registered under it. Kubernetes provides flexible network interfaces in the unique virtual private clouds(VPCs to connect the control plane to the worker nodes. The EKS Control Plane also allows logging audit and diagnostic logs from the control plane to CloudWatch logs for better backup. The control plane has 5 main sub-units.
1. Kube API server– An API is an Application Programming Interface that allows two applications to communicate with each other and share data. An API server exposes API data without custom application development, thus facilitating data flow. The Kube API server provides a front-end to the cluster by authenticating and organizing the state(data). After determining the validity of the state or request, the Kube API server processes it and permits authenticated users, external components, and cluster components to interact with one another.
2. ETCD- Pronounced as ‘et-cee-dee’, this is an open-source key-value (hierarchically organized) store. It is a robust and reliable way to store data to be utilized by the cluster. ETCD allows users to read and write code using simplistic HTTP tools, like curl. An important point to be noted is that if the K8s cluster is using ETCD as its primary backing store, a well-formulated backup plan is mandatory. This is because all K8s objects are stored in ETCD and regular gridlocks are necessary to recover clusters if lost under catastrophic scenarios. ETCD Built-in Snapshot and Volume Snapshots are 2 broad spectrums of ETCD cluster backup. In AWS, the ETCD is completely managed by EKS. EKS runs a customized, dedicated ETCD for every cluster and offers flexibility and scalability.
3. Kube Controller Manager– The Controller Manager runs controller processes. It is like a typical project manager. The control (non-terminating) loops executed by it inspect the data flow and the cluster’s shared state using the API. The AWS EKS Controller Manager regulates the controller processes to achieve the desired milestone. There are typically various controllers running in a cluster. But to ease the workflow, all the controllers are compiled into a single process.
4. Kube Scheduler– The EKS Kube Scheduler is a process that assigns pods to nodes. It decides what node is a valid resort for the pods in question while assessing their configuration, archetype, and purpose. It then allocates each pod to its respective nodes and links them. We shall be discussing pods in detail when we delve into the components of the data plane.
5. Cloud Controller Manager– The Cloud Controller Manager runs CSP specific controllers. AWS EKS Cloud Controller Manager creates and manages AWS Loadbalancers and node’s lifecycles. This means that on-premise Kubernetes Clusters don’t need them. Just like the Kube Controller Manager, the Cloud Controller Manager also has control loops compiled into one file. Their primary function is to link the cluster to the CSP’s API and filter the components interacting only with the cluster.
The Data Plane
The Data Plane functions as the body of a typical Kubernetes Cluster. It receives requests and instructions from the brain (control plane) and executes the required processes in the various worker nodes functioning as organs. The data plane provides services like memory, networks and storage to allow flexible and dynamic processing towards the benchmarked state. The data plane originally consists of multiple worker nodes (virtual machines) to ease the availability of state and enhance performance. We will now discuss the various components of a regular working node.
1. Pod– A pod is the smallest, fundamental deployable object within a Kubernetes Cluster. If you take a look at the infographic again, you can see that a pod contains a Docker container (or any container). The pod creates a running environment layer for the container to abstract over the container runtime to permit a user interface. In simpler words, it is an abstraction containing single or multiple dockers/containers with container-specific resources like networking, shared volumes, etc. A pod usually supports the execution of only one application, but it can run multiple applications too.
2. Services– Just like each website has a URL to identify it, each pod is allocated an IP address to facilitate communication. Since pods are susceptible to damage and could get crashed owing to a service glitch, they could easily replicate and be assigned a new IP address later on. However, a discrepancy in the IP address would jeopardize cluster components’ interaction. A service is a permanent IP address allocated to each pod. So, even if the pod crashes and a new one is created in its place, it will have the same service as the pod before it.
3. Container Runtime– Container Runtime is the software required for running a container. In AWS EKS, the container runtime used in the cluster may even change with time. But this wouldn’t affect the implementation of the Dockers.
4. Kubelet– A Kubelet is like a local manager for the nodes. It checks to ensure that the containers are running within their respective pods. The Kubelet is not responsible for the containers that were not created by Kubernetes. The latest version of the AWS Fargate pod in the AWS EKS is deployed with a kubelet version that is the same as the kubelet in the updated cluster control plane.
5. Kube proxy– The Kube Proxy is a traffic police personnel overlooking the obeisance to the network rules in nodes. It ensures the smooth flow of data traffic. A Kube Proxy is an add-on but is quite essential to the core service. In AWS EKS, the Kube proxy eyes network rules on each EC2 instance node. They are not deployed on Fargate nodes.
References:
- https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
- https://kubernetes.io/docs/concepts/overview/components/#node-components
- https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/
- https://docs.aws.amazon.com/eks/latest/userguide/managing-kube-proxy.html
