Add latest changes from gitlab-org/gitlab@master

4 files changed, 21 insertions, 12 deletions

diff --git a/doc/user/admin_area/analytics/usage_trends.md b/doc/user/admin_area/analytics/usage_trends.md
index a9c5adcf838..5f46908adb0 100644
--- a/doc/user/admin_area/analytics/usage_trends.md
+++ b/doc/user/admin_area/analytics/usage_trends.md
@@ -12,9 +12,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - It's enabled on GitLab.com.
 > - It's recommended for production use.
 
-WARNING:
-This feature might not be available to you. Check the **version history** note above for details.
-
 Usage Trends gives you an overview of how much data your instance contains, and how quickly this volume is changing over time.
 Usage Trends data refreshes daily.
 
diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md
index 632c5804afb..e76497ab5de 100644
--- a/doc/user/application_security/index.md
+++ b/doc/user/application_security/index.md
@@ -219,7 +219,7 @@ security issues:
 WARNING:
 This feature is in its end-of-life process. It is [deprecated](../../update/deprecations.md#vulnerability-check)
 for use in GitLab 14.8, and is planned for removal in GitLab 15.0. Users should migrate to the new
-[Security Approval Policies](policies/#scan-result-policy-editor).
+[Security Approval Policies](policies/scan-result-policies.md).
 
 To prevent a merge request introducing a security vulnerability in a project, enable the
 Vulnerability-Check rule. While this rule is enabled, additional merge request approval by
diff --git a/doc/user/clusters/agent/ci_cd_tunnel.md b/doc/user/clusters/agent/ci_cd_tunnel.md
index d74f8ee6f89..c6dbb1ca70c 100644
--- a/doc/user/clusters/agent/ci_cd_tunnel.md
+++ b/doc/user/clusters/agent/ci_cd_tunnel.md
@@ -12,16 +12,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
 > - Support for Omnibus installations was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5686) in GitLab 14.5.
 
-You can use GitLab CI/CD to safely deploy to and update your Kubernetes clusters.
+You can use a GitLab CI/CD workflow to safely deploy to and update your Kubernetes clusters.
 
-To do so, you install a GitLab agent in your cluster. Then in your GitLab CI/CD pipelines,
-you can refer to the cluster connection as a Kubernetes context.
-Then you can run Kubernetes API commands as part of your GitLab CI/CD pipeline.
+To do so, you must first [install an agent in your cluster](install/index.md). When done, you have a Kubernetes context and can
+run Kubernetes API commands in your GitLab CI/CD pipeline.
 
 To ensure access to your cluster is safe:
 
 - Each agent has a separate context (`kubecontext`).
-- Only the project where the agent is, and any additional projects you authorize can access the agent in your cluster.
+- Only the project where the agent is configured, and any additional projects you authorize, can access the agent in your cluster.
 
 You do not need to have a runner in the cluster with the agent.
 
diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index 6d3151434cc..a8ad19df2e1 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -14,7 +14,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Renamed](https://gitlab.com/groups/gitlab-org/-/epics/7167) from "GitLab Kubernetes Agent" to "GitLab agent for Kubernetes" in GitLab 14.6.
 
 You can connect your Kubernetes cluster with GitLab to deploy, manage,
-and monitor your cloud-native solutions. You can choose from two primary workflows.
+and monitor your cloud-native solutions. 
+
+To connect a Kubernetes cluster to GitLab, you must first [install an agent in your cluster](install/index.md).
+
+The agent runs in the cluster, and you can use it to:
+
+- Communicate with a cluster, which is behind a firewall or NAT.
+- Access API endpoints in a cluster in real time.
+- Push information about events happening in the cluster.
+- Enable a cache of Kubernetes objects, which are kept up-to-date with very low latency.
+
+For more details about the agent's purpose and architecture, see the [architecture documentation](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md).
+
+## Workflows
+
+You can choose from two primary workflows.
 
 In a [**GitOps** workflow](gitops.md), you keep your Kubernetes manifests in GitLab. You install a GitLab agent in your cluster, and
 any time you update your manifests, the agent updates the cluster. This workflow is fully driven with Git and is considered pull-based,
@@ -23,8 +38,6 @@ because the cluster is pulling updates from your GitLab repository.
 In a [**CI/CD** workflow](ci_cd_tunnel.md), you use GitLab CI/CD to query and update your cluster by using the Kubernetes API.
 This workflow is considered push-based, because GitLab is pushing requests from GitLab CI/CD to your cluster.
 
-Both of these workflows require you to [install an agent in your cluster](install/index.md).
-
 ## Supported cluster versions
 
 GitLab supports the following Kubernetes versions. You can upgrade your