提交 e7271546 编写于 作者: Lab机器人's avatar Lab机器人

ignore files

上级 fb3bc59c
无法预览此类型文件
_book/
node_modules/
# CODEChina
# 关于CODEChina
欢迎使用CodeChina代码托管平台,本产品基于 Gitlab CE 版本 (13.2 stable) 开发并,目前版本提供了代码仓库管理、组织管理等基本功能,欢迎体验使用。
体验使用过程中如果遇到任何问题,请与我们联系。
### 联系方式
## 联系我们
- [点此向 CODEChina 产品提交 issue](https://codechina.csdn.net/codechina/beta/~/issues)
......
# Summary
* [Introduction](README.md)
* [首页](README.md)
* [概览](docs/002.md)
* [组织](docs/033.md)
此差异已折叠。
# Installation
> 原文:[https://docs.gitlab.com/ee/install/README.html](https://docs.gitlab.com/ee/install/README.html)
* [Requirements](#requirements)
* [Installing GitLab using the Omnibus GitLab package (recommended)](#installing-gitlab-using-the-omnibus-gitlab-package-recommended)
* [Installing GitLab on Kubernetes via the GitLab Helm charts](#installing-gitlab-on-kubernetes-via-the-gitlab-helm-charts)
* [Installing GitLab with Docker](#installing-gitlab-with-docker)
* [Installing GitLab from source](#installing-gitlab-from-source)
* [Installing GitLab on cloud providers](#installing-gitlab-on-cloud-providers)
* [Securing your GitLab installation](#securing-your-gitlab-installation)
# Installation[](#installation-core-only "Permalink")
GitLab 可以安装在大多数 GNU / Linux 发行版以及许多云提供商中. 为了从 GitLab 获得最佳体验,您需要在性能,可靠性,易于管理(备份,升级和故障排除)以及托管成本之间取得平衡.
根据平台的不同,可以通过多种方式安装 GitLab:
1. **Omnibus GitLab** :官方的 deb / rpm 软件包,包含捆绑的 GitLab 及其依赖的各种组件,例如 PostgreSQL,Redis,Sidekiq 等.
2. **GitLab Helm 图表** :用于在 Kubernetes 上安装 GitLab 及其所有组件的云原生 Helm 图表.
3. **码头**工人:Omnibus GitLab 软件包码头化.
4. **来源** :从头开始安装 GitLab 及其所有组件.
**如有疑问,请选择 Omnibus:** Omnibus GitLab 软件包已经成熟, [可扩展,](../administration/reference_architectures/index.html)并且已在 GitLab.com 上使用. 建议向熟悉 Kubernetes 的人使用 Helm 图表.
## Requirements[](#requirements "Permalink")
在安装 GitLab 之前,查看系统[要求](requirements.html)至关重要. 系统要求包括有关最低硬件,软件,数据库以及支持 GitLab 的其他要求的详细信息.
## Installing GitLab using the Omnibus GitLab package (recommended)[](#installing-gitlab-using-the-omnibus-gitlab-package-recommended "Permalink")
Omnibus GitLab 软件包使用我们的官方 deb / rpm 存储库. 建议大多数用户使用.
如果您需要更多的灵活性和弹性,我们建议按照[参考架构文档](../administration/reference_architectures/index.html)中的[说明](../administration/reference_architectures/index.html)部署 GitLab.
[**> Install GitLab using the Omnibus GitLab package.**](https://about.gitlab.com/install/)
## Installing GitLab on Kubernetes via the GitLab Helm charts[](#installing-gitlab-on-kubernetes-via-the-gitlab-helm-charts "Permalink")
**需要 Kubernetes 经验:**我们建议您先熟悉 Kubernetes,然后再使用 Kubernetes 在生产中部署 GitLab. 管理,可观察性和某些概念的方法与传统部署不同.
在 Kubernetes 上安装 GitLab 时,需要注意一些折衷:
* 管理和故障排除需要 Kubernetes 知识.
* 对于较小的安装,它可能会更昂贵. 默认安装比单节点 Omnibus 部署需要更多的资源,因为大多数服务都是以冗余方式部署的.
* 有一些功能[限制需要注意](https://docs.gitlab.com/charts/) .
[**> Install GitLab on Kubernetes using the GitLab Helm charts.**](https://docs.gitlab.com/charts/)
## Installing GitLab with Docker[](#installing-gitlab-with-docker "Permalink")
GitLab 基于 Omnibus GitLab 软件包维护一组正式的 Docker 映像.
[**> Install GitLab using the official GitLab Docker images.**](docker.html)
## Installing GitLab from source[](#installing-gitlab-from-source "Permalink")
如果您的发行版中没有 Omnibus GitLab 软件包,则可以从源代码安装 GitLab:对于* BSD 等不受支持的系统很有用. 有关目录结构的概述,请阅读[结构文档](structure.html) .
[**> Install GitLab from source.**](installation.html)
## Installing GitLab on cloud providers[](#installing-gitlab-on-cloud-providers "Permalink")
只要有云提供商支持,就可以使用上述任何一种方法将 GitLab 安装在各种云提供商上.
* [在 AWS 上](aws/index.html)安装:使用 GitLab 提供的社区 AMI 在 AWS [](aws/index.html)安装 Omnibus GitLab.
* [在 Google Cloud Platform 上安装 GitLab](google_cloud_platform/index.html) :在 GCP 中的 VM 上安装 Omnibus GitLab.
* [在 Azure 上](azure/index.html)安装 GitLab:从 Azure 市场安装 Omnibus GitLab.
* [在 OpenShift 上](https://docs.gitlab.com/charts/installation/cloud/openshift.html)安装 GitLab:通过使用 GitLab 的 Helm 图表在 OpenShift [](https://docs.gitlab.com/charts/installation/cloud/openshift.html)安装 GitLab.
* [在 DC / OS 上](https://d2iq.com/blog/gitlab-dcos)安装 GitLab:通过[GitLab-Mesosphere 集成](https://about.gitlab.com/blog/2016/09/16/announcing-gitlab-and-mesosphere/)在 Mesosphere DC / OS 上安装 GitLab.
* [在 DigitalOcean 上安装 GitLab:在 DigitalOcean 上](https://about.gitlab.com/blog/2016/04/27/getting-started-with-gitlab-and-digitalocean/)安装 Omnibus GitLab.
* *仅测试!* [DigitalOcean 和 Docker Machine](digitaloceandocker.html) :使用 Docker Machine 在 DigitalOcean 上快速测试任何版本的 GitLab.
## Securing your GitLab installation[](#securing-your-gitlab-installation "Permalink")
完成安装后,请查看我们[建议的做法以保护您的 GitLab 实例](../security/README.html#securing-your-gitlab-installation) .
\ No newline at end of file
# Requirements
> 原文:[https://docs.gitlab.com/ee/install/requirements.html](https://docs.gitlab.com/ee/install/requirements.html)
* [Operating Systems](#operating-systems)
* [Supported Linux distributions](#supported-linux-distributions)
* [Unsupported Linux distributions and Unix-like operating systems](#unsupported-linux-distributions-and-unix-like-operating-systems)
* [Microsoft Windows](#microsoft-windows)
* [Software requirements](#software-requirements)
* [Ruby versions](#ruby-versions)
* [Go versions](#go-versions)
* [Git versions](#git-versions)
* [Node.js versions](#nodejs-versions)
* [Redis versions](#redis-versions)
* [Hardware requirements](#hardware-requirements)
* [Storage](#storage)
* [CPU](#cpu)
* [Memory](#memory)
* [Database](#database)
* [PostgreSQL Requirements](#postgresql-requirements)
* [Additional requirements for GitLab Geo](#additional-requirements-for-gitlab-geo)
* [Puma settings](#puma-settings)
* [Puma workers](#puma-workers)
* [Puma threads](#puma-threads)
* [Unicorn Workers](#unicorn-workers)
* [Redis and Sidekiq](#redis-and-sidekiq)
* [Prometheus and its exporters](#prometheus-and-its-exporters)
* [GitLab Runner](#gitlab-runner)
* [Supported web browsers](#supported-web-browsers)
# Requirements[](#requirements "Permalink")
该页面包含有关受支持的操作系统以及安装和使用 GitLab 所需的硬件要求的有用信息.
## Operating Systems[](#operating-systems "Permalink")
### Supported Linux distributions[](#supported-linux-distributions "Permalink")
* Ubuntu(16.04 / 18.04)
* Debian(8/9/10)
* CentOS 的(6/7/8)
* openSUSE(Leap 15.1 / Enterprise Server 12.2)
* 红帽企业版 Linux(请使用 CentOS 软件包和说明)
* 科学版 Linux(请使用 CentOS 软件包和说明)
* Oracle Linux(请使用 CentOS 软件包和说明)
有关安装选项,请参见[主要安装页面](README.html) .
### Unsupported Linux distributions and Unix-like operating systems[](#unsupported-linux-distributions-and-unix-like-operating-systems "Permalink")
* Arch Linux
* Fedora
* FreeBSD
* Gentoo
* macOS
可以在这些操作系统上安装 GitLab,但不支持. 请参阅[源安装指南](installation.html)[安装指南](https://about.gitlab.com/install/)以获取更多信息.
### Microsoft Windows[](#microsoft-windows "Permalink")
GitLab 是针对基于 Linux 的操作系统开发的. 它**不能**在 Microsoft Windows 上运行,并且我们没有计划在不久的将来支持它. 有关最新的开发状态,请查看此[问题](https://gitlab.com/gitlab-org/gitlab/-/issues/22337) . 请考虑使用虚拟机运行 GitLab.
## Software requirements[](#software-requirements "Permalink")
### Ruby versions[](#ruby-versions "Permalink")
GitLab 需要 Ruby(MRI)2.6\. 从 GitLab 12.2 开始,我们不再支持 Ruby 2.5 及更低版本.
您必须使用 Ruby 的标准 MRI 实现. 我们喜欢[JRuby](https://www.jruby.org/)[Rubinius](https://github.com/rubinius/rubinius#the-rubinius-language-platform) ,但是 GitLab 需要几个具有本机扩展的 Gems.
### Go versions[](#go-versions "Permalink")
所需的最低 Go 版本为 1.13.
### Git versions[](#git-versions "Permalink")
从 GitLab 13.1:
* 需要 Git 2.25.x 及更高版本.
* [建议使用](https://gitlab.com/gitlab-org/gitaly/-/issues/2829) Git 2.27.x 及更高版本.
### Node.js versions[](#nodejs-versions "Permalink")
从 GitLab 12.9 开始,我们仅支持 node.js 10.13.0 或更高版本,并且我们放弃了对 node.js 8 的支持.(在 GitLab 11.8 中取消了对 node.js 6 的支持).
我们建议使用 Node 12.x,因为它速度更快.
GitLab 使用[Webpack](https://webpack.js.org/)编译前端资产,这需要最低版本的 Node.js 10.13.0.
您可以使用`node -v`检查您正在运行哪个版本. 如果您运行的版本低于`v10.13.0` ,则需要将其更新为较新的版本. 您可以在[Node.js 网站上](https://s0nodejs0org.icopy.site/en/download/)找到从社区维护的软件包安装或从源代码进行编译的[说明](https://s0nodejs0org.icopy.site/en/download/) .
## Redis versions[](#redis-versions "Permalink")
GitLab 需要 Redis 5.0+. 从 GitLab 13.0 开始,不支持较低版本.
## Hardware requirements[](#hardware-requirements "Permalink")
### Storage[](#storage "Permalink")
所需的硬盘空间在很大程度上取决于要存储在 GitLab 中的存储库的大小,但是根据*经验,*您应该至少具有与所有存储库加起来一样大的可用空间.
如果您将来想灵活地增加硬盘驱动器空间,请考虑使用[逻辑卷管理(LVM)进行](https://en.wikipedia.org/wiki/Logical_volume_management)安装,以便在需要时可以添加更多硬盘驱动器.
除本地硬盘驱动器外,您还可以安装支持网络文件系统(NFS)协议的卷. 该卷可能位于文件服务器,网络连接存储(NAS)设备,存储区域网络(SAN)或 Amazon Web Services(AWS)弹性块存储(EBS)卷上.
如果您有足够的 RAM 和最新的 CPU,则 GitLab 的速度主要受硬盘搜索时间限制. 具有快速驱动器(7200 RPM 及更高版本)或固态驱动器(SSD)将提高 GitLab 的响应速度.
**注意:**由于文件系统性能可能会影响 GitLab 的整体性能,因此[我们不建议使用 AWS EFS 进行存储](../administration/high_availability/nfs.html#avoid-using-awss-elastic-file-system-efs) .
### CPU[](#cpu "Permalink")
CPU 需求取决于用户数量和预期的工作量. 您的确切需求可能更多,具体取决于您的工作量. 您的工作负载受以下因素影响,这些因素包括但不限于:用户的活跃程度,使用的自动化程度,镜像和回购/更改大小.
以下是一些示例 GitLab 用户库大小的建议最低 CPU 硬件指南.
* **4 芯**是核心的**推荐**最小数目和多达 500 个用户支持
* 8 个内核最多支持 1000 个用户
* 更多用户? 查阅[参考架构页面](../administration/reference_architectures/index.html)
### Memory[](#memory "Permalink")
内存需求取决于用户数量和预期的工作量. 您的确切需求可能更多,具体取决于您的工作量. 您的工作负载受以下因素影响,这些因素包括但不限于:用户的活跃程度,使用的自动化程度,镜像和回购/更改大小.
以下是一些示例 GitLab 用户库大小的建议最低内存硬件指南.
* **4GB RAM****必需的**最小内存大小,最多可支持 500 个用户
* 我们的[内存团队](https://about.gitlab.com/handbook/engineering/development/enablement/memory/)正在努力减少内存需求.
* 8GB RAM 最多支持 1000 个用户
* 更多用户? 查阅[参考架构页面](../administration/reference_architectures/index.html)
除上述之外,即使您当前有足够的可用 RAM,我们通常也建议在服务器上至少有 2GB 的交换空间. 如果您的可用内存发生更改,那么进行交换将有助于减少发生错误的机会. 我们还建议将内核的 swappiness 设置配置为较低的值(例如`10`以充分利用您的 RAM,同时在需要时仍可使用交换功能.
## Database[](#database "Permalink")
PostgreSQL 是唯一受支持的数据库,与 Omnibus GitLab 软件包捆绑在一起. 您也可以使用[外部 PostgreSQL 数据库](https://docs.gitlab.com/omnibus/settings/database.html) . 在 GitLab 12.1 中删除了对 MySQL 的支持. 建议在 MySQL / MariaDB 上使用 GitLab 的现有用户在升级之前[迁移到 PostgreSQL](../update/mysql_to_postgresql.html) .
### PostgreSQL Requirements[](#postgresql-requirements "Permalink")
运行 PostgreSQL 的服务器应*至少有* 5-10 GB 的可用存储空间,尽管确切的要求[取决于用户数量](../administration/reference_architectures/index.html) .
我们强烈建议用户使用下面指定的最低 PostgreSQL 版本,因为这些是用于开发和测试的版本.
| GitLab 版本 | 最低 PostgreSQL 版本 |
| --- | --- |
| 10.0 | 9.6 |
| 12.10 | 11 |
| 13.0 | 11 |
您还必须确保将`pg_trgm`扩展加载到每个 GitLab 数据库中. [可以](https://s0www0postgresql0org.icopy.site/docs/11/sql-createextension.html)使用 PostgreSQL 超级用户[启用](https://s0www0postgresql0org.icopy.site/docs/11/sql-createextension.html)此扩展.
在某些系统上,您可能需要安装一个附加软件包(例如`postgresql-contrib` ),此扩展才可以使用.
**注意:** [在 GitLab 13.0 中已删除了](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#postgresql-11-is-now-the-minimum-required-version-to-install-gitlab)[PostgreSQL 9.6 和 10 的](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#postgresql-11-is-now-the-minimum-required-version-to-install-gitlab)支持,因此 GitLab 可以从 PostgreSQL 11 的改进(例如分区)中受益. 有关过渡到 PostgreSQL 12 的时间表,请参阅[相关的 epic](https://gitlab.com/groups/gitlab-org/-/epics/2184) .
#### Additional requirements for GitLab Geo[](#additional-requirements-for-gitlab-geo "Permalink")
如果您使用的是[GitLab Geo](../administration/geo/replication/index.html)
* 我们强烈建议您在积极开发和测试的情况下运行由 Omnibus 管理的实例. 我们的目标是与大多数外部数据库(不由 Omnibus 管理)兼容(例如, [AWS Relational Database Service(RDS)](https://aws.amazon.com/rds/) ),但我们不保证兼容性.
* 您还必须确保将`postgres_fdw`扩展加载到每个 GitLab 数据库中. [可以](https://s0www0postgresql0org.icopy.site/docs/11/sql-createextension.html)使用 PostgreSQL 超级用户[启用](https://s0www0postgresql0org.icopy.site/docs/11/sql-createextension.html)此扩展.
## Puma settings[](#puma-settings "Permalink")
建议的 Puma 设置取决于运行它的基础结构. Omnibus GitLab 默认为建议的 Puma 设置. 无论安装方法如何,都可以调整 Puma 设置.
如果您使用的是 Omnibus GitLab,请参阅[Puma 设置](https://docs.gitlab.com/omnibus/settings/puma.html)以获取有关更改 Puma 设置的说明. 如果您使用的是 GitLab Helm 图表,请参阅[Webservice 图表](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html) .
### Puma workers[](#puma-workers "Permalink")
推荐的工人人数是根据以下最高者计算得出的:
* `2`
* CPU 核心数-1
例如,一个具有 4 个核心的节点应配置 3 个 Puma Worker.
如果可以提供足够的 CPU 和内存容量,则可以增加 Puma worker 的数量. 数量更多的 Puma 工作人员通常将有助于减少应用程序的响应时间并提高处理并行请求的能力. 您必须执行测试以验证基础架构的最佳设置.
### Puma threads[](#puma-threads "Permalink")
推荐的线程数取决于几个因素,包括总内存和[传统 Rugged 代码的使用](../development/gitaly.html#legacy-rugged-code) .
* 如果操作系统最多具有 2 GB 的内存,则建议的线程数为`1` . 较高的值将导致过多的交换,并降低性能.
* If legacy Rugged code is in use, the recommended number of threads is `1`.
* 在所有其他情况下,建议的线程数为`4` . 由于[Ruby MRI 多线程的](https://en.wikipedia.org/wiki/Global_interpreter_lock)工作方式,我们不建议设置更高的值.
## Unicorn Workers[](#unicorn-workers "Permalink")
对于大多数情况,我们建议使用:(CPU 内核* 1.5)+ 1 = Unicorn worker. 例如,一个具有 4 个核心的节点将有 7 个 Unicorn worker.
对于所有 2GB 以上的计算机,我们建议至少三名 Unicorn 工人. 如果您有一台 1GB 的计算机,我们建议仅配置两个 Unicorn worker,以防止过度交换.
只要您有足够的可用 CPU 和内存容量,就可以增加 Unicorn worker 的数量,这通常将有助于减少应用程序的响应时间并提高处理并行请求的能力.
要在拥有 Omnibus 软件包(默认为上述建议)时更改 Unicorn worker,请参阅[Omnibus GitLab 文档中的 Unicorn 设置](https://docs.gitlab.com/omnibus/settings/unicorn.html) .
## Redis and Sidekiq[](#redis-and-sidekiq "Permalink")
Redis 存储所有用户会话和后台任务队列. Redis 的存储要求极低,每个用户大约 25kB. Sidekiq 使用多线程进程来处理后台作业. 此过程从整个 Rails 堆栈(200MB +)开始,但是由于内存泄漏,它可能随着时间的推移而增长. 在非常活跃的服务器(10,000 个活跃用户)上,Sidekiq 进程可以使用 1GB +的内存.
## Prometheus and its exporters[](#prometheus-and-its-exporters "Permalink")
从 Omnibus GitLab 9.0 起,默认启用[Prometheus](https://s0prometheus0io.icopy.site)及其相关出口商,以实现对 GitLab 的轻松和深度监控. 使用默认设置,这些进程将消耗大约 200MB 的内存.
如果您想禁用 Prometheus 及其出口商或阅读有关它的更多信息,请查阅[Prometheus 文档](../administration/monitoring/prometheus/index.html) .
## GitLab Runner[](#gitlab-runner "Permalink")
强烈建议不要在打算安装 GitLab 的同一台计算机上安装 GitLab Runner. 根据您决定配置 GitLab Runner 的方式以及用于在 CI 环境中运行应用程序的工具的不同,GitLab Runner 会消耗大量可用内存.
如果您决定在同一台计算机上运行 GitLab Runner 和 GitLab Rails 应用程序,则上面提供的内存消耗计算将无效.
由于[安全原因](https://docs.gitlab.com/runner/security/) ,将所有内容都安装在一台机器上也不安全,尤其是当您计划将 Shell executor 与 GitLab Runner 一起使用时.
如果您打算使用 CI 功能,我们建议为每个 GitLab Runner 使用单独的机器. GitLab Runner 服务器要求取决于:
* 您在 GitLab Runner 上配置的[执行程序](https://docs.gitlab.com/runner/executors/)的类型.
* 运行构建作业所需的资源.
* 作业并发设置.
由于作业的性质因每个用例而异,因此您将需要通过调整作业并发来进行实验以获得最佳设置.
作为参考,对 GitLab.com 的[自动缩放共享](../user/gitlab_com/index.html#shared-runners)运行器进行了配置,以便**单个作业**将在**单个实例中**运行,并具有:
* 1vCPU.
* 3.75GB 的 RAM.
## Supported web browsers[](#supported-web-browsers "Permalink")
**警告:**在 GitLab 13.0(2020 年 5 月)中,我们删除了对 Internet Explorer 11 的官方支持.在 GitLab 13.4 发行版(2020 年 9 月)中,我们将删除了所有支持 Internet Explorer 11 的代码.您可以提供[有关此问题的](https://gitlab.com/gitlab-org/gitlab/-/issues/197987)反馈[](https://gitlab.com/gitlab-org/gitlab/-/issues/197987)也可以通过通常的支持渠道.
GitLab supports the following web browsers:
* [Mozilla Firefox](https://www.mozilla.org/en-US/firefox/new/)
* [Google Chrome](https://www.google.com/chrome/)
* [Chromium](https://www.chromium.org/getting-involved/dev-channel)
* [Apple Safari](https://www.apple.com/safari/)
* [Microsoft Edge](https://www.microsoft.com/en-us/edge)
对于列出的 Web 浏览器,GitLab 支持:
* 当前和以前的主要浏览器版本(Internet Explorer 除外).
* 受支持的主要版本的当前次要版本.
**注意:**我们不支持在浏览器中禁用 JavaScript 的情况下运行 GitLab,并且将来也没有支持该计划的计划,因为我们具有诸如 Issue Boards 之类的功能,这些功能广泛需要 JavaScript.
\ No newline at end of file
> 原文:[https://about.gitlab.com/install/](https://about.gitlab.com/install/)
\ No newline at end of file
# GitLab cloud native Helm Chart
> 原文:[https://docs.gitlab.com/charts/](https://docs.gitlab.com/charts/)
* [Introduction](#introduction)
* [Limitations](#limitations)
* [GitLab Helm chart quick start guide](#gitlab-helm-chart-quick-start-guide)
* [Troubleshooting](#troubleshooting)
* [Installation](#installation)
* [Global settings](#global-settings)
* [Complete properties list](#complete-properties-list)
* [Upgrading](#upgrading)
* [Uninstall](#uninstall)
* [Advanced](#advanced)
* [Advanced Configuration](#advanced-configuration)
* [Migrate from Omnibus GitLab to Kubernetes](#migrate-from-omnibus-gitlab-to-kubernetes)
* [Architecture](#architecture)
* [Development](#development)
* [GitLab version mappings](#gitlab-version-mappings)
* [Contributing](#contributing)
# GitLab cloud native Helm Chart[](#gitlab-cloud-native-helm-chart "Permalink")
这是在云本机环境上安装 GitLab 的官方,推荐和受支持的方法.
**注意:**不必在 Kubernetes 上安装 GitLab 即可使用[GitLab Kubernetes 集成](https://docs.gitlab.com/ee/user/project/clusters/) .
## Introduction[](#introduction "Permalink")
The `gitlab/gitlab` chart is the best way to operate GitLab on Kubernetes. This chart contains all the required components to get started, and can scale to large deployments.
该图表包括完整的体验所需的所有组件,但是每个部分都可以单独安装.
* GitLab 核心组件:
* [NGINX 入口](charts/nginx/index.html)
* [登记处](charts/registry/index.html)
* [亚搏体育 app](charts/gitlab/gitaly/index.html) / [Gitaly](charts/gitlab/gitaly/index.html)
* GitLab / [GitLab 出口商](charts/gitlab/gitlab-exporter/index.html)
* GitLab / [GitLab Grafana](charts/gitlab/gitlab-grafana/index.html)
* GitLab / [GitLab 外壳](charts/gitlab/gitlab-shell/index.html)
* GitLab / [迁移](charts/gitlab/migrations/index.html)
* [亚搏体育 app](charts/gitlab/sidekiq/index.html) / [Sidekiq](charts/gitlab/sidekiq/index.html)
* GitLab / [web 服务](charts/gitlab/webservice/index.html)
* 可选依赖项:
* [PostgreSQL 的](https://hub.helm.sh/charts/bitnami/postgresql)
* [雷迪斯](https://hub.helm.sh/charts/bitnami/redis)
* [MinIO](charts/minio/index.html)
* 可选的补充:
* [普罗米修斯](https://hub.helm.sh/charts/stable/prometheus)
* [格拉法纳](https://hub.helm.sh/charts/stable/grafana)
* 使用 Kubernetes 执行器的[*非特权*](https://docs.gitlab.com/runner/install/kubernetes.html) [GitLab Runner](https://docs.gitlab.com/runner/)
* 使用[Jetstack](https://www.jetstack.io/)[cert-manager](https://cert-manager.io/docs/)通过[Let's Encrypt](https://letsencrypt.org/)自动提供 SSL
## Limitations[](#limitations "Permalink")
使用 Helm 图表当前无法使用 GitLab 的某些功能:
* [GitLab Pages](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/37)
* [Smartcard authentication](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/988)
数据库限制:
* GitLab Geo 功能[需要使用外部数据库服务](installation/deployment.html#postgresql) .
## GitLab Helm chart quick start guide[](#gitlab-helm-chart-quick-start-guide "Permalink")
对于那些希望在*非生产*用例中尽快建立并运行这些图表的人,我们提供了概念验证(PoC)部署[快速入门指南](quickstart/index.html) .
本指南将通过部署这些图表使用默认值和功能引导用户,但*不*符合生产做好准备的要求. 如果希望在持续负载下将这些图表部署到生产中,则应遵循以下完整的[安装指南](#installation) .
## Troubleshooting[](#troubleshooting "Permalink")
我们已尽力使这些图表尽可能地无缝,但偶尔也会出现无法控制的问题. 我们已收集了一些常见问题的疑难解答技巧. 在提出[问题](https://gitlab.com/gitlab-org/charts/gitlab/-/issues)之前,请先检查这些内容,并通过提出[合并请求](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests)随意添加它们!
See [Troubleshooting](troubleshooting/index.html).
## Installation[](#installation "Permalink")
`gitlab/gitlab`图表包含所有必需的依赖项. 在生产中,您可能需要启用可选功能或[高级配置](#advanced-configuration) . 本指南深入介绍了这些图表的所有选项和功能.
如果您只是想部署概念验证进行测试,我们强烈建议您遵循我们的[快速入门](#gitlab-helm-chart-quick-start-guide)进行第一次迭代.
1. [Preparation](installation/index.html)
2. [Deployment](installation/deployment.html)
### Global settings[](#global-settings "Permalink")
这些图表的复杂性使其可以使用全局属性. 有许多通用全局设置适用于多个图表. 有关不同的全局配置值及其应用程序的详细信息,请参见[Globals 文档](charts/globals.html) .
### Complete properties list[](#complete-properties-list "Permalink")
经常要求我们将所有可能的属性表直接放入此索引. 这些图表是规模*庞大* ,并作为属性的这种数量超过背景的量,我们在这里很舒服配售. 请参阅我们(几乎) [全面的属性和默认值列表](installation/command-line-options.html) .
## Upgrading[](#upgrading "Permalink")
安装了 GitLab 图表后,应使用`helm upgrade`完成配置更改和图表更新:
```
helm repo add gitlab https://charts.gitlab.io/
helm repo update
helm get values gitlab > gitlab.yaml
helm upgrade gitlab gitlab/gitlab -f gitlab.yaml
```
有关更多详细信息,请参阅[升级](installation/upgrade.html) .
## Uninstall[](#uninstall "Permalink")
要卸载 GitLab Chart,请运行以下命令:
```
helm uninstall gitlab
```
**注意:**在 Helm v2 中,您需要使用`helm delete --purge gitlab`命令.
为了连续起见,这些图表具有一些在执行`helm uninstall`时不会删除的 Kubernetes 对象. 这些是我们要求您有*意识地*删除的项目,因为它们会影响您应选择的重新部署.
* 用于状态数据的 PVC,必须*自觉*删除
* Gitaly:这是您的存储库数据.
* PostgreSQL(如果内部):这是您的元数据.
* Redis(如果内部):这是缓存和作业队列,可以安全地将其删除.
* 机密(如果由我们的共享机密工作生成). 这些图表旨在避免直接通过 Helm 生成 Kubernetes 秘密. 因此,Helm 无法删除它们. 它们包含密码,加密机密等.它们不应被恶意破坏.
* ConfigMaps
* `ingress-controller-leader-RELEASE-nginx` :这是由 NGINX Ingress 控制器本身生成的,不在我们图表的控制范围内. 可以安全地将其删除.
PVC 和秘密将设置`release`标签,因此您可以通过以下方式找到它们:
```
kubectl get pvc,secret -lrelease=gitlab
```
## Advanced[](#advanced "Permalink")
除了在云本机环境中进行 GitLab 的基本部署以外,还可以进行更复杂的配置. 本节为需要进一步计划的任务提供指导,例如大规模部署或从 Omnibus GitLab 迁移.
### Advanced Configuration[](#advanced-configuration "Permalink")
高级和大规模部署具有利用外部服务,扩展功能和备用提供程序的能力.
高级配置示例:
* 亚搏体育 app Geo
* 外部对象存储提供者
* 外部 PostgreSQL,Redis,Gitaly
* 外部入口提供商
See [Advanced Configuration](advanced/index.html).
### Migrate from Omnibus GitLab to Kubernetes[](#migrate-from-omnibus-gitlab-to-kubernetes "Permalink")
可以从[Omnibus GitLab](https://docs.gitlab.com/omnibus/)迁移到这些图表. 这样做通常需要将现有数据迁移到对象存储,因此是[高级配置](advanced/index.html) .
要将现有的 Omnibus GitLab 实例迁移到这些图表,请遵循[迁移文档](installation/migration/index.html) .
## Architecture[](#architecture "Permalink")
这些图表非常复杂,因为它们可以协调整个应用程序套件的部署. 我们提供有关目标,结构,设计决策和资源消耗的[文档](architecture/index.html) .
## Development[](#development "Permalink")
对于那些有兴趣为这些图表做出贡献的人,我们提供了涵盖该项目工作范围的开发指南. 它们可以在[开发中](development/index.html) .
### GitLab version mappings[](#gitlab-version-mappings "Permalink")
GitLab 图表与 GitLab 本身的版本号不同. 预计可能需要在图表中引入一些重大更改,这些更改可能会导致重大版本颠簸,而对这些更改的要求可能会完全阻止这些图表上的其他开发,直到完成为止.
要快速查看它们映射到的`gitlab`图表版本和 GitLab 版本的完整列表,请对[Helm](installation/tools.html#helm)发出以下命令:
```
helm repo add gitlab https://charts.gitlab.io/
helm search repo -l gitlab/gitlab
```
**注意**对于 Helm v2,搜索命令将为`helm search -l gitlab/gitlab`
有关更多信息,请访问[版本映射 docs](installation/version_mappings.html) .
### Contributing[](#contributing "Permalink")
除了我们的[贡献准则](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/CONTRIBUTING.md)之外,请参阅[开发者文档](development/index.html)以了解如何对 GitLab 图表[做出贡献](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/CONTRIBUTING.md) .
\ No newline at end of file
# Install GitLab with Docker
> 原文:[https://docs.gitlab.com/ee/install/docker.html](https://docs.gitlab.com/ee/install/docker.html)
* [Omnibus GitLab based images](#omnibus-gitlab-based-images)
* [Cloud native images](#cloud-native-images)
# Install GitLab with Docker[](#install-gitlab-with-docker "Permalink")
在过去的几年中, [Docker](https://www.docker.com)和容器技术一直在改变软件世界. 它们将本地执行的性能和效率与虚拟化的抽象性,安全性和不变性结合在一起.
GitLab 提供了官方的 Docker 映像,使您可以在操作 GitLab 实例时轻松利用容器化的优势.
## Omnibus GitLab based images[](#omnibus-gitlab-based-images "Permalink")
GitLab 基于我们的[Omnibus GitLab 软件包](https://docs.gitlab.com/omnibus/README.html)维护了一组[正式的 Docker 映像](https://hub.docker.com/u/gitlab) . 这些图像包括:
* [GitLab Community Edition](https://hub.docker.com/r/gitlab/gitlab-ce/)
* [GitLab Enterprise Edition](https://hub.docker.com/r/gitlab/gitlab-ee/)
* [GitLab Runner](https://hub.docker.com/r/gitlab/gitlab-runner/)
提供了有关这些映像的[完整用法指南](https://docs.gitlab.com/omnibus/docker/) ,以及[用于构建映像](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/docker)[Dockerfile](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/docker) .
## Cloud native images[](#cloud-native-images "Permalink")
manbetx 客户端打不开也正在努力向[容器](https://docs.gitlab.com/charts/)[云本机集,](https://docs.gitlab.com/charts/)每个组件服务具有单个映像. 我们打算将这些图像最终替换为[基于 Omnibus GitLab 的图像](#omnibus-gitlab-based-images) .
\ No newline at end of file
此差异已折叠。
此差异已折叠。
# Installing GitLab on Google Cloud Platform
> 原文:[https://docs.gitlab.com/ee/install/google_cloud_platform/](https://docs.gitlab.com/ee/install/google_cloud_platform/)
* [Prerequisites](#prerequisites)
* [Creating the VM](#creating-the-vm)
* [Installing GitLab](#installing-gitlab)
* [Next steps](#next-steps)
* [Assigning a static IP](#assigning-a-static-ip)
* [Using a domain name](#using-a-domain-name)
* [Configuring HTTPS with the domain name](#configuring-https-with-the-domain-name)
* [Configuring the email SMTP settings](#configuring-the-email-smtp-settings)
* [Further reading](#further-reading)
# Installing GitLab on Google Cloud Platform[](#installing-gitlab-on-google-cloud-platform "Permalink")
本指南将帮助您在[Google Cloud Platform(GCP)](https://cloud.google.com/)实例上安装 GitLab.
**替代安装方法:** Google 提供了一份白皮书,用于[在 Google Kubernetes Engine 上部署可投入生产的 GitLab](https://cloud.google.com/solutions/deploying-production-ready-gitlab-on-gke) ,包括所有步骤和外部资源配置. 这些是使用 GCP VM 的替代方法,并使用[Cloud native GitLab Helm chart](https://docs.gitlab.com/charts/) .
## Prerequisites[](#prerequisites "Permalink")
在 GCP 上安装 GitLab 的前提条件只有两个:
1. 您需要有一个 Google 帐户.
2. 您需要注册 GCP 计划. 如果您是第一次,Google 会为您提供[$ 300 的信用额,](https://console.cloud.google.com/freetrial)可在 60 天内[免费](https://console.cloud.google.com/freetrial)使用.
完成这两个步骤后,就可以[创建 VM 了](#creating-the-vm) .
## Creating the VM[](#creating-the-vm "Permalink")
要在 GCP 上部署 GitLab,您首先需要创建一个虚拟机:
1. 转到[https://console.cloud.google.com/compute/instances](https://console.cloud.google.com/compute/instances)并使用您的 Google 凭据登录.
2. 点击**创建**
[![Search for GitLab](img/9f6f0b27f8e7df6c95a3262de502b39f.png)](img/launch_vm.png)
3. On the next page, you can select the type of VM as well as the estimated costs. Provide the name of the instance, desired datacenter, and machine type. Note our [hardware requirements for different user base sizes](../requirements.html#hardware-requirements).
[![Launch on Compute Engine](img/d345ea7938f401127d9471442b27eb27.png)](img/vm_details.png)
4. 要选择大小,类型和所需的[操作系统](../requirements.html#supported-linux-distributions) ,请在" `Boot disk` **"**下单击" **更改** ". 完成后单击" **选择"** .
5. 最后,允许 HTTP 和 HTTPS 通信,然后点击**创建** . 该过程将在几秒钟内完成.
## Installing GitLab[](#installing-gitlab "Permalink")
几秒钟后,实例将被创建并可以登录.下一步是将 GitLab 安装到实例上.
[![Deploy settings](img/ad33446e7ba7897d31835424ce5e1feb.png)](img/vm_created.png)
1. 记下实例的 IP 地址,因为在后续步骤中将需要使用该 IP 地址.
2. 单击 SSH 按钮以连接到实例.
3. 登录到实例后,将出现一个新窗口.
[![GitLab first sign in](img/e2a52ca7a089fcbd9b17f94875cba0ca.png)](img/ssh_terminal.png)
4. 接下来,在[https://about.gitlab.com/install/上](https://about.gitlab.com/install/)按照说明为您选择的操作系统安装 GitLab. 您可以将上述步骤中的 IP 地址用作主机名.
5. 恭喜你! GitLab 现在已安装,您可以通过浏览器访问它. 要完成安装,请在浏览器中打开 URL 并提供初始管理员密码. 该帐户的用户名是`root` .
[![GitLab first sign in](img/279650b9e9c3ec26a7d6f0493bd5af7c.png)](img/first_signin.png)
## Next steps[](#next-steps "Permalink")
这些是首次安装 GitLab 之后要执行的最重要的后续步骤.
### Assigning a static IP[](#assigning-a-static-ip "Permalink")
默认情况下,Google 会为您的实例分配一个临时 IP. 如果您要在生产中使用 GitLab 并使用域名,则强烈建议分配一个静态 IP,如下所示.
阅读 Google 有关如何[提升临时 IP 地址](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip)的文档.
### Using a domain name[](#using-a-domain-name "Permalink")
假设您拥有一个域名,并且已正确设置 DNS 以指向在上一步中配置的静态 IP,则可以通过以下方法配置 GitLab 以了解更改:
1. SSH 进入虚拟机. 您可以轻松使用 Google 控制台中的**SSH**按钮,然后会弹出一个新窗口.
[![SSH button](img/ad33446e7ba7897d31835424ce5e1feb.png)](img/vm_created.png)
将来,您可能想设置[使用 SSH 密钥的连接](https://cloud.google.com/compute/docs/instances/connecting-to-instance) .
2. 使用您喜欢的文本编辑器编辑 Omnibus GitLab 的配置文件:
```
sudo vim /etc/gitlab/gitlab.rb
```
3.`external_url`值设置为您希望 GitLab 在**不使用** `https` **情况下**拥有的域名:
```
external_url 'http://gitlab.example.com'
```
我们将在下一步中设置 HTTPS,而现在无需这样做.
4. 重新配置 GitLab,以使更改生效:
```
sudo gitlab-ctl reconfigure
```
5. 您现在可以使用域名访问 GitLab.
### Configuring HTTPS with the domain name[](#configuring-https-with-the-domain-name "Permalink")
尽管不需要,但强烈建议使用 TLS 证书保护 GitLab. 请遵循[Omnibus 文档中](https://docs.gitlab.com/omnibus/settings/nginx.html)的步骤.
### Configuring the email SMTP settings[](#configuring-the-email-smtp-settings "Permalink")
您需要正确配置电子邮件 SMTP 设置,否则 GitLab 将无法发送通知电子邮件,例如注释和密码更改. 检查[Omnibus 文档的](https://docs.gitlab.com/omnibus/settings/smtp.html)操作方法.
## Further reading[](#further-reading "Permalink")
可以将 GitLab 配置为与其他 OAuth 提供程序,LDAP,SAML,Kerberos 等进行身份验证.以下是您可能感兴趣阅读的一些文档:
* [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/)
* [Integration documentation](../../integration/README.html)
* [GitLab Pages configuration](../../administration/pages/index.html)
* [GitLab Container Registry configuration](../../administration/packages/container_registry.html)
\ No newline at end of file
此差异已折叠。
# Analytics
> 原文:[https://docs.gitlab.com/ee/user/analytics/](https://docs.gitlab.com/ee/user/analytics/)
* [Analytics workspace](#analytics-workspace)
* [Group-level analytics](#group-level-analytics)
* [Project-level analytics](#project-level-analytics)
# Analytics[](#analytics "Permalink")
## Analytics workspace[](#analytics-workspace "Permalink")
在 GitLab 12.2 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/12077) .
通过 Analytics(分析)工作区,可以跨 GitLab 汇总分析,以便用户可以在一个地方查看多个项目和组中的信息.
要访问 Google Analytics(分析)工作区,请单击顶部导航栏中的**更多>分析** .
## Group-level analytics[](#group-level-analytics "Permalink")
在 GitLab 12.8 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/195979) .
在组级别可以使用以下分析功能:
* [Contribution](../group/contribution_analytics/index.html).
* [Insights](../group/insights/index.html).
* [Issues](../group/issues_analytics/index.html).
* [生产力](productivity_analytics.html) (通过`productivity_analytics` [功能标记](../../development/feature_flags/development.html#enabling-a-feature-flag-in-development)启用).
* [值流](value_stream_analytics.html) ,通过`cycle_analytics` [功能标记](../../development/feature_flags/development.html#enabling-a-feature-flag-in-development)启用.
## Project-level analytics[](#project-level-analytics "Permalink")
在项目级别可以使用以下分析功能:
* [CI/CD](../../ci/pipelines/index.html#pipeline-success-and-duration-charts).
* [Code Review](code_review_analytics.html).
* [Insights](../group/insights/index.html).
* [Issues](../group/issues_analytics/index.html).
* [Repository](repository_analytics.html).
* [值流](value_stream_analytics.html) ,通过`cycle_analytics` [功能标记](../../development/feature_flags/development.html#enabling-a-feature-flag-in-development)启用.
\ No newline at end of file
# Code Review Analytics
> 原文:[https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html](https://docs.gitlab.com/ee/user/analytics/code_review_analytics.html)
* [Overview](#overview)
* [Use cases](#use-cases)
* [Permissions](#permissions)
# Code Review Analytics[](#code-review-analytics-starter "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/38062) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.7.
通过 Code Review Analytics,可以轻松地查看打开的合并请求中运行时间最长的审查,从而使您可以对单个合并请求采取措施,并缩短总体周期.
**注意:**最初,不会显示任何数据. 用户在打开的合并请求中发表评论时,将填充数据.
## Overview[](#overview "Permalink")
Code Review Analytics 显示一个打开的合并请求表,该请求至少具有一个非作者注释. 审阅时间从提交第一个非作者评论的时间开始计算. 合并请求的代码审阅时间自动标识为自第一个非作者评论以来的时间.
要访问 Code Review Analytics,请从您项目的菜单中转到 **项目分析>代码审查** .
[![Code Review Analytics](img/0124687ca256ab68d34dd0918f1e1a8d.png "List of code reviews; oldest review first.")](img/code_review_analytics_v12_8.png)
* 该表格按评论时长排序,可帮助您快速找到运行时间最长的评论,这可能需要干预或分解成较小的部分.
* 您可以按里程碑和标签过滤 MR 列表.
* 用于显示作者,批准者,评论数和行更改(-/ +)数的列.
## Use cases[](#use-cases "Permalink")
此功能专为[开发团队负责](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)人和其他想了解广泛的代码审查动态并确定模式以对其进行解释的人员而设计.
您可以使用 Code Review Analytics 通过代码审查来揭露团队的独特挑战,并确定可能会大大加快开发周期的改进.
在以下情况下可以使用代码审查分析:
* 您的团队同意代码审查进度太慢.
* [价值流分析功能](value_stream_analytics.html)表明,审核是您团队最耗时的步骤.
您可以使用 Code Review Analytics 查看当前运行最慢的工作类型,并分析它们之间的模式和趋势. 例如:
* 很多评论或承诺? 也许代码太复杂了.
* 涉及特定作者吗? 也许需要更多的培训.
* 评论和批准者很少? 也许您的团队人手不足.
## Permissions[](#permissions "Permalink")
*[简化版或青铜级](https://about.gitlab.com/pricing/)上.
* 由具有 Reporter 访问权限及以上权限的用户组成.
\ No newline at end of file
# Productivity Analytics
> 原文:[https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html](https://docs.gitlab.com/ee/user/analytics/productivity_analytics.html)
* [Supported features](#supported-features)
* [Accessing metrics and visualizations](#accessing-metrics-and-visualizations)
* [Date ranges](#date-ranges)
* [Permissions](#permissions)
* [Enabling and disabling using feature flags](#enabling-and-disabling-using-feature-flags)
# Productivity Analytics[](#productivity-analytics-premium "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12079) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.3.
使用 Productivity Analytics 追踪发展速度.
For many companies, the development cycle is a black box and getting an estimate of how long, on average, it takes to deliver features is an enormous endeavor.
虽然[价值流分析](../project/cycle_analytics.html)专注于整个软件开发生命周期(SDLC)流程,但生产力分析为工程管理提供了一种以系统的方式向下钻取的方法,以揭示在个人,项目或团队级别上的模式以及成败的原因.
生产力降低的原因很多,从降低代码库到快速成长的团队. 为了进行调查,部门或团队负责人可以从可视化合并请求所花费的时间开始.
## Supported features[](#supported-features "Permalink")
生产力分析允许 GitLab 用户执行以下操作:
* 可视化典型的合并请求(MR)生存期和统计信息. 使用直方图显示创建和合并合并请求之间经过的时间分布.
* 深入研究最耗时的合并请求,选择一些异常值,然后筛选所有后续图表以调查潜在原因.
* 按组,项目,作者,标签,里程碑或特定日期范围过滤. 例如,在里程碑或特定日期范围内,筛选出组或项目中特定作者的合并请求.
* 测量随时间变化的速度. 随时间推移可视化以上图表中每个指标的趋势,以观察进度. 如果发现异常值,请放大特定的日期范围.
## Accessing metrics and visualizations[](#accessing-metrics-and-visualizations "Permalink")
要访问该图表,请导航至组的侧边栏,然后选择**Analytics(分析)> Productivity Analytics(生产力分析)** .
以下度量标准和可视化在项目或组级别可用-当前仅涵盖**合并的**合并请求:
* 直方图,显示创建后经过指定天数进行合并的合并请求数. 选择一个特定的列以筛选后续的图表.
* 直方图显示了合并合并请求所花费的时间(以小时为单位)的细目. 可以使用以下间隔:
* 从第一次提交到第一次评论的时间.
* 从第一次评论到最后一次提交的时间.
* 从上次提交到合并的时间.
* 使用以下内容显示合并请求的大小或复杂度的直方图:
* 每个合并请求的提交数.
* 每次提交的代码行数.
* 触摸的文件数.
* 散点图显示所有 MR 在特定日期合并,以及完成操作所需的天数和 30 天的滚动中位数.
* 该表显示了合并请求的列表及其各自的持续时间指标.
* 用户可以按上述任何指标进行排序.
## Date ranges[](#date-ranges "Permalink")
在 GitLab 12.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/13188) .
GitLab 能够根据日期范围过滤分析. 要过滤结果:
1. 选择一个组.
2. (可选)选择一个项目.
3. 使用可用的日期选择器选择日期范围.
## Permissions[](#permissions "Permalink")
只能访问**Productivity Analytics**仪表板:
*[高级或银级](https://about.gitlab.com/pricing/)以上.
* 由具有[Reporter 访问权限](../permissions.html)及以上[权限的](../permissions.html)用户组成.
## Enabling and disabling using feature flags[](#enabling-and-disabling-using-feature-flags "Permalink")
生产力分析是:
* [默认情况下](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18754)从 GitLab 12.4 [启用](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18754) ,但可以使用以下功能标志禁用:
* `productivity_analytics` .
* `productivity_analytics_scatterplot_enabled` .
* 在 GitLab 12.3 中默认为禁用,但可以使用以下功能标志启用:
* `productivity_analytics` .
GitLab 管理员可以:
* 通过在 Rails 控制台中运行以下命令,从 GitLab 12.4 禁用此功能:
```
Feature.disable(:productivity_analytics)
Feature.disable(:productivity_analytics_scatterplot_enabled)
```
* 通过在 Rails 控制台中运行以下命令,在 GitLab 12.3 中启用此功能:
```
Feature.enable(:productivity_analytics)
```
\ No newline at end of file
# Value Stream Analytics
> 原文:[https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html)
* [Overview](#overview)
* [Date ranges](#date-ranges)
* [How Time metrics are measured](#how-time-metrics-are-measured)
* [How the stages are measured](#how-the-stages-are-measured)
* [Example workflow](#example-workflow)
* [Customizable Value Stream Analytics](#customizable-value-stream-analytics)
* [Stage path](#stage-path)
* [Adding a stage](#adding-a-stage)
* [Re-ordering stages](#re-ordering-stages)
* [Label based stages](#label-based-stages)
* [Hiding unused stages](#hiding-unused-stages)
* [Days to completion chart](#days-to-completion-chart)
* [Chart median line](#chart-median-line)
* [Disabling chart](#disabling-chart)
* [Disabling chart median line](#disabling-chart-median-line)
* [Type of work - Tasks by type chart](#type-of-work---tasks-by-type-chart)
* [Permissions](#permissions)
* [More resources](#more-resources)
# Value Stream Analytics[](#value-stream-analytics "Permalink")
版本历史
* 在项目级别在 GitLab 12.3 之前作为 Cycle Analytics 引入.
* 在小组级别的[GitLab Premium](https://about.gitlab.com/pricing/) 12.3 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/12077) .
* 在 GitLab 12.8 中从 Cycle Analytics [重命名](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23427)为 Value Stream Analytics.
Value Stream Analytics measures the time spent to go from an [idea to production](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#from-idea-to-production-with-gitlab) (also known as cycle time) for each of your projects. Value Stream Analytics displays the median time spent in each stage defined in the process.
有关如何为 Value Stream Analytics 的发展做出贡献的信息,请参阅我们的[贡献者文档](../../development/value_stream_analytics.html) .
值流分析有助于快速确定给定项目的速度. 它指出了开发过程中的瓶颈,从而使管理层能够发现,分类和识别软件开发生命周期中速度下降的根本原因.
Value Stream Analytics 与[GitLab 流程](../../topics/gitlab_flow.html)紧密结合,并为每个阶段计算单独的中位数.
## Overview[](#overview "Permalink")
价值流分析可用:
* 在 GitLab 12.9 中,通过**组>分析>值流**在组级别.
* 在项目级别,通过" **项目">"分析">"价值流"** .
作为"价值流分析"计算的一部分,将跟踪七个阶段.
* **Issue** (Tracker)
* 安排问题的时间(按里程碑或通过将其添加到问题板)
* **Plan** (Board)
* 第一次提交的时间
* **Code** (IDE)
* 是时候创建合并请求了
* **Test** (CI)
* GitLab CI / CD 测试代码所需的时间
* **审核** (合并请求/ MR)
* 花在代码审查上的时间
* **暂存** (连续部署)
* 合并和部署到生产之间的时间
* **Total** (Total)
* 总生命周期时间. 也就是说,项目或团队的速度. [以前称为](https://gitlab.com/gitlab-org/gitlab/-/issues/38317) **Production** .
## Date ranges[](#date-ranges "Permalink")
在 GitLab 12.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/13216) .
GitLab 提供了根据日期范围过滤分析的功能. 要过滤结果:
1. 选择一个组.
2. (可选)选择一个项目.
3. 使用可用的日期选择器选择日期范围.
## How Time metrics are measured[](#how-time-metrics-are-measured "Permalink")
页面顶部附近的"时间"指标的测量方法如下:
* **提前期** :从创建问题到关闭问题的平均时间.
* **周期时间** :从第一次提交到发布完成的中值时间.
注意:通过在提交消息中进行[交联](../project/issues/crosslinking_issues.html)或通过手动链接包含提交的合并请求,将提交与问题相关[](../project/issues/crosslinking_issues.html) .
[![Value stream analytics time metrics](img/f7050ce0aa3559c639befc2fe3d7aacb.png "Time metrics for value stream analytics")](img/vsa_time_metrics_v13_0.png)
## How the stages are measured[](#how-the-stages-are-measured "Permalink")
Value Stream Analytics 根据项目问题记录阶段时间和数据,但阶段和总阶段除外,在阶段和总阶段中,仅测量部署到生产中的数据.
具体而言,如果未设置 CI 且尚未定义`production``production/*` [环境](../../ci/yaml/README.html#environment) ,则此阶段将没有任何数据.
下表进一步描述了价值流分析的每个阶段.
| **Stage** | **Description** |
| --- | --- |
| Issue | 通过标记问题或将其添加到里程碑中,以先发生的为准,来衡量从创建问题到采取行动解决问题之间的平均时间. 仅在标签已经为其创建了[发行委员会列表的](../project/issue_board.html)情况下,才会跟踪该标签. |
| Plan | 测量您在上一阶段采取的操作与将第一次提交推入分支之间的平均时间. 分支的第一个提交是触发**计划****代码**之间分离的提交,并且分支中的至少一个提交需要包含相关的发行编号(例如`#42` ). 如果分支中的所有提交都未提及相关的发行号,则不会考虑该阶段的度量时间. |
| Code | 测量推入第一个提交(上一阶段)与创建与该提交相关的合并请求(MR)之间的平均时间. 保持流程跟踪的关键是在合并请求的描述中包括[问题关闭模式](../project/issues/managing_issues.html#closing-issues-automatically) (例如, `Closes #xxx` ,其中`xxx`是与此合并请求相关的问题编号). 如果合并请求描述中不存在问题结束模式,则不会将 MR 视为平台的测量时间. |
| Test | 测量运行该项目的整个管道的中值时间. 这与 GitLab CI / CD 为推送到上一阶段中定义的合并请求的提交运行每个作业所花费的时间有关. 基本上,这是所有管道的开始->完成时间. |
| Review | 测量从创建到合并之间,审核具有结束问题模式的合并请求所需的平均时间. |
| Staging | 测量从合并合并请求到结束发布模式到首次部署到生产之间的平均时间. 在您的 GitLab CI / CD 配置中,通过设置为`production`或匹配`production/*` (区分大小写, `Production`将不起作用)的环境进行跟踪. 如果没有生产环境,则不会进行跟踪. |
| Total | 从问题创建到将代码部署到生产中,运行整个过程所需的所有时间(中位数)之和. [以前称为](https://gitlab.com/gitlab-org/gitlab/-/issues/38317) **Production** . |
幕后工作原理:
1. 问题和合并请求成对地分组在一起,这样对于每个`<issue, merge request>`对,合并请求都具有对应问题的[问题关闭模式](../project/issues/managing_issues.html#closing-issues-automatically) . **不**考虑所有其他问题和合并请求.
2. 然后,在最近的 XX 天(由 UI 指定-默认为 90 天)中过滤出`<issue, merge request>`对. 因此,它禁止考虑这些对.
3. 对于其余的`<issue, merge request>`对,我们检查阶段所需的信息,例如发行日期,合并请求合并时间等.
综上所述,不会跟踪任何未遵循[GitLab 流程的](../../workflow/gitlab_flow.html)内容,并且 Value Stream Analytics 仪表板将不会显示以下任何数据:
* 合并不会解决问题的请求.
* 未在发行委员会中贴有标签的问题或未分配里程碑的问题.
* 如果项目没有`production``production/*`环境,则为阶段和生产阶段.
## Example workflow[](#example-workflow "Permalink")
以下是一个简单的虚拟周期工作流,它在一天中经历了所有七个阶段后,才发生. 请注意,如果一个阶段没有开始和结束标记,则不会对其进行测量,因此不会在中位时间中进行计算. 假定已创建里程碑并配置了用于测试和设置环境的 CI.
1. 在 09:00( **发行**阶段开始)创建**发行** .
2. 在 11:00( **发行**阶段停止/ **计划**阶段开始)将发行添加到里程碑.
3. 开始解决此问题,在本地创建一个分支,并在 12:00 提交一次.
4. 对分支进行第二次提交,该分支在 12.30( **计划**阶段的停止/ **代码**阶段的开始)中提及发行号.
5. 推送分支并创建一个合并请求,该请求的描述在 14:00( **代码**阶段停止/ **测试****复审**阶段开始)中包含[问题关闭模式](../project/issues/managing_issues.html#closing-issues-automatically) .
6. CI 将开始运行您在[`.gitlab-ci.yml`](../../ci/yaml/README.html)定义的脚本,并需要 5 分钟( **测试**阶段停止).
7. 查看合并请求,确保一切正常,然后在 19:00 合并合并请求. ( **复习**阶段的停止/启动**分期**阶段).
8. 现在,合并请求合并,部署到`production`环境中开始和结束日 19:30( **分期**阶段停止).
9. 循环完成,并且先前阶段的中位数时间总和记录到" **总计"**阶段. 这是从创建问题到将其相关合并请求部署到生产之间的时间.
从上面的示例中,您可以得出每个阶段完成所需的时间,只要达到其总时间即可:
* **问题** :2 小时(11:00-09:00)
* **计划** :1 小时(12:00-11:00)
* **编码** :2h(14:00-12:00)
* **测试时间** :5 分钟
* **评论** :5 小时(19:00-14:00)
* **演出时间** :30 分钟(19:30-19:00)
* **总计** :由于此阶段测量的是之前所有阶段的中位时间之和,因此如果我们不知道之前各阶段的状态,则无法计算. 如果这是项目中运行的第一个周期,则**总**时间为 10h 30min(19:30-09:00)
一些注意事项:
* 在上面的示例中,我们演示了您的第一次提交没有提到发行号也没关系,您可以稍后在正在处理的分支的任何提交中进行此操作.
* 您可以看到,由于未将" **测试"**阶段计算为整个周期的时间,因此" **检查"**阶段已包含在" **审查"**过程中(应测试每个 MR).
* 上面的示例只是七个阶段中的**一个循环** . 添加多个周期,计算它们的中值时间,结果就是 Value Stream Analytics 仪表板显示的内容.
## Customizable Value Stream Analytics[](#customizable-value-stream-analytics "Permalink")
在 GitLab 12.9 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/12196) .
默认阶段旨在直接使用,但是可能并不适合所有团队. 不同的团队使用不同的方法来构建软件,因此一些团队可能想要自定义其 Value Stream Analytics.
GitLab 允许用户隐藏默认阶段并创建自定义阶段,使其更适合其开发工作流程.
**注意:**自定义性[仅适用于组级别的](https://gitlab.com/gitlab-org/gitlab/-/issues/35823#note_272558950)价值流分析.
### Stage path[](#stage-path "Permalink")
在 GitLab 13.0 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/210315) .
从视觉上将阶段描绘为水平过程流. 选择一个阶段将更新值流下方的内容.
默认情况下禁用. 如果您具有自我管理的实例,则管理员可以[打开 Rails 控制台](../../administration/troubleshooting/navigating_gitlab_via_rails_console.html)并使用以下命令启用它:
```
Feature.enable(:value_stream_analytics_path_navigation)
```
### Adding a stage[](#adding-a-stage "Permalink")
在下面的示例中,我们将创建一个新阶段,该阶段可以衡量和跟踪从创建到关闭的所有问题.
1. 导航到您组的" **分析">"价值流"** .
2. 单击**添加阶段**按钮.
3. 填写新的舞台表格:
* 名称:问题开始完成.
* 开始事件:已创建问题.
* 结束事件:问题已关闭.
4. 单击**添加阶段**按钮.
[![New Value Stream Analytics Stage](img/d1c47110b6092ce9cec04ff22addfaa4.png "Form for creating a new stage")](img/new_vsm_stage_v12_9.png)
新阶段将保持不变,并将始终显示在您组的"价值流分析"页面上.
如果要更改或删除阶段,可以通过以下方法轻松地针对自定义阶段进行操作:
1. Hovering over the stage.
2. 单击垂直省略号( )出现的按钮.
[![Value Stream Analytics Stages](img/d277485e75207494ed3529dfcc7a6395.png)](img/vsm_stage_list_v12_9.png)
创建自定义阶段需要指定两个事件:
* 开始.
* 结束.
请小心选择*在*结束事件*之前*发生的开始事件. 例如,考虑一个阶段:
* 在将问题添加到板上时开始.
* 创建问题时结束.
此阶段将不起作用,因为开始事件发生时,结束事件已经发生. 为防止此类无效阶段,UI 禁止出现不兼容的开始和结束事件. 选择开始事件后,停止事件下拉列表将仅列出兼容事件.
### Re-ordering stages[](#re-ordering-stages "Permalink")
在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/196698) .
添加自定义阶段后,您可以"拖放"阶段以重新排列其顺序. 这些更改将自动保存到系统中.
### Label based stages[](#label-based-stages "Permalink")
预定义的开始和结束事件可以涵盖涉及问题和合并请求的许多用例.
为了支持更复杂的工作流程,请使用基于组标签的阶段. 这些事件基于添加或删除的标签. 特别是, [范围标签](../project/labels.html#scoped-labels-premium)对于复杂的工作流程很有用.
在此示例中,我们希望测量更准确的代码检查时间. 工作流程如下:
* 代码审阅开始时,审阅者将`workflow::code_review_start`标签添加到合并请求中.
* 代码检查完成后,检查者将`workflow::code_review_complete`标签添加到合并请求中.
创建一个称为"代码审查"的新阶段:
[![New Label Based Value Stream Analytics Stage](img/ea01744c06eb8853392bfd840dc1517d.png "Creating a label based Value Stream Analytics Stage")](img/label_based_stage_vsm_v12_9.png)
### Hiding unused stages[](#hiding-unused-stages "Permalink")
有时某些默认阶段与团队无关. 在这种情况下,您可以轻松隐藏阶段,使它们不再出现在列表中. 隐藏阶段:
1. 添加定制阶段以激活可定制性.
2. 将鼠标悬停在要隐藏的默认阶段上.
3. 单击垂直省略号( )按钮出现,然后选择" **隐藏舞台"** .
要恢复以前隐藏的默认阶段:
1. Click **添加一个阶段** button.
2. 在右上角打开" **恢复隐藏的阶段"**下拉列表.
3. 选择一个阶段.
## Days to completion chart[](#days-to-completion-chart "Permalink")
在 GitLab 12.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21631) .
该图表直观地描述了完成周期所需的总天数.
该图表使用全局页面过滤器来基于选定的组,项目和时间范围显示数据. 此外,可以从图表本身内选择特定阶段.
### Chart median line[](#chart-median-line "Permalink")
在 GitLab 12.7 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/36675) .
图表上的中间线显示的数据偏移了所选的天数. 例如,如果选择了 30 天的数据(例如 2019-12-16 至 2020-01-15),则中线将代表前 30 天的数据(2019-11-16 至 2019-12 -16)作为要比较的指标.
### Disabling chart[](#disabling-chart "Permalink")
This chart is enabled by default. If you have a self-managed instance, an administrator can open a Rails console and disable it with the following command:
```
Feature.disable(:cycle_analytics_scatterplot_enabled)
```
### Disabling chart median line[](#disabling-chart-median-line "Permalink")
默认情况下,此图表的中线是启用的. 如果您具有自我管理的实例,则管理员可以打开 Rails 控制台并使用以下命令将其禁用:
```
Feature.disable(:cycle_analytics_scatterplot_median_enabled)
```
## Type of work - Tasks by type chart[](#type-of-work---tasks-by-type-chart "Permalink")
在 GitLab 12.10 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/32421) .
此图表显示每天的问题和合并请求的累积计数.
该图表使用全局页面过滤器来基于选定的组,项目和时间范围显示数据. 该图表默认为显示问题计数,但可以切换为显示合并请求数据,并进一步细化为特定的组级标签.
默认情况下,预先选择了最高的组级别标签(最多 10 个),最多可以选择 15 个标签.
## Permissions[](#permissions "Permalink")
Project Value Stream Analytics 仪表板上的当前权限为:
* 公共项目-任何人都可以访问.
* 内部项目-任何经过身份验证的用户都可以访问.
* 私人项目-访客及以上的任何成员都可以访问.
您通常可以[阅读有关权限的更多信息](../../ci/yaml/README.html) .
对于 GitLab 12.3 和更高版本中引入的 Value Stream Analytics 功能:
* 用户必须具有 Reporter 或更高权限.
* 仅在[Premium 或 Silver 等级](https://about.gitlab.com/pricing/)及更高[级别](https://about.gitlab.com/pricing/)上可用.
## More resources[](#more-resources "Permalink")
Learn more about Value Stream Analytics in the following resources:
* [Value Stream Analytics feature page](https://about.gitlab.com/stages-devops-lifecycle/value-stream-analytics/).
* [Value Stream Analytics feature preview](https://about.gitlab.com/blog/2016/09/16/feature-preview-introducing-cycle-analytics/).
* [Value Stream Analytics feature highlight](https://about.gitlab.com/blog/2016/09/21/cycle-analytics-feature-highlight/).
\ No newline at end of file
# Kubernetes clusters
> 原文:[https://docs.gitlab.com/ee/user/project/clusters/](https://docs.gitlab.com/ee/user/project/clusters/)
* [Overview](#overview)
* [Setting up](#setting-up)
* [Supported cluster versions](#supported-cluster-versions)
* [Adding and removing clusters](#adding-and-removing-clusters)
* [Multiple Kubernetes clusters](#multiple-kubernetes-clusters)
* [Setting the environment scope](#setting-the-environment-scope-premium)
* [Configuring your Kubernetes cluster](#configuring-your-kubernetes-cluster)
* [Security implications](#security-implications)
* [GitLab-managed clusters](#gitlab-managed-clusters)
* [Important notes](#important-notes)
* [Clearing the cluster cache](#clearing-the-cluster-cache)
* [Base domain](#base-domain)
* [Installing applications](#installing-applications)
* [Auto DevOps](#auto-devops)
* [Deploying to a Kubernetes cluster](#deploying-to-a-kubernetes-cluster)
* [Deployment variables](#deployment-variables)
* [Custom namespace](#custom-namespace)
* [Integrations](#integrations)
* [Canary Deployments](#canary-deployments-premium)
* [Deploy Boards](#deploy-boards-premium)
* [Viewing pod logs](#viewing-pod-logs)
* [Web terminals](#web-terminals)
* [Troubleshooting](#troubleshooting)
* [Monitoring your Kubernetes cluster](#monitoring-your-kubernetes-cluster)
* [Visualizing cluster health](#visualizing-cluster-health)
# Kubernetes clusters[](#kubernetes-clusters "Permalink")
版本历史
* 在项目的 GitLab 10.1 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/35954) .
* 在 GitLab 11.6 中针对[](../../group/clusters/index.html) [引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/34758) .
* 在 GitLab 11.11 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/39840)[实例](../../instance/clusters/index.html) .
## Overview[](#overview "Permalink")
使用 GitLab 项目 Kubernetes 集成,您可以:
* Use [Review Apps](../../../ci/review_apps/index.html).
* Run [pipelines](../../../ci/pipelines/index.html).
* [部署](#deploying-to-a-kubernetes-cluster)您的应用程序.
* 检测和[监控 Kubernetes](#monitoring-your-kubernetes-cluster) .
*[Auto DevOps](#auto-devops)一起使用.
* Use [Web terminals](#web-terminals).
* Use [Deploy Boards](#deploy-boards-premium).
* Use [Canary Deployments](#canary-deployments-premium).
* View [Logs](#viewing-pod-logs).
* [使用 Knative](serverless/index.html)[Kubernetes 上](serverless/index.html)运行无服务器工作负载.
除了在项目级别进行集成之外,Kubernetes 集群还可以在[组级别](../../group/clusters/index.html)[GitLab 实例级别](../../instance/clusters/index.html)进行集成.
## Setting up[](#setting-up "Permalink")
### Supported cluster versions[](#supported-cluster-versions "Permalink")
GitLab 承诺在任何给定时间至少支持两个生产就绪的 Kubernetes 次要版本. 我们会定期审查我们支持的版本,并提供四个月的弃用期,然后再删除特定版本的支持. 支持的版本范围基于以下方面的评估:
* 我们自己的需求.
* 主要托管 Kubernetes 提供商支持的版本.
* [Kubernetes 社区支持](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions)的版本.
当前,GitLab 支持以下 Kubernetes 版本:
* 1.16
* 1.15
* 1.14
* 1.13(不建议使用,支持终止于 2020 年 11 月 22 日)
* 1.12(不建议使用,支持终止于 2020 年 9 月 22 日)
**注意:**某些 GitLab 功能可能支持此处提供的范围之外的版本.
### Adding and removing clusters[](#adding-and-removing-clusters "Permalink")
有关如何执行以下操作的详细信息,请参见[添加和删​​除 Kubernetes 集群](add_remove_clusters.html)
* 使用 GitLab 的 UI 在 Google Cloud Platform(GCP)或 Amazon Elastic Kubernetes Service(EKS)中创建集群.
* 从任何 Kubernetes 平台向现有集群添加集成.
### Multiple Kubernetes clusters[](#multiple-kubernetes-clusters "Permalink")
版本历史
*[GitLab Premium](https://about.gitlab.com/pricing/) 10.3 中引入
* 在 13.2 中[移至](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35094) GitLab 核心.
您可以将多个 Kubernetes 集群关联到您的项目. 这样,您可以为不同的环境(例如开发,登台,生产等)使用不同的集群.
就像您第一次一样,只需添加另一个集群,并确保[设置一个环境范围即可](#setting-the-environment-scope-premium)将新集群与其他集群区分开.
#### Setting the environment scope[](#setting-the-environment-scope-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)工作方式.
默认环境范围是`*` ,这意味着所有作业,无论其环境如何,都将使用该群集. 每个作用域只能由项目中的单个群集使用,否则将发生验证错误. 另外,没有设置环境关键字的作业将无法访问任何群集.
例如,假设项目中存在以下 Kubernetes 集群:
| Cluster | 环境范围 |
| --- | --- |
| Development | `*` |
| Production | `production` |
[`.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
url: https://staging.example.com/
deploy to production:
stage: deploy
script: make deploy
environment:
name: production
url: https://example.com/
```
结果将是:
* The Development cluster details will be available in the `deploy to staging` job.
* 生产集群详细信息将在`deploy to production`作业中提供.
* `test`作业中没有可用的群集详细信息,因为它没有定义任何环境.
## Configuring your Kubernetes cluster[](#configuring-your-kubernetes-cluster "Permalink")
[将 Kubernetes 群集添加](add_remove_clusters.html)到 GitLab 之后,请阅读本节,其中涵盖了使用 GitLab 配置 Kubernetes 群集的重要注意事项.
### Security implications[](#security-implications "Permalink")
**Important:** The whole cluster security is based on a model where [developers](../../permissions.html) are trusted, so **仅允许受信任的用户控制您的集群**.
默认的群集配置授予对成功构建和部署容器化应用程序所需的广泛功能的访问权限. 请记住,群集上运行的所有应用程序都使用相同的凭据.
### 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) .
您可以选择允许 GitLab 为您管理集群. 如果您的集群由 GitLab 管理,则将自动创建项目资源. 有关创建哪些资源的详细信息,请参见" [访问控制"](add_remove_clusters.html#access-controls)部分.
如果选择管理自己的群集,则不会自动创建特定于项目的资源. 如果使用的是[Auto DevOps](../../../topics/autodevops/index.html) ,则需要显式提供部署作业将使用的`KUBE_NAMESPACE` [部署变量](#deployment-variables) ,否则将为您创建一个名称空间.
#### Important notes[](#important-notes "Permalink")
在 GitLab 和集群上注意以下几点:
* 如果您在群集上[安装应用程序](#installing-applications) ,即使您选择管理自己的群集,GitLab 也会创建运行这些资源所需的资源.
* 请注意,手动管理由 GitLab 创建的资源(例如名称空间和服务帐户)可能会导致意外错误. 如果发生这种情况,请尝试[清除集群缓存](#clearing-the-cluster-cache) .
#### 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 **Clear cluster cache**.
### Base domain[](#base-domain "Permalink")
在 GitLab 11.8 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24580) .
**注意:**使用 GitLab Serverless 时,无需在群集设置上指定基本域. 在这种情况下,域将被指定为 Knative 安装的一部分. 请参阅[安装应用程序](#installing-applications) .
指定基本域将自动将`KUBE_INGRESS_BASE_DOMAIN`设置为环境变量. 如果您使用的是[Auto DevOps](../../../topics/autodevops/index.html) ,则此域将用于不同的阶段. 例如,"自动查看应用程序"和"自动部署".
该域应将通配符 DNS 配置为入口 IP 地址. 安装 Ingress 之后(请参阅[安装应用程序](#installing-applications) ),您可以:
* 创建一个指向您的域提供商指向入口 IP 地址的`A`记录.
* 使用 nip.io 或 xip.io 之类的服务输入通配符 DNS 地址. 例如, `192.168.1.1.xip.io` .
## Installing applications[](#installing-applications "Permalink")
GitLab 可以在项目级集群中安装和管理一些应用程序,例如 Helm,GitLab Runner,Ingress,Prometheus 等. 有关为项目集群安装,升级,卸载和故障排除应用程序的更多信息,请参阅[GitLab 托管应用程序](../../clusters/applications.html) .
## Auto DevOps[](#auto-devops "Permalink")
Auto DevOps 自动检测,构建,测试,部署和监视您的应用程序.
要充分利用 Auto DevOps(自动部署,自动查看应用程序和自动监控),您需要启用 Kubernetes 项目集成.
[Read more about Auto DevOps](../../../topics/autodevops/index.html)
**注意** Kubernetes 群集可以在没有 Auto DevOps 的情况下使用.
## Deploying to a Kubernetes cluster[](#deploying-to-a-kubernetes-cluster "Permalink")
Kubernetes 集群可以作为部署作业的目标. 如果
* 该集群与 GitLab 集成在一起,特殊的[部署变量](#deployment-variables)可用于您的工作,并且不需要配置. 您可以使用诸如`kubectl``helm`工具立即开始从作业中与集群进行交互.
* 您无需使用 GitLab 的集群集成,仍然可以将其部署到集群中. 但是,您需要自己使用[环境变量](../../../ci/variables/README.html#custom-environment-variables)配置 Kubernetes 工具,然后才能通过作业与集群进行交互.
### Deployment variables[](#deployment-variables "Permalink")
Kubernetes 集群集成在 GitLab CI / CD 构建环境中公开了以下[部署变量](../../../ci/variables/README.html#deployment-environment-variables) .
| Variable | Description |
| --- | --- |
| `KUBE_URL` | 等于 API URL. |
| `KUBE_TOKEN` | [环境服务帐户](add_remove_clusters.html#access-controls)的 Kubernetes 令牌. |
| `KUBE_NAMESPACE` | 与项目的部署服务帐户关联的名称空间. 格式为`<project_name>-<project_id>-<environment>` . 对于由 GitLab 管理的集群,GitLab 会在集群中自动创建一个匹配的名称空间. |
| `KUBE_CA_PEM_FILE` | 包含 PEM 数据的文件的路径. 仅当指定了自定义 CA 捆绑包时才存在. |
| `KUBE_CA_PEM` | ( **已弃用** )原始 PEM 数据. 仅当指定了自定义 CA 捆绑包时. |
| `KUBECONFIG` | 包含用于此部署的`kubeconfig`的文件的路径. 如果指定,则将嵌入 CA 捆绑软件. 此配置还嵌入了在`KUBE_TOKEN`定义的相同令牌,因此您可能只需要此变量. 该变量名也会由`kubectl`自动选择,因此,如果使用`kubectl`则实际上不需要显式引用它. |
| `KUBE_INGRESS_BASE_DOMAIN` | 从 GitLab 11.8 开始,此变量可用于为每个群集设置一个域. 有关更多信息,请参见[群集域](#base-domain) . |
**注意:**在 GitLab 11.5 之前, `KUBE_TOKEN`是集群集成的主要服务帐户的 Kubernetes 令牌.**注意:**如果您的集群是在 GitLab 12.2 之前创建的,则默认`KUBE_NAMESPACE`将设置为`<project_name>-<project_id>` .
### Custom namespace[](#custom-namespace "Permalink")
在 GitLab 12.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/27630) .
Kubernetes 集成默认为格式为`<project_name>-<project_id>-<environment>`的特定于项目环境的名称空间(请参阅[部署变量](#deployment-variables) ).
对于**非** GitLab 管理的集群,可以使用`.gitlab-ci.yml` [`environment:kubernetes:namespace`](../../../ci/environments/index.html#configuring-kubernetes-deployments)来定制[`environment:kubernetes:namespace`](../../../ci/environments/index.html#configuring-kubernetes-deployments) .
**注意:**使用[GitLab 管理的集群时](#gitlab-managed-clusters) ,名称空间是在部署之前自动创建的, [无法自定义](https://gitlab.com/gitlab-org/gitlab/-/issues/38054) .
### Integrations[](#integrations "Permalink")
#### Canary Deployments[](#canary-deployments-premium "Permalink")
利用[Kubernetes 的 Canary 部署,](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)并在部署板内部可视化您的 Canary 部署,而无需离开 GitLab.
[Read more about Canary Deployments](../canary_deployments.html)
#### Deploy Boards[](#deploy-boards-premium "Permalink")
GitLab 的部署板提供了 Kubernetes 上运行的每个 CI [环境](../../../ci/environments/index.html)的当前运行状况和状态的合并视图,显示了部署中 Pod 的状态. 开发人员和其他团队成员可以在已经使用的工作流程中逐个窗格地查看发布的进度和状态,而无需访问 Kubernetes.
[Read more about Deploy Boards](../deploy_boards.html)
#### Viewing pod logs[](#viewing-pod-logs "Permalink")
使用 GitLab 可以轻松查看连接的 Kubernetes 集群中正在运行的 Pod 的日志. 通过直接在 GitLab 中显示日志,开发人员可以避免管理控制台工具或跳转到其他界面.
[Read more about Kubernetes logs](kubernetes_pod_logs.html)
#### Web terminals[](#web-terminals "Permalink")
在 GitLab 8.15 中引入.
启用后,Kubernetes 集成将为您的[环境](../../../ci/environments/index.html)添加[Web 终端](../../../ci/environments/index.html#web-terminals)支持. 这基于 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`权限才能使用终端. 支持仅限于环境中第一个容器中的第一个容器.
### Troubleshooting[](#troubleshooting "Permalink")
在开始部署作业之前,GitLab 将为部署作业专门创建以下内容:
* 命名空间.
* A service account.
但是,有时 GitLab 无法创建它们. 在这种情况下,您的工作将失败,并显示以下消息:
```
This job failed because the necessary resources were not successfully created.
```
要在创建名称空间和服务帐户时查找导致此错误的原因,请检查[日志](../../../administration/logs.html#kuberneteslog) .
失败的原因包括:
* 您为 GitLab 提供的令牌没有 GitLab 所需的[`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)特权.
* 缺少`KUBECONFIG``KUBE_TOKEN`变量. 要传递给您的工作,他们必须具有匹配的[`environment:name`](../../../ci/environments/index.html#defining-environments) . 如果您的作业没有设置`environment:name` ,则不会通过 Kubernetes 凭据.
**注意:**从 GitLab 12.0 或更早版本升级的项目级群集可能以导致此错误的方式进行配置. 如果要自己管理名称空间和服务帐户,请确保取消选择由[GitLab 管理的群集](#gitlab-managed-clusters)选项.
## Monitoring your Kubernetes cluster[](#monitoring-your-kubernetes-cluster "Permalink")
自动检测和监控 Kubernetes 指标. 还支持[NGINX Ingress 的](../integrations/prometheus_library/nginx.html)自动监视.
[Read more about Kubernetes monitoring](../integrations/prometheus_library/kubernetes.html)
### Visualizing cluster health[](#visualizing-cluster-health "Permalink")
版本历史
*[GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4701) .
* 在 13.2 中[移至](https://gitlab.com/gitlab-org/gitlab/-/issues/208224) GitLab 核心.
[部署 Prometheus 后](#installing-applications) ,GitLab 将自动监视群集的运行状况. 在群集设置页面的顶部,显示 CPU 和内存利用率以及可用总量. 如果群集的内存不足,则监视群集资源可能很重要,可能会关闭或无法启动.
[![Cluster Monitoring](img/0e27f7f7b1dd7b6748365d5ea985238a.png)](img/k8s_cluster_monitoring.png)
\ No newline at end of file
# Adding and removing Kubernetes clusters
> 原文:[https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html](https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html)
* [Before you begin](#before-you-begin)
* [Access controls](#access-controls)
* [Important notes](#important-notes)
* [RBAC cluster resources](#rbac-cluster-resources)
* [ABAC cluster resources](#abac-cluster-resources)
* [Security of GitLab Runners](#security-of-gitlab-runners)
* [Create new cluster](#create-new-cluster)
* [Add existing cluster](#add-existing-cluster)
* [Existing Kubernetes cluster](#existing-kubernetes-cluster)
* [Disable Role-Based Access Control (RBAC) (optional)](#disable-role-based-access-control-rbac-optional)
* [Enabling or disabling integration](#enabling-or-disabling-integration)
* [Removing integration](#removing-integration)
* [Learn more](#learn-more)
# Adding and removing Kubernetes clusters[](#adding-and-removing-kubernetes-clusters "Permalink")
GitLab 为以下 Kubernetes 提供者提供了集成的集群创建功能:
* Google Kubernetes 引擎(GKE).
* Amazon Elastic Kubernetes 服务(EKS).
GitLab 还可以与本地或托管的任何标准 Kubernetes 提供程序集成.
**注意:**观看[使用 GitLab 和 Google Cloud Platform 进行](https://about.gitlab.com/webcast/scalable-app-deploy/)的网络广播[可扩展应用程序部署,](https://about.gitlab.com/webcast/scalable-app-deploy/)并了解如何通过单击几下加速由 Google Cloud Platform(GCP)管理的 Kubernetes 集群.**提示:**每个新的 Google Cloud Platform(GCP)帐户[在注册后](https://console.cloud.google.com/freetrial)都会获得[$ 300 的信用额](https://console.cloud.google.com/freetrial) ,并且与 Google 合作,GitLab 能够为新的 GCP 帐户提供额外的$ 200,以开始使用 GitLab 的 Google Kubernetes Engine Integration. 您所要做的就是[点击此链接](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form)并申请信贷.
## Before you begin[](#before-you-begin "Permalink")
在使用 GitLab [添加 Kubernetes 集群](#create-new-cluster)之前,您需要:
* GitLab 本身. 要么:
* 一个[GitLab.com 帐户](https://about.gitlab.com/pricing/#gitlab-com) .
* 使用 GitLab 12.5 或更高版本的[自我管理安装](https://about.gitlab.com/pricing/#self-managed) . 这将确保 GitLab UI 可用于创建集群.
* 以下 GitLab 访问:
* [维护者](../../permissions.html#project-members-permissions)对项目级集群的项目[访问](../../permissions.html#project-members-permissions) .
* [维护者](../../permissions.html#group-members-permissions)对组级别集群的[访问权限](../../permissions.html#group-members-permissions) .
* 自我管理的实例级别群集的管理[区域访问](../../admin_area/index.html) .
## Access controls[](#access-controls "Permalink")
在 GitLab 中创建集群时,系统会询问您是否要创建以下任一集群:
* A [Role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) cluster.
* An [Attribute-based access control (ABAC)](https://kubernetes.io/docs/reference/access-authn-authz/abac/) cluster.
**注意:**建议使用[RBAC](#rbac-cluster-resources) ,GitLab 为默认值.
GitLab 创建必要的服务帐户和特权,以安装和运行[GitLab 托管的应用程序](index.html#installing-applications) . 当 GitLab 创建集群时,将在`default`名称空间中创建具有`cluster-admin`特权的`gitlab`服务帐户,以管理新创建的集群.
**注意:**用于部署的受限服务帐户是在 GitLab 11.5 中[引入的](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) .
The first time you install an application into your cluster, the `tiller` service account is created with `cluster-admin` privileges in the `gitlab-managed-apps` namespace. This service account will be used by Helm to install and run [GitLab managed applications](index.html#installing-applications).
Helm 还将为每个已安装的应用程序创建其他服务帐户和其他资源. 有关每个应用程序,请查阅 Helm 图表的文档.
如果要[添加现有的 Kubernetes 集群](add_remove_clusters.html#add-existing-cluster) ,请确保该帐户的令牌具有该集群的管理员特权.
GitLab 创建的资源取决于集群的类型.
### Important notes[](#important-notes "Permalink")
请注意以下有关访问控制的内容:
* 仅当集群[由 GitLab 管理时,](index.html#gitlab-managed-clusters)才会创建特定于环境的资源.
* 如果您的集群是在 GitLab 12.2 之前创建的,它将为所有项目环境使用单个名称空间.
### RBAC cluster resources[](#rbac-cluster-resources "Permalink")
GitLab 为 RBAC 集群创建以下资源.
| Name | Type | Details | 创建时间 |
| --- | --- | --- | --- |
| `gitlab` | `ServiceAccount` | `default` namespace | 创建一个新集群 |
| `gitlab-admin` | `ClusterRoleBinding` | [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) roleRef | 创建一个新集群 |
| `gitlab-token` | `Secret` | `gitlab` ServiceAccount 的令牌 | 创建一个新集群 |
| `tiller` | `ServiceAccount` | `gitlab-managed-apps` namespace | 安装舵图 |
| `tiller-admin` | `ClusterRoleBinding` | `cluster-admin` roleRef | 安装舵图 |
| 环境名称空间 | `Namespace` | 包含所有特定于环境的资源 | 部署到集群 |
| 环境名称空间 | `ServiceAccount` | 使用环境的名称空间 | 部署到集群 |
| 环境名称空间 | `Secret` | 环境 ServiceAccount 的令牌 | 部署到集群 |
| 环境名称空间 | `RoleBinding` | [`edit`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) roleRef | 部署到集群 |
### ABAC cluster resources[](#abac-cluster-resources "Permalink")
GitLab 为 ABAC 群集创建以下资源.
| Name | Type | Details | 创建时间 |
| --- | --- | --- | --- |
| `gitlab` | `ServiceAccount` | `default` namespace | 创建一个新集群 |
| `gitlab-token` | `Secret` | `gitlab` ServiceAccount 的令牌 | 创建一个新集群 |
| `tiller` | `ServiceAccount` | `gitlab-managed-apps` namespace | 安装舵图 |
| `tiller-admin` | `ClusterRoleBinding` | `cluster-admin` roleRef | 安装舵图 |
| 环境名称空间 | `Namespace` | 包含所有特定于环境的资源 | 部署到集群 |
| 环境名称空间 | `ServiceAccount` | 使用环境的名称空间 | 部署到集群 |
| 环境名称空间 | `Secret` | 环境 ServiceAccount 的令牌 | 部署到集群 |
### Security of GitLab Runners[](#security-of-gitlab-runners "Permalink")
GitLab Runners 默认情况[](https://docs.gitlab.com/runner/executors/docker.html)启用了[特权模式](https://docs.gitlab.com/runner/executors/docker.html) ,这使他们可以执行特殊命令并在 Docker 中运行 Docker. 运行某些[Auto DevOps](../../../topics/autodevops/index.html)作业需要此功能. 这意味着容器正在特权模式下运行,因此,您应该注意一些重要的细节.
特权标志为正在运行的容器提供了所有功能,而容器又可以执行主机可以执行的几乎所有操作. 请注意与对任意映像执行`docker run`操作相关的固有安全风险,因为它们有效地具有 root 用户访问权限.
如果您不想在特权模式下使用 GitLab Runner,请执行以下任一操作:
* 在 GitLab.com 上使用共享的跑步者. 他们没有这个安全问题.
* 使用[Shared Runners 中](../../gitlab_com/index.html#shared-runners)描述的配置来设置自己的[Runners](../../gitlab_com/index.html#shared-runners) . 这涉及:
1. 确保您没有通过[应用程序](index.html#installing-applications)安装它.
2. [使用`docker+machine`](https://docs.gitlab.com/runner/executors/docker_machine.html)安装 Runner.
## Create new cluster[](#create-new-cluster "Permalink")
可以使用 Google Kubernetes Engine(GKE)上的 GitLab 或 Amazon Elastic Kubernetes Service(EKS)在项目,组或实例级别上创建新集群:
1. 导航到您的:
* 项目的 **操作> Kubernetes**页面,用于项目级集群.
* 组的 **Kubernetes**页面,用于组级别集群.
* **管理区>** **Kubernetes**页面,用于实例级集群.
2. Click **添加 Kubernetes 集群**.
3. 单击**创建新集群**选项卡.
4. 单击**Amazon EKS****Google GKE** ,然后按照说明提供所需的服务:
* [亚马逊 EKS](add_eks_clusters.html#new-eks-cluster) .
* [Google GKE](add_gke_clusters.html#creating-the-cluster-on-gke) .
## Add existing cluster[](#add-existing-cluster "Permalink")
如果您已有 Kubernetes 集群,则可以将其添加到项目,组或实例中.
**注意:** arm64 集群不支持 Kubernetes 集成. 有关详细信息,请参阅问题[Helm Tiller 无法在 arm64 群集上安装](https://gitlab.com/gitlab-org/gitlab/-/issues/29838) .
### Existing Kubernetes cluster[](#existing-kubernetes-cluster "Permalink")
要将 Kubernetes 集群添加到您的项目,组或实例:
1. 导航到您的:
1. 项目的 **操作> Kubernetes**页面,用于项目级集群.
2. 组的 **Kubernetes**页面,用于组级别集群.
3. **管理区>** **Kubernetes**页面,用于实例级集群.
2. Click **添加 Kubernetes 集群**.
3. 单击**添加现有集群**选项卡,然后填写详细信息:
1. **Kubernetes 集群名称** (必填)-您希望为**集群指定**的名称.
2. **环境范围** (必需)- [](index.html#setting-the-environment-scope-premium)此集群[相关的环境](index.html#setting-the-environment-scope-premium) .
3. **API URL** (必填)-这是 GitLab 用于访问 Kubernetes API 的 URL. Kubernetes 公开了几个 API,我们想要所有这些 API 通用的"基本" URL. 例如, `https://kubernetes.example.com`而不是`https://kubernetes.example.com/api/v1` .
通过运行以下命令获取 API URL:
```
kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'
```
4. **CA 证书** (必需)-需要有效的 Kubernetes 证书才能对集群进行身份验证. 我们将使用默认创建的证书.
1. 列出带有`kubectl get secrets` ,并且应将其命名类似于`default-token-xxxxx` . 复制该令牌名称以在下面使用.
2. 通过运行以下命令获取证书:
```
kubectl get secret <secret name> -o jsonpath = "{['data']['ca \. crt']}" | base64 --decode
```
**注意:**如果命令返回整个证书链,则需要在证书链的底部复制*根 ca*证书.
5. **令牌** -GitLab 使用服务令牌对 Kubernetes 进行身份验证,服务令牌的作用域是特定的`namespace` . **使用的令牌应属于具有[`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)特权的服务帐户.** 要创建此服务帐户:
1. 创建一个名为`gitlab-admin-service-account.yaml` ,其内容为:
```
apiVersion : v1 kind : ServiceAccount metadata : name : gitlab-admin namespace : kube-system --- apiVersion : rbac.authorization.k8s.io/v1beta1 kind : ClusterRoleBinding metadata : name : gitlab-admin roleRef : apiGroup : rbac.authorization.k8s.io kind : ClusterRole name : cluster-admin subjects : - kind : ServiceAccount name : gitlab-admin namespace : kube-system
```
2. 将服务帐户和群集角色绑定应用于您的群集:
```
kubectl apply -f gitlab-admin-service-account.yaml
```
您将需要`container.clusterRoleBindings.create`权限来创建集群级角色. 如果您没有此权限,则可以选择启用基本身份验证,然后以管理员身份运行`kubectl apply`命令:
```
kubectl apply -f gitlab-admin-service-account.yaml --username = admin --password = <password>
```
**注意:**可以打开基本身份验证,并可以使用 Google Cloud Console 获取密码凭据.
输出:
```
serviceaccount "gitlab-admin" created clusterrolebinding "gitlab-admin" created
```
3. 检索`gitlab-admin`服务帐户的令牌:
```
kubectl -n kube-system describe secret $( kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}' )
```
从输出中复制`<authentication_token>`值:
```
Name : gitlab-admin-token-b5zv4 Namespace : kube-system Labels : <none> Annotations : kubernetes.io/service-account.name=gitlab-admin kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8 Type : kubernetes.io/service-account-token Data ==== ca.crt : 1025 bytes namespace : 11 bytes token : <authentication_token>
```
**注意:**对于 GKE 群集,您将需要`container.clusterRoleBindings.create`权限来创建群集角色绑定. 您可以按照[Google Cloud 文档](https://cloud.google.com/iam/docs/granting-changing-revoking-access)授予访问权限.
6. **由 GitLab 管理的群集** -如果要让 GitLab 管理该群集的名称空间和服务帐户,请选中此复选框. 有关更多信息,请参见[托管集群部分](index.html#gitlab-managed-clusters) .
7. **项目名称空间** (可选)-您不必填写它; 将其保留为空白,GitLab 将为您创建一个. 也:
* 每个项目应具有唯一的名称空间.
* 如果您正在使用具有更广泛权限的机密(例如`default`的机密),则项目名称空间不一定是机密的名称空间.
* 你**不**应该使用`default`为项目命名空间.
* 如果您或某人为项目专门创建了一个秘密(通常具有有限的权限),则该秘密的名称空间和项目名称空间可能是相同的.
4. 最后,单击**创建 Kubernetes 集群**按钮.
几分钟后,您的集群将准备就绪. 现在,您可以继续安装一些[预定义的应用程序](index.html#installing-applications) .
#### Disable Role-Based Access Control (RBAC) (optional)[](#disable-role-based-access-control-rbac-optional "Permalink")
通过 GitLab 集成连接集群时,您可以指定集群是否支持 RBAC. 这将影响 GitLab 如何与集群进行某些操作的交互. 如果您在创建时*未*选中**启用 RBAC 的群集**复选框,则 GitLab 将假定与群集进行交互时禁用了 RBAC. 如果是这样,则必须在群集上禁用 RBAC 才能使集成正常工作.
[![rbac](img/9d9a196fe723b5afc79e2d7b29fd0f4d.png)](img/rbac_v13_1.png)
**注意:**禁用 RBAC 意味着群集中运行的任何应用程序或可以向群集进行身份验证的用户都具有完全的 API 访问权限. 这是一个[安全问题](index.html#security-implications) ,可能不是所希望的.
为了有效地禁用 RBAC,可以应用全局权限来授予完全访问权限:
```
kubectl create clusterrolebinding permissive-binding \
--clusterrole=cluster-admin \
--user=admin \
--user=kubelet \
--group=system:serviceaccounts
```
## Enabling or disabling integration[](#enabling-or-disabling-integration "Permalink")
成功创建新集群或添加现有集群后,即可启用 Kubernetes 集群集成. 要禁用 Kubernetes 集群集成:
1. 导航到您的:
* 项目的 **操作> Kubernetes**页面,用于项目级集群.
* 组的 **Kubernetes**页面,用于组级别集群.
* **管理区>** **Kubernetes**页面,用于实例级集群.
2. 单击群集的名称.
3. 单击**GitLab 集成**切换.
4. Click **保存更改**.
## Removing integration[](#removing-integration "Permalink")
要从您的项目中删除 Kubernetes 集群集成,请首先导航到集群详细信息页面的**Advanced Settings**选项卡,然后执行以下任一操作:
* 选择**删除集成** ,仅删除 Kubernetes 集成.
* [从 GitLab 12.6 中](https://gitlab.com/gitlab-org/gitlab/-/issues/26815) ,选择**删除集成和资源** ,以在**删除集成时**也删除所有相关的 GitLab 集群资源(例如,名称空间,角色和绑定).
删除集群集成时,请注意:
* 您需要具有维护人员及以上[权限](../../permissions.html)才能删除 Kubernetes 集群集成.
* 删除集群时,只删除其与 GitLab 的关系,而不删除集群本身. 要删除集群,可以通过访问 GKE 或 EKS 仪表板或使用`kubectl``kubectl` .
## Learn more[](#learn-more "Permalink")
要了解有关自动部署应用程序的更多信息,请阅读有关[Auto DevOps](../../../topics/autodevops/index.html) .
\ No newline at end of file
# Adding EKS clusters
> 原文:[https://docs.gitlab.com/ee/user/project/clusters/add_eks_clusters.html](https://docs.gitlab.com/ee/user/project/clusters/add_eks_clusters.html)
* [EKS requirements](#eks-requirements)
* [Additional requirements for self-managed instances](#additional-requirements-for-self-managed-instances-core-only)
* [New EKS cluster](#new-eks-cluster)
* [Troubleshooting creating a new cluster](#troubleshooting-creating-a-new-cluster)
* [Error: Request failed with status code 422](#error-request-failed-with-status-code-422)
* [Could not load Security Groups for this VPC](#could-not-load-security-groups-for-this-vpc)
* [`ROLLBACK_FAILED` during cluster creation](#rollback_failed-during-cluster-creation)
* [Existing EKS cluster](#existing-eks-cluster)
* [Create a default Storage Class](#create-a-default-storage-class)
* [Deploy the app to EKS](#deploy-the-app-to-eks)
# Adding EKS clusters[](#adding-eks-clusters "Permalink")
GitLab 支持添加新的和现有的 EKS 集群.
## EKS requirements[](#eks-requirements "Permalink")
在通过 GitLab 集成在 Amazon EKS 上创建第一个集群之前,请确保满足以下要求:
* 设置了[Amazon Web Services](https://aws.amazon.com/)帐户,您就可以登录.
* 您有权管理 IAM 资源.
* 如果要使用[现有的 EKS 集群](#existing-eks-cluster)
* 已正确配置工作节点的 Amazon EKS 集群.
* [安装并配置](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#get-started-kubectl)`kubectl`以访问 EKS 集群.
### Additional requirements for self-managed instances[](#additional-requirements-for-self-managed-instances-core-only "Permalink")
如果您使用自我管理的 GitLab 实例,则必须首先使用一组 Amazon 凭证配置 GitLab. 这些凭证将用于承担创建集群的用户提供的 Amazon IAM 角色. 创建一个 IAM 用户,并确保其有权承担您的用户将用来创建 EKS 群集的角色.
例如,以下策略文档允许在帐户`123456789012`假设一个角色的名称以`gitlab-eks-`
```
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/gitlab-eks-*" } }
```
为 IAM 用户生成访问密钥,并使用凭据配置 GitLab:
1. 导航至**管理区域>设置>集成,**然后展开**Amazon EKS**部分.
2. Check **启用 Amazon EKS 集成**.
3. 在相应的`Account ID``Access key ID``Secret access key`字段中输入帐户 ID 和访问密钥凭据.
4. Click **保存更改**.
## New EKS cluster[](#new-eks-cluster "Permalink")
在 GitLab 12.5 中[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/22392) .
要创建新的 Kubernetes 集群并将其添加到您的项目,组或实例:
1. 导航到您的:
* 项目的 **操作> Kubernetes**页面,用于项目级集群.
* 组的 **Kubernetes**页面,用于组级别集群.
* **管理区>** **Kubernetes** ,用于实例级集群.
2. Click **添加 Kubernetes 集群**.
3. 在" **创建新集群"**选项卡下,单击**Amazon EKS** . 将为您提供一个`Account ID``External ID` ,供下一步使用.
4.[IAM 管理控制台中](https://console.aws.amazon.com/iam/home) ,创建一个 IAM 角色:
1. 在左侧面板中,选择**角色** .
2. 单击**创建角色** .
3.`Select type of trusted entity` ,选择**另一个 AWS 账户** .
4. 在 GitLab 中的`Account ID`字段中输入`Account ID` .
5. 选中**需要外部 ID** .
6. 在 GitLab 中将`External ID`输入到`External ID`字段中.
7. 单击**下一步:权限** .
8. 点击**创建策略** ,这将打开一个新窗口.
9. 选择**JSON**标签,然后粘贴以下代码段代替现有内容:
```
{
"Version" : "2012-10-17" ,
"Statement" : [
{
"Effect" : "Allow" ,
"Action" : [
"autoscaling:CreateAutoScalingGroup" ,
"autoscaling:DescribeAutoScalingGroups" ,
"autoscaling:DescribeScalingActivities" ,
"autoscaling:UpdateAutoScalingGroup" ,
"autoscaling:CreateLaunchConfiguration" ,
"autoscaling:DescribeLaunchConfigurations" ,
"cloudformation:CreateStack" ,
"cloudformation:DescribeStacks" ,
"ec2:AuthorizeSecurityGroupEgress" ,
"ec2:AuthorizeSecurityGroupIngress" ,
"ec2:RevokeSecurityGroupEgress" ,
"ec2:RevokeSecurityGroupIngress" ,
"ec2:CreateSecurityGroup" ,
"ec2:createTags" ,
"ec2:DescribeImages" ,
"ec2:DescribeKeyPairs" ,
"ec2:DescribeRegions" ,
"ec2:DescribeSecurityGroups" ,
"ec2:DescribeSubnets" ,
"ec2:DescribeVpcs" ,
"eks:CreateCluster" ,
"eks:DescribeCluster" ,
"iam:AddRoleToInstanceProfile" ,
"iam:AttachRolePolicy" ,
"iam:CreateRole" ,
"iam:CreateInstanceProfile" ,
"iam:CreateServiceLinkedRole" ,
"iam:GetRole" ,
"iam:ListRoles" ,
"iam:PassRole" ,
"ssm:GetParameters"
],
"Resource" : "*"
}
]
}
```
**注意:**这些权限使 GitLab 能够创建资源,但不能删除它们. 这意味着,如果在创建过程中遇到错误,更改将不会回滚,您必须手动删除资源. 您可以通过删除相关的[CloudFormation 堆栈](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)来做到这一点
10. 点击**审核政策** .
11. 为此策略输入合适的名称,然后点击**创建策略** . 您现在可以关闭此窗口.
12. 切换回"创建角色"窗口,然后选择刚创建的策略.
13. 单击**下一步:标签** ,并选择输入您希望与此角色关联的任何标签.
14. 单击**下一步:查看** .
15. 在提供的字段中输入角色名称和可选描述.
16. 点击**创建角色** ,新角色名称将显示在顶部. 单击其名称,然后从新创建的角色复制`Role ARN` .
5. 在 GitLab 中,将复制的角色 ARN 输入到`Role ARN`字段中.
6. Click **使用 AWS 进行身份验证**.
7. 选择集群的设置:
* **Kubernetes 集群名称** -您希望赋予集群的名称.
* **环境范围** -该集群的[关联环境](index.html#setting-the-environment-scope-premium) .
* **Kubernetes 版本** -要使用的 Kubernetes 版本. 当前唯一支持的版本是 1.14\.
* **角色名称** -选择[IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html)以允许 Amazon EKS 和 Kubernetes 控制平面代表您管理 AWS 资源. 此 IAM 角色与上面创建的 IAM 角色是分开的,如果尚不存在,则需要创建它.
* **区域** -将在其中创建群集的[区域](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) .
* **密钥对名称** -如果需要,选择可用于连接到工作节点的[密钥对](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) .
* **VPC-**选择要用于 EKS 群集资源的[VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) .
* **子网** -在您的 VPC 中选择运行工作节点的[子网](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html) . 您必须至少选择两个.
* **安全组** -选择[安全组](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)以应用到在工作节点子网中创建的 EKS 管理的弹性网络接口.
* **实例类型** -工作节点的[实例类型](https://aws.amazon.com/ec2/instance-types/) .
* **节点数** -工作节点数.
* **由 GitLab 管理的群集** -如果要让 GitLab 管理该群集的名称空间和服务帐户,请选中此复选框. 有关更多信息,请参见[托管集群部分](index.html#gitlab-managed-clusters) .
8. 最后,单击**创建 Kubernetes 集群**按钮.
大约 10 分钟后,您的集群便可以使用了. 现在,您可以继续安装一些[预定义的应用程序](index.html#installing-applications) .
**注意:**您需要将 AWS 外部 ID 添加到[AWS CLI 中](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount)[IAM 角色,](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount)才能使用`kubectl`管理集群.
### Troubleshooting creating a new cluster[](#troubleshooting-creating-a-new-cluster "Permalink")
创建新集群时,通常会遇到以下错误.
#### Error: Request failed with status code 422[](#error-request-failed-with-status-code-422 "Permalink")
提交初始身份验证表单时,如果无法确定您提供的角色,则 GitLab 会返回状态码 422 错误. 确保已使用 GitLab 提供的**帐户 ID****外部 ID**正确配置了角色. 在 GitLab 中,确保输入正确的**Role ARN** .
#### Could not load Security Groups for this VPC[](#could-not-load-security-groups-for-this-vpc "Permalink")
当在配置表单中填充选项时,GitLab 将返回此错误,因为 GitLab 已成功承担了您提供的角色,但是该角色没有足够的权限来检索表单所需的资源. 确保已为角色分配了正确的权限.
#### `ROLLBACK_FAILED` during cluster creation[](#rollback_failed-during-cluster-creation "Permalink")
由于 GitLab 在创建一个或多个资源时遇到错误,因此创建过程停止. 您可以检查关联的[CloudFormation 堆栈](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)以查找创建失败的特定资源.
如果`Cluster`资源因错误`The provided role doesn't have the Amazon EKS Managed Policies associated with it.`失败,则`The provided role doesn't have the Amazon EKS Managed Policies associated with it.`**角色名称**中指定的**角色**配置不正确.
**注意:**此角色不应与上面创建的角色相同. 如果您没有现有的[EKS 群集 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html) ,则必须创建一个.
## Existing EKS cluster[](#existing-eks-cluster "Permalink")
有关添加现有 EKS 群集的信息,请参阅" [现有 Kubernetes 群集"](add_remove_clusters.html#existing-kubernetes-cluster) .
### Create a default Storage Class[](#create-a-default-storage-class "Permalink")
Amazon EKS 没有开箱即用的默认存储类,这意味着对持久卷的请求将不会自动满足. 作为 Auto DevOps 的一部分,已部署的 PostgreSQL 实例将请求持久存储,并且如果没有默认存储类,它将无法启动.
如果默认的存储类尚不存在并且需要使用,请按照 Amazon 的[存储类指南](https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html)创建一个.
或者,通过将项目变量[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.html#environment-variables)设置为`false`来禁用 PostgreSQL.
### Deploy the app to EKS[](#deploy-the-app-to-eks "Permalink")
在禁用 RBAC 和部署服务的情况下,现在可以利用[Auto DevOps](../../../topics/autodevops/index.html)构建,测试和部署应用程序.
如果尚未启用,则[启用 Auto DevOps](../../../topics/autodevops/index.html#at-the-project-level) . 如果创建了通配符 DNS 条目以解析到负载均衡器,请在"自动 DevOps"设置下的" `domain`字段中输入它. 否则,已部署的应用程序将无法在群集外部从外部获得.
[![Deploy Pipeline](img/de608fa9aefa963f38d0d95043413679.png)](img/pipeline.png)
将自动创建一个新管道,该管道将开始构建,测试和部署该应用程序.
管道完成后,您的应用将在 EKS 中运行,并可供用户使用. 单击**CI / CD>环境** .
[![Deployed Environment](img/dc47374cec4da1de3e6476346ecf738e.png)](img/environment.png)
您将看到环境及其部署状态的列表,以及浏览到应用程序,查看监视指标甚至访问正在运行的 Pod 上的 Shell 的选项.
\ No newline at end of file
# Adding GKE clusters
> 原文:[https://docs.gitlab.com/ee/user/project/clusters/add_gke_clusters.html](https://docs.gitlab.com/ee/user/project/clusters/add_gke_clusters.html)
* [GKE requirements](#gke-requirements)
* [New GKE cluster](#new-gke-cluster)
* [Creating the cluster on GKE](#creating-the-cluster-on-gke)
* [Cloud Run for Anthos](#cloud-run-for-anthos)
* [Existing GKE cluster](#existing-gke-cluster)
# Adding GKE clusters[](#adding-gke-clusters "Permalink")
GitLab 支持添加新的和现有的 GKE 集群.
## GKE requirements[](#gke-requirements "Permalink")
在通过 GitLab 集成在 Google GKE 上创建第一个集群之前,请确保满足以下要求:
* 设置了具有访问权限的[结算帐户](https://cloud.google.com/billing/docs/how-to/manage-billing-account) .
* 启用了 Kubernetes Engine API 和相关服务. 它应该可以立即工作,但是创建项目后最多可能需要 10 分钟. 有关更多信息,请参见[Kubernetes Engine 文档](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin)["开始之前"部分](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin) .
## New GKE cluster[](#new-gke-cluster "Permalink")
[GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/25925)开始, [GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/25925)提供的所有 GKE 群集均为[VPC 本地的](https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips) .
请注意以下几点:
* 必须在实例级别的 GitLab 中启用[Google 身份验证集成](../../../integration/google.html) . 如果不是这种情况,请要求您的 GitLab 管理员启用它. 在 GitLab.com 上启用了此功能.
*[GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55902)开始,由[GitLab](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55902)创建的所有 GKE 集群都启用了 RBAC. 请参阅[RBAC 部分](add_remove_clusters.html#rbac-cluster-resources)以获取更多信息.
*[GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18341)开始,群集的 Pod 地址 IP 范围将设置为/ 16,而不是常规的/ 14\. / 16 是 CIDR 表示法.
* GitLab 要求启用基本身份验证并为集群颁发客户端证书,以设置[初始服务帐户](add_remove_clusters.html#access-controls) . 在[GitLab 11.10 及更高版本中](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58208) ,集群创建过程明确要求 GKE 创建启用了基本身份验证和客户端证书的集群.
### Creating the cluster on GKE[](#creating-the-cluster-on-gke "Permalink")
要创建新的 Kubernetes 集群并将其添加到您的项目,组或实例:
1. 导航到您的:
* 项目的 **操作> Kubernetes**页面,用于项目级集群.
* 组的 **Kubernetes**页面,用于组级别集群.
* **管理区>** **Kubernetes**页面,用于实例级集群.
2. Click **添加 Kubernetes 集群**.
3. 在[ **建立新丛集]**标签下,按一下[ **Google GKE]** .
4. 如果尚未连接 Google 帐户,请单击" **使用 Google 登录"**按钮.
5. 选择集群的设置:
* **Kubernetes 集群名称** -您希望赋予集群的名称.
* **环境范围** -该集群的[关联环境](index.html#setting-the-environment-scope-premium) .
* **Google Cloud Platform 项目** -选择您在 GCP 控制台中创建的将托管 Kubernetes 集群的项目. 了解有关[Google Cloud Platform 项目的](https://cloud.google.com/resource-manager/docs/creating-managing-projects)更多信息.
* **区域** -选择将在其下创建群集的[区域区域](https://cloud.google.com/compute/docs/regions-zones/) .
* **节点数** -输入希望群集具有的节点数.
* **计算机类型** -群集将基于的虚拟机实例的[计算机类型](https://cloud.google.com/compute/docs/machine-types) .
* **为 Anthos 启用 Cloud Run-**如果要对此集群使用 Cloud Run for Anthos,请选中此复选框. 有关更多信息,请参见[Anthos](#cloud-run-for-anthos)[Cloud Run 部分](#cloud-run-for-anthos) .
* **由 GitLab 管理的群集** -如果要让 GitLab 管理该群集的名称空间和服务帐户,请选中此复选框. 有关更多信息,请参见[托管集群部分](index.html#gitlab-managed-clusters) .
6. 最后,单击**创建 Kubernetes 集群**按钮.
几分钟后,您的集群将准备就绪. 现在,您可以继续安装一些[预定义的应用程序](index.html#installing-applications) .
### Cloud Run for Anthos[](#cloud-run-for-anthos "Permalink")
在 GitLab 12.4 中[引入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16566) .
创建群集后,可以选择使用 Cloud Run for Anthos 代替分别安装 Knative 和 Istio. 这意味着将在创建时在集群上启用 Cloud Run(Knative),Istio 和 HTTP Load Balancing,并且不能单独[安装或卸载](../../clusters/applications.html) .
## Existing GKE cluster[](#existing-gke-cluster "Permalink")
有关添加现有 GKE 群集的信息,请参阅" [现有 Kubernetes 群集"](add_remove_clusters.html#existing-kubernetes-cluster) .
\ No newline at end of file
# 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).
\ No newline at end of file
# Instance-level Kubernetes clusters
> 原文:[https://docs.gitlab.com/ee/user/instance/clusters/](https://docs.gitlab.com/ee/user/instance/clusters/)
* [Overview](#overview)
* [Cluster precedence](#cluster-precedence)
* [Cluster environments](#cluster-environments-premium)
* [More information](#more-information)
# Instance-level Kubernetes clusters[](#instance-level-kubernetes-clusters "Permalink")
在 GitLab 11.11 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/39840) .
## Overview[](#overview "Permalink")
[项目级](../../project/clusters/index.html)[组级](../../group/clusters/index.html) Kubernetes 集群类似,实例级 Kubernetes 集群允许您将 Kubernetes 集群连接到 GitLab 实例,这使您可以在多个项目中使用同一集群.
## Cluster precedence[](#cluster-precedence "Permalink")
GitLab 将尝试按以下顺序匹配集群:
* 项目级集群.
* 组级别群集.
* 实例级集群.
要选择集群,必须启用集群并使其与[环境选择器](../../../ci/environments/index.html#scoping-environments-with-specs)匹配.
## Cluster environments[](#cluster-environments-premium "Permalink")
有关将哪种 CI [环境](../../../ci/environments/index.html)部署到 Kubernetes 集群的统一视图,请参阅[集群环境](../../clusters/environments.html)文档.
## More information[](#more-information "Permalink")
有关集成 GitLab 和 Kubernetes 的信息,此[Kubernetes 集群](../../project/clusters/index.html) .
\ No newline at end of file
# Canary Deployments
> 原文:[https://docs.gitlab.com/ee/user/project/canary_deployments.html](https://docs.gitlab.com/ee/user/project/canary_deployments.html)
* [Overview](#overview)
* [Use cases](#use-cases)
* [Enabling Canary Deployments](#enabling-canary-deployments)
# Canary Deployments[](#canary-deployments-premium "Permalink")
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1659) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.1.
一种流行的[持续部署](https://en.wikipedia.org/wiki/Continuous_deployment)策略,其中将一小部分机队更新为应用程序的新版本.
## Overview[](#overview "Permalink")
在采用[持续交付时](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) ,公司需要决定要使用哪种部署策略. 最受欢迎的策略之一是金丝雀部署,首先将一小部分机队更新为新版本. 金丝雀的这个子集,然后在煤矿中成为众所周知的[金丝雀](https://en.wiktionary.org/wiki/canary_in_a_coal_mine) .
如果应用程序的新版本存在问题,则仅会影响一小部分用户,并且可以固定更改或快速还原更改.
利用[Kubernetes 的 Canary 部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) ,无需离开 GitLab,即可在[Deploy Board](deploy_boards.html)内部可视化您的 Canary 部署.
## Use cases[](#use-cases "Permalink")
当您只想向部分 Pod 舰队提供功能并观看其行为时,可以使用 Canary 部署. 如果一切正常,您可以将该功能部署到生产中,因为它不会造成任何问题.
Canary 部署对于后端重构,性能改进或用户界面不变的其他更改也特别有用,但是您要确保性能保持不变或有所提高. 开发人员在使用面向用户的更改的 Canary 时需要谨慎,因为默认情况下,来自同一用户的请求将随机分布在 Canary 和非 Canary Pod 之间,这可能导致混乱甚至错误. 如果需要,您可能需要考虑[在 Kubernetes 服务定义中将`service.spec.sessionAffinity`设置为`ClientIP`](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) ,但这超出了本文档的范围.
## Enabling Canary Deployments[](#enabling-canary-deployments "Permalink")
Canary 部署要求您正确配置 Deploy Boards:
1. 请按照以下步骤[启用 Deploy Boards](deploy_boards.html#enabling-deploy-boards) .
2. 要跟踪 canary 部署,您需要使用`track: canary`标记 Kubernetes 部署和 Pod. 为了快速入门,您可以将[自动部署](../../topics/autodevops/stages.html#auto-deploy)模板用于 GitLab 提供的金丝雀部署.
根据部署情况,标签应该是`stable``canary` . 通常, `stable`且空白或丢失的标签表示同一件事,而`canary`或任何其他轨道表示金丝雀/临时. 这使 GitLab 能够发现部署是稳定的还是金丝雀(临时)的.
完成以上所有设置并且管道至少运行了一次之后,导航至" **管道">"环境"**下的环境页面. 随着管道的执行,部署委员会将清楚地标记金丝雀荚,从而可以快速,轻松地洞察每种环境和部署的状态.
Canary deployments are marked with a yellow dot in the Deploy Board so that you can easily notice them.
[![Canary deployments on Deploy Board](img/9a002df90c6ed1d01c8ae3a9817242df.png)](img/deploy_boards_canary_deployments.png)
\ No newline at end of file
# Cluster Environments
> 原文:[https://docs.gitlab.com/ee/user/clusters/environments.html](https://docs.gitlab.com/ee/user/clusters/environments.html)
* [Overview](#overview)
* [Usage](#usage)
# Cluster Environments[](#cluster-environments-premium "Permalink")
> * 在[GitLab Premium](https://about.gitlab.com/pricing/) 12.3 中针对组级集群[引入](https://gitlab.com/gitlab-org/gitlab/-/issues/13392) .
> * 在[GitLab Premium](https://about.gitlab.com/pricing/) 12.4 中针对实例级集群进行了[介绍](https://gitlab.com/gitlab-org/gitlab/-/issues/14809) .
群集环境提供了一个统一的视图,用于说明将哪些 CI [环境](../../ci/environments/index.html)部署到 Kubernetes 群集及其:
* 显示项目和与部署相关的相关环境.
* 显示该环境的窗格的状态.
## Overview[](#overview "Permalink")
使用集群环境,您可以深入了解:
* 哪些项目已部署到集群.
* 每个项目的环境使用了多少个 Pod.
* 用于部署到该环境的 CI 作业.
[![Cluster environments page](img/662e9b0c090a4f28c82eb779aabdc9c8.png)](img/cluster_environments_table_v12_3.png)
仅限集群[维护者和所有者](../permissions.html#group-members-permissions)访问集群环境
## Usage[](#usage "Permalink")
为了:
* 跟踪集群的环境,您必须成功[部署到 Kubernetes 集群](../project/clusters/index.html#deploying-to-a-kubernetes-cluster) .
* 正确显示容器使用情况,必须[启用 Deploy Boards](../project/deploy_boards.html#enabling-deploy-boards) .
成功部署到组级或实例级集群后:
1. 导航到您组的**Kubernetes**页面.
2. 单击**环境**选项卡.
**注意:**此页面仅包含成功部署到群集的信息. 非群集环境将不包括在内.
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
require(['gitbook', 'jquery'], function(gitbook, $) {
var SITES = {
'facebook': {
'label': 'Facebook',
'icon': 'fa fa-facebook',
'onClick': function(e) {
e.preventDefault();
window.open('http://www.facebook.com/sharer/sharer.php?s=100&p[url]='+encodeURIComponent(location.href));
}
},
'twitter': {
'label': 'Twitter',
'icon': 'fa fa-twitter',
'onClick': function(e) {
e.preventDefault();
window.open('http://twitter.com/home?status='+encodeURIComponent(document.title+' '+location.href));
}
},
'google': {
'label': 'Google+',
'icon': 'fa fa-google-plus',
'onClick': function(e) {
e.preventDefault();
window.open('https://plus.google.com/share?url='+encodeURIComponent(location.href));
}
},
'weibo': {
'label': 'Weibo',
'icon': 'fa fa-weibo',
'onClick': function(e) {
e.preventDefault();
window.open('http://service.weibo.com/share/share.php?content=utf-8&url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title));
}
},
'instapaper': {
'label': 'Instapaper',
'icon': 'fa fa-instapaper',
'onClick': function(e) {
e.preventDefault();
window.open('http://www.instapaper.com/text?u='+encodeURIComponent(location.href));
}
},
'vk': {
'label': 'VK',
'icon': 'fa fa-vk',
'onClick': function(e) {
e.preventDefault();
window.open('http://vkontakte.ru/share.php?url='+encodeURIComponent(location.href));
}
}
};
gitbook.events.bind('start', function(e, config) {
var opts = config.sharing;
// Create dropdown menu
var menu = $.map(opts.all, function(id) {
var site = SITES[id];
return {
text: site.label,
onClick: site.onClick
};
});
// Create main button with dropdown
if (menu.length > 0) {
gitbook.toolbar.createButton({
icon: 'fa fa-share-alt',
label: 'Share',
position: 'right',
dropdown: [menu]
});
}
// Direct actions to share
$.each(SITES, function(sideId, site) {
if (!opts[sideId]) return;
gitbook.toolbar.createButton({
icon: site.icon,
label: site.text,
position: 'right',
onClick: site.onClick
});
});
});
});
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
> 原文:[https://about.gitlab.com/install/](https://about.gitlab.com/install/)
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
../coffee-script/bin/cake
\ No newline at end of file
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册