Kubernetes集群的搭建与DevOps实践（上）- 架构设计篇

一、为什么需要Kubernetes

1.1 传统部署的痛点

在引入容器编排之前，典型的应用部署方式存在以下问题：

 

问题类型 具体表现 业务影响

部署效率低 手工SSH登录、停止服务、上传文件、启动服务 每次部署30分钟+，容易出错

单点故障 服务器宕机导致业务完全中断 服务可用性低于95%

扩容困难 增加服务器需要手工配置环境、部署应用 扩容耗时2小时+，错过业务高峰

资源利用率低 按峰值配置资源，平时大量闲置 CPU平均使用率仅15-25%

配置管理混乱 配置文件散落在各服务器，无版本管理 环境不一致导致故障

无法回滚 出问题只能再走一遍部署流程 故障恢复时间15-20分钟

1.2 Kubernetes能解决什么问题

痛点 K8s解决方案 实际效果

部署效率低 声明式Deployment + 滚动更新 部署时间：30分钟 -> 5分钟

单点故障 Pod副本 + 健康检查 + 自动重启 可用性：95% -> 99.5%

扩容困难 水平扩缩容(HPA) 扩容时间：2小时 -> 2分钟

资源利用率低 智能调度 + 资源配额 CPU利用率：25% -> 60%

配置管理混乱 ConfigMap + Secret 集中管理，版本可追溯

无法回滚 滚动更新 + 版本历史 一键回滚，30秒完成

1.3 技术方案对比

方案 优势 劣势 适用场景

Docker Compose 简单易用、学习成本低 不支持集群、无法水平扩展 开发环境、单机小应用

Docker Swarm 轻量级、易上手、与Docker无缝集成 生态不如K8s、功能有限 中小型项目、快速原型

Kubernetes 功能强大、生态丰富、行业标准 学习曲线陡峭、运维复杂 中大型生产环境

云原生PaaS 开箱即用、免运维 成本高、厂商绑定 预算充足的企业

选择Kubernetes的核心理由：

 

声明式API：告诉系统"我要什么"而非"怎么做"，系统自动达成目标状态

自愈能力：Pod崩溃自动重启，节点故障自动迁移

生态成熟：几乎任何需求都有现成解决方案

行业标准：人才储备充足，问题容易解决

二、整体架构设计

2.1 架构拓扑图

可观测性层

 

中间件层 - Docker部署

 

应用层 - K8s集群

 

DevOps工具层

 

内网管理层

 

外网访问层

 

中间件服务

 

K8s服务

 

构建镜像

 

负载均衡

 

拉取镜像

 

metrics

 

logs

 

SSH管理

 

SSH管理

 

互联网用户

 

Entry节点

Nginx + Squid

 

堡垒机

JumpServer

 

GitLab

代码仓库+CI/CD

 

Harbor

镜像仓库

 

3个Master节点

 

Worker-01

 

Worker-02

 

API网关

 

微服务集群

 

前端应用

 

Middleware节点

 

MySQL

 

Redis

 

RabbitMQ

 

Elasticsearch

 

Nacos

 

Prometheus

指标采集

 

Grafana

可视化

 

Filebeat

日志采集

 

Kibana

日志分析

 

2.2 资源规划

服务器类型 配置建议 数量 用途 说明

Entry节点 2C/4G 1 Nginx负载均衡、外网代理 唯一公网入口

Middleware 8C/32G 1-2 中间件集群 SSD+HDD混合存储

K8s Master 4C/8G 3 控制平面 高可用最低3节点

K8s Worker 8C/32G 2+ 应用服务 按业务需求扩展

JumpServer 4C/8G 1 堡垒机 安全审计

总计：8台云主机，满足中小规模微服务系统的生产需求。

 

2.3 网络规划

采用三层子网架构，实现网络隔离：

 

VPC网络: 10.0.0.0/16

├── entry子网: 10.0.10.0/24 (Entry、JumpServer)

├── middleware子网: 10.0.20.0/24 (中间件节点)

└── k8s子网: 10.0.30.0/24 (K8s集群)

 

