Docker and Kubernetes¶
Application containerization and orchestration as the foundation of modern software deployment.
What is Docker?¶
Docker packages an application into a container that contains all required libraries, configuration and runtime. The application then behaves the same on every server, regardless of where it runs.
- Fast startup
-
A container starts in milliseconds to seconds, because it does not boot a whole operating system.
- Low resource usage
-
It shares the host kernel, so a single server can run many containers.
- Portability
-
The same image runs on a developer laptop, in CI and on a production server.
- Isolation
-
Applications do not interfere with each other and library conflicts disappear.
What Docker is used for¶
| Use case | Example |
|---|---|
| Web services | Nginx, API backends, microservices |
| Databases | PostgreSQL, MySQL, Redis in isolation |
| Testing | Running several application versions in parallel |
| CI/CD | GitLab CI, GitHub Actions, automated builds |
| Teaching | A single identical environment for a whole class |
Drawbacks and limits¶
Where Docker is not a good fit
- Weaker isolation than a full virtual machine, since it shares the OS kernel
- Not a replacement for a desktop system or a full OS
- No automatic scaling or self-healing: that requires an orchestrator
- Containers are ephemeral: data must be stored in volumes
What is Kubernetes?¶
Kubernetes (K8s) is a container orchestrator. It does not create containers, but manages their lifecycle, scaling, availability and communication.
In short
Docker = packaging and running applications Kubernetes = managing hundreds to thousands of containers
Kubernetes solves what Docker alone cannot:
- automatic restarts on failure
- scaling based on load
- distributing requests across containers
- self-healing: replacing a crashed container
- roll-out and roll-back of versions
- managing configuration and secrets
- networking between services in a cluster
Comparison¶
| Area | Docker | Kubernetes |
|---|---|---|
| Primary purpose | Application containerization | Container orchestration |
| Scope | Individual containers | Thousands of containers at once |
| Control | Manual / Compose | Automatic, declarative |
| Failure recovery | None | Self-healing |
| Scaling | Basic | Automatic (HPA) |
| Updates | Manual | Rolling updates + rollback |
| Networking | Simple | Extensive virtual network |
| Best for | Development, testing, small services | Large systems, production |
When to use which?¶
-
Use Docker if...
- you want to run an application quickly
- you are testing code or libraries
- you run a smaller project
- you need an isolated environment
- a single server is enough
-
Use Kubernetes if...
- you need to scale applications
- you have microservices or a large API
- you need high availability
- you want automation and self-healing
- the application must run without downtime
How they fit together¶
graph LR
A[Dockerfile] --> B[Docker build]
B --> C[Image in Harbor]
C --> D[Kubernetes pull]
D --> E[Running container]
E --> F[Monitoring and self-healing]
F --> D- Docker builds an image from a Dockerfile
- The image is pushed to a registry (TUKE Harbor)
- Kubernetes pulls the image
- Kubernetes starts containers according to a definition (Deployment, StatefulSet…)
- Kubernetes watches their health and replaces them on failure
- As load grows, it adds more replicas