Lots of folks have explained it well in the normal terms used for it. Here's the comparison.
Compare it to init. Systemd is currently the dominant init for most Linux flavors. When your system starts and the kernel has done its thing, init takes over. It launches daemons, sets up networking, that sort of thing. After startup, it will relaunch things that crash, possibly do other things.
Kubernetes is sort of an init for an emerging pattern of cross-machine systems. Like systemd, it uses configuration to figure out what should run in what order, relaunches things that fail and manages networking (albeit in a very different context), that sort of thing.
There are huge differences because the problems are very different. But as a high level comparison, there are worse ones. (Especially if you're very charitable when interpreting "that sort of thing".)
I’m going to alter and copy this idea: “kubernetes is distributed init”. I’d say it’s also distributed cron and if you include the resource stuff, a distributed kernel :p
You have a bunch of servers with kubernetes software installed on all of them. 1 of them is master, the rest are workers. You talk to Master through API and it talks to workers with SSH.
You send the Master some YAML files that list what containers you want running, how many, and lots of optional details. Master makes it happen so it matches what you said should be running.
Master also constantly checks everything so it matches what you asked for, even if something changes like a server failing. That's it.
Nice clear explanation. In the spirit of ELI5 I kind of think "container" is a terrible name for what seem to be super-lightweight VMs, I can't help thinking something like "instance" might have been better.
In the same way in OO languages we instantiate a class to get an object instance, containerisation seems to involve creating an instance (or several instances) of an image.
But I am really still learning all this stuff - I'm sure there's a reason behind it, and at the end of the day it's simply a set of terms one needs to absorb.
Instance is probably more overloaded, but also abstract in this case. Container refers to the virtualization mechanism that is lighter than an entire operating system but still isolates several processes into their own environment.
That's fair enough, I guess it's just the fact that the term until very recently confused me rather than clarified things; I found it genuinely obfuscatory, as a developer with relatively light infrastructure experience.
Of course I have come to terms with the fact that by now it's entrenched so we're using it, end of story - give me a few more years and I'll be pretty much adapted to it :-)
Full Disclosure: I work for Red Hat in the Container and PaaS Practice in Consulting.
As others here have said, it’s a Container Orchestration Platform and is a largely pluggable architecture that also manages at varying extents Clustered Computing Resources, Application Resource Management, SDN Networking, DNS, Service Discovery, Load Balancing, and other concerns of “Cloud Native Application Development and Deployment“.
Red Hat's open source OpenShift PaaS[1] is amazing. It has all the missing pieces you need for a production Kubernetes cluster: documentation and playbooks on how to run a production cluster[2], a build system, a container registry with fine-grained permissions, application templates, a logging framework...
Red Hat is a major contributor to Kubernetes and continually upstreams OpenShift features (like RBAC - they implemented it in OpenShift first, then upstreamed it, and then rebased OpenShift on top of it, removing the custom implementation).
I'm currently looking at migrating a large enterprise setup to Kubernetes/OpenShift.
I really like OpenShift. I had a hard time grokking K8s but OpenShift is much more friendly. I was able to PoC a microservices app on OpenShift with Minishift[1]. This way you can play around with it locally and make sure you understand what you're doing. The documentation is pretty good. Red Hat has stepped up big time in this area.
No offense, please, but whenever I see a website describing a thing as $chain_of_buzzwords like this, I immediately close the tab. This is technically a correct definition, but completely unhelpful to a person coming in from the outside, who is not familiar with the problem space.
Heck, even I am not sure what "application resource management" means, after working with Kubernetes for two years now. I could make educated guesses, but nothing certain.
The key concept to understand is that containers are just regular operating system processes with additional isolation.
Most people are familiar with memory isolation between processes. The use of further isolation mechanisms for the filesystem, I/O etc. is generally termed a container [1].
Kubernetes adds an orchestration layer on top of containers to manage processes running across different operating system instances.
The simplest way to explain it is that it is google's version of docker swarm.
Aside from that, it's a way to manage the deployment of containers across one or more hosts. Getting more traffic than usual? You have a program that detects it and sends a command to kubernetes/dockerswarm that tells it to scale up the number of web containers. Stuff like that.
Kubernetes is a container operating system. A container allows is a light weight virtual computer. Which allows you to run applications in isolation. This is useful when you might have applications with conflicting libraries. When you have multiple applications packaged in containers. You need to decide on which computer to run it, you have to deal with the networking, the load balancing if scaling it out. Upgrades and such things. Kubernetes is designed to automate all that away. You build a cluster (group of computers) You tell kubernetes you wish to deploy/run an app, kubernetes figures out where to deploy it, how to network it, link em, load balance, etc.
Kubernetes is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications
Kubernetes is a thing that makes it easier for one program to talk to several other programs, by tying them together with elastic string, and putting them in whatever room it thinks they should live, and makes them as big or small as they said they needed to be. It runs in the engine bay of the truck, not in the cab of the truck, or in the container.
To follow this up, can anyone explain the benefits over Docker? I've used Docker before but am unfamiliar with Kubernetes terminology. I do understand it's an open source project by Google.
The main benefits over the competing docker project, Docker Swarm, is that it does WAY MORE, is 100% free and open source, and has much better adoption.
I would argue that with Docker Swarm you have to bring the glue yourself, and it doesn't really solve any of the hard problems. Kubernets on the other hand is an all-in-one package that solves a LOT of hard problems for you.
If you accept the analogy that Kubernetes is an OS for the Data Center, then ‘docker’ command is the process/application launcher in that model. ‘docker’ does one thing well and Kubernetes does many things to provide a management and monitoring framework around a Container Runtime like ‘docker’ or ‘cri-o’ or the others.
Just to correct you, while Kubernetes originated at Google, it is now not owned by them and was contributed to the Cloud Native Computing Foundation (CNCF) and is independently governed there: https://www.cncf.io/projects/
Kubernetes runs Docker containers (and rkt containers) but provides additional functionality like ensuring x instances of that container run across a cluster, load balancing, service discovery, and configuration management.
So let’s say your application is running In Docker. How do you make sure that all the containers that should be running are running and how do you make sure they can talk to each other and the outside world as necessary?
Kubernetes is one solution. You use config files to specify how many of what should be running and it makes sure the system stays in that state and recovers as need be. It’s at a higher level of abstraction than running Docker containers manually on machines.
This makes sense from container to container communication. Does this help with database instances or is it typical to leave database calls as an external source to the orchestration?
This isn't a full explanation, but Kubernetes isn't a direct competitor to Docker -- but rather Swarm, Docker's orchestration solution. Both work with Docker (or one of it's direct competitors such as Rkt) to orchestrate multiple containers that work in conjunction with eachother.
What your application like (web browser, spreadsheet, and word processor) is to your operating system. Docker is to kubernetes. Docker lets you package applications into containers, kubernetes manages your containers, in terms of scheduling, resource allocation, etc.
I assume it depends on the need but an orchestration could represent a bunch of microservice apps for a single larger project. This is making me think... can you nest orchestrations?
Its a tool for DevOps helping orchestrate container deployments and scaling, you probably want to play around with docker before diving into to kubernetes.
Most of these tools have been around for more than 5 years, many organizations have invested tons of money to use them, and each is supported financially by one or more corporations, so by that metric alone they aren't going anywhere anytime soon.
