For quite some time now, not only dock workers, but also us, IT workers, have been dealing with containers. It's impossible to stay out of this. Containerization affects and catches up with everyone in one way or another, whether you're a Dev, DevOps, or Sysadmin.
When talking about this topic, it's hard not to mention two names: Docker and Kubernetes.
Docker has been around for a while now. But did it really all start with Docker in 2013? The history of operating system-level virtualization goes back a little longer. In its early days, Docker was based on LXC (LinuX Containers), which debuted much earlier, in 2008. I myself used OpenVZ containers in my work in the mid-2000s. The beginnings can be traced back to the late 70s, with the appearance of chroot, at least as far as the Unix system is concerned. This means we have jumped back 40 years in time. There have been and are countless solutions like Docker. So why did Docker become the “runner-up”?
I think one of the reasons, if not the biggest, is the standardization in the field of operating system-level virtualization associated with Docker. (Maybe I should mention the names of the organizations and companies that play a role in this here, but this is not the place for advertising, advertising Docker Inc. is inevitable because of the name.) Before Docker, each developer or development group developed independently, based on their own ideas. There were no real standards in this area, no interface specifications that everyone followed.
Docker (container format, runtime environment, and more) is of decisive importance, but what is its role and place today? That will become clear soon…
It's time to move on, because if we want to build a serious system, we still need something that manages the containers; scales them, balances the load between them, and does this on a bunch of computers at the same time, in a coordinated way. And "it" is the orchestrator, and if we say "the orchestrator", then it's Kubernetes.
Yes, of course there are other implementations, such as Docker's own Docker Swarm or Apache Mesos, but the competition between them was decided a few years ago, and Kubernetes was clearly the winner. Kubernetes, originally named Seven of Nine (the name of the Borg from the Star Trek television series), was made open source by Google in the summer of 2014 and transferred to the care of the Cloud Native Computing Foundation.
So, Kubernetes manages the cluster; it makes decisions, maintains the desired states, automatically scales, and instructs Docker accordingly, which diligently executes tasks; starts or stops containers.
Anyone who has worked with Kubernetes knows that it has a lot of options and features. However, in an environment where everything is implemented using containers with a single lifetime, it is not easy to manage stateful applications, such as a database. Such applications were often managed outside the Kubernetes cluster until recently.
After this lengthy introduction, we have reached our topic in the title: Kubernetes Operators. Of course, I do not want to discuss the personnel who operate Kubernetes here, but the new feature of Kubernetes, which I have named Kubernetes Operators. The name is not accidental, as it is an option, an “extension” that greatly facilitates and simplifies, or rather replaces, the work of the personnel (operators).
Sticking with the original example, the database, using the appropriate Kubernetes operator, creating, operating, scaling, or updating a database cluster will no longer be a tedious task for management staff in Kubernetes.
The promise of Kubernetes is automation, and with the help of Kubernetes Operators, this is realized at a new, much higher level than before.
I think containerization is the fastest growing and most exciting thing in IT right now. It's worth getting involved!
You can learn the details and gain practical knowledge in the related courses of Training360!