Migrating On-Premises Kubernetes to Amazon Elastic Kubernetes Service (EKS)

As a long-standing partner with the largest public cloud hyperscalers (AWS, Google Cloud and Azure), WWT has performed many types of cloud migrations for our clients over the years, each with their own unique challenges. A common type of migration we've encountered involves migrating containerized services from on-premises Kubernetes to Amazon's Elastic Kubernetes Service (EKS).

This article provides an overview of the framework and methodology we use for migrating such workloads to the AWS cloud, including useful insights into the key differences between on-premises Kubernetes and Amazon EKS.

On-premises Kubernetes

Using on-premises Kubernetes typically gives an organization greater control and management capabilities, but at a significant cost. It also offers faster integration into processes with fewer challenges. Yet when a process is completely on-premises, it's rarely re-evaluated until it breaks or a new license is required to maintain it.

Given the benefits, most data centers still fall short in comparison to the standards and distribution AWS has achieved in the cloud. Upgrading on-premises Kubernetes processes can be arduous, especially given the volume of releases and the speed at which enterprises perform upgrades. Teams can quickly become buried by the feature parity of newer releases. It's even common for enterprises to dedicate whole teams to the upgrade process, which can get very expensive very fast.

AWS Elastic Kubernetes Service

Amazon EKS is a managed Kubernetes service designed to run Kubernetes in the AWS cloud and in on-premises data centers. Plus, it now supports control-plane logging into CloudWatch for enhanced audit and diagnostic purposes.

Given their responsibility for hosting the cluster, AWS ensures every aspect remains documented and evaluated. This results in fewer cracks in the design and an overall stronger, more holistic solution. Additional benefits of AWS-hosted EKS include a shared security model, cluster availability SLAs, and windows node support (which is desirable for many clients).

Moreover, EKS makes it easy to test different cluster versions (e.g., one cluster can run version 'A' and another at version 'B' to easily facilitate workload testing). This also helps to simplify version moves and reduce management overhead.

As a certified Kubernetes conformance, AWS EKS can help organizations with their compliance needs. Many other certifications are likewise pre-built into AWS' service.  

Our migration methodology

At a high level, our phased migration process follows this general outline:

1. Who, why, what
2. On-premises environment details (virtual machines, networking, certs/keys, Kubernetes configs, etc.)
3. Development lifecycle assessment
4. CI/CD assessment
5. Migrate workload

Let's review some nuances about these steps.

Who, why, what phase

At the outset, we always gather the business case and desired outcomes behind the who, why and what of each migration:

• Who: Who is the business owner of the workload?
• Why: Why is the workload being migrated? This comes from the business success criteria; the answer can be as simple as "to reduce data center costs, staffing overhead, etc."
• What: What workload should be migrated first? This helps shake out the details re: what success looks like and what to expect with the rest of the workloads.

Business owners typically have an intimate understanding of the workload in scope for migration. Because they hold all the keys, building a relationship with them is critical to this initial portion of the process. Most of the time they won't know what the business success criteria, and they'll have a separate set of criteria they want to accomplish beyond the migration.   

For example, a business owner says, "we do not have Splunk working with this workload. We need this to be working in the cloud." This is a specific success criteria, where the broader success criteria might be: "migrate these workloads to the cloud." 

The quickest route to achieving an outcome involves picking the simplest workload (i.e., the lowest hanging fruit) for a pilot migration. This initial workload will be used to validate the new environment's design and operational readiness.

On-prem environment details phase

Once the who, why and what are understood, we then dive into the details of the on-premises environment. This includes assessing network hardware, software, ports and container-specific details. It's extremely important to establish a performance baseline, which helps to validate the subsequent success of the migration. 

It's also critical to gather detailed information on the client's existing containers: HD, MEM, CPU, PORTS and STORAGE. Next, we'll need details on the ACLs, firewalls, routing, DNS and all things networking.

After capturing this type of workload information, we move into analyzing the current Kubernetes cluster. We've found that a good way to begin involves looking at what version of Kubernetes is running on-premises and comparing that to what version EKS is able run in AWS, as versions update fairly quickly.

Connectivity and storage

