后端工程

Kubernetes容器编排实战：从Pod到生产级部署的完整指南

系统学习Kubernetes核心概念与生产环境最佳实践，涵盖Pod设计、Service/Ingress配置、资源管理、HPA自动扩缩容、Helm包管理及多集群部署策略。

Leeting Yan 2025-11-27 5 分钟阅读 2097 字

引言

Kubernetes（K8s）在 2025 年已是容器编排的事实标准。但它并非银弹——复杂度不亚于维护一个小型操作系统。

何时该用 K8s：服务数量超过 5-10 个需要统一编排、需要自动扩缩容和滚动更新、有专职 DevOps 或平台工程师、多云部署需求。

何时不该用：单体应用或简单项目（Docker Compose 更合适）、团队小于 3 人缺乏运维能力、MVP 阶段优先验证业务。

1. 核心概念回顾

对象	作用	核心特点
Pod	最小调度单元	临时性、可替换
Deployment	管理副本和更新	滚动更新、回滚
Service	稳定网络端点	ClusterIP/NodePort/LB
ConfigMap	非敏感配置	键值对、文件挂载
Secret	敏感数据	Base64 编码、可加密
Namespace	逻辑隔离	多租户、资源配额

2. Pod 设计最佳实践

2.1 资源限制

resources:
  requests: { cpu: "250m", memory: "256Mi" }   # 调度依据
  limits:   { cpu: "1000m", memory: "512Mi" }   # 运行上限，内存超出则 OOM Kill

最佳实践：始终设置 requests 和 limits，requests 设为平均使用量，limits 设为峰值的 1.5-2 倍。配合 LimitRange 设置 Namespace 级默认值。

2.2 探针配置

# 启动探针：启动慢的应用（如 Java），避免 liveness 过早杀死容器
startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30, periodSeconds: 5   # 最多等 150 秒

# 存活探针：失败则重启容器
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10, failureThreshold: 3

# 就绪探针：失败则从 Service 摘除，不接收流量
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5, failureThreshold: 2

原则：liveness 只检查进程存活，不检查依赖；readiness 检查关键依赖可用性；避免 liveness 依赖外部服务，否则数据库故障会导致所有 Pod 重启。

3. Service 与 Ingress

3.1 Service 类型

类型	访问方式	适用场景
ClusterIP	集群内部（默认）	服务间通信
NodePort	节点 IP + 端口	开发测试
LoadBalancer	云厂商 LB	生产暴露服务
ExternalName	DNS CNAME	连接外部服务

3.2 Ingress 配置

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/rate-limit: "100"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
    - hosts: [api.example.com]
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend: { service: { name: api-server, port: { number: 80 } } }
          - path: /ws
            pathType: Prefix
            backend: { service: { name: websocket-server, port: { number: 80 } } }

4. 资源管理与调度

4.1 亲和性与反亲和性

Pod 反亲和性确保副本分布在不同节点/可用区，提高可用性：

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels: { app: api-server }
        topologyKey: kubernetes.io/hostname   # 不同节点
  # 软性约束：尽量分布在不同可用区
  preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector: { matchLabels: { app: api-server } }
        topologyKey: topology.kubernetes.io/zone

4.2 污点与容忍

污点限制哪些 Pod 可调度到节点（如 GPU 专用节点），容忍允许特定 Pod 调度到带污点的节点：

tolerations:
  - key: "dedicated", operator: "Equal", value: "gpu", effect: "NoSchedule"

5. HPA 与 VPA

5.1 HPA 配置

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: api-server-hpa }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api-server }
  minReplicas: 3
  maxReplicas: 20
  behavior:
    scaleDown: { stabilizationWindowSeconds: 300 }  # 缩容冷却 5 分钟
    scaleUp:   { stabilizationWindowSeconds: 60 }   # 扩容冷却 1 分钟
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }
    - type: Resource
      resource: { name: memory, target: { type: Utilization, averageUtilization: 80 } }
    # 自定义指标（如 QPS）
    - type: Pods
      pods: { metric: { name: http_requests_per_second },
              target: { type: AverageValue, averageValue: "1000" } }

最佳实践：扩容冷却 < 缩容冷却（避免缩容抖动），配合 PDB 保证更新期间可用性，自定义指标比 CPU 更精准。

5.2 VPA 配置

VPA 自动调整 requests/limits。注意 VPA 和 HPA 不能同时基于 CPU/内存，但可组合使用：VPA 调资源 + HPA 调副本（基于自定义指标）。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata: { name: api-server-vpa }
spec:
  targetRef: { apiVersion: apps/v1, kind: Deployment, name: api-server }
  updatePolicy: { updateMode: "Auto" }
  resourcePolicy:
    containerPolicies:
      - containerName: api
        minAllowed: { cpu: "100m", memory: "128Mi" }
        maxAllowed: { cpu: "2000m", memory: "2Gi" }

6. 存储管理

PV/PVC 抽象持久化存储：Pod → PVC (claim) → PV (volume) → StorageClass → 实际存储。StatefulSet 中使用 volumeClaimTemplates 为每个 Pod 创建独立 PVC。主流 CSI 驱动：AWS EBS CSI、GCP PD CSI、Azure Disk CSI、Ceph RBD CSI。

7. Helm 包管理

Chart 结构：Chart.yaml（元数据）、values.yaml（默认配置）、values-{env}.yaml（环境配置）、templates/（模板文件）。常用命令：helm install、helm upgrade、helm rollback。推荐公共 Chart：ingress-nginx、cert-manager、kube-prometheus-stack、bitnami/postgresql、bitnami/redis。

8. 生产环境 Checklist

8.1 安全策略

Pod Security Standards（PSS，K8s 1.25+）替代已废弃的 PodSecurityPolicy：

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted

容器安全上下文：

securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities: { drop: ["ALL"] }

清单：非 root 运行、禁用特权模式、只读根文件系统、最小基础镜像（distroless/Alpine）、Secret 加密存储。

8.2 网络策略

默认拒绝所有流量，按需开放（Deny-All）：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: api-server-policy }
spec:
  podSelector: { matchLabels: { app: api-server } }
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - namespaceSelector: { matchLabels: { name: ingress-nginx } }
      ports: [{ port: 8080 }]
  egress:
    - to: [{ podSelector: { matchLabels: { app: postgres } } }]
      ports: [{ port: 5432 }]
    - ports: [{ port: 53, protocol: UDP }]  # DNS

9. 多集群与混合云策略

驱动因素：地域级高可用、合规要求（GDPR）、环境隔离、避免云厂商锁定。

方案	特点
Karmada（CNCF）	多集群调度、策略分发
Crossplane（CNCF）	基础设施即代码、跨云管理
Rancher	多集群管理 UI
Istio Multi-Cluster	跨集群服务通信

10. 总结

Kubernetes 生产级部署需要多维度优化：Pod 设计（资源限制 + 三种探针）、服务暴露（Ingress + TLS）、调度策略（亲和性 + 污点）、自动扩缩容（HPA + VPA）、存储管理（CSI + PVC）、包管理（Helm）、安全加固（PSS + NetworkPolicy）、多集群方案（Karmada/Crossplane）。

不是所有项目都需要 K8s。采用前请评估团队能力、业务复杂度和运维成本。中小规模项目，Docker Compose + 云服务可能更具性价比。

11. 延伸阅读

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章返回首页

引言

目录