Migrating a web application to Azure Kubernetes Service (AKS) involves careful planning and consideration to ensure a successful and smooth transition. As you analyze your application's architecture to determine its suitability for containerization and microservices this list attempts to provide guidance and key considerations to keep in mind during the migration process.
| Topic | Guidance |
|---|---|
| Azure subscription that will host App Service Plan and other required services. | Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings |
| Service Level Agreements (SLA) for Online Services | Licensing Documents (microsoft.com) |
| Requirement of advanced configuration for the application workload to adhere to regulatory compliances. | Azure compliance documentation |
| Security | Container security protects the entire end-to-end pipeline from build to the application workloads running in Azure Kubernetes Service (AKS). Kubernetes includes security components, such as pod security standards and Secrets. Azure includes components like Active Directory, Microsoft Defender for Containers, Azure Policy, Azure Key Vault, network security groups, and orchestrated cluster upgrades. See guidance provided here Security concepts for applications and clusters in Azure Kubernetes Service |
| BCDR Requirements | When your applications store and consume data persisted on disks or in files, you need to take regular backups or snapshots of that data, back up your data using an appropriate tool for your storage type, such as Velero or Azure Backup. Verify the integrity and security of those backups. Azure Backup now allows you to back up AKS clusters (cluster resources and persistent volumes attached to the cluster) using a backup extension Velero (formerly Heptio Ark) gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a public cloud platform or on-premises. |
| Topic | Guidance |
|---|---|
| Application Architecture | Analyze your application's architecture to determine its suitability for containerization and microservices. Identify stateless and stateful components that need to be migrated. |
| Application Containerization | Containerize your application, Azure Migrate offers a unified platform to assess and migrate to Azure on-premises servers, infrastructure, applications, and data. For AKS, you can use Azure Migrate for the following tasks: -Containerizing ASP.NET applications and migrating to AKS. -Containerizing Java web applications and migrating to AKS |
| Windows Nodes | The following limitations apply to Windows Server node pools: AKS supports Windows Server 2019 and 2022 node pools. Windows Server 2022 is the default operating system for Kubernetes versions 1.25.0 and higher. Windows Server 2019 is the default OS for earlier versions. -The AKS cluster can have a maximum of 10 node pools. -The AKS cluster can have a maximum of 100 nodes in each node pool. -The Windows Server node pool name has a limit of six characters. Limitations |
| Monitoring | AKS generates the same kinds of monitoring data as other Azure resources that are described in Monitoring data from Azure resources. See Monitoring AKS data reference for detailed information on the metrics and logs created by AKS. AKS generates the same kinds of monitoring data as other Azure resources that are described in Monitoring data from Azure resources. See Monitoring AKS data reference for detailed information on the metrics and logs created by AKS. Refer to Monitor Azure Kubernetes Service (AKS) |
| Cost Optimization | Cost optimization is about understanding your different configuration options and recommended best practices to reduce unnecessary expenses and improve operational efficiencies. Before you use this article, you should see the cost optimization section in the Azure Well-Architected Framework. When discussing cost optimization with Azure Kubernetes Service, it's important to distinguish between cost of cluster resources and cost of workload resources. Cluster resources are a shared responsibility between the cluster admin and their resource provider, while workload resources are the domain of a developer. Azure Kubernetes Service has considerations and recommendations for both of these roles. Refer to Optimize costs in Azure Kubernetes Service (AKS) |
| Scaling | Azure Kubernetes Service (AKS) can be scaled-in and out depending upon infrastructure needs (requiring more or less capacity), adding node pools with special capabilities like GPU, or application needs, in this case you have several factors like number and rate of concurrent connections, number of requests, back-end latencies on AKS applications. The most common scalability options for AKS are the cluster autoscaler and the horizontal pod autoscaler. The cluster autoscaler adjusts the number of nodes based on the requested compute resources in the node pool. The horizontal pod autoscaler (HPA) adjusts the number of pods in a deployment depending on CPU utilization or other configured metrics. Scalability considerations for Azure Kubernetes Service environments |
| Topic | Guidance |
|---|---|
| Virtual Directory/Filesystem | It is a common practice to store web app content under site root or on the mounted virtual directories. Any files that require persistent changes will be reset during pod restarts and will not transfer across pods. It is recommended that any files that have changes that need to persist to store them in a persistent volume mounted to the node. External storage guarantees the maintenance of files and is accessible across all pods which supports consistency across all instances of the application. Find more info here about the different types of storage you can mount to identify the option that best fits your applications data storage requirements. |
| Registry | Applications writing to the registry are supported in AKS, but since containers are stateless, you should be mindful of these actions because anything that needs to persist beyond the life of the pod will be reset when the pods are destroyed or restarted. |
| Session Management and Caching | It is common to use session state in .NET Core to manage user information and to create sticky sessions. Since containers are stateless, it is recommended to transition state management models to use services such as Redis Cache to store the session information outside of the cluster to prevent deletion when pods are destroyed or restarted. This model also helps reduce memory consumption on the container. Please refer to documentation on using Azure Redis Cache for state management for .NET Core. |
| Domain Services | AKS supports Windows Authentication and Group Managed Service Accounts (GMSA) through a PowerShell module. If your application is using Windows Authentication and/or GMSA with an on-premises domain controller, it is recommended that you create a 2nd domain controller in Azure that is synced to your on-premises Domain Controller. The Azure Domain Controller reduces latency for authentication requests for your application and simplifies the networking required to connect your application to your on-premises resources. See our HoL 1 for an example of how to setup your Domain Controller in Azure. |
| Reliability | A reliable web application is one that is both resilient and available. Resiliency is the ability of the system to recover from failures and continue to function. The goal of resiliency is to return the application to a fully functioning state after a failure occurs. Availability is a measure of whether your users can access your web application when they need to. You should use the Retry and Circuit Breaker patterns as critical first steps toward improving application reliability. These design patterns introduce self-healing qualities and help your application maximize the reliability features of the cloud. Pay particular attention to your application’s startup code (for example, your project’s startup.cs, deferred initialization of services in your IoC container, etc.). While not required for a successful migration, you’ll gain full advantage of AKS’s horizontal pod autoscaler (HPA) features by ensuring that your application can start reliably. |
| Topic | Solution |
|---|---|
| Scaling | .NET Framework applications and some .NET Core applications require Windows for their runtime environment. Windows images are generally larger than Linux images, and with .NET framework, the container image size increases drastically. When using Windows containers on AKS, it is recommended to keep your container images as lean as possible to facilitate auto-scaling to support load on your application. Using a base Windows Server 2022 image, multi-stage build and installing application dependencies on top are a few of the things that keep the image as small as possible. It is also recommended to set your image pull policy to IfNotPresent so that any new pods utilize the image cached on the node. For example, if your image is 10 GB, every time you need to scale to support incoming requests, your cluster has to spin up another 10GB pod and if it also has to pull the image from a remote image repository, it could take several minutes for that pod to come online. For more information on how to handle scaling with Windows containers on AKS, check out the documentation in the Azure Architecture center. |
| Ingress | Windows Containers are supported by most ingress controllers with a couple of caveats.
|