返回模板页

Kubernetes 架构图示例

以下示例展示了不同团队如何用 K8s 架构图记录集群拓扑、支持事故响应和新人培训，帮助你理解各组件的组织方式，并将模板套用到自己的集群中。

编辑此 Kubernetes 架构图模板返回模板页
Kubernetes 架构图示例

真实案例

三层 Web 应用

使用场景: 记录标准有状态 Web 应用部署的后端工程师

Ingress：nginx ingress controller，负责 TLS 终止
frontend-svc → 2 个前端 Pod（React / SSR）
backend-svc → 2 个后端 Pod（REST API）
db-svc → 1 个 PostgreSQL Pod + PVC
ConfigMap：环境变量；Secret：数据库凭证
后端 Deployment 绑定 HPA，目标 CPU 70%

这样组织的原因: 将工作负载分配到三个专用 Worker 节点，一眼就能看出节点故障的影响范围——Node 3 宕机只影响数据库，无状态的前端和后端不受波及。

带服务网格的微服务平台

使用场景: 在 Istio 下运行 10+ 个服务的平台工程师

Istio Ingress Gateway 作为统一入口
Namespace: auth → auth-service + redis-cache
Namespace: catalog → catalog-service + search-service
Namespace: orders → order-service + payment-service
每个 Pod 注入 Istio Sidecar 代理
monitoring namespace 中的 Prometheus + Grafana

这样组织的原因: 在图中用 Namespace 作为分组容器，直接映射到 Kubernetes RBAC 和网络策略边界，读者能立即看出哪个团队负责哪些服务、流量在哪里被允许通过。

在校生的 Kubernetes 学习集群

使用场景: 搭建本地或云端学习环境的计算机专业学生

单个 Worker 节点（minikube 或 kind）
nginx-pod 通过 NodePort Service 暴露
mysql-pod 挂载 hostPath 卷（学习用存储）
Deployment 和 ReplicaSet 关系标注
kubectl port-forward 本地访问

这样组织的原因: 即使是最简单的单节点集群也值得画一张图——它迫使学习者在动手操作之前就理清 Deployment、ReplicaSet 和 Pod 之间的关系，避免"为什么删了 Pod 它又回来了"这类困惑。

画好 Kubernetes 架构图的技巧

  • 使用 Pod 六边形图形，让熟悉 K8s 的读者一眼认出语义，快速定位。
  • 用 Frame 容器表示 Namespace，帮助读者理解 RBAC 和网络策略的生效范围。
  • 流量方向从上到下绘制（Ingress → Service → Pod），符合流量"下沉"的心智模型。
  • 只在真正写入持久数据的 Pod 上连接 PVC，避免过度标注导致图表噪音。

和相似工具的对比

架构图 vs `kubectl get all` 输出

kubectl 给你的是当前真实状态的列表，但读不出拓扑：谁调用谁、流量从哪进来、哪个 Service 指向哪组 Pod 全靠脑补。架构图牺牲实时性换来关系的可读性，所以两者是互补的——排障看 kubectl，讲解和评审看图。

架构图 vs Helm chart / YAML

YAML 是给集群看的，图是给人看的。同一份 Deployment，YAML 要翻三个文件才能确认它挂了哪个 PVC，图上一眼就能看到。新人 onboarding、故障复盘、跨团队评审这三个场景，图的效率明显高于直接读 chart。

Kubernetes 架构图 vs 通用微服务架构图

通用微服务图画的是服务之间的调用关系，不关心跑在哪。Kubernetes 图必须额外表达 K8s 特有的层级：Namespace 边界、Service 到 Pod 的选择器关系、副本数、以及存储是不是持久的。如果你的图去掉这些还成立，那它其实是微服务图，不是 K8s 图。

手绘风格 vs 官方图标规范图

正式交付文档适合用官方图标保持规范；但在白板上讨论、边讲边改的场景，手绘风格反而更好——它天然传达「这版还能改」，同事更愿意直接在图上提意见，而不是把它当成已定稿的架构。

常见误区

  • 把 Service 和 Pod 画成一对一

    这是最常见的错误。Service 通过 label selector 指向**一组** Pod，副本数会变。画成一对一会让读者误以为扩容需要改 Service，掩盖了 K8s 最核心的解耦设计。正确做法：一个 Service 用一条线连到一个 Pod 分组框，并把副本数标在框上。

  • 漏掉 Namespace 边界

    只画 Pod 和 Service、不画 Namespace，图看起来更干净，但丢掉了最关键的隔离信息——RBAC 权限和 NetworkPolicy 都以 Namespace 为单位生效。读者无法判断跨服务调用是否需要额外放行规则。

  • 给每个 Pod 都挂存储

    无状态 Pod 不需要 PVC。给所有 Pod 都画上存储图标，会让读者判断不出真正需要备份和迁移关注的是哪几个组件——而这恰恰是灾备方案里最需要先确认的信息。

  • 把控制平面和业务负载混在一层

    API Server、etcd、Scheduler 属于控制平面，业务 Pod 属于数据平面。混画在同一层会让人以为业务流量会经过 API Server，而实际上业务请求走的是 Ingress → Service → Pod，完全不碰控制平面。托管集群（EKS/GKE/ACK）里控制平面通常直接省略或单独放一个灰色区域即可。

常见问题

Kubernetes 架构图应该画到多细？+

按读者定位。给新人 onboarding：画到 Service 和 Pod 分组即可，标出流量入口和数据落盘位置。给 SRE 做故障预案：需要加上副本数、HPA 阈值、PVC 和跨可用区分布。给管理层汇报：只保留 Namespace 级别的分块。同一个集群画三张不同粒度的图，比画一张什么都有的大图更有用。

需要把 ConfigMap 和 Secret 画进去吗？+

视目的而定。讲流量拓扑时它们是噪音，建议省略；但如果这张图要用来做配置审计或排查「为什么两个环境行为不一致」，那就该画出来，并且明确标出哪些 Pod 挂载了哪个 ConfigMap。不要为了「完整」而默认全画上。

多集群或多可用区怎么画？+

用最外层 Frame 表示集群或可用区边界，每个集群内部只保留有差异的部分，相同的结构写一句「同上」而不是复制一遍。跨集群的流量（如全局负载均衡、集群间同步）用穿过边界的连线单独标注，这类连线通常是延迟和故障域分析的重点，值得用不同颜色区分。

托管集群（EKS/GKE/ACK）要画控制平面吗？+

一般不用。托管集群的控制平面由云厂商负责，你既不能改也不用运维，画出来只会占空间。除非这张图的目的正是解释托管责任边界——谁负责哪一层——这时把控制平面画成一个灰色区域并注明「云厂商托管」反而是重点。

架构图怎么跟集群实际状态保持同步？+

不要指望手工图长期精确同步，那是注定失败的。可行做法是：图只表达**意图和拓扑**（这类结构短期内不常变），实时状态交给 kubectl 和监控面板。在图上标一个「最后更新日期」，并约定在架构变更评审时同步更新，比追求自动生成更现实。

在线开始编辑

回到模板页，替换成你自己的内容，就可以继续使用这套结构。

使用这个模板： /editor/new?template=kubernetes-architecture

编辑此 Kubernetes 架构图模板