在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排障的核心就四个字：日志、配置、资源、网络。把这几个维度捋一遍，绝大多数问题都能找到根因。
