Kubernetes clusters

• Setting up
  • Adding and removing clusters
  • • Setting the environment scope
• Auto DevOps
• • Deployment variables
  • Integrations
    • Deploy Boards
    • Web terminals
• Monitoring your Kubernetes cluster

Kubernetes clusters

版本历史

• 在项目的 GitLab 10.1 中 .
• 在 GitLab 11.6 中针对组 .
• 在 GitLab 11.11 中引入了 .

使用 GitLab 项目 Kubernetes 集成，您可以：

• Use Review Apps.
• Run .
• 部署您的应用程序.
• 检测和 .
• 与Auto DevOps一起使用.
• Use .
• Use Deploy Boards.
• Use .
• View Logs.
• 在Kubernetes 上运行无服务器工作负载.

除了在项目级别进行集成之外，Kubernetes 集群还可以在或GitLab 实例级别进行集成.

Setting up

GitLab 承诺在任何给定时间至少支持两个生产就绪的 Kubernetes 次要版本. 我们会定期审查我们支持的版本，并提供四个月的弃用期，然后再删除特定版本的支持. 支持的版本范围基于以下方面的评估：

• 我们自己的需求.
• Kubernetes 社区支持的版本.

当前，GitLab 支持以下 Kubernetes 版本：

• 1.16
• 1.15
• 1.14
• 1.13（不建议使用，支持终止于 2020 年 11 月 22 日）
• 1.12（不建议使用，支持终止于 2020 年 9 月 22 日）

注意：某些 GitLab 功能可能支持此处提供的范围之外的版本.

Adding and removing clusters

有关如何执行以下操作的详细信息，请参见添加和删​​除 Kubernetes 集群 ：

• 使用 GitLab 的 UI 在 Google Cloud Platform（GCP）或 Amazon Elastic Kubernetes Service（EKS）中创建集群.
• 从任何 Kubernetes 平台向现有集群添加集成.

Multiple Kubernetes clusters

版本历史

• 在GitLab Premium 10.3 中引入
• 在 13.2 中 GitLab 核心.

您可以将多个 Kubernetes 集群关联到您的项目. 这样，您可以为不同的环境（例如开发，登台，生产等）使用不同的集群.

就像您第一次一样，只需添加另一个集群，并确保设置一个环境范围即可将新集群与其他集群区分开.

Setting the environment scope

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

默认环境范围是 ，这意味着所有作业，无论其环境如何，都将使用该群集. 每个作用域只能由项目中的单个群集使用，否则将发生验证错误. 另外，没有设置环境关键字的作业将无法访问任何群集.

例如，假设项目中存在以下 Kubernetes 集群：

中设置了以下环境：

结果将是：

• The Development cluster details will be available in the deploy to staging job.
• 生产集群详细信息将在deploy to production作业中提供.
• test作业中没有可用的群集详细信息，因为它没有定义任何环境.

将 Kubernetes 群集添加到 GitLab 之后，请阅读本节，其中涵盖了使用 GitLab 配置 Kubernetes 群集的重要注意事项.

Important: The whole cluster security is based on a model where are trusted, so 仅允许受信任的用户控制您的集群.

默认的群集配置授予对成功构建和部署容器化应用程序所需的广泛功能的访问权限. 请记住，群集上运行的所有应用程序都使用相同的凭据.

GitLab-managed clusters

版本历史

• 在 GitLab 11.5 中 .
• 在 GitLab 11.11 中成为可选 .

如果选择管理自己的群集，则不会自动创建特定于项目的资源. 如果使用的是 ，则需要显式提供部署作业将使用的KUBE_NAMESPACE 部署变量 ，否则将为您创建一个名称空间.

Important notes

在 GitLab 和集群上注意以下几点：

• 如果您在群集上安装应用程序 ，即使您选择管理自己的群集，GitLab 也会创建运行这些资源所需的资源.
• 请注意，手动管理由 GitLab 创建的资源（例如名称空间和服务帐户）可能会导致意外错误. 如果发生这种情况，请尝试 .

Clearing the cluster cache

在 GitLab 12.6 中 .

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

清除缓存：

1. 导航到项目的” 操作”>” Kubernetes”页面，然后选择您的集群.
2. 展开高级设置部分.
3. Click Clear cluster cache.

Base domain

在 GitLab 11.8 中 .

注意：使用 GitLab Serverless 时，无需在群集设置上指定基本域. 在这种情况下，域将被指定为 Knative 安装的一部分. 请参阅安装应用程序 .

指定基本域将自动将KUBE_INGRESS_BASE_DOMAIN设置为环境变量. 如果您使用的是 ，则此域将用于不同的阶段. 例如，”自动查看应用程序”和”自动部署”.

