Disposition strategy and planning for migrating Kubernetes clusters

Introduction

Migrating Kubernetes clusters can be a complex and challenging task, requiring careful planning and execution to ensure a smooth transition. A key aspect of this process is the disposition strategy – the approach taken to determine the fate of the existing cluster and resources as the migration occurs.
Effective disposition planning is crucial for minimizing downtime, data loss, and disruption to ongoing operations. It involves deciding which workloads and assets to migrate, which to retire, and which to re-architect or reconfigure for the new environment. This process must balance factors like cost, performance, security, and regulatory compliance to ensure the target environment meets the organization’s needs.
Developing a robust disposition strategy requires thoroughly understanding the current Kubernetes infrastructure, applications, and data. It also necessitates close collaboration between IT, DevOps, and application teams to align on requirements, priorities, and timelines. Only by taking a methodical, cross-functional approach can organizations successfully plan and execute a Kubernetes migration that optimizes for the long-term.
This introduction provides an overview of the importance of disposition strategy in Kubernetes migration projects, highlighting the key considerations and challenges involved. The following sections will dive deeper into the migration framework and best practices for developing and implementing an effective disposition plan.

Why Move to a Managed Service?

Migrating to a managed service such as Amazon Elastic Kubernetes Service (Amazon EKS) can offer numerous benefits for organizations running Kubernetes-based platforms. As a managed Kubernetes service, EKS abstracts away much of the underlying infrastructure complexity. This allows teams to focus on building and running applications rather than managing the Kubernetes control plane. EKS provides high availability and scalability out-of-the-box. It has tight integration with other AWS services like AWS Identity and Access Management (IAM), Amazon Virtual Private Cloud (VPC), and Amazon CloudWatch for enhanced security, networking, and observability. This can lead to reduced operational overhead and increased reliability compared to self-managed Kubernetes clusters. Additionally, EKS simplifies the upgrade process by launching new API server nodes with the updated Kubernetes version to replace the existing ones.

The Kubernetes landscape includes various options, such as managed services from other cloud providers and Platform-as-a-Service (PaaS) offerings. While these alternatives can provide value in certain scenarios, EKS stands out by abstracting away infrastructure complexity and tightly integrating with the broader AWS ecosystem. This can simplify operations, enhance reliability, and enable seamless access to AWS services – key advantages for organizations invested in the AWS platform.

AWS Migration Framework

AWS has formulated a three-phase migration process designed to help approach migrations at scale. AWS approaches migrations in three phases: Assess, Mobilize and Migrate.

Fig 1. AWS Migration Framework

Assess

The Assess phase of a Kubernetes migration begins by establishing a solid business case for the change. This involves validating the underlying rationale and quantifying the expected benefits, whether they be cost savings, improved reliability or increased agility. Next, a thorough assessment of the existing Kubernetes cluster(s) is conducted. This includes identifying a discovery tool (such as Matilda Cloud or ModelizeIT) to discover clusters in their current landscape, evaluating the current version of Kubernetes, assessing the security posture, and reviewing the networking configuration to identify any potential issues or areas for improvement. An application discovery and inventory process is completed to understand workloads and components that need to be migrated. This provides visibility into the existing landscape and helps form the overall migration strategy.

Finally, the assessment phase involves evaluating replication tools that can facilitate the efficient and reliable migration of Kubernetes resources, such as infrastructure configurations, applications, and data to the new environment. Selecting the right set of tools is critical to ensuring a smooth transition with minimal downtime or data loss. By thoroughly assessing the current state in this phase, organizations can develop a robust migration plan that addresses the technical, operational, and business requirements for transitioning to a new Kubernetes platform.

Mobilize

In Mobilize we build readiness through experience. This phase lays the foundation for your applications, tooling, governance and operating model, processes and skills gap. We create the translated architecture and build the landing zone for the Kubernetes cluster in this phase. We setup infrastructure provisioning to build a rapid Proof of Concept (PoC).

In this phase, we build the translated architecture from on-prem Kubernetes setup to EKS environment. This includes mapping existing configurations to AWS components like Amazon VPC, AWS IAM and Amazon Elastic Compute Cloud (EC2) or AWS Fargate to run workloads. By building this translated architecture, we create a foundation or landing zone for migrating workloads at scale. One of the recommended approaches here is to use EKS Blueprints to provision your EKS Cluster, this comes with a well-architected setup and a wide range of popular open-source add-ons, including Prometheus, Karpenter, Nginx, etc.

