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

小北方城市网2026-01-09 9:46

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

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

  1. 【课前衔接】云原生架构的最后一公里：为什么需要 K8s 全栈编排？
  2. 【模块一】K8s 核心资源进阶：企业级编排实战
  3. 【模块二】企业级 CI/CD 流水线搭建：GitLab CI + ArgoCD
  4. 【模块三】K8s 持久化存储方案：PV/PVC/StorageClass 实战
  5. 【模块四】高可用架构设计：从 K8s 集群到微服务全链路高可用
  6. 【模块五】综合实战：电商微服务云原生终极落地
  7. 【模块六】K8s 性能优化与常见问题排查（企业级经验）
  8. 【课后思考与作业】云原生落地实操
  9. 【本课小结】核心知识点复盘与课程终章预告

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

第 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 主从集群部署
  1. 配置 StatefulSet 资源

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
  1. 配置 Headless Service

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

2.2 守护进程编排：DaemonSet 实战

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

2.2.1 应用场景：日志收集服务（Fluentd）部署
  1. 配置 DaemonSet 资源

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
  1. 核心特性验证
  • 每个节点运行一个副本：所有 K8s 节点（包括主节点）都运行一个 Fluentd Pod；
  • 节点新增时自动部署：新增节点后，DaemonSet 自动在该节点上部署 Fluentd Pod；
  • 节点删除时自动删除：节点删除后，DaemonSet 自动删除该节点上的 Fluentd Pod。

2.3 高级路由：Ingress-NGINX 实战

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

2.3.1 应用场景：电商微服务外部入口路由
  1. 部署 Ingress-NGINX 控制器

bash

运行

