我们在Google Compute Engine实例上安装了自托管的Gitlab Enterprise。该实例受防火墙保护，因此只有我们的员工才能访问服务器。
当我们部署Kubernetes集群（使用Gitlab CI）时，运行程序无法访问GitLab，因此将无法启动CI作业。
我可以将Google Kubernetes实例的外部IP地址手动添加到我们的GitLab防火墙（允许所选IP范围的所有协议和端口的GCP防火墙），然后它将正常工作。但是因为我们有数量不断变化的Kubernetes实例（以及抢占实例），所以我们必须每天手动进行此操作。
那不是最佳的情况。我已经尝试添加内部IP范围（10.132.0.0/20、10.0.0.0/8、10.56.0.0/14），但这不是解决方案。如果不指定确切的实例IP，跑步者仍然无法访问gitlab服务器。
我想念什么？
答案 0 :(得分：1)
GKE节点在GCE平台中显示为VM实例。它们由主节点管理，如果认为它们不健康，则可以将其删除（由kube-controller删除）。删除后，将重新创建它们。因此，IP地址是短暂的。使用每个VM实例的外部IP地址将非常具有挑战性，因为IP地址一直在变化。这不是可行的解决方案。
一种解决方法是充分利用NAT Gateway。来自GKE节点的所有出站流量都将被路由到充当NAT网关的特定VM实例。这样，您将只有1个静态IP地址，它是NAT Gateway的外部IP地址。
然后，您将具有一个可以添加到防火墙规则的单个静态IP地址。
答案 1 :(得分：0)
三年后，您可能会受益于 GitLab 14.1（2021 年 7 月）
但是，仅适用于高级版和终极版，不适用于免费版：
<块引用>Kubernetes 集群的 CI/CD 隧道
到目前为止，将 Kubernetes 集群连接到 GitLab CI/CD 需要用户向 GitLab 开放他们的集群。
出于安全考虑，一些组织不鼓励对外开放防火墙。
GitLab 现在附带 CI/CD 隧道，该隧道使用 GitLab Kubernetes Agent 将 GitLab Runners 与您的 Kubernetes 集群连接起来。这支持通用的 GitOps 工作流程，其中可以在管道中对部署逻辑进行编码。
您和您的团队可以安全地使用您喜欢的工具来运行部署本身，使用 kubectl、helm、kpt、tanka 或其他任何没有安全问题的东西。
要使用隧道，请在您的 CI/CD 管道中定义 kubecontext 以连接您的代理。为了简化这个过程，我们计划在未来的迭代中automatically inject the kubecontext进入 CI/CD 环境。
CI/CD 隧道目前仅在配置了代理的项目中受支持，但我们正在研究 adding group-level support。您可以安全地开始在 GitLab SaaS 和自我管理实例上使用隧道。
参见 Documentation 和 Epic。