In this blog, we will discuss Kubernetes (aka k8s for short). In this blog, we will cover the following:

  • What is Kubernetes?
  • How is it different from the traditional model?
  • How has Kubernetes evolved?
  • Why would you need k8s?
  • What can k8s do?

In the end, we will walk through setting up a Kubernetes cluster on the Microsoft Azure cloud.

What is Kubernetes

Kubernetes or k8s is an orchestrator to build, deploy, update, and manage containers. A container is a standard unit of software that packages up code and all dependencies, so the application runs quickly and reliably from one computing environment to another.

Container Deployment

Traditional Deployment Era

Traditionally, customers ran applications on physical servers. However, there was no way to define resource boundaries for Apps in a physical server, and this caused resource allocation issues. For example, suppose multiple applications run on a physical server. In that case, there can be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution would be to run each application on a different physical server. But this did not scale as resources were underutilized, and it was expensive for organizations to maintain many physical servers.

Virtualized Deployment Era

As a solution, virtualization was introduced. It allows you to run multiple Virtual Machines (VMs) on a single physical server’s CPU. In addition, virtualization will enable applications to be isolated between VMs and provide security as the information of one application cannot be freely accessed by another application.

Virtualization allows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs, and much more. In addition, with virtualization, you can present a set of physical resources as a cluster of disposable virtual machines.

Each VM is a complete machine running all the components, including its own operating system, on top of the virtualized hardware.

Container Deployment Era

Container engines often referred to as operating-system-level virtualization, are operating systems where the kernel allows multiple isolated instances. Each instance is referred to as a container, virtualization engine. Developers use these to create secure, virtual hosting environments with isolated resources.

Therefore, containers are considered lightweight. Similar to a VM, a container has its own filesystem, the share of CPU, memory, process space, and more. However, as they are decoupled from the underlying infrastructure, they are portable across clouds and OS distributions.

Container Run-Time Engine

To create a microservice ecosystem, software solutions such as container management software, container orchestration software, container networking software, container monitoring software, and service discovery software. There are various Container run time engines available in the market, below are a few popular ones:

There are various Container run time engines available in the market, below are a few popular ones:

  • Containers
  • CRI-O
  • Docker
  • Rocket
  • LXD

Docker container runtime integrates well with the Kubernetes engine of the above Container runtime.

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services. It also facilitates declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

Looking for more information on container orchestration? Check out our blog, A Developer’s Guide to Container Orchestration, Kubernetes, & AKS

Why Do I Need Kubernetes?

Containers are an excellent way to bundle and run your applications. However, you need to manage the containers that run the applications and ensure no downtime in a production environment. For example, another container needs to start if a container goes down. Wouldn’t it be easier if a system handled this behavior?

That’s how Kubernetes comes to the rescue! Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for your system.

Kubernetes provides you with:

  • Service discovery and load balancing. Kubernetes can expose a container using the DNS name or IP address. Then, if traffic to a container is high, Kubernetes can load balance and distribute the network traffic to stabilize the deployment.
  • Storage orchestration. Kubernetes allows you to automatically mount a storage system of your choice, such as local storage, public cloud providers, and more.
  • Automated rollouts and rollbacks. You can describe the desired state for your deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, you can automate Kubernetes to create new containers for your deployment, remove existing containers and adopt all their resources to the new container.
  • Automatic bin packing. You provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. Then, you tell Kubernetes how much CPU and memory (RAM) each container needs. As a result, Kubernetes can fit containers onto your nodes to make the best use of your resources.
  • Self-healing. Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
  • Secret and configuration management. Kubernetes let you store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. You can deploy and update secrets and application configuration without rebuilding your container images or exposing secrets in your stack configuration.

A Kubernetes Cluster is a group of machines (Virtual or physical) running together. There are two types of systems in the k8s cluster a Master and a Worker node. Together, these servers form a Kubernetes cluster and are controlled by the services that make up the Control Plane. As a best practice, the worker node hosts user applications, whereas the Master node hosts all system components. However, the master can host user applications, but it is not recommended.

Kubernetes Master Node Control Plane

Kubernetes Cluster Infrastructure Setup

Below is the architecture diagram set up on the Azure cloud. We will set up a single Vnet and two subnets for easier management. One subnet will host worker nodes, and the other subnet will host the master node. Ubuntu LTS 20.x OS will be used for Master and worker nodes. In addition, we will deploy the Windows 10 system to test our applications.

Virtual Network

Since we are creating a k8s cluster setup for learning purposes, all ports are opened to communicate across subnets. Below are the default ports to communicate across cluster components for enterprise-class clusters.

Control Plane and Worker Nodes

Azure Virtual Network Setup

Here, we create a single Vnet and two subnets thru the Azure portal. I’ve included screenshots below to navigate and submit for creation after logging into

