服务器K8s集群Nexus排错：Pod启动失败与连接超时处理

在K8s集群里跑Nexus仓库，最常见的问题集中在三处：Pod反复重启、Service访问超时、Nexus自身返回502或存储写入失败。
排查顺序建议从Pod状态入手，再查Service和Ingress，最后看Nexus应用日志和存储权限。
下面按零基础也能照做的步骤展开。

先确认Pod到底卡在哪一步

登录到能执行kubectl的跳板机或Master节点，先看Nexus所在命名空间的Pod状态：

kubectl get pods -n nexus -o wide

重点关注STATUS列，常见取值对应不同方向：

• CrashLoopBackOff：容器启动后立即退出，多半是配置错误、内存不足或数据目录权限不对。
• Pending：调度失败，通常是节点资源不够、PVC未绑定或节点选择器不匹配。
• Running但READY为0/1：容器在跑但探针没过，检查livenessProbe和readinessProbe的路径与端口。
• ImagePullBackOff：拉不到镜像，检查镜像地址、私有仓库Secret和网络策略。

确认状态后，直接看事件和日志：

kubectl describe pod  -n nexus
kubectl logs  -n nexus --tail=100

describe输出末尾的Events区域会直接告诉你失败原因，比如FailedMount、Back-off pulling image或OOMKilled。
这一步能省掉大量猜测。

存储与权限：Nexus数据目录写不进去

Nexus默认以非root用户运行，如果PVC挂载后的目录属主不是200（Nexus镜像内UID），容器会因无法写/nexus-data而退出。
检查PVC绑定状态：

kubectl get pvc -n nexus

如果状态是Pending，说明没有匹配的PV或StorageClass不可用。
若已Bound，进入Pod确认挂载点权限：

kubectl exec -it  -n nexus -- ls -ld /nexus-data

预期应看到目录属主为200:200或具备写权限。
如果不对，在宿主机或通过initContainer调整权限：

chown -R 200:200 /data/nexus

注意：生产环境不要直接对已挂载的PVC执行递归chown，先确认没有其他Pod在用同一卷，避免影响正在写入的数据。

Service和Ingress访问不通怎么查

Pod正常后，先验证集群内Service是否可达。
进入任意一个同命名空间的Pod执行：

kubectl exec -it <任意pod> -n nexus -- curl -I http://nexus-service:8081

如果返回Connection refused，检查Service的targetPort是否和Nexus容器实际监听端口一致。
Nexus默认HTTP端口是8081，HTTPS是8443，很多YAML模板会写错。

kubectl get svc nexus-service -n nexus -o yaml

核对port和targetPort。
如果集群内能通但外部访问超时，再看Ingress或NodePort：

kubectl describe ingress  -n nexus
kubectl get endpoints -n nexus

Endpoints为空说明Service没有选中任何Pod，通常是selector标签与Pod的labels不匹配。
这是新手最容易忽略的一步。

资源不足与探针误判

Nexus启动较吃内存，默认resources.limits.memory如果设得过低，容器会被OOMKilled。
查看是否发生过内存杀进程：

kubectl describe pod  -n nexus | grep -A5 "Last State"

若看到Reason: OOMKilled，适当调高内存限制，比如从1Gi调到2Gi，并确认节点有足够可分配资源：

kubectl describe node  | grep -A10 "Allocated resources"

另外，Nexus首次启动初始化较慢，如果livenessProbe的initialDelaySeconds太短，容器会在初始化完成前被反复重启。
建议将initialDelaySeconds设为120以上，failureThreshold设为3到5，给足启动时间。

常见疑问

Nexus Pod一直CrashLoopBackOff，最先看什么？
先执行kubectl logs看应用日志最后几行，再执行kubectl describe pod看Events。多数情况是数据目录权限或内存限制导致，按上文存储和资源两节排查即可。

Service能ping通但curl超时？
ping用的是ICMP，Service是四层转发，两者机制不同。直接用curl -v或wget测试目标端口，同时检查NetworkPolicy是否拦截了流量。

Ingress返回502但Pod正常？
检查Ingress的serviceName和servicePort是否与实际Service一致，再看Ingress Controller日志是否有连接后端超时的记录。

排错的核心思路是分层验证：Pod状态和事件、存储挂载、Service端点、Ingress转发、应用日志。
每层确认无误后再进入下一层，不要一上来就改配置。
修复后重新执行kubectl get pods和curl验证，确认Pod稳定运行且接口有正常响应，再继续后续使用。