在GCP部署的OpenShift Pod内访问http://metadata.google.internal时遭遇连接拒绝错误的解决方法

我来帮你搞定这个连接拒绝的问题，在GCP部署的OpenShift集群里，Pod访问元数据服务出问题是比较常见的场景，咱们一步步排查解决：

• 先检查节点上的元数据代理状态
  OpenShift在GCP上默认靠节点的kube-metadata-proxy来转发Pod的元数据请求。你先看看这个代理Pod是不是正常运行：

oc get pods -n kube-system | grep metadata-proxy

要是发现代理Pod状态异常或者没运行，直接删掉它让集群重建就行：

oc delete pod <metadata-proxy-pod-name> -n kube-system

• 确认Pod的服务账户权限
  Pod用的服务账户得有访问GCP元数据的权限才行。默认的OpenShift服务账户权限可能不够，你可以给对应的服务账户绑定一个合适的GCP角色，比如roles/compute.viewer：

gcloud projects add-iam-policy-binding <你的项目ID> --member "serviceAccount:<你的服务账户>@<你的项目ID>.iam.gserviceaccount.com" --role "roles/compute.viewer"

另外别忘了检查Pod的YAML配置里，serviceAccountName字段是不是指向了这个有权限的服务账户。

• 排查网络策略限制
  有时候集群的网络策略会挡住Pod的出站流量，连不上metadata服务。先看看当前有哪些网络策略：

oc get networkpolicy

如果有策略限制了80端口的出站，得修改策略允许Pod访问metadata.google.internal，或者新增一个专门的规则放行这个地址的流量。

• 在节点上测试元数据访问
  登录到Pod所在的节点，直接在节点上跑curl命令试试：

curl 'http://metadata.google.internal/computeMetadata/v1/project/?recursive=true' -H 'Metadata-Flavor: Google'

要是节点能正常拿到响应，说明问题出在Pod到节点的转发环节；要是节点也访问不了，那得检查GCP节点本身的元数据服务，或者重启节点试试。

• 验证Pod的DNS解析
  先确认Pod能不能正确解析metadata.google.internal这个域名，在Pod里执行：

nslookup metadata.google.internal

如果解析失败，看看集群的DNS服务（coredns）是不是正常：

oc get pods -n openshift-dns

要是DNS Pod状态不对，重启它们就行，或者检查DNS的配置有没有问题。

内容的提问来源于stack exchange，提问作者Talat Shaheen