Why do you need Kubernetes and why is it more than PaaS?

In a big production came not only Docker , but also Kubernetes. And even if the containers are far from being always simple enough, then the “helper” even more so remains beyond the bounds of correct understanding among many system administrators, DevOps engineers, developers. In this small article, an attempt is made to answer one of the eternal questions (in the context of Kubernetes) with the help of a visual explanation of the idea and features of this project. Perhaps this is what you lacked in order to begin a close acquaintance with Kubernetes or even its operation?

Co-founder and architect of Box, a large online service (about 1,400 employees), Sam Ghods, in his last year's speech at KubeCon, pointed to a typical perception error Kubernetes. Many see this product as a regular container orchestration framework. But if everything was really so, then why do its developers tirelessly remind about “the roots of the Kubernetes API, going back to the architecture * created over 10 years in the framework of the Google Borg project? ..

Google Borg is a cluster manager designed to run thousands of tasks in parallel distributed across thousands of applications running across multiple clusters. It is this architecture that Kubernetes inherited, transferring cluster ideas to the modern soil of containers. How is this different from the many cloud platforms that exist today? Let's start with the very concept of the platform .
')
* The Kubernetes architecture is designed in such a way that it allows you to extend this platform, but developers are asked to follow the basic principles .

Kubernetes as a platform

Architect Box gives this definition: "The platform provides a level of abstraction that takes away any problem from you, so that you can create over it [without thinking about it]." Examples: The Linux platform allows you to make system calls regardless of the computer hardware, and the Java platform allows you to run applications regardless of the operating system. What should be the platform for launching applications based on microservice architecture?

Key features of this platform are portability and extensibility . Each cloud platform offers its own options for achieving these goals. For example, for automatic scaling, AWS has Auto Scaling Groups, Google Cloud Platform has Autoscaler, Microsoft Azure has Scale Set, and OpenStack has autoscaling API in Heat. All this in itself is not bad, because the needs are met, but the end user has difficulty. To place an application, for each service provider it is necessary to support its mechanisms: add API support, take into account the specifics of the work of the implementation used, etc. In addition, all of these solutions lack the service discovery system for truly convenient and automated deployment of microservices. And if you need to be flexible and be able to host applications in different environments (in a public cloud, in your data center, on client servers ...)?



This is the first plus and essence of Kubernetes as a platform, that is, a truly universal system for deploying applications that can be physically placed anywhere and in any way: on bare hardware, in public or private clouds, regardless of their developers and specific APIs. But Kubernetes is great not only where to run, but also what : it can be applications in different languages ​​and under different operating systems, they can be stateless and stateful . The principle of “if an application can run in a container, it should run perfectly in Kubernetes” is supported.

The purpose of Kubernetes as a platform is to provide a basic, abstract platform as a service (Platform as a Service, PaaS), while retaining the flexibility in choosing specific components of this PaaS.

Kubernetes and PaaS

The fact that Kubernetes is not traditional PaaS is described in the project documentation, which explains that the authors strive to retain the possibility of user choice in places where this is important. In particular, therefore:

• Kubernetes does not offer any built-in messaging, data processing, DBMS, etc. services.
• Kubernetes does not have its own store with ready services for deployment in one click.
• Kubernetes does not deploy source code and does not build applications. Continuous integration (CI) processes are supported, but their implementation is left for other tools.
• Similarly for logging and monitoring systems.

Thus, if PaaS usually focuses on the provision of functionality, then Kubernetes is primarily a universal, abstract approach. Despite the fact that Kubernetes offers a number of functions that are traditionally inherent in PaaS: application deployment, scaling, load balancing, logging, etc., the platform is modular and invites users to choose specific solutions for various tasks. This approach made Kubernetes a base for PaaS such as OpenShift from Red Hat and Deis.

Conclusion

Kubernetes follows a principle to which they usually (however, not always) strive for standards . He was well illustrated by Bjorn Straustrup in his classic book The C ++ Programming Language:

What should be in the standard C ++ library? The ideal for a programmer is the ability to find every interesting, significant and reasonably generalized class, function, template, etc. in library. However, the question is not “what should be in a library,” but “what should be in a standard library”. And the answer “Everything!” Is the first reasonable approach to the answer to the first question, but not the last. The standard library is what each author should provide and do it in such a way that each programmer can rely on it [i.e. really needed it - approx. trans. ].

With reference to Kubernetes, it can be said that this system is the foundation , the very “standard library” for building PaaS and other similar solutions.



PS If you want to understand the technical structure and practice of using Kubernetes, see the video from my recent report “ Our experience with Kubernetes in small projects ”. For a more detailed and deep immersion, we are preparing a series of articles on Kubernetes - subscribe to the hub and expect them in the near future.