Kubernetes部署中遇到的常见问题及解决方案

在Kubernetes（K8s）部署过程中，翻车其实挺常见的——镜像拉不下来、Pod起不来、Service访问不了……这些问题几乎每个运维和开发都会遇到。别急，下面把最常见的坑和对应的解法掰开揉碎讲清楚。

1. Pod无法启动

原因：

• 镜像拉取失败——最常见，比如地址写错、镜像不存在、或私有仓库没配认证。
• 资源限制不足——CPU或内存请求设得太高，节点没那么多资源。
• 配置错误——比如环境变量、命令参数写错了。
• 存储卷问题——挂载的PVC不存在或权限不对。

解决方案：

• 先确认镜像仓库地址是否可访问，可以用 docker pull 或 crictl pull 手动验证。
• 调整资源请求（requests）和限制（limits），让Pod申请的资源不超过节点可用量。
• 仔细过一遍Pod的YAML，尤其检查 env、command、args 这些容易出错的地方。
• 检查存储卷的 claimName 是否对应存在的PVC，以及PVC的访问模式是否匹配。

2. Service无法访问

原因：

• Service配置错误——端口号、协议、选择器没写对。
• Pod的标签与Service的选择器不匹配——这是最常见的“连不上”原因。
• 网络策略（NetworkPolicy）限制了流量——默认允许的情况下很少遇到，但一旦配了策略就容易忽略。

解决方案：

• 检查Service的YAML，确保 selector 里的标签和Pod的 labels 完全一致。
• 用 kubectl get endpoints 看看Service背后有没有关联的Pod IP，如果Endpoints为空，说明选择器没对上。
• 检查NetworkPolicy，确认没有 deny 规则拦住了入站或出站流量。

3. Ingress控制器无法正常工作

原因：

• Ingress资源配置错误——比如路径写错、后端Service名称或端口不对。
• Ingress控制器本身没安装好——或者安装后没配置对应的Service Type（比如LoadBalancer）。
• DNS解析问题——域名没指向Ingress控制器的对外IP。

解决方案：

• 用 kubectl describe ingress 查看事件，通常会把错误原因写得很清楚。
• 确保Ingress控制器（比如nginx-ingress、traefik）的Pod正常运行，并且暴露了端口（通常是80和443）。
• 检查域名解析，可以用 nslookup 或 dig 确认是否指向了正确的IP。

4. Pod频繁重启

原因：

• 容器启动失败——比如启动脚本出错、依赖的服务没就绪。
• 资源不足——实际运行期间内存或CPU超限，被OOM Kill。
• 健康检查失败——liveness或readiness探针配置不当，导致K8s认为Pod不健康而重启。

解决方案：

• 先看日志：kubectl logs 加上 --previous 参数可以看上一次重启的日志。
• 调整资源限制，特别留意内存是否给了足够余量。
• 检查探针配置：initialDelaySeconds 是否太短？periodSeconds 是否合理？探针返回的HTTP状态码或命令退出码是否符合预期？

5. 集群节点不稳定

原因：

• 节点硬件故障——磁盘IO异常、内存损坏、CPU过热。
• 节点网络问题——丢包、延迟高，导致kubelet与API Server通信中断。
• Kubernetes组件故障——kubelet、kube-proxy、容器运行时（如containerd）出现崩溃。

解决方案：

• 检查节点状态：kubectl describe node 可以看到节点条件和资源使用情况。
• 登录节点，查看系统日志（journalctl -u kubelet 以及 dmesg）定位硬件或网络问题。
• 检查组件日志，比如 journalctl -u kubelet 能看到kubelet的详细报错。

6. 配置文件语法错误

原因：

• YAML格式问题——最常见的是缩进不对，或者把Tab和空格混用了。
• JSON格式错误——少个逗号、多个大括号。

解决方案：

• 强烈推荐在编辑器中安装YAML/JSON检查插件，或者在提交前用 kubectl apply --dry-run=client -f file.yaml 验证。
• 也可以把YAML内容复制到在线校验工具（比如 yamlchecker.com）快速定位错误行。
• 记住：YAML缩进必须用空格，不能用Tab。

7. 权限问题

原因：

• RBAC权限不足——比如ServiceAccount没有创建Pod或访问Secret的权限。
• Secret或ConfigMap未正确挂载——通常是因为Secret不存在或挂载路径写错了。

解决方案：

• 检查RBAC配置：确保ServiceAccount绑定了合适的Role/ClusterRole，并且Role的规则覆盖了所需操作。
• 查看Pod事件：kubectl describe pod 会提示“secret not found”或“volume mount failed”之类的信息。
• 确认Secret/ConfigMap的名称和命名空间与Pod配置一致。

8. 日志收集问题

原因：

• 日志驱动配置错误——比如容器运行时用了 none 驱动，导致没有日志输出。
• 日志级别设置不当——业务程序把日志级别设得太高，或者根本没打日志。

解决方案：

• 检查容器运行时的日志驱动配置（如containerd的 config.toml），确保是 json-file 或 journald 等常见驱动。
• 调整应用日志级别，确保标准输出（stdout/stderr）能捕获到关键信息。
• 如果使用集群级的日志采集（如Fluentd、Logstash），确认DaemonSet或Sidecar的配置正确。

解决方案总结

• 检查日志：Pod、Service、Ingress、节点组件……日志永远是第一排查入口。
• 验证配置：YAML/JSON语法对不对？选择器、端口、标签是否匹配？用 kubectl explain 随时查字段说明。
• 资源管理：CPU/内存够不够？存储卷可不可用？网络带宽有没有瓶颈？
• 网络检查：DNS解析正常吗？Service的Endpoints有IP吗？防火墙或网络策略有没有拦？
• 权限管理：RBAC角色绑定对吗？Secret/ConfigMap挂载成功了吗？
• 组件状态：kubelet、kube-proxy、容器运行时是否正常运行？用 kubectl get componentstatuses 快速查看。

说一千道一万，K8s排障的核心就四个字：日志、配置、资源、网络。把这几个维度捋一遍，绝大多数问题都能找到根因。