What awaits you before, after and during the transition to Kubernetes - business note

Hello!



In this article, we decided to speculate a little about when and why a business needs Kubernetes. How hard it is to enter technology, how fast and how it will pay off. Is it worth it and how it all threatens. We do not set ourselves the task of writing a deep technical review, of which there are many, but in the following materials we will certainly share our achievements in terms of application architecture and stability of work under the control of Kubernetes. Now let's focus on whether the game is worth the candle and what we get at the exit.







Time to market - the speed of output updates to the market - today is becoming a key factor in the effectiveness of an IT solution. The product needs to be improved every day: add new functions and modules to it, maintain documentation and scripts in perfect condition. At the same time, online systems should work smoothly and be updated without affecting users.

')

Microservices guard the stealthy continuous update, the containers and the infrastructure for their orchestration - Kubernetes (or K8S, it is called in technical circles).

How Kubernetes provides continuous system updates

The main task in updating an IT solution is to ensure its correct operation after the transfer from the development environment to the product platform. And also in the smooth operation of the system at the time of the product update.



The problem lies in the fact that the settings of the development environment and industrial servers often do not match. Containers eliminate this problem by combining all software components into one package isolated from the external environment. This allows you to quickly and reliably deploy applications on any infrastructure and facilitates updating the code base of the system.



Unnoticed by users, updates are performed by duplicating containers and sequentially redirecting users from one to another. We use Kuberenetes to manage containers (orchestration). Ultimately, it makes it easier to manage the solution, deploy and update, monitor work, and debug in case of failures.

When the company needs Kubernetes

It’s time for companies to think about switching to the Kubernetes platform when:

• A project or system is a significant tool for a business and therefore must be fault tolerant and continue to work, even if some part has failed.
• The system is highly loaded, while it must support fast updates or improvements.
• The system periodically needs additional capacity. And needs them promptly.
• And with all this, the speed of delivery of updates to the industrial environment is measured in weeks, months, years, but never in hours or days.

You also need Kubernetes as an automation and standardization tool for working with a solution, if in addition to the above:

• There is no isolation between the IT systems of the company and each can influence the other.
• If you need to write a separate script each time to communicate with the parameters of the server on which the system is deployed, that is, you can only scale this process with your hands.
• In the development team there are key people - carriers of the “secret knowledge” about the project or system, and they seem unique and irreplaceable.

In fact, the transition to Kubernetes is a necessity for companies that need to maintain information systems online 24/7.

Why Kubernetes?

Kubernetes is not the only alternative to ensure continuous integration and deployment (CI / CD). But it was Kubernetes that became the industry standard in managing systems that require high availability.



For us as a developer, the decisive arguments for Kubernetes are the following:

• The platform is focused on applications, not infrastructure.
• Kubernetes is convenient to work with one data center, as well as with several, distributed in different cities.
• Easy solution support due to clear documentation and active community.
• Flexible configuration of different applications, secure traffic distribution.
• Docker container support.

What are the benefits of Kubernetes business?

• Flexible setup and automated update process
  
  You yourself determine what part of the system to launch into commercial operation. Kubernetes allows you to make a short release cycle. All operations - from the source code of the system to release into the product environment - are performed automatically. You do not need a team of engineers to make the system work. Current updates do not affect the performance of the system and can be carried out at any time convenient for developers.
• System placement and scaling
  
  The system can be located both at the customer’s computing facilities (or in the data center), and at any cloud provider, for example, Amazon or Azure. Any level of performance and fault tolerance can be easily achieved by scaling the cluster.
• Standardization and self-documentation
  
  The solution does not require instructions. It is self-documented and immediately immediately packaged into a unit of use - a container. We describe the configuration in Kubernetes as a plan / scheme. Do not write scripts that prepare the environment, as it was before Kubernetes. Instead, we pass information (a scheme) to Kubernetes on how the solution should work. And he himself implements this scheme.
  
  
  
  Developers are now writing an application to work in a container. DevOps engineers write a diagram of how an application should work in a container, and Kubernetes cam performs the task of building a solution.
  
  
  
  The technology of working with Kubernetes is standardized. It will be easy for you to train a new employee on your release system or transfer the system to a new contractor.
  
  
  
  The final configuration description that Kubernetes creates is also documentation for the system. From the names it is immediately clear which parameters are configured and what they are for.
  
  
  
  Due to this, the Kubernetes platform as a whole universalizes releases, updates and application release.

• Painless live testing
  
  Changed the process of testing solutions. Developers can create, on demand, identical product environments for automated testing. And the general logs of the application and the work of Kubernetes with the application help to even more quickly investigate problems and find errors.

What does the transition process to Kubernetes require from business?

