Migrating to Kubernetes: What You Need to Know

We’ve all been to a city where traffic is so bad that you're wondering who planned and designed the streets, and where did all the cars come from? From not enough lanes to the out-of-date infrastructure, you hit bottleneck after bottleneck on the way to your destination.

Just like a city, your organization may start feeling the traffic as you deal with various microservices across different platforms. The good news is that you don't have to plan your day around avoiding "rush hour" when you have an open-source tool like Kubernetes.

Migrating to Kubernetes provides an open road for your deployment workloads. Depending on the size of your organization, and the challenges you're facing, there are many considerations to define before making the move. Understanding your starting point is crucial to head down the road towards running your application on Kubernetes.

Kubernetes’ Problem Solving Abilities

You may have heard of Kubernetes and its popularity, but what problem-solving capabilities does it have exactly? 

Kubernetes does the following:

· Runs your containerized applications at scale

· Simplifies complex deployment operations

· Builds resilience to failure and automates the rollback process

· Optimizes resource allocation

· Increases security by removing human factors

If these problem-solving abilities ring a bell, it's worth understanding some best practices for migration. Kubernetes is meant to be extremely flexible and configurable but isn't always the simplest tool to use. Teams require a large amount of training and skill-building to properly implement container orchestration. In addition, all the other dependencies like cloud services, development tools, and DevOps.

Blueprinting Your Kubernetes Migration

Define Goals

The first step for your organization is to define goals for the implementation and imagine how it will change and evolve over the next decade. If the goal is to be the primary tool to run applications regardless of the infrastructure, a strategy that's forward-thinking and flexible is a high priority.

From here, you can begin refining the exact organization goals to begin designing the size of your clusters, or the flexibility to satisfy the needs of a variety of teams. Your goal is to have as much control as possible while adhering to your enterprise standards and delivering baseline functionality.

In addition, take a look at projects that are already in progress. Will hopping into a new containerized approach impact the way they currently work? And will the impact justify the churn the teams will face?

Examine Applications

Pulling together information about your applications should answer questions such as "Which services combine to create an application?" or "Which components do we need to migrate as part of this application?" Then, start looking at network interactions between different interfaces, and which services need access to other applications, always keeping security best practices in mind. 

Another consideration is your filesystems’ interaction. Are your files going to contain static, configuration, or dynamic data and how is the data manipulated by the application at run-time?

Experts in your given application must be involved, and with the goals of migration in mind, remember to continually ask yourself if the migration is in the best interest of the application and your organization.

Migration Time

Containerize

The frequent first action is to begin containerizing all services and processes, and deploying them to an environment to stage your changes. Depending on the types of legacy systems you're using, this can be a daunting task that requires high-touch and an expert team.

Building your image repositories can contain a variety of development languages depending on the types of applications. With your strategy in mind, the content and context of your image formats will deliver consistency or some degree of customization depending on your applications and teams' requirements.

The goal is to create an effective solution that works for most of your organization with an efficient, portable, maintainable, and scalable framework. You're left with two large decisions to make:

1. Refactor or reshape your existing legacy application

2. Run the entire application inside of a container

These decisions are based solely on the unique needs of your application. Factors like the need for multiple persistent volumes will have huge downstream impacts on how your application operates in its new containerized form.

Security is also a large factor. What kind of data are you housing, and how are secrets going to be managed? Service account strategies must be determined, and best practices like defense-in-depth and the principle of least-privilege followed.

Effectively building your containers in the way that best suits an application will help you identify issues early and reduce the chance of a complete overall occurring down the road.

Establish Objects

Objects are your persistent "record of intent" to which your system will work to ensure it exists and is achieving your desired state. It requires the use of the Kubernetes API, and when provided some basic information about your object, actively manages the way your application runs.

Here are some high-level technical considerations:

· Storage

· Controllers

· Configurations

· Network Policies

As mentioned above, persistent storage is an important decision point. Determining whether you have the need or capability to migrate to a cloud-native solution or stick with persistent volumes.

Understand how your controllers will manage your pods (the smallest deployable unit) to watch the state of your cluster and make changes when detected. Kubernetes has some native functionality that can greatly help with this like Deployment, DaemonSet, and StatefulSet. Each with its unique capabilities depending on your organization's requirements.

Configurations are best stored in your SCM system and are pushed to your cluster. Configmaps are an option, they are API objects that contain data instead of a spec to access key-value pairs. You can even make these maps immutable to prevent anyone from accidentally modifying these across your organization while reducing the overall load.

Secrets management is another configuration factor that holds your private data and keeps it out of your application code. They are very similar to config maps, but specifically designed to contain confidential data. You also need a networking solution to control traffic flow with a feature like Network Policies for your applications clusters. They're application-centric which allows your pods to be isolated or non-isolated.

Be Patient

There are several other considerations to make as you begin your migration to Kubernetes, but an important factor to consider is that the process takes time. It's not going to be rolled out completely in even a few months without a greenfield application. Benefits aren't always apparent right away, either. 

Frequently you may even have a parallel system while you work on migration, and the cost savings might not emerge until much further down the road. New features are constantly rolling out, changing the way things are done, but with a proper plan, you're going to future-proof your applications.