markdown guide
 

Docker images: think of them as blueprints, for example a blueprint for creating a cow.

Docker daemon: think of it as corral for letting the cows run wild.

Docker swarm (and Kubernetes): think of it as a rancher that manages the cows.

Let's say you create many cows (docker containers) with the same blueprint (docker image) and let the cows do their thing in the corral (docker daemon).

You have all the dairy cows in one place but it's getting pretty crowded and they're eating all the stuff around them (resources) and you need to redistribute them to other areas or they will die.

You hire the rancher named Kubernetes and tell him of all the other corrals (nodes). The rancher checks each corrals capacities (resources) that they can handle. The rancher will take care of moving the cows around when the corrals are low on food to more abundant areas and the rancher will also take care of creating new cows for you if cows die for any reason.

The rancher is responsible optimizing your cattle ranch as efficient as possible and making it scale as long as you tell him of all the locations that his allowed to move the cows to. You can also tell him to only grow the ranch to a certain size or to dynamically scale larger to produce more milk based on the dairy consumption demand by the population (auto-scaling).

 

This is the most understandable explanation ever. Thanks mate...

 
 

This is so 5 years old. Nice, Thank you so much.

 

🀯 dude. Legendary!
So simple when you put it that way.

 
 
 

I really loved the way to toke a complex thing like kubernetes and made so simple, that I can animate it. And explain it to my 4year old son.. 😁 Amusing, thanks

 
 

I can't explain it like you're 5, but I'll do my best to keep things clear.

If you're comfortable with Docker, that helps. Docker is great when you need to run a container on a single host, but when you have more than one host; it doesn't quite work. This is where Kubernetes comes in.

Kubernetes provides the management layer for containers to be distributed across multiple machines and communicate with each other.


Gory details:

Kubernetes has a control plane. This is just technical phrasing. All it means is there's an API to administrate the software. When you ask Kubernetes to run a container for you, you send the request to the control plane; the API server to be specific.

Now because Kubernetes can run on multiple hosts, the API server can't actually run the container. Instead, it stores the "desired" state in etcd. The database of the control plane.

Another part of the control plane is the scheduler. It monitors the desired state. When something new is added it tries to work out which machine can run it. There are many constraints, but CPU or MEM are the common options.

So how does it know which host can run it with the constraints? Well, every host in your cluster also runs a kubelet. This is another part of the control plane. The scheduler asks each kubelet what CPU and MEM it has available. Once a kubelet says a host is available, the scheduler updates the desired state and suggests that the container be run on that host.

Now a controller for the resource type takes over and your desired state becomes actual state.

Anytime the system changes, this loops runs to ensure desired state is met.


Resources

Kubernetes isn't just spinning up containers. It provides resource types for many features beyond the Docker runtime.

Pods: Multiple containers that share namespaces. This is actually the atomic unit you can request

Services: allows containers within the system to communicate with other containers, with load balancing. Services also provide DNS based service discovery (like docker compose)

Deployment: a redundant way to update your containers. Can update N% at a time (perform rolling updates)

There's also RBAC, NetworkPolicies, and a thousand other things.

Hopefully this helps you on your Kubernetes path. Ping me any time with questions

 

Thank you so much for this detailed explanation.

 

That's a good one! I've written an article for you, hopefully you will find it useful! If there is anything I've missed, feel free to let me know in the comments section. I would also love to hear which parts exactly do you find troublesome.

 
 

I agree with that feeling about complicated Kubernetes.

Even though Kubernetes offer for tremendous tech server like Spotify, Netflix.
In the case of solo side project, that's enough by docker-compose.

Hey you!! who using kubernates or managing fully container infrastructure on a daily basis.
above my understanding is right?

Thank you for read itπŸ˜€

 

Docker build isolated containers for apps. Kubernetes lets you place those containers in boxes called pods. These pods can then have labels put on them which lets Kubernetes now how many you want, on what type of hardware, and which ones you want to run on the same or different hardware.

 

So would you say Terraform is the General Manager or the owner of many ranches, who's also on horse back ensure Kubernetes uses the best Ranches?

 

If you're familiar with React, then Kubernetes is like React for infrastructure

It takes a definition of what resources should exist and how they should be wired together, and "renders" the infrastructure accordingly

 

You know a JavaScript frontend framework is over-hyped when it's used to explain how Kubernetes work.

Kind of like hearing your grandparents talk bitcoin at Thanksgiving.

Maybe it works on a super abstract level. But like, the concept of computers or programming is more generic and takes an input and transforms it to an output, which seems like the idea that the comparison conveys.

Just an observation I enjoyed. :)

Classic DEV Post from Dec 27 '18

Ever been stumped by <E>, <T>, <K, V> in OO language documentation?

Over on the Reddit /r/dartlang group, an individual by the name of NFC_TagsForD...

Hassan Sani profile image
MEAN Stack developer, father of twins a beautiful girl and a cute boy. Co-Chair Node.js Africa