Edit

Migrate from Amazon EKS to Azure Kubernetes Service (AKS)

  • Article

This article provides strategies for migrating typical stateless and stateful workloads from Amazon EKS to Azure Kubernetes Service (AKS).

Considerations

The actual deployment process of a real-world production workload can vary depending on the following factors:

  • Deployment strategies: The choice between GitOps and traditional DevOps Continuous Integration/Continuous Deployment (CI/CD) methods significantly influences the deployment approach. GitOps prioritizes declarative infrastructure managed through version-controlled repositories, while DevOps CI/CD focuses on automated workflows for application delivery.

  • Deployment artifacts: The selection of deployment artifacts plays a crucial role in defining the deployment structure. YAML files, manifest files, Helm charts, and Kustomize configurations represent various approaches to specifying and customizing deployment settings, each with its strengths and use cases.

  • Workload authentication and authorization: Depending on the setup, authentication and authorization methods can differ. You can use Amazon Web Services (AWS) Identity and Access Management (IAM) roles, workload identity mechanisms, or connection strings for access control.

  • Monitoring: Implementation of monitoring solutions is a critical aspect that can involve various tools and methodologies to ensure the performance and health of the deployed workloads. For more information on how AKS monitoring compares to EKS, see Kubernetes monitoring and logging.

Before beginning your migration, review and consider the following general guidance and best-practice resources:

  • Review the cluster operator and developer best practices.
  • Define the monitoring and alerting strategy to ensure the application is performing as expected.
  • Define the security and compliance requirements for the application and the AKS environment.
  • Define the access control policies and how they're enforced. Identify any compliance standards that must be adhered to.
  • Define the disaster recovery and business continuity plan for the AKS environment and the application.
  • Define the backup and restore policies and procedures. Identify the recovery time objective (RTO) and recovery point objective (RPO).
  • Identify any risks or challenges that might be encountered during the deployment.
  • Test the functionality to ensure the application works as expected before redirecting live traffic to the new AKS cluster.

Workload migration considerations

This section reviews some things you should consider before migrating your workloads from Amazon EKS to AKS.

Understand your existing Amazon EKS environment

Analyze the existing EKS environment to understand the current architecture, resources, and configurations.

  • Review EKS configuration: Assess EKS cluster configuration, such as node types, number of nodes, Kubernetes version and support policy, and scaling configuration.

    Note

    EKS allows the creation of custom AMI images for EKS nodes. AKS doesn't allow the use of custom node images. If your deployment requires node customization, you can apply kubelet customization and/or DaemonSets to customize your nodes.

  • Review application workloads: Identify all the Kubernetes workloads running on the EKS cluster including deployments, services, stateful sets, ingress configurations, and persistent volume claims. Ensure you have a complete list of applications and their associated resources.

  • Check dependencies: Identify any dependencies on AWS services specific to EKS.

    AWS service Dependency
    AWS Secret Manager Azure Key Vault
    AWS Guard Duty Agent Microsoft Defender for Containers
    EKS Pod Identity Agent Microsoft Entra ID Workload Identity
    Amazon Elastic File System (EFS) or Elastic Block Store (EBS) Container Storage Interface (CSI) drivers AKS CSI Drivers

  • Backup EKS cluster: You can use a non-Microsoft tool like Velero to back up and migrate Kubernetes resources and persistent volumes.

Prepare the Azure AKS environment

The Amazon virtual private cloud (VPC) Container Networking Interface (CNI) is the default networking plugin supported by EKS. An AKS cluster supports multiple network plugins and methods to deploy a cluster in a virtual network, including:

To prepare your AKS cluster, follow these steps:

  1. Create a new AKS cluster in Azure, configuring the desired networking settings to match your requirements.
  2. Review your Kubernetes manifests and YAML files used in EKS. Check for any potential Kubernetes API version incompatibility or specific EKS configurations that AKS doesn't support.
  3. Ensure that your Docker images and container image registry location are accessible from the AKS cluster. Verify network connectivity and any required authentication and authorization settings for accessing the images.

By following these steps, you can successfully create an AKS cluster and ensure compatibility for your Kubernetes manifests and Docker images, ensuring a smooth migration process from EKS to AKS.

Migration overview

Migrating from Amazon EKS to AKS involves several steps, such as:

  • Container image migration: Migrating container images is a crucial step when moving from EKS to AKS. You can use tools like kubectl, Docker, or container registries to export and import images.

    1. Export Images from EKS.
    2. Set up an Azure Container Registry and attach it to AKS if you haven't already.
    3. Push images to Container Registry.

    Container images can also be imported into Container Registry directly from a non-Azure public or private repository. For more information, see Import container images.

  • Kubernetes manifest migration: AKS uses the Kubernetes YAML file manifest to define Kubernetes objects. Deployments are typically created and managed with kubectl create or kubectl apply. Create a deployment by defining a manifest file in the YAML format. For more information, see this sample AKS manifest. You can learn more about how YAML files work on Kubernetes by reviewing Deployments and YAML manifests.

  • Data migration: Carefully plan your migration of stateful applications to avoid data loss or unexpected downtime. For more information, see the section Stateful workload migration considerations.

Stateless workload migration considerations

Migrating your Kubernetes manifests involves adapting the configuration to work in the Azure environment, including these steps:

  1. Update manifests: Update your Kubernetes manifests to use the new image locations in Container Registry. Replace the image references in your YAML files with the Container Registry path.

    1. Review your existing Kubernetes manifest files for AWS-specific configurations, such as VPC and IAM roles.
    2. Review the EKS IAM roles associated with nodes, service accounts, and other resources. Map it with equivalent Azure AKS role-based access control (RBAC) roles. For more information, see Kubernetes workload identity and access.
    3. Modify the manifest files to replace AWS-specific settings with Azure-specific settings, like annotations.

  2. Apply manifests to AKS:

    1. Connect to AKS Cluster.
    2. Apply the modified Kubernetes manifest files using kubectl apply -f.

Stateful workload migration considerations

If your applications use Persistent Volumes (PVs) or Persistent Volume Claims (PVCs) for data storage, make sure you back up this data. You can use tools like Velero to perform cluster backups, including for PVs and PVCs data. For more information, see Backup and restore your Amazon EKS cluster resources using Velero.

Stateful applications typically have persistent data storage requirements, which add complexity to the migration process. For a comparison of the storage capabilities of Amazon EKS and AKS, see Storage options for a Kubernetes cluster.

Follow these steps to back up persistent data:

  1. Set up Velero in AKS and EKS cluster.
  2. Perform a backup of your EKS cluster.
  3. Copy the Velero backup from S3 bucket to Azure blob storage, by using the az copy command.
  4. Since AKS and EKS might use different storageClassNames for the persistent volume claims, create a configMap that translates the source storageClassNames to an AKS-compatible class name. You can ignore this step if you're using the same storage solution on the EKS and the AKS Kubernetes clusters.
  5. Restore the backup to AKS (using Velero restore command).
  6. Apply necessary changes to the restored objects, such as references to container images in Amazon Elastic Container Registry (ECR), or access to secrets.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal authors:

  • Dixit Arora | Senior Customer Engineer, ISV DN CoE
  • Ketan Chawda | Senior Customer Engineer, ISV DN CoE

Other contributors:

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps