当它是一个吊舱时，Gitlab如何使用Kubernetes执行器创建吊舱呢？

Question

嘿，我刚接触过gitlab的CI/CD，有点困惑。

我得到了一个Kubernetes集群，它连接到一个Gitlab实例来运行CI/CD管道。有一个带有kubernetes执行器的gitlab跑步者，据我所知，这意味着有一个运行管道的吊舱。

kubectl get pods -n gitlab-runner支持这一点(现在还有其他问题，但通常是1/1 running)：

NAMESPACE        NAME                                           READY   STATUS    RESTARTS   AGE
gitlab-runner    gitlab-runner-gitlab-runner-6b7bf4d766-9t4k6   0/1     Running   248        29d

CI/CD管道调用像kubectl apply -f [...]这样的命令来创建新的部署和pods。但为什么这样做呢？如果管道命令运行pod，那么修改主机集群配置应该是不可能的，对吗？我以为集装箱化的重点是客人不能改变主人。

我逻辑上的缺陷在哪里？

Answer 1

我认为集装箱化的全部意义是客人不能修改主机。

您忽略了可选地注入到每个Pod中的the serviceAccount，并且那些ServiceAccount对象可以绑定到Role或ClusterRole对象，以可选地授予它们特权来对库中的API操作，该API是在众所周知的DNS地址https://kubernetes.default.svc.cluster.local上在集群中公开的。

所以，是的，它们基本上不能修改主机，但是kubernetes是一个编排引擎，因此GitLab运行程序可以请求在集群中旋转一个新的Pod，只要GitLab运行程序拥有正确的kubernetes凭据，就会像用户请求kubectl执行相同的操作一样严肃对待。

另一种看待这个问题的方法是，如果您在kubernetes之外运行gitlab-runner，但向它提供群集的凭据，那么您就会遇到在现有集群基础结构之外运行另一个VM的问题，同时带来所有的维护负担。