Merge branch 'selhorn-remove-cicd-tunnel' into 'master'

Removed CI/CD tunnel

See merge request gitlab-org/gitlab!81347

doc/development/documentation/styleguide/word_list.md

@@ -201,10 +201,6 @@ CI/CD is always uppercase. No need to spell it out on first use.
 Use **CI/CD minutes** instead of **CI minutes**, **pipeline minutes**, **pipeline minutes quota**, or
 **CI pipeline minutes**. This decision was made in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342813).
 
-## CI/CD tunnel
-
-Use lowercase for **tunnel** in **CI/CD tunnel**.
-
 ## click
 
 Do not use **click**. Instead, use **select** with buttons, links, menu items, and lists.

doc/topics/autodevops/customize.md

@@ -431,7 +431,7 @@ applications.
 | `HELM_UPGRADE_EXTRA_ARGS`               | Allows extra options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. |
 | `INCREMENTAL_ROLLOUT_MODE`              | If present, can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
 | `K8S_SECRET_*`                          | Any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) is made available by Auto DevOps as environment variables to the deployed application. |
-| `KUBE_CONTEXT`                          | From GitLab 14.5, can be used to select which context to use from `KUBECONFIG`. When `KUBE_CONTEXT` is blank, the default context in `KUBECONFIG` (if any) will be used. A context must be selected when using the [CI/CD tunnel](../../user/clusters/agent/ci_cd_tunnel.md). |
+| `KUBE_CONTEXT`                          | From GitLab 14.5, can be used to select a context to use from `KUBECONFIG`. When `KUBE_CONTEXT` is blank, the default context in `KUBECONFIG` (if any) is used. A context must be selected when used [with the agent for Kubernetes](../../user/clusters/agent/ci_cd_tunnel.md). |
 | `KUBE_INGRESS_BASE_DOMAIN`              | Can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) for more information. |
 | `KUBE_NAMESPACE`                        | The namespace used for deployments. When using certificate-based clusters, [this value should not be overwritten directly](../../user/project/clusters/deploy_to_cluster.md#custom-namespace). |
 | `KUBECONFIG`                            | The kubeconfig to use for deployments. User-provided values take priority over GitLab-provided values. |

doc/topics/release_your_application.md

@@ -30,14 +30,14 @@ to Kubernetes clusters using the [GitLab agent](../user/clusters/agent/install/i
 
 #### GitOps deployments **(PREMIUM)**
 
-With the [GitLab agent](../user/clusters/agent/install/index.md), you can perform [pull-based
+With the [GitLab agent for Kubernetes](../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
+#### Deploy to Kubernetes from GitLab CI/CD
 
-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
+With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform [push-based
+deployments](../user/clusters/agent/ci_cd_tunnel.md) from GitLab CI/CD. The agent provides
 a secure and reliable connection between GitLab and your Kubernetes cluster.
 
 ### Deploy to AWS with GitLab CI/CD

doc/user/clusters/management_project_template.md

@@ -25,7 +25,7 @@ For instance, you can:
 
 The template contains the following [components](#configure-the-available-components):
 
-- A pre-configured GitLab CI/CD file so that you can configure CI/CD pipelines using the [CI/CD Tunnel](agent/ci_cd_tunnel.md).
+- A pre-configured `.gitlab-ci.yml`file so that you can configure CI/CD pipelines using [the agent for Kubernetes](agent/ci_cd_tunnel.md).
 - A pre-configured [Helmfile](https://github.com/roboll/helmfile) so that
 you can manage cluster applications with [Helm v3](https://helm.sh/).
 - An `applications` directory with a `helmfile.yaml` configured for each
@@ -69,7 +69,7 @@ We assume that you already have a cluster connected through the agent and
 
 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)](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/infrastructure/clusters/index.md

@@ -67,6 +67,5 @@ 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 and you can expose the cluster connection to other projects and groups to [access it from GitLab CI/CD](../../clusters/agent/ci_cd_tunnel.md).
 By doing so, you are granting these projects and groups access to the same cluster, which is similar to group-level clusters' use case.