Once the translated architecture is created, we create a migration wave plan. More information about creating a wave plan can be found here.

We also conduct Immersion Days and workshops on EKS to help the teams gain hands-on experience. This aims at empowering the teams with the necessary skills to effectively operate EKS after migration. This ensures that teams are well-prepared and reduces the risk of operational challenges during and after the migration.

Migrate and Optimize

In Migrate, we start migration at scale based on the experience built from the Mobilize phase. Teams can now plan and execute a phased migration approach using the wave plan to minimize disruption. In this phase, we will need to migrate container images to an image repository. Possible locations are Amazon Elastic Container Registry (Amazon ECR) or any third-party repository on AWS. Kubernetes resources, manifests, persistent volumes and data stores also need to be migrated to the EKS environment. Then, they build CI/CD pipelines to automate the build, test and deployment process to the clusters. Additionally, organizations can fine-tune EKS clusters to optimize resource utilization, networking, storage, etc. You could also implement cost optimization strategies such as right-sizing instances, and leveraging spot instances to manage the cost of the EKS cluster.

Key considerations

When you are planning to migrate a self-managed Kubernetes cluster to EKS, there are several key considerations to keep in mind for a seamless and successful transition.

Thorough Workload Assessment

In the assess phase above, we examined how a detailed assessment of your workloads in advance is essential to minimize roadblocks during the migration process. Additionally, start by performing an application compatibility assessment to ensure that your applications are compatible with the Kubernetes version and features offered by EKS. Verify that the EKS version you plan to migrate to supports the required Kubernetes Feature Gates, Admission Controllers, and API versions needed by your workloads and platform. It’s also crucial to migrate to the same Kubernetes version as your self-managed cluster to avoid API inconsistencies. Review your resource allocation strategy and understand how it differs between your self-managed Kubernetes and the EKS environment. This will help you plan the resource provisioning and data migration for your stateful applications within the cluster, ensuring a smooth transition. Assess the application downtime requirements and develop a well-crafted cutover plan to avoid any disruption to your business operations. When planning the migration waves, it’s recommended to start with simple, stateless applications to minimize risk.

Networking and Security

Carefully plan the security requirements for each workload based on the application’s usage, integration, and configuration needs. Leverage Role-Based Access Control (RBAC) and implement EKS pod identity or IAM roles for service accounts (IRSA) to grant fine-grained permissions to pods accessing AWS resources, following the principle of least privilege. Enable encryption on Amazon EBS volumes and Etcd encryption to protect your data and Kubernetes secrets at rest. Consider enabling private access to the Kubernetes API server and secure the communication between the Kubelet and API server within your VPC. Utilize the Amazon VPC CNI and AWS Load Balancer Controllers to ensure seamless networking and load balancing within the EKS environment.

Comprehensive Testing

In addition to functional testing, it’s crucial to carry out stress tests to validate application performance and identify any latency issues introduced by the migration. Thoroughly test the integration with third-party systems to ensure a successful transition. Wherever applicable, consider using the blue/green or canary deployment methods to avoid business disruption during the migration process.

Leverage Tooling

Take advantage of the various tools and utilities available in the AWS ecosystem to streamline the migration process. Leverage CloudFormation, Terraform, or the AWS CLI to automate the provisioning and configuration of your EKS cluster and supporting resources.

Continuous Optimization

Migrating to EKS should not be viewed as a one-off event. Continuous monitoring of the cluster’s health and performance post-migration is essential. If you intend to use AWS-native observability solutions, tools like Amazon CloudWatch, and AWS X-Ray can be utilized to monitor your EKS cluster. If you prefer open-source solutions, Amazon Managed Service for Prometheus, Grafana, and Amazon OpenSearch service can be leveraged. Regardless of the tooling choice, it’s crucial to continuously optimize your infrastructure and application configurations to ensure optimal performance and reliability.

By addressing these key considerations, you can ensure a successful and seamless migration of your self-managed Kubernetes cluster to EKS, leveraging the benefits of a fully managed Kubernetes service and positioning your organization for long-term scalability and resilience.

Migration workflow with disposition strategies

Relocate

Fig 2. Relocate disposition strategy

