第 6 课：云原生架构终极落地｜K8s 全栈编排与高可用架构设计实战

✅ 课程衔接：已掌握服务网格（Istio）的全链路治理能力，实现了电商微服务的东西向流量管控。但大规模微服务集群的基础设施层治理仍存在核心痛点：容器编排复杂、部署流程手动化、持久化存储管理困难、高可用架构设计缺失等。本课聚焦Kubernetes（K8s）全栈编排，作为云原生架构的核心基础设施，实现微服务的自动化部署、弹性扩缩容、持久化存储、高可用架构设计，完成从服务网格到云原生架构的终极落地，打造企业级高可用、高弹性的云原生系统。✅ 核心价值：✅ 掌握 K8s 核心资源进阶配置（StatefulSet、DaemonSet、Ingress）；✅ 搭建企业级 CI/CD 自动化流水线（GitLab CI + ArgoCD）；✅ 实现 K8s 持久化存储方案（PV/PVC/StorageClass）；✅ 设计并落地电商微服务高可用架构（99.99% 可用性）；✅ 具备云原生架构全栈落地与运维能力。✅ 学习目标：✅ 精通 K8s 核心资源的企业级配置与应用场景；✅ 独立搭建 CI/CD 自动化流水线，实现代码提交到部署的全自动化；✅ 掌握 K8s 持久化存储方案，解决有状态服务的存储问题；✅ 设计并落地电商微服务的高可用架构；✅ 掌握 K8s 性能优化与常见问题排查技巧。

📚 课程目录（实战导向｜聚焦云原生终极落地）

✅ 一、课前衔接：云原生架构的最后一公里

第 5 课我们实现了电商微服务的 Istio 服务网格治理，解决了服务间通信的东西向流量管控问题，但随着微服务规模扩大到数十个，基础设施层的治理成为云原生架构落地的最后一公里瓶颈：

• 容器编排复杂：手动管理 Docker 容器的部署、扩缩容、升级，效率低下且易出错；
• 部署流程手动化：代码提交后需手动构建镜像、部署至 K8s，无法实现快速迭代；
• 持久化存储管理困难：有状态服务（如 MySQL、Redis）的存储需求无法通过 Docker 容器满足，数据持久化与迁移困难；
• 高可用架构设计缺失：K8s 集群单节点故障、微服务单副本部署、数据库主从切换等问题，导致系统可用性无法达到企业级要求；
• 运维成本高：缺乏自动化的监控、告警、故障恢复机制，运维人员需手动处理大量问题。

而Kubernetes（K8s） 作为云原生架构的核心基础设施，是容器编排的行业标准，核心功能包括容器编排、自动化部署、弹性扩缩容、持久化存储、服务发现与负载均衡等。结合前几课的 Istio 服务网格，K8s 与 Istio 共同构成云原生架构的完整体系：

• K8s：负责基础设施层的容器编排、部署、存储、网络等资源管理；
• Istio：负责应用层的服务间通信治理、流量控制、安全治理、可观测性。

本课的核心目标是通过 K8s 全栈编排，实现电商微服务的云原生终极落地，打造企业级高可用、高弹性的云原生系统。

✅ 二、模块一：K8s 核心资源进阶：企业级编排实战

K8s 的核心资源包括 Pod、Deployment、Service、Ingress 等，基础资源已无法满足企业级微服务的编排需求，本课聚焦进阶资源的企业级配置，解决有状态服务、守护进程、高级路由等核心问题。

2.1 有状态服务编排：StatefulSet 实战

Deployment 适用于无状态服务（如前端、后端 API 服务），而StatefulSet适用于有状态服务（如 MySQL、Redis、Kafka），核心特性包括固定的 Pod 名称、固定的存储、有序的部署与扩缩容。

2.1.1 应用场景：MySQL 主从集群部署

yaml