K8s内部网络:

├── Pod网段: 172.16.0.0/16 (Calico管理)

└── Service网段: 10.96.0.0/12 (kube-proxy管理)

网络互访规则：

 

源 目标 说明

Entry Middleware、K8s Nginx转发、代理访问

K8s Entry、Middleware 访问中间件、外网代理

Middleware Entry 外网代理访问

JumpServer All 运维管理通道

安全组配置原则：

 

# 公网入站(仅Entry节点)

- SSH端口(非22)、80(HTTP)、443(HTTPS)

 

# 内网互访

- entry子网: 允许与middleware、k8s双向通信

- middleware子网: 允许与entry、k8s通信

- k8s子网: 允许内部互访 + 访问middleware

2.4 架构权衡分析

设计决策 优点 风险 缓解措施

3 Master节点 满足高可用要求 - etcd自动选举

2 Worker节点 成本可控 资源紧张时扩容 预留扩容空间

中间件单节点 简化运维、降低成本 单点故障 定时备份、主从可选

三层子网隔离 安全性高 配置复杂 脚本自动化

三、技术选型与对比

技术选型不是"选最好的"，而是"选最合适的"，以下是三个核心组件的选型分析。

 

3.1 容器运行时：为什么选择containerd

背景：Kubernetes弃用Docker

从Kubernetes 1.24开始，正式移除了对Docker的内置支持（dockershim）。这并不意味着Docker镜像不能用了，而是需要选择原生支持CRI接口的容器运行时。

 

三大容器运行时对比

对比项 Docker containerd CRI-O

定位 完整的容器平台 容器运行时 专为K8s设计的运行时

与K8s集成 间接（需dockershim） 原生CRI支持 原生CRI支持

性能 中等 高 高

资源占用 高（200+ MB） 中（50MB左右） 低（30MB左右）

调试工具 docker cli crictl, ctr, nerdctl crictl

社区活跃度 高 高 中

适用场景 开发环境 生产K8s集群 OpenShift环境

架构对比

Docker架构（多了一层）：

 

kubelet -> dockershim -> Docker Engine -> containerd -> runc

containerd架构（更直接）：

 

kubelet -> CRI Plugin -> containerd -> runc

性能数据对比

测试项 Docker containerd 提升

Pod启动时间 2.3秒 1.8秒 22%

内存占用(空载) 210MB 48MB 77%

CPU使用率(空载) 1.2% 0.3% 75%

结论：选择containerd，原因是原生CRI支持、性能更好、资源占用更少。

 

3.2 网络插件：为什么选择Calico

主流网络插件对比

插件 网络模式 性能 NetworkPolicy 复杂度 推荐场景

Flannel VXLAN/Host-GW 中 不支持 简单 学习、开发环境

Calico BGP/VXLAN 高 支持 中等 生产环境（首选）

Weave VXLAN 低 支持 简单 小型集群

Cilium eBPF 高 支持 复杂 新一代方案

Calico的两种网络模式

模式 工作原理 性能 适用场景

BGP模式 节点间通过BGP协议交换路由，数据包直接路由，无封装 最高 同一二层网络、自建机房

VXLAN模式 数据包通过VXLAN隧道封装传输 中等 跨子网、云环境

混合模式 同子网BGP，跨子网VXLAN 高 推荐的通用方案

选择Calico的理由

性能卓越：BGP模式无封装开销，性能接近裸金属

NetworkPolicy支持：支持细粒度的网络访问控制

灵活性：可根据环境选择BGP或VXLAN模式

生产验证：大量企业生产环境使用，文档完善

推荐配置：

 

# 混合模式：同子网BGP，跨子网VXLAN

calicoNetwork:

  bgp: Enabled

  ipPools:

  - cidr: 172.16.0.0/16

    encapsulation: VXLANCrossSubnet # 关键配置

    natOutgoing: Enabled

3.3 Ingress Controller：为什么选择Traefik

主流Ingress Controller对比

对比项 Nginx Ingress Traefik Istio Gateway

性能 高 中高 中

配置方式 Annotation Annotation/CRD CRD

