Add latest changes from gitlab-org/gitlab@13-12-stable-eev13.12.0-rc42

6 files changed, 365 insertions, 88 deletions

diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index 31accfdd9e4..5e272f2a816 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -56,7 +56,7 @@ There are several components that work in concert for the Agent to accomplish Gi
 You can use the same GitLab project or separate projects for configuration and manifest files, as follows:
 
 - Single GitLab project (recommended): when you use a single repository to hold both the manifest and the configuration files, these projects can be either private or public, as you prefer.
-- Two GitLab projects: when you opt to use two different GitLab projects, one for manifest files, and another for configuration files, the manifests project must be private, while the configuration project can be either private or public. Our backlog contains issues for adding support for
+- Two GitLab projects: when you opt to use two different GitLab projects, one for manifest files, and another for configuration files, the manifests project must be public, while the configuration project can be either private or public. Our backlog contains issues for adding support for
 [private manifest repositories outside of the configuration project](https://gitlab.com/gitlab-org/gitlab/-/issues/220912) and
 [group level agents](https://gitlab.com/gitlab-org/gitlab/-/issues/283885) in the future.
 
@@ -100,27 +100,39 @@ To use the KAS:
 
 ### Define a configuration repository
 
-Next, you need a GitLab repository to contain your Agent configuration. The minimal
-repository layout looks like this:
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7, the Agent manifest configuration can be added to multiple directories (or subdirectories) of its repository.
+
+To configure an Agent, you need:
+
+1. A GitLab repository to hold the configuration file.
+1. Install the Agent in a cluster.
+
+After installed, when you update the configuration file, GitLab transmits the
+information to the cluster automatically without downtime.
+
+In your repository, add the Agent configuration file under:
 
 ```plaintext
 .gitlab/agents/<agent-name>/config.yaml
 ```
 
-Your `config.yaml` file can specify multiple manifest projects in the
-section `manifest_projects`:
+Your `config.yaml` file specifies all configurations of the Agent, such as:
+
+- The manifest projects to synchronize.
+- The address of the `hubble-relay` for the Network Security policy integrations.
+
+As an example, a minimal Agent configuration that sets up only the manifest
+synchronizations is:
 
 ```yaml
 gitops:
   manifest_projects:
-  - id: "path-to/your-manifest-project-number1"
-  ...
+  - id: "path-to/your-manifest-project-1"
+    paths:
+    - glob: '/**/*.{yaml,yml,json}'
 ```
 
-GitLab [versions 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) also
-supports manifest projects containing
-multiple directories (or subdirectories) of YAML files. For more information see our
-documentation on the [Kubernetes Agent configuration repository](repository.md).
+All the options for the [Kubernetes Agent configuration repository](repository.md) are documented separately.
 
 ### Create an Agent record in GitLab
 
@@ -158,8 +170,8 @@ the Agent in subsequent steps. You can create an Agent record with GraphQL:
   }
   ```
 
-  NOTE:
-  GraphQL only displays the token one time after creating it.
+WARNING:
+GraphQL only displays the token and ids **one time** after creating it. Make sure to write down the `secret`, `clusterAgentId`, and `clusterAgentTokenId`; you'll need them later.
 
   If you are new to using the GitLab GraphQL API, refer to the
   [Getting started with the GraphQL API page](../../../api/graphql/getting_started.md),
@@ -202,7 +214,7 @@ docker run --pull=always --rm registry.gitlab.com/gitlab-org/cluster-integration
 
 For more advanced configurations, we recommend to use [the `kpt` based installation method](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/tree/master/build/deployment/gitlab-agent).
 
-Otherwise, you can follow below for fully manual, detailed installation steps.
+Otherwise, follow the manual installation steps described below.
 
 ##### Create the Kubernetes secret
 
@@ -211,14 +223,14 @@ After generating the token, you must apply it to the Kubernetes cluster.
 To create your Secret, run:
 
 ```shell
-kubectl create secret generic -n <YOUR_NAMESPACE> gitlab-agent-token --from-literal=token='YOUR_AGENT_TOKEN'
+kubectl create secret generic -n gitlab-kubernetes-agent gitlab-kubernetes-agent-token --from-literal=token='YOUR_AGENT_TOKEN'
 ```
 
 The following example file contains the
 Kubernetes resources required for the Agent to be installed. You can modify this
 example [`resources.yml` file](#example-resourcesyml-file) in the following ways:
 
-- Replace `namespace: gitlab-agent` with `namespace: <YOUR-DESIRED-NAMESPACE>`.
+- Replace `namespace: gitlab-kubernetes-agent` with `namespace: <YOUR-DESIRED-NAMESPACE>`.
 - You can configure `kas-address` (Kubernetes Agent Server) in several ways.
   The agent can use the WebSockets or gRPC protocols to connect to the Agent Server.
   Select the option appropriate for your cluster configuration and GitLab architecture:
@@ -233,7 +245,7 @@ example [`resources.yml` file](#example-resourcesyml-file) in the following ways
     When using the Omnibus GitLab, specify the `ws` scheme (such as `ws://GitLab.host.tld:80/-/kubernetes-agent/`).
   - Specify the `grpc` scheme if both Agent and Server are installed in one cluster.
     In this case, you may specify `kas-address` value as
-    `grpc://gitlab-kas.<your-namespace>:5005`) to use gRPC directly, where `gitlab-kas`
+    `grpc://gitlab-kas.<your-namespace>:8150`) to use gRPC directly, where `gitlab-kas`
     is the name of the service created by `gitlab-kas` chart, and `your-namespace`
     is the namespace where the chart was installed. Encrypted gRPC is not supported yet.
     Follow the
