Kubernetes facilitates deployments by standardizing them around an API and a CLI. The goal is to make your infrastructure services (AWS, GCP, Self-Hosted, etc.) as irrelevant as possible to the application teams. You tell Kubernetes your desired state (e.g. I want two websites up with these URLs) and it does the rest. This declarative approach to deployments is what makes Kubernetes different from, say, a CI/CD script that SSHs into a server and runs the docker/docker-compose commands to get to an end state.
To answer your question: If Docker is a tool for putting goods into a shipping container then Kubernetes is an employee to whom you give a shipping manifest to and they plan and execute on getting those containers to where they need to be.
So where does terraform come in the mix? Doesn't it do exactly the same thing?
Docker is like a daycare worker, making sure kids play nice in their own sandboxes. Each kid sets up their own mini-world (operating system) with the worker making sure they don't step on each other's toes.
Kubernetes is more than the entire daycare itself. It not only relies on the daycare worker to run the kids. It manages multiple daycares so that if one gets full, or becomes unmanageable if one of the kids starts running amuck, or even if the phone lines between daycares goes down. Parents can still call and ask kubernetes to tend to 15 more "jimmy"'s.
Kubernetes has a standard way of getting dump trucks of sand and making sandboxes of all sizes for the kids.
It gives each kid a unique name(DNS) that is easy to figure out and call up regardless of which daycare they have been moved to. Some jobs any "Jimmy" can do, so you can ask "Jimmy" to do a thing without needing to know where Jimmy1 or Jimmy4 are exactly. Kubernetes handles (Service) sending the message.
Some kids are special needs and have a mom (Operator/Stateful sets) to make sure all her kids know what their job is as each are given unique red wagons(disk volumes) which follow them to whatever daycare they are playing at.
Kubernetes asks each kid how to tell they are having fun(healthiness probe) or if they are picky about the types of daycares they get assigned to(nodeSelector).
Kubernetes let's you set up a small sandcastle(ConfigMap) in the office (API server) that gets copied to a corner of each "Jimmy" sandbox, so you update the one in the office and it gets updated everywhere.
Kubernetes makes it easy to have Jimmy John and Suzie all play in adjacent sandboxes wherever they go, sharing the same red wagon(volumes are shared), and making it easy for them to talk to each other (localhost) rather than needing a phone(DNS lookup).
Docker on the other hand is like the daycare worker, one of a few types of daycare workers (docker, containerd...). Kubernetes needs a worker, but they all match the job description (container runtime interface(CRI)). These workers expect someone else to build the daycare, but can do most everything else once inside a fully built one.
Put simply, Kubernetes allows deployment of code (such as Docker containers) across a cluster. Docker runs a container on a host, Kubernetes runs a container on multiple hosts. Kubernetes also allows for automatic scaling. It's not really a one vs the other, it's that Kubernetes allows for mass scaling of Docker containers.
If Docker was a ship, Kubernetes would be the fleet command.
Kubernetes is an orchestration tool built on top of docker. Think of Kubernetes like a project manager, it’s responsible for scheduling, deploying and monitoring docker containers across a cluster.
Kubernetes (or k8s for short) is a clustering solution for docker. In simple terms, it is the answer to the question "but can I spread docker-compose over multiple servers?". What it does:
Creates a central management API that keeps desired state configuration for the cluster, keeps track of resource allocation and triggers container deployment on cluster nodes
Creates a virtual network, connecting the dockers of all nodes in the cluster. Optionally, the vnet can allow different levels of isolation, i.e. a back-end namespace that does not have any internet access and can't initiate connections to other namespaces.
Based on the above, creates service virtual IPs, allowing network level load balancing for deployed containers. Imagine 3 containers, all running Redis cluster accessible by the service IP
Manages storage mounts, allowing containers to attach to persistent storage from any node in the server. The most basic storage driver is NFS, but support is wide (glusterfs, s3, etc.)
Can scale deployments (run additional worker containers as needed), do rolling-restart updates, re-deploy containers if a node dies. A properly configured deployment can handle a node VM getting rebooted with 0 downtime and 0 failed requests.
K8s is not easy or simple, but once you learn it, it can be a powerful tool for deploying scalable applications.
I started off trying to ELI5, but I'm not sure if I succeeded; I'm sure I rambled.
Computing can be broken into multiple individual resources: CPU, RAM, Disk, and Network. As computers got more powerful it was more efficient to divide the resources than to add more computers.
One solution that emerged was Virtual Machines. These software machines carved up the resources and dedicated them to a process. The Operating System would run on this machine wouldn't see the rest of the parent host (hypervisor).
Now this worked well but had disadvantage of inflexible reservations. If you dedicated 25% of a hypervisor to a VM but then only needed 10% the other 15% would just sit idle regardless of what the rest of the hypervisor was doing.
Enter containers. Containers divide the resources of a computer in the same manner as Virtual Machines, but are not completely separate from their parent host. Instead of install an entire operating system and running the various software components that entails a container relies on the parent host's layers to operate.
This configuration makes containers lighter-weight and more flexible than virtual machines, hooray for efficiency.
Now, both Virtual Machines and Containers are just a building block. Managing them directly can be quite a hassle as you add more. There are solutions for handling a large number of machines (virtual or physical), most of them involve a piece of software running within the machine to run configuration commands. For these types of systems to work you have to write out a lot of code and define the configuration, maintain connections, and do a lot of testing.
Enter the latest solution: Orchestration. Kubernetes is orchestration software. It's job is to coordinate the resources and containers, especially across multiple hosts. Kubernetes monitors and maintains the docker containers running and ensures the desired configuration is maintained.
Kubernetes is akin to Docker Swarm.
Kubernetes facilitates deployments by standardizing them around an API and a CLI. The goal is to make your infrastructure services (AWS, GCP, Self-Hosted, etc.) as irrelevant as possible to the application teams. You tell Kubernetes your desired state (e.g. I want two websites up with these URLs) and it does the rest. This declarative approach to deployments is what makes Kubernetes different from, say, a CI/CD script that SSHs into a server and runs the docker/docker-compose commands to get to an end state.
To answer your question: If Docker is a tool for putting goods into a shipping container then Kubernetes is an employee to whom you give a shipping manifest to and they plan and execute on getting those containers to where they need to be.
So where does terraform come in the mix? Doesn't it do exactly the same thing?
More replies
More replies
As someone said on Twitter:
"One time I tried to explain Kubernetes to someone. Then we both didn't understand it."
More replies
Docker is like a daycare worker, making sure kids play nice in their own sandboxes. Each kid sets up their own mini-world (operating system) with the worker making sure they don't step on each other's toes.
Kubernetes is more than the entire daycare itself. It not only relies on the daycare worker to run the kids. It manages multiple daycares so that if one gets full, or becomes unmanageable if one of the kids starts running amuck, or even if the phone lines between daycares goes down. Parents can still call and ask kubernetes to tend to 15 more "jimmy"'s.
Kubernetes has a standard way of getting dump trucks of sand and making sandboxes of all sizes for the kids.
It gives each kid a unique name(DNS) that is easy to figure out and call up regardless of which daycare they have been moved to. Some jobs any "Jimmy" can do, so you can ask "Jimmy" to do a thing without needing to know where Jimmy1 or Jimmy4 are exactly. Kubernetes handles (Service) sending the message.
Some kids are special needs and have a mom (Operator/Stateful sets) to make sure all her kids know what their job is as each are given unique red wagons(disk volumes) which follow them to whatever daycare they are playing at.
Kubernetes asks each kid how to tell they are having fun(healthiness probe) or if they are picky about the types of daycares they get assigned to(nodeSelector).
Kubernetes let's you set up a small sandcastle(ConfigMap) in the office (API server) that gets copied to a corner of each "Jimmy" sandbox, so you update the one in the office and it gets updated everywhere.
Kubernetes makes it easy to have Jimmy John and Suzie all play in adjacent sandboxes wherever they go, sharing the same red wagon(volumes are shared), and making it easy for them to talk to each other (localhost) rather than needing a phone(DNS lookup).
Docker on the other hand is like the daycare worker, one of a few types of daycare workers (docker, containerd...). Kubernetes needs a worker, but they all match the job description (container runtime interface(CRI)). These workers expect someone else to build the daycare, but can do most everything else once inside a fully built one.
More replies
Put simply, Kubernetes allows deployment of code (such as Docker containers) across a cluster. Docker runs a container on a host, Kubernetes runs a container on multiple hosts. Kubernetes also allows for automatic scaling. It's not really a one vs the other, it's that Kubernetes allows for mass scaling of Docker containers.
More replies
If Docker was a ship, Kubernetes would be the fleet command.
Kubernetes is an orchestration tool built on top of docker. Think of Kubernetes like a project manager, it’s responsible for scheduling, deploying and monitoring docker containers across a cluster.
More replies
Kubernetes (or k8s for short) is a clustering solution for docker. In simple terms, it is the answer to the question "but can I spread docker-compose over multiple servers?". What it does:
Creates a central management API that keeps desired state configuration for the cluster, keeps track of resource allocation and triggers container deployment on cluster nodes
Creates a virtual network, connecting the dockers of all nodes in the cluster. Optionally, the vnet can allow different levels of isolation, i.e. a back-end namespace that does not have any internet access and can't initiate connections to other namespaces.
Based on the above, creates service virtual IPs, allowing network level load balancing for deployed containers. Imagine 3 containers, all running Redis cluster accessible by the service IP
Manages storage mounts, allowing containers to attach to persistent storage from any node in the server. The most basic storage driver is NFS, but support is wide (glusterfs, s3, etc.)
Can scale deployments (run additional worker containers as needed), do rolling-restart updates, re-deploy containers if a node dies. A properly configured deployment can handle a node VM getting rebooted with 0 downtime and 0 failed requests.
K8s is not easy or simple, but once you learn it, it can be a powerful tool for deploying scalable applications.
I started off trying to ELI5, but I'm not sure if I succeeded; I'm sure I rambled.
Computing can be broken into multiple individual resources: CPU, RAM, Disk, and Network. As computers got more powerful it was more efficient to divide the resources than to add more computers.
One solution that emerged was Virtual Machines. These software machines carved up the resources and dedicated them to a process. The Operating System would run on this machine wouldn't see the rest of the parent host (hypervisor).
Now this worked well but had disadvantage of inflexible reservations. If you dedicated 25% of a hypervisor to a VM but then only needed 10% the other 15% would just sit idle regardless of what the rest of the hypervisor was doing.
Enter containers. Containers divide the resources of a computer in the same manner as Virtual Machines, but are not completely separate from their parent host. Instead of install an entire operating system and running the various software components that entails a container relies on the parent host's layers to operate.
This configuration makes containers lighter-weight and more flexible than virtual machines, hooray for efficiency.
Now, both Virtual Machines and Containers are just a building block. Managing them directly can be quite a hassle as you add more. There are solutions for handling a large number of machines (virtual or physical), most of them involve a piece of software running within the machine to run configuration commands. For these types of systems to work you have to write out a lot of code and define the configuration, maintain connections, and do a lot of testing.
Enter the latest solution: Orchestration. Kubernetes is orchestration software. It's job is to coordinate the resources and containers, especially across multiple hosts. Kubernetes monitors and maintains the docker containers running and ensures the desired configuration is maintained.
I ... should probably not teach 5 year olds.