动态配置 需重载 热更新 热更新

Let's Encrypt 需插件 内置 需cert-manager

UI Dashboard 无 内置 Kiali

学习曲线 低 中 高

适用场景 追求性能 平衡易用性 服务网格

性能对比数据

压测环境：1000并发，持续10分钟

 

Nginx Ingress: 45000 QPS, P95延迟 12ms

Traefik: 38000 QPS, P95延迟 15ms

Istio Gateway: 32000 QPS, P95延迟 22ms

 

结论：Nginx性能最好，但差距不大

选择Traefik的理由

动态配置热更新：配置变更无需重载，零中断

Let's Encrypt自动化：内置ACME客户端，自动申请和续期证书

可视化Dashboard：实时查看流量和路由配置

中间件机制：可复用的配置组件（限流、认证等）

对于大多数应用，性能已经足够，Traefik的易用性优势值得这个性能差距。

 

四、DevOps体系设计

K8s只是基础设施，要实现真正的持续交付，还需要完整的DevOps工具链。本节介绍CI/CD、镜像管理、监控和日志的架构设计。

 

4.1 DevOps全景图

运维阶段

 

CD阶段

 

CI阶段

 

开发阶段

 

push

 

触发

 

构建

 

打包

 

推送

 

拉取

 

部署

 

指标

 

日志

 

开发者

 

GitLab仓库

 

CI Pipeline

 

Maven/npm构建

 

Docker镜像

 

Harbor仓库

 

K8s集群

 

应用服务

 

Prometheus

 

Filebeat

 

Grafana

 

Elasticsearch

 

Kibana

 

DevOps流程说明：

 

阶段 工具 职责 触发条件

代码管理 GitLab 版本控制、代码审查 开发者提交

持续集成 GitLab CI 编译、测试、构建镜像 Push/MR事件

镜像管理 Harbor 存储、扫描、分发镜像 镜像推送

持续部署 kubectl/Helm 应用发布、滚动更新 手动/自动触发

监控告警 Prometheus + Grafana 指标采集、可视化、告警 持续运行

日志管理 Filebeat + ES + Kibana 日志收集、存储、分析 持续运行

4.2 CI/CD架构设计

为什么需要CI/CD

手工部署的问题：

 

问题 具体表现 后果

效率低 每次部署需要30分钟+ 发布频率受限，无法快速迭代

易出错 漏步骤、配置错误、环境不一致 线上故障频发

不可追溯 谁部署的？什么版本？ 问题定位困难

无法回滚 出问题只能重新部署 故障恢复时间长

CI/CD带来的改变：

 

代码提交 -> 自动构建 -> 自动测试 -> 自动部署 -> 自动监控

   | | | | |

  1分钟 5分钟 3分钟 2分钟 持续

              

总计：从提交到上线 ~11分钟，全程自动化，可追溯

CI/CD工具选型对比

工具 优势 劣势 适用场景

Jenkins 插件丰富、社区成熟 配置复杂、UI老旧、维护成本高 复杂定制需求

GitLab CI 与GitLab深度集成、YAML配置、内置模板 依赖GitLab平台 GitLab用户首选

GitHub Actions 与GitHub集成、市场丰富 私有部署受限 GitHub用户

Tekton K8s原生、灵活 学习曲线陡、生态较新 云原生深度用户

Argo CD GitOps理念、声明式 只负责CD，需配合CI工具 GitOps实践

选择GitLab CI的理由：

 

一站式平台：代码、CI/CD、Issue、Wiki集成在一起

配置即代码：.gitlab-ci.yml版本化管理

模板复用：include机制实现配置复用

可视化Pipeline：直观查看构建状态和日志

私有部署：完全可控，数据不外泄

流水线设计原则

模板化设计：

 

项目A/.gitlab-ci.yml

项目B/.gitlab-ci.yml -----> 公共模板库

项目C/.gitlab-ci.yml ├── java-template.yml

                                  ├── node-template.yml

                                  └── docker-template.yml

好处：

 

统一构建规范，减少重复配置

修改模板即可批量更新所有项目

