Docker vs. Kubernetes: The ONLY Video You Need to Finally Understand Containers!

[@TheCodingGopher]

Looking to upgrade my audio setup with a Blue Yeti USB microphone! If you'd like to support the channel, you can buy me a coffee here: ko-fi.com/thecodinggopher.

[@debbie8062]

another great video on Kubernetes!! this really is the only video i needed to understand containers 🤯

[@TheCodingGopher]

🚀!

[@AdrenalineAkash13]

Clean Concise and to the point. A great way to begin with #Docker

[@TheCodingGopher]

Appreciate the comment

[@gabrielcanaple3479]

incredible video man, although i've been on the development side, i was curious about the deployment and orchestration magic and you made it really clear ! thanks man

[@TheCodingGopher]

It's my pleasure, thank you for tuning in

[@abdulsamadayoade9439]

detailed and straight to the point, thank you

[@TheCodingGopher]

My pleasure, cheers

[@JokerAob]

Great video and very good explanation!

[@BrunoBernard-kn6vt]

Amazing! Can you talk about Docker Swarm / Docker Stack?

[@TheCodingGopher]

Yes, added to my ideas list!

[@xthefrancisxify]

Awesome video

[@TheCodingGopher]

Cheers

[@marhensa]

if my project is only small scale, I only need portainer right? also another question which is better podman or docker?

[@debbie8062]

For small-scale projects, Portainer can indeed be sufficient. It provides an easy-to-use interface for managing Docker containers and simplifies tasks like deployment, monitoring, and volume management. However, if your project grows in complexity or scale, you might eventually need to delve deeper into Docker or Podman for advanced features.

[@TheCodingGopher]

Yes; Portainer is enough for small-scale projects (also has a nice GUI). It's a bit hard to say which is objectively "better", but here's a comparison. Podman is rootless (i.e. don't need admin), more secure, no daemon required. Better for local development or envs with strict security needs. Docker is more mature, has broader community support, and integrates well with CI/CD tools. It's better for production / larger ecosystems.

[@MichaelScharf]

Where does docker compose fit into the picture?

[@TheCodingGopher]

Docker Compose manages multi-container apps with a simple `docker-compose.yml` file; good for local development. Kubernetes handles container orchestration at scale; good for production environments.

[@MichaelScharf]

What do you think something like portainer that allows you to run docker compose files without the overhead of kubernetes?

[@TheCodingGopher]

@@MichaelScharf Portainer is a great lightweight alternative for managing Docker Compose files without the complexity of Kubernetes; very solid for smaller-scale / local deployments.

[@TheCoder-1924]

@@MichaelScharf you use it with docker swarm. docker swarm and docker compose combo is good

[@Ryan11lv426]

I think a few examples of better comparisons would be: - docker swarm vs kubernetes since those are both orchestration platforms - docker engine vs podman since they handle the lifetime of their containers differently - lxc vs docker since there is large differences in how containerd and lxd interact with the os/kernel/containers Hopefully not too critical your mic was fine and you pulled good diagrams in, but my opinion is it's a long video to say docker is a runtime package used in industry mainly for building images (it does have an engine to run containers on a single machine). While kubernetes is an orchestration platform for managing running containers across multiple nodes/machines.

[@TheCodingGopher]

This is a common challenge I often face. The audience for this video is quite diverse in terms of skill levels / YOE. This video serves as a basic introduction to Docker and Kubernetes concepts, aimed at developers who are newer to these topics and looking for a soft introduction. At the end, I clarify that Docker and Kubernetes are not an either/or choice; they’re complementary and can work together in a hybrid approach. That said, you make valid points about better comparisons. I’ll take note of them and consider creating a follow-up video focused on Docker Swarm vs. Kubernetes, and I'll incorporate the other comparisons as well. Cheers.

[@ighor]

Everything you said is wrong unless you replace 'Docker' with 'Containerd'. Docker itself is also an orchestrator and supports scalability. Both Docker and Kubernetes are using Containerd to run images. It would be worth comparing Docker vs Kubernetes, explaining at least that the first one can work with local hardware and the second one can't, the second one supports lots of filesystem and network drivers and the first one doesn’t.

[@TheCodingGopher]

That's not quite accurate; there are a few incorrect blanket statements. Docker itself is not an orchestrator. While it supports Docker Swarm for orchestration, its primary role is as a container runtime. Containerd is the actual container runtime used by both Docker and Kubernetes to run containers. In the video, I made the distinction between local development with Docker (which works well on a single machine) and production environments with Kubernetes (which is designed for scaling across clusters). As for file system and network drivers, Docker supports various drivers through its plugin system. While Kubernetes may have more built-in drivers, Docker integrates well with these through its ecosystem.

[@ighor]

@@TheCodingGopher Docker is not integrates well with Kubernetes drivers. Docker can’t use these Kubernetes drivers unless it’s image running inside a Kubernetes cluster

[@TheCodingGopher]

@@ighor You are partially correct; but here's more context: Docker doesn't "use" Kubernetes drivers directly because Docker is a container runtime, while Kubernetes is an orchestrator. However, when Docker containers run in a Kubernetes cluster, they indirectly rely on Kubernetes' drivers since Kubernetes controls the underlying infrastructure via Containerd. Docker has its own drivers (via plugins), but in Kubernetes, Containerd handles the runtime, and Kubernetes manages the drivers.

[@ighor]

​@@TheCodingGopherDocker containers can’t run in Kubernetes, that method is deprecated. Only container images run in Kubernetes, and they are not related to Docker at all. There is no easy way to run Kubernetes storage drivers in Docker alone. This important note is rarely mentioned, and it’s worth highlighting when comparing the two

[@TheCodingGopher]

@@ighor Good callout. Looks like Kubernetes no longer relies on Docker as a container runtime since the deprecation of DockerShim. Instead, it uses container runtimes that support the Container Runtime Interface (CRI), like containerd / CRI-O. Docker images can still be used in Kubernetes though (since they're OCI-compliant).