After the EKS version is decided, the next step is to evaluate the type of networking being used on-premises for Kubernetes, making note of the type of networking modules deployed. It's important to reflect this in EKS, if possible. 

During this discovery phase, we note any tools used to build workload layers, such as Helm or Helm-like solutions, which can deploy to Kubernetes. Having these tools in mind during migrations is key. There are different approaches to deploying workloads to the cloud; while using the same method for on-premises can work, many times it does not.

On-premises storage is far different from cloud storage. We typically recommend moving to cloud-native storage and testing these newer solutions. If needed, clients can always consider traditional storage vendors with cloud-based products.

We've found that hybrid solutions often cost too much to be considered, and the speed is not comparable. Remember that data in transit needs to be encrypted, especially moving between private and public data centers.

Communication

Workload dependencies are crucial to discover and understand. In many cases, the workload will rely on a large database. Sometimes, this database is so large that moving it to the cloud can appear daunting. Don't worry! It's important to know that cloud-based database solutions offer capabilities that can often be more advantageous than on-premises solutions.

Most companies have visibility into their workloads and leverage application logging and monitoring tools. If this is an afterthought, though, it can make troubleshooting application performance difficult. There are many cloud-native monitoring options in the market; choosing the right one often requires a balance between meeting technical requirements and your comfort with change.

Configuration and DNS

When designing the AWS EKS environment, it's important to understand the current config and see what needs to be adapted to the EKS environment. If you have a team that manages DNS, they might need to play with the on-premises Kubernetes DNS functionality. It is important to get an understanding of their control and to see if it's suitable to allow EKS to manage the Kubernetes DNS via the Ingress controller.

Geo-location

Finally, we consider where workloads will be accessed from. When deciding where to deploy EKS, it's important to understand the geographical considerations of your customer base. We recommend deploying into the AWS region that is closest to your user base, using AWS Local Zones, or setting up methods to get access to the AWS backbone via points of presence, such as CloudFront.

Development lifecycle assessment phase

Understanding the development lifecycle of EKS workloads is critical. Some companies are so large that each workload could be its own business, operating in its own unique manner.

That's why we always ask about the software development lifecycle for each workload. Understanding the criteria for a successful code promotion to production is helpful. We also research the change request/emergency change request process and how long requests normally take to process. If scheduling for the change request process is overlooked, the migration can hit speed bumps. 

CI/CD assessment phase

Next, we ensure that we fully understand the CI/CD deployment processes, as well as the schedule for updates and release candidates. Some workloads are very agile, so it's important to be prepared for executing as fast as possible. 

Either DevOps engineers or software developers are typically the gatekeepers of the CI/CD process. Understanding the process and all the systems that are utilized during the pipeline will help with migration planning.

When choosing the pilot workload, it's best to pick one that will touch on the majority of the key components shared by all workloads. We always seek to understand the processes and get the correct teams involved in information gathering.

Migrate workloads phase

Once the foundation has been built, the final task is migrating workloads to the AWS public cloud.

Standing up Amazon EKS

A Well-Architected AWS environment is required before migrating any workloads. That means an EKS cluster must be available to land the workload on. We use all the information gathered to help define this environment. 

Below are the generic items needed for an EKS cluster build:

1. Cluster
2. Member roles
3. Labels and annotations
4. Account access
5. Cluster options
6. Fargate
7. VPC and subnet

Migration to AWS public cloud

There is much to consider before migration can begin. It's common to deploy, test, change and deploy, test, change until finding a working balance. The workload will be viable, but the connection of all other items related to the workload can cause sprawl. Stay focused and make sure to stick with the business success criteria as a guide.

After the first workload is running in EKS successfully, we then rinse and repeat for the next workloads. At this point, all the required information one would need to start projecting timelines should be readily available for additional migrations. It's typical to use the data that was collected up to this point to define a path for all future workloads.  

At this stage, we can create a pattern for all the parts we've covered, taking into consideration all decisions made about size, storage and accessing the cloud. This process can be used to refine and optimize your cloud environment, setting your organization up for more efficient outcomes through subsequent phases of cloud adoption.

Need help with next steps?

We help clients across industries simplify the process of migrating applications to the right cloud environment for their business. Reach out to your account team today to learn more about our migration capabilities and our close partnership with AWS.