Logo

菜单

易君召
易君召
发布于 2026-07-24 / 2 阅读
0
0

如何用 Kubernetes 管理微服务架构

一、核心定位：K8s 为什么适配微服务

微服务痛点：多服务部署、扩缩容、故障自愈、灰度发布、服务发现、配置统一、资源隔离；

K8s 核心能力完美匹配：容器编排、自愈、弹性伸缩、服务网关、配置中心、流量治理、资源调度。

整体分层架构（微服务 + K8s）：

  1. 基础设施层：服务器 / 云主机、存储、网络

  2. Kubernetes 底座：Master 控制平面 + Node 工作节点

  3. 微服务运行层：Pod（最小运行单元）

  4. 服务网络层：Service、Ingress、ServiceMesh

  5. 配置 / 存储层：ConfigMap、Secret、PV/PVC

  6. 运维管控层：HPA 自动扩缩容、Deployment、StatefulSet、Job/CronJob

  7. 可观测层：日志、监控、链路追踪

二、第一步：微服务容器化（前置条件）

K8s 只管理容器，所有微服务必须先打包镜像：

  1. 每个微服务独立编写Dockerfile，最小基础镜像（Alpine）减小体积

  2. 构建镜像，推送私有镜像仓库（Harbor）

  3. 规范：镜像版本语义化（v1.0.0），区分环境镜像（dev/test/prod）

示例 Java 微服务 Dockerfile：

dockerfile

FROM openjdk:17-jdk-slim
WORKDIR /app
COPY target/demo-user-service.jar app.jar
# 健康检查，给K8s探测存活/就绪
HEALTHCHECK --interval=10s --timeout=3s --retries=3 \
  CMD curl -f http://127.0.0.1:8080/actuator/health || exit 1
ENTRYPOINT ["java","-jar","app.jar"]

三、K8s 核心资源管理不同类型微服务

微服务分无状态服务、有状态服务、定时任务、一次性任务，对应 K8s 控制器：

1. Deployment：无状态微服务（90% 业务微服务）

用户服务、订单服务、商品服务等无状态业务服务，核心能力：

  • 多副本部署，负载均衡

  • 滚动更新 / 回滚（灰度、蓝绿发布基础）

  • Pod 故障自动重建，自愈

  • 配合 HPA 实现 CPU / 内存自动扩缩容

基础 yaml 示例（user 微服务）：

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
  namespace: biz-prod # 命名空间隔离环境
spec:
  replicas: 3 # 3副本高可用
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: user-service
        image: harbor.local/biz/user-service:v1.0.0
        ports:
        - containerPort: 8080
        # 资源限制，避免服务抢占节点资源
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1000m"
            memory: "1Gi"
        # 存活探针：容器崩溃自动重启
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        # 就绪探针：未就绪不加入Service负载均衡
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

2. StatefulSet：有状态微服务

数据库 MySQL、Redis 集群、消息队列 RocketMQ/Kafka、注册中心 Nacos 等：

  • 固定 Pod 名称、稳定网络标识

  • 有序部署、有序删除，适合集群组件

  • 持久化存储绑定，数据不随 Pod 重建丢失

3. Job / CronJob：任务型微服务

数据同步、报表统计、定时清缓存、异步批处理任务：

  • Job：一次性离线任务，执行完成退出

  • CronJob：定时周期任务，支持 cron 表达式

四、服务通信：解决微服务调用、流量接入

4.1 Service：内部服务发现（微服务间调用核心）

Pod IP 动态变化，Service 提供固定 ClusterIP，实现服务注册发现：

  • ClusterIP：集群内部访问，微服务互相调用（默认）

  • NodePort：节点端口暴露，测试使用

  • LoadBalancer：云厂商负载均衡，公网入口

yaml

apiVersion: v1
kind: Service
metadata:
  name: user-service-svc
  namespace: biz-prod
spec:
  selector:
    app: user-service # 关联Deployment的Pod标签
  ports:
  - port: 80 # Service内部端口
    targetPort: 8080 # 容器端口
  type: ClusterIP

微服务调用规则：服务名.命名空间.svc.cluster.local

例：订单服务调用用户服务：http://user-service-svc.biz-prod.svc.cluster.local:80

4.2 Ingress：统一网关，外部流量接入

Service 无法直接暴露公网，Ingress 作为七层网关，统一管理所有微服务外网入口：

  • 域名路由分发（shturl.cc/7kdLEY → user 服务，shturl.cc/7RKcNqE → order 服务）

  • 统一 SSL 证书、限流、黑白名单

    常用控制器：Nginx Ingress Controller

4.3 Service Mesh（Istio/Linkerd）：精细化流量治理

复杂微服务场景（灰度、蓝绿、熔断、限流、链路追踪、服务认证），补充 K8s 原生能力短板：

  1. 流量分发：按权重灰度发布、基于用户标签路由

  2. 故障容错：超时、重试、熔断、舱壁隔离

  3. 安全：服务间 mTLS 加密、权限访问控制

  4. 观测：分布式链路追踪、流量监控

