Kubernetes部署的自托管GitLab升级至17.1.0后Web服务无法连接容器注册表

嘿，遇到这种升级后服务突然失联的情况确实闹心，我帮你梳理几个在K8s环境下最可能的排查方向和解决办法：

• 先确认Registry服务本身是否正常运行
  先从最基础的开始：登录到任意一个webservice的Pod里（kubectl exec -n <你的GitLab命名空间> -it <webservice-pod-name> -- bash），然后用telnet gitlab-registry 5000或者curl -v http://gitlab-registry:5000试试能不能通。如果连不上，先去看Registry的Pod状态：kubectl get pods -n <命名空间> -l app=registry，是不是有Pod处于CrashLoopBackOff或者Pending状态？再拉取Registry的日志看看启动时有没有报错：kubectl logs -n <命名空间> <registry-pod-name>，常见的问题比如存储卷挂载失败、配置文件语法错误，或者依赖的Redis/PostgreSQL连不上。

• 检查K8s服务发现和配置正确性
  GitLab升级（尤其是大版本升级）可能会通过Helm Chart覆盖部分配置。你需要确认webservice组件的配置里，指向Registry的地址是否正确。比如进入webservice的ConfigMap（kubectl edit configmap -n <命名空间> gitlab-webservice），查找registry_api_url或者registry_external_url字段，确认值是K8s内部的Registry服务地址，比如http://gitlab-registry.<命名空间>.svc.cluster.local:5000——别写成外部的域名了，内部通信要用ClusterIP服务的地址。

• 排查NetworkPolicy的拦截
  如果你的K8s集群启用了NetworkPolicy，升级过程中可能新增了默认拒绝的策略，或者修改了原有允许webservice访问Registry的规则。你可以先临时删除GitLab命名空间下的所有NetworkPolicy测试：kubectl delete networkpolicy -n <命名空间> --all，如果删完之后能连上了，就说明是策略的问题。接下来需要调整NetworkPolicy，允许带有app: webservice标签的Pod访问带有app: registry标签的Pod的5000端口。

• 检查TLS证书和Faraday的适配问题
  GitLab 17.1.0可能升级了Faraday库，对TLS证书的校验更严格了。如果你的Registry用的是自签名证书，要确认webservice的Pod里已经把这个证书加到了系统信任的证书存储中（比如/etc/ssl/certs目录）。另外，检查GitLab配置里的registry_verify_certificates字段，如果是自签证书的场景，可能需要临时设置为false（生产环境建议替换为可信CA签发的证书）。

• 检查Registry的资源限制
  升级后Registry的资源需求可能变高了，如果Pod的CPU/内存限制设置得太低，可能会导致服务无法正常响应请求。你可以用kubectl top pod -n <命名空间> <registry-pod-name>查看资源使用情况，如果CPU或内存接近上限，就调整Deployment里的resources.limits和resources.requests参数，给Registry多分配点资源。

备注：内容来源于stack exchange，提问作者Paul