From Zero To Kubernetes In Production In 90 Days

Foreword

Most Kubernetes implementations don’t have the luxury of starting a new environment from scratch.

Most of the time, our implementations are projects that migrate existing production applications to run on newly-created Kubernetes environments.

We’ve been through this situation many times, so we thought it would be helpful to give you a high-level step-by-step overview of a typical migration process. Obviously your situation may differ, so plan on some level of readjustment based on our preliminary conversations.

Stage 1: Review & Create A Plan

In this stage, we want to learn as much as possible about your current operations.

Here are the important topics we will explore in more detail with you:

1. How are features built and delivered from idea to production?
2. How complicated are your CI/CD scripts?
3. Are you using any custom CLI or deployment tools?
4. What is your current VPC architecture?
5. What are your security requirements?
6. Are you running your own database-like services?
7. Which monitoring tools are you currently using?

Answering these questions will help us prepare a detailed plan of action and make sure we won’t uncover surprises later in the implementation.

Stage 2: Migrate Non-Production Environments

After we understand every aspect of your needs and expected outcomes, we will start migrating your stack to run on Kubernetes. To reduce the risk of downtime, we’ll start with non-production environments first.

We typically take these actions in this order:

1. Create the necessary VPC architecture and Kubernetes cluster components
2. Set up access control roles based on security requirements
3. Dockerize all the application components
4. Integrate Docker build, push and deployment steps into existing CI/CD pipelines
5. Setup additional Kubernetes services, such as:
6. Cloud load balancer setup (aka ingress controller)
7. DNS automation
8. Ephemeral services needed for unit and integration tests like temporary databases
9. Autoscaling configuration for application components and cluster nodes
10. Feeds of monitoring and logs data to existing services

At the end of this stage, every new commit will eventually be built and deployed to Kubernetes. However, the application components will continue to serve the customers from existing environments.

Stage 3: Training

If no one on your team can use Kubernetes effectively, you’re going to miss the majority of benefits Kubernetes provides.

The main goal of this phase is to help your whole team understand the important concepts they need to use Kubernetes on a daily basis and get familiar with the Kubernetes’ API and CLI.

We’ll run a hands-on training session for your entire dev team and include a more intensive training for key team members who will be responsible for maintaining the Kubernetes environment into the future.

Stage 4: Prepare The Production Environment

During this stage we want to make sure all the needed configurations have been completed to ensure a zero-downtime switchover.

In addition to setting up a new, separate production cluster, we’ll run the following tests to verify that everything is ready for the switchover:

1. Run a load test to test CPU and memory configurations
2. Run a few autoscaling scenarios to verify that the production cluster can scale to meet the expected load
3. Verify we can access the monitoring dashboards, alerts and container metrics
4. Check that key team members are able to access the cluster resources and know how to respond in case of a downtime

Stage 5: Perform The Switchover

Usually this step takes less than a few hours and can be done during off-hours, when you expect to have the least amount of customer activity.

We’ll perform a set of final availability checks and will gradually transition live traffic to the new system using DNS. Since we didn’t migrate any stateless applications, both the old and the new system will be communicating with the same databases. This will allow us to make a gradual transition instead of a hard cut-off.

Stage 6: (Optional) After-Care

One of the main drawbacks of Kubernetes is that it has a pretty steep learning curve. It may take time for the new tools and concepts for be second-nature for your team.

The transition will be much easier if you make sure additional support is in place in case some team members need it.

Other companies have kept us onboard for an extra month or two while the team gets acclimated, and that has made a smoother adjustment for everyone.

These support services can provide assistance for day-to-day operations or for emergency support related to production issues.

Summary

If you’re running a medium-sized environment with less than 15 micro-services, most of the time it will take us about 90 days to migrate your application components to Kubernetes, not including additional support.

We’ve done many similar migrations in the past and confident that the processes we’ve developed will make your migration smooth and straightforward.

If you have any questions, we would love to help. You can send us an email or schedule a short diagnostic call.

‍