到目前为止，我们一直在对所有工作负载使用GKE公共集群。我们创建了第二个私有群集（仍为GKE），具有更高的安全性和可用性（旧的是单个区域，新的是区域群集）。我们将Gitlab.com用于我们的代码，但在群集中使用了自托管的Gitlab CI运行器。
运行程序在公共群集上运行良好，所有工作负载均已成功完成。但是，在私有群集上，thr CI的所有kubectl命令都以Unable to connect to the server: dial tcp <IP>:443: i/o timeout error失败。 CI配置没有更改-相同的基本映像，仍然使用带有特定于CI的服务帐户的gcloud SDK来对集群进行身份验证。
两个集群都启用了主授权网络，并且仅设置了我们的办公室IP。可以通过公共IP访问Master。身份验证成功，两者均禁用了客户端证书和基本身份验证。配置了Cloud NAT，节点可以访问Internet（可以提取容器映像，Gitlab CI可以连接等）。
我缺少一些重要的配置吗？我还要看什么？
答案 0 :(得分：2)
我已经找到解决问题的方法，但我不确定原因。
我使用了gcloud container clusters get-credentials [CLUSTER_NAME]，它给出了主机的公共端点。但是由于某种原因，无法从群集中访问该地址-因此我认为这将需要将NAT的公共IP（不是静态提供）添加到授权网络中。
我添加了--internal-ip标志，该标志提供了群集的内部IP地址。 CI现在可以连接到主服务器。
来源：https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#internal_ip
tl; dr-gcloud container clusters get-credentials --internal-ip [CLUSTER_NAME]
答案 1 :(得分：0)
如果是gitlab.com，则可以在GKE上的主授权网络中将其IP范围列入白名单。