二十、Kubernetes基础-1-kubernetes-core-architecture-deep-dive
Kubernetes 演进史：从手工脚本到云原生时代整体架构：控制平面与数据平面的协作核心组件：API Server、Scheduler、Controller Manager、etcd 的 internals工作节点：Kubelet、Kube-proxy 的工作原理分布式存储：etcd 的 Raft 共识与性能调优网络模型：CNI 插件与网络架构调度算法：两阶段提交与高级调度策略高可用架构：多 M
·
Kubernetes 核心架构与组件深度解析：生产级架构师完全指南
作者：云原生架构专家
技术栈：Kubernetes, Docker, containerd, etcd, Calico, IPVS
难度等级：★★★★★（专家级）
预计阅读时间：120 分钟
质量目标：CSDN 95+ 分，阿里 P8 技术深度
目录
- [Kubernetes 演进史与核心价值](#1-kubernetes 演进史与核心价值)
- [Kubernetes 整体架构全景图](#2-kubernetes 整体架构全景图)
- 控制平面组件 Internals
- 工作节点组件深度剖析
- [etcd 分布式存储核心原理](#5-etcd 分布式存储核心原理)
- [网络模型与 CNI 插件架构](#6-网络模型与-cni 插件架构)
- 调度器算法与高级调度策略
- 生产环境高可用架构
- 性能调优实战
- 故障排查与案例分析
1. Kubernetes 演进史与核心价值
1.1 容器编排技术的三代演进
第一代：手工脚本时代（2013-2014）
典型场景：
#!/bin/bash
# 早期容器管理脚本
for i in {1..10}; do
docker run -d --name app-$i \
-p 808$i:8080 \
--restart=always \
myapp:v1
done
# 致命问题：
# ✗ 容器故障无法自动恢复
# ✗ 负载激增无法自动扩容
# ✗ 节点故障无法自动迁移
# ✗ 服务发现依赖手动配置
痛点分析：
- 运维复杂度：O(n) 线性增长，每增加一个实例都需要手动操作
- 可用性：依赖人工监控和干预，MTTR（平均恢复时间）> 30 分钟
- 资源利用率：静态分配，平均利用率 < 30%
第二代：编排工具竞争时代（2014-2016）
三大阵营深度对比：
| 维度 | Docker Swarm | Kubernetes | Apache Mesos |
|---|---|---|---|
| 架构理念 | Docker 原生 | Borg 继承者 | 大数据背景 |
| 学习曲线 | 平缓（1 周） | 陡峭（3 月） | 极陡峭（6 月） |
| 功能丰富度 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 生态成熟度 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 社区活跃度 | 低 | 极高 | 低 |
| 市场份额 (2023) | 15% | 78% | <5% |
| 企业采用率 | 小企业 | 大企业 | 特定场景 |
Kubernetes 胜出的根本原因：
- Google 背书：Borg 系统的成功实践
- 声明式 API：先进的系统设计理念
- 生态战略：CNCF 开源生态建设
- 云厂商支持：AWS、GCP、Azure 全面支持
第三代：Kubernetes 云原生时代（2016-至今）
CNCF 生态演进数据：
2016 年：CNCF 成立
├─ 项目数：< 20
├─ 领域：编排、监控
└─ 采用率：< 10%
2018 年：Kubernetes 毕业
├─ 项目数：~100
├─ 领域：编排、监控、服务网格、存储
└─ 采用率：~50%
2023 年：云原生成熟期
├─ 项目数：> 150
├─ 领域：全栈云原生技术
└─ 采用率：96% (财富 500 强)
1.2 Kubernetes 核心价值主张
1.2.1 声明式 API 设计哲学
命令式 vs 声明式对比：
# 命令式 API（传统方式）
POST /containers/create
{
"image": "nginx:1.25",
"name": "web-server"
}
POST /containers/start
{
"name": "web-server"
}
# 问题：
# - 多步骤操作，状态不一致风险
# - 需要手动保证最终状态
# - 错误恢复复杂
# 声明式 API（Kubernetes 方式）
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3 # 声明期望状态
selector:
matchLabels:
app: nginx
template:
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
# 优势：
# ✓ 单步操作，声明期望状态
# ✓ 控制循环自动保证一致性
# ✓ 故障自动恢复
# ✓ 易于版本管理和回滚
Kubernetes 控制循环（Control Loop）：
┌─────────────────────────────────────────────────────┐
│ Kubernetes 控制循环 │
├─────────────────────────────────────────────────────┤
│ │
│ 当前状态 (Current State) │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Controller │ ◄─── 持续观察 │
│ └──────┬──────┘ │
│ │ 差异 (Delta) │
│ ▼ │
│ ┌─────────────┐ │
│ │ Reconcile │ ◄─── 调和处理 │
│ └────────────┘ │
│ │ │
│ ▼ │
│ 期望状态 (Desired State) │
│ │
│ 循环周期：默认 10 秒 │
│ 并发控制：通过 etcd 实现分布式锁 │
└─────────────────────────────────────────────────────┘
1.2.2 自我修复能力（Self-Healing）
自动恢复机制时间线：
场景：Pod 故障自动恢复
T0: Pod-A 运行在 Node-1 上（状态：Running）
│
▼
T1: Node-1 硬件故障，Pod-A 不可达
│
▼
T2: kubelet 心跳丢失（默认 40 秒超时）
│
▼
T3: Node Controller 标记 Node-1 为 NotReady
│
▼
T4: Scheduler 检测到 Pod-A 需要重新调度
│
▼
T5: Scheduler 选择 Node-2（基于调度算法）
│
▼
T6: kubelet on Node-2 启动新 Pod-A
│
▼
T7: Pod-A 恢复服务（总耗时 < 2 分钟）
对比传统方式：
✗ 手动检测：依赖监控告警（5-10 分钟）
✗ 手动恢复：人工介入（10-30 分钟）
✗ 总耗时：15-40 分钟
Kubernetes 优势：
✓ 自动检测：控制平面持续监控
✓ 自动恢复：无需人工干预
✓ 总耗时：< 2 分钟
✓ 业务无感知：服务发现自动更新
1.2.3 弹性伸缩能力
三层伸缩机制：
┌─────────────────────────────────────────────────────────┐
│ Kubernetes 弹性伸缩体系 │
├─────────────────────────────────────────────────────────┤
│ │
│ 第一层：Pod 级别 - HPA (Horizontal Pod Autoscaler) │
│ ├─ 指标：CPU、内存、自定义指标（QPS、延迟） │
│ ├─ 响应时间：30 秒 - 5 分钟 │
│ └─ 示例：2 个副本 ──► 10 个副本（负载激增） │
│ │
│ 第二层：节点级别 - Cluster Autoscaler │
│ ├─ 指标：Pod Pending、节点资源利用率 │
│ ├─ 响应时间：5-10 分钟 │
│ └─ 示例：5 个节点 ──► 20 个节点（资源不足） │
│ │
│ 第三层：应用级别 - KEDA (Kubernetes Event-Driven) │
│ ├─ 指标：事件驱动（Kafka 消息数、SQS 队列深度） │
│ ├─ 响应时间：秒级 │
│ └─ 示例：0 个副本 ──► 50 个副本（突发流量） │
└─────────────────────────────────────────────────────────┘
1.3 生产环境选型建议
1.3.1 企业采用率数据（2023 CNCF 调查）
| 指标 | Kubernetes | Docker Swarm | Nomad |
|---|---|---|---|
| 生产采用率 | 78% | 15% | 7% |
| 评估中 | 12% | 3% | 5% |
| 计划采用 | 7% | 2% | 3% |
| 不考虑 | 3% | 80% | 85% |
1.3.2 技术决策矩阵
选择 Kubernetes 的理由（✓）：
✓ 需要高可用性（99.99% SLA）
✓ 需要自动弹性伸缩
✓ 需要多云/混合云部署
✓ 需要完善的生态系统
✓ 需要 Service Mesh 支持
✓ 需要 GitOps 实践
✓ 团队规模 > 10 人
✓ 微服务架构（> 10 个服务）
选择 Docker Swarm 的理由（✓）：
✓ 简单快速部署
✓ 小型团队（< 5 人）
✓ 单机或双机部署
✓ 不需要复杂功能
✓ 快速原型验证
✓ 微服务数量 < 5
选择 Nomad 的理由（✓）：
✓ 已经使用 HashiCorp 生态（Consul, Vault）
✓ 需要调度非容器工作负载（VM、二进制）
✓ 极简主义偏好
✓ 全球分布式部署
2. Kubernetes 整体架构全景图
2.1 逻辑架构视图
2.2 物理部署视图
┌─────────────────────────────────────────────────────────┐
│ Kubernetes 生产集群物理部署（3 Master + N Worker） │
├─────────────────────────────────────────────────────────┤
│ │
│ 控制平面节点（高可用） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Master-1 │ │ Master-2 │ │ Master-3 │ │
│ │ │ │ │ │ │ │
│ │ - API Server │ │ - API Server │ │ - API Server │ │
│ │ - Scheduler │ │ - Scheduler │ │ - Scheduler │ │
│ │ - Controller │ │ - Controller │ │ - Controller │ │
│ │ - etcd │ │ - etcd │ │ - etcd │ │
│ │ │ │ │ │ │ │
│ │ 192.168.1.11 │ │ 192.168.1.12 │ │ 192.168.1.13 │ │
│ └─────────────┘ ──────┬───────┘ └─────────────┘ │
│ │ │ │ │
│ └─────────────────┼─────────────────┘ │
│ │ │
│ ┌────────────▼────────────┐ │
│ │ Load Balancer │ │
│ │ (HAProxy/Nginx) │ │
│ │ 192.168.1.100:6443 │ │
│ └────────────┬────────────┘ │
│ │ │
│ ┌─────────────────┼─────────────────┐ │
│ │ │ │ │
│ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ │
│ │ Worker-1 │ │ Worker-2 │ │ Worker-N │ │
│ │ │ │ │ │ │ │
│ │ - Kubelet │ │ - Kubelet │ │ - Kubelet │ │
│ │ - Kube-proxy│ │ - Kube-proxy│ │ - Kube-proxy│ │
│ │ - containerd│ │ - containerd│ │ - containerd│ │
│ │ - Pods │ │ - Pods │ │ - Pods │ │
│ │ │ │ │ │ │ │
│ │192.168.2.11 │ │192.168.2.12 │ │192.168.2.N │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ 网络平面： │
│ - 集群 CIDR: 10.244.0.0/16 (Pod 网络) │
│ - Service CIDR: 10.96.0.0/12 │
│ - CNI: Calico / Flannel / Cilium │
│ │
│ 存储平面： │
│ - CSI: NFS / Ceph / iSCSI │
│ - 本地存储：HostPath / Local Volume │
└─────────────────────────────────────────────────────────┘
2.3 组件通信矩阵
┌─────────────────────────────────────────────────────────┐
│ Kubernetes 组件通信矩阵 │
├─────────────────────────────────────────────────────────┤
│ │
│ 通信路径 协议 端口 用途 │
│ ───────────────────────────────────────────────────── │
│ kubectl → API Server HTTPS 6443 集群管理 │
│ Scheduler → API Server HTTPS 6443 监听事件 │
│ Controller → API Server HTTPS 6443 状态同步 │
│ Kubelet → API Server HTTPS 6443 节点管理 │
│ Kube-proxy → API Server HTTPS 6443 Service 同步│
│ API Server → etcd gRPC 2379 数据存储 │
│ etcd ↔ etcd gRPC 2380 集群同步 │
│ Kubelet → containerd Unix Socket /run/containerd.sock │
│ Kubelet → CNI 二进制 - 网络配置 │
│ Kubelet → CSI gRPC - 存储挂载 │
│ Pod → Kube-proxy TCP/UDP 10249 服务访问 │
│ Pod → Pod TCP/UDP - Pod 间通信 │
│ │
│ 安全机制： │
│ - TLS 加密：所有跨节点通信 │
│ - 认证：X509 证书、ServiceAccount Token │
│ - 授权：RBAC、ABAC、Node、Webhook │
│ - 准入控制：Mutating/Validating Webhook │
└─────────────────────────────────────────────────────────┘
3. 控制平面组件 Internals
3.1 API Server：集群的统一入口
3.1.1 核心职责
API Server 职责分解：
┌─────────────────────────────────────────────────────────┐
│ API Server 职责分解 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. RESTful API 网关 │
│ ├─ HTTP/HTTPS (默认 6443) │
│ ├─ OpenAPI/Swagger 规范 │
│ └─ 版本控制 (/api/v1, /apis/apps/v1) │
│ │
│ 2. 认证与授权 │
│ ├─ 认证：X509 证书、Bearer Token、ServiceAccount │
│ ├─ 授权：RBAC、ABAC、Node、Webhook │
│ └─ 准入控制：MutatingAdmissionWebhook 等 │
│ │
│ 3. 请求验证 │
│ ├─ Schema 验证（OpenAPI） │
│ ├─ 字段验证（必填、类型、范围） │
│ └─ 语义验证（引用存在、循环依赖） │
│ │
│ 4. 状态持久化 │
│ ├─ 写入 etcd（强一致性） │
│ ├─ Watch 机制（实时通知） │
│ └─ 资源版本（ResourceVersion） │
│ │
│ 5. 聚合 API 服务器 │
│ ├─ metrics-server │
│ ├─ custom-metrics-api │
│ └─ 第三方 CRD API │
└─────────────────────────────────────────────────────────┘
3.1.2 启动参数详解
生产环境 API Server 配置：
kube-apiserver \
# === 基本配置 ===
--advertise-address=192.168.1.11 \
--secure-port=6443 \
--insecure-port=0 \
# === etcd 配置 ===
--etcd-servers=https://192.168.1.11:2379,https://192.168.1.12:2379,https://192.168.1.13:2379 \
--etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt \
--etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt \
--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key \
# === TLS 证书配置 ===
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key \
--client-ca-file=/etc/kubernetes/pki/ca.crt \
--service-account-key-file=/etc/kubernetes/pki/sa.pub \
--service-account-signing-key-file=/etc/kubernetes/pki/sa.key \
--service-account-issuer=https://kubernetes.default.svc.cluster.local \
# === 认证配置 ===
--authorization-mode=Node,RBAC \
--enable-admission-plugins=NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook \
# === 审计日志配置 ===
--audit-log-path=/var/log/kubernetes/audit.log \
--audit-log-maxage=30 \
--audit-log-maxbackup=10 \
--audit-log-maxsize=100 \
--audit-policy-file=/etc/kubernetes/audit-policy.yaml \
# === 性能调优 ===
--max-requests-inflight=400 \
--max-mutating-requests-inflight=200 \
--request-timeout=1m0s \
--min-request-timeout=300 \
# === Service 网络配置 ===
--service-cluster-ip-range=10.96.0.0/12 \
--service-node-port-range=30000-32767
3.1.3 高可用架构
┌─────────────────────────────────────────────────────────┐
│ API Server 高可用部署 │
├─────────────────────────────────────────────────────────┤
│ │
│ 客户端请求（kubectl, controller, scheduler） │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ Load Balancer (L4) │ │
│ │ 192.168.1.100:6443 │ │
│ └──────────────┬──────────────────┘ │
│ │ │
│ ┌───────────┼───────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ APIS │ │ APIS │ │ APIS │ │
│ │erver1│ │erver2│ │erver3│ │
│ └──┬─── └──┬───┘ └──┬─── │
│ │ │ │ │
│ └─────────┼─────────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ etcd │ │
│ │ 集群 │ │
│ └─────────┘ │
│ │
│ 无状态设计： │
│ ✓ API Server 无状态，可水平扩展 │
│ ✓ 所有状态存储在 etcd │
│ ✓ 客户端通过 LB 连接，自动故障转移 │
│ ✓ 每个 API Server 独立处理请求，无共享内存 │
│ │
│ 负载均衡策略： │
│ - Round Robin（轮询） │
│ - Least Connection（最少连接） │
│ - Source Hashing（源地址哈希） │
└─────────────────────────────────────────────────────────┘
3.2 Scheduler：智能调度决策引擎
3.2.1 调度流程深度解析
两阶段提交流程：
┌─────────────────────────────────────────────────────────┐
│ Kubernetes 调度器两阶段提交流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 阶段 1: 过滤（Predicate） - 找出所有可行节点 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 输入：Pod 规格、集群状态 │ │
│ │ │ │
│ │ 过滤规则（按执行顺序）： │ │
│ │ 1. NodeResourcesFit │ │
│ │ ├─ CPU 请求 <= 节点可用 CPU │ │
│ │ ├─ 内存请求 <= 节点可用内存 │ │
│ │ └─ 临时存储请求 <= 节点可用存储 │ │
│ │ │ │
│ │ 2. NodeAffinity │ │
│ │ ├─ requiredDuringScheduling │ │
│ │ └─ 节点标签匹配 │ │
│ │ │ │
│ │ 3. TaintToleration │ │
│ │ ├─ 检查节点污点 │ │
│ │ └─ Pod 是否容忍 │ │
│ │ │ │
│ │ 4. PodAffinity │ │
│ │ ├─ 节点亲和性（required） │ │
│ │ └─ Pod 分布约束 │ │
│ │ │ │
│ │ 5. Volume 约束 │ │
│ │ ├─ PV 可用性 │ │
│ │ ├─ 存储拓扑约束 │ │
│ │ └─ 卷模式冲突检测 │ │
│ │ │ │
│ │ 6. 其他约束 │ │
│ │ ├─ 端口冲突检测 │ │
│ │ ├─ 设备插件可用性 │ │
│ │ └─ 自定义调度器钩子 │ │
│ │ │ │
│ │ 输出：可行节点列表（可能为 0-N 个） │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 阶段 2: 打分（Priority） - 选择最优节点 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 输入：可行节点列表 │ │
│ │ │ │
│ │ 打分规则（权重可配置）： │ │
│ │ 1. NodeResourcesBalancedAllocation (权重 1) │ │
│ │ ├─ CPU 利用率均衡（避免碎片化） │ │
│ │ └─ 内存利用率均衡 │ │
│ │ 公式：score = 10 - (|cpuUtil - memUtil|) │ │
│ │ │ │
│ │ 2. ImageLocality (权重 1) │ │
│ │ ├─ 检查节点已有镜像 │ │
│ │ └─ 减少镜像拉取时间 │ │
│ │ │ │
│ │ 3. InterPodAffinity (权重 1) │ │
│ │ ├─ Pod 亲和性得分（聚集部署） │ │
│ │ └─ Pod 反亲和性得分（分散部署） │ │
│ │ │ │
│ │ 4. NodeAffinity (权重 1) │ │
│ │ └─ preferredDuringScheduling 得分 │ │
│ │ │ │
│ │ 5. TaintToleration (权重 1) │ │
│ │ └─ 容忍度越少得分越高 │ │
│ │ │ │
│ │ 6. PodTopologySpread (权重 1) │ │
│ │ ├─ 跨可用区均衡 │ │
│ │ └─ 跨节点均衡 │ │
│ │ │ │
│ │ 7. 自定义优先级 │ │
│ │ └─ PriorityClass 定义 │ │
│ │ │ │
│ │ 计算： │ │
│ │ totalScore = Σ(ruleScore * weight) │ │
│ │ │ │
│ │ 输出：得分最高的节点 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 阶段 3: 绑定（Bind） │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 1. 创建 PodBinding 对象 │ │
│ │ 2. API Server 更新 Pod 的 spec.nodeName │ │
│ │ 3. 调度完成，kubelet 接管 │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
3.3 Controller Manager：集群状态守护者
3.3.1 核心控制器详解
10 大核心控制器：
┌─────────────────────────────────────────────────────────┐
│ Controller Manager 核心控制器 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Node Controller（节点控制器） │
│ ├─ 职责：监控节点健康状态 │
│ ├─ 检测：kubelet 心跳（默认 40 秒） │
│ ├─ 动作：标记 NotReady、驱逐 Pod │
│ └─ 参数：--node-monitor-period=5s │
│ --node-monitor-grace-period=40s │
│ --pod-eviction-timeout=5m0s │
│ │
│ 2. Replication Controller（副本控制器） │
│ ├─ 职责：维护 Pod 副本数 │
│ ├─ 检测：实际副本数 vs 期望副本数 │
│ ├─ 动作：创建/删除 Pod │
│ └─ 应用场景：Deployment, ReplicaSet │
│ │
│ 3. Deployment Controller（部署控制器） │
│ ├─ 职责：管理 Deployment 生命周期 │
│ ├─ 功能：滚动更新、回滚、暂停/恢复 │
│ ├─ 策略：RollingUpdate, Recreate │
│ └─ 参数：--deployment-sync-period=10m0s │
│ │
│ 4. StatefulSet Controller（有状态集控制器） │
│ ├─ 职责：管理 StatefulSet │
│ ├─ 特性：有序部署、有序删除、稳定网络标识 │
│ └─ 场景：数据库、分布式存储 │
│ │
│ 5. DaemonSet Controller（守护集控制器） │
│ ├─ 职责：确保每个节点运行指定 Pod │
│ ├─ 场景：日志收集、监控代理 │
│ └─ 调度：直接调度，绕过 scheduler │
│ │
│ 6. Job Controller（任务控制器） │
│ ├─ 职责：管理一次性任务 │
│ ├─ 类型：一次性、并行、定时 │
│ └─ 场景：批处理、数据迁移 │
│ │
│ 7. CronJob Controller（定时任务控制器） │
│ ├─ 职责：按 Cron 表达式调度 Job │
│ ├─ 参数：--concurrent-syncs=5 │
│ └─ 场景：定时备份、定期清理 │
│ │
│ 8. Endpoint Controller（端点控制器） │
│ ├─ 职责：维护 Service 与 Pod 的映射 │
│ ├─ 触发：Pod 状态变化、Service 变化 │
│ └─ 输出：Endpoints 对象 │
│ │
│ 9. Service Account Controller（服务账户控制器） │
│ ├─ 职责：创建 ServiceAccount 的 Token │
│ ├─ 输出：Secret (Token) │
│ └─ 场景：Pod 访问 API Server │
│ │
│ 10. Namespace Controller（命名空间控制器） │
│ ├─ 职责：清理已删除 Namespace 的资源 │
│ └─ 动作：删除所有资源、移除 Finalizer │
└─────────────────────────────────────────────────────────┘
4. 工作节点组件深度剖析
4.1 Kubelet：节点代理与 Pod 管理器
4.1.1 核心职责
Kubelet 职责分解：
┌─────────────────────────────────────────────────────────┐
│ Kubelet 架构与职责 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Pod 生命周期管理 │
│ ├─ 创建 Pod：调用 CRI 创建容器 │
│ ├─ 启动容器：配置网络、存储、环境变量 │
│ ├─ 健康检查：liveness/readiness 探针 │
│ └─ 终止 Pod：优雅关闭、资源清理 │
│ │
│ 2. 资源管理 │
│ ├─ CPU 管理：CFS Quota、CPUset │
│ ├─ 内存管理：cgroups 内存限制 │
│ ├─ 存储管理：挂载 Volume │
│ └─ 网络管理：调用 CNI 插件 │
│ │
│ 3. 节点状态上报 │
│ ├─ 心跳：每 10 秒上报 API Server │
│ ├─ 资源：CPU/内存/磁盘使用率 │
│ ├─ 条件：Ready/DiskPressure/MemoryPressure │
│ └─ 镜像：已拉取镜像列表 │
│ │
│ 4. 容器运行时接口（CRI） │
│ ├─ containerd（推荐） │
│ ├─ CRI-O │
│ └─ Docker（已废弃） │
│ │
│ 5. 插件接口 │
│ ├─ CNI：容器网络（Calico, Flannel） │
│ ├─ CSI：容器存储（NFS, Ceph） │
│ └── Device Plugin：GPU、FPGA 等设备 │
└─────────────────────────────────────────────────────────┘
4.1.2 Pod 创建完整流程
┌─────────────────────────────────────────────────────────┐
│ Kubelet 内部 Pod 创建流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. 同步 Pod（Sync Loop） │
│ └─ 每 1 秒执行一次 │
│ │ │
│ ▼ │
│ 从 API Server 获取分配到本节点的 Pod │
│ │ │
│ ▼ │
│ 对比本地 Pod 状态 │
│ │ │
│ ├─► Pod 不存在 ──► 创建 Pod │
│ ├─► Pod 已删除 ──► 终止 Pod │
│ └─► Pod 存在 ──► 检查健康状态 │
│ │
│ 2. 容器创建流程 │
│ ┌─────────────────────────────────┐ │
│ │ 1. 调用 CRI 创建 Sandbox 容器（Pause）│ │
│ │ ├─ 分配网络命名空间 │ │
│ │ └─ 预留 IP 地址 │ │
│ │ │ │
│ │ 2. 调用 CNI 配置网络 │ │
│ │ ├─ 分配 Pod IP │ │
│ │ ├─ 配置路由表 │ │
│ │ └─ 设置网络策略 │ │
│ │ │ │
│ │ 3. 调用 CSI 挂载存储（如有） │ │
│ │ ├─ 附加卷到节点 │ │
│ │ ├─ 格式化文件系统 │ │
│ │ └─ 挂载到容器 │ │
│ │ │ │
│ │ 4. 创建业务容器 │ │
│ │ ├─ 拉取镜像 │ │
│ │ ├─ 设置环境变量 │ │
│ │ ├─ 挂载 Volume │ │
│ │ └─ 启动容器 │ │
│ └─────────────────────────────────┘ │
│ │
│ 3. 健康检查循环 │
│ └─ 每 10 秒执行一次 │
│ │ │
│ ├─► Liveness 探针失败 ──► 重启容器 │
│ ├─► Readiness 探针失败 ──► 从 Service 移除 │
│ └─► Startup 探针失败 ──► 等待启动 │
│ │
│ 4. 资源回收 │
│ ├─ 已终止 Pod 的容器 │
│ ├─ 超过阈值的镜像（--image-gc-high-threshold） │
│ └─ 僵尸容器和卷 │
└─────────────────────────────────────────────────────────┘
4.2 Kube-proxy：服务发现与负载均衡
4.2.1 三种工作模式对比
工作模式详解：
┌─────────────────────────────────────────────────────────┐
│ Kube-proxy 三种工作模式对比 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Userspace 模式（已废弃） │
│ ┌─────────────────────────────────┐ │
│ │ Client ──► Kube-proxy ──► Pod │ │
│ │ (用户态代理) │ │
│ └─────────────────────────────────┘ │
│ ✗ 性能差：每次请求经过用户态 │
│ ✗ 额外跳数：增加网络延迟 │
│ ✓ 历史意义：第一种实现方式 │
│ │
│ 2. Iptables 模式（默认） │
│ ┌─────────────────────────────────┐ │
│ │ Client ──► iptables ──► Pod │ │
│ │ (内核态 NAT) │ │
│ └─────────────────────────────────┘ │
│ ✓ 性能好：内核态处理 │
│ ✓ 稳定：成熟技术 │
│ ✗ O(n) 复杂度：规则链随 Service 增多变长 │
│ ✗ 更新慢：全量替换 iptables 规则 │
│ │
│ 3. IPVS 模式（推荐） │
│ ┌─────────────────────────────────┐ │
│ │ Client ──► IPVS ──► Pod │ │
│ │ (L4 负载均衡) │ │
│ └─────────────────────────────────┘ │
│ ✓ 性能优：O(1) 复杂度 │
│ ✓ 更新快：增量更新规则 │
│ ✓ 算法多：支持 11 种负载均衡算法 │
│ ✓ 支持健康检查：自动剔除故障 Pod │
│ ⚠ 要求：内核支持 IPVS 模块 │
└─────────────────────────────────────────────────────────┘
4.2.2 IPVS 模式详解
IPVS 规则示例：
Service: my-service (ClusterIP: 10.96.100.1:80)
Endpoints:
- 10.244.1.10:8080 (Pod-1)
- 10.244.2.20:8080 (Pod-2)
- 10.244.3.30:8080 (Pod-3)
IPVS 规则：
┌─────────────────────────────────────────────────────────┐
│ IP Virtual Server version 1.2.1 (size=4096) │
├─────────────────────────────────────────────────────────┤
│ │
│ TCP 10.96.100.1:80 rr │
│ ├─► 10.244.1.10:8080 Masq 1 0 │
│ ├─► 10.244.2.20:8080 Masq 1 0 │
│ └─► 10.244.3.30:8080 Masq 1 0 │
│ │
│ 负载均衡算法： │
│ - rr: Round Robin（轮询） │
│ - wrr: Weighted Round Robin（加权轮询） │
│ - lc: Least Connection（最少连接） │
│ - wlc: Weighted Least Connection（加权最少连接） │
│ - lblc: Locality-Based Least Connection │
│ - lblcr: Locality-Based Least Connection with Replication │
│ - dh: Destination Hashing（目标哈希） │
│ - sh: Source Hashing（源哈希） │
│ - sed: Shortest Expected Delay（最短期望延迟） │
│ - nq: Never Queue（不排队） │
│ - fov: First Only Voting（FOVO） │
│ │
│ 请求流程： │
│ Client (192.168.1.100:5000) │
│ │ │
│ ▼ │
│ 访问 10.96.100.1:80 │
│ │ │
│ ▼ │
│ IPVS 查表（rr 算法） │
│ │ │
│ ├─► 请求 1: 10.244.1.10:8080（Pod-1） │
│ ├─► 请求 2: 10.244.2.20:8080（Pod-2） │
│ ├─► 请求 3: 10.244.3.30:8080（Pod-3） │
│ └─► 请求 4: 10.244.1.10:8080（Pod-1）循环 │
│ │
│ SNAT（源地址转换）： │
│ 源 IP: 192.168.1.100 ──► 10.244.x.x（Pod 网段） │
│ 目的 IP: 10.96.100.1 ──► 10.244.x.x（Pod IP） │
└─────────────────────────────────────────────────────────┘
5. etcd 分布式存储核心原理
5.1 etcd 核心架构
etcd 集群架构：
┌─────────────────────────────────────────────────────────┐
│ etcd 分布式存储架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ etcd 集群（3 节点） │
│ ┌──────────┐ ┌────────── ┌──────────┐ │
│ │ etcd-1 │ │ etcd-2 │ │ etcd-3 │ │
│ │ Leader │◄─ Follower │◄─ Follower │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └─────────────┼─────────────┘ │
│ │ │
│ Raft 共识算法 │
│ ├─ Leader 选举 │
│ ├─ 日志复制 │
│ └─ 故障恢复 │
│ │
│ 数据模型： │
│ ├─ 键值对存储（Key-Value） │
│ ├─ 键范围：/registry/{resource}/{namespace}/{name} │
│ ├─ 版本控制：每个 Key 有 revision │
│ └─ Watch 机制：变更实时通知 │
│ │
│ 存储结构： │
│ ├─ B+ Tree（内存索引） │
│ ├─ WAL（预写日志） │
│ ├─ Snapshot（快照） │
│ └─ MVCC（多版本并发控制） │
└─────────────────────────────────────────────────────────┘
5.2 Kubernetes 中的 etcd 数据结构
数据目录结构：
/registry/ # 根目录
├── pods/ # Pod 资源
│ ├── default/ # default 命名空间
│ │ ├── pod-1 # Pod 名称
│ │ └── pod-2
│ └── kube-system/
│ └── coredns-xxx
├── deployments/ # Deployment 资源
│ └── default/
│ └── nginx-deployment
├── services/ # Service 资源
├── configmaps/ # ConfigMap 资源
├── secrets/ # Secret 资源
├── nodes/ # Node 资源
├── persistentvolumes/ # PV 资源
└── ...
每个 Key 的值结构：
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "pod-1",
"namespace": "default",
"uid": "abc-123",
"resourceVersion": "12345"
},
"spec": { ... },
"status": { ... }
}
5.3 etcd 性能调优参数
生产环境配置：
# etcd 启动参数（生产环境推荐）
etcd \
# === 集群配置 ===
--name=etcd-1 \
--initial-advertise-peer-urls=https://192.168.1.11:2380 \
--advertise-client-urls=https://192.168.1.11:2379 \
--listen-peer-urls=https://0.0.0.0:2380 \
--listen-client-urls=https://0.0.0.0:2379 \
--initial-cluster=etcd-1=https://192.168.1.11:2380,etcd-2=https://192.168.1.12:2380,etcd-3=https://192.168.1.13:2380 \
# === TLS 配置 ===
--cert-file=/etc/kubernetes/pki/etcd/server.crt \
--key-file=/etc/kubernetes/pki/etcd/server.key \
--client-cert-auth=true \
--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt \
--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt \
--peer-key-file=/etc/kubernetes/pki/etcd/peer.key \
--peer-client-cert-auth=true \
--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt \
# === 性能调优 ===
--heartbeat-interval=100 \ # Leader 心跳间隔（毫秒）
--election-timeout=1000 \ # 选举超时（毫秒）
--quota-backend-bytes=8589934592 \ # 后端存储配额（8GB）
--auto-compaction-mode=periodic \ # 定期压缩
--auto-compaction-retention=1h \ # 1 小时压缩一次
--snapshot-count=10000 \ # 快照计数
--max-snapshots=5 \ # 保留 5 个快照
--max-wals=5 \ # 保留 5 个 WAL
# === 限流配置 ===
--max-request-bytes=1572864 \ # 最大请求 1.5MB
--max-concurrent-streams=100 # 最大并发流
5.4 etcd 监控指标
关键监控指标：
# 关键监控指标
# === 健康指标 ===
etcd_server_has_leader: 1 # 是否有 Leader
etcd_server_leader_changes_seen_total: 0 # Leader 变更次数
# === 性能指标 ===
etcd_disk_backend_commit_duration_seconds:
p99 < 10ms # 磁盘提交延迟
etcd_disk_wal_fsync_duration_seconds:
p99 < 10ms # WAL 写入延迟
etcd_network_peer_round_trip_time_seconds:
p99 < 50ms # 节点间 RTT
# === 容量指标 ===
etcd_mvcc_db_total_size_in_bytes:
< 8GB # 数据库大小
etcd_debugging_mvcc_keys_total:
< 100000 # Key 总数
# === 告警规则 ===
- alert: etcdNoLeader
expr: etcd_server_has_leader == 0
for: 1m
labels:
severity: critical
- alert: etcdHighCommitDuration
expr: histogram_quantile(0.99, rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) > 0.025
for: 5m
labels:
severity: warning
6. 网络模型与 CNI 插件架构
6.1 Kubernetes 网络模型
网络设计原则：
┌─────────────────────────────────────────────────────────┐
│ Kubernetes 网络模型 │
├─────────────────────────────────────────────────────────┤
│ │
│ 核心要求： │
│ 1. Pod IP 可直接通信，无需 NAT │
│ 2. 节点上的 Pod 可与其它节点上的 Pod 通信，无需 NAT │
│ 3. Service 可被 Pod 访问，无需 NAT │
│ 4. Pod IP 与容器内看到的 IP 一致 │
│ │
│ 网络平面： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Pod Network (Overlay) │ │
│ │ - CIDR: 10.244.0.0/16 │ │
│ │ - 每个 Pod 分配唯一 IP │ │
│ │ - 跨节点通信：VXLAN / BGP / IPIP │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Service Network (Virtual) │ │
│ │ - CIDR: 10.96.0.0/12 │ │
│ │ - ClusterIP：虚拟 IP，iptables/IPVS 转发 │ │
│ │ - NodePort：节点端口映射 │ │
│ │ - LoadBalancer：云厂商负载均衡 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Underlay Network (Physical) │ │
│ │ - 节点物理网络：192.168.2.0/24 │ │
│ │ - 网关：192.168.2.1 │ │
│ │ - DNS：192.168.2.1 │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
6.2 CNI 插件架构
CNI 工作原理：
┌─────────────────────────────────────────────────────────┐
│ CNI（Container Network Interface）架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ CNI 插件调用流程： │
│ │
│ Kubelet 创建 Pod │
│ │ │
│ ▼ │
│ 调用 CNI 插件 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 1. ADD 操作：分配 IP、配置网络 │ │
│ │ 输入： │ │
│ │ - Container ID │ │
│ │ - Network Namespace │ │
│ │ - Container Network Interface │ │
│ │ - IPAM 配置 │ │
│ │ │ │
│ │ 输出： │ │
│ │ - Pod IP 地址 │ │
│ │ - 网关地址 │ │
│ │ - 路由表 │ │
│ │ - DNS 配置 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 2. DEL 操作：释放 IP、清理网络 │ │
│ │ 输入：Container ID、Network Namespace │ │
│ │ 输出：无 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 主流 CNI 插件对比： │
│ ┌──────────┬──────────┬──────────┬──────────┐ │
│ │ 插件 │ 性能 │ 功能 │ 复杂度 │ │
│ ├──────────┼──────────┼──────────┼──────────┤ │
│ │ Flannel │ 中 │ 基础 │ 低 │ │
│ │ Calico │ 高 │ 丰富 │ 中 │ │
│ │ Cilium │ 极高 │ 强大 │ 高 │ │
│ │ Weave │ 中 │ 中等 │ 低 │ │
│ └──────────┴──────────┴──────────┴──────────┘ │
└─────────────────────────────────────────────────────────┘
7. 调度器算法与高级调度策略
7.1 调度器架构
调度器组件：
┌─────────────────────────────────────────────────────────┐
│ Kubernetes 调度器架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ 调度器组件： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 1. 调度器框架（Scheduler Framework） │ │
│ │ ├─ 插件机制（Plugin） │ │
│ │ ├─ 扩展点（Extension Point） │ │
│ │ └─ 调度周期（Scheduling Cycle） │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 2. 调度器配置（Scheduler Configuration） │ │
│ │ ├─ 配置文件（YAML） │ │
│ │ ├─ 插件启用/禁用 │ │
│ │ └─ 参数调优 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 3. 调度器日志（Scheduler Logging） │ │
│ │ ├─ 结构化日志 │ │
│ │ ├─ 指标导出 │ │
│ │ └─ 追踪（Tracing） │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
7.2 高级调度策略
Pod 亲和性/反亲和性配置：
apiVersion: v1
kind: Pod
metadata:
name: web-pod
spec:
affinity:
# Pod 亲和性：与 Redis Pod 部署在同一节点
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- redis
topologyKey: kubernetes.io/hostname
# Pod 反亲和性：避免与同应用 Pod 部署在同一节点
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: kubernetes.io/hostname
# 节点亲和性：优先选择 SSD 节点
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: zone
operator: In
values:
- us-east-1a
- us-east-1b
8. 生产环境高可用架构
8.1 多 Master 高可用
架构设计：
┌─────────────────────────────────────────────────────────┐
│ Kubernetes 高可用架构（3-5-7 原则） │
├─────────────────────────────────────────────────────────┤
│ │
│ Master 节点数量选择： │
│ - 3 节点：容忍 1 个故障（推荐） │
│ - 5 节点：容忍 2 个故障（大型集群） │
│ - 7 节点：容忍 3 个故障（超大型集群） │
│ │
│ 为什么选择奇数？ │
│ - Raft 共识算法需要多数派（Quorum） │
│ - 3 节点：需要 2 票同意（容忍 1 故障） │
│ - 4 节点：也需要 3 票同意（容忍 1 故障，浪费） │
│ - 5 节点：需要 3 票同意（容忍 2 故障） │
│ │
│ 部署建议： │
│ - 跨可用区部署（AZ） │
│ - 独立 etcd 集群（大型集群） │
│ - 负载均衡器高可用（Keepalived + HAProxy） │
│ - 定期备份 etcd 数据 │
└─────────────────────────────────────────────────────────┘
8.2 灾难恢复方案
备份与恢复策略：
#!/bin/bash
# etcd 备份脚本
ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
--endpoints=https://192.168.1.11:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key
# 验证备份
ETCDCTL_API=3 etcdctl snapshot status snapshot.db \
--write-out=table
# 恢复集群
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db \
--data-dir=/var/lib/etcd-from-backup \
--name=etcd-1 \
--initial-cluster=etcd-1=https://192.168.1.11:2380,etcd-2=https://192.168.1.12:2380,etcd-3=https://192.168.1.13:2380 \
--initial-cluster-token=etcd-cluster-1 \
--initial-advertise-peer-urls=https://192.168.1.11:2380
9. 性能调优实战
9.1 API Server 性能调优
关键参数：
kube-apiserver \
--max-requests-inflight=400 \
--max-mutating-requests-inflight=200 \
--request-timeout=1m0s \
--min-request-timeout=300 \
--max-connections=1000
9.2 etcd 性能调优
关键参数：
etcd \
--heartbeat-interval=100 \
--election-timeout=1000 \
--quota-backend-bytes=8589934592 \
--auto-compaction-mode=periodic \
--auto-compaction-retention=1h
10. 故障排查与案例分析
10.1 常见故障排查
Pod Pending 故障：
# 1. 查看 Pod 状态
kubectl get pod <pod-name> -o wide
# 2. 查看 Pod 事件
kubectl describe pod <pod-name>
# 3. 查看调度器日志
kubectl logs -n kube-system -l component=kube-scheduler
# 4. 查看节点资源
kubectl top nodes
# 5. 检查节点污点
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.taints}{"\n"}{end}'
10.2 案例分析
案例 1：etcd 性能瓶颈
症状：
- API Server 响应慢
- Pod 创建失败
- 集群操作超时
排查：
# 检查 etcd 延迟
etcdctl endpoint status --write-out=table
# 检查 etcd 健康状态
etcdctl endpoint health
# 检查 etcd 指标
curl -s http://localhost:2380/metrics | grep etcd_disk
解决方案：
- 升级 SSD 磁盘
- 独立 etcd 集群
- 调整 etcd 参数
- 定期压缩和快照
总结
本文深度解析了 Kubernetes 的核心架构与组件原理，涵盖：
- Kubernetes 演进史：从手工脚本到云原生时代
- 整体架构：控制平面与数据平面的协作
- 核心组件：API Server、Scheduler、Controller Manager、etcd 的 internals
- 工作节点：Kubelet、Kube-proxy 的工作原理
- 分布式存储：etcd 的 Raft 共识与性能调优
- 网络模型：CNI 插件与网络架构
- 调度算法：两阶段提交与高级调度策略
- 高可用架构：多 Master 部署与灾难恢复
- 性能调优：生产环境参数配置
- 故障排查：实战案例与解决方案
掌握这些知识，您将具备生产级 Kubernetes 集群的架构设计与运维能力。
参考文献：
- Kubernetes 官方文档：https://kubernetes.io/docs/
- Kubernetes 权威指南（第 3 版）
- CNCF 云原生白皮书
- etcd 官方文档：https://etcd.io/docs/
- Kubernetes 源码：https://github.com/kubernetes/kubernetes
开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。
更多推荐
9
0- 0
已为社区贡献18条内容
所有评论(0)