新项目快速接入，只需include模板

智能构建检测：

 

Java文件变更

 

前端文件变更

 

配置文件变更

 

文档变更

 

代码提交

 

检测变更类型

 

执行Maven构建

 

执行npm构建

 

仅部署，跳过构建

 

跳过Pipeline

 

设计要点：

 

根据变更文件类型决定执行哪些阶段

避免无意义的全量构建，节省资源和时间

支持手动触发强制全量构建

4.3 镜像管理策略

为什么需要私有镜像仓库

场景 公共仓库(DockerHub) 私有仓库(Harbor)

拉取速度 受网络影响，可能很慢 内网访问，毫秒级

镜像安全 公开可见 私有隔离，权限控制

安全扫描 付费功能 内置Trivy扫描

可用性 依赖外网 内网独立运行

限流 免费版有拉取限制 无限制

镜像仓库选型对比

仓库 功能 复杂度 适用场景

Docker Registry 基础镜像存储 低 简单场景

Harbor 企业级功能（扫描、复制、RBAC） 中 生产环境推荐

Nexus 多类型制品（Maven+Docker+npm） 中 统一制品管理

JFrog Artifactory 全功能企业级 高 大型企业

选择Harbor的理由：

 

CNCF毕业项目：社区活跃，持续演进

安全扫描：内置Trivy，自动检测CVE漏洞

镜像签名：Notary支持，确保镜像完整性

复制策略：支持多数据中心镜像同步

RBAC权限：项目级别的精细权限控制

Web UI：友好的管理界面

镜像版本策略

标签类型 示例 用途 是否可变

Git SHA app:a1b2c3d 精确追溯到提交 不可变

语义版本 app:1.2.3 正式发布版本 不可变

分支标签 app:develop 最新开发版 可变

latest app:latest 最新版本 可变，不推荐生产使用

推荐做法：

 

生产环境使用Git SHA或语义版本，确保可追溯

测试环境可使用分支标签

禁止在生产环境使用latest标签

4.4 监控体系设计

可观测性三大支柱

                     可观测性

                        |

        +---------------+---------------+

        | | |

      指标 日志 追踪

    (Metrics) (Logs) (Traces)

        | | |

   Prometheus ELK/Loki Jaeger

   + Grafana /Zipkin

支柱 回答的问题 工具

指标(Metrics) 系统现在怎么样？趋势如何？ Prometheus + Grafana

日志(Logs) 发生了什么？错误详情？ ELK / Loki

追踪(Traces) 请求经过了哪些服务？瓶颈在哪？ Jaeger / Zipkin

本方案聚焦：指标和日志（覆盖90%监控需求）

 

监控方案对比

方案 架构 优势 劣势 适用场景

Prometheus + Grafana 拉取式 云原生标准、生态丰富 长期存储需额外方案 K8s环境首选

Zabbix 推送式 功能全面、历史悠久 配置复杂、不够云原生 传统运维

Datadog/New Relic SaaS 开箱即用、免运维 成本高、数据外泄 预算充足团队

VictoriaMetrics 兼容Prometheus 性能更高、长期存储 社区较小 大规模场景

选择Prometheus + Grafana的理由：

 

K8s原生集成：ServiceMonitor自动发现

PromQL强大：灵活的查询语言

Grafana生态：丰富的Dashboard模板

Alertmanager：灵活的告警路由

社区标准：几乎所有云原生组件都暴露Prometheus指标

监控分层设计

+------------------+------------------------------------------+

| 业务监控 | 订单量、成功率、响应时间、业务异常 |

+------------------+------------------------------------------+

| 应用监控 | JVM指标、HTTP请求、数据库连接池 |

+------------------+------------------------------------------+

| K8s监控 | Pod状态、资源使用、Deployment健康 |

+------------------+------------------------------------------+

| 基础设施监控 | CPU、内存、磁盘、网络、进程 |

+------------------+------------------------------------------+

层级 关键指标 数据来源

基础设施 CPU/内存/磁盘/网络 Node Exporter

K8s层 Pod/Deployment/Service状态 kube-state-metrics

