1. Pod频繁重启：没设置资源限额的悲剧
技术栈：Kubernetes v1.25 + YAML配置
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
template:
spec:
containers:
- name: nginx
image: nginx:1.21
# 缺少resources字段会导致容器资源无节制使用
解决方案：
# 正确配置：添加资源请求和限制
resources:
requests:
memory: "256Mi"
cpu: "200m"
limits:
memory: "512Mi"
cpu: "500m" # CPU限额设置为0.5核
技术分析：
- 应用场景：Web服务器、数据库等需要稳定性的服务
- 优缺点：预防OOMKilled事件，但过度限制会导致资源浪费
- 注意事项：建议通过压测确定合理数值，生产环境必须配置
2. 服务雪崩：就绪探针配置缺失
技术栈：Spring Boot应用 + Kubernetes Service
# 危险配置：没有就绪探针的Service
livenessProbe:
httpGet:
path: /actuator/health
initialDelaySeconds: 5
# 缺少readinessProbe会导致流量打到未初始化完成的Pod
修复方案：
readinessProbe:
httpGet:
path: /api/ready # 业务自定义就绪检查端点
port: 8080
failureThreshold: 3
periodSeconds: 10 # 每10秒检测一次
关联技术：
# 使用kubectl debug命令验证探针
kubectl port-forward pod/web-7d8f9 8080:8080
curl http://localhost:8080/api/ready
3. 配置文件混乱：ConfigMap热更新失效
技术栈：Python Flask应用 + ConfigMap
# 错误用法：直接挂载ConfigMap目录
volumes:
- name: config
configMap:
name: app-settings
volumeMounts:
- mountPath: /etc/config # 整个目录挂载导致单文件更新不生效
正确配置：
# 精准挂载单个配置文件
volumeMounts:
- mountPath: /app/config.yaml
subPath: config.yaml # 使用subPath隔离更新
热更新技巧：
# 触发配置重新加载（无需重启Pod）
kubectl rollout restart deployment/myapp
4. 存储灾难：PVC删除导致数据丢失
技术栈：AWS EKS + EBS存储类
# 危险配置：使用默认回收策略
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: ebs.csi.aws.com
reclaimPolicy: Delete # 默认值会在PVC删除时销毁数据
正确配置：
reclaimPolicy: Retain # 保留存储卷
parameters:
encrypted: "true" # 启用加密功能
数据保护策略：
# 创建定期快照的CronJob
kubectl create cronjob ebs-snapshot \
--image=aws-cli \
--schedule="0 2 * * *" \
-- \
ec2 create-snapshot --volume-id $(kubectl get pv pvc-xxxx -o jsonpath='{.spec.awsElasticBlockStore.volumeID}')
5. 版本陷阱：API弃用导致集群升级失败
技术栈：Kubernetes 1.22升级到1.25
# 检查废弃API的命令
kubectl api-resources --verbs=list --namespaced -o wide | grep "v1beta1"
迁移方案：
# 旧的Deployment配置（已弃用）
apiVersion: extensions/v1beta1 # 1.16+已弃用
# 修正为
apiVersion: apps/v1
升级检查清单：
- 使用kube-no-trouble扫描集群
- 分阶段升级（先worker node后master）
- 保留快速回滚的快照
6. 网络黑洞：Service类型选择错误
技术栈：NodePort vs LoadBalancer
# 错误场景：生产环境直接使用NodePort
kind: Service
spec:
type: NodePort # 需要手动管理流量分发
ports:
- nodePort: 31000 # 端口冲突风险
云环境最佳实践：
type: LoadBalancer # 自动创建云厂商负载均衡器
metadata:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
7. 调度瓶颈：节点亲和性配置不当
技术栈：GPU节点调度
# 模糊的节点选择器导致调度失败
nodeSelector:
accelerator: gpu # 标签可能不存在
# 精确的节点亲和性配置
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node.kubernetes.io/instance-type
operator: In
values: [p3.2xlarge, g4dn.xlarge]
8. 日志黑洞：DaemonSet配置错误
技术栈：Fluentd日志收集
# 错误配置：未挂载Docker日志目录
volumeMounts:
- name: varlog
mountPath: /var/log # 遗漏容器运行时日志路径
# 正确配置
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
9. 认证危机：RBAC权限过大
技术栈：服务账户权限控制
# 危险的角色绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
subjects:
- kind: ServiceAccount
name: frontend
roleRef:
kind: ClusterRole
name: cluster-admin # 授予过高权限
# 最小权限原则示例
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
10. 扩展陷阱：HPA指标选择错误
技术栈：Prometheus + Custom Metrics
# 无效的CPU指标配置
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 80 # 可能无法反映真实负载
# 使用自定义业务指标
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: 1000
11. 技术总结
应用场景：
- 中小规模集群优化
- CI/CD环境调试
- 多云环境部署验证
注意事项：
- 生产环境必须启用审计日志
- 定期执行kube-bench安全扫描
- 使用Kyverno等工具实施策略管控
评论