# mysql-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
namespace: ecommerce
spec:
serviceName: mysql # 必须指定Headless Service名称
replicas: 2 # 主从两个节点
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
– name: mysql
image: mysql:5.7
ports:
– containerPort: 3306
env:
– name: MYSQL_ROOT_PASSWORD
value: "123456"
– name: MYSQL_REPLICATION_ROLE
valueFrom:
fieldRef:
fieldPath: metadata.labels['role']
volumeMounts:
– name: mysql-data
mountPath: /var/lib/mysql
volumeClaimTemplates: # 动态创建PVC，每个Pod一个独立的PVC
– metadata:
name: mysql-data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "standard" # 关联StorageClass
resources:
requests:
storage: 10Gi

yaml

# mysql-headless-service.yaml
apiVersion: v1
kind: Service
metadata:
name: mysql
namespace: ecommerce
spec:
clusterIP: None # Headless Service，无集群IP
selector:
app: mysql
ports:
– port: 3306
targetPort: 3306

• 固定 Pod 名称：mysql-0、mysql-1，重启后名称不变；
• 固定存储：每个 Pod 对应一个 PVC，数据持久化存储；
• 有序部署：先部署mysql-0（主节点），再部署mysql-1（从节点）；
• 有序扩缩容：扩缩容时按顺序进行，保证主从集群的稳定性。

2.2 守护进程编排：DaemonSet 实战

DaemonSet适用于需要在每个 K8s 节点上运行一个副本的服务（如日志收集、监控代理、网络插件），核心特性是每个节点仅运行一个副本，节点新增时自动部署，节点删除时自动删除。

2.2.1 应用场景：日志收集服务（Fluentd）部署

yaml

# fluentd-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd
namespace: kube-system
spec:
selector:
matchLabels:
app: fluentd
template:
metadata:
labels:
app: fluentd
spec:
tolerations: # 容忍主节点的污点，允许在主节点上部署
– key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
– name: fluentd
image: fluent/fluentd:v1.14
ports:
– containerPort: 24224
volumeMounts:
– name: varlog
mountPath: /var/log
– name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
volumes:
– name: varlog
hostPath:
path: /var/log
– name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers

• 每个节点运行一个副本：所有 K8s 节点（包括主节点）都运行一个 Fluentd Pod；
• 节点新增时自动部署：新增节点后，DaemonSet 自动在该节点上部署 Fluentd Pod；
• 节点删除时自动删除：节点删除后，DaemonSet 自动删除该节点上的 Fluentd Pod。

2.3 高级路由：Ingress-NGINX 实战

Ingress-NGINX是 K8s 的 Ingress 控制器，负责将外部流量路由至内部服务，核心功能包括HTTP/HTTPS 路由、负载均衡、SSL 终止、路径重写等，是 K8s 集群的外部入口。

2.3.1 应用场景：电商微服务外部入口路由

bash

运行

# 部署Ingress-NGINX控制器
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.0/deploy/static/provider/cloud/deploy.yaml

yaml

# ecommerce-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ecommerce-ingress
namespace: ecommerce
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$1 # 路径重写
nginx.ingress.kubernetes.io/ssl-redirect: "false" # 暂时关闭SSL重定向
spec:
ingressClassName: nginx # 指定Ingress控制器
rules:
– host: www.ecommerce.com # 域名
http:
paths:
– path: /api/order/(.*)
pathType: Prefix
backend:
service:
name: order-service
port:
number: 8080
– path: /api/goods/(.*)
pathType: Prefix
backend:
service:
name: goods-service
port:
number: 8080