应用层 JVM/HTTP/DB连接 应用内置metrics端点

业务层 订单/支付/用户行为 自定义metrics

4.5 日志体系设计

日志收集方案对比

方案 架构 优势 劣势 适用场景

ELK Stack Filebeat -> ES -> Kibana 功能强大、查询灵活 资源消耗大 中大规模

Loki + Grafana Promtail -> Loki -> Grafana 轻量、与Prometheus集成 不支持全文索引 轻量场景

Fluentd 通用收集器 插件丰富、灵活 配置复杂 复杂路由需求

选型建议：

 

团队规模 日志量 推荐方案 理由

小 <10GB/天 Loki 轻量、与Grafana统一

中 10-100GB/天 ELK 功能全面、查询强大

大 >100GB/天 ELK + 冷热分离 性能和成本平衡

日志收集架构

日志平台

 

K8s集群

 

stdout

 

stdout

 

stdout

 

Pod

 

Filebeat

 

Pod

 

Pod

 

Filebeat

 

Elasticsearch

 

Kibana

 

设计要点：

 

DaemonSet部署：每个节点一个Filebeat实例

采集stdout：应用日志输出到标准输出

结构化日志：JSON格式，便于解析和查询

索引策略：按日期分索引，便于清理和管理

保留策略：根据合规要求设置保留天数

五、中间件体系设计

微服务架构离不开中间件的支撑，具体的选择通常依赖于后端的整体架构，以下是我们的选择。

 

5.1 中间件全景图

中间件层

 

应用层

 

API网关

 

微服务集群

 

MySQL

数据存储

 

Redis

缓存

 

Elasticsearch

搜索/日志

 

RabbitMQ

消息队列

 

Nacos

配置/注册中心

 

MinIO

对象存储

 

中间件职责：

 

中间件 职责 应用场景

MySQL 关系型数据存储 业务数据持久化

Redis 缓存、分布式锁 热点数据缓存、会话管理

Elasticsearch 全文搜索、日志存储 商品搜索、日志分析

RabbitMQ 异步消息、解耦 订单处理、通知推送

Nacos 配置管理、服务发现 动态配置、服务注册

MinIO 对象存储 图片、文件存储

5.2 中间件选型分析

5.2.1 数据库：MySQL

对比项 MySQL PostgreSQL 云RDS

生态成熟度 高 高 高

运维复杂度 中 中 低

成本 低 低 高

团队熟悉度 高 中 高

选择MySQL的理由：

 

团队熟悉，运维经验丰富

生态成熟，工具链完善

后续可平滑迁移到云RDS

5.2.2 缓存：Redis

对比项 Redis Memcached 云Redis

数据结构 丰富（String/Hash/List/Set/ZSet） 简单（Key-Value） 丰富

持久化 支持（RDB/AOF） 不支持 支持

集群模式 支持 需客户端分片 支持

成本 低 低 高

选择Redis的理由：

 

数据结构丰富，适用场景广

支持持久化，数据更安全

原生支持集群模式

5.2.3 消息队列：RabbitMQ

对比项 RabbitMQ Kafka RocketMQ

吞吐量 中（万级） 高（百万级） 高（十万级）

延迟 低（毫秒） 中（毫秒） 低（毫秒）

功能完整性 高 中 高

运维复杂度 低 高 中

选择RabbitMQ的理由：

 

功能完整，支持多种消息模式

管理界面友好，运维简单

延迟低，适合业务消息

5.2.4 配置中心：Nacos

对比项 Nacos Apollo Consul

配置管理 支持 支持 支持

服务发现 支持 不支持 支持

架构复杂度 低 高 中

社区活跃度 高 中 高

选择Nacos的理由：

 

配置管理 + 服务发现一体化

架构简单，部署方便

阿里开源，与Spring Cloud Alibaba深度集成

5.2.5 对象存储：MinIO

对比项 MinIO 云OSS FastDFS

S3兼容 完全兼容 兼容 不兼容

私有部署 支持 不支持 支持

运维复杂度 低 无需运维 高

成本 低 按量付费 低

