Group-level Kubernetes clusters

原文：https://docs.gitlab.com/ee/user/group/clusters/

• Installing applications
• RBAC compatibility
• Cluster precedence
• Multiple Kubernetes clusters
• GitLab-managed clusters
  • Clearing the cluster cache
• Base domain
• Environment scopes
• Cluster environments
• Security of Runners
• More information

Group-level Kubernetes clusters

在 GitLab 11.6 中引入 .

与项目级和实例级 Kubernetes 集群类似，组级 Kubernetes 集群允许您将 Kubernetes 集群连接到您的组，从而使您可以在多个项目中使用同一集群.

Installing applications

GitLab 可以在您的组级别集群中安装和管理某些应用程序. 有关为您的组集群安装，升级，卸载和故障排除应用程序的更多信息，请参阅GitLab 托管应用程序 .

RBAC compatibility

版本历史

• 在 GitLab 11.4 中引入 .
• 项目名称空间限制是在 GitLab 11.5 中引入的.

对于具有 Kubernetes 集群的组中的每个项目，GitLab 都会在项目名称空间中创建具有edit权限的受限服务帐户.

Cluster precedence

如果项目的群集可用且未禁用，则 GitLab 在使用属于包含该项目的组的任何群集之前，先使用项目的群集. 对于子组，如果未禁用该组，则 GitLab 将使用与项目最接近的祖先组的集群.

Multiple Kubernetes clusters

版本历史

• 在 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 管理的集群，将不会自动创建特定于项目的资源. 如果将Auto DevOps用于具有不受 GitLab 管理的群集的部署，则必须确保：

• 项目的部署服务帐户有权部署到KUBE_NAMESPACE .
• KUBECONFIG正确反映了对KUBE_NAMESPACE任何更改（这不是自动的 ）. 不建议直接编辑KUBE_NAMESPACE .

注意：如果您在群集上安装应用程序 ，即使您选择管理自己的群集，GitLab 也会创建运行它们所需的资源.

Clearing the cluster cache

在 GitLab 12.6 中引入 .

如果您选择允许 GitLab 为您管理集群，则 GitLab 将存储它为项目创建的名称空间和服务帐户的缓存版本. 如果在群集中手动修改这些资源，则此缓存可能与群集不同步，这可能导致部署作业失败.

清除缓存：

1. 导航到您小组的 Kubernetes页面，然后选择您的集群.
2. 展开高级设置部分.
3. Click 清除集群缓存.

Base domain

在 GitLab 11.8 中引入 .

集群级别的域允许每个多个 Kubernetes 集群支持多个域.指定域时，这将在Auto DevOps阶段自动设置为环境变量（ KUBE_INGRESS_BASE_DOMAIN ）.

该域应将通配符 DNS 配置为入口 IP 地址.

Environment scopes

将多个 Kubernetes 集群添加到您的项目时，您需要通过环境范围来区分它们. 环境范围将群集与环境相关联，类似于特定于环境的变量的工作方式.

在评估哪个环境与群集的环境范围匹配时， 群集优先级将生效. 项目级别的集群优先，其次是最接近的祖先组，然后是该组的父级，依此类推.

例如，如果您的项目具有以下 Kubernetes 集群：

.gitlab-ci.yml中设置了以下环境：

stages:
  - test
  - deploy
test:
  stage: test
  script: sh test
deploy to staging:
  stage: deploy
  script: make deploy
  environment:
    name: staging/$CI_COMMIT_REF_NAME
    url: https://staging.example.com/
deploy to production:
  stage: deploy
  script: make deploy
  environment:
    name: production/$CI_COMMIT_REF_NAME
    url: https://example.com/

结果是：

• 项目集群用于test作业.
• 分段群集用于deploy to staging作业.
• 生产集群用于deploy to production作业.

Cluster environments

有关将哪种 CI 环境部署到 Kubernetes 集群的统一视图，请参阅集群环境文档.

Security of Runners

有关安全配置 GitLab Runners 的重要信息，请参阅项目级集群的 Runners 安全性文档.

More information

For information on integrating GitLab and Kubernetes, see Kubernetes clusters.