In connection with general digitalization, the popularity of the application containerization method is growing fast. Technology contributes to the rapid introduction of company services into a productive environment, where short time-to-market helps to win, and delay threatens to lose points in the competitive race. In addition, the use of a content management tool as if Kubernetes has become a trend, and for a reason. We believe that this is a truly breakthrough technology that has great advantages. This container orchestrator from Google helps you manage servers and the containers running on them, automate load-based resource usage, save on hardware by running multiple containers on a single server, and unify the interaction between related company services.

These benefits have made Kubernetes a powerful tool for some kinds of projects. However, the platform also has disadvantages, more precisely, such properties that make it very difficult to use Kubernetes in practice, because of which it may simply not be suitable for your project. The purpose of this article is not to focus on the shortcomings of the orchestrator, but to ensure that those companies that have not yet decided how containerization suits them (or those that do not use Docker fully) think about whether they need Kubernetes.

And for those who nevertheless decided to “try” this orchestrator, at the end of the article there will be a small tutorial on creating a secure Kubernetes cluster.

WHAT PROJECTS IS KUBERNETES GOOD FOR?

The idea of containerization in IT is akin to Malcolm McLean’s containerization in logistics. The container allows you to pack single settings into a universal module that can be launched in any cloud or physical environment. This is very convenient and it is obvious that the future belongs to such technology: according to forecasts, more than 70% of the market will switch to containerization in the coming years.

Containers are much easier to work with in CI/CD – you can build a reliable pipeline with little to no reconfiguration. In addition, Kubernetes has interesting features for IT engineers that make container orchestration more manageable – the same auto scaling (autoscaling) or a platform component like Kubelet that automatically starts and stops application containers when problems are detected. More often than not, however, it is the large-scale orchestration that benefits from all this.

Kubernetes is more suitable for high-load, scalable big-data projects that need to work with an abundance of container clusters and cloud PaaS / IaaS solutions. That is why such giants as Google, Amazon, Tinder, BlaBlaCar, CERN, Huawei, and Microsoft use containers and Kubernetes.

WHAT PROJECTS ARE NOT SUITABLE FOR KUBERNETES

Without dwelling on the disadvantages of the technology, we will list those that make the practical use of the orchestrator less convenient.

An additional level of abstraction complicates the system and increases its fragility.

• The ecosystem is replete with specific concepts and interrelated components: node, sub, node, label, controller, service, and others. In addition, it is developing rapidly and requires a lot of time and attention from the developer to stay up to date with new tools and practices – especially at the beginning of use, when it is not known what of all this may be needed.
• The system description documentation is quite voluminous, and studying it for the implementation of urgent projects is long and expensive
• High operating costs. Kubernetes is a rather expensive orchestrator to maintain since it requires experienced specialists with a high cost of services, which are currently quite a few. In addition, this proprietary technology introduces a kind of “vendor-lock”. However, orchestration products that are fully compatible with Kubernetes Open Source are also emerging: for example, the CRI-O runtime
• Kubernetes is a multicomponent, complex, relatively new, and therefore regularly changing system. This development and this complexity are expected to entail various failures and vulnerabilities, since it takes time, often calculated in years, to fully debug processes. At the same time, external threats are evolving rapidly. Therefore, there may be some orchestrator security issues that developers of third-party services that increase the security of Kubernetes and microservice applications are now successfully closing, but their presence only proves the problem. These are, for example, Luntry, Anchore, KubeXray, Falco, Aporeto, Cilium, and many other products.

FROM OUR PRACTICE

We have noticed that in a small or medium-sized company, containerization technology, and in particular Kubernetes, not only complicates the work of IT specialists but also becomes unaffordable. Therefore, there are not so many real implementations of this product on the market, because most companies do not need containerized application management systems – this is the lot of large developments of complex systems, where the costs of microservice technology (labor intensity, high cost of specialists) will pay off.

If your projects can handle the complexity of the system with a monolithic architecture, then this solution will be preferable to using microservices. On the other hand, if it has become difficult to maintain the code, then you can solve the problem by “cutting” the project into microservices that have their interface and manage them either without an orchestrator or with a less complex orchestrator. Vertical scaling can remain effective if there is no large amount of data and heavy loads: total database size up to 50 GB, tables up to 1 million records, network loads up to 50 requests/sec. It is worth sticking to the framework of a monolithic architecture even when there is no way to distribute work between different teams. If the problem is security, it can be solved by wrapping database queries in stored procedures. There are other ways to solve emerging problems without moving to Kubernetes.

If the budget does not allow for high salaries of additional specialists, then it is worth looking towards the use of virtual machines, which are created using the Ansible configuration management system and do not require highly skilled maintenance staff or simpler orchestration systems. In the practice of our company, there are cases when we removed clients from the “needle” of Kubernetes, and they are still grateful to us. For example, a client contacted us with problems on a server located on a co-location: the server constantly crashed, rebooted, had hardware problems, and downtime in a production environment was up to 30 minutes per week. The architecture was originally set up for Kubernetes and according to many companies that the client contacted before us, the elimination of problems would be very expensive.

We moved the infrastructure from the complex Kubernetes orchestration system to the Docker Compose container orchestration system, which is simpler and more understandable for the client. Also, all the necessary settings were made, and the infrastructure was put on monitoring and technical support. This “downgrade” made it possible to quickly return to the rails of their development process in the company, and each developer was able to deploy a local test environment at his workplace without the help of DevOps engineers. As a result, the errors and bugs accumulated over several months were very quickly fixed, and tested, and, again, without the help of DevOps engineers, the production environment was updated. In a production environment, a simple and understandable way to backup and restore on a common test environment was implemented, and each developer was able to get the latest version of the database and static content for development for full QA testing.

If you are not planning to deploy many similar, similar services on large-scale infrastructure, but are looking for a reliable, extensible, easy-to-maintain orchestrator, then look at the alternatives. If safety and reliability are at the forefront of your business, then you should also think about alternative or combined technologies.

SUMMARY

Yes, Kubernetes is a handy tool, but for large projects. This convenience has caused the orchestrator to become hype in the engineering environment. However, the popularity of Kubernetes does not mean that it is right for you. In practice, small and medium-sized applications may even “lose” due to their use. You should carefully evaluate the requirements for the project and check which tool will successfully cope with its tasks, but will require less of your attention and the company’s money.

When choosing Kubernetes as your container orchestrator, use the security guide.