一旦进项目，好看的架构图就没那么管用了。
Swarm 集群跑了几个月，服务发现、滚动更新、跨节点网络都还行；微服务数量上来、要细粒度扩缩容和 CRD 扩展时，才开始认真评估 K8s。
容器编排基础
容器编排需求
容器管理：管理大量容器的生命周期。
服务发现：自动发现和注册服务。
负载均衡：在容器间均衡负载。
自动扩缩容：根据负载自动调整容器数量。
graph TB
subgraph 容器编排需求
A[容器管理]
B[服务发现]
C[负载均衡]
D[自动扩缩容]
end
subgraph 具体功能
E[创建/删除]
F[健康检查]
G[流量分发]
H[容量规划]
end
A --> E
B --> F
C --> G
D --> H
subgraph 业务价值
I[简化运维]
J[提高可用性]
K[优化资源]
L[降低成本]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
容器编排架构
控制平面：负责集群的控制和管理。
数据平面：负责实际的工作负载运行。
网络层：负责容器间的网络通信。
存储层：负责容器的持久化存储。
graph TB
subgraph 容器编排架构
A[控制平面]
A --> B[数据平面]
A --> C[网络层]
A --> D[存储层]
end
subgraph 控制平面组件
E[API服务器]
F[调度器]
G[控制器]
H[etcd存储]
end
A --> E
A --> F
A --> G
A --> H
subgraph 数据平面组件
I[Kubelet]
J[Kube-proxy]
K[容器运行时]
end
B --> I
B --> J
B --> K
style A fill:#FFD700,stroke:#DAA520,stroke-width:2px
style E fill:#90EE90,stroke:#006400,stroke-width:1px
Docker Swarm
Docker Swarm是Docker原生的容器编排解决方案。
Swarm架构
Manager节点：负责集群管理。
Worker节点：负责运行容器。
Raft协议：用于Manager节点间的协调。
服务模型：基于服务的容器编排模型。
graph TB
subgraph Swarm集群
A[Manager节点1]
B[Manager节点2]
C[Manager节点3]
D[Worker节点1]
E[Worker节点2]
F[Worker节点N]
end
subgraph Raft一致性
A <--> B
B <--> C
A <--> C
end
subgraph 任务分发
G[调度器]
G --> D
G --> E
G --> F
end
A --> G
B --> G
C --> G
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
Swarm服务
服务定义：定义服务的期望状态。
任务调度：将服务调度到合适的节点。
负载均衡：服务间的负载均衡。
滚动更新：服务的滚动更新机制。
sequenceDiagram
participant User as 用户
participant Manager as Swarm Manager
participant Scheduler as 调度器
participant Worker as Worker节点
participant Container as 容器
User->>Manager: 创建服务
Manager->>Scheduler: 提交服务定义
Scheduler->>Scheduler: 资源评估
Scheduler->>Worker: 分配任务
Worker->>Container: 启动容器
Container-->>Worker: 容器就绪
Worker-->>Scheduler: 任务状态更新
Scheduler-->>Manager: 服务状态更新
Manager-->>User: 服务创建完成
Note over User,Container: Swarm服务创建流程
Swarm网络
Overlay网络：跨主机的容器网络。
服务发现：内置的服务发现机制。
负载均衡：内置的负载均衡功能。
网络隔离：不同服务的网络隔离。
graph TB
subgraph Swarm网络
A[服务A]
B[服务B]
C[Overlay网络]
end
subgraph 节点分布
D[节点1]
E[节点2]
F[节点3]
end
A --> C
B --> C
C --> D
C --> E
C --> F
subgraph 网络特性
G[跨节点通信]
H[服务发现]
I[负载均衡]
J[网络安全]
end
C --> G
C --> H
C --> I
C --> J
style C fill:#87CEEB,stroke:#1E90FF,stroke-width:2px
Kubernetes架构
Kubernetes是目前最流行的容器编排系统。
K8s核心组件
API Server：集群的统一入口。
etcd：集群的键值存储。
Scheduler：负责Pod调度。
Controller Manager：负责集群状态维护。
graph TB
subgraph K8s控制平面
A[API Server]
B[etcd]
C[Scheduler]
D[Controller Manager]
end
subgraph 交互关系
E[存储数据]
F[调度决策]
G[状态管理]
end
A --> B: E
A --> C: F
A --> D: G
subgraph 外部接口
H[kubectl]
I[Dashboard]
J[API客户端]
end
A --> H
A --> I
A --> J
style A fill:#FFD700,stroke:#DAA520,stroke-width:2px
style B fill:#90EE90,stroke:#006400,stroke-width:1px
Pod概念
最小部署单元：Pod是K8s的最小部署单元。
共享网络：Pod内容器共享网络命名空间。
共享存储：Pod内容器共享存储卷。
生命周期：Pod有独立的生命周期。
graph TB
subgraph Pod结构
A[Pod]
A --> B[容器1]
A --> C[容器2]
A --> D[共享存储]
end
subgraph 网络命名空间
E[共享网络栈]
E --> F[共享IP地址]
E --> G[共享端口空间]
end
A --> E
subgraph 存储卷
H[EmptyDir]
I[ConfigMap]
J[Secret]
end
D --> H
D --> I
D --> J
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style E fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
控制器模式
副本控制器：维护Pod的副本数量。
部署控制器：管理应用的部署和更新。
状态集控制器：管理有状态应用。
守护集控制器：在每个节点上运行一个Pod。
sequenceDiagram
participant API as API Server
participant Controller as 控制器
participant Scheduler as 调度器
participant Kubelet as Kubelet
participant Pod as Pod
API->>Controller: 监听资源变化
Controller->>Controller: 调谐循环
Controller->>API: 创建Pod对象
API->>Scheduler: 通知新Pod
Scheduler->>Scheduler: 调度决策
Scheduler->>API: 更新Pod绑定
API->>Kubelet: 通知Pod创建
Kubelet->>Pod: 创建容器
Pod-->>Kubelet: 容器状态
Kubelet->>API: 更新Pod状态
API->>Controller: 通知状态更新
Note over API,Pod: 控制器工作流程
K8s资源管理
K8s提供了丰富的资源管理能力。
Deployment
声明式配置：使用声明式配置定义应用。
滚动更新：支持应用的滚动更新。
回滚机制：支持应用的回滚操作。
扩缩容：支持应用的扩缩容。
graph TB
subgraph Deployment生命周期
A[创建Deployment]
A --> B[创建ReplicaSet]
B --> C[创建Pod]
C --> D[Pod运行]
end
subgraph 更新流程
E[更新Deployment]
E --> F[创建新ReplicaSet]
F --> G[逐步扩展新Pod]
G --> H[逐步收缩旧Pod]
end
subgraph 回滚流程
I[触发回滚]
I --> J[恢复旧ReplicaSet]
J --> K[清理新ReplicaSet]
end
D --> E
H --> I
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style E fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
Service与Ingress
Service：提供稳定的服务访问入口。
ClusterIP：集群内部可访问的服务。
NodePort：通过节点端口暴露服务。
LoadBalancer：通过负载均衡器暴露服务。
Ingress：基于HTTP的路由规则。
graph TB
subgraph Service类型
A[ClusterIP]
B[NodePort]
C[LoadBalancer]
end
subgraph 访问方式
D[集群内部]
E[节点端口]
F[外部负载均衡]
end
A --> D
B --> E
C --> F
subgraph Ingress
G[Ingress Controller]
G --> H[路由规则]
H --> I[后端服务]
end
F --> G
D --> I
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style G fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
ConfigMap与Secret
ConfigMap：存储配置数据。
Secret：存储敏感数据。
环境变量：将配置注入环境变量。
挂载卷：将配置挂载为文件。
graph TB
subgraph 配置管理
A[ConfigMap]
B[Secret]
end
subgraph 注入方式
C[环境变量]
D[挂载卷]
E[命令行参数]
end
A --> C
A --> D
B --> C
B --> D
subgraph 数据特性
F[明文存储]
G[Base64编码]
H[加密存储]
end
A --> F
B --> G
B --> H
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style B fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
存储管理
K8s提供了灵活的存储管理能力。
存储卷类型
EmptyDir：Pod删除时数据丢失。
HostPath：使用主机路径。
PersistentVolume：持久化存储卷。
StorageClass：动态存储分配。
graph TB
subgraph 存储卷类型
A[EmptyDir]
B[HostPath]
C[PersistentVolume]
D[StorageClass]
end
subgraph 存储特性
E[临时存储]
F[节点存储]
G[持久存储]
H[动态分配]
end
A --> E
B --> F
C --> G
D --> H
subgraph 生命周期
I[Pod生命周期]
J[集群生命周期]
K[动态创建]
end
A --> I
C --> J
D --> K
style C fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
PV与PVC
PersistentVolume：集群级别的存储资源。
PersistentVolumeClaim：命名空间级别的存储请求。
绑定机制：PV与PVC的绑定机制。
回收策略：PV的回收策略。
sequenceDiagram
participant Admin as 管理员
participant K8s as Kubernetes
PV as PersistentVolume
PVC as PersistentVolumeClaim
Pod as Pod
Admin->>PV: 创建PV
PV->>K8s: 注册PV
Admin->>PVC: 创建PVC
PVC->>K8s: 请求存储
K8s->>K8s: 匹配PV
K8s->>PVC: 绑定PV
Pod->>PVC: 挂载存储
PVC->>PV: 使用存储
Note over Admin,Pod: PV/PVC绑定流程
网络管理
K8s提供了强大的网络管理能力。
网络模型
扁平网络：所有Pod在同一个扁平网络中。
无NAT：Pod间通信无需NAT。
IP分配：每个Pod有独立的IP地址。
网络策略：支持网络访问控制。
graph TB
subgraph K8s网络模型
A[Pod1<br/>10.244.0.2]
B[Pod2<br/>10.244.0.3]
C[Pod3<br/>10.244.1.2]
D[PodN<br/>10.244.255.254]
end
subgraph 网络特性
E[扁平地址空间]
F[无需NAT]
G[IP-per-Pod]
end
A --> E
B --> F
C --> G
subgraph 网络实现
H[CNI插件]
I[网络策略]
end
D --> H
A --> I
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style H fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
CNI插件
Flannel：简单的Overlay网络。
Calico：基于BGP的网络。
Weave Net：加密的网络解决方案。
Cilium：基于eBPF的网络。
graph TB
subgraph CNI插件对比
A[Flannel]
B[Calico]
C[Weave Net]
D[Cilium]
end
subgraph 网络技术
E[VXLAN Overlay]
F[BGP路由]
G[加密Overlay]
H[eBPF]
end
A --> E
B --> F
C --> G
D --> H
subgraph 适用场景
I[简单场景]
J[生产环境]
K[安全需求]
L[高性能需求]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
调度与扩缩容
K8s提供了智能的调度和扩缩容能力。
调度策略
资源请求：Pod的资源需求。
资源限制：Pod的资源限制。
节点选择器：选择特定的节点。
亲和性规则：定义Pod的亲和性规则。
graph TB
subgraph 调度流程
A[待调度Pod]
A --> B[过滤节点]
B --> C[打分排序]
C --> D[选择节点]
D --> E[绑定Pod]
end
subgraph 调度约束
F[资源需求]
G[节点选择器]
H[亲和性规则]
I[反亲和性规则]
end
B --> F
B --> G
C --> H
C --> I
subgraph 调度策略
J[资源利用率]
K[负载均衡]
L[高可用性]
end
C --> J
C --> K
C --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
自动扩缩容
HPA：基于CPU/内存的水平扩缩容。
VPA：垂直扩缩容。
Cluster Autoscaler：集群节点的自动扩缩容。
自定义指标：基于自定义指标的扩缩容。
sequenceDiagram
participant Monitor as 监控系统
participant Metrics as 指标服务
participant HPA as HPA控制器
participant Deployment as Deployment
participant Cluster as Cluster Autoscaler
Monitor->>Metrics: 收集指标
Metrics->>HPA: 提供指标
HPA->>HPA: 计算期望副本数
alt 需要扩容
HPA->>Deployment: 扩容副本
Deployment->>Cluster: 检查资源
Cluster->>Cluster: 增加节点
else 需要缩容
HPA->>Deployment: 缩容副本
Deployment->>Cluster: 检查资源
Cluster->>Cluster: 减少节点
end
Note over Monitor,Cluster: 自动扩缩容流程
服务网格
服务网格为微服务提供了丰富的网络功能。
服务网格架构
数据平面：使用Sidecar代理处理网络流量。
控制平面：管理配置和策略。
服务发现：自动的服务发现机制。
流量管理：精细的流量管理能力。
graph TB
subgraph 服务网格架构
A[应用Pod]
A --> B[Sidecar代理]
B --> C[控制平面]
end
subgraph 数据平面
D[Envoy代理]
E[流量拦截]
F[负载均衡]
end
B --> D
B --> E
B --> F
subgraph 控制平面
G[配置管理]
H[策略管理]
I[证书管理]
end
C --> G
C --> H
C --> I
style C fill:#FFD700,stroke:#DAA520,stroke-width:2px
style D fill:#90EE90,stroke:#006400,stroke-width:1px
Istio特性
流量管理：智能的流量路由。
安全：服务间的安全通信。
可观测性：丰富的监控和追踪能力。
策略执行：统一的策略执行。
graph TB
subgraph Istio核心功能
A[流量管理]
B[安全]
C[可观测性]
D[策略执行]
end
subgraph 具体特性
E[请求路由]
F[mTLS]
G[分布式追踪]
H[访问控制]
end
A --> E
B --> F
C --> G
D --> H
subgraph 应用价值
I[流量控制]
J[安全加固]
K[故障排查]
L[合规管理]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style B fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
运维实践
有效的运维实践是保证K8s集群稳定运行的关键。
集群部署
kubeadm：官方的集群部署工具。
kops：AWS上的集群部署工具。
Rancher：企业级K8s管理平台。
云服务商：使用云服务商的托管K8s。
graph TB
subgraph 部署方式
A[kubeadm]
B[kops]
C[Rancher]
D[云服务商K8s]
end
subgraph 部署特点
E[官方工具]
F[AWS优化]
G[企业级管理]
H[托管服务]
end
A --> E
B --> F
C --> G
D --> H
subgraph 适用场景
I[自建集群]
J[AWS环境]
K[企业环境]
L[生产环境]
end
A --> I
B --> J
C --> K
D --> L
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
监控与日志
Prometheus：监控指标收集。
Grafana：监控数据可视化。
ELK Stack：日志收集和分析。
分布式追踪：应用性能监控。
graph TB
subgraph 监控日志体系
A[Prometheus]
B[Grafana]
C[ELK Stack]
D[Jaeger]
end
subgraph 功能覆盖
E[指标收集]
F[数据可视化]
G[日志分析]
H[分布式追踪]
end
A --> E
B --> F
C --> G
D --> H
subgraph 数据源
I[cAdvisor]
J[Filebeat]
K[应用埋点]
end
A --> I
C --> J
D --> K
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
最佳实践
基于实际项目的K8s最佳实践。
设计原则
声明式配置：使用声明式而非命令式配置。
不可变基础设施：使用不可变的基础设施。
单一职责：每个组件职责单一。
资源限制：设置合理的资源限制。
graph TB
subgraph 设计原则
A[声明式配置]
B[不可变基础设施]
C[单一职责]
D[资源限制]
end
subgraph 实施要点
E[GitOps]
F[镜像构建]
G[微服务设计]
H[配额管理]
end
A --> E
B --> F
C --> G
D --> H
subgraph 质量保证
I[配置管理]
J[版本控制]
K[资源监控]
end
A --> I
B --> J
D --> K
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style B fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
安全实践
RBAC：基于角色的访问控制。
网络策略：网络安全策略。
镜像扫描：容器镜像安全扫描。
Secret管理：安全的Secret管理。
sequenceDiagram
participant User as 用户
participant K8s as Kubernetes
participant RBAC as RBAC
participant Policy as 网络策略
participant Scanner as 镜像扫描器
User->>K8s: 访问集群
K8s->>RBAC: 验证权限
RBAC-->>K8s: 权限检查结果
alt 权限通过
K8s->>Policy: 检查网络策略
Policy-->>K8s: 策略检查结果
K8s->>Scanner: 扫描镜像
Scanner-->>K8s: 扫描结果
alt 镜像安全
K8s-->>User: 执行操作
else 镜像不安全
K8s-->>User: 拒绝操作
end
else 权限拒绝
K8s-->>User: 拒绝访问
end
Note over User,Scanner: K8s安全检查流程
未来发展趋势
容器编排技术仍在不断发展，未来的趋势包括：
Serverless容器
无服务器容器：按需运行的容器实例。
自动扩缩容：完全自动的扩缩容。
按需付费：按实际使用付费。
简化运维：大幅简化运维工作。
graph TB
subgraph Serverless容器特性
A[按需运行]
B[自动扩缩容]
C[按需付费]
D[简化运维]
end
subgraph 技术实现
E[函数计算]
F[事件驱动]
G[冷启动优化]
end
A --> E
B --> F
C --> G
subgraph 应用价值
H[降低成本]
I[提高效率]
J[减少复杂度]
end
A --> H
B --> I
D --> J
style A fill:#90EE90,stroke:#006400,stroke-width:1px
style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px
边缘计算
边缘部署：在边缘节点部署K8s。
离线运行：支持离线运行模式。
轻量级：适配边缘设备的轻量级K8s。
统一管理：云边统一的集群管理。
graph TB
subgraph 云边协同架构
A[云中心集群]
A --> B[边缘节点1]
A --> C[边缘节点2]
A --> D[边缘节点N]
end
subgraph 边缘特性
E[资源受限]
F[网络不稳定]
G[离线运行]
end
B --> E
C --> F
D --> G
subgraph 统一管理
H[统一控制面]
I[应用分发]
J[状态同步]
end
A --> H
A --> I
A --> J
style A fill:#FFD700,stroke:#DAA520,stroke-width:2px
style H fill:#90EE90,stroke:#006400,stroke-width:1px
收个尾
Swarm 上手快、和 Docker CLI 一体，小团队、服务量不大时够用。要细粒度调度、丰富 CRD、成熟生态和可观测性，K8s 基本是默认选项——代价是控制面复杂、运维门槛高。
编排工具解决的是容器生命周期、服务发现、扩缩容和故障恢复；选 Swarm 还是 K8s，看团队规模、服务复杂度和有没有专职平台同学。别为了追标准硬上 K8s，也别在明显需要 K8s 的能力时硬撑 Swarm。
版权声明: 本文首发于
指尖魔法屋-容器编排技术：Docker Swarm不够用了之后（https://blog.thinkmoon.cn/post/48-container-orchestration-swarm-k8s-practice/）
转载或引用必须申明原指尖魔法屋来源及源地址！