该域应将通配符 DNS 配置为入口 IP 地址. 安装 Ingress 之后（请参阅安装应用程序 ），您可以：

• 创建一个指向您的域提供商指向入口 IP 地址的A记录.
• 使用 nip.io 或 xip.io 之类的服务输入通配符 DNS 地址. 例如， 192.168.1.1.xip.io .

Installing applications

GitLab 可以在项目级集群中安装和管理一些应用程序，例如 Helm，GitLab Runner，Ingress，Prometheus 等. 有关为项目集群安装，升级，卸载和故障排除应用程序的更多信息，请参阅GitLab 托管应用程序 .

Auto DevOps 自动检测，构建，测试，部署和监视您的应用程序.

要充分利用 Auto DevOps（自动部署，自动查看应用程序和自动监控），您需要启用 Kubernetes 项目集成.

注意 Kubernetes 群集可以在没有 Auto DevOps 的情况下使用.

Deploying to a Kubernetes cluster

Kubernetes 集群可以作为部署作业的目标. 如果

• 该集群与 GitLab 集成在一起，特殊的可用于您的工作，并且不需要配置. 您可以使用诸如kubectl或helm工具立即开始从作业中与集群进行交互.
• 您无需使用 GitLab 的集群集成，仍然可以将其部署到集群中. 但是，您需要自己使用环境变量配置 Kubernetes 工具，然后才能通过作业与集群进行交互.

Kubernetes 集群集成在 GitLab CI / CD 构建环境中公开了以下 .

注意：在 GitLab 11.5 之前， KUBE_TOKEN是集群集成的主要服务帐户的 Kubernetes 令牌.注意：如果您的集群是在 GitLab 12.2 之前创建的，则默认KUBE_NAMESPACE将设置为<project_name>-<project_id> .

Custom namespace

在 GitLab 12.6 中 .

Kubernetes 集成默认为格式为的特定于项目环境的名称空间（请参阅部署变量 ）.

注意：使用 ，名称空间是在部署之前自动创建的， 无法自定义 .

Integrations

Canary Deployments

利用并在部署板内部可视化您的 Canary 部署，而无需离开 GitLab.

Read more about Canary Deployments

Deploy Boards

GitLab 的部署板提供了 Kubernetes 上运行的每个 CI 环境的当前运行状况和状态的合并视图，显示了部署中 Pod 的状态. 开发人员和其他团队成员可以在已经使用的工作流程中逐个窗格地查看发布的进度和状态，而无需访问 Kubernetes.

Viewing pod logs

使用 GitLab 可以轻松查看连接的 Kubernetes 集群中正在运行的 Pod 的日志. 通过直接在 GitLab 中显示日志，开发人员可以避免管理控制台工具或跳转到其他界面.

Web terminals

在 GitLab 8.15 中引入.

启用后，Kubernetes 集成将为您的添加Web 终端支持. 这基于 Docker 和 Kubernetes 中的exec功能，因此您可以在现有容器中获得一个新的 Shell 会话. 要使用此集成，您应该使用上面的部署变量将其部署到 Kubernetes，并确保对所有部署，副本集和 Pod 进行注释：

• app.gitlab.com/env: $CI_ENVIRONMENT_SLUG
• app.gitlab.com/app: $CI_PROJECT_PATH_SLUG

$CI_ENVIRONMENT_SLUG和$CI_PROJECT_PATH_SLUG是 CI 变量的值.

您必须是项目所有者或拥有maintainer权限才能使用终端. 支持仅限于环境中第一个容器中的第一个容器.

在开始部署作业之前，GitLab 将为部署作业专门创建以下内容：

• 命名空间.
• A service account.

但是，有时 GitLab 无法创建它们. 在这种情况下，您的工作将失败，并显示以下消息：

This job failed because the necessary resources were not successfully created.

要在创建名称空间和服务帐户时查找导致此错误的原因，请检查 .

失败的原因包括：

• 您为 GitLab 提供的令牌没有 GitLab 所需的cluster-admin特权.
• 缺少KUBECONFIG或KUBE_TOKEN变量. 要传递给您的工作，他们必须具有匹配的 . 如果您的作业没有设置environment:name ，则不会通过 Kubernetes 凭据.

注意：从 GitLab 12.0 或更早版本升级的项目级群集可能以导致此错误的方式进行配置. 如果要自己管理名称空间和服务帐户，请确保取消选择由GitLab 管理的群集选项.

自动检测和监控 Kubernetes 指标. 还支持自动监视.

Read more about Kubernetes monitoring

Visualizing cluster health

版本历史

• 在GitLab Ultimate 10.6 中 .