错误一：livenessProbe探针“自杀式”配置——30秒内让Pod重启20次

现象：Pod状态在Running → Terminating → CrashLoopBackOff之间循环，重启间隔仅30秒。某电商平台订单服务因该问题导致支付接口5分钟不可用，损失超百万。

技术陷阱：健康检查接口依赖数据库连接池，而探针参数设置与应用实际启动时间冲突：

livenessProbe:
  httpGet:
    path: /health  # 直接查询数据库
    port: 8080
  initialDelaySeconds: 3  # 启动仅3秒就开始探测
  timeoutSeconds: 1      # 1秒超时（小于数据库连接超时5秒）
  periodSeconds: 10       # 每10秒探测一次，加剧连接池压力

当数据库连接池耗尽时，探针请求因超时而失败，触发Pod重启。重启后连接泄漏持续累积，最终导致数据库完全不可用。

正确配置：

livenessProbe:
  httpGet:
    path: /health/liveness  # 独立的内存健康检查接口
    port: 8080
  initialDelaySeconds: 60   # 预留应用启动时间
  timeoutSeconds: 5
  failureThreshold: 3       # 允许3次失败再重启

错误二：缺失Resource Limits——节点资源“雪崩式”耗尽

案例：某银行在K8s集群部署初期未设置资源限制，导致一个内存泄漏的Java应用占用节点90%内存，触发OOM killer，连带杀死相邻3个核心服务Pod。

资源争夺机制：Kubernetes采用请求-限制模型：

• requests：调度时的资源保证（如512Mi内存）
• limits：运行时的资源上限（如1Gi内存）

若缺失limits，容器可无限制使用节点资源，导致：

1. 内存溢出（OOMKilled）：进程被内核强制终止
2. CPU节流：容器被限制在低优先级运行，响应延迟飙升

正确配置：

resources:
  requests:
    cpu: "500m"    # 0.5核CPU保证
    memory: "512Mi"
  limits:
    cpu: "1000m"   # 1核CPU上限
    memory: "1Gi"

错误三：HPA配置“反向优化”——流量高峰时Pod不增反减

典型误区：某电商促销活动中，HPA配置
targetCPUUtilizationPercentage: 90%，导致流量突增时Pod始终不扩容。

数学陷阱：HPA存在容忍度机制（默认10%），当requests=limits时：

• 实际利用率在81%~99%之间均被忽略
• 90%目标利用率 → 有效扩容阈值高达99%

正确配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 60  # 目标利用率降至60%
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 缩容冷却5分钟

错误四：Service标签“致命拼写错误”——流量路由“黑洞”

生产事故：某支付系统新部署的Pod因标签拼写错误（app: oder-service而非order-service），导致Service的Endpoints为空，交易流量全部丢失。

排查命令：

kubectl get endpoints order-service  # 显示空列表
kubectl describe svc order-service | grep Selector  # 检查选择器
kubectl get pods -l app=order-service  # 验证Pod标签匹配

预防措施：使用标签校验工具，在CI/CD流程中添加：

# 检查Deployment与Service标签匹配
if ! kubectl get deployment order-service -o jsonpath='{.spec.selector.matchLabels}' | grep -q "app=order-service"; then
  echo "标签不匹配，部署终止"
  exit 1
fi

错误五：ConfigMap挂载“路径覆盖”——应用配置“离奇失踪”

故障场景：将ConfigMap挂载到/etc目录，导致容器内/etc/resolv.conf被覆盖，DNS解析失败。

原理：Kubernetes挂载卷时会替换目标目录，而非合并内容。正确做法是使用subPath挂载单个文件：

volumeMounts:
- name: config-volume
  mountPath: /etc/app/config.yaml
  subPath: config.yaml  # 仅挂载指定文件

错误六：PodSecurityContext“权限炸弹”——以root运行被禁用

错误配置：

securityContext:
  runAsUser: 0  # 使用root用户运行

若集群启用PodSecurityPolicy，会直接拒绝创建此类Pod。正确做法：

securityContext:
  runAsUser: 1000        # 非root用户ID
  runAsGroup: 3000
  fsGroup: 2000          # 卷访问权限组

错误七：StatefulSet无头服务“DNS解析失败”

排查要点：

1. 确认Service名称与StatefulSet的serviceName一致
2. 检查DNS记录：nslookup web-0.nginx.default.svc.cluster.local
3. 验证无头服务配置：

spec:
  clusterIP: None  # 必须设置为None
  selector:
    app: nginx

错误八：节点亲和性“逻辑冲突”——Pod永远Pending

典型错误：同时设置
requiredDuringSchedulingIgnoredDuringExecution和冲突的nodeSelector，导致Pod无法调度。正确示例：

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disktype
          operator: In
          values:
          - ssd

配置检查清单

1. 存活探针：避免依赖外部服务，initialDelaySeconds > 应用启动时间
2. 资源限制：所有Pod必须设置requests和limits，比例建议1:2
3. HPA：目标CPU利用率≤70%，配置缩容冷却时间
4. 标签管理：使用自动化工具校验Deployment与Service标签一致性
5. 安全上下文：禁用root用户，设置readOnlyRootFilesystem: true