Do you want to know what Kubernetes is, what role and what benefits it has? We chose to illustrate each explanation with Kubernetes comics and graphs that will help you better understand the concepts and the way Kubernetes works. Watch the video below to find out more about Kubernetes.
[Video Transcript]
Right now, as part of this webinar, we will be covering a little bit of the Kubernetes basics, and with that being said, let's just start it and see what Kubernetes is all about.
I wouldn't be using many images here from the official Kubernetes comic. If you haven't seen it yet, I highly recommend that you go through, it's not now at a bit later, just Google for Kubernetes comics, it's stored on the Google cloud. It will be probably the first link that comes up.
It does a very good job of explaining the history or:
- How microservices applications showed up.
- What's the relationship between microservices and containers
- Why we needed containers
- and why we need Kubernetes
The history of Kubernetes
This is probably 10, 15, maybe 20 years ago, the age of monolithic applications. Every application is one huge mountain of code, everything in one place. And these monolithic applications have impressive feature sets, but troubleshooting, debugging, deploying these applications could be difficult.
Because of this difficulty somebody came up with an idea that, you know, in hindsight it seems very simple. Just take the application and chop it up into multiple smaller applications. And I think you already know where I'm going with this: the idea of microservices applications that are made up of multiple smaller components.
Each one of those components can be written in a different programming language. Each one can be debugged, updated, deployed individually without affecting the rest of the projects.
Yes. These components talk to one another in order to build the larger application, but other than that, each one is an independent application, an independent component, that we can modify without affecting the rest of the functionality. This was a great idea. And, developers loved the idea of microservices.
However, for the sysadmins, this created a big problem because now sysadmin no longer needs to run. Only one application. That one application has suddenly become 10, 20, 50 smaller applications. And each one is a base to run. How do we solve this?
Because whenever we try to add multiple separate applications on the same operating system, things very quickly become very difficult, mostly because of dependencies.
Each application you have specific libraries, each application requires specific versions of those rivalries and conflicts can occur and solving those conflicts can be very, very difficult.
Putting them all in a single virtual machine, you have the same problem. You still have problems with dependencies. So you'll say, I know what we'll do. We'll just start one set with books or machines for each and every service. Where it could work, but you have a whole new problem here, but every single virtual machine that you run, you have a cost.
And I don't just mean the money. I mean, the fact that you have to run one full operating system for each and every virtual machine.
That operating system requires CPU, requires memory, that operating system requests maintenance, you need to patch it, updated security. So it also consumes time. Having many many virtual machines, one for each microservice can be expensive in terms of resources, and in terms of time. Can we do things better?
share this on:
