Changing server architecture is always a big step for any project. Here at Dysnix, we lead most of our clients through this process by providing Kubernetes services. And each time, it has been a different experience.
If your company is choosing Kubernetes migration strategy, obviously, there is a good reason for that: increasing stability, environment unification, and quick autoscaling.
Kubernetes best fits microserver architectures. As a matter of fact, the more distinct the cluster entities are the better. This allows:
Before I even get closer to explaining the process, I'd like you to imagine the real goal of your migration.
These and other questions should be considered before you start to migrate to Kubernetes, as this process is no joke for developers and businesses in general. Below the tip of the iceberg, a whole mountain of rework can wait for your team, so your staff definitely has to be ready for it and know for sure what these actions are for. On the other hand, even if Kubernetes migration ends smoothly, your app design or business logic can extract zero benefits of Kubernetes in your particular case.
In this article, I'll share Dysnix's expertise on migrating to Kubernetes process and tools, describe common mistakes, and how to avoid them.
As a logical continuation of the previous point, I'm going from the point of strategy to that of tactics. Let's see what you have to consider and what you have to do with those answers you get from the “goals” questions.
Your documentation, visualization tools, and broad planning will help you to estimate the time and resource scope you'll need for migration. Describe each part of your app and the connections in between, mark them on the schematic. Use a deployment or hexagonal view for your convenience, or even a simple data flow chart will do the same thing. After this step is done, you'll have a full map of modules and how they are connected. This will give you a full understanding of what exactly will be migrated to Kubernetes.
Despite the enthusiasm you might feel at this stage—"Let's rewrite everything!" — you have to stay cool and build your modules' migration order from simplest to hardest. With this approach, you'll be able to train your team and prepare for the most "Herculean tasks". Or try to prepare your plan using another concept: choose the most essential modules, those responsible for business logic work, for example, and set them as most important. Other modules can be marked as secondary and then work on them after the core of the app is migrated to k8s.
The tasks you'll need to solve here will be:
I should mention that depending on the type of your app, some stages might shrink or expand in time, and that's okay. Moreover, you might need to hire some additional staff and multiply your team's expertise. Each business experiences migration individually.
But let's get back to the whole following process in a brief description:
Now you have a general understanding of the Kubernetes adoption. Let's dive deeper into the theme with technical peculiarities, application migration best practices, and Kubernetes use cases.
When developing a project's architecture, we try to completely avoid storing data in files. Why?
Ways to avoid this are as follows:
Nevertheless, if it is Persistent Volume that is required, it should be prepared properly.
When all requirements are met, make a YAML-file for Kubernetes Persistent Volume. In the case of AWS, it may look like this:
apiVersion: v1 kind: PersistentVolume metadata: name: example-my-pv annotations: volume.beta.kubernetes.io/storage-class: "default" spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce awsElasticBlockStore: volumeID: vol-0dc1fcf80ac20300a fsType: ext4