Azure Kubernetes Service —An Introduction

Introduction:-
Kubernetes is an open-source orchestration system for application deployment, scaling, and management in a containerization platform. It was originally designed by Google. Microsoft recently adopted it for its Azure environment, providing Azure Kubernetes Service as a managed service.

Terminology:-
Below are some of the key concepts which I believe will help immensely in understanding Kubernetes.

Services:-
Services is the endpoint of pod , means AKS control panel access the container by contacting the services. In other term if we need to expose the pod to the outside world we need to attach service with the pod. Following are types of services which can be used to expose a pod.
1.Public LoadBalencer( Default)
2.Private LoadBalencer (Private)
3.Ingress

Namespaces:-
The container technology is achieved by isolating a group of processes of an Operating System. The isolation is done in such a way that one set of processes cannot overlap the other set of processes . This facility is achieved by namespaces. Namespace provides a boundary and a unique name in the kubernetes environment. In AKS following are the types of namespaces
.
kube-system:- This is the namespace which contains the kubernetes system related containers
default:- This namespace comes by default after login to the kubernetes environment.

Container Registry:-
Container registry is the repository of the containerized image of the application example Dockerhub. In AKS environment Microsoft provides Azure Container Registry as a service for holding the containerized image

Kubernetes Control Plane (master):-
The Kubernetes master (this is a collection of processes) ensures the Kubernetes cluster is working as expected by maintaining the clusters desired state.
Kubernetes Nodes:-
The nodes are where the containers and workflows are run. The nodes can be virtual machines, physical machines etc. The Kubernetes master controls each node.

Environment Preparation:-
1. Preparing the application image and populate the ACR(Azure Container Registry):-
In existing scenario a sample application is cloned using git and pushed to Azure Container Registry
$ git clone https://somerepo.com/Azure-Samples/aci-helloworld

Exporting a variable name with ACR name
$ACR_NAME=weeusaksconreg01.azurecr.i
$ az acr build — registry $ACR_NAME — image customized-imag:v1 .weeusaksconreg01.azurecr.io

In Azure its is always a best practice to provide access through Service-principal
$ az ad sp create-for-rbac — skip-assignment
{
“appId”: “xxxxxxxxxxxxxx”,
“displayName”: “azure-cli-2020”,
“name”: “http://azure-cli-2020",
“password”: “yyyyyyyyyyyyy”,
“tenant”: “zzzzzzzzzzzzzz”
}

Identify the ACR ID
$az acr show — resource-group weeusAksRG — name weeusAksConReg01 — query “id” — output tsv
/subscriptions/wwwwww /resourceGroups/weeusAksRG/providers/Microsoft.ContainerRegistry/registries/weeusAksConReg01

Assign ACR reader access to Service Principal:
$ az role assignment create — assignee “ xxxxxxxxxxxxxx “ — scope “/subscriptions/wwwwwwww/resourceGroups/weeusAksRG/providers/Microsoft.ContainerRegistry/registries/weeusAksConReg01” — role Reader

Create AKS cluster with previously Created SP so that it can read the container image from ACR
$az aks create \
— resource-group weeusAksRG \
— name weeusaksclus02 \
— node-count 1 \
— kubernetes-version 1.15.10 \
— generate-ssh-keys \
— node-vm-size Standard_D2_v3
— service-principal “xxxxxxxxxxxxxx” — client-secret “yyyyyyyyyyyyy”

So by this way the AKS cluster have the permission to read application images in ACR.

Scenario1:-
In scenario1 the application inside pod will be exposed by using the default load balancer service i.e pod will access from internet by sing the public IP of the load balancer

Scenario1 Architecture:-

Scenario1 Deployment Template:-
Following is the sample deployment template of the app

Scenario1 deployment details:-

Scenario1 APP status Check:-
Now the app can be accessed by the public IP

Scenario2:-
In scenario2 the application inside pod will be exposed by using the internal load balancer service i.e pod will have a private IP of a VNET’s subnet , In this case POD is exposed inside VNET, which can be exposed via Application Gateway with WAF protection. This is the recommended architecture in which the containerized service is secured by using web application firewall

Scenario2 Architecture:-

Scenario2 Deployment Template:-
Following is the sample deployment template of the app in which an explicit VNET subnet private IP is assigned to the loadbalancer

Scenario2 deployment details
As it can be seen that the internal app service mapped with the IP which is mentioned in the deployment template

Conclusion:-
Azure Kubernetes Service is having the same flexibility of OpenSource Kubernetes and less complexity.As Microsoft makes AKS as manage service takes the responsibility of managing Master Node.
Microsoft also provides various addon to monitor Kubernetes environment by adding monitoring insights.
Monitoring log can be saved in loganalytics workspace.
As a whole AKS provides wonderful platform to maintain rapid app development cycle by the power of aks and Azure tools.