Running one container is manageable. Running several brings harder questions: how do you update them, recover from failures, scale them, and let them communicate? Kubernetes manages containerized applications across a cluster—a group of computers—and helps address those problems. section 1.5 section 8.0
Instead of choosing a machine for every container yourself, you can let Kubernetes place containers on nodes in the cluster. It can start and restart containers, change the number of instances, and switch or roll back versions. The computers might be cloud virtual machines or your own hardware. section 1.6 section 8.0 section 8.1
Describe the result you want
Suppose a Python web app should use Python 3.10, receive internet traffic on ports 80 and 443, and use example.com. Those statements describe the desired result, not every action needed to produce it. Kubernetes configuration files, called manifests, take this declarative approach; a working manifest must express the configuration Kubernetes needs. section 1.1
A practical route from an application to Kubernetes is:
- Build and track the application, then package it as a container image so its dependencies are easier to manage. section 1.2
- Set up a cluster and connect with kubectl, the Kubernetes command-line tool. section 8.0
- Run the container with a Deployment and expose it with a Service; DNS and ingress address further communication and traffic needs. section 8.0
Managed Kubernetes avoids operating the cluster’s control plane yourself and can simplify provisioning. It does not remove every difficulty: even one web app needs configuration, while storage, permissions, debugging, and continuous updates add work. Manifests help make deployments portable between clusters, but cloud-specific volumes, load balancers, and public IP addresses may need changes during a move. section 1.6 section 8.1.1
