Kubernetes Pod创建过程及API Server, Scheduler等组件如何协同工作
本文以deploy nginx service 为例讲解。
首先我们看看Kubernetes 的架构和deploy中用到一些主要组件
Master Node and Worker Node:
Step by Step: What will happen when run below cmd to deploy an Nginx Service?
when you run below code to deploy
kubectl apply -f deployment.yaml
deployment.yaml:
A deployment is a declaration of what you want.
┌─────────────────────────────────────────────────────────────────┐
│ DEPLOYMENT = CONFIGURATION │
│ │
│ It's just a YAML/JSON definition stored in etcd: │
│ │
│ apiVersion: apps/v1 │
│ kind: Deployment │
│ metadata: │
│ name: nginx-deployment │
│ namespace: default │
│ spec: │
│ replicas: 3 │
│ selector: │
│ matchLabels: │
│ app: nginx │
│ template: │
│ spec: │
│ containers: │
│ - name: nginx │
│ image: nginx:latest │
│ ports: │
│ - containerPort: 80 │
└─────────────────────────────────────────────────────────────────┘
It "lives" in etcd in master node as data，and is different from Deployment Controller.
┌─────────────────────────────────────────────────────────────────┐
│ MASTER NODE │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ etcd (Key-Value Store) │ │
│ │ │ │
│ │ Key: /registry/deployments/default/nginx-deployment │ │
│ │ Value: { │ │
│ │ "apiVersion": "apps/v1", │ │
│ │ "kind": "Deployment", │ │
│ │ "spec": { │ │
│ │ "replicas": 3, │ │
│ │ "template": { ... } │ │
│ │ } │ │
│ │ } │ │
│ └─────────────────────────────────────────────────────────┘ │
│ ▲ │
│ │ │
│ ┌───────────────────────────┴─────────────────────────────┐ │
│ │ API Server (Serves REST API) │ │
│ │ │ │
│ │ GET /apis/apps/v1/namespaces/default/deployments │ │
│ │ → Returns the Deployment config from etcd │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Deployment Controller is part of Controller Manager on Master Node.
│ │ │ WHAT IT DOES: │ │ │
│ │ │ 1. Watches etcd for Deployment objects │ │ │
│ │ │ 2. When a Deployment is created: │ │ │
│ │ │ a. Creates a ReplicaSet │ │ │
│ │ │ b. Sets replica count = 3 │ │ │
│ │ │ 3. Monitors Deployment status │ │ │
│ │ │ 4. Handles rolling updates │ │ │
│ │ │ 5. Rolls back on failure │ │ │
Master Node:
Step 1: API Server Receives the Request
API Server validates who are you(authentication) and do you have permission(authorization), and also validate if the YAML is correct?
Step 2: API Server Writes to etcd and returns 201 created to kuberctl. etcd is a key-value pairs database
Step 3: Controller Manager Watches for etcd Changes via API Server and then create ReplicaSet accordingly.
Controller checks desired states and actual states
Desired State (replica:3) → Controller(reconcile) → Actual State (pods running)
Step 4: ReplicaSet Controller Creates Pods
Step 5: Scheduler Assigns Pods to Nodes(Scheduler decides which nodes to deploy). Scheduler doesn't run containers — it just decides where they should run!
Step 6: Kubelet(worker node) Pulls and Runs Containers
Step 7: Service Creates Stable Endpoint
Complete Timeline (with times)
Visual: The Watch Loop Pattern
Everything is event-driven. Components don't talk directly — they communicate only through the API Server!
Failure Scenarios
Failure What Happens
API Server down :❌ No operations possible (kubectl fails)
etcd down: ❌ API Server can't store/retrieve state
Scheduler down: ⚠️ New pods stay Pending (existing pods continue)
Controller Manager down: ⚠️ No reconciliation (desired state not maintained)
Kubelet down: ⚠️ Pods on that node stop running
Network issue: ⚠️ Pods can't communicate, but continue running
Complete Flow: How Worker Node Creates a Service
when deploy nginx with :
kubectl create deployment nginx --image=nginx --replicas=3
kubectl expose deployment nginx --port=80 --type=ClusterIP
Phase 1: Pod Assignment (Scheduler decides)
Phase 2: Kubelet Watches and Reacts
# What Kubelet does continuously:
while true:
watch API Server for pods with spec.nodeName = this-node
if new pod assigned:
create pod
if pod needs update:
update pod
if pod needs deletion:
delete pod
Step-by-step Kubelet actions:
Phase 3: Container Runtime Deep Dive
What actually runs on the node:
Behind the scenes, kubelet calls CRI:
ctr run --rm docker.io/library/nginx:latest nginx-pod
This creates processes like:
PID NAME
1234 containerd-shim (parent process)
5678 nginx: master process
5679 nginx: worker process
5680 nginx: worker process
Phase 4: Kube-Proxy Network Setup:
This happens regardless of Service creation — kube-proxy watches for Services and Endpoints.
Phase 5: Network Traffic Flow:
Component Interactions: The Complete Picture
┌────────────────────────────────────────────────────────────────────┐
│ MASTER NODE │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ etcd │ │
│ │ /registry/pods/default/nginx-abc-123: {nodeName: node-1}│ │
│ └──────────────────────────────────────────────────────────┘ │
│ ▲ ▲ ▲ │
│ │ │ │ │
│ ┌───────┘ │ └───────┐ │
│ │ │ │ │
│ ┌─────────────────┴─┐ ┌────┴────┐ ┌───┴──────────┐ │
│ │ API Server │ │ │ │ Scheduler │ │
│ │ (REST API) │ │ │ │ │ │
│ └─────────────────┬─┘ └─────────┘ └───────────────┘ │
│ │ │
│ │ (API Server is the only entrypoint) │
└────────────────────┼────────────────────────────────────────────┘
│
│ kubelet watches for pods assigned to node
│ kube-proxy watches for services
│
┌────────────────────┼────────────────────────────────────────────┐
│ │ WORKER NODE │
│ ┌─────────────────▼─┐ ┌────────────────────────────────┐ │
│ │ KUBELET │ │ KUBE-PROXY │ │
│ │ ┌──────────────┐ │ │ ┌──────────────────────────┐ │ │
│ │ │ Pod Manager │ │ │ │ iptables/IPVS Manager │ │ │
│ │ └──────────────┘ │ │ └──────────────────────────┘ │ │
│ │ ┌──────────────┐ │ └────────────────────────────────┘ │
│ │ │ Probe Manager│ │ │
│ │ └──────────────┘ │ ┌────────────────────────────────┐ │
│ │ ┌──────────────┐ │ │ CNI (Pod Network) │ │
│ │ │Volume Manager│ │ │ - Assigns IPs │ │
│ │ └──────────────┘ │ │ - Routes between pods │ │
│ └────────────────────┘ └────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ CRI (Container Runtime Interface) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ CONTAINER RUNTIME (containerd/docker) │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Pod A │ │ Pod B │ │ Pod C │ │ │
│ │ │ nginx │ │ redis │ │ app │ │ │
│ │ │ 10.244.1.5│ │ 10.244.1.6│ │ 10.244.1.7│ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ CSI (Container Storage Interface) │ │
│ │ - Mounts volumes for PVCs │ │
│ │ - /var/lib/kubelet/pods/{pod-id}/volumes/ │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
What Happens When a Service is Created
Real-World Example: Deploying MySQL
When you deploy MySQL with PVC:
1. API Server receives MySQL deployment
2. etcd stores deployment spec
3. Scheduler assigns pod to node-1
4. Kubelet on node-1 sees pod assigned
5. Kubelet volume manager:
- Calls CSI driver
- CSI mounts PVC to /var/lib/kubelet/pods/xxx/volumes/
6. Kubelet CRI:
- Pulls mysql:8.0 image
- Creates container with:
- Volume mount: /var/lib/mysql → PVC
- Environment: MYSQL_ROOT_PASSWORD
7. Container starts, writes data to PVC
8. Kubelet updates status: Running
9. Kube-proxy updates iptables for service
10. Pod is now accessible via Service
浙公网安备 33010602011771号