Kubernetes clusters · Gitlab 中文文檔

# 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](https://img.kancloud.cn/aa/1a/aa1a0ce5054543cdef722c04793a0bd2_1928x920.png)](img/k8s_cluster_monitoring.png)