020.md

# Group-level Kubernetes clusters

> 原文：[https://docs.gitlab.com/ee/user/group/clusters/](https://docs.gitlab.com/ee/user/group/clusters/)

*   [Installing applications](#installing-applications)
*   [RBAC compatibility](#rbac-compatibility)
*   [Cluster precedence](#cluster-precedence)
*   [Multiple Kubernetes clusters](#multiple-kubernetes-clusters)
*   [GitLab-managed clusters](#gitlab-managed-clusters)
    *   [Clearing the cluster cache](#clearing-the-cluster-cache)
*   [Base domain](#base-domain)
*   [Environment scopes](#environment-scopes-premium)
*   [Cluster environments](#cluster-environments-premium)
*   [Security of Runners](#security-of-runners)
*   [More information](#more-information)

# Group-level Kubernetes clusters[](#group-level-kubernetes-clusters "Permalink")

在 GitLab 11.6 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34758) .

与[项目级](../../project/clusters/index.html)和[实例级](../../instance/clusters/index.html) Kubernetes 集群类似，组级 Kubernetes 集群允许您将 Kubernetes 集群连接到您的组，从而使您可以在多个项目中使用同一集群.

## Installing applications[](#installing-applications "Permalink")

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

## RBAC compatibility[](#rbac-compatibility "Permalink")

版本历史

*   在 GitLab 11.4 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/29398) .
*   [项目名称空间限制](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716)是在 GitLab 11.5 中引入的.

对于具有 Kubernetes 集群的组中的每个项目，GitLab 都会在项目名称空间中创建具有[`edit`权限](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)的受限服务帐户.

## Cluster precedence[](#cluster-precedence "Permalink")

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

## Multiple Kubernetes clusters[](#multiple-kubernetes-clusters "Permalink")

版本历史

*   在 13.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35094)了 GitLab Core.

您可以将多个 Kubernetes 集群关联到您的组，并为不同的环境（例如开发，登台和生产）维护不同的集群.

添加另一个群集时，请[设置环境范围](#environment-scopes-premium)以帮助区分新群集和其他群集.

## GitLab-managed clusters[](#gitlab-managed-clusters "Permalink")

版本历史

*   在 GitLab 11.5 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22011) .
*   在 GitLab 11.11 中成为[可选](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26565) .

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](../../project/clusters/add_remove_clusters.html#access-controls) section for details on which resources GitLab creates for you.

对于不受 GitLab 管理的集群，将不会自动创建特定于项目的资源. 如果将[Auto DevOps](../../../topics/autodevops/index.html)用于具有不受 GitLab 管理的群集的部署，则必须确保：

*   项目的部署服务帐户有权部署到[`KUBE_NAMESPACE`](../../project/clusters/index.html#deployment-variables) .
*   `KUBECONFIG`正确反映了对`KUBE_NAMESPACE`任何更改（这[不是自动的](https://gitlab.com/gitlab-org/gitlab/-/issues/31519) ）. 不建议直接编辑`KUBE_NAMESPACE` .

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

### Clearing the cluster cache[](#clearing-the-cluster-cache "Permalink")

在 GitLab 12.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/31759) .

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

清除缓存：

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

## Base domain[](#base-domain "Permalink")

在 GitLab 11.8 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24580) .

集群级别的域允许每个[多个 Kubernetes 集群](#multiple-kubernetes-clusters)支持多个域.指定域时，这将在[Auto DevOps](../../../topics/autodevops/index.html)阶段自动设置为环境变量（ `KUBE_INGRESS_BASE_DOMAIN` ）.

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

## Environment scopes[](#environment-scopes-premium "Permalink")

将多个 Kubernetes 集群添加到您的项目时，您需要通过环境范围来区分它们. 环境范围将群集与[环境](../../../ci/environments/index.html)相关联，类似于[特定](../../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables)于[环境的变量的](../../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables)工作方式.

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

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

| Cluster | 环境范围 | Where |
| --- | --- | --- |
| Project | `*` | Project |
| Staging | `staging/*` | Project |
| Production | `production/*` | Project |
| Test | `test` | Group |
| Development | `*` | Group |

[`.gitlab-ci.yml`](../../../ci/yaml/README.html)中设置了以下环境：

```
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[](#cluster-environments-premium "Permalink")

有关将哪种 CI [环境](../../../ci/environments/index.html)部署到 Kubernetes 集群的统一视图，请参阅[集群环境](../../clusters/environments.html)文档.

## Security of Runners[](#security-of-runners "Permalink")

有关安全配置 GitLab Runners 的重要信息，请参阅项目级集群[的 Runners 安全性](../../project/clusters/add_remove_clusters.html#security-of-gitlab-runners)文档.

## More information[](#more-information "Permalink")

For information on integrating GitLab and Kubernetes, see [Kubernetes clusters](../../project/clusters/index.html).