Help us learn about your current experience with the documentation. Take the survey.

基于 Group 的 Kubernetes 集群（基于证书）（已弃用）

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

此功能在 GitLab 14.5 中已弃用。要将集群连接到 GitLab， 请使用 GitLab agent for Kubernetes。

类似于项目级和 实例级 Kubernetes 集群， group-level Kubernetes 集群允许您将 Kubernetes 集群连接到 您的 group，使您能够在多个项目中使用同一个集群。

要查看您的 group-level Kubernetes 集群：

  1. 在左侧边栏，选择 Search or go to 并找到您的 group。
  2. 选择 Operate > Kubernetes。

集群管理项目

将集群管理项目 附加到您的集群，以管理需要 cluster-admin 权限的共享资源， 用于安装，例如 Ingress 控制器。

RBAC 兼容性

对于每个带有 Kubernetes 集群的 group 下的项目，GitLab 在项目命名空间中创建一个受限的 服务账户，具有 edit 权限。

集群优先级

如果项目的集群可用且未禁用，GitLab 会使用 项目的集群，然后再使用包含该项目的 group 的任何集群。 对于 subgroup，GitLab 会使用项目最近的祖先 group 的集群， 前提是该集群未被禁用。

多个 Kubernetes 集群

您可以将多个 Kubernetes 集群关联到您的 group，并为不同的环境维护不同的集群， 例如开发、预发布和生产。

添加另一个集群时， 设置环境范围 以帮助 区分新集群与其他集群。

GitLab 管理的集群

您可以选择让 GitLab 为您管理集群。如果 GitLab 管理 您的集群，您项目的资源将自动创建。有关 GitLab 为您创建哪些资源的详细信息， 请参阅访问控制部分。

对于非 GitLab 管理的集群，项目特定的资源不会自动创建。如果您正在使用 Auto DevOps 进行部署，且使用的是非 GitLab 管理的集群，您必须确保：

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

清除集群缓存

如果您选择让 GitLab 为您管理集群，GitLab 会存储为其项目创建的命名空间和服务账户的缓存版本。如果您 手动修改集群中的这些资源，此缓存可能与您的集群不同步， 这可能导致部署作业失败。

要清除缓存：

  1. 在左侧边栏，选择 Search or go to 并找到您的 group。
  2. 选择 Operate > Kubernetes。
  3. 选择您的集群。
  4. 展开 Advanced settings。
  5. 选择 Clear cluster cache。

基础域名

集群级别的域名支持多个域名 根据多个 Kubernetes 集群 指定域名时， 这会在 Auto DevOps 阶段自动设置为环境变量（KUBE_INGRESS_BASE_DOMAIN）。

该域名应配置通配符 DNS 到 Ingress IP 地址。更多详情。

环境范围

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

当向您的项目添加多个 Kubernetes 集群时，您需要使用环境范围来区分它们。环境范围将集群与 environments 关联， 类似于环境特定的 CI/CD 变量的工作方式。

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

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

Cluster Environment scope Where
Project * Project
Staging staging/* Project
Production production/* Project
Test test Group
Development * Group

并且 .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/

结果是：

  • Project 集群用于 test 作业。
  • Staging 集群用于 deploy to staging 作业。
  • Production 集群用于 deploy to production 作业。

集群环境

  • Tier: Premium, Ultimate
  • Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

有关哪些 CI environments 部署到 Kubernetes 集群的统一视图，请参阅 cluster environments 文档。

Runner 的安全性

有关安全配置 runners 的重要信息，请参阅 项目级集群的 Security of runners 文档。

更多信息

有关集成 GitLab 和 Kubernetes 的信息，请参阅 Kubernetes clusters。