琼殿技术论坛»首页 › 后端架构/服务器运行环境 › Kubernetes论坛 › Kubernetes集群的搭建与DevOps实践（上）- 架构设计篇 ...
返回列表 发新帖
查看: 60|回复: 0

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

[复制链接]
印顺荣

5

主题

0

回帖

0

积分

热心网友

金币
0
阅读权限
220
精华
0
威望
0
贡献
0
在线时间
0 小时
注册时间
2011-12-13
发表于 2025-12-6 14:17:00 | 显示全部楼层 |阅读模式

本文将探讨生产级Kubernetes集群的架构设计、技术选型，以及完整的DevOps体系设计

适合读者：架构师、技术负责人、希望深入理解K8s和DevOps设计原理的工程师

目录

  • 一、为什么需要Kubernetes
  • 二、整体架构设计
  • 三、技术选型与对比
  • 四、DevOps体系设计
  • 五、中间件体系设计
  • 六、K8s核心概念精要
  • 七、设计决策分析
  • 八、总结与最佳实践

一、为什么需要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的核心理由：

  1. 声明式API：告诉系统"我要什么"而非"怎么做"，系统自动达成目标状态
  2. 自愈能力：Pod崩溃自动重启，节点故障自动迁移
  3. 生态成熟：几乎任何需求都有现成解决方案
  4. 行业标准：人才储备充足，问题容易解决

二、整体架构设计

2.1 架构拓扑图

graph TB subgraph 外网访问层 Internet[互联网用户] Internet --> Entry[Entry节点<br/>Nginx + Squid] end subgraph 内网管理层 JumpServer[堡垒机<br/>JumpServer] end subgraph DevOps工具层 GitLab[GitLab<br/>代码仓库+CI/CD] Harbor[Harbor<br/>镜像仓库] GitLab --> |构建镜像| Harbor end subgraph 应用层 - K8s集群 Entry --> |负载均衡| K8sMaster[3个Master节点] Harbor --> |拉取镜像| K8sMaster K8sMaster --> K8sNode1[Worker-01] K8sMaster --> K8sNode2[Worker-02] subgraph K8s服务 K8sNode1 --> Gateway[API网关] K8sNode1 --> Services[微服务集群] K8sNode2 --> Websites[前端应用] end end subgraph 中间件层 - Docker部署 Middleware[Middleware节点] subgraph 中间件服务 Middleware --> MySQL[(MySQL)] Middleware --> Redis[(Redis)] Middleware --> RabbitMQ[RabbitMQ] Middleware --> ES[Elasticsearch] Middleware --> Nacos[Nacos] end end subgraph 可观测性层 Prometheus[Prometheus<br/>指标采集] Grafana[Grafana<br/>可视化] Filebeat[Filebeat<br/>日志采集] Kibana[Kibana<br/>日志分析] Services -.-> |metrics| Prometheus Services -.-> |logs| Filebeat Prometheus --> Grafana Filebeat --> ES ES --> Kibana end Gateway --> Services Services --> MySQL Services --> Redis Services --> Nacos JumpServer -.-> |SSH管理| K8sMaster JumpServer -.-> |SSH管理| Middleware

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的理由

  1. 性能卓越：BGP模式无封装开销，性能接近裸金属
  2. NetworkPolicy支持：支持细粒度的网络访问控制
  3. 灵活性：可根据环境选择BGP或VXLAN模式
  4. 生产验证：大量企业生产环境使用，文档完善

推荐配置：

# 混合模式：同子网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的理由

  1. 动态配置热更新：配置变更无需重载，零中断
  2. Let's Encrypt自动化：内置ACME客户端，自动申请和续期证书
  3. 可视化Dashboard：实时查看流量和路由配置
  4. 中间件机制：可复用的配置组件（限流、认证等）

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

四、DevOps体系设计

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

4.1 DevOps全景图

graph LR subgraph 开发阶段 Dev[开发者] --> |push| GitLab[GitLab仓库] end subgraph CI阶段 GitLab --> |触发| Pipeline[CI Pipeline] Pipeline --> |构建| Build[Maven/npm构建] Build --> |打包| Docker[Docker镜像] Docker --> |推送| Harbor[Harbor仓库] end subgraph CD阶段 Harbor --> |拉取| K8s[K8s集群] K8s --> |部署| App[应用服务] end subgraph 运维阶段 App --> |指标| Prometheus[Prometheus] App --> |日志| Filebeat[Filebeat] Prometheus --> Grafana[Grafana] Filebeat --> ES[Elasticsearch] ES --> Kibana[Kibana] end

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的理由：

  1. 一站式平台：代码、CI/CD、Issue、Wiki集成在一起
  2. 配置即代码：.gitlab-ci.yml版本化管理
  3. 模板复用：include机制实现配置复用
  4. 可视化Pipeline：直观查看构建状态和日志
  5. 私有部署：完全可控，数据不外泄