Kubernetes itself will be only a small part of your new system. We need to be prepared that Kubernetes as a tool for standardizing the entire development, update and publication cycle of applications will entail a change of everything at the moment of transition: software architecture, infrastructure development and maintenance.

• Solution Architecture
  
  From a product point of view, transition is possible only if the system is implemented or updated to a microservice architecture based on services that can be packaged in containers (stateless services).
• Development process
  
  From the point of view of the development process, transition primarily involves a change in thinking. Any situational improvements and “crutches” added at the last moment are completely excluded. An IT solution developer can work only as one team that initially makes the initially tested, supported, packaged in containers, decomposable product. Everything should be built logically from the first line of the code to the operation.
• Update process
  
  Even at the stage of developing the application architecture, you need to think about how to update the solution without stopping. And immediately understand how you will update the database, the API, how it is logical to support several versions of the application, taking into account the fact that during the update people work with the system and they can fall into different versions.
  
  
  
  And one more turn of thinking is connected with the fact that when switching to Kubernetes, the infrastructure starts working in unchanged mode (read only), and in order to update the system, you need to create new versions of the application images and tell Kubernetes to use the new version, and the old version will later turn off and will remove itself.

So, system improvements and changes in technology can not be avoided. Moving will not be fast. But you will need to change the paradigm only once.

Case How we transferred to Kubernetes microservice system

We operate a highly loaded microservice architecture solution in the product environment, which transmits more than 300 thousand transactions per day, and 60-80 thousand per hour at peak times. We regularly update the product, there are also more urgent releases, which previously required to suspend the operation of the system or part of its functionality for some time.



We went out into the food environment without the K8S, but the system was developed initially with an eye. The translation of the solution to Kubernetes took 6 weeks. We moved in the following directions:

1) Deployment pipeline configuration

a. Configuring the constant build pipeline, test and update the application (CI / CD) in test environments.

b. Configure continuous updates in an industrial environment.

c. Preparation and configuration of the environment as close as possible to the industrial environment (preprod). We deployed and tested the cluster next to the current virtual machines.

d. Development of a migration plan for the industrial environment.



So, everything seems to be simple, we have a CI / CD pipeline for all media and can be switched, but it is still early!

2) Selection of cluster configuration

We spent a couple of weeks selecting the most stable configuration of components and versions of the Kubernetes cluster: operating system + Docker + Kubernetes.



We tested 3 different operating system configurations (Ubuntu, CentOS, Oracle Linux latest versions). On each operating system, we checked on 2 different versions of Docker and Kubernetes - the one that came in the latest versions of the standard packages of the operating system, and the latest version from the manufacturer. As a result, the configurations from the standard delivery of Oracle Linux showed the greatest stability, and we stopped at them.

3) Container settings

We spent some more time on tuning the container parameters - we set up the requirements for memory, disk, and processes.



And only after we did all this and tested various parameters of the system’s functioning (stability, fault tolerance, and others) in the preprode under loads close to the combat ones, and the system worked stably, we moved to the final stage - migration.



Then everything was easy.

Day C. Migration

For combat migration, we chose the time with the minimum load of the system: the minimum number of users and the absence of increased workload according to the schedule of internal workings of the system algorithms.



A simple system was about an hour and almost did not affect users. The migration itself consisted in switching users from one system to another and observing that everything went fine.

Life with Kubernetes

Now the update process does not affect the performance of the system, can be carried out at any time convenient for developers and looks like this:

1. The developers made a revision, tested it, sent the code to the publication.
2. The code was automatically assembled, packaged in docker images and published to a private docker repository.
3. Kubernetes automatically raises new versions of services, checks that services are working correctly, switches users to use new versions of services, stops the work of old versions and removes them from the cluster. The update took place.

Summarizing our experience

You need Kubernetes if:

1. Required to ensure high availability of the system.
2. The system is developing dynamically, and you need to deliver changes for the product environment with your eyes closed.
3. You want to work as a single command from code to product environment.
4. You are making a dynamic, evolving system that will be exploited for years.

Kubernetes is “expensive,” since entering the technology will require:

1. Learning by the developers of related technologies.
2. Revision of the processes of design, development, deployment, testing, management environments.
3. Experience in the operation of Kubernetes itself: now you need to monitor not only your system, but also the Kubernetes application services.

Pay for Kubernetes very quickly:

1. The process of updating the system is much simpler and faster. Developers are exempt from the whole block of labor costs.
2. Each new specialist will be included in the project already on rails.
3. The pipeline will be transparent and automated.
4. Experience will repeat your command for other systems.
5. You will update the system without decommissioning it, which means without stopping the business.

PS Practical advice: divide the technology entry into two stages: developing a system with the correct microservice architecture and transferring it under the control of K8S. Thus, the transition to Kubernetes does not turn into a global refactoring.