Azure Kubernetes Service - Architecture & Implementation Case Study

Azure Kubernetes Service – Architecture & Implementation Case
Study
Context
The purpose of the case study is to provide a clear understanding of the Azure Kubernetes Infrastructure
implementation and deployment of a sample containerized application. The deployment strategy described in this
document can be used as a startup infrastructure for the clients who want to adapt Azure Kubernetes Service in
Azure cloud infrastructure
Background
Arnhold Delmaize involved Idea to assess their cloud environment, improve the cloud infrastructure in terms of
architecture and found out the scope of automation. Ahold Delmaize is having AKS infrastructure and Idea cloud
foundation team is currently managing the AKS infrastructure
About the Author

Indra katjee has been in Idea for the past five years and is currently working in Alberto Heikuvan project in dhaka.
His responsibility to find out the opportunities of to improve the cloud infrastructure and the scope of automation on
Azure Cloud. He is also representing as an Architect in DA board meeting with Customer architectural discussion
in Linux Infrastructure area. Currently he is working as a SPOC for managing the AKS infrastructure from Idea
cloud foundation team side.
Note
The implementation shown here is in a personal free-tire subscription based on the knowledge which is acquired
by studying the architecture of Arnhold Delmaize. It is ensured that no client data is compromised by providing the
information of the implementation shown in this blog.
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
Pods
A pod is basically a single container or a group of containers which hosts the application.
Services
Services is the endpoint of pod , means AKS control panel access the container by contacting the services. In
1 of 9
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
2 of 9 6/1/2020, 8:20 AM
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:-
3 of 9
Scenario1 Deployment Template:-
Following is the sample deployment template of the app
4 of 9 6/1/2020, 8:20 AM
Scenario1 deployment details
Scenario1 APP status Check

Now the app can be accessed by the public IP
5 of 9 6/1/2020, 8:20 AM
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:-
6 of 9
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
7 of 9
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 Kubernates Service is having the same flavours of OpenSource Kubernates and less complexity.As
Microsoft takes away the headache of managing Master node .
Microsoft also provides various addon to monitor Kubernates 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.
8 of 9
9 of 9 6/1/2020, 8:20 AM

Azure Kubernetes Service - Architecture & Implementation Case Study

Uploaded by

Copyright:

Available Formats

Azure Kubernetes Service - Architecture & Implementation Case Study

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure Kubernetes Service - Architecture & Implementation Case Study

Uploaded by

Copyright:

Available Formats

Azure Kubernetes Service – Architecture & Implementation Case

About the Author

Kubernetes Control Plane (master)

Exporting a variable name with ACR name

Identify the ACR ID:

Assign ACR reader access to Service Principal

Scenario1 APP status Check

You might also like