Merge branch 'agent-doc' into 'master'

Add more detail about the purpose of the agent to the docs

See merge request gitlab-org/gitlab!81407

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.
 

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