In today’s competitive market for apps and services, agility is key. Technology continues to change rapidly and businesses must be ready to adapt to new trends and scale fast as demand increases. That’s why the use of cloud infrastructures and container-based deployments by software companies is growing rapidly. But migrating to container-based architectures can be challenging and no company wants to risk downtime or failures in the process. Luckily Kubernetes, the world’s leading open-source container orchestration system, can simplify migration considerably, allowing easier deployment, management and scalability.
In this guide we’ll go over what’s required to migrate to cloud-based Kubernetes clusters. We’ve drawn on the expertise of Fabrick, whose own use of Kubernetes and cloud-native applications provides a useful guide for your own operations. We’ll give a brief rundown of Kubernetes and containerisation, how you set up your environment and how to move to containerised architectures. We’ll also list some best practices following your Kubernetes migration.
Why migrate to the cloud with Kubernetes?
Kubernetes is an extensible container orchestration system, usually used for deploying apps, systems or software on cloud architectures. If you’re thinking about using containers in the cloud, you could be coming from one of several different starting points in your Kubernetes migration journey, so let’s wind back a little.
Traditionally, software was deployed to dedicated servers, typically hosted in a rack somewhere. This physical hardware was hard to scale and the hosted applications were usually monolithic. As server virtualisation, and in particular, cloud computing, took hold in the early 2000s, the possibilities for flexible and adaptable deployment architectures became apparent. Containerisation was the result.
Containerisation breaks software down into lightweight components, each with bundled dependencies and configurations. This approach solves many of the problems of monolithic software by allowing applications to scale easily. Containers can be added as required and updates made to each component without affecting others. Communications between services are facilitated by using microservices and opening up APIs, allowing greater interoperability. And software hosted in containerised environments is also inherently more portable, meaning users aren’t tied to particular infrastructures.
While containerisation offers many benefits, it’s not without challenges. Container infrastructures can get complex, particularly for big apps or services. Enter Kubernetes. It provides a means to schedule and deploy containers more easily. Kubernetes can organise groups of linked containers as ‘pods’. It can manage ‘replica sets’ of these pods for simpler scaling and failover support, and look after all aspects of the container lifecycle.
Step-by-step guide: cloud migration
Over half of publicly accessible container platforms are now using Kubernetes. That’s testament to its value in managing cloud infrastructures. So let’s look at how to migrate to Kubernetes.
Preparing your environments
Your existing infrastructure is most likely hosted on some kind of virtual machine architecture. It may even be directly hosted on physical servers, though this is now less common. Either way, the transition path to containerisation may not be obvious. Preparation is key though.
First decide on the service provider for your Kubernetes migration. Cloud-based IaaS services are plentiful and you can even host Kubernetes yourself, though we’d recommend taking advantage of the flexibilities offered by the cloud. Amazon, Microsoft Azure and Google are big players in the market, but there are others. You should choose a platform based on familiarity, prior use, technology preferences and cost, but bear in mind that you can change it later.
When setting up your environment, it’s also important to know what your dependencies are, as you’ll need to ensure these are available in your new cloud setup. Use tools such as grep to identify library imports. Depending on your code choices, look for terms like include, import, use or require.
Restructuring applications for cloud-native use
Before you begin migrating, you’ll almost certainly need to refactor your code. You should restructure it to ensure functionality is encapsulated in isolated components, all the while maintaining features and performance. This can of course be a lengthy process, so it’s wise to employ tactics such as the Strangler Fig pattern to avoid major interruptions.
Of course, the exact process of refactoring will depend on the nature of your applications, your technology and many other factors. While it’s outside the scope of this article to cover refactoring in full, you’ll find many more resources online.
Kubernetes clusters and containerisation
To prepare for containerisation, you’ll need to make sure your Git repository is properly configured, as this will likely be the key point of access for your containers to grab your code. Along with this, you may need to rationalise your build system, making sure it’s properly componentised and checked into Git.
With that done, you’re ready to build your container images. Using Docker, you can simply run docker build with a Dockerfile in your build folder to generate your image. You’ll also need a Kubernetes cluster to deploy them to. If you’re using a managed Kubernetes platform, this can usually be set up through their web interface. You’ll need to configure factors like node size, scaling methods and so on.
To deploy your images, you’ll need to create Kubernetes manifest file in YAML format. Then you can simply use the kubectl command line tool to deploy your containers:
kubectl apply -f manifest.yamlCode language: CSS (css)This tool has many other functions, allowing you to monitor node progress, check status and much more. At this stage, you should also create your replica set. This is basically a collection of pods, each of which is a duplicate of your default instance, to handle higher levels of traffic. You can create as many pods as you wish, scaling up or down as required.
Creating a maintenance page
Before you make any DNS changes or redirects, make sure you have a maintenance page for your new Kubernetes cluster. That way, in case of any interruptions to service, users will at least not be faced with 404 errors. In fact, you can do this step before you even set up your Kubernetes cluster and host it with Nginx for example.
Redirecting traffic to the Kubernetes cluster
With your cluster set up, your Kubernetes migration is nearly complete. There are one or two final steps to expose it to the world. First set up a load balancer to route incoming traffic across your pods:
kubectl expose deployment my-app --type=LoadBalancer --port=80 --target-port=80This may take a few minutes before it becomes active. You can check its status and, once active, grab the IP address with the following command:
doctl compute load-balancer list --format Name,Created,IP,StatusCode language: PHP (php)Kubernetes automatically creates DNS records for services and pods, meaning you don’t need to manage IP addresses manually. You will need to configure the service IP with your domain host of course. Check your Kubernetes platform for details.
Post migration best practices
Getting started with containerisation in the cloud can be a bit of a task, though it is rendered much easier with Kubernetes. However, once your Kubernetes migration is complete, it’s worth following these best practices to stay on track:
- Implement security measures. Cloud security is a whole area in itself, which may differ from the security practices you’re used to. Be sure not to skimp on it.
- Make time for post-migration issues. There are likely to be some teething problems with any transition. Set aside time slots in the first couple of weeks to monitor and adjust as necessary.
- Ensure your team are trained and prepared. It’s not just development staff who need to know about the migration. Support requirements and procedures may change, so keep your support staff up-to-date and confident of the new setup.
- Communicate to stakeholders. Let them know about your Kubernetes migration. Explain the improvements and how it all fits into future plans. This helps to keep technological innovation at the forefront of business awareness.
Conclusions: go conquer the cloud!
Moving your apps, software or services into the cloud is a must. It will improve the performance and flexibility of your products and also help to future-proof your business. And remember, your Kubernetes migration is just the beginning. Once you’ve adapted to the agility of containerised development and deployment, new technical horizons open up, with APIs, microservices and more – you’ll be poised to take advantage of them!
