Case study on Azure AKS(Azure Kubernetes Service)

Azure Kubernetes Service (AKS) simplifies deploying a managed Kubernetes cluster in Azure by offloading much of the complexity and operational overhead to Azure. As a hosted Kubernetes service, Azure handles critical tasks for you, like health monitoring and maintenance.

Since the Kubernetes masters are managed by Azure, you only manage and maintain the agent nodes. Thus, as a managed Kubernetes service, AKS is free; you only pay for the agent nodes within your clusters, not for the masters.

You can create an AKS cluster using the Azure portal, the Azure CLI, Azure PowerShell, or using template-driven deployment options, such as Resource Manager templates and Terraform. When you deploy an AKS cluster, the Kubernetes master and all nodes are deployed and configured for you. Additional features such as advanced networking, Azure Active Directory integration, and monitoring can also be configured during the deployment process. Windows Server containers are supported in AKS.

Access, security, and monitoring

For improved security and management, AKS lets you integrate with Azure Active Directory (Azure AD) and:

• Use Kubernetes role-based access control (Kubernetes RBAC).
• Monitor the health of your cluster and resources.

Identity and security management

To limit access to cluster resources, AKS supports Kubernetes RBAC. Kubernetes RBAC lets you control access and permissions to Kubernetes resources and namespaces.

You can also configure an AKS cluster to integrate with Azure AD. With Azure AD integration, you can configure Kubernetes access based on existing identity and group membership. Your existing Azure AD users and groups can be provided with an integrated sign-on experience and access to AKS resources.

Integrated logging and monitoring

Azure Monitor for Container Health collects memory and processor performance metrics from containers, nodes, and controllers within your AKS cluster and deployed applications. You can review both the container logs and the Kubernetes master logs. This monitoring data is stored in an Azure Log Analytics workspace and is available through the Azure portal, Azure CLI, or a REST endpoint.

Clusters and nodes

AKS nodes run on Azure virtual machines (VMs). With AKS nodes, you can connect storage to nodes and pods, upgrade cluster components, and use GPUs. AKS supports Kubernetes clusters that run multiple node pools to support mixed operating systems and Windows Server containers.

Cluster node and pod scaling

As demand for resources change, the number of cluster nodes or pods that run your services can automatically scale up or down. You can use both the horizontal pod autoscaler or the cluster autoscaler. This approach to scaling lets the AKS cluster automatically adjust to demands and only run the resources needed.

Cluster node upgrades

AKS offers multiple Kubernetes versions. As new versions become available in AKS, your cluster can be upgraded using the Azure portal or Azure CLI. During the upgrade process, nodes are carefully cordoned and drained to minimize disruption to running applications.

GPU-enabled nodes

AKS supports the creation of GPU-enabled node pools. Azure currently provides single or multiple GPU-enabled VMs. GPU-enabled VMs are designed for compute-intensive, graphics-intensive, and visualization workloads.

Confidential computing nodes (public preview)

AKS supports the creation of Intel SGX-based, confidential computing node pools (DCSv2 VMs). Confidential computing nodes allow containers to run in a hardware-based, trusted execution environment (enclaves). Isolation between containers, combined with code integrity through attestation, can help with your defense-in-depth container security strategy. Confidential computing nodes support both confidential containers (existing Docker apps) and enclave-aware containers.

Storage volume support

To support application workloads, you can mount storage volumes for persistent data. You can use both static and dynamic volumes. Depending on the number of connected pods expected to share the storage volumes, you can use storage backed by either Azure Disks for single pod access, or Azure Files for multiple concurrent pod access.

Virtual networks and ingress

An AKS cluster can be deployed into an existing virtual network. In this configuration, every pod in the cluster is assigned an IP address in the virtual network, and can directly communicate with other pods in the cluster and other nodes in the virtual network. Pods can also connect to other services in a peered virtual network and to on-premises networks over ExpressRoute or site-to-site (S2S) VPN connections.

Ingress with HTTP application routing

