服务器K8s集群SonarQube排错：Pod启动失败与Web无法访问排查

SonarQube在K8s里跑不起来，多数不是镜像本身的问题，而是资源限制、数据库连接、持久化卷或启动探针配置不当。
下面按从外到内的顺序，梳理一套能直接照做的排错流程。

先确认Pod到底卡在哪一步

执行以下命令查看Pod整体状态：

kubectl get pods -n sonarqube -o wide

重点看STATUS和RESTARTS两列：

• Pending：通常是没有节点满足资源请求，或PVC没绑定成功。
• CrashLoopBackOff：容器反复退出，需要看上一次崩溃日志。
• Running但READY 0/1：应用启动了但健康检查没过。
• ImagePullBackOff：镜像拉取失败，检查镜像地址和私有仓库密钥。

配合kubectl describe pod -n sonarqube看Events，能快速区分是调度问题还是容器内部问题。

日志和事件是排错主线

查看当前日志：

kubectl logs  -n sonarqube

如果容器已经重启过，查看上一次崩溃日志：

kubectl logs  -n sonarqube --previous

常见日志关键词与含义：

• Connection refused或UnknownHostException：数据库地址或网络策略不通。
• Access denied for user：数据库账号密码错误或权限不足。
• max virtual memory areas vm.max_map_count：Elasticsearch内置组件要求宿主内核参数，需在节点执行sysctl -w vm.max_map_count=262144并写入/etc/sysctl.conf。
• No space left on device：PVC容量不足或节点磁盘满。

同时用kubectl describe pod看Events里是否有FailedScheduling、FailedMount或Unhealthy，这些信息比日志更早暴露问题。

数据库连接是最高频故障点

SonarQube从某个大版本开始不再内置数据库，必须外接PostgreSQL或MySQL。
若Pod反复重启且日志停在Waiting for database，按以下顺序检查：

1. 在Pod内测试连通性：

kubectl exec -it  -n sonarqube -- bash
# 容器内执行
nc -zv  5432

1. 核对Secret或环境变量中的SONAR_JDBC_URL、SONAR_JDBC_USERNAME、SONAR_JDBC_PASSWORD是否与数据库实际一致。
2. 确认数据库已创建对应库，例如PostgreSQL中执行CREATE DATABASE sonarqube;。
3. 检查NetworkPolicy或云厂商安全组是否放行了Pod网段到数据库端口的流量。

如果数据库连接正常但仍启动慢，把readinessProbe的initialDelaySeconds临时调大，例如从60调到120，观察是否能进入Running状态。

持久化与资源限制别忽略

SonarQube的数据目录/opt/sonarqube/data和扩展目录/opt/sonarqube/extensions需要持久化。
PVC处于Pending时，用kubectl describe pvc -n sonarqube查看原因，常见是StorageClass不存在或节点亲和性冲突。

资源方面，SonarQube对内存较敏感。
若Pod因OOMKilled退出，kubectl describe pod会显示Reason: OOMKilled，此时需要提高resources.limits.memory，一般建议不低于2Gi，具体视代码库规模调整。

验证服务是否真正恢复

排错后按以下顺序验证：

• kubectl get pods -n sonarqube显示Running且READY 1/1。
• kubectl get svc -n sonarqube确认Service的端口映射正确。
• 集群内用curl -I http://:9000返回HTTP 200或302。
• 通过Ingress或NodePort从浏览器访问，能打开登录页即算恢复。

若页面能打开但登录后报错，优先看web.log和ce.log，这两个日志在Pod的/opt/sonarqube/logs目录下，用kubectl exec进入容器查看即可。

几个容易踩的坑

• 启动探针livenessProbe的failureThreshold设得太小，导致应用还没初始化完就被重启，形成死循环。
• 用latest标签拉镜像，每次重建可能拉到不同版本，排错时先固定镜像tag。
• 数据库和SonarQube不在同一集群时，跨网络延迟会拖慢启动，必要时把数据库迁移到同区域。
• 修改配置后忘记kubectl rollout restart deployment -n sonarqube，导致改动未生效。

整体来看，服务器K8s集群SonarQube排错的核心是：先看Pod状态和Events，再结合日志定位是数据库、存储还是资源问题，最后用探针和访问测试确认恢复。
按这个顺序走，大部分启动失败都能在十分钟内找到方向。