Create a Virtual Network

Create Virtual Network with IP Addresses

The above step creates one Vnet named aks-vnet with a CIDR of 10.0.0./16. And also creates two subnets, one with a CIDR range of by name aks-master-subnet and the other subnet with CIDR range by name aks-worker-subnet.

Azure VMs Setup

We will set up three Ubuntu 20 LTS systems for worker nodes, one Ubuntu 20 LTS for the master node, and one for Windows 10. As per official documentation, it is recommended to have 2GB Memory and 2 CPUs. But to get better performance, at least 8GB of Memory and four vCPUs are suggested.

Below table shows – the VM sizes, OS type, and hostnames used in our lab setup.

Azure VMs setup

After logging into the Azure portal thru (, please follow “Virtual machines” à Create à”Virtual machine” and follow the below screenshots. This procedure will create a new master node with 8GB Ram, two vCPUs, and four disks. First, choose subnet “aks-master-subnet.” Next, select “password” as the mode of “authentication type” and provide 12 characters long alphanumeric string with lower n upper case and special characters. Also, allow port 22 for “Public inbound” options, allowing ssh and sftp protocols to connect it to this system.

The same steps need to be followed to create Worker nodes but choose “aks-worker-subnet” to create instances under CIDR.

Azure VM Creation

Windows 10 jump server is set up in subnet, and this instance will be used to test applications deployed onto the k8s cluster. A minor modification is needed to connect to this VM and setup while creating, please follow the below screenshots.

Windows 10 System Setup

By default, the windows system requires Network-level authentication, which requires a domain controller. However, as we set it up for learning purposes, we will disable the NLA.

Error Message while connecting through remote desktop

Follow the below screenshot to disable NLA. Next, select VM, “Jumpserver” à” RUN Command” à”DisableNLA” à”RUN.” Once this is successful, VM needs to restart, this change to take effect.

Disabling NLA configuration

With the above updates to the jumpserver configuration, you will be able to connect thru the “remote desktop connection” utility. Once logged, you can check connectivity to all four systems by using ssh from the command line. It would be best if you got successfully authenticated and logged into master and worker nodes.

Connectivity testing from jump server to nodes

Installing Prerequisite Software

After building the network and systems, we have to update system packages and install the required software on Master and worker nodes. These packages are:

  • Docker
    • CRE – A software responsible for running the containers.
  • kubeadm
    • A CLI tool that will set up the cluster, upgrade and join worker nodes.
  • Kubelet
    • The kubelet is the primary “node agent” that runs on each node and handles node level operations
  • Kubectl
    • A CLI tool – Used to manage k8s cluster through its API Server.

To install these packages, follow the steps mentioned below on Master as well as Worker nodes:

Step 1. We have to do SSH to our virtual machines with the username and password and switch user to superuser by using Sudo.

switch user to superuser

Step 2. Now we will install the Docker package in our machine using the following command:

apt-get update && apt-get install</li>

 Install the Docker package

Step 3. Update the apt package index and install packages needed to use the Kubernetes apt repository:

apt-get update && apt-get install -y apt-transport-https ca-certificates curl</li>

Update the apt package index

apt-package-index.png" alt="Update the apt package index " width="800" height="134"

Step 4. Add below lines into /etc/docker/daemon.json to declare systemd as cGROUP driver for docker runtime. If the file is not present, you can create it with the below commands.

chmod 600 /etc/docker/daemon.json

Step 5. Download the Google Cloud public signing key:

curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg

Step 6. Add the Kubernetes apt repository:

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list

Step 7. Update apt package index, install kubelet, kubeadm, and kubectl, and pin their version:

apt-get update
apt-get install -y kubelet kubeadm kubectl
apt-mark hold kubelet kubeadm kubectl

Setup Kubernetes Cluster

As we have successfully installed Kubeadm, next we will create a Kubernetes cluster using the following mentioned steps:

Step 8. We have to initialize kubeadm on the master node. This command will check the node for all required dependencies. Once successful, then it will install control plane components. We will set up the k8s cluster on private IPs. Hence, we need to get the private IP of the master node from Azure portal à Virtual Machine à master à networking à NIC Private IP
(Note: Run this command in Master Node only.)

kubeadm init --apiserver-advertise-address=

The Kubeadm will run multiple preflight checks, create certificates, and build kubeconfig configuration and this step will take 4-6 minutes depending upon the system’s size.

Kubeadm will run multiple preflight checks

Successful k8s cluster creation will generate the below output and print some commands to join worker nodes to this cluster and make kubectl work.
Please note the highlighted part in the below screenshot, which is required to join worker nodes.

requirements to join worker nodes

Master node successful creation output

The above screenshot output shows that cluster is up and running, and the master node is in “Not ready” status. We will have to install CNI to enable communication channels across nodes and Cluster DNS to start functioning. Apply Weave CNI (Container Network Interface) on the master node.

kubectl apply -f "$(kubectl version | base64 | tr -d '\n')"

Weaver installation and verification of successful pod build

The above command will take a minute to create weaver pods by downloading from weave works, creating weave pods, and bringing coreDNS pods online.

Run below commands as normal user (Non root user to have kubectl connect to K8s cluster)

  • mkdir -p $HOME/.kube</li>
  • sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config</li>
  • sudo chown $(id -u):$(id -g) $HOME/.kube/config</li>

Join Worker Nodes to the Kubernetes Cluster

Our Kubernetes master node is set up, and we should join Worker nodes in our cluster. Perform the following step on all worker nodes as root users or using “sudo.”

kubeadm join --token fajbkz.6fv9xzxeqwkp6n7z --discovery-token-ca-cert-hash sha256:7e7bd6fdfb711c02714d7bafcecc2b48f8bb838b818cffb41845df517e13719d

Also, you can regenerate the above “tokens” and “hash” codes by running the below command on the master node.

kubeadm token create --print-join-command #(On MASTER node only)

The below screenshot shows the successful joining of worker node to cluster. Follow the same procedure on other worker nodes.

Successful worker node joining into k8s cluster

The below screenshot shows the successful k8s cluster with one master node and three worker nodes.

Successful three-node joining into k8s cluster


Kubernetes can be set up in multiple ways depending on your comfortability; I have leveraged kubeadm tool to build a k8 cluster. However, for a better understanding of k8s concepts and to have hands-on. I have opted for the kubeadm tool with one master and 3 worker nodes, which are scalable and single worker nodes.

Alternatively, you may also use minikube to set up an automated, easy and simple tool for building k8s cluster on a single VM in a minimal and automated way.


Establishing a Clear Cloud Adoption Strategy

As we hear a lot of buzz about cloud adoption, I wanted to share my thoughts about cloud adoption approaches and strategies to migrating on-premises workloads to public clouds in this blog. This blog predominantly covers infrastructure assets migration in line with applications. As many would feel that cloud adoption brings significant cost savings to OpEx and CapEx, it requires meticulous planning, design, and architecting. This requires careful consideration of various aspects such as network traffic inflow and outflow, Business Continuity Plan (BCP) like High Availability Disaster Recovery (HA/DR), Data Replication within Regions or Geographies, etc. Data Transfer to Cloud during migration, which is a one-time exercise.

There are many ways you can migrate your applications to the cloud. However, before the migration phase, it is essential to determine the current environment, dependencies, servers and applications, licenses, and much more.

Three Popular Migration Approaches

  • Rehost: Generally referred to as lift and shift or like to like migration, lifts servers or applications from the current hosting environment and shifts them to infrastructure in the public cloud. This approach has low risks in the cloud journey but may not leverage full cloud benefits.
  • Replatform: Minor changes to the application and/or Infrastructure architecture during the migration. This approach leverages cloud benefits such as App Pools, Availability Sets, AZs, etc.
  • Refactor: Re-architect your existing application to leverage the features and services offered by the cloud environments. Refactor can become an expensive option but can avail the best possible benefits of the cloud. One can re-architect the application to become highly available and scalable. It is the most time-consuming among all options since it requires complete awareness of current architecture and building a new solution by leveraging cloud services.

Learn about the top three modernization approaches — rehosting, replatforming, and refactoring — uncovering pros, cons, and process ideas as you go.

Critical Factors to Consider

Vendor Lock-in

  • Vendor lock-in is the common term for a situation where an organization wishes to transfer its business away from one of its current vendors but cannot do so due to the projected cost, duration, or complexity of switching.
  • Considerations when choosing a cloud partner:
    • Create and Negotiate Your Exit Strategy
      • Always remember that the best time to create an exit strategy is before signing an initial service agreement.
    • Develop or design portable vendor-agnostic applications
      • Building portable applications can also help organizations avoid cloud vendor lock-in. Suppose you develop a business-critical application whose core functionality depends on a platform-specific feature like Azure’s data lake analytics or Amazon Lex. In that case, you’ll end up locked into that cloud service provider.
  • Multi-Cloud
    • This cloud computing model encompasses the usage of multiple cloud providers, choosing specific services from each, as per their requirements. This approach reduces the dependency on single cloud technology or cloud service provider. And thus, it offers avoidance of cloud vendor Lock-in and provides the best of multiple cloud service providers.

Business Continuity and Disaster Recovery

  • Business Continuity and Disaster Recovery (BCDR or BC/DR) is a set of processes and techniques used to help an organization recover from a disaster and continue or resume routine business operations. It is a broad term that combines the roles and functions of IT and business in the aftermath of a disaster.
  • High Availability Design: When there is a system outage, the Recovery Point Objective (RPO) is a measure of how frequently you take backups. Recovery Time Objective (RTO) is the amount of downtime a business can tolerate.
  • Fault Domains: A set of hardware components that share a single point of failure.
  • Update Domains:  A logical group of the underlying hardware that can undergo maintenance or be rebooted at the same time.
  • Availability Set: A logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability.
  • Availability Zones: A logical data center in a region available for use by any AWS customer.

Network Costs

  • While on-premises, data transfer doesn’t cost a dime; data transit in the cloud does. Various cloud providers have multiple charges. This is one of the significant components that need to be factored in while moving to the cloud.
  • Ingres or inflow to the cloud is not chargeable. Egress or outflow traffic is chargeable and is applicable for data flow from cloud to on-premises or cloud to the Internet.
  • While data within the same availability zone is free for some cloud providers, it is chargeable across regions or Geographies.

Security Risks and Compliance

Shared Resources in Public Cloud

  • For some clients, their applications or systems (VMs) shouldn’t be hosted on the same physical host as their competitors. When opted for VMs, one won’t control which physical system these VMs are created or migrated to.
    For this kind of compliance requirement, the client should opt for dedicated hosts.

Data Security During Transit and Rest

  • Most of the CSPs offer data encryption at rest, by default, while it’s in transit over the internet from the user to cloud, and then internally when it’s moving within the provider network, for example, between data centers, zones, and regions.
  • Data at rest – data stored in buckets/disks can also be secured by encrypting, and cloud providers offer various services such as managed keys and client-sourced keys, etc.

Backup and Restoration

  • While backing up the data to cloud location doesn’t incur network traffic costs, many CSPs have storage costs during the backup stage. However, while the recovery process, network costs do get charged.
  • While storing data at cloud locations has many offerings by CSPs, things to be considered while deciding storage solution are frequency of data access – hot/cold/archive, etc.
  • Restoration of backed up data
  • Data archival solution for compliance requirements

Four Stages of Cloud Adoption: A Quick Glance

  1. Assessment and Design: The first stage has Asset Discovery, Asset Consolidation, Scope Definitions, Costing.
  2. Planning: Wave group creation, cutover planning, defining exit criteria, stakeholder identification, and notification channel creation.
  3. Cutover and Execution: Migration rollout, sign-off approvals, and rollback (if any).
  4. Analysis and Optimization: Baselining and performance analysis, Optimize the resource utilization by leveraging cloud-native tools.

Asset Discovery

  • The first and most crucial step in cloud adoption is tracing out the inventory like hardware and software assets and how they are interconnected. For example, Servers (physical, virtual, Linux or Windows), Network gear like switches, routers, wireless devices, Voice devices, etc., Storage arrays, Backup devices, Security devices such as Firewalls, VPN gateways, etc.
  • Validate identified assets with available CMDB of the customer and create application affinity mapping by having workshops, surveys, interviews with application teams
  • Discover infrastructure workload footprint
  • Application to server grouping
  • High-level application dependency mapping
  • Gather as-is resource parameters

Application Views

Define Migration Scenarios

  • Assess various approaches for migration and best fits for multiple scenarios
  • Proof of concept and benchmarking cut over timelines
  • The Migration strategy finalization for various scenarios. This includes 2 tier architecture, 3 tier architecture, INFRA Utility servers like
  • AD, print servers, collaboration servers, etc.

Wave Group Creation

  • Finalize wave groups in line with Application dependency
  • Create cutover plans and finalize downtimes, roll back time also need to be included
    • The cutover plan also needs to have test cases from INFRA and App/Biz teams
  • Identification of stakeholders and communication modes

Migration Execution

  • Communication channels initiation and notification to all stakeholders
  • Initiate pre-migration activities:
    • Target environment building, NW connectivity establishment, and necessary firewall rules enablement and data replication
    • Migration tool setup
  • Cutover initiation and progress monitoring
  • Cutover to Target environment on public cloud
  • UAT by application team and sign off
  • Cutover and go-live
  • Rollback, in case of failures

Hand Over to Support Team

  • Heightened support for 48 hours by the Migration team
  • Handover of successful workloads on cloud environment to the operations team
  • Request support team to decommission source workloads at On-Premises after one week (As per accepted retention policy by customer)

Bringing Organizations Cost-Effective Solutions

Cloud adoption has become one of the critical strategies for many organizations to bring cost-effective solutions to their business community. Nowadays, many cloud Solution Specialists (CSPs) and System Integrators (SI) offer professional consulting services to facilitate the cloud adoption journey. It is recommended to decide which cloud strategy works for your organization and validate the abovementioned items to monitor and optimize resource utilization.

Transform your business into a modern enterprise that engages customers, supports innovation, and differentiates your organization, all while cutting costs.