• 域名路由：通过www.ecommerce.com访问电商微服务；
• 路径路由：/api/order/**路由至订单服务，/api/goods/**路由至商品服务；
• 负载均衡：Ingress-NGINX 控制器自动实现负载均衡，将请求分发至服务的多个 Pod。

2.4 配置管理：ConfigMap 与 Secret 实战

ConfigMap用于存储非敏感配置数据（如数据库连接字符串、应用配置），Secret用于存储敏感配置数据（如密码、密钥、证书），核心特性是配置与代码分离，动态更新配置。

2.4.1 ConfigMap 应用场景：应用配置管理

yaml

# order-service-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: order-service-config
namespace: ecommerce
data:
application.yml: |
spring:
datasource:
url: jdbc:mysql://mysql:3306/order_db?useSSL=false&serverTimezone=UTC
username: root
password: 123456
redis:
host: redis
port: 6379

yaml

# order-service-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
namespace: ecommerce
spec:
template:
spec:
containers:
– name: order-service
image: order-service:v1.0
volumeMounts:
– name: config-volume
mountPath: /app/config
volumes:
– name: config-volume
configMap:
name: order-service-config # 引用ConfigMap

2.4.2 Secret 应用场景：敏感配置管理

yaml

# mysql-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
namespace: ecommerce
type: Opaque
data:
root-password: MTIzNDU2 # 123456的Base64编码

yaml

# mysql-statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
namespace: ecommerce
spec:
template:
spec:
containers:
– name: mysql
image: mysql:5.7
env:
– name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret # 引用Secret
key: root-password

✅ 三、模块二：企业级 CI/CD 流水线搭建：GitLab CI + ArgoCD

CI/CD（持续集成 / 持续部署）是云原生架构的核心自动化流程，GitLab CI负责持续集成（代码提交→自动构建→自动测试），ArgoCD负责持续部署（自动将应用部署至 K8s 集群），两者结合实现代码提交到部署的全自动化。

3.1 前置条件

3.2 GitLab CI 持续集成配置

yaml

# .gitlab-ci.yml
stages:
– build # 构建阶段
– test # 测试阶段
– push # 推送镜像阶段

# 构建Docker镜像
build:
stage: build
script:
– docker build -t harbor.example.com/ecommerce/order-service:$CI_COMMIT_SHA .
only:
– master

# 运行单元测试
test:
stage: test
script:
– docker run harbor.example.com/ecommerce/order-service:$CI_COMMIT_SHA mvn test
only:
– master

# 推送Docker镜像至私有仓库
push:
stage: push
script:
– docker push harbor.example.com/ecommerce/order-service:$CI_COMMIT_SHA
– docker tag harbor.example.com/ecommerce/order-service:$CI_COMMIT_SHA harbor.example.com/ecommerce/order-service:latest
– docker push harbor.example.com/ecommerce/order-service:latest
only:
– master

• 代码提交至 GitLab master 分支后，GitLab CI 自动触发流水线；
• 流水线依次执行构建、测试、推送镜像阶段；
• 镜像推送至私有仓库后，标签为提交的 SHA 值和 latest。

3.3 ArgoCD 持续部署配置

yaml

# order-service-argocd.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: order-service
namespace: argocd
spec:
project: default
source:
repoURL: https://gitlab.example.com/ecommerce/order-service.git # GitLab仓库地址
targetRevision: master # 分支
path: k8s # K8s资源配置文件所在路径
destination:
server: https://kubernetes.default.svc # K8s集群地址
namespace: ecommerce # 目标命名空间
syncPolicy:
automated:
prune: true # 自动删除不在GitLab中的资源
selfHeal: true # 自动修复与GitLab配置不一致的资源

• GitLab CI 推送镜像后，更新 K8s 资源配置文件中的镜像标签；
• ArgoCD 自动检测到 GitLab 仓库的配置变更，触发同步流程；
• ArgoCD 自动将应用部署至 K8s 集群，实现持续部署。

3.4 CI/CD 流水线核心优势

✅ 四、模块三：K8s 持久化存储方案：PV/PVC/StorageClass 实战

K8s 的持久化存储是解决有状态服务存储问题的核心方案，核心资源包括PersistentVolume（PV）、PersistentVolumeClaim（PVC）、StorageClass，实现存储资源的动态分配、持久化存储、灵活管理。

4.1 核心资源概念解析

4.2 静态存储方案：PV + PVC 实战

静态存储方案适用于存储资源固定的场景，管理员手动创建 PV，用户创建 PVC 请求 PV 资源。

4.2.1 应用场景：NFS 存储卷

yaml

# nfs-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
capacity:
storage: 10Gi
accessModes:
– ReadWriteMany # 多节点读写
persistentVolumeReclaimPolicy: Retain # 保留策略，PVC删除后PV保留
nfs:
path: /nfs/data
server: 192.168.1.100 # NFS服务器地址

yaml

# nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
namespace: ecommerce
spec:
accessModes:
– ReadWriteMany
resources:
requests:
storage: 10Gi

yaml

# app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app
namespace: ecommerce
spec:
template:
spec:
containers:
– name: app
image: app:v1.0
volumeMounts:
– name: nfs-volume
mountPath: /app/data
volumes:
– name: nfs-volume
persistentVolumeClaim:
claimName: nfs-pvc # 引用PVC

4.3 动态存储方案：StorageClass + PVC 实战

动态存储方案适用于存储资源动态分配的场景，管理员创建 StorageClass，用户创建 PVC 并指定 StorageClass，K8s 自动创建对应的 PV。

4.3.1 应用场景：云存储卷（以阿里云 OSS 为例）

yaml

# aliyun-oss-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: aliyun-oss
provisioner: ossplugin.csi.aliyun.com # 阿里云OSS CSI驱动
parameters:
bucket: ecommerce-oss # OSS Bucket名称
region: cn-hangzhou # 地域
accessKeyId: LTAI5t7xxxx # AccessKey ID
accessKeySecret: 8kxxxx # AccessKey Secret
reclaimPolicy: Delete # 删除策略，PVC删除后PV自动删除

yaml

# aliyun-oss-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: aliyun-oss-pvc
namespace: ecommerce
spec:
accessModes:
– ReadWriteMany
resources:
requests:
storage: 10Gi
storageClassName: aliyun-oss # 指定StorageClass

• 创建 PVC 后，K8s 自动创建对应的 PV；
• PV 与 OSS Bucket 关联，数据持久化存储在 OSS 中；
• 删除 PVC 后，PV 自动删除，OSS Bucket 中的数据根据 reclaimPolicy 决定是否删除。

4.4 电商微服务持久化存储方案设计

根据电商微服务的不同服务类型，设计对应的持久化存储方案：

✅ 五、模块四：高可用架构设计：从 K8s 集群到微服务全链路高可用

高可用架构是企业级云原生系统的核心要求，目标是实现99.99% 的可用性（每年停机时间不超过 52.56 分钟）。高可用架构设计需要覆盖K8s 集群、微服务、数据库、缓存、网络等全链路层面。

5.1 K8s 集群高可用设计

K8s 集群的高可用是整个云原生系统高可用的基础，核心设计原则是多节点部署、避免单点故障、自动故障恢复。

5.1.1 控制平面高可用

• 多 master 节点部署：至少 3 个 master 节点，实现 etcd 集群的高可用；
• 负载均衡器：使用云厂商的负载均衡器或自建 HAProxy，实现 API Server 的负载均衡；
• 自动故障恢复：master 节点故障时，etcd 集群自动选举新的 leader，API Server 通过负载均衡器自动切换至可用节点。

5.1.2 数据平面高可用

• 多 node 节点部署：至少 2 个 node 节点，实现 Pod 的分布式部署；
• Pod 反亲和性：配置 Pod 反亲和性，确保同一服务的多个 Pod 部署在不同的 node 节点上；
• 节点亲和性：配置节点亲和性，确保服务的 Pod 部署在指定的 node 节点上（如高性能节点）。

5.2 微服务高可用设计

微服务的高可用是云原生系统高可用的核心，核心设计原则是多副本部署、弹性扩缩容、熔断降级、故障隔离。

5.2.1 多副本部署

• 每个微服务至少部署 2 个副本，确保单个 Pod 故障时，服务仍能正常运行；
• 使用 Deployment 或 StatefulSet 的 replicas 字段配置副本数。

5.2.2 弹性扩缩容

• 使用 HPA（Horizontal Pod Autoscaler）实现 Pod 的自动扩缩容，根据 CPU 使用率、内存使用率、QPS 等指标自动调整副本数；
• 使用 VPA（Vertical Pod Autoscaler）实现 Pod 的垂直扩缩容，根据 Pod 的资源使用情况自动调整 CPU 和内存限制。

5.2.3 熔断降级

• 使用 Istio 的熔断降级功能，实现服务间的熔断降级，避免单个服务故障导致的服务雪崩；
• 使用 Sentinel 的熔断降级功能，实现接口级别的熔断降级，确保核心接口的可用性。

5.2.4 故障隔离

• 使用 K8s 的命名空间实现服务的故障隔离，不同的服务部署在不同的命名空间中；
• 使用 Istio 的服务网格实现服务间的故障隔离，单个服务故障时，不影响其他服务的运行。

5.3 数据库高可用设计

数据库的高可用是云原生系统高可用的关键，核心设计原则是主从复制、读写分离、自动故障切换。

5.3.1 MySQL 高可用设计

• 主从复制：使用 StatefulSet 部署 MySQL 主从集群，主节点负责写操作，从节点负责读操作；
• 读写分离：使用 ProxySQL 实现 MySQL 的读写分离，将读请求分发至从节点，写请求分发至主节点；
• 自动故障切换：使用 MHA（Master High Availability）实现 MySQL 主从集群的自动故障切换，主节点故障时，自动选举新的主节点。

5.3.2 Redis 高可用设计

• 主从复制：使用 StatefulSet 部署 Redis 主从集群，主节点负责写操作，从节点负责读操作；
• 哨兵模式：使用 Redis Sentinel 实现 Redis 主从集群的自动故障切换，主节点故障时，自动选举新的主节点；
• 集群模式：使用 Redis Cluster 实现 Redis 的分片集群，提高 Redis 的性能和可用性。

5.4 网络高可用设计

网络的高可用是云原生系统高可用的保障，核心设计原则是多路径路由、负载均衡、故障自动切换。

5.4.1 Ingress 高可用设计

• 多副本部署：Ingress-NGINX 控制器至少部署 2 个副本，确保单个副本故障时，Ingress 仍能正常运行；
• 云厂商负载均衡器：使用云厂商的负载均衡器实现 Ingress 的负载均衡，将外部流量分发至 Ingress 的多个副本；
• 健康检查：配置 Ingress 的健康检查，确保负载均衡器只将流量分发至健康的 Ingress 副本。

5.4.2 服务网格高可用设计

• 多副本部署：Istio 的控制平面和数据平面至少部署 2 个副本，确保单个副本故障时，服务网格仍能正常运行；
• 自动故障恢复：Istio 的控制平面和数据平面支持自动故障恢复，副本故障时，自动重启或切换至可用副本。

✅ 六、模块五：综合实战：电商微服务云原生终极落地

承接前几课的电商微服务项目，基于本课知识点实现云原生终极落地，打造企业级高可用、高弹性的云原生系统。

6.1 实战目标

• 电商微服务全栈部署至 K8s 集群，实现容器编排、自动化部署、弹性扩缩容；
• 搭建企业级 CI/CD 流水线，实现代码提交到部署的全自动化；
• 实现电商微服务的持久化存储，解决有状态服务的存储问题；
• 设计并落地电商微服务的高可用架构，实现 99.99% 的可用性；
• 性能指标：系统支持 10 万 QPS，响应时间平均 < 100ms，可用性 99.99%。

6.2 核心落地步骤

✅ 七、模块六：K8s 性能优化与常见问题排查（企业级经验）

7.1 K8s 性能优化核心技巧

7.2 常见问题与排查方案

✅ 八、课后思考与作业

必做题（核心实操）

选做题（拓展提升）

📌 本课小结

本课核心落地了云原生架构的终极落地：通过 K8s 全栈编排，实现了电商微服务的容器编排、自动化部署、弹性扩缩容、持久化存储；通过搭建企业级 CI/CD 流水线，实现了代码提交到部署的全自动化；通过设计并落地高可用架构，实现了 99.99% 的可用性。结合前几课的 Istio 服务网格，K8s 与 Istio 共同构成了云原生架构的完整体系，打造了企业级高可用、高弹性的云原生系统。

掌握本课内容后，你将具备云原生架构的全栈落地与运维能力，能够独立完成企业级云原生系统的设计与落地，成为一名资深的云原生架构师。

🎉 课程终章预告

本架构系列课程从架构核心认知出发，依次讲解了分层架构、分布式架构、微服务架构、API 网关、服务网格、云原生架构，形成了完整的架构知识体系。下一章将为架构师综合能力提升，包括架构评审、技术选型、团队管理、架构演进等核心能力，帮助你从一名技术人员成长为一名优秀的架构师。