Kubernetes架构与原理笔记
·
一、核心设计哲学：声明式API与控制器模式
1.1 声明式vs命令式
# 声明式示例 - 告诉K8s"我想要什么"
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3 # "我想要3个副本运行nginx"
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.25
核心思想：用户只声明期望状态，Kubernetes负责让实际状态向期望状态收敛。
1.2 控制器模式（控制循环）
┌─────────────────────────────────────────────────────┐
│ 期望状态 (Spec) │
│ (存储在etcd中，通过YAML定义) │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 控制器 (Controller) │
│ 1. 监听API Server获取当前状态 │
│ 2. 比较当前状态 vs 期望状态 │
│ 3. 执行调谐(Reconcile)操作使两者一致 │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 实际状态 (Status) │
│ (集群中实际运行的状态) │
└─────────────────────────────────────────────────────┘
二、架构全景：Master-Node双平面模型
2.1 控制平面（Master节点）详细架构
创建Pod
│
▼
┌──────────────┐
│ Pending │◄──┐
│ (等待调度) │ │
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Scheduling │ │
│ (调度中) │ │
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Container │ │
│ Creating │ │
│ (创建容器) │ │
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Running │ │ 可能发生
│ (运行中) │───┤ 重启
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Succeeded │ │
│ (成功结束) │ │
├──────────────┤ │
│ Failed │ │
│ (失败结束) │───┘
├──────────────┤
│ Unknown │
│ (状态未知) │
└──────────────┘
2.2 数据平面（Worker节点）详细架构
┌─────────────────────────────────────────────────────────────┐
│ 工作节点 (Worker Node) │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Pod (最小调度单元) │ │
│ │ ┌─────────┐ ┌─────────┐ 共享： │ │
│ │ │容器1 │ │容器2 │ • Network Namespace │ │
│ │ │ │ │ │ • IPC Namespace │ │
│ │ │ 镜像 │ │ 镜像 │ • UTS Namespace │ │
│ │ │ 进程 │ │ 进程 │ 隔离： │ │
│ │ │ 资源限制│ │ 资源限制│ • PID Namespace │ │
│ │ │ │ │ │ • User Namespace │ │
│ │ └─────────┘ └─────────┘ • Mount Namespace │ │
│ └─────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────────┼───────────────────────┐ │
│ │ ▼ │ │
│ │ ┌────────────┐ ┌────────────┐ ┌──────────┐ │ │
│ │ │ Kubelet │ │ Kube-proxy │ │ 容器运行时 │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ 节点代理 │ │ 网络代理 │ │ Docker │ │ │
│ │ │ 管理Pod │ │ 服务发现 │ │ containerd│ │ │
│ │ │ 生命周期 │ │ 负载均衡 │ │ CRI-O │ │ │
│ │ └────────────┘ └────────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 操作系统 (Linux内核) │ │
│ │ • cgroups (资源限制) │ │
│ │ • namespaces (隔离) │ │
│ │ • SELinux/AppArmor (安全) │ │
│ │ • 网络栈 (iptables/ipvs) │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
三、核心组件深度解析
3.1 API Server：集群的"前门"
工作原理：
// 简化的请求处理流程
1. 客户端请求 → 2. 认证(Authentication) → 3. 授权(Authorization) →
4. 准入控制(Admission Control) → 5. 验证(Validation) →
6. 持久化到etcd → 7. 返回响应
关键特性：
-
无状态设计：可水平扩展，通过负载均衡提供服务
-
资源版本控制：每个对象都有resourceVersion，解决并发冲突
-
Watch机制：客户端可监听资源变化，实现事件驱动架构
3.2 etcd：分布式一致性存储
Raft一致性算法：
任期1 任期2 任期3
┌───┐ 选举 ┌───┐ 选举 ┌───┐
│A为│───────► │B为│───────► │C为│
│Leader│ │Leader│ │Leader│
└───┘ └───┘ └───┘
│ 复制日志 │ 复制日志 │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│节点1│ │节点1│ │节点1│
├─────┤ ├─────┤ ├─────┤
│节点2│ │节点2│ │节点2│
├─────┤ ├─────┤ ├─────┤
│节点3│ │节点3│ │节点3│
└─────┘ └─────┘ └─────┘
存储结构：
/key
├── /registry
│ ├── /pods
│ │ ├── /default
│ │ │ ├── /pod-1 → {pod spec and status}
│ │ │ └── /pod-2 → {pod spec and status}
│ ├── /services
│ └── /deployments
└── /leases
└── /kube-node-lease
3.3 Scheduler：智能调度引擎
调度流程：
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 过滤(Predicate)│ │ 评分(Priority) │ │ 绑定(Bind) │
│ │ │ │ │ │
│ 从所有节点中排除│ │ 对可行节点打分，│ │ 将Pod绑定到 │
│ 不满足条件的节点│ │ 选择最优节点 │ │ 选中的节点 │
│ │ │ │ │ │
│ • 资源充足 │ │ • 最少请求资源 │ │ 通过API Server │
│ • 端口不冲突 │ │ • 均衡负载 │ │ 更新Pod的 │
│ • 节点选择器 │ │ • 亲和性/反亲和性 │ │ nodeName字段 │
│ • 污点与容忍 │ │ • 数据局部性 │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
调度器扩展机制：
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
schedulerName: my-custom-scheduler # 可指定自定义调度器
containers:
- name: nginx
image: nginx
nodeSelector:
disktype: ssd # 节点选择器
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- zone-a
3.4 Controller Manager：自动化控制中枢
核心控制器及其作用：
| 控制器 | 作用 | 调谐周期 |
|---|---|---|
| Deployment Controller | 管理ReplicaSet，实现滚动更新和回滚 | 持续监听 |
| ReplicaSet Controller | 确保指定数量的Pod副本运行 | 持续监听 |
| Node Controller | 监控节点状态，处理节点故障 | 5秒 |
| Service Controller | 创建和管理Service的负载均衡器 | 持续监听 |
| Endpoint Controller | 维护Service与Pod的端点映射 | 持续监听 |
| Namespace Controller | 管理命名空间生命周期 | 持续监听 |
工作流程示例（ReplicaSet Controller）：
for {
// 1. 获取期望状态
rs := client.AppsV1().ReplicaSets(namespace).Get(name)
desiredReplicas := rs.Spec.Replicas
// 2. 获取当前状态
pods := client.CoreV1().Pods(namespace).List(labelSelector)
currentReplicas := len(pods.Items)
// 3. 计算差值并调谐
diff := desiredReplicas - currentReplicas
if diff > 0 {
// 创建Pod
for i := 0; i < diff; i++ {
createPod(rs.Spec.Template)
}
} else if diff < 0 {
// 删除Pod
deletePods(pods, -diff)
}
// 4. 更新状态
updateReplicaSetStatus(rs, currentReplicas)
}
3.5 Kubelet：节点上的"管家"
Pod生命周期管理：
┌───────────────────────────────────────────────┐
│ Pod Spec (来自API Server) │
└───────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ Pod 状态管理 │
│ 1. 镜像拉取策略检查 │
│ 2. 挂载存储卷 │
│ 3. 创建容器运行时配置 │
│ 4. 调用CRI创建容器 │
│ 5. 执行PostStart钩子 │
└───────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ 容器运行时交互 │
│ • 通过CRI与containerd/Docker通信 │
│ • 配置cgroups资源限制 │
│ • 设置namespaces隔离 │
└───────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ 健康检查与状态上报 │
│ • Liveness Probe (存活探针) │
│ • Readiness Probe (就绪探针) │
│ • Startup Probe (启动探针) │
│ • 定期向API Server上报节点状态 │
└───────────────────────────────────────────────┘
3.6 Kube-proxy：服务发现与负载均衡
三种代理模式对比：
| 模式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| userspace (已弃用) | 在用户空间监听端口，转发请求 | 简单易懂 | 性能差，频繁内核/用户空间切换 |
| iptables (默认) | 使用netfilter规则直接转发 | 性能好，无需上下文切换 | 规则链可能过长，调试复杂 |
| IPVS (推荐) | 基于内核的L4负载均衡 | 高性能，支持多种算法 | 需要内核模块支持 |
iptables模式示例：
# Service创建后，kube-proxy生成的iptables规则
# 1. 创建KUBE-SERVICES链
iptables -t nat -N KUBE-SERVICES
# 2. 将Service流量重定向到KUBE-SVC-xxx链
iptables -t nat -A KUBE-SERVICES -d 10.96.0.1/32 -p tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y
# 3. 负载均衡规则（随机选择Pod）
iptables -t nat -A KUBE-SVC-XXX -m statistic --mode random --probability 0.5 -j KUBE-SEP-AAA
iptables -t nat -A KUBE-SVC-XXX -j KUBE-SEP-BBB
# 4. DNAT到具体Pod IP
iptables -t nat -A KUBE-SEP-AAA -p tcp -j DNAT --to-destination 10.244.1.2:80
四、核心对象与工作原理
4.1 Pod：最小的计算单元
Pod设计哲学：
┌─────────────────────────────────────────────────────────┐
│ Pod │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ 容器A │ │ 容器B │ │ Init │ │
│ │ (主业务容器) │ │ (边车容器) │ │ Container │ │
│ │ │ │ │ │ (初始化) │ │
│ └────────────┘ └────────────┘ └────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 共享的Linux Namespace │ │
│ │ • Network: 共享IP和端口空间 │ │
│ │ • IPC: 进程间通信 │ │
│ │ • UTS: 共享主机名 │ │
│ │ • Volume: 共享存储卷 │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
Pod生命周期：
创建Pod
│
▼
┌──────────────┐
│ Pending │◄──┐
│ (等待调度) │ │
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Scheduling │ │
│ (调度中) │ │
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Container │ │
│ Creating │ │
│ (创建容器) │ │
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Running │ │ 可能发生
│ (运行中) │───┤ 重启
└──────────────┘ │
│ │
▼ │
┌──────────────┐ │
│ Succeeded │ │
│ (成功结束) │ │
├──────────────┤ │
│ Failed │ │
│ (失败结束) │───┘
├──────────────┤
│ Unknown │
│ (状态未知) │
└──────────────┘
4.2 Service：稳定的网络端点
Service类型与工作原理：
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80 # Service端口
targetPort: 9376 # Pod端口
# 类型选择：
# type: ClusterIP # 默认，集群内部访问
# type: NodePort # 节点端口暴露
# type: LoadBalancer # 云提供商负载均衡器
# type: ExternalName # 外部服务别名
Endpoint对象：
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 10.244.1.2
- ip: 10.244.2.3
ports:
- port: 9376
4.3 存储架构：Volume与CSI
存储抽象层次：
┌─────────────────────────────────────────┐
│ Pod (使用存储) │
├─────────────────────────────────────────┤
│ Volume (卷定义) │
│ • emptyDir (临时存储) │
│ • hostPath (节点本地) │
│ • configMap/secret │
│ • persistentVolumeClaim │
├─────────────────────────────────────────┤
│ PersistentVolumeClaim (存储声明) │
│ • 存储大小 │
│ • 访问模式 (RWO, ROX, RWX) │
│ • 存储类名 │
├─────────────────────────────────────────┤
│ PersistentVolume (存储卷) │
│ • 本地存储 (hostPath, local) │
│ • 网络存储 (NFS, iSCSI, Ceph) │
│ • 云存储 (AWS EBS, GCP PD) │
├─────────────────────────────────────────┤
│ StorageClass (存储类) │
│ • 动态卷配置 │
│ • 卷参数 │
├─────────────────────────────────────────┤
│ CSI Driver (容器存储接口驱动) │
│ • 厂商特定实现 │
│ • 标准化接口 │
└─────────────────────────────────────────┘
五、网络模型深度解析
5.1 Kubernetes网络三大要求
-
Pod到Pod通信：所有Pod无需NAT即可直接通信
-
节点到Pod通信：节点可以与所有Pod通信
-
Service抽象：Service IP必须可路由，负载均衡到后端Pod
5.2 CNI（容器网络接口）工作原理
源Pod (10.244.1.2) 目标Pod (10.244.2.3)
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ eth0 │ │ eth0 │
│ (容器内) │ │ (容器内) │
└─────────────┘ └─────────────┘
│ │
▼ ▲
┌─────────────┐ ┌─────────────┐
│ veth │ │ veth │
│ (主机端) │ │ (主机端) │
└─────────────┘ └─────────────┘
│ ▲
▼ │
┌─────────────┐ VXLAN隧道 ┌─────────────┐
│ flannel.1 │──────────────────────►│ flannel.1 │
│ (VTEP设备) │ 封装/解封 │ (VTEP设备) │
└─────────────┘ (外层UDP封装) └─────────────┘
│ ▲
▼ │
┌─────────────┐ ┌─────────────┐
│ eth0 │ │ eth0 │
│ (物理网卡) │ │ (物理网卡) │
└─────────────┘ └─────────────┘
│ ▲
▼ │
物理网络 (192.168.1.0/24) ──────────┘
5.3 典型网络方案：Flannel VXLAN
数据包流向：
六、调度与资源管理
6.1 资源模型与QoS类别
apiVersion: v1
kind: Pod
metadata:
name: qos-demo
spec:
containers:
- name: qos-demo-ctr
image: nginx
resources:
requests: # 保证的最小资源
memory: "64Mi"
cpu: "250m"
limits: # 允许的最大资源
memory: "128Mi"
cpu: "500m"
QoS类别自动分配：
| 资源设置 | QoS类别 | OOM Kill优先级 | 说明 |
|---|---|---|---|
| requests=limits | Guaranteed | 最后 | 资源完全保证 |
| 仅设置requests | Burstable | 中间 | 最小保证，可突发 |
| 未设置资源 | BestEffort | 最先 | 尽力而为，无保证 |
6.2 高级调度特性
污点(Taint)与容忍(Toleration)：
# 给节点添加污点
kubectl taint nodes node1 key=value:NoSchedule
# Pod定义容忍
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"
containers:
- name: nginx
image: nginx
节点亲和性(Node Affinity)：
apiVersion: v1
kind: Pod
metadata:
name: with-node-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: another-node-label-key
operator: In
values:
- another-node-label-value
containers:
- name: with-node-affinity
image: nginx
七、扩展机制与自定义资源
7.1 CRD（自定义资源定义）
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
cronSpec:
type: string
image:
type: string
replicas:
type: integer
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
7.2 Operator模式
┌─────────────────────────────────────────────────────┐
│ 自定义资源 (CR) │
│ (如: CronTab) │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 自定义控制器 (Operator) │
│ 1. 监听CR变化 (通过client-go informer) │
│ 2. 执行业务逻辑 │
│ 3. 创建/管理标准K8s资源 (Pod, Service等) │
│ 4. 更新CR状态 │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 管理的K8s资源 │
│ (Pod, Service, ConfigMap等) │
└─────────────────────────────────────────────────────┘
八、安全架构
8.1 访问控制四步流程
客户端请求
│
▼
┌──────────────┐
│ 认证 │ ←── TLS证书/Token/OpenID Connect
│(Authentication)│
└──────────────┘
│
▼
┌──────────────┐
│ 授权 │ ←── RBAC/ABAC/Node授权
│(Authorization)│
└──────────────┘
│
▼
┌──────────────┐
│ 准入控制 │ ←── 动态准入控制Webhook
│(Admission │ (Validating/Mutating)
│ Control) │
└──────────────┘
│
▼
请求处理/存储
8.2 RBAC（基于角色的访问控制）
# 1. 创建角色 (定义权限)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # 核心API组
resources: ["pods"]
verbs: ["get", "watch", "list"]
# 2. 创建角色绑定 (关联用户/组/ServiceAccount)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: ServiceAccount
name: default
namespace: default
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
8.3 Pod安全策略（PSP）与Pod安全标准（PSS）
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
spec:
privileged: false # 禁止特权容器
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
- 'persistentVolumeClaim'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
rule: 'MustRunAsNonRoot' # 禁止以root运行
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
九、高可用架构
9.1 多Master高可用方案
┌─────────────────┐
│ 负载均衡器 │
│ (haproxy/nginx) │
└────────┬────────┘
│
┌────────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Master节点1 │ │ Master节点2 │ │ Master节点3 │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ API │ │◄────►│ │ API │ │◄────►│ │ API │ │
│ │ Server │ │ │ │ Server │ │ │ │ Server │ │
│ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ Controller │ │ │ │ Controller │ │ │ │ Controller │ │
│ │ Manager │ │ │ │ Manager │ │ │ │ Manager │ │
│ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ Scheduler │ │ │ │ Scheduler │ │ │ │ Scheduler │ │
│ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │
│ │ │ │ │ │
│ ┌─────────────┐ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │
│ │ etcd │◄┼──────┼►│ etcd │◄┼──────┼►│ etcd │ │
│ │ 成员节点 │ │ │ │ 成员节点 │ │ │ │ 成员节点 │ │
│ └─────────────┘ │ │ └─────────────┘ │ │ └─────────────┘ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
9.2 etcd高可用配置
# etcd集群配置示例
# 节点1配置
name: etcd-1
initial-advertise-peer-urls: https://192.168.1.101:2380
listen-peer-urls: https://192.168.1.101:2380
listen-client-urls: https://192.168.1.101:2379,https://127.0.0.1:2379
advertise-client-urls: https://192.168.1.101:2379
initial-cluster: etcd-1=https://192.168.1.101:2380,etcd-2=https://192.168.1.102:2380,etcd-3=https://192.168.1.103:2380
initial-cluster-state: new
十、Kubernetes设计模式总结
10.1 核心设计模式
-
控制器模式：声明式API + 调谐循环
-
Sidecar模式：辅助容器增强主容器功能
-
Ambassador模式：代理容器处理外部通信
-
Adapter模式：适配容器统一输出格式
-
Operator模式：扩展K8s管理有状态应用
-
服务发现模式：通过DNS和环境变量发现服务
10.2 Kubernetes成功的关键
-
抽象层次恰当：在灵活性和易用性之间找到平衡
-
扩展性设计：CRD、CSI、CNI等标准化扩展接口
-
云原生理念：微服务、容器化、声明式API、不可变基础设施
-
社区驱动：CNCF治理下的开放协作模式
总结
Kubernetes的架构是分布式系统设计的典范，通过精巧的分层设计和模块化组件，实现了：
-
声明式配置管理：用户关注"是什么"，而非"怎么做"
-
自我修复能力：通过控制器持续保持期望状态
-
水平扩展性：无状态设计和标准接口支持大规模集群
-
多云可移植性：抽象底层基础设施差异
-
生态系统繁荣：标准化扩展接口催生丰富工具链
理解Kubernetes架构与原理的关键在于把握其控制循环的核心思想：每个控制器都不断将观察到的状态向期望状态调整，这种简单的模式通过组合产生了强大的自动化能力，使Kubernetes成为现代云原生应用的基石。
更多推荐
18
0- 0
已为社区贡献8条内容
所有评论(0)