Merge branch 'selhorn-agent-lowercase' into 'master'

Updated agent to lowercase

See merge request gitlab-org/gitlab!81209

doc/administration/clusters/kas.md

@@ -4,15 +4,15 @@ 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
 ---
 
-# Install the GitLab Agent Server for Kubernetes (KAS) **(FREE SELF)**
+# Install the GitLab agent server for Kubernetes (KAS) **(FREE SELF)**
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.10, the GitLab Agent Server (KAS) became available on GitLab.com under `wss://kas.gitlab.com`.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.10, the GitLab agent server (KAS) became available on GitLab.com under `wss://kas.gitlab.com`.
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) from GitLab Premium to GitLab Free in 14.5.
 
-The GitLab Agent Server for Kubernetes is a GitLab backend service dedicated to
-managing the [GitLab Agent for Kubernetes](../../user/clusters/agent/index.md).
+The GitLab agent server for Kubernetes is a GitLab backend service dedicated to
+managing the [GitLab agent for Kubernetes](../../user/clusters/agent/index.md).
 
-The KAS acronym refers to the former name, Kubernetes Agent Server.
+The KAS acronym refers to the former name, Kubernetes agent server.
 
 The KAS is already installed and available in GitLab.com under `wss://kas.gitlab.com`.
 This document describes how to install a KAS for GitLab self-managed instances.
