Kubernetes 应用架构：从对象模型到生产级参考架构

一、K8s 应用架构到底管什么

K8s 应用架构可以理解为业务应用与平台之间的“运行契约”，至少回答以下问题：

1. 应用以什么工作负载运行：Deployment、StatefulSet、Job 还是 CronJob？
2. 服务如何被发现和访问：Service、Ingress 还是 Gateway API？
3. 配置和密钥如何注入：ConfigMap、Secret，还是外部配置中心？
4. 数据如何持久化：本地盘、PVC、对象存储还是外部数据库？
5. 如何发布和回滚：滚动更新、蓝绿还是金丝雀？
6. 如何扩缩容：HPA、KEDA、VPA 还是集群自动扩缩？
7. 如何隔离和授权：Namespace、RBAC、NetworkPolicy、ResourceQuota？
8. 如何观测和告警：Metrics、Logs、Traces、Events 和 SLO？
9. 如何保证供应链安全：镜像扫描、签名、准入控制和最小权限？

因此，K8s 应用架构不是单个 YAML 文件，而是一套围绕应用生命周期的分层设计。

二、核心对象与职责边界

在生产架构中，常用对象可按职责划分：

一个常见误区是“所有应用都用 Deployment”。实际上，无状态服务优先 Deployment；有状态中间件使用 StatefulSet 并谨慎评估是否适合上 K8s；节点级代理用 DaemonSet；批处理用 Job/CronJob。

三、生产级参考架构

一个典型的 K8s 应用参考架构可以按流量和数据路径组织：

客户端
  -> DNS / CDN / WAF
  -> Ingress 或 Gateway API
  -> 认证、限流、灰度路由
  -> Service
  -> Pod（Deployment / StatefulSet）
  -> 缓存、数据库、消息队列、对象存储

旁路能力包括：

• 配置与密钥：ConfigMap、Secret、External Secrets；
• 可观测性：Prometheus、日志采集、OpenTelemetry、告警；
• 弹性能力：HPA、KEDA、Cluster Autoscaler；
• 安全治理：RBAC、NetworkPolicy、镜像扫描、准入控制；
• 交付体系：CI 构建镜像，GitOps 同步集群状态；
• 可用性保障：PDB、多副本、反亲和、多可用区部署。

在命名空间规划上，建议按“环境 + 团队/业务域”划分，例如 prod-order、staging-order。每个命名空间配合 ResourceQuota、LimitRange、RBAC 和默认拒绝的 NetworkPolicy，形成基本隔离边界。

四、关键设计决策

1. 无状态优先，有状态谨慎

业务服务尽量无状态，会话放到 Redis 或令牌中。数据库、消息队列等有状态系统是否上 K8s，要综合评估运维能力、存储性能、备份恢复和故障域。不要因为“云原生”而把核心数据库盲目容器化。

2. 配置外置，密钥外部化

普通配置放 ConfigMap，敏感信息放 Secret，但生产环境更建议使用外部密钥管理或 External Secrets。镜像应做到“一次构建，多环境晋级”。

3. 健康探针与优雅停机

readinessProbe 决定是否接流量，livenessProbe 决定是否重启。应用还需处理 SIGTERM、设置 preStop 和合理 terminationGracePeriodSeconds，避免发布时请求中断。

4. 资源请求与限制

所有生产 Pod 应设置 requests/limits。requests 影响调度，limits 影响运行时约束。结合 HPA、PDB 和拓扑分布，避免单节点故障导致整体不可用。

5. 发布策略

常规服务可用滚动更新；关键服务可采用蓝绿或金丝雀。发布流程应集成镜像扫描、配置校验、健康检查和自动回滚。GitOps 模式下，集群状态由 Git 声明式驱动，便于审计和回滚。

6. 安全默认收紧

使用非 root 用户、只读根文件系统、最小权限 ServiceAccount、NetworkPolicy 默认拒绝、镜像签名和准入控制。Secret 不应明文提交到 Git。

7. 可观测性从第一天开始

至少具备指标、日志、追踪和事件四类数据。应用暴露业务指标和 RED/USE 指标，定义 SLO 和告警阈值。没有可观测性的微服务架构，排障成本会迅速上升。

五、少量代码示例

下面仅用一个精简 YAML 表达最小部署单元：Deployment 提供多副本和就绪探针，Service 提供集群内稳定访问。生产环境还需补充 securityContext、PDB、HPA、NetworkPolicy 等。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels: { app: demo }
  template:
    metadata:
      labels: { app: demo }
    spec:
      containers:
        - name: demo
          image: nginx:1.27
          ports: [{ containerPort: 80 }]
          readinessProbe:
            httpGet: { path: /, port: 80 }
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { cpu: 500m, memory: 256Mi }
---
apiVersion: v1
kind: Service
metadata:
  name: demo
spec:
  selector: { app: demo }
  ports:
    - port: 80
      targetPort: 80

这段代码的价值不在“能跑”，而在于体现几个架构习惯：副本化、标签选择、健康检查、资源约束和稳定服务入口。

六、落地路径与常见误区

建议按以下路径落地：

1. 先规范命名空间、镜像、资源配置和探针；
2. 再建立 CI/CD 与 GitOps 发布链路；
3. 补齐日志、指标、追踪和告警；
4. 引入 HPA、PDB、NetworkPolicy 和资源配额；
5. 最后推进多环境晋级、混沌演练和成本治理。

常见误区包括：把 K8s 当虚拟机用；所有服务都拆微服务；没有 requests/limits；Secret 明文入库；只配 liveness 不配 readiness；缺少 PDB 导致滚动发布中断；把数据库随意容器化；缺少 NetworkPolicy 导致横向移动风险。

结论

Kubernetes 应用架构的核心，不是堆砌对象，而是围绕业务应用建立一套可运行的平台契约：工作负载合理、入口清晰、配置外置、存储有边界、安全默认收紧、发布可回滚、观测可排障、容量可治理。对多数团队而言，应先以简单、标准、可自动化的架构跑通生产闭环，再逐步引入服务网格、金丝雀、多集群等高级能力。架构的目标不是“最云原生”，而是让应用在 K8s 上稳定、可控、可持续演进。