Kubernetes容器化部署实战：Pod资源配额与滚动更新配置

容器化应用部署：Kubernetes Pod资源配额与requests配置

Kubernetes集群调度依赖Pod的requests与limits配置。requests是调度时承诺的资源量，limits是运行时硬上限，前者决定Pod落到哪个节点，后者决定CGroup是否限制用量。配置缺失会让调度器把Pod全堆到一台节点，触发内存OOM或CPU抢占，Pod被反复驱逐。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-svc
  namespace: prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-svc
  template:
    metadata:
      labels:
        app: order-svc
    spec:
      containers:
      - name: order-svc
        image: registry.example.com/order-svc:1.4.2
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: "1"
            memory: 1Gi
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080

requests值建议取压测得到的P99稳态用量，limits内存与requests保持1.5到2倍，CPU limit可设1核到2核。requests过大浪费资源，过小则节点超卖导致Pod竞争。

Kubernetes滚动更新与回滚：deployment策略与健康检查联动

滚动更新时新版Pod先就绪再摘流，由Deployment的maxSurge与maxUnavailable控制节奏。健康检查（readinessProbe）必须配置，否则新版Pod尚未就绪也会被纳入Service流量，发布瞬间产生大量502。

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

maxSurge=1表示允许多出一个新Pod，maxUnavailable=0表示发布期间不能有旧Pod低于期望副本数，这是零中断发布的常见组合。发布完成后如需回滚，kubectl rollout undo deployment/order-svc直接退回上一版镜像，回滚过程同样走滚动更新。

Kubernetes配置管理：ConfigMap与Secret的挂载方式

应用配置应通过ConfigMap管理，敏感信息走Secret。两者都支持环境变量注入与文件挂载两种方式，文件挂载能实现配置变更后由应用热加载。

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.yaml: |
    log_level: info
    cache_ttl: 300
---
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:
  password: "ChangeMe123"

# Deployment 中挂载
volumeMounts:
  - name: app-config
    mountPath: /etc/app/config
    readOnly: true
volumes:
  - name: app-config
    configMap:
      name: app-config

Secret的stringData在创建时自动base64编码，集群内通过kubectl get secret -o yaml仍能看到明文，生产环境应启用KMS加密或使用外部密钥管理组件如Secrets Store CSI Driver。

Kubernetes故障排查：Pod Pending与CrashLoopBackOff诊断步骤

Pod处于Pending时，kubectl describe pod会给出具体原因：节点资源不足、污点未容忍、持久卷未绑定等。CrashLoopBackOff则说明容器启动后反复退出，需要看日志和退出码。

# 诊断流程
kubectl describe pod order-svc-xxx
kubectl logs order-svc-xxx --previous
kubectl get events --sort-by=.lastTimestamp | tail -20
# 容器反复退出
kubectl exec -it order-svc-xxx -- sh

日志无输出时检查entrypoint和健康检查的启动路径；Exit Code 137常见于内存limit触底被杀，配合kubectl top pod确认用量。事件里会明确显示OOMKilled或Evicted。

Kubernetes存储与网络：PVC挂载与Service暴露的配置要点

有状态应用需要持久卷，StorageClass自动创建PV，PVC挂载到Pod后数据生命周期独立于容器。网络层用Service暴露：ClusterIP供集群内访问，NodePort供外部，Ingress做域名路由。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: standard
  resources:
    requests:
      storage: 20Gi
---
apiVersion: v1
kind: Service
metadata:
  name: order-svc
spec:
  selector:
    app: order-svc
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

多副本共享读写场景改用ReadWriteMany，需要存储后端支持NFS或CephFS。Service选择器必须与Pod标签严格一致，selector写错是服务连不通的高频原因。

Kubernetes部署的熟练度体现在资源声明是否与业务真实负载匹配，以及故障定位是否按顺序排查。把requests/limits、探针、滚动策略三件套配置正确，多数集群问题都可以规避。