流水线设计原则

模板化设计：

项目A/.gitlab-ci.yml
项目B/.gitlab-ci.yml    ----->   公共模板库
项目C/.gitlab-ci.yml              ├── java-template.yml
                                  ├── node-template.yml
                                  └── docker-template.yml

好处：

  • 统一构建规范，减少重复配置
  • 修改模板即可批量更新所有项目
  • 新项目快速接入，只需include模板

智能构建检测：

graph TD A[代码提交] --> B{检测变更类型} B --> |Java文件变更| C[执行Maven构建] B --> |前端文件变更| D[执行npm构建] B --> |配置文件变更| E[仅部署，跳过构建] B --> |文档变更| F[跳过Pipeline]

设计要点：

  • 根据变更文件类型决定执行哪些阶段
  • 避免无意义的全量构建，节省资源和时间
  • 支持手动触发强制全量构建

4.3 镜像管理策略

为什么需要私有镜像仓库

场景 公共仓库(DockerHub) 私有仓库(Harbor)
拉取速度 受网络影响，可能很慢 内网访问，毫秒级
镜像安全 公开可见 私有隔离，权限控制
安全扫描 付费功能 内置Trivy扫描
可用性 依赖外网 内网独立运行
限流 免费版有拉取限制 无限制

镜像仓库选型对比

仓库 功能 复杂度 适用场景
Docker Registry 基础镜像存储 低 简单场景
Harbor 企业级功能（扫描、复制、RBAC） 中 生产环境推荐
Nexus 多类型制品（Maven+Docker+npm） 中 统一制品管理
JFrog Artifactory 全功能企业级 高 大型企业

选择Harbor的理由：

  1. CNCF毕业项目：社区活跃，持续演进
  2. 安全扫描：内置Trivy，自动检测CVE漏洞
  3. 镜像签名：Notary支持，确保镜像完整性
  4. 复制策略：支持多数据中心镜像同步
  5. RBAC权限：项目级别的精细权限控制
  6. 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的理由：

  1. K8s原生集成：ServiceMonitor自动发现
  2. PromQL强大：灵活的查询语言
  3. Grafana生态：丰富的Dashboard模板
  4. Alertmanager：灵活的告警路由
  5. 社区标准：几乎所有云原生组件都暴露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 + 冷热分离 性能和成本平衡

日志收集架构

graph LR subgraph K8s集群 Pod1[Pod] --> |stdout| Filebeat1[Filebeat] Pod2[Pod] --> |stdout| Filebeat1 Pod3[Pod] --> |stdout| Filebeat2[Filebeat] end subgraph 日志平台 Filebeat1 --> ES[Elasticsearch] Filebeat2 --> ES ES --> Kibana[Kibana] end

设计要点：

  1. DaemonSet部署：每个节点一个Filebeat实例
  2. 采集stdout：应用日志输出到标准输出
  3. 结构化日志：JSON格式，便于解析和查询
  4. 索引策略：按日期分索引，便于清理和管理
  5. 保留策略：根据合规要求设置保留天数

五、中间件体系设计

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

5.1 中间件全景图

graph TB subgraph 应用层 Gateway[API网关] Services[微服务集群] end subgraph 中间件层 MySQL[(MySQL<br/>数据存储)] Redis[(Redis<br/>缓存)] ES[(Elasticsearch<br/>搜索/日志)] RabbitMQ[RabbitMQ<br/>消息队列] Nacos[Nacos<br/>配置/注册中心] MinIO[MinIO<br/>对象存储] end Gateway --> Services Services --> MySQL Services --> Redis Services --> ES Services --> RabbitMQ Services --> Nacos Services --> 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单机部署

选择理由：

  1. 项目阶段：初期业务量不大，单机足够承载
  2. 运维简单：Docker Compose一键部署，易于管理
  3. 成本可控：无需额外购买云服务
  4. 灵活性：后续可根据需要平滑升级

5.4 演进路径规划

graph LR A[阶段一<br/>Docker单机] --> B[阶段二<br/>主从/集群] B --> C[阶段三<br/>云托管服务] A --> |业务增长| B B --> |规模扩大| C