五、配置与密钥统一管理

微服务海量配置文件、数据库账号密码，禁止硬编码进镜像：

  1. ConfigMap：存放明文配置（yml、properties、环境变量）

  2. Secret：加密存储敏感信息（数据库密码、AK/SK、Token）

使用方式：挂载为容器内文件 / 注入环境变量

yaml

# 配置挂载示例，Deployment中添加
volumes:
- name: config-volume
  configMap:
    name: user-config
- name: secret-volume
  secret:
    secretName: db-secret
containers:
volumeMounts:
- name: config-volume
  mountPath: /app/config
- name: secret-volume
  mountPath: /app/secret
  readOnly: true

六、弹性伸缩：自动应对流量波动

1. HPA（HorizontalPodAutoscaler）水平扩缩容

根据 CPU、内存、自定义 QPS 指标自动增减 Pod 副本数，应对流量峰值 / 低谷：

yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: user-hpa
  namespace: biz-prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: user-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

2. VPA 垂直扩缩容

自动调整 Pod CPU / 内存资源配额，优化资源利用率。

3. Cluster Autoscaler 集群节点伸缩

当节点资源不足，自动新增云服务器节点；低负载自动缩容释放机器。

七、微服务发布策略（K8s 原生 + Istio 增强）

1. K8s Deployment 原生滚动更新（默认）

逐步新建新版本 Pod，销毁旧版本，不中断业务；支持 revision 版本记录，一键回滚。

yaml

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1 # 最多多启动1个Pod
      maxUnavailable: 0 # 更新过程不允许服务不可用

2. 蓝绿发布

两套完整副本（绿：旧版本，蓝：新版本），测试验证通过后，切换 Service 标签瞬间切流量；回滚同样秒级切换。

3. 灰度发布（金丝雀发布）

Istio 流量权重分发，少量流量导入新版本验证，无异常再全量切流。

八、多环境隔离：Namespace 命名空间

同一集群区分开发、测试、预发、生产环境，资源逻辑隔离：

  • dev、test、staging、prod 独立 Namespace

  • 配合 ResourceQuota 资源配额，限制各环境 CPU 内存上限，避免测试抢占生产资源

  • NetworkPolicy 网络策略，禁止开发环境访问生产数据库

九、存储管理：微服务持久化数据

微服务缓存、文件、数据库数据使用 PV/PVC 解耦存储与 Pod：

  • PV：底层存储资源（云盘、NAS、本地磁盘）

  • PVC：存储申请，微服务 yaml 直接挂载 PVC，无需关心底层存储

  • StorageClass：动态创建存储卷，无需手动创建 PV

十、可观测体系：监控、日志、链路追踪

微服务故障排查三大支柱，K8s 标准运维栈：

  1. 监控（Prometheus + Grafana）

    采集 Pod CPU、内存、网络、业务 QPS 指标，配置告警规则（Pod 宕机、CPU 打满、错误率飙升）。

  2. 日志（ELK/EFK）

    FluentBit 采集容器标准输出日志，统一存入 Elasticsearch，Kibana 检索日志，按服务、Pod、请求 ID 过滤。

  3. 链路追踪（Jaeger/Zipkin，配合 Istio）

    记录微服务之间完整调用链，快速定位慢接口、调用异常。

十一、完整落地流程（从 0 到 1 管理微服务）

  1. 微服务改造：应用健康检查、暴露监控端点、配置外置化

  2. 容器化：编写 Dockerfile，打包推送私有镜像仓库

  3. 资源编排：编写 Deployment/Service/Ingress/ConfigMap/Secret yaml

  4. 环境隔离：创建不同 Namespace，配置资源配额、网络策略

  5. 发布部署：kubectl apply 部署服务，使用滚动更新迭代版本

  6. 流量治理：Ingress 管理外网，Istio 实现灰度、熔断、限流

  7. 弹性伸缩：配置 HPA 实现 Pod 自动扩缩容

  8. 可观测：部署 Prometheus、EFK、Jaeger，配置告警

  9. 运维自动化：结合 GitOps（ArgoCD/Flux），代码仓库管理 yaml，自动发布

十二、最佳实践总结

  1. 资源规范：所有容器配置 requests/limits，防止资源争抢

  2. 健康探针：必须配置 liveness/readiness 探针，保障自愈能力

  3. 配置分离：禁止镜像硬编码配置、密码，统一使用 ConfigMap/Secret

  4. 环境隔离：命名空间区分环境，生产环境严格权限管控

  5. 灰度发布：生产优先使用 Istio 金丝雀发布，降低发布风险

  6. 自动化运维：采用 GitOps，yaml 纳入代码管理，减少手动 kubectl 操作

  7. 服务网格：复杂多微服务场景引入 Istio，补齐流量治理短板

  8. 监控告警：全链路监控，关键指标配置告警，提前发现故障

主流 Linux 发行版特色、定位...

评论