Group-level Kubernetes clusters
- Installing applications
- Cluster precedence
- GitLab-managed clusters
- Base domain
- Cluster environments
- More information
Group-level Kubernetes clusters
在 GitLab 11.6 中引入 .
与和实例级 Kubernetes 集群类似,组级 Kubernetes 集群允许您将 Kubernetes 集群连接到您的组,从而使您可以在多个项目中使用同一集群.
GitLab 可以在您的组级别集群中安装和管理某些应用程序. 有关为您的组集群安装,升级,卸载和故障排除应用程序的更多信息,请参阅 .
RBAC compatibility
版本历史
- 是在 GitLab 11.5 中引入的.
对于具有 Kubernetes 集群的组中的每个项目,GitLab 都会在项目名称空间中创建具有权限的受限服务帐户.
Cluster precedence
如果项目的群集可用且未禁用,则 GitLab 在使用属于包含该项目的组的任何群集之前,先使用项目的群集. 对于子组,如果未禁用该组,则 GitLab 将使用与项目最接近的祖先组的集群.
版本历史
- 在 13.2 中引入了 GitLab Core.
您可以将多个 Kubernetes 集群关联到您的组,并为不同的环境(例如开发,登台和生产)维护不同的集群.
GitLab-managed clusters
版本历史
- 在 GitLab 11.5 中引入 .
- 在 GitLab 11.11 中成为 .
You can choose to allow GitLab to manage your cluster for you. If GitLab manages your cluster, resources for your projects will be automatically created. See the Access controls section for details on which resources GitLab creates for you.
对于不受 GitLab 管理的集群,将不会自动创建特定于项目的资源. 如果将用于具有不受 GitLab 管理的群集的部署,则必须确保:
- 项目的部署服务帐户有权部署到
KUBE_NAMESPACE
. KUBECONFIG
正确反映了对KUBE_NAMESPACE
任何更改(这 ). 不建议直接编辑KUBE_NAMESPACE
.
注意:如果您在群集上安装应用程序 ,即使您选择管理自己的群集,GitLab 也会创建运行它们所需的资源.
在 GitLab 12.6 中 .
如果您选择允许 GitLab 为您管理集群,则 GitLab 将存储它为项目创建的名称空间和服务帐户的缓存版本. 如果在群集中手动修改这些资源,则此缓存可能与群集不同步,这可能导致部署作业失败.
清除缓存:
- 导航到您小组的 Kubernetes页面,然后选择您的集群.
- 展开高级设置部分.
- Click 清除集群缓存.
Base domain
在 GitLab 11.8 中 .
该域应将通配符 DNS 配置为入口 IP 地址.
将多个 Kubernetes 集群添加到您的项目时,您需要通过环境范围来区分它们. 环境范围将群集与环境相关联,类似于于环境的变量的工作方式.
在评估哪个环境与群集的环境范围匹配时, 将生效. 项目级别的集群优先,其次是最接近的祖先组,然后是该组的父级,依此类推.
例如,如果您的项目具有以下 Kubernetes 集群:
.gitlab-ci.yml
中设置了以下环境:
结果是:
- 项目集群用于
test
作业. - 分段群集用于
deploy to staging
作业.
Cluster environments
有关将哪种 CI 环境部署到 Kubernetes 集群的统一视图,请参阅文档.
Security of Runners
有关安全配置 GitLab Runners 的重要信息,请参阅项目级集群文档.