Ensiklopedia VibeKoding: Principles of Kubernetes Orchestration.Ensiklopedia VibeKoding: Principles of Kubernetes Orchestration.
Docker solved the "packaging" problem, and Kubernetes solves the "management" problem. When you have dozens or hundreds of containers that need deployment, scaling, and fault recovery, manual management is impractical. Kubernetes (K8s) is the "operating system" for containers, automating the deployment, scaling, and operations of containerized applications.Docker solved the "packaging" problem, and Kubernetes solves the "management" problem. When you have dozens or hundreds of containers that need deployment, scaling, and fault recovery, manual management is impractical. Kubernetes (K8s) is the "operating system" for containers, automating the deployment, scaling, and operations of containerized applications.
What will you learn from this article?What will you learn from this article?
After completing this chapter, you will gain:After completing this chapter, you will gain:
| Chapter | Content | Core Concepts |
|---|---|---|
| Chapter 1 | Why K8s is Needed | Challenges of container orchestration |
| Chapter 2 | K8s Architecture | Control plane, worker nodes, etcd |
| Chapter 3 | Core Resources | Pod, Deployment, Service, Ingress |
| Chapter 4 | Declarative Management | YAML, kubectl, control loops |
| Chapter 5 | Operations Practices | Rolling updates, HPA, health checks |
------
Docker makes packaging and running individual containers simple, but when you face the following scenarios, manual management becomes inadequate:Docker makes packaging and running individual containers simple, but when you face the following scenarios, manual management becomes inadequate:
| Challenge | Description | K8s Solution |
|---|---|---|
| Multi-instance deployment | A service needs 10 replicas running | Deployment automatically manages replica counts |
| Fault recovery | A container crashes and needs automatic restart | Controllers automatically detect and recreate Pods |
| Service discovery | Container IPs change; how to find each other? | Service provides stable DNS and IP |
| Rolling updates | Can't stop service when updating versions | Gradually replace old Pods with zero downtime |
| Elastic scaling | Auto-scale during traffic peaks | HPA automatically adjusts replica count based on CPU/memory |
| Resource scheduling | Place containers on the most suitable machines | Scheduler intelligently schedules |
You don't tell K8s "start 3 containers" (imperative). Instead, you tell it "I want 3 replicas running" (declarative). K8s continuously monitors to ensure the actual state matches your declared desired state. If a Pod crashes, it automatically creates a new one to replace it.You don't tell K8s "start 3 containers" (imperative). Instead, you tell it "I want 3 replicas running" (declarative). K8s continuously monitors to ensure the actual state matches your declared desired state. If a Pod crashes, it automatically creates a new one to replace it.
------
A K8s cluster consists of a Control Plane and Worker Nodes.A K8s cluster consists of a Control Plane and Worker Nodes.
CODE User Request → Ingress Controller → Service → kube-proxy → Pod (Container) ↑ Endpoint list (maintained by Service)
------
K8s describes the cluster's desired state through various "resource objects."K8s describes the cluster's desired state through various "resource objects."
| Category | Resources | Purpose |
|---|---|---|
| Workloads | Pod, Deployment, StatefulSet, DaemonSet, Job | Run applications |
| Networking | Service, Ingress, NetworkPolicy | Service discovery and traffic management |
| Configuration | ConfigMap, Secret | Configuration and sensitive data management |
| Storage | PersistentVolume, PersistentVolumeClaim | Persistent storage |
| Scheduling | Node, Namespace, ResourceQuota | Resource isolation and limits |
------
K8s's core working mechanism is the reconciliation loop:K8s's core working mechanism is the reconciliation loop:
CODE Observe → Diff → Act → Observe... ↓ ↓ ↓ Read actual Compare Execute state with corrective desired actions state
You declare replicas: 3. The controller discovers only 2 Pods running and creates 1 new one. This loop executes every few seconds, ensuring the system always converges toward the desired state.You declare replicas: 3. The controller discovers only 2 Pods running and creates 1 new one. This loop executes every few seconds, ensuring the system always converges toward the desired state.
| Command | Purpose | Example |
|---|---|---|
kubectl apply -f | Apply YAML configuration | kubectl apply -f deployment.yaml |
kubectl get | List resources | kubectl get pods -o wide |
kubectl describe | View resource details | kubectl describe pod my-app-xxx |
kubectl logs | View Pod logs | kubectl logs -f my-app-xxx |
kubectl exec | Enter Pod terminal | kubectl exec -it my-app-xxx -- sh |
kubectl delete | Delete resources | kubectl delete -f deployment.yaml |
kubectl scale | Manual scaling | kubectl scale deploy my-app --replicas=5 |
kubectl create is imperative — "create this resource," and will error if it already exists. kubectl apply is declarative — "ensure the resource is in this state," creating if it doesn't exist or updating if it does. In production, you should always use apply.kubectl create is imperative — "create this resource," and will error if it already exists. kubectl apply is declarative — "ensure the resource is in this state," creating if it doesn't exist or updating if it does. In production, you should always use apply.
------
Deployment uses a rolling update strategy by default: gradually creating new version Pods while gradually terminating old version Pods.Deployment uses a rolling update strategy by default: gradually creating new version Pods while gradually terminating old version Pods.
yaml spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # At most create 1 extra Pod maxUnavailable: 0 # No Pods allowed to be unavailable
| Operation | Command |
|---|---|
| Update image | kubectl set image deploy/my-app app=my-app:2.0 |
| View update status | kubectl rollout status deploy/my-app |
| View revision history | kubectl rollout history deploy/my-app |
| Rollback to previous version | kubectl rollout undo deploy/my-app |
HPA (Horizontal Pod Autoscaler) automatically adjusts the number of Pod replicas based on CPU, memory, or custom metrics.HPA (Horizontal Pod Autoscaler) automatically adjusts the number of Pod replicas based on CPU, memory, or custom metrics.
yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70
K8s monitors Pod health through three types of probes:K8s monitors Pod health through three types of probes:
| Probe | Purpose | Failure Consequence |
|---|---|---|
| livenessProbe | Detect if container is alive | Restart container |
| readinessProbe | Detect if container is ready | Remove from Service, don't receive traffic |
| startupProbe | Detect if container has finished starting | Don't run other probes during startup |
Without health check probes configured, K8s can only determine health by whether the process exists. But often the process is still running while the service is no longer responding (like deadlocks, edge of OOM). Configuring livenessProbe allows K8s to automatically restart these "zombie" containers.Without health check probes configured, K8s can only determine health by whether the process exists. But often the process is still running while the service is no longer responding (like deadlocks, edge of OOM). Configuring livenessProbe allows K8s to automatically restart these "zombie" containers.
------
Kubernetes is the de facto standard for container orchestration, and understanding its core concepts is the foundation of cloud-native development.Kubernetes is the de facto standard for container orchestration, and understanding its core concepts is the foundation of cloud-native development.
Key takeaways from this chapter:Key takeaways from this chapter: