Introduction
Kubernetes is an open-source container orchestration solution developed by Google. It helps us to automate deployments, scale, and manage containerized applications. It was released by Google in 2015 and is now developed and maintained by the Cloud Native Computing Foundation (CNCF). We can build enterprise-grade container orchestrations using Kubernetes.
Azure Kubernetes Service is a managed Kubernetes Service offered by Microsoft Azure. Setting up a Kubernetes Cluster is cumbersome at times, and we need to put in much effort to have the cluster up and running. Azure Kubernetes Services encapsulates all complexities involved and makes things easy for us. We need to focus on developing container-based applications and deploy them to the Azure Kubernetes Service. The underlying Azure platform handles all infrastructure concerns.
Azure Kubernetes Service is a Platform as a Service offering from Azure Cloud. Azure Kubernetes Service is developed on top of Azure Kubernetes Engine, which is an open-source project developed and maintained by Microsoft.
Let us focus on understanding the underlying architecture and internals of Azure Kubernetes Service.
High-Level Architecture
The Azure Kubernetes Service consists of the following components.
We develop our containerized applications, and these applications run on the Nodes. The Nodes are usually Virtual Machines or Containers. The nodes are either a physical node or a serverless virtual node. In the case of the serverless virtual Node, the nodes are containers running on Azure Container Instances. We define the number of Nodes and the size of each of the Nodes.
Control Plane works as a master and manages the Nodes. We interact with the Control Plane using API calls. We provide all the cluster details like the application deployment information, node size, number of nodes, networking details, and all other necessary information to the Control Plane with the help of API calls. The Control Plane configures the Nodes and the cluster and then deploys the application to the cluster. We interact with the Nodes through the Control Plane and not directly. The Control plane is abstracted to us, and the underlying Azure platform manages it. We need not worry about getting the Control Plane ready. The Control Plane manages architectural concerns like Scalability, Reliability, Availability, and many more. We need to focus on developing the application and deciding on the Node size and number of Nodes. The Control Plane does the rest of the trick.
The applications run on containers hosted on the Nodes. These containers get the images from the Container Registry that is a repository of the images. Azure Kubernetes Service supports Docker Registry as well as the Azure Container Registry.
Figure 1 depicts the High-Level Architecture of Azure Kubernetes Service.
Control Plane
When we create an Azure Kubernetes Service, we provision a Control Plane for the Kubernetes Service. The Control Plane acts as a master component. It manages and controls the Kubernetes Cluster. The Control Plane consists of the following components.
- API Server
- Scheduler
- Etcd
- Controller Manager
The API Server is also known as kube-apiserver. The API Server exposes the Kubernetes APIs. We interact with the Azure Kubernetes Service cluster using these APIs. We use either kubectl commands or the Kubernetes dashboard to work with these APIs. We provide the application deployment, Nodes, and cluster information to the Azure Kubernetes Service using these APIs. Azure Kubernetes Service creates the Kubernetes cluster using the information we provided using the APIs.
The Scheduler is also known as kube-scheduler. The Scheduler determines the nodes on which to run the application workload. It plans out the Nodes and starts these Nodes.
Etcd is a highly available key-value data store. It maintains the state information for the Kubernetes cluster and the configuration.
The Controller Manager is also known as kube-controller-manager. The Controller Manager may handle many smaller controllers. It takes care of all the node operations like replication and many more. Figure 2 depicts the Control Plane architecture.
Azure Kubernetes Service provides a single-tenant Control plane having a dedicated API Server, Scheduler, Etcd, and Controller Manager. You can create your Control Plane as well by extending the Azure Kubernetes Service engine.
Nodes
The Nodes run the containerized workflows. The Node is usually an Azure Virtual Machine. The Node consists of the following components.
The kubelet is the Kubernetes agent sitting on the Node. The Control plane interacts with the Node through the kubelet. The kubelet processes the Control Plane requests to manage and schedule the Node.
The Pod is the smallest unit of deployment, where we deploy the application. The Kubernetes cluster hosts identical Pods hosting the same application component. This identical set of Pods is called Replica sets. If a Pod in the Replica set goes down, another identical Pod boots up. These Pods scale dynamically when the incoming load increases. End users consume the application hosted on Pod using Ingress Controllers.
We define the number of Pods in a replica set, and the Control Plane manages and controls these Pods through the kubelet. The Pod contains a single container. In specific complex scenarios, it can contain multiple containers.
The kube-proxy manages the networking aspect of the Kubernetes Cluster.
Winding-up
In this article, we explored the internal architecture of the Azure Kubernetes Service. Before we start deploying workloads to the Azure Kubernetes cluster, we must understand these necessary components well. This understanding helps us orchestrate containerized applications with ease using Azure Kubernetes Service.