Kubernetes运维实战：5大核心问题解决方案-平芜编程栈

1. Kubernetes常见问题深度解析

作为容器编排领域的事实标准，Kubernetes（简称K8s）在实际部署和维护过程中总会遇到各种"坑"。今天结合我多年在生产环境中的实战经验，梳理出五个最具代表性的问题场景及其解决方案。这些问题覆盖了从集群搭建到日常运维的关键环节，每个都是血泪教训换来的经验。

2. 集群初始化与节点管理

2.1 节点NotReady状态排查指南

当执行kubectl get nodes发现节点状态异常时，建议按以下顺序排查：

网络连通性检查：
```
ping <节点IP> ssh <节点IP> # 测试SSH连接
```
如果基础网络不通，需要检查CNI插件配置。Calico和Flannel是最常用的选择，但要注意：
- Calico对网络策略支持更完善
- Flannel配置更简单但功能较少
关键组件状态检查：
```
journalctl -u kubelet --no-pager -n 50 # 查看kubelet日志 systemctl status docker # 容器运行时状态
```
常见错误包括：
- 证书过期（特别是使用kubeadm安装时）
- 内存不足导致OOMKill
- 磁盘空间不足（/var/lib/docker容易爆满）

重要提示：生产环境务必配置节点监控，建议使用Node Exporter配合Prometheus实现资源监控。

2.2 资源分配与调度优化

通过以下命令查看节点资源使用情况：

kubectl top nodes kubectl describe nodes | grep -A 10 Allocatable

优化建议：

设置合理的requests/limits比例（建议limits不超过requests的1.5倍）

使用Pod反亲和性避免单点过载：

affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: [my-webapp] topologyKey: kubernetes.io/hostname

3. 存储与持久化卷难题

3.1 PVC一直处于Pending状态

当持久卷声明无法绑定时，需要检查：

StorageClass配置是否正确：
```
kubectl get storageclass kubectl describe storageclass <name>
```
常见问题：
- 未指定默认StorageClass
- Provisioner服务不可用（如nfs-client未运行）
PV与PVC的匹配条件：
- accessModes必须兼容（RWX/RWO）
- storageClassName必须一致
- 资源请求大小要匹配

3.2 数据持久化最佳实践

对于有状态应用，建议：

使用StatefulSet而非Deployment

配置适当的volumeClaimTemplates：

volumeClaimTemplates: - metadata: name: data spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "ssd" resources: requests: storage: 100Gi

定期备份PV数据（Velero是不错的选择）

4. 网络问题诊断技巧

4.1 Service无法访问的排查流程

检查Endpoint是否正常：
```
kubectl get endpoints <service-name>
```
如果Endpoint为空，说明Selector与Pod标签不匹配

测试ClusterIP连通性：

kubectl run -it --rm --image=alpine test -- sh apk add curl curl <cluster-ip>:<port>

检查kube-proxy日志：

kubectl logs -n kube-system <kube-proxy-pod>

4.2 Ingress控制器常见配置错误

以Nginx Ingress为例，典型问题包括：

未暴露80/443端口：

ports: - name: http containerPort: 80 hostPort: 80 - name: https containerPort: 443 hostPort: 443

未正确配置default-backend
忘记创建对应的ServiceAccount

5. 工作负载管理经验谈

5.1 Deployment滚动更新卡住怎么办

当kubectl rollout status长时间不完成时：

检查就绪探针配置是否过于严格
查看ReplicaSet事件：
```
kubectl describe rs <rs-name>
```
回滚到上一版本：
```
kubectl rollout undo deployment/<name>
```

5.2 资源限制导致的OOMKill

内存泄漏是Java应用的常见问题，建议：

resources: limits: memory: "2Gi" cpu: "1" requests: memory: "1Gi" cpu: "0.5"

同时配置合理的JVM参数：

-XX:MaxRAMPercentage=75.0

6. 监控与日志收集方案

6.1 搭建基础监控栈

推荐组合：

Prometheus（指标收集）
Grafana（可视化）
Alertmanager（告警）

安装步骤：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install prometheus prometheus-community/kube-prometheus-stack

6.2 日志收集的坑与技巧

避免使用DaemonSet收集所有日志，建议：

对关键应用单独配置sidecar容器
使用Fluent Bit替代Fluentd（资源消耗更少）

设置合理的日志轮转策略：

args: - --log-file-max-size=200 - --log-file-max-age=5

7. 安全加固实践

7.1 RBAC配置原则

遵循最小权限原则：

kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]

7.2 镜像安全扫描

集成Trivy到CI流程：

trivy image --exit-code 1 --severity CRITICAL my-image:latest

定期检查运行中的镜像：

kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq |\ xargs -I{} trivy image {}

8. 性能调优实战

8.1 API Server优化参数

修改/etc/kubernetes/manifests/kube-apiserver.yaml：

spec: containers: - command: - kube-apiserver - --max-requests-inflight=1500 - --max-mutating-requests-inflight=500

8.2 etcd性能调优

关键参数：

--quota-backend-bytes=8589934592 # 8GB --auto-compaction-retention=24h

监控etcd性能：

etcdctl check perf

9. 版本升级注意事项

9.1 预升级检查清单

备份所有关键资源：

kubectl get all --all-namespaces -o yaml > all-resources.yaml

检查API版本兼容性
逐个节点滚动升级

9.2 回滚方案设计

确保：

有完整的备份（包括etcd快照）
了解降级路径（不是所有版本都支持降级）
测试过回滚流程

10. 疑难杂症处理记录

10.1 诡异的DNS解析失败

当遇到间歇性DNS问题时：

检查CoreDNS日志：

kubectl logs -n kube-system <coredns-pod>

测试不同查询类型：

dig +short <service>.<namespace>.svc.cluster.local dig +short <pod-ip>.default.pod.cluster.local

10.2 节点磁盘压力处理

自动清理Docker旧镜像：

docker system prune -af --filter "until=24h"

配置kubelet自动回收：

--eviction-hard=memory.available<100Mi,nodefs.available<10% --eviction-minimum-reclaim=memory.available=0Mi,nodefs.available=500Mi

Kubernetes运维实战：5大核心问题解决方案