阶段一：Docker单机（当前）

  • 部署方式：Docker Compose
  • 高可用：定时备份 + 快速恢复
  • 适用场景：日活<1万、数据量<100GB

阶段二：主从/集群

  • MySQL：主从复制 / MGR集群
  • Redis：哨兵模式 / Cluster集群
  • ES：多节点集群
  • 适用场景：日活1-10万、数据量100GB-1TB

阶段三：云厂商托管

  • 云RDS：MySQL托管服务
  • 云Redis：Redis托管服务
  • 云ES：Elasticsearch托管服务
  • 适用场景：日活>10万、追求高可用和免运维

演进原则：

  1. 按需升级：业务增长驱动，不过度设计
  2. 平滑迁移：选型时考虑兼容性，降低迁移成本
  3. 数据安全：每次迁移前做好备份和回滚方案

六、K8s核心概念精要

6.1 核心资源关系图

graph TB subgraph 用户访问 User[用户] --> Ingress[Ingress<br/>7层路由] end subgraph K8s集群 Ingress --> Service[Service<br/>服务发现+负载均衡] Service --> Pod1[Pod-1] Service --> Pod2[Pod-2] Service --> Pod3[Pod-3] Deployment[Deployment<br/>声明式管理] --> |管理| Pod1 Deployment --> |管理| Pod2 Deployment --> |管理| Pod3 ConfigMap[ConfigMap<br/>配置管理] -.-> Pod1 Secret[Secret<br/>敏感信息] -.-> Pod1 end

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 污点和容忍 专用节点、节点维护

七、总结与最佳实践

7.1 架构设计核心原则

基础设施层：

  1. 高可用优先：Master至少3节点（可容忍1个节点故障），应用至少2副本
  2. 网络隔离：分层子网，最小化暴露面
  3. 预留扩展空间：资源规划留有余量

中间件层：
4. 简单优先：初期Docker单机，按需演进
5. 兼容性考量：选型时考虑后续迁移成本
6. 数据安全：定时备份，快速恢复能力

DevOps层：
7. 自动化优先：能自动化的绝不手工操作
8. 配置即代码：CI/CD配置、K8s YAML全部版本化
9. 模板复用：通过模板统一规范，减少重复

运维层：
10. 监控先行：先部署监控，再部署应用
11. 可观测性：指标、日志、追踪三位一体
12. 故障预案：提前准备回滚方案

7.2 技术选型检查清单

层级 组件 推荐选型 选型依据
容器 运行时 containerd 原生CRI、性能好、轻量
网络 CNI插件 Calico 性能高、NetworkPolicy支持
网络 Ingress Traefik 热更新、Let's Encrypt、Dashboard
中间件 数据库 MySQL 8.x 生态成熟、团队熟悉
中间件 缓存 Redis 7.x 数据结构丰富、持久化
中间件 消息队列 RabbitMQ 功能完整、运维简单
中间件 配置中心 Nacos 配置+服务发现一体化
DevOps CI/CD GitLab CI 与GitLab集成、模板化、可视化
DevOps 镜像仓库 Harbor 企业级、安全扫描、RBAC
监控 指标 Prometheus + Grafana 云原生标准、生态丰富
监控 日志 ELK / Loki 根据规模选择

7.3 系列文章

本文介绍了K8s集群的架构设计、技术选型、DevOps体系设计以及中间件体系设计。

下一篇《部署实践篇》将详细介绍具体实施步骤：

  • 环境准备：网络规划、基础设施初始化、系统优化
  • 中间件部署：Docker Compose部署MySQL、Redis等
  • 集群搭建：kubeadm初始化、Calico网络、Traefik Ingress
  • CI/CD搭建：Harbor配置、GitLab CI模板设计
  • 监控部署：Prometheus + Grafana、告警规则配置
  • 故障排查：常见问题速查表

附篇《故障排查实战》通过真实案例介绍：

  • 典型案例：跨节点Pod通信504问题的完整排查过程
  • 排查方法论：分层诊断法、工具选择
  • 安全组配置：云环境K8s集群安全组配置清单

关键词: Kubernetes、架构设计、技术选型、DevOps、云原生



来源：https://www.cnblogs.com/gOODiDEA/p/19315714
回复

使用道具 举报

返回列表 发新帖
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|琼殿技术论坛 |nimba_sitemap:appname

相关侵权、举报、投诉及建议等，请发 E-mail：qiongdian@foxmail.com

Powered by Discuz! X5.0 © 2001-2026 Discuz! Team.

在本版发帖返回顶部