The HTTP application routing add-on makes it easy to access applications deployed to your AKS cluster. When enabled, the HTTP application routing solution configures an ingress controller in your AKS cluster.

As applications are deployed, publicly accessible DNS names are autoconfigured. The HTTP application routing sets up a DNS zone and integrates it with the AKS cluster. You can then deploy Kubernetes ingress resources as normal.

To get started with ingress traffic, see HTTP application routing.

Development tooling integration

Kubernetes has a rich ecosystem of development and management tools that work seamlessly with AKS. These tools include Helm and the Kubernetes extension for Visual Studio Code. These tools work seamlessly with AKS.

Additionally, Azure provides several tools that help streamline Kubernetes, such as Azure Dev Spaces and DevOps Starter.

Azure Dev Spaces provides a rapid, iterative Kubernetes development experience for teams. With minimal configuration, you can run and debug containers directly in AKS. To get started, see Azure Dev Spaces.

DevOps Starter provides a simple solution for bringing existing code and Git repositories into Azure. DevOps Starter automatically:

• Creates Azure resources (such as AKS);
• Configures a release pipeline in Azure DevOps Services that includes a build pipeline for CI;
• Sets up a release pipeline for CD; and,
• Generates an Azure Application Insights resource for monitoring.

Docker image support and private container registry

AKS supports the Docker image format. For private storage of your Docker images, you can integrate AKS with Azure Container Registry (ACR).

To create a private image store, see Azure Container Registry.

Kubernetes certification

AKS has been CNCF-certified as Kubernetes conformant.

Case Study: WhiteSource simplifies deployments using Azure Kubernetes Service

WhiteSource simplifies open-source usage management for security and compliance professionals worldwide. Now the WhiteSource solution can meet the needs of even more companies, thanks to a re-engineering effort that incorporated Azure Kubernetes Service (AKS).

WhiteSource was created by software developers on a mission to make it easier to consume open-source code. Founded in 2008, the company is headquartered in Israel, with offices in Boston and New York City. Today, WhiteSource serves customers around the world, including Fortune 100 companies. As much as 60 to 70 percent of the modern codebase includes open-source components. WhiteSource simplifies the process of consuming these components and helps to minimize the cost and effort of securing and managing them so that developers can freely and fearlessly use open-source code.

Simplifying deployments, monitoring, availability, and scalability

WhiteSource was looking for a way to deliver new services faster to provide more value for its customers. The solution required more agility and the ability to quickly and dynamically scale up and down, while maintaining the lowest costs possible.

Because WhiteSource is a security DevOps–oriented company, its solution required the ability to deploy fast and to roll back even faster. Focusing on an immutable approach, WhiteSource was looking for a built-in solution to refresh the environment upon deployment or restart, keeping no data on the app nodes.

Finding the right container solution

The WhiteSource development team explored many vendors and technologies in its quest to find the right container orchestrator. The team knew that it wanted to use Kubernetes because it was the best established container solution in the open-source community. The WhiteSource team was already using other managed alternatives, but it hoped to find an even better way to manage the building process of Kubernetes clusters in the cloud. The solution needed to quickly scale per work queue and to keep the application environment clean post-execution. However, the Kubernetes management solutions that the team tried were too cumbersome to deploy, maintain, and get proper support for.

A Microsoft solution specialist demonstrated Azure Kubernetes Service to the WhiteSource development team, and the team knew immediately that it had found the right easy-to-use solution. AKS manages a hosted Kubernetes environment, making it quick and easy to deploy and manage containerized applications — without container orchestration expertise. It also eliminates the burden of ongoing operations and maintenance by provisioning, upgrading, and scaling resources on demand, without taking the application offline. AKS also supported a cloud-agnostic solution that could run the WhiteSource application on multiple clouds.

Architecture

The WhiteSource solution was redesigned as a multicontainer application. The developmental language was mostly Java that runs under a WildFly (JBoss) application server. The application is deployed to an AKS cluster that pulls images from Azure Container Registry and runs in 60 to 70 Kubernetes pods.

