Kubernetes基础架构深度解析
·
Kubernetes (K8S) 基础架构深度解析：从原理到请求全流程
文章主题：Kubernetes 集群架构与核心组件工作原理
适用场景：K8S 入门学习、架构设计、故障排查
技术栈：Kubernetes、Docker、Containerd、Linux 网络
目录
- 一、前言
- 二、Kubernetes 整体架构概览
- 三、控制平面（Control Plane）核心组件
- 四、工作节点（Worker Node）核心组件
- 五、Master 如何调度任务到 Node 节点？
- 六、用户 HTTP 请求如何到达 Pod 并返回数据？
- 七、核心概念解析
- 八、常见网络模式对比
- 九、总结
一、前言
Kubernetes（简称 K8S）是目前最流行的容器编排平台，它帮助我们自动化部署、扩展和管理容器化应用。然而，对于初学者来说，K8S 的架构和组件交互往往显得复杂。
本文将深入浅出地讲解 K8S 的基础架构，重点回答两个核心问题：
- Master 节点如何与 Node 节点通信并调度任务？
- 用户的 HTTP 请求如何经过层层路由最终到达 Pod 并返回数据？
二、Kubernetes 整体架构概览
2.1 集群架构示意图
┌─────────────────────────────────────────────────────────────┐
│ Kubernetes Cluster │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────────────┐ │
│ │ Control Plane │ │ Worker Node 1 │ │
│ │ (Master 节点) │ │ │ │
│ │ │ │ ┌────────────────────┐ │ │
│ │ • API Server │◄────────┤─►│ kubelet │ │ │
│ │ • etcd │ │ │ │ │ │
│ │ • Scheduler │ │ │ ┌──────────────┐ │ │ │
│ │ • Controller │ │ │ │ Pod 1 │ │ │ │
│ │ Manager │ │ │ │ (Container) │ │ │ │
│ │ │ │ │ └──────────────┘ │ │ │
│ └────────┬─────────┘ │ │ │ │ │
│ │ │ │ ┌──────────────┐ │ │ │
│ │ │ │ │ Pod 2 │ │ │ │
│ │ │ │ │ (Container) │ │ │ │
│ │ │ │ └──────────────┘ │ │ │
│ │ │ │ │ │ │
│ │ │ └────────────────────┘ │ │
│ │ │ │ │
│ │ │ • kube-proxy │ │
│ │ │ • Container Runtime │ │
│ │ └──────────────────────────┘ │
│ │ │
│ │ ┌──────────────────────────┐ │
│ └───────────────────┤ Worker Node 2 │ │
│ │ (结构同 Node 1) │ │
│ └──────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 外部用户 / 负载均衡器 │ │
│ │ HTTP Request → Ingress → Service → Pod │ │
│ └──────────────────────────────────────────────────────┘ │
─────────────────────────────────────────────────────────────┘
2.2 架构分层
Kubernetes 集群主要分为两大层次：
- 控制平面（Control Plane）：负责整个集群的管理和决策
- 工作节点（Worker Node）：负责运行实际的应用容器
三、控制平面（Control Plane）核心组件
控制平面是 K8S 的"大脑"，包含以下核心组件：
3.1 API Server（kube-apiserver）
作用：集群的"唯一入口"和"通信枢纽"
┌─────────────────────────────────────┐
│ kube-apiserver │
─────────────────────────────────────┤
│ • 接收所有 REST API 请求 │
│ • 认证（Authentication） │
│ • 授权（Authorization） │
│ • 准入控制（Admission Control） │
│ • 将数据持久化到 etcd │
│ • 提供 Watch 机制实现实时监听 │
└─────────────────────────────────────┘
关键特性：
- ✅ 所有组件（包括 kubectl、kubelet、controller-manager）都通过 API Server 通信
- ✅ 无状态设计，可以水平扩展
- ✅ 不直接调用其他组件，而是通过 etcd 和 Watch 机制间接交互
示例：
# 用户通过 kubectl 创建 Pod
kubectl create -f pod.yaml
# 请求流程：
# kubectl → API Server → 认证 → 授权 → 写入 etcd
3.2 etcd（分布式键值存储）
作用：集群的"数据库"，存储所有集群状态和配置
┌─────────────────────────────────────┐
│ etcd │
├─────────────────────────────────────┤
│ • 存储所有集群数据 │
│ • 高可用（Raft 共识算法） │
│ • 支持 Watch 监听机制 │
│ • 数据示例： │
│ /registry/pods/default/pod-1 │
│ /registry/nodes/node-1 │
│ /registry/services/default/svc-1 │
└─────────────────────────────────────┘
存储内容：
- Pod、Deployment、Service 等资源定义
- Node 状态信息
- ConfigMap、Secret 配置
- 集群事件和状态
3.3 Scheduler（调度器）
作用：决定 Pod 应该运行在哪个 Node 上
┌─────────────────────────────────────┐
│ kube-scheduler │
├─────────────────────────────────────┤
│ • 监听未调度的 Pod │
│ • 根据资源需求、亲和性、污点等规则 │
│ • 选择最优的 Node │
│ • 更新 Pod 的 nodeName 字段 │
└─────────────────────────────────────
调度流程：
1. API Server 发现新 Pod（nodeName 为空）
2. Scheduler 监听到这个事件
3. 执行过滤（Filtering）：排除不满足条件的 Node
4. 执行打分（Scoring）：给候选 Node 打分
5. 选择最高分的 Node
6. 通过 API Server 更新 Pod 的 nodeName
3.4 Controller Manager（控制器管理器）
作用：维护集群的"期望状态"与"实际状态"一致
┌─────────────────────────────────────┐
│ kube-controller-manager │
├─────────────────────────────────────┤
│ 包含多个控制器： │
│ • Node Controller：监控节点状态 │
│ • Replication Controller：维持 Pod │
│ 副本数 │
│ • Deployment Controller：管理部署 │
│ • Job Controller：管理一次性任务 │
│ • Service Controller：管理 Service │
└─────────────────────────────────────
工作原理：
循环执行（Control Loop）：
1. 从 etcd 读取"期望状态"（Desired State）
2. 从 API Server 获取"实际状态"（Current State）
3. 比较两者差异
4. 执行操作使实际状态趋近期望状态
四、工作节点（Worker Node）核心组件
Worker Node 是实际运行容器的工作节点，包含以下核心组件：
4.1 kubelet
作用：Node 节点上的"代理"，负责管理 Pod 和容器
┌─────────────────────────────────────┐
│ kubelet │
├─────────────────────────────────────┤
│ • 监听 API Server（通过 Watch） │
│ • 接收 Pod 创建/删除指令 │
│ • 调用容器运行时（Containerd/ │
│ Docker）创建容器 │
│ • 执行健康检查（Liveness/ │
│ Readiness Probe） │
│ • 定期上报节点状态到 API Server │
─────────────────────────────────────┘
工作流程：
1. kubelet 启动后向 API Server 注册节点
2. 持续监听分配给本节点的 Pod
3. 当收到新 Pod 指令时：
a. 下载镜像
b. 创建容器
c. 启动容器
d. 执行健康检查
4. 定期上报节点和 Pod 状态
4.2 kube-proxy
作用：维护节点上的网络规则，实现 Service 的负载均衡
┌─────────────────────────────────────┐
│ kube-proxy │
├─────────────────────────────────────┤
│ • 监听 Service 和 Endpoint 变化 │
│ • 在节点上配置 iptables/ipvs 规则 │
│ • 实现 Service 的虚拟 IP 路由 │
│ • 支持三种模式： │
│ - iptables（默认） │
│ - ipvs（高性能） │
│ - userspace（已废弃） │
└─────────────────────────────────────┘
4.3 Container Runtime（容器运行时）
作用：真正运行容器的底层引擎
┌─────────────────────────────────────┐
│ Container Runtime │
├─────────────────────────────────────┤
│ 常见实现： │
│ • containerd（推荐） │
│ • CRI-O │
│ • Docker（已弃用，通过 dockershim） │
│ │
│ 职责： │
│ • 拉取镜像 │
│ • 创建和启动容器 │
│ • 管理容器生命周期 │
└─────────────────────────────────────┘
五、Master 如何调度任务到 Node 节点？
5.1 完整调度流程
让我们以创建一个 Pod 为例，详细讲解 Master 如何与 Node 节点交互：
5.2 详细步骤解析
步骤 1-4：用户提交请求并持久化
# 用户执行
kubectl apply -f pod.yaml
# pod.yaml 内容
apiVersion: v1
kind: Pod
metadata:
name: my-app
namespace: default
spec:
containers:
- name: app
image: nginx:1.21
ports:
- containerPort: 80
交互过程：
kubectl发送 HTTP POST 请求到 API Server- API Server 验证用户身份（认证）
- API Server 检查用户权限（授权）
- API Server 将 Pod 定义写入 etcd，此时
nodeName字段为空
步骤 5-8：Scheduler 调度 Pod
Scheduler 监听机制：
// Scheduler 通过 Watch 机制监听 Pod 变化
// 伪代码示意
watcher := apiServer.Watch("/registry/pods")
for event := range watcher.ResultChan() {
pod := event.Object.(*Pod)
if pod.Spec.NodeName == "" {
// 这是一个未调度的 Pod，需要调度
nodeName := schedule(pod)
pod.Spec.NodeName = nodeName
apiServer.Update(pod)
}
}
调度算法详解：
-
过滤阶段（Predicate）：排除不满足条件的 Node
• PodFitsResources：节点资源是否充足？ • PodFitsHostPorts：端口是否冲突？ • HostName：是否指定了特定节点？ • NodeAffinity：节点亲和性匹配？ • Taints/Tolerations：污点和容忍度？ -
打分阶段（Priority）：给候选 Node 打分
• LeastRequestedPriority：资源使用率最低的节点得分高 • BalancedResourceAllocation：资源分配最均衡的节点得分高 • ImageLocalityPriority：镜像已在节点的得分高 • NodeAffinityPriority：亲和性匹配度高的得分高 -
选择最优节点：
最终得分 = Σ(各规则得分 × 权重) 选择得分最高的 Node
步骤 9-10：Controller Manager 监控状态
Controller Manager 持续监控 Pod 状态：
• 检查 Pod 是否成功调度
• 检查 Pod 是否正常运行
• 如果 Pod 失败，根据重启策略处理
• 更新 Pod 状态到 API Server
步骤 11-15：kubelet 执行容器创建
kubelet 工作流程：
// kubelet 监听分配给自己的 Pod
watcher := apiServer.Watch("/registry/pods")
for event := range watcher.ResultChan() {
pod := event.Object.(*Pod)
// 检查 Pod 是否分配给当前节点
if pod.Spec.NodeName == currentNodeName {
// 调用容器运行时创建容器
containerID := runtime.CreateContainer(pod)
runtime.StartContainer(containerID)
// 执行健康检查
go healthCheck(pod, containerID)
// 上报状态
apiServer.UpdatePodStatus(pod.Name, "Running")
}
}
容器创建详细过程：
-
网络设置：
# 为 Pod 分配 IP 地址 # 创建网络命名空间 # 配置 veth pair 连接 Pod 和宿主机网桥 -
存储挂载：
# 挂载 Volume # 挂载 ConfigMap/Secret # 配置持久化存储 -
容器启动：
# 调用 containerd/docker 创建容器 # 设置环境变量 # 执行启动命令 -
健康检查：
# Pod 定义中的探针配置 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5
六、用户 HTTP 请求如何到达 Pod 并返回数据？
这是 Kubernetes 网络的核心问题。让我们从外到内追踪一个 HTTP 请求的完整旅程。
6.1 请求路径总览
用户浏览器
↓
DNS 解析
↓
负载均衡器（云厂商 LB / Nginx / HAProxy）
↓
Ingress Controller（ingress-nginx / traefik）
↓
Service（ClusterIP / NodePort / LoadBalancer）
↓
kube-proxy（iptables / ipvs 规则）
↓
Pod IP（容器）
↓
应用处理请求并返回响应
↓
反向路径返回给用户
6.2 详细请求流程
场景：用户访问 http://myapp.example.com
前提条件：
# 1. Deployment 定义
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: myapp:1.0
ports:
- containerPort: 8080
---
# 2. Service 定义
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app
ports:
- port: 80
targetPort: 8080
type: ClusterIP
---
# 3. Ingress 定义
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app-service
port:
number: 80
步骤 1：DNS 解析
用户输入：http://myapp.example.com
↓
DNS 查询
↓
解析到 Ingress Controller 的 IP（例如：203.0.113.10）
步骤 2：到达 Ingress Controller
HTTP 请求：
Host: myapp.example.com
Path: /
Method: GET
↓
Ingress Controller（例如：ingress-nginx）
↓
解析 Ingress 规则：
myapp.example.com → my-app-service:80
Ingress Controller 工作原理：
# ingress-nginx 内部生成的 Nginx 配置（简化版）
server {
server_name myapp.example.com;
location / {
proxy_pass http://my-app-service.default.svc.cluster.local:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
步骤 3：Service 虚拟 IP 路由
Ingress Controller 发起请求到：
my-app-service.default.svc.cluster.local:80
↓
DNS 解析 Service 名称（CoreDNS）
↓
解析到 Service ClusterIP：10.96.45.123
↓
kube-proxy 拦截目标 IP 为 10.96.45.123 的请求
kube-proxy iptables 规则（简化）：
# 查看 iptables 规则
iptables -t nat -L KUBE-SERVICES
# 关键规则：
# 目标 IP 10.96.45.123:80 → 跳转到 KUBE-SVC-XXX 链
# KUBE-SVC-XXX 链 → 随机选择一个 Endpoint
# Endpoint → Pod IP:8080
iptables 规则示例：
# Service ClusterIP 规则
-A KUBE-SERVICES -d 10.96.45.123/32 -p tcp -m tcp --dport 80 \
-j KUBE-SVC-XPGD46QRK7WJZT7O
# 负载均衡到后端 Pod（假设 3 个 Pod）
-A KUBE-SVC-XPGD46QRK7WJZT7O -m statistic --mode random --probability 0.33333 \
-j KUBE-SEP-AAAA1111
-A KUBE-SVC-XPGD46QRK7WJZT7O -m statistic --mode random --probability 0.50000 \
-j KUBE-SEP-BBBB2222
-A KUBE-SVC-XPGD46QRK7WJZT7O -j KUBE-SEP-CCCC3333
# 最终 DNAT 到 Pod IP
-A KUBE-SEP-AAAA1111 -p tcp -m tcp -j DNAT --to-destination 10.244.1.5:8080
-A KUBE-SEP-BBBB2222 -p tcp -m tcp -j DNAT --to-destination 10.244.2.8:8080
-A KUBE-SEP-CCCC3333 -p tcp -m tcp -j DNAT --to-destination 10.244.3.12:8080
步骤 4：到达 Pod 容器
请求到达 Pod IP：10.244.1.5:8080
↓
网络命名空间隔离（每个 Pod 独立的网络栈）
↓
容器内的应用进程接收请求
↓
应用处理业务逻辑
↓
返回响应数据
Pod 网络结构：
宿主机网络
│
├── veth pair (veth1 ↔ eth0)
│ │
│ └── Pod 网络命名空间
│ │
│ ├── eth0: 10.244.1.5 (Pod IP)
│ ├── lo: 127.0.0.1
│ └── 应用进程监听 0.0.0.0:8080
│
└── cni0 网桥（连接所有 Pod）
步骤 5：响应返回
Pod 容器
↓
通过 veth pair 返回到宿主机网络
↓
经过 iptables 反向路径（SNAT/MASQUERADE）
↓
到达 Ingress Controller
↓
通过负载均衡器
↓
返回给用户浏览器
6.3 完整请求时序图
6.4 不同 Service 类型的请求路径
ClusterIP（默认）
只能在集群内部访问
↓
Pod → Service ClusterIP → kube-proxy → 后端 Pod
NodePort
通过任意节点的 IP + 端口访问
↓
用户 → NodeIP:30080 → kube-proxy → Pod
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
type: NodePort
ports:
- port: 80
targetPort: 8080
nodePort: 30080 # 范围：30000-32767
LoadBalancer
云厂商提供的外部负载均衡器
↓
用户 → Cloud LB IP → NodePort → Pod
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
七、核心概念解析
7.1 Pod：最小部署单元
Pod
├── Pause Container（基础设施容器）
│ ── 共享网络命名空间
├── Business Container 1（业务容器）
│ ├── 共享 Pod IP
│ ├── 共享 Volume
│ └── localhost 通信
└── Business Container 2（Sidecar 容器）
├── 共享 Pod IP
├── 共享 Volume
└── localhost 通信
特点：
- ✅ 一个 Pod 可以包含多个容器
- ✅ Pod 内的容器共享网络和存储
- ✅ Pod 是调度的最小单元（不是容器）
7.2 Service：服务发现与负载均衡
Service（虚拟 IP）
│
├── Endpoint 1: Pod-1 (10.244.1.5:8080)
├── Endpoint 2: Pod-2 (10.244.2.8:8080)
└── Endpoint 3: Pod-3 (10.244.3.12:8080)
作用：
- ✅ 提供稳定的访问入口（Pod IP 会变，Service IP 不变）
- ✅ 负载均衡到后端 Pod
- ✅ 服务发现（通过 DNS）
7.3 Namespace：资源隔离
Cluster
├── default Namespace
│ ├── Pod-1
│ ├── Service-1
│ └── Deployment-1
├── kube-system Namespace
│ ├── CoreDNS
│ ├── kube-proxy
│ └── Ingress Controller
└── my-app Namespace
├── Pod-2
├── Service-2
└── Deployment-2
7.4 CNI（容器网络接口）
常见的 CNI 插件：
| CNI 插件 | 特点 | 适用场景 |
|---|---|---|
| Flannel | 简单、Overlay 网络 | 小型集群、学习 |
| Calico | BGP 路由、高性能 | 生产环境、大规模 |
| Cilium | eBPF、可观测性强 | 高级网络策略 |
| Weave | 去中心化、加密 | 跨云部署 |
八、常见网络模式对比
8.1 iptables vs ipvs
| 特性 | iptables | ipvs |
|---|---|---|
| 性能 | 中等（规则多时性能下降） | 高（哈希表查找） |
| 扩展性 | O(n) 复杂度 | O(1) 复杂度 |
| 负载均衡算法 | 仅支持随机 | 支持多种（轮询、最少连接等） |
| 配置复杂度 | 简单 | 需安装 ipvs 模块 |
| 推荐场景 | 小规模集群 | 大规模集群 |
8.2 网络通信路径对比
Pod 间通信（同节点）
Pod-1 (10.244.1.5)
↓
veth pair
↓
cni0 网桥
↓
veth pair
↓
Pod-2 (10.244.1.8)
Pod 间通信（跨节点）
Node-1: Pod-1 (10.244.1.5)
↓
cni0 网桥
↓
flannel.1 / calico 路由
↓
Node-2: Pod-2 (10.244.2.8)
九、总结
9.1 核心要点回顾
Master 调度 Node 的关键机制
1. API Server：统一入口，所有组件通过它通信
2. etcd：存储集群状态，支持 Watch 监听
3. Scheduler：监听未调度 Pod，执行调度算法
4. Controller Manager：维护期望状态与实际状态一致
5. kubelet：监听分配给自己的 Pod，管理容器生命周期
HTTP 请求到达 Pod 的完整路径
1. DNS 解析 → Ingress Controller IP
2. Ingress Controller → Service ClusterIP
3. kube-proxy → iptables/ipvs 规则 → Pod IP
4. Pod 容器处理请求 → 反向路径返回
9.2 架构图总结
┌─────────────────────────────────────────────────────┐
│ 用户请求流程 │
├─────────────────────────────────────────────────────┤
│ │
│ 用户 → DNS → LB → Ingress → Service → kube-proxy │
│ ↓ │
│ Pod (Container) │
│ ↓ │
│ 应用处理 │
│ ↓ │
│ 反向路径返回用户 │
│ │
─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────
│ Master 调度流程 │
├─────────────────────────────────────────────────────┤
│ │
│ 用户 → API Server → etcd（存储 Pod 定义） │
│ ↓ │
│ Scheduler（调度算法） │
│ ↓ │
│ 更新 Pod（设置 nodeName） │
│ ↓ │
│ kubelet（监听并创建容器） │
│ ↓ │
│ 上报状态 → API Server → etcd │
│ │
└─────────────────────────────────────────────────────┘
9.3 学习建议
- 搭建实验环境：使用 Minikube 或 kind 搭建本地 K8S 集群
- 动手实践：创建 Pod、Service、Deployment，观察实际行为
- 查看日志：使用
kubectl logs、kubectl describe排查问题 - 网络调试：使用
kubectl exec进入容器测试网络连通性 - 深入学习：阅读官方文档，理解高级特性
9.4 常用命令速查
# 查看集群信息
kubectl cluster-info
kubectl get nodes
# 查看 Pod
kubectl get pods -o wide
kubectl describe pod <pod-name>
kubectl logs <pod-name>
# 查看 Service 和 Endpoint
kubectl get svc
kubectl get endpoints
# 查看 iptables 规则（在节点上执行）
iptables -t nat -L KUBE-SERVICES
# 进入 Pod 调试
kubectl exec -it <pod-name> -- /bin/sh
# 端口转发（本地访问 Pod）
kubectl port-forward <pod-name> 8080:8080
# 查看网络策略
kubectl get networkpolicies
参考资料
- Kubernetes 官方文档：https://kubernetes.io/docs/
- Kubernetes 网络模型：https://kubernetes.io/docs/concepts/services-networking/
- CNI 规范：https://github.com/containernetworking/cni
- iptables 详解：https://wiki.archlinux.org/title/iptables
- Calico 文档：https://docs.tigera.io/calico/latest/about/
- Flannel 文档：https://github.com/flannel-io/flannel
如果觉得这篇文章对您有帮助，欢迎：
- 👍 点赞支持
- 留言讨论
- ⭐ 收藏备用
有任何 K8S 架构问题，欢迎在评论区交流！
更多推荐
8
0- 0
已为社区贡献8条内容
所有评论(0)