Kubernetes is an open-source system for automating the deployment, scaling, and management of containerized applications. The system was developed at Google, modeled after Borg, another tool used within the company for cluster management. The primary task of Kubernetes is the grouping and orchestration of containers—executable code bundled with all its dependencies—which can be deployed on any IT infrastructure and then easily moved, which is extremely important in the era of cloud culture. Such grouping of containers into logical units facilitates management and discovery, which is particularly significant for large corporate applications that may consist of hundreds or even thousands of containers. Companies are interested in implementing Kubernetes because most large organizations today are, at least to some extent, software producers. Applications have become the foundation of modern business operations. Containers help solve problems that typically arise in such situations: they accelerate software delivery, facilitate updates and modernization, and simplify code management throughout the entire application lifecycle. Certainly, implementing Kubernetes is not a simple task. In the text below, we will try to answer the most frequently asked questions from companies regarding such a project.
Is it worth implementing Kubernetes in an enterprise?
Undoubtedly, it is worth it, especially if a company produces large amounts of software and wants to do so even faster, easier, and more securely. Nevertheless, it is worth emphasizing here that Kubernetes, as a container orchestration platform, is not a panacea for all the ills associated with building and managing applications. Kubernetes itself is a large vehicle used to transport various things. However, if we have nothing to transport, buying such a vehicle makes no sense.
“Kubernetes is just a tool; installing it in a corporate environment will not magically make us run applications while eliminating all problems arising throughout their lifecycle. You still need a framework, supporting applications, and many other small elements. The implementation of Kubernetes itself is just the beginning of the road to improving development” – says Łukasz Sztachański, Cloud Engineer at Mindbox.
What is the process of implementing Kubernetes in a company?
Basically, we have two paths to choose from: building Kubernetes from scratch or using a commercial solution, such as OpenShift, which is the de facto standard today. Let’s start with the latter option. Commercial providers offer a ready-made recipe for an ideal set of technologies that will create a Kubernetes platform. A huge advantage of this approach is that the entire installation process is maximally simplified. Ultimately, we receive a platform that supports all DevOps processes and is easy to use. The most widely used and popular platform based on Kubernetes is OpenShift. The technology stack proposed by RedHat is
[i]optimal. It has components for event logging, offers a graphical dashboard, complete solutions for databases, and a software development platform. An undoubted downside of choosing a ready-made solution, besides the license cost, which is non-trivial, is that the ready-made recipe, although very good, does not fit all use cases. This problem is solved by the approach of building Kubernetes from scratch. It allows for creating a platform perfectly tailored to the company’s needs and requirements. However, it requires having people with deep knowledge and experience, as well as strong training. Additionally, it requires much more time than implementing a commercial solution. How much time is needed in both cases?
“Assuming there are no limitations in the organization’s environment that could delay implementation, such as a lack of access to certain systems, a platform based on a ready-made solution can be implemented in a week. Installation takes a few hours, but then you still need to adapt the platform to the company’s environment. After a week, development teams can deploy applications to the running cluster with minimal friction using a CI/CD (Continuous Integration/Continuous Delivery) process. Of course, in this case, expert knowledge regarding the integration of authentication centers or network configuration is also needed, but all of this is relatively simple compared to building from scratch, which can take several months. I would estimate building a platform with functionalities comparable to commercial solutions at two months” – comments Łukasz Sztachański.
What are the symptoms of a poorly implemented Kubernetes?
The basic premise of Kubernetes architecture is full, automated infrastructure and application redundancy. Therefore, any failures should be practically unnoticeable. Furthermore, the platform configuration should be maintained in code. No one should do anything manually. All management and development of the platform should take place at the code level. Thanks to this, if our application suddenly disappears for any reason, we are able to set up the same cluster with the same configuration and applications in another data center within a few hours, because we already have the recipe we prepared earlier. However, if we still have a single point of failure or notice failures in parts of the data center, this is something worrying, something that suggests that the Kubernetes implementation did not go as planned. The same applies to applications. If they are written in a way that does not allow them to be moved to another part of the Kubernetes cluster without noticeable downtime, it means we have a problem. With a good implementation, we should be resilient to failures.
What characterizes a well-implemented Kubernetes?
Conversely, if we are resilient to failures, there is no need to act manually, and configurations can be quickly restored. If we are able to roll back experimental changes, it means that everything is most likely working perfectly.
“Let’s ask ourselves a few questions about the use of our Kubernetes cluster. For example: do we have CI/CD processes when creating software? Or: do we deliver software in a fast and automated way? By answering such questions, we will quickly find out if we have a well-implemented Kubernetes” – says Łukasz Sztachański.
Kubernetes implementation strategies
When preparing for implementation, an organization basically has two strategies to choose from: Big Bang or selecting
one project. The first option is a total, rapid revolution, building one platform to which we will move all software projects. From a set moment, all applications will run on this platform (or several platforms used in the organization). At one moment, we stop software development in the old model and move to the new one. Developers have one point of interaction. On one hand, this is a good solution. It offers high potential gain, but it is also burdened with a high risk of failure. We pay off technical debt very quickly, but we force something on the organization and test it on a living organism. Sometimes things can go wrong. The second model involves choosing one project. For example, in a bank, it could be a customer chat. For this one element in the entire corporate environment, we create a template that will describe how to create the platform, how to install it, how to write code, and what CI/CD tools we will use. After building such a platform along with all additional elements, we will launch the new customer chat application. Later, we can recreate the same template for another project in the organization; for example, in the case of our bank, it could be an application supporting balance display or interactions with the credit bureau (BIK).
Kubernetes vs Docker implementation
Docker is an engine for running containers. Kubernetes is a container orchestrator, a complete, complex system that ensures containers maintain the state described by developers. For example, if a development team decides that their application containerized with Docker should run in four copies, the Kubernetes platform will be responsible for ensuring they are launched and will constantly maintain those four copies. In the event of a failure, Kubernetes will react in the appropriate way and launch another copy. Of course, these mechanisms are much more complicated, the topology can be more complex, and more complicated rules can be created, but the principle is always the same.
“Until recently, in the field of container orchestration, one could speak of competition. An alternative was, for example, Docker Swarm, but it offered, like other competitors, much less than Kubernetes. And that is precisely why Kubernetes has become the de facto standard today” – concludes Łukasz Sztachański.
