Gitlab CI Runner 如何在不在批准的 IP 范围内连接 Kubernetes 集群

Question

我有一个 AKS（Azure Kubernetes 服务）集群，在“网络”部分启用了“批准的 IP 地址”，仅允许某些计算机通过 Kubectl API 连接到它

我还有一个 Gitlab 项目，我在其中通过 Gitalb GUI 设置 Kubernetes 集成，从而在我的 AKS 集群上安装了

gitlab-agent

。

我还有一个 Gitlab 运行程序，它设置为 Vnet/子网中的 Linux VM，与我的 K8s 集群所在的 Vnet/子网不同。

“批准的 IP 地址”列表中没有我的 Gitlab 运行程序的 IP 地址，但我的 Gitlab 运行程序仍然能够连接到我的 Kubernetes 集群，并且我无法运行我不期望的

kubectl

命令。

我无法理解一个 Vnet/子网中的 Gitlab 运行程序如何能够与另一个 Vnet/子网中的 Kubernetes 集群连接。

Answer 1

由于您在集群中使用 GitLab 代理，因此您的集群只需要能够访问 GitLab，而不是相反。您的集群与 GitLab 建立连接并通过该建立的连接接收 API 命令。

代理架构设计的一部分是实现与 NAT 或防火墙后面的集群的连接。如将 Kubernetes 集群与 GitLab 连接中所述：

代理在集群中运行，您可以使用它来：

• 与位于防火墙或 NAT 后面的集群进行通信。 [...]

在 GitLab CI/CD 作业中，您通常会使用代理上下文与代理进行通信。这在一定程度上是通过 GitLab 在配置连接的代理时提供的

$KUBECONFIG

变量来启用的：

所有 CI/CD 作业现在都包含一个 kubeconfig 文件，其中包含每个共享代理连接的上下文。 kubeconfig 路径在环境变量

$KUBECONFIG

中可用。选择上下文以从 CI/CD 脚本运行 kubectl 命令。

因此，简而言之，您的 GitLab CI 作业正在利用集群中运行的代理建立的连接，如前所述，即使您的集群位于不允许新的入站连接的 NAT 或防火墙后面，该连接也能正常工作。