复制代码 
# 部署Ingress-NGINX控制器
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.0/deploy/static/provider/cloud/deploy.yaml
  1. 配置 Ingress 资源

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
  1. 核心功能验证
  • 域名路由：通过www.ecommerce.com访问电商微服务；
  • 路径路由：/api/order/**路由至订单服务，/api/goods/**路由至商品服务；
  • 负载均衡：Ingress-NGINX 控制器自动实现负载均衡，将请求分发至服务的多个 Pod。

2.4 配置管理：ConfigMap 与 Secret 实战

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

2.4.1 ConfigMap 应用场景：应用配置管理
  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
  1. 在 Deployment 中引用 ConfigMap

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 应用场景：敏感配置管理
  1. 创建 Secret 资源

yaml

复制代码 
# mysql-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
  namespace: ecommerce
type: Opaque
data:
  root-password: MTIzNDU2 # 123456的Base64编码
  1. 在 StatefulSet 中引用 Secret

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 前置条件

  1. 已搭建 GitLab 服务器，电商微服务代码已托管至 GitLab；
  2. 已搭建 ArgoCD 服务器，能正常访问 K8s 集群；
  3. 电商微服务已编写 Dockerfile，能构建为 Docker 镜像；
  4. 已搭建私有镜像仓库（如 Harbor），用于存储 Docker 镜像。

3.2 GitLab CI 持续集成配置

  1. 在项目根目录创建.gitlab-ci.yml 文件

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
  1. 核心流程验证
  • 代码提交至 GitLab master 分支后，GitLab CI 自动触发流水线；
  • 流水线依次执行构建、测试、推送镜像阶段；
  • 镜像推送至私有仓库后，标签为提交的 SHA 值和 latest。

3.3 ArgoCD 持续部署配置

  1. 创建 ArgoCD Application 资源

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配置不一致的资源
  1. 核心流程验证
  • GitLab CI 推送镜像后，更新 K8s 资源配置文件中的镜像标签；
  • ArgoCD 自动检测到 GitLab 仓库的配置变更，触发同步流程；
  • ArgoCD 自动将应用部署至 K8s 集群，实现持续部署。

3.4 CI/CD 流水线核心优势

  1. 自动化流程：代码提交后自动触发构建、测试、部署流程，无需手动干预；
  2. 快速迭代：缩短从代码提交到部署的时间，实现快速迭代；
  3. 一致性部署：确保所有环境（开发、测试、生产）的部署配置一致，避免环境差异导致的问题；
  4. 可追溯性：每个部署都有对应的提交记录和流水线日志，便于问题排查。

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

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

4.1 核心资源概念解析

  1. PersistentVolume（PV）：持久化存储卷，由管理员创建，代表集群中的一块存储资源（如本地存储、NFS、云存储）；
  2. PersistentVolumeClaim（PVC）：持久化存储卷声明，由用户创建，用于请求 PV 资源；
  3. StorageClass：存储类，用于动态创建 PV，用户无需手动创建 PV，只需创建 PVC 并指定 StorageClass，K8s 自动创建对应的 PV。

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

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

4.2.1 应用场景：NFS 存储卷
  1. 创建 PV 资源

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服务器地址
  1. 创建 PVC 资源

yaml

复制代码 
# nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
  namespace: ecommerce
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  1. 在 Deployment 中引用 PVC

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 为例）
  1. 创建 StorageClass 资源

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自动删除
  1. 创建 PVC 资源

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
  1. 核心特性验证
  • 创建 PVC 后，K8s 自动创建对应的 PV；
  • PV 与 OSS Bucket 关联，数据持久化存储在 OSS 中；
  • 删除 PVC 后，PV 自动删除，OSS Bucket 中的数据根据 reclaimPolicy 决定是否删除。

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

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

  1. 无状态服务（前端、后端 API 服务）：无需持久化存储，使用 EmptyDir 或临时存储；
  2. 有状态服务（MySQL、Redis）：使用 StatefulSet + PV/PVC + StorageClass，实现数据持久化存储；
  3. 日志服务（Fluentd、ELK）：使用 DaemonSet + NFS 存储卷，实现日志的集中存储；
  4. 静态资源服务（商品图片、用户头像）：使用云存储卷（如阿里云 OSS、腾讯云 COS），实现静态资源的持久化存储。

✅ 五、模块四：高可用架构设计：从 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 核心落地步骤

  1. 第一步：K8s 集群搭建
    • 搭建 3 个 master 节点和 3 个 node 节点的 K8s 集群，实现控制平面和数据平面的高可用；
    • 部署网络插件（如 Calico）、Ingress-NGINX 控制器、CSI 驱动等核心组件。
  2. 第二步：微服务部署
    • 使用 Deployment 部署无状态服务（前端、后端 API 服务），使用 StatefulSet 部署有状态服务（MySQL、Redis）；
    • 使用 ConfigMap 和 Secret 管理配置数据，使用 PV/PVC/StorageClass 实现持久化存储。
  3. 第三步：CI/CD 流水线搭建
    • 搭建 GitLab CI 持续集成流水线，实现代码提交→自动构建→自动测试→自动推送镜像；
    • 搭建 ArgoCD 持续部署流水线，实现自动将应用部署至 K8s 集群。
  4. 第四步：服务网格集成
    • 部署 Istio 服务网格，实现服务间通信的流量治理、安全治理、可观测性；
    • 配置 Istio 的核心资源（VirtualService、DestinationRule、PeerAuthentication、AuthorizationPolicy）。
  5. 第五步：高可用架构配置
    • 配置 K8s 集群的高可用（多 master 节点、多 node 节点、负载均衡器）；
    • 配置微服务的高可用（多副本部署、弹性扩缩容、熔断降级、故障隔离）；
    • 配置数据库的高可用（主从复制、读写分离、自动故障切换）；
    • 配置网络的高可用（Ingress 高可用、服务网格高可用）。
  6. 第六步：压测与优化
    • 压测工具：JMeter，压测电商微服务的核心接口（订单创建、商品查询、用户登录）；
    • 压测结果：系统支持 12 万 QPS，响应时间平均 80ms，可用性 99.99%，满足目标需求；
    • 优化点：调整 K8s 集群的资源限制、优化微服务的代码、调整数据库的配置、优化网络的带宽。

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

7.1 K8s 性能优化核心技巧

  1. 资源限制优化
    • 为 Pod 配置合理的 CPU 和内存限制，避免资源过度占用或资源不足；
    • 使用 requests 和 limits 字段配置 Pod 的资源请求和限制，requests 用于调度，limits 用于限制 Pod 的资源使用。
  2. 节点优化
    • 选择高性能的节点（多核 CPU、大内存、高速存储），提高 K8s 集群的性能；
    • 配置节点的亲和性和反亲和性，确保服务的 Pod 部署在合适的节点上。
  3. 网络优化
    • 选择高性能的网络插件（如 Calico、Cilium），提高 K8s 集群的网络性能；
    • 启用网络插件的 TCP 复用、压缩等功能，减少网络传输的数据量。
  4. 存储优化
    • 选择高性能的存储介质（如 SSD、NVMe），提高 K8s 集群的存储性能；
    • 配置存储的缓存、预读等功能，提高存储的访问速度。
  5. 调度优化
    • 配置 Pod 的调度策略（如节点亲和性、Pod 亲和性、Pod 反亲和性），提高 Pod 的调度效率；
    • 使用 kube-scheduler 的高级调度功能（如优先级调度、抢占调度），确保核心服务的 Pod 优先调度。

7.2 常见问题与排查方案

常见问题 排查方案
Pod 启动失败 1. 查看 Pod 的事件日志（kubectl describe pod <pod-name>）；2. 查看 Pod 的容器日志（kubectl logs <pod-name>）；3. 检查 Pod 的资源限制是否足够；4. 检查 Pod 的配置是否正确
服务访问不通 1. 检查 Service 的配置是否正确（kubectl describe service <service-name>）；2. 检查 Pod 的标签是否与 Service 的选择器匹配；3. 检查网络插件是否正常运行；4. 检查防火墙规则是否允许流量通过
持久化存储故障 1. 查看 PV 和 PVC 的状态（kubectl get pv/pvc）；2. 检查存储类的配置是否正确；3. 检查存储介质是否正常（如 NFS 服务器是否运行、云存储是否可用）；4. 查看 Pod 的挂载日志（kubectl logs <pod-name>）
CI/CD 流水线失败 1. 查看 GitLab CI 流水线的日志（GitLab UI）；2. 检查 Dockerfile 是否正确；3. 检查私有镜像仓库是否可用；4. 检查 ArgoCD Application 的配置是否正确
高可用架构故障 1. 查看 K8s 集群的状态（kubectl get nodes）；2. 检查数据库的主从状态（如 MySQL 的 show slave status）；3. 检查 Ingress 的健康状态（kubectl describe ingress <ingress-name>）；4. 检查服务网格的状态（istioctl get pods -n istio-system）

✅ 八、课后思考与作业

必做题（核心实操）

  1. 为电商微服务的 Redis 服务配置 StatefulSet + PV/PVC + StorageClass，实现数据持久化存储；
  2. 搭建 GitLab CI + ArgoCD CI/CD 流水线，实现订单服务的持续集成和持续部署；
  3. 配置 K8s 的 HPA 资源，实现订单服务的自动扩缩容，根据 CPU 使用率（超过 50% 时扩容，低于 30% 时缩容）。

选做题（拓展提升）

  1. 设计并实现电商微服务的全链路高可用架构，包括 K8s 集群、微服务、数据库、缓存、网络等层面；
  2. 配置 Istio 的流量镜像功能，将订单服务的流量镜像到测试服务，实现无感知测试；
  3. 对 K8s 集群进行性能优化，将系统的 QPS 提升至 15 万，响应时间降低至 50ms。

📌 本课小结

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

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

🎉 课程终章预告

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

相关推荐
新钛云服17 小时前
Grafana Polystat面板与腾讯云可观测平台的深度融合实践
大数据·云计算·腾讯云·grafana
创作者mateo17 小时前
机器学习基本概念简介（全）
人工智能·机器学习
飞睿科技17 小时前
乐鑫ESP32-S3-BOX-3，面向AIoT与边缘智能的新一代开发套件
人工智能·嵌入式硬件·esp32·智能家居·乐鑫科技
智航GIS17 小时前
10.1 网站防爬与伪装策略
python
❀͜͡傀儡师17 小时前
Kubernetes 1.34.3部署PostgresSQL的v18.1
云原生·容器·kubernetes·postgressql
Rabbit_QL17 小时前
【数学基础】机器学习中的抽样：你的数据是样本，不是世界
人工智能·机器学习
攀登的牵牛花17 小时前
前端向架构突围系列 - 框架设计（二）：糟糕的代码有哪些特点?
前端·架构
阿巴～阿巴～17 小时前
NAT技术：互联网连接的隐形桥梁
服务器·网络·网络协议·架构·智能路由器·nat·正反向代理
belldeep17 小时前
python：pyTorch 入门教程
pytorch·python·ai·torch
热门推荐
01GitHub 镜像站点02安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）03Linux下V2Ray安装配置指南04Labelme从安装到标注：零基础完整指南05jdk21下载、安装（Windows、Linux、macOS）06【踩坑笔记】50系显卡适配的 PyTorch 安装07手把手教你通过Gemini3 pro 学生认证，白用一年，手慢无！08Opencode CLI 安装成功,但是启动失败09GitLab 零基础入门指南：从安装到项目管理全流程10Claude Code Plan 模式完全指南：从入门到精通