@@ -31,7 +31,7 @@ You can also opt to use an [external KAS](#use-an-external-kas-installation).
 
 For [Omnibus](https://docs.gitlab.com/omnibus/) package installations:
 
-1. Edit `/etc/gitlab/gitlab.rb` to enable the Agent Server:
+1. Edit `/etc/gitlab/gitlab.rb` to enable the agent server:
 
    ```ruby
    gitlab_kas['enable'] = true
@@ -96,7 +96,7 @@ For GitLab instances installed through Omnibus packages:
 
 ## Troubleshooting
 
-If you have issues while using the GitLab Agent Server for Kubernetes, view the
+If you have issues while using the GitLab agent server for Kubernetes, view the
 service logs by running the following command:
 
 ```shell
@@ -105,7 +105,7 @@ kubectl logs -f -l=app=kas -n <YOUR-GITLAB-NAMESPACE>
 
 In Omnibus GitLab, find the logs in `/var/log/gitlab/gitlab-kas/`.
 
-You can also [troubleshoot issues with individual Agents](../../user/clusters/agent/troubleshooting.md).
+You can also [troubleshoot issues with individual agents](../../user/clusters/agent/troubleshooting.md).
 
 ### KAS logs - GitOps: failed to get project information
 

doc/administration/logs.md

@@ -1095,9 +1095,9 @@ For Omnibus GitLab installations, GitLab Monitor logs are in `/var/log/gitlab/gi
 
 For Omnibus GitLab installations, GitLab Exporter logs are in `/var/log/gitlab/gitlab-exporter/`.
 
-## GitLab Agent Server
+## GitLab agent server
 
-For Omnibus GitLab installations, GitLab Agent Server logs are
+For Omnibus GitLab installations, GitLab agent server logs are
 in `/var/log/gitlab/gitlab-kas/`.
 
 ## Praefect Logs

doc/api/jobs.md

@@ -474,7 +474,7 @@ Example of response
 }
 ```
 
-## Get GitLab Agent by `CI_JOB_TOKEN` **(PREMIUM)**
+## Get GitLab agent by `CI_JOB_TOKEN` **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/324269) in GitLab 13.11.
 

doc/architecture/blueprints/gitlab_to_kubernetes_communication/index.md

@@ -9,7 +9,7 @@ description: 'GitLab to Kubernetes communication'
 # GitLab to Kubernetes communication **(FREE)**
 
 The goal of this document is to define how GitLab can communicate with Kubernetes
-and in-cluster services through the GitLab Agent.
+and in-cluster services through the GitLab agent.
 
 ## Challenges
 
@@ -48,7 +48,7 @@ are stored on the GitLab side and this is yet another security concern for our c
 For more discussion on these issues, read
 [issue #212810](https://gitlab.com/gitlab-org/gitlab/-/issues/212810).
 
-## GitLab Agent epic
+## GitLab agent epic
 
 To address these challenges and provide some new features, the Configure group
 is building an active in-cluster component that inverts the
@@ -62,12 +62,12 @@ The customer does not need to provide any credentials to GitLab, and
 is in full control of what permissions the agent has.
 
 For more information, visit the
-[GitLab Agent repository](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent) or
+[GitLab agent repository](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent) or
 [the epic](https://gitlab.com/groups/gitlab-org/-/epics/3329).
 
 ### Request routing
 
-Agents connect to the server-side component called GitLab Agent Server
+Agents connect to the server-side component called GitLab agent server
 (`gitlab-kas`) and keep an open connection that waits for commands. The
 difficulty with the approach is in routing requests from GitLab to the correct agent.
 Each cluster may contain multiple logical agents, and each may be running as multiple

doc/development/features_inside_dot_gitlab.md

@@ -12,7 +12,7 @@ When implementing new features, please refer to these existing features to avoid
 - [Custom Dashboards](../operations/metrics/dashboards/index.md#add-a-new-dashboard-to-your-project): `.gitlab/dashboards/`.
 - [Issue Templates](../user/project/description_templates.md#create-an-issue-template): `.gitlab/issue_templates/`.
 - [Merge request Templates](../user/project/description_templates.md#create-a-merge-request-template): `.gitlab/merge_request_templates/`.
-- [GitLab Agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/configuration_repository.md#layout): `.gitlab/agents/`.
+- [GitLab agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/configuration_repository.md#layout): `.gitlab/agents/`.
 - [CODEOWNERS](../user/project/code_owners.md#set-up-code-owners): `.gitlab/CODEOWNERS`.
 - [Route Maps](../ci/review_apps/#route-maps): `.gitlab/route-map.yml`.
 - [Customize Auto DevOps Helm Values](../topics/autodevops/customize.md#customize-values-for-helm-chart): `.gitlab/auto-deploy-values.yaml`.

doc/development/go_guide/go_upgrade.md

@@ -134,7 +134,7 @@ if you need help finding the correct person or labels:
 | GitLab Compose Kit            | [Issuer Tracker](https://gitlab.com/gitlab-org/gitlab-compose-kit/-/issues) |
 | GitLab Container Registry     | [Issue Tracker](https://gitlab.com/gitlab-org/container-registry) |
 | GitLab Elasticsearch Indexer  | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer/-/issues) |
-| GitLab Agent Server (KAS) | [Issue Tracker](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues) |
+| GitLab agent server for Kubernetes (KAS) | [Issue Tracker](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues) |
 | GitLab Pages                  | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-pages/-/issues) |
 | GitLab Quality Images         | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-build-images/-/issues) |
 | GitLab Shell                  | [Issue Tracker](https://gitlab.com/gitlab-org/gitlab-shell/-/issues) |

doc/development/internal_api/index.md

@@ -42,7 +42,7 @@ file, and include the token Base64 encoded in a `secret_token` parameter
 or in the `Gitlab-Shared-Secret` header.
 
 NOTE:
-The internal API used by GitLab Pages, and GitLab Agent Server (`kas`) uses JSON Web Token (JWT)
+The internal API used by GitLab Pages, and GitLab agent server (`kas`) uses JSON Web Token (JWT)
 authentication, which is different from GitLab Shell.
 
 ## Git Authentication
@@ -400,13 +400,13 @@ Example response:
 }
 ```
 
-## GitLab Agent endpoints
+## GitLab agent endpoints
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/41045) in GitLab 13.4.
 > - This feature is not deployed on GitLab.com
 > - It's not recommended for production use.
 
-The following endpoints are used by the GitLab Agent Server (`kas`)
+The following endpoints are used by the GitLab agent server (`kas`)
 for various purposes.
 
 These endpoints are all authenticated using JWT. The JWT secret is stored in a file
@@ -414,11 +414,11 @@ specified in `config/gitlab.yml`. By default, the location is in the root of the
 GitLab Rails app in a file called `.gitlab_kas_secret`.
 
 WARNING:
-The GitLab Agent is under development and is not recommended for production use.
+The GitLab agent is under development and is not recommended for production use.
 
-### GitLab Agent information
+### GitLab agent information
 
-Called from GitLab Agent Server (`kas`) to retrieve agent
+Called from GitLab agent server (`kas`) to retrieve agent
 information for the given agent token. This returns the Gitaly connection
 information for the agent's project in order for `kas` to fetch and update
 the agent's configuration.
@@ -434,9 +434,9 @@ curl --request GET --header "Gitlab-Kas-Api-Request: <JWT token>" \
      --header "Authorization: Bearer <agent token>" "http://localhost:3000/api/v4/internal/kubernetes/agent_info"
 ```
 
-### GitLab Agent project information
+### GitLab agent project information
 
-Called from GitLab Agent Server (`kas`) to retrieve project
+Called from GitLab agent server (`kas`) to retrieve project
 information for the given agent token. This returns the Gitaly
 connection for the requested project. GitLab `kas` uses this to configure
 the agent to fetch Kubernetes resources from the project repository to
@@ -460,9 +460,9 @@ curl --request GET --header "Gitlab-Kas-Api-Request: <JWT token>" \
      --header "Authorization: Bearer <agent token>" "http://localhost:3000/api/v4/internal/kubernetes/project_info?id=7"
 ```
 
-### GitLab Agent usage metrics
+### GitLab agent usage metrics
 
-Called from GitLab Agent Server (`kas`) to increase the usage
+Called from GitLab agent server (`kas`) to increase the usage
 metric counters.
 
 | Attribute | Type   | Required | Description |
@@ -481,9 +481,9 @@ curl --request POST --header "Gitlab-Kas-Api-Request: <JWT token>" --header "Con
      --data '{"gitops_sync_count":1}' "http://localhost:3000/api/v4/internal/kubernetes/usage_metrics"
 ```
 
-### GitLab Agent alert metrics
+### GitLab agent alert metrics
 
-Called from GitLab Agent Server (KAS) to save alerts derived from Cilium on Kubernetes
+Called from GitLab agent server (KAS) to save alerts derived from Cilium on Kubernetes
 Cluster.
 
 | Attribute | Type   | Required | Description |
@@ -505,7 +505,7 @@ curl --request POST --header "Gitlab-Kas-Api-Request: <JWT token>" \
 
 ### Create Starboard vulnerability
 
-Called from the GitLab Agent Server (`kas`) to create a security vulnerability
+Called from the GitLab agent server (`kas`) to create a security vulnerability
 from a Starboard vulnerability report. This request is idempotent. Multiple requests with the same data
 create a single vulnerability. The response contains the UUID of the created vulnerability finding.
 
@@ -563,7 +563,7 @@ Example response:
 
 ### Resolve Starboard vulnerabilities
 
-Called from the GitLab Agent Server (`kas`) to resolve Starboard security vulnerabilities.
+Called from the GitLab agent server (`kas`) to resolve Starboard security vulnerabilities.
 Accepts a list of finding UUIDs and marks all Starboard vulnerabilities not identified by
 the list as resolved.
 

doc/install/openshift_and_gitlab/index.md

@@ -20,7 +20,7 @@ Some components (documented on the GitLab Operator doc) are not supported yet.
 
 ## Deploy to and integrate with OpenShift from GitLab
 
-Deploying custom or COTS applications on top of OpenShift from GitLab is supported using [the GitLab Agent](../../user/clusters/agent/index.md).
+Deploying custom or COTS applications on top of OpenShift from GitLab is supported using [the GitLab agent](../../user/clusters/agent/index.md).
 
 ## Use OpenShift to run a GitLab Runner Fleet
 

doc/topics/autodevops/index.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Auto DevOps **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38366) in GitLab 11.0.
-> - Support for the GitLab Agent was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299350) in GitLab 14.5.
+> - Support for the GitLab agent was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/299350) in GitLab 14.5.
 
 GitLab Auto DevOps is a collection of pre-configured features and integrations
 that work together to support your software delivery process.

doc/topics/autodevops/stages.md

@@ -659,7 +659,7 @@ ciliumNetworkPolicy:
 #### Enabling Alerts
 
 You can also enable alerts. Network policies with alerts are considered only if
-[Agent](../../user/clusters/agent/index.md)
+the [agent](../../user/clusters/agent/index.md)
 has been integrated.
 
 You can enable alerts as follows:

doc/topics/release_your_application.md

@@ -26,17 +26,17 @@ deployment using GitLab CI/CD.
 ### Deploy applications to Kubernetes clusters
 
 With the extensive integration between GitLab and Kubernetes, you can safely deploy your applications
-to Kubernetes clusters using the [GitLab Agent](../user/clusters/agent/install/index.md).
+to Kubernetes clusters using the [GitLab agent](../user/clusters/agent/install/index.md).
 
 #### GitOps deployments **(PREMIUM)**
 
-With the [GitLab Agent](../user/clusters/agent/install/index.md), you can perform [pull-based
+With the [GitLab agent](../user/clusters/agent/install/index.md), you can perform [pull-based
 deployments of Kubernetes manifests](../user/clusters/agent/gitops.md). This provides a scalable, secure, and cloud-native
 approach to manage Kubernetes deployments.
 
 #### Deploy to Kubernetes with the CI/CD Tunnel
 
-With the [GitLab Agent](../user/clusters/agent/install/index.md), you can perform push-based
+With the [GitLab agent](../user/clusters/agent/install/index.md), you can perform push-based
 deployments with the [CI/CD Tunnel](../user/clusters/agent/ci_cd_tunnel.md). It provides
 a secure and reliable connection between GitLab and your Kubernetes cluster.
 

doc/user/application_security/cluster_image_scanning/index.md

@@ -29,7 +29,7 @@ To integrate GitLab with security scanners other than those listed here, see
 You can use cluster image scanning through the following methods:
 
 - [The cluster image scanning analyzer](#use-the-cluster-image-scanning-analyzer)
-- [The GitLab Agent](#cluster-image-scanning-with-the-gitlab-agent)
+- [The GitLab agent](#cluster-image-scanning-with-the-gitlab-agent)
 
 ## Use the cluster image scanning analyzer
 
@@ -277,22 +277,22 @@ Here's an example cluster image scanning report:
 }
 ```
 
-## Cluster image scanning with the GitLab Agent
+## Cluster image scanning with the GitLab agent
 
-You can use the [GitLab Agent](../../clusters/agent/index.md) to
+You can use the [GitLab agent](../../clusters/agent/index.md) to
 scan images from within your Kubernetes cluster and record the vulnerabilities in GitLab.
 
 ### Prerequisites
 
 - [Starboard Operator](https://aquasecurity.github.io/starboard/v0.10.3/operator/installation/kubectl/)
   installed and configured in your cluster.
-- [GitLab Agent](../../clusters/agent/install/index.md)
+- [GitLab agent](../../clusters/agent/install/index.md)
   set up in GitLab, installed in your cluster, and configured using a configuration repository.
 
 ### Configuration
 
-The Agent runs the cluster image scanning once the `cluster_image_scanning`
-directive is added to your [Agent's configuration repository](../../clusters/agent/vulnerabilities.md).
+The agent runs the cluster image scanning once the `cluster_image_scanning`
+directive is added to your [agent's configuration repository](../../clusters/agent/vulnerabilities.md).
 
 ## Security Dashboard
 
@@ -302,7 +302,7 @@ the security vulnerabilities in your groups, projects, and pipelines.
 ## Interacting with the vulnerabilities
 
 After you find a vulnerability, you can address it in the [vulnerability report](../vulnerabilities/index.md)
-or the [GitLab Agent's](../../clusters/agent/vulnerabilities.md)
+or the [GitLab agent's](../../clusters/agent/vulnerabilities.md)
 details section.
 
 ## Troubleshooting

doc/user/clusters/agent/index.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223061) in GitLab 13.4.
 > - Support for `grpcs` [introduced](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/7) in GitLab 13.6.
-> - Agent Server [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300960) on GitLab.com under `wss://kas.gitlab.com` through an Early Adopter Program in GitLab 13.10.
+> - Agent server [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300960) on GitLab.com under `wss://kas.gitlab.com` through an Early Adopter Program in GitLab 13.10.
 > - The agent became available to every project on GitLab.com in GitLab 13.11.
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) from GitLab Premium to GitLab Free in 14.5.
 > - [Renamed](https://gitlab.com/groups/gitlab-org/-/epics/7167) from "GitLab Kubernetes Agent" to "GitLab agent for Kubernetes" in GitLab 14.6.

doc/user/clusters/agent/repository.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Working with the agent for Kubernetes **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7.
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.11, the GitLab Agent became available on GitLab.com.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.11, the GitLab agent became available on GitLab.com.
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) the `ci_access` attribute in GitLab 14.3.
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) from GitLab Premium to GitLab Free in 14.5.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332227) in GitLab 14.0, the `resource_inclusions` and `resource_exclusions` attributes were removed and `reconcile_timeout`, `dry_run_strategy`, `prune`, `prune_timeout`, `prune_propagation_policy`, and `inventory_policy` attributes were added.

doc/user/clusters/agent/troubleshooting.md

@@ -4,9 +4,9 @@ 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
 ---
 
-# Troubleshooting the GitLab Agent for Kubernetes
+# Troubleshooting the GitLab agent for Kubernetes
 
-When you are using the GitLab Agent for Kubernetes, you might experience issues you need to troubleshoot.
+When you are using the GitLab agent for Kubernetes, you might experience issues you need to troubleshoot.
 
 You can start by viewing the service logs:
 
@@ -14,7 +14,7 @@ You can start by viewing the service logs:
 kubectl logs -f -l=app=gitlab-agent -n gitlab-kubernetes-agent
 ```
 
-If you are a GitLab administrator, you can also view the [GitLab Agent Server logs](../../../administration/clusters/kas.md#troubleshooting).
+If you are a GitLab administrator, you can also view the [GitLab agent server logs](../../../administration/clusters/kas.md#troubleshooting).
 
 ## Transport: Error while dialing failed to WebSocket dial
 
@@ -28,7 +28,7 @@ If you are a GitLab administrator, you can also view the [GitLab Agent Server lo
 ```
 
 This error is shown if there are some connectivity issues between the address
-specified as `kas-address`, and your Agent pod. To fix it, make sure that you
+specified as `kas-address`, and your agent pod. To fix it, make sure that you
 specified the `kas-address` correctly.
 
 ```json
@@ -189,4 +189,4 @@ Alternatively, you can mount the certificate file at a different location and in
 ```
 
 This error is shown if the manifest project is not public. To fix it, make sure your manifest project is public or your manifest files
-are stored in the Agent's configuration repository.
+are stored in the agent's configuration repository.

doc/user/clusters/integrations.md

@@ -32,9 +32,9 @@ to automate this step.
 
 Prometheus and Elastic Stack cluster integrations can only be enabled for clusters [connected through cluster certificates](../project/clusters/add_existing_cluster.md).
 
-To enable Prometheus for your cluster connected through the [GitLab Agent](agent/index.md), you can [integrate it manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
+To enable Prometheus for your cluster connected through the [GitLab agent](agent/index.md), you can [integrate it manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
 
-There is no option to enable Elastic Stack for your cluster if it is connected with the GitLab Agent.
+There is no option to enable Elastic Stack for your cluster if it is connected with the GitLab agent.
 Follow this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300230) for updates.
 
 ## Prometheus cluster integration
@@ -44,7 +44,7 @@ Follow this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300230) for up
 WARNING:
 This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. However, you can **still use** Prometheus
 for Kubernetes clusters connected to GitLab through the
-[Agent](agent/index.md) by [enabling Prometheus manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
+[agent](agent/index.md) by [enabling Prometheus manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
 
 You can integrate your Kubernetes cluster with
 [Prometheus](https://prometheus.io/) for monitoring key metrics of your

doc/user/clusters/management_project.md

@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 WARNING:
 The cluster management project was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
-To manage cluster applications, use the [GitLab Agent](agent/index.md)
+To manage cluster applications, use the [GitLab agent](agent/index.md)
 with the [Cluster Management Project Template](management_project_template.md).
 
 A project can be designated as the management project for a cluster.

doc/user/clusters/management_project_template.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25318) in GitLab 12.10 with Helmfile support via Helm v2.
 > - Helm v2 support was [dropped](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63577) in GitLab 14.0. Use Helm v3 instead.
-> - [Migrated](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/24) to the GitLab Agent in GitLab 14.5.
+> - [Migrated](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/24) to the GitLab agent in GitLab 14.5.
 
 Use a repository to install, manage, and deploy clusters applications through code.
 
@@ -31,45 +31,45 @@ you can manage cluster applications with [Helm v3](https://helm.sh/).
 - An `applications` directory with a `helmfile.yaml` configured for each
 application available in the template.
 
-## Use the Agent with the Cluster Management Project Template
+## Use the agent with the Cluster Management Project Template
 
 To use a new project created from the Cluster Management Project Template
-with a cluster connected to GitLab through the [GitLab Agent](agent/index.md),
+with a cluster connected to GitLab through the [GitLab agent](agent/index.md),
 you have two options:
 
-- [Use one single project](#single-project) to configure the Agent and manage cluster applications.
-- [Use separate projects](#separate-projects) - one to configure the Agent and another to manage cluster applications.
+- [Use one single project](#single-project) to configure the agent and manage cluster applications.
+- [Use separate projects](#separate-projects) - one to configure the agent and another to manage cluster applications.
 
 ### Single project
 
 This setup is particularly useful when you haven't connected your cluster
-to GitLab through the Agent yet and you want to use the Cluster Management
+to GitLab through the agent yet and you want to use the Cluster Management
 Project Template to manage cluster applications.
 
-To use one single project to configure the Agent and to manage cluster applications:
+To use one single project to configure the agent and to manage cluster applications:
 
 1. [Create a new project from the Cluster Management Project Template](#create-a-new-project-based-on-the-cluster-management-template).
-1. Configure the new project as the [Agent's configuration repository](agent/repository.md)
-(where the Agent is registered and its `config.yaml` is stored).
+1. Configure the new project as the [agent's configuration repository](agent/repository.md)
+(where the agent is registered and its `config.yaml` is stored).
 1. From your project's settings, add a [new environment variable](../../ci/variables/index.md#add-a-cicd-variable-to-a-project) `$KUBE_CONTEXT` and set it to `path/to/agent-configuration-project:your-agent-name`.
 1. [Configure the components](#configure-the-available-components) inherited from the template.
 
 ### Separate projects
 
 This setup is particularly useful **when you already have a cluster** connected
-to GitLab through the Agent and want to use the Cluster Management
+to GitLab through the agent and want to use the Cluster Management
 Project Template to manage cluster applications.
 
-To use one project to configure the Agent ("project A") and another project to
+To use one project to configure the agent ("project A") and another project to
 manage cluster applications ("project B"), follow the steps below.
 
-We assume that you already have a cluster connected through the Agent and
-[configured through the Agent's configuration repository](agent/repository.md)
+We assume that you already have a cluster connected through the agent and
+[configured through the agent's configuration repository](agent/repository.md)
 ("project A").
 
 1. [Create a new project from the Cluster Management Project Template](#create-a-new-project-based-on-the-cluster-management-template).
 This new project is "project B".
-1. In your "project A", [grant the Agent access to the new project (B) through the CI/CD Tunnel](agent/ci_cd_tunnel.md#authorize-the-agent).
+1. In your "project A", [grant the agent access to the new project (B) through the CI/CD Tunnel](agent/ci_cd_tunnel.md#authorize-the-agent).
 1. From the "project's B" settings, add a [new environment variable](../../ci/variables/index.md#add-a-cicd-variable-to-a-project) `$KUBE_CONTEXT` and set it to `path/to/agent-configuration-project:your-agent-name`.
 1. In "project B", [configure the components](#configure-the-available-components) inherited from the template.
 

doc/user/group/clusters/index.md

@@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 WARNING:
 This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. To connect clusters to GitLab,
-use the [GitLab Agent](../../clusters/agent/index.md).
+use the [GitLab agent](../../clusters/agent/index.md).
 
 Similar to [project-level](../../project/clusters/index.md) and
 [instance-level](../../instance/clusters/index.md) Kubernetes clusters,

doc/user/infrastructure/clusters/index.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Kubernetes clusters **(FREE)**
 
-To connect clusters to GitLab, use the [GitLab Agent](../../clusters/agent/index.md).
+To connect clusters to GitLab, use the [GitLab agent](../../clusters/agent/index.md).
 
 ## Certificate-based Kubernetes integration (DEPRECATED)
 
@@ -24,7 +24,7 @@ It had the following issues:
 - Users were constantly reporting issues with features based on this model.
 
 For this reason, we started to build features based on a new model, the
-[GitLab Agent](../../clusters/agent/index.md).
+[GitLab agent](../../clusters/agent/index.md).
 Maintaining both methods in parallel caused a lot of confusion
 and significantly increased the complexity to use, develop, maintain, and
 document them. For this reason, we decided to deprecate them to focus on the
@@ -38,7 +38,7 @@ Follow this [epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)
 for updates.
 
 You can find technical information about why we moved away from cluster certificates into
-the GitLab Agent model on the [Agent's blueprint documentation](../../../architecture/blueprints/gitlab_to_kubernetes_communication/index.md).
+the GitLab agent model on the [agent's blueprint documentation](../../../architecture/blueprints/gitlab_to_kubernetes_communication/index.md).
 
 ## Deprecated features
 
@@ -67,6 +67,6 @@ The concept of [project-level](../../project/clusters/index.md),
 [instance-level](../../instance/clusters/index.md) clusters becomes
 extinct in the new model, although the functionality remains to some extent.
 
-The Agent is always configured in a single GitLab project, but you can use the CI/CD Tunnel to
-authorize other projects and groups to use the same Agent.
+The agent is always configured in a single GitLab project, but you can use the CI/CD Tunnel to
+authorize other projects and groups to use the same agent.
 By doing so, you are granting these projects and groups access to the same cluster, which is similar to group-level clusters' use case.

doc/user/infrastructure/index.md

@@ -30,11 +30,11 @@ Learn more about how GitLab can help you run [Infrastructure as Code](iac/index.
 ## Integrated Kubernetes management
 
 The GitLab integration with Kubernetes helps you to install, configure, manage, deploy, and troubleshoot
-cluster applications. With the GitLab Agent, you can connect clusters behind a firewall,
+cluster applications. With the GitLab agent, you can connect clusters behind a firewall,
 have real-time access to API endpoints, perform pull-based or push-based deployments for production
 and non-production environments, and much more.
 
-Learn more about the [GitLab Agent](../clusters/agent/index.md).
+Learn more about the [GitLab agent](../clusters/agent/index.md).
 
 ## Runbooks in GitLab