The Relocate disposition strategy provides a systematic approach to migrating Kubernetes-based applications to Amazon EKS. The process begins with a comprehensive discovery and assessment of the existing Kubernetes clusters and applications. Next, a target Amazon EKS cluster is provisioned to serve as the destination for the migration. The Kubernetes manifests and Helm charts used to deploy the application are then migrated, with minimal or no changes required. A common change would be changing image URLs since you’ve migrated the container image to a new container registry. Any associated data is also relocated to suitable AWS storage options, such as Amazon Simple Storage Service (Amazon S3) or Amazon Elastic File System (Amazon EFS), to ensure a seamless transition. For pods using EBS volumes or other persistent storage types, you can use a Kubernetes backup and restore tool, Velero.

Once the application components have been migrated, the application is deployed on the new Amazon EKS cluster. Rigorous validation and testing are conducted to ensure the migrated application functions as expected. Finally, the DNS record is updated to redirect traffic to the newly deployed, production-ready application on Amazon EKS. This Relocate workflow enables organizations to efficiently move their Kubernetes-based workloads to the scalable and managed Amazon EKS service.

Replatforming

Fig 3. Replatform disposition strategy

The process of replatforming Kubernetes applications to EKS involves a well-defined workflow. It builds on top of the relocate approach where we leverage custom integration with other AWS services to increase cloud value realization. First, we will need to discover and assess your existing Kubernetes clusters to understand the current state of your infrastructure. This includes identifying the cluster configurations, deployments, and any dependencies. Next, you’ll create a target EKS cluster in AWS, which provides a managed Kubernetes control plane and worker nodes.

With the target EKS cluster in place, you can then migrate your Kubernetes manifests or Helm charts to the new environment. This ensures your application configurations and deployments are seamlessly transferred. Additionally, you’ll need to migrate any persistent data to AWS storage solutions, such as Amazon EBS or Amazon EFS, with minimal or no changes to your application.

Once the application is deployed on the EKS cluster, you can integrate other AWS services to enhance its functionality. This may include setting up databases using Amazon Relational Database Service (Amazon RDS), load balancers using AWS Load Balancers, observability tools using Amazon managed service for Prometheus or AWS Distro for OpenTelemetry (ADOT). These managed services from AWS help streamline the deployment and management of your Kubernetes-based applications.

After thorough validation and testing, you can finally cutover traffic using DNS to the production EKS cluster, making the migrated application accessible to your users.

This end-to-end workflow ensures a smooth and efficient transition of your Kubernetes applications to the EKS platform, leveraging the scalability, reliability, and managed services provided by AWS.

Rearchitect/Refactor

Fig 4. Rearchitect/Refactor disposition strategy

The journey of refactoring or rearchitecting Kubernetes applications often begins with identifying the right modernization pattern such as, breaking down monolithic applications into a microservices-based architecture. By decomposing the monolith into smaller, independent services, you can unlock the benefits of scalability, resilience, and easier maintenance. As you define the target microservices architecture, you’ll need to carefully plan the integration with various AWS services, such as managed databases, storage solutions, and serverless components, to create a robust and cloud-native ecosystem.

Migrating the application data to AWS storage options, like Amazon S3 or Amazon EFS, with minimal or no changes ensures a seamless transition and preserves data integrity. Once the refactored applications are ready, you can deploy them on the EKS platform, taking advantage of its managed Kubernetes capabilities.

To streamline the development and deployment process, you’ll implement a CI/CD pipeline tailored to the new EKS cluster. This automated workflow will handle the building, testing, and deployment of the refactored applications, ensuring consistency and reliability.

This comprehensive refactoring or rearchitecting approach empowers organizations to modernize their Kubernetes-based applications, improve scalability, and leverage the vast ecosystem of managed services offered by Amazon Web Services.

Conclusion

By developing a robust disposition strategy, organizations can effectively assess existing Kubernetes resources and optimize the move to the managed EKS service. The key is to take a methodical, phased approach that begins with a thorough assessment of the current Kubernetes landscape. This provides the necessary visibility and baseline to make informed decisions about which workloads to rehost, replatform, or rearchitect as part of the migration.

Leveraging AWS tools and services can significantly streamline the migration process. From automating infrastructure provisioning to integrating with other AWS offerings, the AWS ecosystem enables organizations to maximize the benefits of EKS, such as improved reliability, scalability, and operational efficiency. Continuous optimization is also crucial. By closely monitoring the health and performance of the EKS environment post-migration, organizations can further tune their infrastructure and application configurations to ensure optimal long-term outcomes. With a well-crafted disposition strategy and a phased migration approach, organizations can unlock the full potential of Amazon EKS, positioning their Kubernetes-based workloads for greater agility, resilience, and cost efficiency in the cloud.