@@ -243,47 +255,53 @@ example [`resources.yml` file](#example-resourcesyml-file) in the following ways
     Check the [chart's KAS Ingress documentation](https://docs.gitlab.com/charts/charts/gitlab/kas/#ingress)
     to learn more about it.
   - In the near future, Omnibus GitLab intends to provision `gitlab-kas` under a sub-domain by default, instead of the `/-/kubernetes-agent/` path. Please follow [this issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5784) for details.
-- If you defined your own secret name, replace `gitlab-agent-token` with your
+- If you defined your own secret name, replace `gitlab-kubernetes-agent-token` with your
   secret name in the `secretName:` section.
 
 To apply this file, run the following command:
 
 ```shell
-kubectl apply -n <YOUR-DESIRED-NAMESPACE> -f ./resources.yml
+kubectl apply -n gitlab-kubernetes-agent -f ./resources.yml
 ```
 
 To review your configuration, run the following command:
 
 ```shell
-$ kubectl get pods -n <YOUR-DESIRED-NAMESPACE>
+$ kubectl get pods -n gitlab-kubernetes-agent
 
-NAMESPACE     NAME                               READY   STATUS    RESTARTS   AGE
-gitlab-agent  gitlab-agent-77689f7dcb-5skqk      1/1     Running   0          51s
+NAMESPACE                NAME                                          READY   STATUS    RESTARTS   AGE
+gitlab-kubernetes-agent  gitlab-kubernetes-agent-77689f7dcb-5skqk      1/1     Running   0          51s
 ```
 
 ##### Example `resources.yml` file
 
 ```yaml
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: gitlab-kubernetes-agent
+---
 apiVersion: v1
 kind: ServiceAccount
 metadata:
-  name: gitlab-agent
+  name: gitlab-kubernetes-agent
 ---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: gitlab-agent
+  name: gitlab-kubernetes-agent
 spec:
   replicas: 1
   selector:
     matchLabels:
-      app: gitlab-agent
+      app: gitlab-kubernetes-agent
   template:
     metadata:
       labels:
-        app: gitlab-agent
+        app: gitlab-kubernetes-agent
     spec:
-      serviceAccountName: gitlab-agent
+      serviceAccountName: gitlab-kubernetes-agent
       containers:
       - name: agent
         # Make sure to specify a matching version for production
@@ -291,15 +309,17 @@ spec:
         args:
         - --token-file=/config/token
         - --kas-address
-        - wss://kas.host.tld:443 # change this line for the one below if using Omnibus GitLab
+        - wss://kas.host.tld:443 # replace this line with the line below if using Omnibus GitLab or GitLab.com.
         # - wss://gitlab.host.tld:443/-/kubernetes-agent/
+        # - wss://kas.gitlab.com # for GitLab.com users, use this KAS.
+        # - grpc://host.docker.internal:8150 # use this attribute when connecting from Docker.
         volumeMounts:
         - name: token-volume
           mountPath: /config
       volumes:
       - name: token-volume
         secret:
-          secretName: gitlab-agent-token
+          secretName: gitlab-kubernetes-agent-token
   strategy:
     type: RollingUpdate
     rollingUpdate:
@@ -309,7 +329,7 @@ spec:
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
-  name: gitlab-agent-write
+  name: gitlab-kubernetes-agent-write
 rules:
 - resources:
   - '*'
@@ -324,20 +344,20 @@ rules:
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
-  name: gitlab-agent-write-binding
+  name: gitlab-kubernetes-agent-write-binding
 roleRef:
-  name: gitlab-agent-write
+  name: gitlab-kubernetes-agent-write
   kind: ClusterRole
   apiGroup: rbac.authorization.k8s.io
 subjects:
-- name: gitlab-agent
+- name: gitlab-kubernetes-agent
   kind: ServiceAccount
-  namespace: gitlab-agent
+  namespace: gitlab-kubernetes-agent
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
-  name: gitlab-agent-read
+  name: gitlab-kubernetes-agent-read
 rules:
 - resources:
   - '*'
@@ -351,15 +371,15 @@ rules:
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
-  name: gitlab-agent-read-binding
+  name: gitlab-kubernetes-agent-read-binding
 roleRef:
-  name: gitlab-agent-read
+  name: gitlab-kubernetes-agent-read
   kind: ClusterRole
   apiGroup: rbac.authorization.k8s.io
 subjects:
-- name: gitlab-agent
+- name: gitlab-kubernetes-agent
   kind: ServiceAccount
-  namespace: gitlab-agent
+  namespace: gitlab-kubernetes-agent
 ```
 
 ### Create manifest files
@@ -388,7 +408,7 @@ apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-deployment
-  namespace: gitlab-agent  # Can be any namespace managed by you that the agent has access to.
+  namespace: gitlab-kubernetes-agent  # Can be any namespace managed by you that the agent has access to.
 spec:
   selector:
     matchLabels:
@@ -481,7 +501,7 @@ If you face any issues while using GitLab Kubernetes Agent, you can read the
 service logs with the following command
 
 ```shell
-kubectl logs -f -l=app=gitlab-agent -n <YOUR-DESIRED-NAMESPACE>
+kubectl logs -f -l=app=gitlab-kubernetes-agent -n gitlab-kubernetes-agent
 ```
 
 GitLab administrators can additionally view the [Kubernetes Agent Server logs](../../../administration/clusters/kas.md#troubleshooting).
@@ -520,7 +540,7 @@ It's not possible to set the `grpc` scheme due to the issue
 [It is not possible to configure KAS to work with `grpc` without directly editing GitLab KAS deployment](https://gitlab.com/gitlab-org/gitlab/-/issues/276888). To use `grpc` while the
 issue is in progress, directly edit the deployment with the
 `kubectl edit deployment gitlab-kas` command, and change `--listen-websocket=true` to `--listen-websocket=false`. After running that command, you should be able to use
-`grpc://gitlab-kas.<YOUR-NAMESPACE>:5005`.
+`grpc://gitlab-kas.<YOUR-NAMESPACE>:8150`.
 
 ### Agent logs - Decompressor is not installed for grpc-encoding
 
@@ -542,25 +562,27 @@ is unknown to the agent. One approach to fixing it is to present the CA certific
 via a Kubernetes `configmap` and mount the file in the agent `/etc/ssl/certs` directory from where it
 will be picked up automatically.
 
-For example, if your internal CA certifciate is `myCA.pem`:
+For example, if your internal CA certificate is `myCA.pem`:
 
 ```plaintext
-kubectl -n gitlab-agent create configmap ca-pemstore --from-file=myCA.pem
+kubectl -n gitlab-kubernetes-agent create configmap ca-pemstore --from-file=myCA.pem
 ```
 
 Then in `resources.yml`:
 
 ```yaml
     spec:
-      serviceAccountName: gitlab-agent
+      serviceAccountName: gitlab-kubernetes-agent
       containers:
       - name: agent
         image: "registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/agentk:<version>"
         args:
         - --token-file=/config/token
         - --kas-address
-        - wss://kas.host.tld:443 # change this line for the one below if using Omnibus GitLab
+        - wss://kas.host.tld:443 # replace this line with the line below if using Omnibus GitLab or GitLab.com.
         # - wss://gitlab.host.tld:443/-/kubernetes-agent/
+        # - wss://kas.gitlab.com # for GitLab.com users, use this KAS.
+        # - grpc://host.docker.internal:8150 # use this attribute when connecting from Docker.
         volumeMounts:
         - name: token-volume
           mountPath: /config
@@ -570,7 +592,7 @@ Then in `resources.yml`:
       volumes:
       - name: token-volume
         secret:
-          secretName: gitlab-agent-token
+          secretName: gitlab-kubernetes-agent-token
       - name: ca-pemstore-volume
         configMap:
           name: ca-pemstore
@@ -590,8 +612,10 @@ Alternatively, you can mount the certificate file at a different location and in
         - --ca-cert-file=/tmp/myCA.pem
         - --token-file=/config/token
         - --kas-address
-        - wss://kas.host.tld:443 # change this line for the one below if using Omnibus GitLab
+        - wss://kas.host.tld:443 # replace this line with the line below if using Omnibus GitLab or GitLab.com.
         # - wss://gitlab.host.tld:443/-/kubernetes-agent/
+        # - wss://kas.gitlab.com # for GitLab.com users, use this KAS.
+        # - grpc://host.docker.internal:8150 # use this attribute when connecting from Docker.
         volumeMounts:
         - name: token-volume
           mountPath: /config
@@ -599,3 +623,34 @@ Alternatively, you can mount the certificate file at a different location and in
           mountPath: /tmp/myCA.pem
           subPath: myCA.pem
 ```
+
+## Remove the GitLab Kubernetes Agent
+
+1. Remove an Agent record with GraphQL by deleting the `clusterAgent` and the `clusterAgentToken`.
+
+   ```graphql
+   mutation deleteAgent {
+     clusterAgentDelete(input: { id: "<cluster-agent-id>" } ) {
+       errors
+     }
+   }
+
+   mutation deleteToken {
+     clusterAgentTokenDelete(input: { id: "<cluster-agent-token-id>" }) {
+       errors
+     }
+   }
+   ```
+
+1. Verify whether the removal occurred successfully. If the output in the Pod logs includes `unauthenticated`, it means that the agent was successfully removed:
+
+   ```json
+      {"level":"warn","time":"2021-04-29T23:44:07.598Z","msg":"GetConfiguration.Recv failed","error":"rpc error:
+      code = Unauthenticated desc = unauthenticated"}
+   ```
+
+1. Delete the GitLab Kubernetes Agent in your cluster:
+
+   ```shell
+   kubectl delete -n gitlab-kubernetes-agent -f ./resources.yml
+   ```
diff --git a/doc/user/clusters/agent/repository.md b/doc/user/clusters/agent/repository.md
index 9caa4a89daf..49e5e8c58df 100644
--- a/doc/user/clusters/agent/repository.md
+++ b/doc/user/clusters/agent/repository.md
@@ -94,3 +94,41 @@ gitops:
       # If 'paths' is not specified or is an empty list, the configuration below is used
     - glob: '/**/*.{yaml,yml,json}'
 ```
+
+## Surface network security alerts from cluster to GitLab
+
+The GitLab Agent provides an [integration with Cilium](index.md#kubernetes-network-security-alerts).
+To integrate, add a top-level `cilium` section to your `config.yml` file. Currently, the
+only configuration option is the Hubble relay address:
+
+```yaml
+cilium:
+  hubble_relay_address: "<hubble-relay-host>:<hubble-relay-port>"
+```
+
+If your Cilium integration was performed through GitLab Managed Apps, you can use `hubble-relay.gitlab-managed-apps.svc.cluster.local:80` as the address:
+
+```yaml
+cilium:
+  hubble_relay_address: "hubble-relay.gitlab-managed-apps.svc.cluster.local:80"
+```
+
+## Debugging
+
+To debug the cluster-side component (`agentk`) of the GitLab Kubernetes Agent, set the log
+level according to the available options:
+
+- `off`
+- `warning`
+- `error`
+- `info`
+- `debug`
+
+The log level defaults to `info`. You can change it by using a top-level `observability`
+section in the configuration file, for example:
+
+```yaml
+observability:
+  logging:
+    level: debug
+```
diff --git a/doc/user/clusters/applications.md b/doc/user/clusters/applications.md
index b11ca7aac12..212823853e4 100644
--- a/doc/user/clusters/applications.md
+++ b/doc/user/clusters/applications.md
@@ -4,27 +4,41 @@ group: Configure
 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/#assignments
 ---
 
-# GitLab Managed Apps **(FREE)**
+# GitLab Managed Apps (DEPRECATED) **(FREE)**
 
-GitLab provides **GitLab Managed Apps** for various
-applications which can be added directly to your configured cluster. These
-applications are needed for [Review Apps](../../ci/review_apps/index.md) and
-[deployments](../../ci/environments/index.md) when using [Auto DevOps](../../topics/autodevops/index.md).
-You can install them after you [create a cluster](../project/clusters/add_remove_clusters.md).
-GitLab provides GitLab Managed Apps [using CI/CD](#install-using-gitlab-cicd).
-GitLab Managed Apps with [one-click installations](#install-with-one-click)
-have been deprecated, and are scheduled for removal in GitLab 14.0.
+**GitLab Managed Apps** was created to help you configure applications in your
+cluster directly from GitLab. You could use this feature through two different
+methods: "one-click install" and "CI/CD template". Both methods are **deprecated**:
 
-## Install using GitLab CI/CD
+- The **one-click install** method was deprecated in GitLab 13.9 and **will be
+  removed** in GitLab 14.0.
+- The **CI/CD template method** was deprecated in GitLab 13.12 and is scheduled
+  to be removed in GitLab 15.0.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20822) in GitLab 12.6.
+Both methods were limiting as you couldn't fully customize your third-party apps installed
+through GitLab Managed Apps. Therefore, we decided to deprecate this feature and provide
+better [GitOps-driven alternatives](https://about.gitlab.com/direction/configure/kubernetes_management/#gitlab-managed-applications) to our users, such as [cluster integrations](integrations.md#cluster-integrations) and [cluster management project](management_project.md).
+
+Read the sections below according to the installation method you chose to
+learn how to proceed to keep your apps up and running:
+
+- [One-click install method](#install-with-one-click-deprecated)
+- [CI/CD template method](#install-using-gitlab-cicd-deprecated)
+
+## Install using GitLab CI/CD (DEPRECATED)
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20822) in GitLab 12.6.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 WARNING:
-This is a _beta_ feature, and some applications might miss features to provide full integration with GitLab.
+The GitLab Managed Apps CI/CD installation method was [deprecated in 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/327908). 
+Your applications continue to work. However, we no longer support and maintain the GitLab CI/CD template for
+Managed Apps (`Managed-Cluster-Applications.gitlab-ci.yml`).
+As a replacement, we are working on a [cluster management project template](https://gitlab.com/gitlab-org/gitlab/-/issues/327908),
+still to be released.
 
-This primary method for installing applications to clusters allows users to install GitLab-managed
-applications using GitLab CI/CD. It also allows customization of the
-install using Helm `values.yaml` files.
+The CI/CD template was the primary method for installing applications to clusters via GitLab Managed Apps
+and customize them through Helm.
 
 Supported applications:
 
@@ -138,6 +152,8 @@ Note the following:
 
 ### Install Ingress using GitLab CI/CD
 
+> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
+
 To install Ingress, define the `.gitlab/managed-apps/config.yaml` file
 with:
 
@@ -162,6 +178,8 @@ and ping at least 2 people from the
 
 ### Install cert-manager using GitLab CI/CD
 
+> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
+
 cert-manager is installed using GitLab CI/CD by defining configuration in
 `.gitlab/managed-apps/config.yaml`.
 
@@ -206,6 +224,8 @@ least 2 people from the
 
 ### Install Sentry using GitLab CI/CD
 
+> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
+
 The Sentry Helm chart [recommends](https://github.com/helm/charts/blob/f6e5784f265dd459c5a77430185d0302ed372665/stable/sentry/values.yaml#L284-L285)
 at least 3 GB of available RAM for database migrations.
 
@@ -275,6 +295,8 @@ least 2 people from the
 
 ### Install PostHog using GitLab CI/CD
 
+> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
+
 [PostHog](https://posthog.com) 🦔 is a developer-friendly, open-source product analytics platform.
 
 To install PostHog into the `gitlab-managed-apps` namespace of your cluster,
@@ -325,7 +347,8 @@ If you run into issues,
 
 ### Install Prometheus using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25138) in GitLab 12.8.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25138) in GitLab 12.8.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 [Prometheus](https://prometheus.io/docs/introduction/overview/) is an
 open-source monitoring and alerting system for supervising your
@@ -352,6 +375,8 @@ least 2 people from the [APM group](https://about.gitlab.com/handbook/product/ca
 
 ### Install GitLab Runner using GitLab CI/CD
 
+> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
+
 GitLab Runner is installed using GitLab CI/CD by defining configuration in
 `.gitlab/managed-apps/config.yaml`.
 
@@ -390,7 +415,8 @@ least 2 people from the
 
 ### Install Cilium using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/22) in GitLab 12.8.
+> - [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/22) in GitLab 12.8.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 [Cilium](https://cilium.io/) is a networking plugin for Kubernetes that you can use to implement
 support for [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
@@ -505,7 +531,8 @@ least 2 people from the
 
 ### Install Falco using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/91) in GitLab 13.1.
+> - [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/91) in GitLab 13.1.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 GitLab Container Host Security Monitoring uses [Falco](https://falco.org/)
 as a runtime security tool that listens to the Linux kernel using eBPF. Falco parses system calls
@@ -601,7 +628,8 @@ least 2 people from the
 
 ### Install Vault using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9982) in GitLab 12.9.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9982) in GitLab 12.9.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 [HashiCorp Vault](https://www.vaultproject.io/) is a secrets management solution which
 can be used to safely manage and store passwords, credentials, certificates, and more. A Vault
@@ -703,7 +731,8 @@ least 2 people from the
 
 ### Install JupyterHub using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/40) in GitLab 12.8.
+> - [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/40) in GitLab 12.8.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 JupyterHub is installed using GitLab CI/CD by defining configuration in
 `.gitlab/managed-apps/config.yaml` as follows:
@@ -760,7 +789,8 @@ least 2 people from the
 
 ### Install Elastic Stack using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25138) in GitLab 12.8.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25138) in GitLab 12.8.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 Elastic Stack is installed using GitLab CI/CD by defining configuration in
 `.gitlab/managed-apps/config.yaml`.
@@ -796,7 +826,8 @@ least 2 people from the [APM group](https://about.gitlab.com/handbook/product/ca
 
 ### Install Crossplane using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35675) in GitLab 12.9.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35675) in GitLab 12.9.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 Crossplane is installed using GitLab CI/CD by defining configuration in
 `.gitlab/managed-apps/config.yaml`.
@@ -827,7 +858,8 @@ If you run into issues,
 
 ### Install Fluentd using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/76) in GitLab 12.10.
+> - [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/76) in GitLab 12.10.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 To install Fluentd into the `gitlab-managed-apps` namespace of your cluster using
 GitLab CI/CD, define the following configuration in `.gitlab/managed-apps/config.yaml`:
@@ -858,6 +890,8 @@ least 2 people from the
 
 ### Install Knative using GitLab CI/CD
 
+> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
+
 To install Knative, define the `.gitlab/managed-apps/config.yaml` file
 with:
 
@@ -908,7 +942,8 @@ kubectl delete -f https://gitlab.com/gitlab-org/cluster-integration/cluster-appl
 
 ### Install AppArmor using GitLab CI/CD
 
-> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/100) in GitLab 13.1.
+> - [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/100) in GitLab 13.1.
+> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
 
 To install AppArmor into the `gitlab-managed-apps` namespace of your cluster using
 GitLab CI/CD, define the following configuration in `.gitlab/managed-apps/config.yaml`:
@@ -998,13 +1033,13 @@ at least 2 people from the
 Logs produced by pods running **GitLab Managed Apps** can be browsed using
 [**Log Explorer**](../project/clusters/kubernetes_pod_logs.md).
 
-## Install with one click
+## Install with one click (DEPRECATED)
 
 WARNING:
-The one-click installation method is deprecated and scheduled for removal in [GitLab 14.0](https://gitlab.com/groups/gitlab-org/-/epics/4280).
-This removal does not affect installed applications to avoid breaking
-changes. Following GitLab 14.0, users can take ownership of already installed applications
-using our documentation.
+The one-click installation method was deprecated in GitLab 13.9 and will be removed in [GitLab 14.0](https://gitlab.com/groups/gitlab-org/-/epics/4280).
+The removal does not break nor uninstall any apps you have installed but removes the GitLab UI page
+for installing and updating your GitLab Managed Apps.
+Follow the process to [take ownership of your GitLab Managed Apps](#take-ownership-of-your-gitlab-managed-apps).
 
 Applications managed by GitLab are installed onto the `gitlab-managed-apps`
 namespace. This namespace:
@@ -1668,3 +1703,88 @@ Spawn failed: Timeout
 
 This is due to DigitalOcean imposing a few limits with regards to creating additional block storage volumes.
 [Learn more about DigitalOcean Block Storage Volumes limits.](https://www.digitalocean.com/docs/volumes/#limits)
+
+## Take ownership of your GitLab Managed Apps
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327803) in GitLab 13.12.
+
+With the removal of the [One-click install method](#install-with-one-click-deprecated) in GitLab 14.0,
+the **Applications** tab (under your project's  **Operations > Kubernetes**)
+will no longer be displayed:
+
+![GitLab Managed Apps - Applications tab](img/applications_tab_v13_12.png)
+
+This tab was dedicated to installing and maintaining GitLab Managed Apps.
+To continue managing your installed applications, one of the possible ways is to
+install [Helm](https://helm.sh/) locally, as described below.
+
+### View installed applications
+
+To view the applications you have installed in your cluster through GitLab Managed Apps,
+you need to verify the resources you have in the `gitlab-managed-apps` namespace.
+On your computer, [configure `kubectl`](https://kubernetes.io/docs/reference/kubectl/overview/)
+to connect to your cluster, open the terminal and run:
+
+```shell
+kubectl get all -n gitlab-managed-apps
+```
+
+If there is no output or the namespace does not exist, you do not have any applications
+installed through GitLab Managed Apps. If this is the case, you have nothing else to do.
+
+### Identify the Helm version
+
+Next, verify which Helm version GitLab used to install your applications.
+
+#### For apps installed with Helm v3
+
+To list your apps installed with Helm v3, run:
+
+```shell
+kubectl get secrets -n gitlab-managed-apps | grep 'helm.sh/release'
+```
+
+You can manage these applications with Helm v3 and you don't need any further steps.
+
+All applications not listed with the command above were installed with Helm v2.
+
+#### For apps installed with Helm v2
+
+If you have apps installed with Helm v2, you can either:
+
+- A. Install Helm v3 and [upgrade your apps to Helm v3](https://helm.sh/docs/topics/v2_v3_migration/).
+- B. Install Helm v2 and keep using this Helm version, which is not recommended as Helm v2 was deprecated in favor of
+Helm v3.
+
+If you choose to keep using Helm v2 (B), follow the steps below to manage your apps:
+
+1. Install [Helm v2](https://v2.helm.sh/docs/install/) in your computer.
+1. Start a local Tiller server:
+
+   ```shell
+   export TILLER_NAMESPACE=gitlab-managed-apps
+   tiller -listen localhost:44134
+   ```
+
+1. In another tab, initialize your Helm client:
+
+   ```shell
+   export HELM_HOST="localhost:44134"
+   helm init --client-only
+   ```
+
+1. Now your environment is ready to manage your apps with Helm v2. For example, to list your releases:
+
+   ```shell
+   helm ls
+   ```
+
+### Cluster integrations
+
+Some applications were not only installed in your cluster by GitLab through Managed Apps but were also
+directly integrated with GitLab so that you could benefit from seeing, controlling, or getting notified
+about them through GitLab.
+To keep them integrated, read the documentation for:
+
+- [Prometheus cluster integration](integrations.md#prometheus-cluster-integration)
+- [Elastic Stack cluster integration](integrations.md#elastic-stack-cluster-integration)
diff --git a/doc/user/clusters/img/applications_tab_v13_12.png b/doc/user/clusters/img/applications_tab_v13_12.png
new file mode 100644
index 00000000000..c4f1a8862e8
--- /dev/null
+++ b/doc/user/clusters/img/applications_tab_v13_12.png
diff --git a/doc/user/clusters/integrations.md b/doc/user/clusters/integrations.md
index 74c48d1a010..a8b181f8726 100644
--- a/doc/user/clusters/integrations.md
+++ b/doc/user/clusters/integrations.md
@@ -10,7 +10,9 @@ GitLab provides several ways to integrate applications to your
 Kubernetes cluster.
 
 To enable cluster integrations, first add a Kubernetes cluster to a GitLab
-[project](../project/clusters/add_remove_clusters.md) or [group](../group/clusters/index.md#group-level-kubernetes-clusters).
+[project](../project/clusters/add_remove_clusters.md) or
+[group](../group/clusters/index.md#group-level-kubernetes-clusters) or
+[instance](../instance/clusters/index.md).
 
 ## Prometheus cluster integration
 
@@ -20,30 +22,33 @@ You can integrate your Kubernetes cluster with
 [Prometheus](https://prometheus.io/) for monitoring key metrics of your
 apps directly from the GitLab UI.
 
-Once enabled, you will see metrics from services available in the
+[Alerts](../../operations/metrics/alerts.md) can be configured the same way as
+for [external Prometheus instances](../../operations/metrics/alerts.md#external-prometheus-instances).
+
+Once enabled, you can see metrics from services available in the
 [metrics library](../project/integrations/prometheus_library/index.md).
 
-Prerequisites:
+### Prometheus Prerequisites
 
-To benefit from this integration, you must have Prometheus
-installed in your cluster with the following requirements:
+To use this integration:
 
-1. Prometheus must be installed inside the `gitlab-managed-apps` namespace.
+1. Prometheus must be installed in your cluster in the `gitlab-managed-apps` namespace.
 1. The `Service` resource for Prometheus must be named `prometheus-prometheus-server`.
 
-You can use the following commands to install Prometheus to meet the requirements for cluster integrations:
+You can manage your Prometheus however you like, but as an example, you can set
+it up using [Helm](https://helm.sh/) as follows:
 
 ```shell
-# Create the require Kubernetes namespace
+# Create the required Kubernetes namespace
 kubectl create ns gitlab-managed-apps
 
 # Download Helm chart values that is compatible with the requirements above.
-# You should substitute the tag that corresponds to the GitLab version in the url
+# You should substitute the tag that corresponds to the GitLab version in the URL
 # - https://gitlab.com/gitlab-org/gitlab/-/raw/<tag>/vendor/prometheus/values.yaml
 #
 wget https://gitlab.com/gitlab-org/gitlab/-/raw/v13.9.0-ee/vendor/prometheus/values.yaml
 
-# Add the Prometheus community helm repo
+# Add the Prometheus community Helm chart repository
 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
 
 # Install Prometheus
@@ -62,6 +67,65 @@ To enable the Prometheus integration for your cluster:
       **Operations > Kubernetes**.
       - For a [group-level cluster](../group/clusters/index.md), navigate to your group's
       **Kubernetes** page.
+      - For an [instance-level cluster](../instance/clusters/index.md), navigate to your instance's
+      **Kubernetes** page.
+1. Select the **Integrations** tab.
+1. Check the **Enable Prometheus integration** checkbox.
+1. Click **Save changes**.
+1. Go to the **Health** tab to see your cluster's metrics.
+
+## Elastic Stack cluster integration
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61077) in GitLab 13.12.
+
+You can integrate your cluster with [Elastic
+Stack](https://www.elastic.co/elastic-stack) to index and [query your pod
+logs](../project/clusters/kubernetes_pod_logs.md).
+
+### Elastic Stack Prerequisites
+
+To use this integration:
+
+1. Elasticsearch 7.x or must be installed in your cluster in the
+   `gitlab-managed-apps` namespace.
+1. The `Service` resource must be called `elastic-stack-elasticsearch-master`
+   and expose the Elasticsearch API on port `9200`.
+1. The logs are expected to be [Filebeat container logs](https://www.elastic.co/guide/en/beats/filebeat/7.x/filebeat-input-container.html)
+   following the [7.x log structure](https://www.elastic.co/guide/en/beats/filebeat/7.x/exported-fields-log.html)
+   and include [Kubernetes metadata](https://www.elastic.co/guide/en/beats/filebeat/7.x/add-kubernetes-metadata.html).
+
+You can manage your Elastic Stack however you like, but as an example, you can
+use [this Elastic Stack chart](https://gitlab.com/gitlab-org/charts/elastic-stack) to get up and
+running:
+
+```shell
+# Create the required Kubernetes namespace
+kubectl create namespace gitlab-managed-apps
+
+# Download Helm chart values that is compatible with the requirements above.
+# You should substitute the tag that corresponds to the GitLab version in the URL
+# - https://gitlab.com/gitlab-org/gitlab/-/raw/<tag>/vendor/elastic_stack/values.yaml
+#
+wget https://gitlab.com/gitlab-org/gitlab/-/raw/v13.9.0-ee/vendor/elastic_stack/values.yaml
+
+# Add the GitLab Helm chart repository
+helm repo add gitlab https://charts.gitlab.io
+
+# Install Elastic Stack
+helm install prometheus gitlab/elastic-stack -n gitlab-managed-apps --values values.yaml
+```
+
+### Enable Elastic Stack integration for your cluster
+
+To enable the Elastic Stack integration for your cluster:
+
+1. Go to the cluster's page:
+      - For a [project-level cluster](../project/clusters/index.md), navigate to your project's
+      **Operations > Kubernetes**.
+      - For a [group-level cluster](../group/clusters/index.md), navigate to your group's
+      **Kubernetes** page.
+      - For an [instance-level cluster](../instance/clusters/index.md), navigate to your instance's
+      **Kubernetes** page.
 1. Select the **Integrations** tab.
 1. Check the **Enable Prometheus integration** checkbox.
 1. Click **Save changes**.
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index da9bacc9788..e728577e194 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -20,7 +20,7 @@ privileges.
 
 This can be useful for:
 
-- Creating pipelines to install cluster-wide applications into your cluster, see [Install using GitLab CI/CD (beta)](applications.md#install-using-gitlab-cicd) for details.
+- Creating pipelines to install cluster-wide applications into your cluster, see [Install using GitLab CI/CD (beta)](applications.md#install-using-gitlab-cicd-deprecated) for details.
 - Any jobs that require `cluster-admin` privileges.
 
 ## Permissions