The main WhiteSource app runs on Azure Virtual Machines and is exposed from behind a web application firewall (WAF) in Azure Application Gateway. The WhiteSource developers were early adopters of Application Gateway, which provides an application delivery controller (ADC) as a service with Layer 7 load-balancing capabilities — in effect, handling the solution’s front end.

The services that run on AKS communicate with the front end through Application Gateway to get the requests from clients, process them, and then return the answers to the application servers. When the WhiteSource application starts, it samples an Azure Database for MySQL database and looks for an open-source component to process. After finding the data, it starts processing, sends the results to the database, and expires. The process running in the container can be scrubbed entirely from the environment. The container starts fresh, and no data is saved. Then it starts all over.

Containers also make it easy to continuously build and deploy applications. The containerized workflow is integrated into the WhiteSource continuous integration (CI) and continuous deployment in Jenkins. The developers update the application by pushing commits to GitHub. Jenkins automatically runs a new container build, pushes container images to Azure Container Registry, and then runs the app in AKS. By setting up a continuous build to produce the WhiteSource container images and orchestration, the team has increased the speed and reliability of its deployments. In addition, the new CI/CD pipeline serves environments hosted on multiple clouds.

Azure services in the WhiteSource solution

The WhiteSource solution is built on a stack of Azure services that includes the following primary components, in addition to AKS:

• Azure Virtual Machine scale sets are used to run the AKS containers. They make it easy to create and manage a group of identical, load-balanced, and autoscaling VMs and are designed to support scale-out workloads, like the WhiteSource container orchestration based on AKS.
• Application Gateway is the web traffic load balancer that manages traffic to the WhiteSource application. A favorite feature is connection draining, which enables the developers to change members within a back-end pool without disruption to the service. Existing connections to the WhiteSource application continue to be sent to their previous destinations until either the connections are closed or a configurable timeout expires.
• Azure Database for MySQL is a relational database service based on the open-source MySQL Server engine that stores information about a customer’s detected open-source components.
• Azure Blob storage is optimized for storing massive amounts of unstructured data. The WhiteSource application uses blob storage to serve reports directly to a customer’s browser.
• Azure Queue storage is used to store large numbers of messages that can be accessed from anywhere in the world via authenticated calls using HTTP or HTTPS. The WhiteSource solution uses queues to create a backlog of work to process asynchronously.

Using AKS, we get all of the advantages of Kubernetes as a service without the overhead of building and maintaining our own managed cluster. And I get my support in one place for everything. As a Microsoft customer, for me, that’s very important.

Benefits of AKS

The WhiteSource developers couldn’t help comparing AKS to their experience with Amazon Elastic Container Service for Kubernetes (Amazon EKS). They felt that the learning curve for AKS was considerably shorter. Using the AKS documentation, walk-throughs, and example scenarios, they ramped up quickly and created two clusters in less time than it took to get started with EKS. The integration with other Azure components provided a great operational and development experience, too.

Other benefits included:

• Automated scaling. With AKS, WhiteSource can scale its container usage according to demand. The workloads can change dynamically, enabling some background processes to run when the cluster is idle, and then return to running the customer-facing services when needed. In addition, more instances can run for a much lower cost than they could with the previous methods the company used.
• Faster updates. Security is a top priority for WhiteSource. The company needs to update its databases of open-source components as quickly as possible with the latest information. It was accustomed to a more manual deployment process, so the ease of AKS surprised them. Its integration with Azure DevOps and its CD pipeline makes it simple to push updates as often as needed.
• Safer deployments. The WhiteSource deployment pipeline includes rolling updates. An update can be deployed with zero downtime by incrementally updating pod instances with new ones. Even if an update includes an error and the application crashes, it doesn’t terminate the other pods and performance is not affected.
• Control over configurations. The entire WhiteSource environment is set up to use a Kubernetes manifest file that defines the desired state for the cluster and the container images to run. The manifest file makes it easy to configure and create all the objects needed to run the application on Azure.

Thanks for reading this articals…………..