选择MinIO的理由：

 

S3 API兼容，后续可无缝迁移到云OSS

私有部署，数据可控

轻量级，单节点即可运行

5.3 部署策略选择

部署方式对比

部署方式 优点 缺点 适用阶段

Docker单机 简单、快速、成本低 无高可用、容量有限 MVP/初创期

K8s StatefulSet 统一管理、自动调度 运维复杂、性能损耗 中大规模

主从/集群 高可用、读写分离 运维复杂、成本增加 成长期

云厂商托管 免运维、高可用 成本高、厂商绑定 成熟期

当前选择：Docker单机部署

选择理由：

 

项目阶段：初期业务量不大，单机足够承载

运维简单：Docker Compose一键部署，易于管理

成本可控：无需额外购买云服务

灵活性：后续可根据需要平滑升级

5.4 演进路径规划

业务增长

 

规模扩大

 

阶段一

Docker单机

 

阶段二

主从/集群

 

阶段三

云托管服务

 

阶段一：Docker单机（当前）

部署方式：Docker Compose

高可用：定时备份 + 快速恢复

适用场景：日活<1万、数据量<100GB

阶段二：主从/集群

MySQL：主从复制 / MGR集群

Redis：哨兵模式 / Cluster集群

ES：多节点集群

适用场景：日活1-10万、数据量100GB-1TB

阶段三：云厂商托管

云RDS：MySQL托管服务

云Redis：Redis托管服务

云ES：Elasticsearch托管服务

适用场景：日活>10万、追求高可用和免运维

演进原则：

 

按需升级：业务增长驱动，不过度设计

平滑迁移：选型时考虑兼容性，降低迁移成本

数据安全：每次迁移前做好备份和回滚方案

六、K8s核心概念精要

6.1 核心资源关系图

K8s集群

 

用户访问

 

管理

 

管理

 

管理

 

用户

 

Ingress

7层路由

 

Service

服务发现+负载均衡

 

Pod-1

 

Pod-2

 

Pod-3

 

Deployment

声明式管理

 

ConfigMap

配置管理

 

Secret

敏感信息

 

6.2 核心资源说明

资源 作用 类比

Pod 最小部署单元，包含一个或多个容器 一个应用实例

Deployment 声明式管理Pod，支持滚动更新和回滚 应用版本管理器

Service 为Pod提供稳定的访问入口和负载均衡 内部DNS+负载均衡器

Ingress 7层HTTP路由，暴露服务给外部访问 反向代理

ConfigMap 存储非敏感配置 配置文件

Secret 存储敏感信息（密码、证书） 加密的配置文件

6.3 Service的四种类型

类型 说明 使用场景

ClusterIP 集群内部访问（默认） 微服务间调用

NodePort 通过节点IP+端口访问 开发测试、简单场景

LoadBalancer 云厂商负载均衡器 公有云环境

ExternalName 返回外部服务的CNAME 访问外部服务

6.4 kube-proxy工作模式

kube-proxy负责实现Service的网络转发规则：

 

模式 实现方式 性能 推荐场景

iptables iptables规则 中 中小集群（默认）

ipvs IPVS负载均衡 高 大规模集群（推荐）

ipvs模式优势：

 

规则查找O(1)复杂度，性能更稳定

支持多种负载均衡算法（rr、wrr、lc等）

支持会话保持

6.5 Pod调度机制

调度器决定Pod运行在哪个节点：

 

Pod创建请求

    ↓

过滤阶段（排除不满足条件的节点）

- 资源不足

- 节点污点

- 亲和性规则不满足

    ↓

打分阶段（对候选节点评分）

- 资源均衡度

- 镜像本地性

- 亲和性权重

    ↓

选择得分最高的节点

常用调度策略：

 

策略 配置方式 场景

NodeSelector 标签选择器 简单的节点选择

NodeAffinity 亲和性规则 复杂的节点选择

PodAffinity Pod亲和性 Pod靠近部署

PodAntiAffinity Pod反亲和性 Pod分散部署

Taints/Tolerations 污点和容忍 专用节点、节点维护