Terminology – PaaS Compute Options

Terminology – PaaS Compute Options

There are different terminologies that are associated with Kubernetes. In the previous section, you might have noticed the keyword pod; that is Kubernetes terminology. Figure 9.15 explains the terminology.

FIGURE 9.14 Azure container groups

Pools refers to a group of virtual machines (nodes) having identical configurations. For example, you could create a pool with Windows VMs for running Windows containers and a pool with Linux VM for running Linux containers. Pools are also called node pools.

Nodes are the virtual machines in which the containerized applications are running. These nodes are grouped using pools. Earlier nodes used to be known as minions. The cluster schedules the containerized applications to these virtual machines based on resource availability.

Pods represent the smallest execution unit in Kubernetes. A pod encapsulates one or more applications, in other words, one or more containers.

A container represents the executable image that is composed of all binaries, libraries, and software required to run your application. These containers are encapsulated inside the pod. The container is created using container images that are stored in repositories like Docker Hub, Azure Container Registry, etc.

 Deployment is another Kubernetes primitive used to run one or more identical pods. During the creation of the deployment, you can specify the number of pods required, and Kubernetes will make sure that it maintains this number no matter what happens. Even if you delete one pod that is part of a deployment, Kubernetes will immediately spin up another pod to match the number of replicas.

A manifest is the YAML or JSON file used for the creation of Kubernetes primitives like pods, deployment, etc. Every item in Kubernetes is created using a YAML/JSON file. This is similar to an Ansible playbook or Chef recipe.

As this book is not about the workings of these primitives, you will be focusing on the configuration of Kubernetes on Azure using AKS. If you are interested in learning more about these terminologies, please visit https://kubernetes.io.

Now you will learn about cluster components in AKS.

Cluster Components

An Azure Kubernetes Service cluster can be divided into two components.

• Azure-managed nodes
• Customer-managed nodes

Azure-managed nodes are the masters of the cluster, and they’re responsible for managing the cluster. When you create an AKS cluster, this node is automatically provisioned and configured with all the management-layer components. As this layer is managed by Azure, customers will not be able to access or make configuration changes to this one. Also, you are not paying for this node.

Customer-managed nodes are the virtual machines on which containerized applications are running. You can have one or more nodes in a cluster. As shown in Figure 9.16, a Kubernetes customer-managed node runs the following components:

• Kubelet is responsible for processing the requests that are coming from the Azure-managed node or the master node. Also, kubelet processes the scheduling requests sent by the scheduler to run the containers.
• Kube-proxy is managing the virtual networking on each node. The proxy handles network routes and IP addressing for services and pods.
• The container runtime is something you learned about in the “Container Instances” section. This component is responsible for running the container and setting up interactions with network and storage. The AKS cluster running Kubernetes version 1.19 or higher uses container as the runtime, and versions prior to 1.19 use Moby as the container runtime.

Customer-managed nodes can be grouped together into node pools based on the configuration. During the creation of the cluster, you can specify the initial number of nodes and the size of the node. These nodes will be added to the default node pool.

Let’s see how networking is implemented in AKS.

FIGURE 9.15 AKS terminology