Add latest changes from gitlab-org/gitlab@13-0-stable-ee

1 files changed, 33 insertions, 9 deletions

diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index 74a58b93442..1298a24fcac 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -1,3 +1,9 @@
+---
+stage: Monitor
+group: APM
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+---
+
 # Kubernetes clusters
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/35954) in GitLab 10.1 for projects.
@@ -30,10 +36,28 @@ Using the GitLab project Kubernetes integration, you can:
 - View [Logs](#logs).
 - Run serverless workloads on [Kubernetes with Knative](serverless/index.md).
 
+### Supported cluster versions
+
+GitLab is committed to support at least two production-ready Kubernetes minor versions at any given time. We regularly review the versions we support, and provide a four-month deprecation period before we remove support of a specific version. The range of supported versions is based on the evaluation of:
+
+- Our own needs.
+- The versions supported by major managed Kubernetes providers.
+- The versions [supported by the Kubernetes community](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions).
+
+Currently, GitLab supports the following Kubernetes versions:
+
+- 1.15
+- 1.14
+- 1.13 (deprecated, support ends on November 22, 2020)
+- 1.12 (deprecated, support ends on September 22, 2020)
+
+NOTE: **Note:**
+Some GitLab features may support versions outside the range provided here.
+
 ### Deploy Boards **(PREMIUM)**
 
 GitLab's Deploy Boards offer a consolidated view of the current health and
-status of each CI [environment](../../../ci/environments.md) running on Kubernetes,
+status of each CI [environment](../../../ci/environments/index.md) running on Kubernetes,
 displaying the status of the pods in the deployment. Developers and other
 teammates can view the progress and status of a rollout, pod by pod, in the
 workflow they already use without any need to access Kubernetes.
@@ -78,8 +102,8 @@ Kubernetes clusters can be used without Auto DevOps.
 
 > Introduced in GitLab 8.15.
 
-When enabled, the Kubernetes integration adds [web terminal](../../../ci/environments.md#web-terminals)
-support to your [environments](../../../ci/environments.md). This is based on the `exec` functionality found in
+When enabled, the Kubernetes integration adds [web terminal](../../../ci/environments/index.md#web-terminals)
+support to your [environments](../../../ci/environments/index.md). This is based on the `exec` functionality found in
 Docker and Kubernetes, so you get a new shell session within your existing
 containers. To use this integration, you should deploy to Kubernetes using
 the deployment variables above, ensuring any deployments, replica sets, and
@@ -181,8 +205,8 @@ you can either:
 ### Setting the environment scope **(PREMIUM)**
 
 When adding more than one Kubernetes cluster to your project, you need to differentiate
-them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments.md) similar to how the
-[environment-specific variables](../../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables) work.
+them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments/index.md) similar to how the
+[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) work.
 
 The default environment scope is `*`, which means all jobs, regardless of their
 environment, will use that cluster. Each scope can only be used by a single
@@ -262,7 +286,7 @@ A Kubernetes cluster can be the destination for a deployment job. If
   the cluster from your jobs using tools such as `kubectl` or `helm`.
 - You don't use GitLab's cluster integration you can still deploy to your
   cluster. However, you will need configure Kubernetes tools yourself
-  using [environment variables](../../../ci/variables/README.md#creating-a-custom-environment-variable)
+  using [environment variables](../../../ci/variables/README.md#custom-environment-variables)
   before you can interact with the cluster from your jobs.
 
 ### Deployment variables
@@ -297,7 +321,7 @@ of the form `<project_name>-<project_id>-<environment>` (see [Deployment
 variables](#deployment-variables)).
 
 For **non**-GitLab-managed clusters, the namespace can be customized using
-[`environment:kubernetes:namespace`](../../../ci/environments.md#configuring-kubernetes-deployments)
+[`environment:kubernetes:namespace`](../../../ci/environments/index.md#configuring-kubernetes-deployments)
 in `.gitlab-ci.yml`.
 
 NOTE: **Note:** When using a [GitLab-managed cluster](#gitlab-managed-clusters), the
@@ -314,7 +338,7 @@ the deployment job:
 
 However, sometimes GitLab can not create them. In such instances, your job will fail with the message:
 
-```text
+```plaintext
 This job failed because the necessary resources were not successfully created.
 ```
 
@@ -325,7 +349,7 @@ Reasons for failure include:
 - The token you gave GitLab does not have [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
   privileges required by GitLab.
 - Missing `KUBECONFIG` or `KUBE_TOKEN` variables. To be passed to your job, they must have a matching
-  [`environment:name`](../../../ci/environments.md#defining-environments). If your job has no
+  [`environment:name`](../../../ci/environments/index.md#defining-environments). If your job has no
   `environment:name` set, it will not be passed the Kubernetes credentials.
 
 NOTE: **NOTE:**