For the past month I've been working with Docker, it an awesome tool I get what I am doing but I still find it difficult to wrap my head around Kubernetes or Docker Swamp.
For the past month I've been working with Docker, it an awesome tool I get what I am doing but I still find it difficult to wrap my head around Kubernetes or Docker Swamp.
For further actions, you may consider blocking this person and/or reporting abuse
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 he's 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...
🤯 dude. Legendary!
So simple when you put it that way.
this is a great explanation, perfect as a ELI5.
This is so 5 years old. Nice, Thank you so much.
This was brilliant. Thanks!
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
Very nice explanation!
I am thinking of translating it into Spanish to share it with my local community. Would it bother you if I do? I would obviously reference you as the author.
It's fine with me. Thanks for asking!
this is really awesome explanation
This is pure gold! :D
thanks for this, you are awesome!
Just Wow
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.
Kubernetes - Explained Like You're Five
Marceli-Wac ・ Sep 21 ・ 6 min read
Thank you so much, I truly appreciate.
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😀
One of my favorite values that Kubernetes providesAs a dev, you've experienced memory leaks from time to time, even sometimes within a mostly managed framework, since sometimes folks have to wrap some unmanaged object and forget to put a finalizer. They can be very difficult to track down sometimes...
So lets say that your code with the hidden leak was in a container. If you were to take that container, and write up a Kubernetes
deployment templatefor it, you could ask that Kubernetes monitor its memory consumption. You can also specify that when it reaches some threshold (say 85%) that kubernetes is to start up a new instance.What's really beautiful about this is that Kubernetes will start up the new instance, and wait for it to declare itself fully ready before it ever touches the old instance. And since all of your customer's traffic is routed through a Kubernetes
serviceobject (where the port connections are defined), it will only suddenly switch-the-traffic to the newly started container after it declares itself fully ready.It will then even wait for all of the API calls still processing through the old container to finish before requesting that container to stop.
So, in a seamless way, and in a fully automated way, the issue with the memory leak had absolutely no consequences to your customer as you work to try to find and fix it.
To me, that's beautiful.
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
Kubernetes is an operating system just for multiple machines.