Kubernetes is a modern approach rapidly becoming the standard methodology to manage cloud-native applications in a production environment. Azure Kubernetes Service (AKS) has produced solutions that allow customers to create fully-managed Kubernetes clusters quickly and easily.
AKS is an open-source, fully managed container orchestration service that became available in June 2018 and is available on the Azure and can be used to deploy, scale, and manage Docker containers and container-based applications in a cluster environment.
Azure Kubernetes Service offers provision, scaling, and upgrades per requirement or demand without downtime in the Kubernetes cluster. The best thing about AKS is that you don’t require deep knowledge and expertise in container orchestration to manage AKS in some scenarios.
Azure container instances are the pretty right option to deploy containers on the public cloud. AKS is an ideal platform for developers to develop their modern applications using Kubernetes on the Azure architecture. The Azure Container Instances help reduce the strain on developers to deploy and run their applications on Kubernetes architecture.

AKS Core Concepts

Azure Kubernetes Service (AKS) core concepts, including infrastructure components, access and identity, security, network, storage, and scaling. Each one of the following covers a specific topic so that you can understand the basics of Kubernetes in no time.
Control Plane provides the core Kubernetes services and orchestration of application workloads. When you create an AKS cluster, a control plane is automatically created and configured. This control plane is provided at no cost as a managed Azure resource abstracted from the user. You only pay for the nodes attached to the AKS cluster. The control plane and its resources reside only in the region where you created the cluster.
Kube-apiserver is the API server is how the underlying Kubernetes APIs are exposed. This component provides the interaction for management tools, such as kubectl or the Kubernetes dashboard.
etcd To maintain the state of your Kubernetes cluster and configuration, the highly available etcd is a key-value store within Kubernetes.
Kube-scheduler When you create or scale applications, the Scheduler determines what nodes can run the workload and starts them.
Kube-controller-manager, The Controller Manager, oversees several smaller Controllers that perform actions such as replicating pods and handling node operations.
Nodes and node pools – To run your applications and supporting services, you need a Kubernetes node. An AKS cluster has at least one node, an Azure virtual machine (VM) that runs the Kubernetes node components and container runtime.
kubelet, The Kubernetes agent, processes the orchestration requests from the control plane and schedules running the requested containers.
Kube-proxy Handles virtual networking on each node. The proxy routes network traffic and manage IP addresses for services and pods.
Container runtime Allows containerized applications to run and interact with additional resources, such as the virtual network and storage. AKS clusters using Kubernetes version 1.19+ for Linux node pools use containers as their container runtime. The Azure VM size for your nodes defines the storage CPUs, memory, size, and type available. Plan the node size around whether your applications require large amounts of CPU and memory or high-performance storage.
TIP: Scale out the number of nodes in your AKS cluster to meet demand.

Node pools, Nodes of the same configuration are grouped into node pools. A Kubernetes cluster contains at least one node pool. The initial number of nodes and size is defined when creating an AKS cluster, making a default node pool. This default node pool in AKS contains the underlying VMs that run your agent nodes.

