部署面板（已弃用）
- 版本：Free, Premium, Ultimate
- 提供：GitLab.com, GitLab Self-Managed, GitLab Dedicated
在 GitLab 自托管版上，默认情况下此功能不可用。要启用此功能，管理员可以 启用名为 certificate_based_clusters 的功能标志。
GitLab 部署面板提供了在 Kubernetes 上运行的每个 CI 环境 的当前健康状态和状态的统一视图，显示部署中 pod 的状态。开发人员和其他团队成员可以在他们已经使用的工作流程中逐个 pod 查看部署的进度和状态，无需访问 Kubernetes。
如果您有 Kubernetes 集群，可以使用 Auto DevOps 自动将应用程序部署到生产环境。
通过部署面板，您可以更深入地了解部署情况，具有以下优势：
- 从部署开始就跟踪，而不仅仅是在完成时
- 观察构建在多个服务器上的部署过程
- 更详细的状态信息（成功、运行中、失败、等待中、未知）
- 查看 金丝雀部署
以下是生产环境的部署面板示例。
方块代表您 Kubernetes 集群中与给定环境关联的 pod。将鼠标悬停在每个方块上，您可以看到正在部署的部署状态。百分比是更新到最新版本的 pod 的百分比。
部署面板与 Kubernetes 紧密集成，因此您应该熟悉：
使用场景
部署面板是特定环境的 Kubernetes pod 的可视化表示，因此有很多使用场景。举几个例子：
- 您想要将暂存环境中运行的内容提升到生产环境。因此，您前往环境列表，验证暂存环境中运行的内容是否符合您的预期，然后选择 手动作业 部署到生产环境。
- 您触发了一个部署，有很多容器需要升级，您知道这需要一些时间（您还限制了部署速度，每次只停用 X 个容器）。但您需要告诉某人何时部署完成，因此您前往环境列表，查看生产环境，实时查看每个 pod 部署时的进度。
- 您收到报告说生产环境中有异常，因此您查看生产环境，查看正在运行的内容，以及部署是否正在进行、卡住或失败。
- 您有一个看起来不错的 MR，但您想在暂存环境中运行它，因为暂存环境在某些方面设置得更接近生产环境。因此，您前往环境列表，找到您感兴趣的 审查应用，然后选择手动操作将其部署到暂存环境。
启用部署面板
要显示特定 环境 的部署面板，您应该：
-
拥有一个带有部署阶段的 已定义环境。
-
拥有一个正在运行的 Kubernetes 集群。
如果您使用 OpenShift，请确保您使用的是
Deployment资源 而不是DeploymentConfiguration。否则，部署面板将无法正确渲染。有关更多信息，请阅读 OpenShift 文档 和 GitLab 问题 #4584。 -
使用
docker或kubernetesexecutor 配置 GitLab Runner。 -
为集群在您的项目中配置 Kubernetes 集成。Kubernetes namespace 特别重要，因为您需要它 用于您的部署脚本（通过
KUBE_NAMESPACE部署变量暴露）。 -
确保 Kubernetes 注解
app.gitlab.com/env: $CI_ENVIRONMENT_SLUG和app.gitlab.com/app: $CI_PROJECT_PATH_SLUG应用于 部署、副本集和 pod，其中$CI_ENVIRONMENT_SLUG和$CI_PROJECT_PATH_SLUG是 CI/CD 变量的值。这样我们可以在可能有多个环境的集群/命名空间中 查找正确的环境。这些资源应包含在 Kubernetes 服务设置中定义的命名空间内。您可以使用 Auto deploy.gitlab-ci.yml模板，它具有预定义的阶段和命令，并自动 应用注解。每个项目在 Kubernetes 中也必须有一个唯一的命名空间。下图演示了这在 Kubernetes 内部如何显示。如果您使用 GCP 管理集群，可以通过导航到 Workloads > deployment name > Details 在 GCP 本身查看部署详情：
设置完所有上述说明并且管道至少运行一次后， 前往 Operate > Environments 下的环境页面。
部署面板默认可见。您可以明确选择 其各自环境名称旁边的三角形来隐藏它们。
示例清单文件
以下示例是 Kubernetes 清单部署文件的摘录，使用两个注解 app.gitlab.com/env 和 app.gitlab.com/app 来启用 部署面板：
apiVersion: apps/v1
kind: Deployment
metadata:
name: "APPLICATION_NAME"
annotations:
app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}
spec:
replicas: 1
selector:
matchLabels:
app: "APPLICATION_NAME"
template:
metadata:
labels:
app: "APPLICATION_NAME"
annotations:
app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}这些注解应用于部署、副本集和 pod。通过更改副本数量，例如 kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}，您可以从面板上跟踪实例的 pod。
YAML 文件是静态的。如果您使用 kubectl apply 应用它，您必须
手动提供项目和环境 slug，或者创建一个脚本来
在应用前替换 YAML 中的变量。
金丝雀部署
一种流行的 CI 策略，其中将舰队的一小部分更新到您应用程序的新版本。