Node selectors in an AKS cluster with multiple node pools may need to tell the Kubernetes Scheduler which node pool to use for a given resource. For example, ingress controllers shouldn’t run on Windows Server nodes. Node selectors let you define various parameters, like node OS, to control where a pod should be scheduled.
Resource reservations help the node function as part of your cluster. This usage can create a discrepancy between your node’s total resources and the allocatable resources in AKS. Remember this information when setting requests and limits for user deployed pods.
Pods use to run an instance of your application. A pod represents a single instance of your application. Pods typically have a 1:1 mapping with a container. In advanced scenarios, a pod may contain multiple containers. Multi-container pods are scheduled together on the same node and allow containers to share related resources.
YAML manifests A deployment represents identical pods managed by the Kubernetes Deployment Controller. A deployment defines the number of pod replicas to create. The Kubernetes Scheduler ensures that additional pods are scheduled on healthy nodes if pods or nodes encounter problems.
Helm is commonly used to manage applications in Kubernetes. You can deploy resources by building and using existing public Helm charts that contain a packaged version of application code and Kubernetes YAML manifests.
Namespaces Kubernetes resources, such as pods and deployments, are logically grouped into a namespace to divide an AKS cluster and restrict create, view, or manage access to resources. For example, you can develop namespaces to separate business groups. Users can only interact with resources within their assigned namespaces.
Master security is the components that are part of the managed service provided by Microsoft. Each AKS cluster has its own single-tenanted, dedicated Kubernetes master to give the API Server, Scheduler, etc. This master is managed and maintained by Microsoft. By default, the Kubernetes API server uses a public IP address and an FQDN. You can control access to the API server using Kubernetes role-based access controls and Azure Active Directory.
Node security is the Azure virtual machines that you manage and maintain. Linux nodes run an optimized Ubuntu distribution using the Moby container runtime. Windows Server nodes run an optimized Windows Server 2019 release and also use the Moby container runtime. The nodes are automatically deployed with the latest OS security updates and configurations when an AKS cluster is created or scaled up.

A ReplicaSet purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
Service is an abstract way to expose an application running on a set of Pods as a network service. With Kubernetes, you don’t need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their IP addresses and a single DNS name for a set of Pods and can load-balance across them.
Namespaces – Kubernetes resources, such as pods and deployments, are logically grouped into a namespace to divide an AKS cluster and restrict creating, viewing, or managing resources access. For example, you can develop namespaces to separate business groups. Users can only interact with resources within their assigned namespaces.
Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Keeping confidential information a Secret is safer and more flexible than putting it verbatim in a Pod definition or a container image.
StatefulSets and DaemonSets – Using the Kubernetes Scheduler, the Deployment Controller runs replicas on any available node with available resources. A replica exists on each select node within a cluster. While this approach may be sufficient for stateless applications, The Deployment Controller is not ideal for applications that require:

• A persistent naming convention or storage.

Two Kubernetes resources, however, let you manage these types of applications:

• StatefulSets maintain the state of applications beyond an individual pod lifecycle, such as storage.
• DaemonSets ensure a running instance on each node early in the Kubernetes bootstrap process.

StatefulSets – Modern application development often aims for stateless applications. For stateful applications, like those that include database components, you can use StatefulSets. Like deployments, a StatefulSet creates and manages at least one identical pod. Replicas in a StatefulSet follow an agile, sequential approach to deployment, scale, upgrade, and termination. The naming convention, network names, and storage persist as replicas are rescheduled with a StatefulSet.
In short, some of the main AKS specifications. For more about K8S-AKS-Core-Concepts.

How to build AKS

The scenario below is simple to create an AKS cluster and deploy an application with a specific YAML with several steps using Azure CLI.
Note: the creation of this scenario is done from Windows Terminal on Windows 11 
Note: the Azure CLI is the command-line interface that allows users to interact with Azure services without using the Azure portal. The AZ CLI provides a quick, easy, and efficient way to create, list, and modify resources on the fly at a terminal.

Connect to Azure via Azure CLI

In this section, you will configure the AZ CLI for authentication to Azure. Authentication to Azure is needed for interacting with Azure services at the command line.
After the authentication with AZ CLI is set, you will need to choose an Azure subscription based on your Microsoft account.
First, let’s authenticating with “az login.” Open the Windows Terminal and type the command “az login,” used to start the authentication process.
Note: in some authentication scenarios, you need to authenticate via user and device login

Once you’ve logged on, the Windows Terminal will show the JSON data for the default Azure subscription information.
Choosing a Subscription – If there’s more than one subscription available in the Azure account, you’ll need to choose one to use. Running az account list –all will show you the account’s available subscriptions. You can select and set a default subscription by running az account set –subscription name.

Build Resource Group for AKS

Once you are have logged on to Azure, you need to create a resource group for the AKS. A resource group is a set location that stores the Azure resources being designed.
TO create a Resource Group, you need to use the AZ CLI resource used as an az group. To create a resource group, run the following command:

az group make –location west Europe –name aksdemo

The two parameters will be used:
--name for the resource group name.
--location For the Azure region being used.

AKS Cluster Configuration

Now, create the AKS cluster itself, and first, let’s pick a Kubernetes API Version. The version allows you to pick a dedicated Kubernetes API version. To know what Kubernetes API versions are available in each region, you need to run the following AZ CLI command:

az aks get-versions –location westeurope

TIP: Azure helps to administer the Kubernetes cluster in AKS. With that, AKS manages the Kubernetes API. The Kubernetes API sits on the master node, and no one outside of Microsoft has access to it. As a result, you cannot pick any Kubernetes API version you’d like, and you must choose one supported by Azure. The available Kubernetes API versions may differ depending on the region that the AKS cluster will be residing in.

Deploy Azure Kubernetes Services

Azure Kubernetes Service lets you quickly deploy and manage clusters. If you look at the AZ CLI documentation for creating an AKS cluster, you’ll see many parameters, most of which are optional. After looking at the documentation, go back to the terminal.
The command below will show the most important parameters to get an AKS cluster up and running with the Kubernetes API version. The AZ CLI resource that will be used is az aks. Enter the correct resource group name and AKS cluster name.

az aks create –resource-group aksdemo –name aksdemocluster –node-count 1 –Kubernetes-version 1.18.19 –generate-ssh-keys

Note: A second resource group is automatically created to store the AKS resources when you create an AKS cluster. For more information

The parameters used are:
--resource-group that you created in the previous section.
--name With the name of the AKS cluster.
name-count 1 With the number of worker nodes that will be running. In a dev environment, one node is exemplary.
--kubernetes-version Is the API version that will be used in the AKS cluster.

Confirm AKS Cluster Exists

Now that the AKS cluster is created, you can see if the AKS cluster is up and running using AZ CLI. Run the following command to show the current AKS cluster JSON output on a terminal:

az aks show –name aksdemocluster –resource-group aksdemo

Kubernetes Configuration Locally (Kubeconfig)

Now let’s configure the Kubeconfig.
Once the cluster is created, it can be managed locally on a terminal much like everything you’ve done with Azure CLI so far. To address the AKS cluster locally, a kubeconfig, the Kubernetes configuration of the AKS cluster, will need to be cloned to a local machine.
Note: The AZ CLI resource that will be used is az aks.
Run the command below to copy the kubeconfig to a local computer to clone the Kubeconfig

az aks get-credentials –name aksdemocluster –resource-group aksdemo

The output will be similar to what is displayed in the screenshot below, letting you know that the kubeconfig has been stored in the default location.

Accessing AKS from Localhost

The kubectl commands allow users to interact with the Kubernetes API to manage deployments, pods, nodes, and other Kubernetes resources. To get started with kubectl, run the following command to ensure that you can view the nodes:

kubectl get nodes

Note: The AKS cluster can be accessed from a local machine’s terminal to manage Kubernetes components like deployments and pods. It can even be used to create a Kubernetes deployment.

Deploy a Demo Application

Now it’s time to create a Kubernetes deployment. To do so, you can use one of the existing examples in GitHub. Here, we’ll use the example of spinning up an Nginx deployment. Nginx is an open-source web server.
Run the command below to create an Nginx deployment:

kubectl create -f https://raw.githubusercontent.com/eshlomo1/Azure/main/AKS/Demo/nginx-deployment.yaml

The Kubernetes deployment will be created, as shown in the screenshot below. Once its completed, use kubectl to check on the deployments by running this command:

kubectl get deployments

TIP: you can run the “kubectl get deployments” to know which deployment you’ve got
If we check how it looks like the command that we’ve run, we can see all of the information in the Azure portal.

TIP: for all Azure CLI commands, go to Azure/Azure AKS demo commands.txt at main · eshlomo1/Azure (github.com)
Well done. You have successfully created an AKS cluster and deployed a simple application.