Remove GitLab-managed applications UI

Part of https://gitlab.com/gitlab-org/gitlab/-/issues/293583

Changelog: removed

app/assets/javascripts/clusters/forms/components/integration_form.vue

@@ -41,17 +41,10 @@ export default {
       toggleEnabled: true,
       envScope: '*',
       baseDomainField: '',
-      externalIp: '',
     };
   },
   computed: {
-    ...mapState([
-      'enabled',
-      'editable',
-      'environmentScope',
-      'baseDomain',
-      'applicationIngressExternalIp',
-    ]),
+    ...mapState(['enabled', 'editable', 'environmentScope', 'baseDomain']),
     canSubmit() {
       return (
         this.enabled !== this.toggleEnabled ||
@@ -64,7 +57,6 @@ export default {
     this.toggleEnabled = this.enabled;
     this.envScope = this.environmentScope;
     this.baseDomainField = this.baseDomain;
-    this.externalIp = this.applicationIngressExternalIp;
   },
 };
 </script>
@@ -135,13 +127,6 @@ export default {
             <gl-link :href="autoDevopsHelpPath" target="_blank">{{ content }}</gl-link>
           </template>
         </gl-sprintf>
-        <div v-if="applicationIngressExternalIp" class="js-ingress-domain-help-text inline">
-          {{ s__('ClusterIntegration|Alternatively, ') }}
-          <gl-sprintf :message="s__('ClusterIntegration|%{externalIp}.nip.io')">
-            <template #externalIp>{{ externalIp }}</template>
-          </gl-sprintf>
-          {{ s__('ClusterIntegration|can be used instead of a custom domain. ') }}
-        </div>
         <gl-sprintf
           class="inline"
           :message="s__('ClusterIntegration|%{linkStart}More information%{linkEnd}')"

app/assets/javascripts/clusters/forms/stores/state.js

@@ -6,7 +6,6 @@ export default (initialState = {}) => {
     editable: parseBoolean(initialState.editable),
     environmentScope: initialState.environmentScope,
     baseDomain: initialState.baseDomain,
-    applicationIngressExternalIp: initialState.applicationIngressExternalIp,
     autoDevopsHelpPath: initialState.autoDevopsHelpPath,
     externalEndpointHelpPath: initialState.externalEndpointHelpPath,
   };

app/views/clusters/clusters/show.html.haml

@@ -27,9 +27,6 @@
   provider_type: @cluster.provider_type,
   pre_installed_knative: @cluster.knative_pre_installed? ? 'true': 'false',
   help_path: help_page_path('user/project/clusters/index.md'),
-  helm_help_path: help_page_path('user/clusters/applications.md', anchor: 'helm'),
-  ingress_help_path: help_page_path('user/clusters/applications.md', anchor: 'determining-the-external-endpoint-automatically'),
-  ingress_dns_help_path: help_page_path('user/clusters/applications.md', anchor: 'pointing-your-dns-at-the-external-endpoint'),
   environments_help_path: help_page_path('ci/environments/index.md', anchor: 'create-a-static-environment'),
   clusters_help_path: help_page_path('user/project/clusters/index.md', anchor: 'deploying-to-a-kubernetes-cluster'),
   deploy_boards_help_path: help_page_path('user/project/deploy_boards.md', anchor: 'enabling-deploy-boards'),
@@ -51,13 +48,20 @@
 
   = render 'banner'
 
+  .gl-alert.gl-alert-warning{ role: 'alert' }
+    = sprite_icon('warning', css_class: "gl-alert-icon gl-alert-icon-no-title gl-icon")
+    %button.js-close.gl-alert-dismiss{ type: 'button', 'aria-label' => _('Dismiss'), data: { testid: 'dismiss-one-click-application-removal' } }
+      = sprite_icon('close', css_class: 'gl-icon')
+    .gl-alert-body
+      = s_('ClusterApplicationsRemoved|One-click application management was removed in GitLab 14.0. Your applications are still installed in your cluster, and integrations continue working.')
+      = link_to _('More information.'), help_page_path("user/clusters/applications"), target: '_blank'
+
   - if cluster_created?(@cluster)
     .js-toggle-container
       %ul.nav-links.mobile-separator.nav.nav-tabs{ role: 'tablist' }
         = render 'details_tab'
         = render_if_exists 'clusters/clusters/environments_tab'
         = render 'clusters/clusters/health_tab'
-        = render 'applications_tab'
         = render 'integrations_tab'
         = render 'advanced_settings_tab'
 

doc/development/architecture.md

@@ -215,7 +215,7 @@ click NodeExporter "./architecture.html#node-exporter"
 ### Component legend
 
 - ✅ - Installed by default
-- ⚙ - Requires additional configuration, or GitLab Managed Apps
+- ⚙ - Requires additional configuration
 - ⤓ - Manual installation required
 - ❌ - Not supported or no instructions available
 - N/A - Not applicable

doc/operations/index.md

@@ -73,7 +73,7 @@ production services. GitLab provides centralized, aggregated log storage for you
 distributed application, enabling you to collect logs across multiple services and
 infrastructure.
 
-- [View logs of pods or managed applications](../user/project/clusters/kubernetes_pod_logs.md)
+- [View logs of pods](../user/project/clusters/kubernetes_pod_logs.md)
   in connected Kubernetes clusters.
 
 ## Manage your infrastructure in code

doc/operations/metrics/dashboards/index.md

@@ -217,8 +217,46 @@ links:
 
 ## Troubleshooting
 
-When troubleshooting issues with a managed Prometheus app, it is often useful to
-[view the Prometheus UI](../../../user/project/integrations/prometheus.md#access-the-ui-of-a-prometheus-managed-application-in-kubernetes).
+### Accessing the UI of Prometheus in Kubernetes
+
+When troubleshooting issues with an in-cluster Prometheus, it can help to
+view the Prometheus UI. In the example below, we assume the Prometheus
+server to be the pod  `prometheus-prometheus-server` in the `gitlab-managed-apps`
+namespace:
+
+1. Find the name of the Prometheus pod in the user interface of your Kubernetes
+   provider, such as GKE, or by running the following `kubectl` command in your
+   terminal. For example:
+
+   ```shell
+   kubectl get pods -n gitlab-managed-apps | grep 'prometheus-prometheus-server'
+   ```
+
+   The command should return a result like the following example, where
+   `prometheus-prometheus-server-55b4bd64c9-dpc6b` is the name of the Prometheus pod:
+
+   ```plaintext
+   gitlab-managed-apps  prometheus-prometheus-server-55b4bd64c9-dpc6b  2/2  Running  0  71d
+   ```
+
+1. Run a `kubectl port-forward` command. In the following example, `9090` is the
+   Prometheus server's listening port:
+
+   ```shell
+    kubectl port-forward prometheus-prometheus-server-55b4bd64c9-dpc6b 9090:9090 -n gitlab-managed-apps
+   ```
+
+   The `port-forward` command forwards all requests sent to your system's `9090` port
+   to the `9090` port of the Prometheus pod. If the `9090` port on your system is used
+   by another application, you can change the port number before the colon to your
+   desired port. For example, to forward port `8080` of your local system, change the
+   command to:
+
+   ```shell
+   kubectl port-forward prometheus-prometheus-server-55b4bd64c9-dpc6b 8080:9090 -n gitlab-managed-apps
+   ```
+
+1. Open `localhost:9090` in your browser to display the Prometheus user interface.
 
 ### "No data found" error on Metrics dashboard page
 

doc/operations/metrics/index.md

@@ -16,10 +16,10 @@ critical. For GitLab to display your information in charts, you must:
    For an overview, see [How to instrument Prometheus metrics in GitLab](https://www.youtube.com/watch?v=tuI2oJ3TTB4).
 1. **Expose metrics for capture** - Make logs, metrics, and traces available for capture.
 1. [**Configure Prometheus to gather metrics**](#configure-prometheus-to-gather-metrics) -
-   Deploy managed applications like Elasticsearch, Prometheus, and Jaeger to gather
+   Use applications like Elasticsearch, Prometheus, and Jaeger to gather
    the data you've exposed.
 1. **GitLab collects metrics** - GitLab uses Prometheus to scrape the data you've
-   captured in your managed apps, and prepares the data for display. To learn more, read
+   captured in your applications, and prepares the data for display. To learn more, read
    [Collect and process metrics](#collect-and-process-metrics).
 1. **Display charts in the GitLab user interface** - GitLab converts your metrics
    into easy-to-read charts on a default dashboard. You can create as many custom charts
@@ -34,30 +34,10 @@ your Prometheus integration depends on where your apps are running:
 - **For manually-configured Prometheus** -
   [Specify your Prometheus server](../../user/project/integrations/prometheus.md#manual-configuration-of-prometheus),
   and define at least one environment.
-- **For GitLab-managed Prometheus** - GitLab can
-  [deploy and manage Prometheus](../../user/project/integrations/prometheus.md#managed-prometheus-on-kubernetes) for you.
-  You must also complete a code deployment, as described in
-  [Deploy code with GitLab-managed Prometheus](#deploy-code-with-gitlab-managed-prometheus),
-  for the **Operations > Metrics** page to contain data.
-
-### Deploy code with GitLab-managed Prometheus
-
-For GitLab-managed Prometheus, you can set up [Auto DevOps](../../topics/autodevops/index.md)
-to quickly create a deployment:
-
-1. Navigate to your project's **Operations > Kubernetes** page.
-1. Ensure that, in addition to Prometheus, you also have GitLab Runner and Ingress
-   installed.
-1. After installing Ingress, copy its endpoint.
-1. Navigate to your project's **Settings > CI/CD** page. In the
-   **Auto DevOps** section, select a deployment strategy and save your changes.
-1. On the same page, in the **Variables** section, add a variable named
-   `KUBE_INGRESS_BASE_DOMAIN` with the value of the Ingress endpoint you
-   copied previously. Leave the type as **Variable**.
-1. Navigate to your project's **{rocket}** **CI/CD > Pipelines** page, and run a
-   pipeline on any branch.
-1. When the pipeline has run successfully, graphs are available on the
-   **Operations > Metrics** page.
+- **For a cluster integrated Prometheus** - GitLab can query
+  [an in-cluster Prometheus](../../user/clusters/integrations.md#prometheus-cluster-integration).
+  You must also complete a code deployment to your cluster for the **Operations > Metrics**
+  page to contain data. You can do this using [Auto DevOps](../../topics/autodevops/quick_start_guide.md).
 
 ![Monitoring Dashboard](img/prometheus_monitoring_dashboard_v13_3.png)
 

doc/topics/autodevops/requirements.md

@@ -66,8 +66,7 @@ To make full use of Auto DevOps with Kubernetes, you need:
 
   Runners should be registered as [shared runners](../../ci/runners/runners_scope.md#shared-runners)
   for the entire GitLab instance, or [specific runners](../../ci/runners/runners_scope.md#specific-runners)
-  that are assigned to specific projects (the default if you've installed the
-  GitLab Runner managed application).
+  that are assigned to specific projects.
 
 - **Prometheus** (for [Auto Monitoring](stages.md#auto-monitoring))
 

doc/user/clusters/applications.md

@@ -14,8 +14,7 @@ If you want to migrate your GitLab managed apps management to this template, ref
 cluster directly from GitLab. You could use this feature through two different
 methods: "one-click install" and "CI/CD template". Both methods are **deprecated**:
 
-- The **one-click install** method was deprecated in GitLab 13.9 and **will be
-  removed** in GitLab 14.0.
+- The **one-click install** method was [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63348) 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.
 
@@ -23,12 +22,6 @@ Both methods were limiting as you couldn't fully customize your third-party apps
 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.
@@ -38,8 +31,8 @@ WARNING:
 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.
+The new recommended way to manage cluster applications is to use the [cluster management project template](management_project_template.md).
+If you want to migrate your GitLab managed apps management to this template, reference to [migrating from GitLab managed apps to project template](migrating_from_gma_to_project_template.md).
 
 The CI/CD template was the primary method for installing applications to clusters via GitLab Managed Apps
 and customize them through Helm.
@@ -822,11 +815,6 @@ management project. Refer to the
 [chart](https://gitlab.com/gitlab-org/charts/elastic-stack) for all
 available configuration options.
 
-NOTE:
-In this alpha implementation of installing Elastic Stack through CI, reading the
-environment logs through Elasticsearch is unsupported. This is supported if
-[installed with the UI](#elastic-stack).
-
 Support for installing the Elastic Stack managed application is provided by the
 GitLab APM group. If you run into unknown issues,
 [open a new issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new), and ping at
@@ -1034,565 +1022,29 @@ GitLab Container Security group. If you run into unknown issues,
 at least 2 people from the
 [Container Security group](https://about.gitlab.com/handbook/product/categories/#container-security-group).
 
-## Browse applications logs
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36769) in GitLab 13.2.
-
-Logs produced by pods running **GitLab Managed Apps** can be browsed using
-[**Log Explorer**](../project/clusters/kubernetes_pod_logs.md).
+## Install with one click (REMOVED)
 
-## Install with one click (DEPRECATED)
+> [Removed](https://gitlab.com/groups/gitlab-org/-/epics/4280) in GitLab 14.0.
 
-WARNING:
-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.
+The one-click installation method was deprecated in GitLab 13.9 and 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, it only
+removes the "Applications" tab from the cluster page.
 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:
-
-- Is different from the namespace used for project deployments.
-- Is created once.
-- Has a non-configurable name.
-
-To view a list of available applications to install for a:
-
-- [Project-level cluster](../project/clusters/index.md), navigate to your project's
-  **Operations > Kubernetes**.
-- [Group-level cluster](../group/clusters/index.md), navigate to your group's
-  **Kubernetes** page.
-
-You can install the following applications with one click:
-
-- [Helm](#helm)
-- [Ingress](#ingress)
-- [cert-manager](#cert-manager)
-- [Prometheus](#prometheus)
-- [GitLab Runner](#gitlab-runner)
-- [JupyterHub](#jupyterhub)
-- [Knative](#knative)
-- [Crossplane](#crossplane)
-- [Elastic Stack](#elastic-stack)
-
-With the exception of Knative, the applications are installed in a dedicated
-namespace called `gitlab-managed-apps`.
-
-Some applications are installable only for a project-level cluster.
-Support for installing these applications in a group-level cluster is
-planned for future releases.
-For updates, see the [issue tracking progress](https://gitlab.com/gitlab-org/gitlab/-/issues/24411).
-
-WARNING:
-If you have an existing Kubernetes cluster with Helm already installed,
-you should be careful as GitLab cannot detect it. In this case, installing
-Helm with the applications results in the cluster having it twice, which
-can lead to confusion during deployments.
-
-In GitLab versions 11.6 and greater, Helm is upgraded to the latest version
-supported by GitLab before installing any of the applications.
-
-### Helm
-
-> - Introduced in GitLab 10.2 for project-level clusters.
-> - Introduced in GitLab 11.6 for group-level clusters.
-> - [Uses a local Tiller](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2 and later.
-> - [Uses Helm 3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46267) for clusters created with GitLab 13.6 and later.
-> - [Offers legacy Tiller removal](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47457) in GitLab 13.7 and later.
-
-[Helm](https://helm.sh/docs/) is a package manager for Kubernetes and is
-used to install the GitLab-managed apps. GitLab runs each `helm` command
-in a pod in the `gitlab-managed-apps` namespace inside the cluster.
-
-- For clusters created in GitLab 13.6 and newer, GitLab uses Helm 3 to manage
-  applications.
-- For clusters created on versions of GitLab prior to 13.6, GitLab uses Helm 2
-  with a local [Tiller](https://v2.helm.sh/docs/glossary/#tiller) server. Prior
-  to [GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/209736), GitLab
-  used an in-cluster Tiller server in the `gitlab-managed-apps` namespace. You
-  can safely uninstall the server from the GitLab application page if you have
-  previously installed it. This doesn't affect your other applications.
-
-The GitLab Helm integration does not support installing applications behind a proxy,
-but a [workaround](../../topics/autodevops/index.md#install-applications-behind-a-proxy)
-is available.
-
-#### Upgrade a cluster to Helm 3
-
-GitLab does not offer a way to migrate existing application management
-on existing clusters from Helm 2 to Helm 3. To migrate a cluster to Helm 3:
-
-1. Uninstall all applications on your cluster.
-1. [Remove the cluster integration](../project/clusters/add_remove_clusters.md#removing-integration).
-1. [Re-add the cluster](../project/clusters/add_remove_clusters.md#existing-kubernetes-cluster) as
-   an existing cluster.
-
-### cert-manager
-
-> Introduced in GitLab 11.6 for project- and group-level clusters.
-
-[cert-manager](https://cert-manager.io/docs/) is a native Kubernetes certificate
-management controller that helps with issuing certificates. Installing
-cert-manager on your cluster issues a certificate by [Let's Encrypt](https://letsencrypt.org/)
-and ensures that certificates are valid and up-to-date.
-
-The chart used to install this application depends on the version of GitLab used. In:
-
-- GitLab 12.3 and newer, the [`jetstack/cert-manager`](https://github.com/jetstack/cert-manager)
-  chart is used with a
-  [`values.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/vendor/cert_manager/values.yaml)
-  file.
-- GitLab 12.2 and older, the
-  [`stable/cert-manager`](https://github.com/helm/charts/tree/master/stable/cert-manager)
-  chart was used.
-
-If you installed cert-manager prior to GitLab 12.3, Let's Encrypt
-[blocks requests](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
-from older versions of `cert-manager`. To resolve this:
-
-1. [Back up any additional configuration](https://cert-manager.io/docs/tutorials/backup/).
-1. Uninstall cert-manager.
-1. Install cert-manager again.
-
-### GitLab Runner
-
-> - Introduced in GitLab 10.6 for project-level clusters.
-> - Introduced in GitLab 11.10 for group-level clusters.
-
-[GitLab Runner](https://docs.gitlab.com/runner/) is the open source project that
-is used to run your jobs and send the results back to GitLab. It's used in
-conjunction with [GitLab CI/CD](../../ci/README.md), the open-source continuous
-integration service included with GitLab that coordinates the jobs.
-
-If the project is on GitLab.com, [shared runners](../gitlab_com/index.md#shared-runners)
-are available. You don't have to deploy one if they are enough for your
-needs. If a project-specific runner is desired, or there are no shared runners,
-you can deploy one.
-
-The deployed runner is set as **privileged**. Root access to the underlying
-server is required to build Docker images, so it's the default. Be sure to read
-the [security implications](../project/clusters/index.md#security-implications)
-before deploying one.
-
-The [`runner/gitlab-runner`](https://gitlab.com/gitlab-org/charts/gitlab-runner)
-chart is used to install this application, using
-[a preconfigured `values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/main/values.yaml)
-file. Customizing the installation by modifying this file is not supported. This
-also means you cannot modify `config.toml` file for this Runner. If you want to
-have that possibility and still deploy Runner in Kubernetes, consider using the
-[Cluster management project](management_project.md) or installing Runner manually
-via [GitLab Runner Helm Chart](https://docs.gitlab.com/runner/install/kubernetes.html).
-
-### Ingress
-
-> - Introduced in GitLab 10.2 for project-level clusters.
-> - Introduced in GitLab 11.6 for group-level clusters.
-
-[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
-provides load balancing, SSL termination, and name-based virtual hosting
-out of the box. It acts as a web proxy for your applications and is useful
-if you want to use [Auto DevOps](../../topics/autodevops/index.md) or deploy your own web apps.
-
-The Ingress Controller installed is
-[Ingress-NGINX](https://kubernetes.io/docs/concepts/services-networking/ingress/),
-which is supported by the Kubernetes community.
+If you are not yet on GitLab 14.0 or later, you can refer to [an older version of this document](https://docs.gitlab.com/13.12/ee/user/clusters/applications.html#install-with-one-click-deprecated).
 
-With the following procedure, a load balancer must be installed in your cluster
-to obtain the endpoint. You can use either
-Ingress, or Knative's own load balancer ([Istio](https://istio.io)) if using Knative.
-
-To publish your web application, you first need to find the endpoint, which is either an IP
-address or a hostname associated with your load balancer.
-
-To install it, click on the **Install** button for Ingress. GitLab attempts
-to determine the external endpoint and it should be available in a few minutes.
-
-#### Determining the external endpoint automatically
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17052) in GitLab 10.6.
-
-After you install Ingress, the external endpoint should be available in a few minutes.
-
-NOTE:
-This endpoint can be used for the
-[Auto DevOps base domain](../../topics/autodevops/index.md#auto-devops-base-domain)
-using the `KUBE_INGRESS_BASE_DOMAIN` environment variable.
-
-If the endpoint doesn't appear and your cluster runs on Google Kubernetes Engine:
-
-1. [Examine your Kubernetes cluster](https://console.cloud.google.com/kubernetes)
-   on Google Kubernetes Engine to ensure there are no errors on its nodes.
-1. Ensure you have enough [Quotas](https://console.cloud.google.com/iam-admin/quotas)
-   on Google Kubernetes Engine. For more information, see
-   [Resource Quotas](https://cloud.google.com/compute/quotas).
-1. Review [Google Cloud's Status](https://status.cloud.google.com/) for service
-   disruptions.
-
-The [`stable/nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
-chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/vendor/ingress/values.yaml)
-file.
-
-After installing, you may see a `?` for **Ingress IP Address** depending on the
-cloud provider. For EKS specifically, this is because the ELB is created
-with a DNS name, not an IP address. If GitLab is still unable to
-determine the endpoint of your Ingress or Knative application, you can
-[determine it manually](#determining-the-external-endpoint-manually).
-
-#### Determining the external endpoint manually
-
-See the [Base domain section](../project/clusters/index.md#base-domain) for a
-guide on how to determine the external endpoint manually.
-
-#### Using a static IP
-
-By default, an ephemeral external IP address is associated to the cluster's load
-balancer. If you associate the ephemeral IP with your DNS and the IP changes,
-your apps aren't reachable, and you'd have to change the DNS record again.
-To avoid that, change it into a static reserved IP.
-
-Read how to [promote an ephemeral external IP address in GKE](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip).
-
-#### Pointing your DNS at the external endpoint
-
-After you have set up the external endpoint, associate it with a
-[wildcard DNS record](https://en.wikipedia.org/wiki/Wildcard_DNS_record) (such
-as `*.example.com.`) to reach your apps. If your external endpoint is an IP
-address, use an A record. If your external endpoint is a hostname, use a CNAME
-record.
-
-### JupyterHub
-
-> - Introduced in GitLab 11.0 for project-level clusters.
-> - Introduced in GitLab 12.3 for group and instance-level clusters.
-
-[JupyterHub](https://jupyterhub.readthedocs.io/en/stable/) is a multi-user service
-for managing notebooks across a team. [Jupyter Notebooks](https://jupyter-notebook.readthedocs.io/en/latest/)
-provide a web-based interactive programming environment used for data analysis,
-visualization, and machine learning.
-
-The [`jupyter/jupyterhub`](https://jupyterhub.github.io/helm-chart/)
-chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/vendor/jupyter/values.yaml)
-file.
-
-Authentication is enabled only for [project members](../project/members/index.md)
-for project-level clusters and group members for group-level clusters with
-[Developer or higher](../permissions.md) access to the associated project or group.
-
-GitLab uses a [custom Jupyter image](https://gitlab.com/gitlab-org/jupyterhub-user-image/blob/master/Dockerfile)
-that installs additional relevant packages on top of the base Jupyter. Ready-to-use
-DevOps Runbooks built with Nurtch's [Rubix library](https://github.com/Nurtch/rubix)
-are also available.
-
-More information on creating executable runbooks can be found in
-[our Runbooks documentation](../project/clusters/runbooks/index.md#configure-an-executable-runbook-with-gitlab).
-Ingress must be installed and have an IP address assigned before
-JupyterHub can be installed.
-
-#### Jupyter Git Integration
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28783) in GitLab 12.0 for project-level clusters.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/32512) in GitLab 12.3 for group and instance-level clusters.
-
-When installing JupyterHub onto your Kubernetes cluster,
-[JupyterLab's Git extension](https://github.com/jupyterlab/jupyterlab-git)
-is provisioned and configured using the authenticated user's:
-
-- Name.
-- Email.
-- Newly created access token.
-
-JupyterLab's Git extension enables full version control of your notebooks, and
-issuance of Git commands in Jupyter. You can issue Git commands through the
-**Git** tab on the left panel, or through Jupyter's command-line prompt.
-
-JupyterLab's Git extension stores the user token in the JupyterHub DB in encrypted
-format, and in the single user Jupyter instance as plain text, because
-[Git requires storing credentials as plain text](https://git-scm.com/docs/git-credential-store)
-Potentially, if a nefarious user finds a way to read from the file system in the
-single-user Jupyter instance, they could retrieve the token.
-
-![Jupyter's Git Extension](img/jupyter-git-extension.gif)
-
-You can clone repositories from the files tab in Jupyter:
-
-![Jupyter clone repository](img/jupyter-gitclone.png)
-
-### Knative
-
-> - Introduced in GitLab 11.5 for project-level clusters.
-> - Introduced in GitLab 12.3 for group- and instance-level clusters.
-
-[Knative](https://cloud.google.com/knative/) provides a platform to
-create, deploy, and manage serverless workloads from a Kubernetes
-cluster. It's used in conjunction with, and includes
-[Istio](https://istio.io) to provide an external IP address for all
-programs hosted by Knative.
-
-The [`knative/knative`](https://storage.googleapis.com/triggermesh-charts)
-chart is used to install this application.
-
-During installation, you must enter a wildcard domain where your applications
-are exposed. Configure your DNS server to use the external IP address for that
-domain. Applications created and installed are accessible as
-`<program_name>.<kubernetes_namespace>.<domain_name>`, which requires
-your Kubernetes cluster to have
-[RBAC enabled](../project/clusters/add_remove_clusters.md#rbac-cluster-resources).
-
-### Prometheus
-
-> - Introduced in GitLab 10.4 for project-level clusters.
-> - Introduced in GitLab 11.11 for group-level clusters.
-
-[Prometheus](https://prometheus.io/docs/introduction/overview/) is an
-open-source monitoring and alerting system you can use to supervise your
-deployed applications.
-
-GitLab is able to monitor applications by using the
-[Prometheus integration](../project/integrations/prometheus.md). Kubernetes container CPU and
-memory metrics are collected, and response metrics are also retrieved
-from NGINX Ingress.
-
-The [`stable/prometheus`](https://github.com/helm/charts/tree/master/stable/prometheus)
-chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/vendor/prometheus/values.yaml)
-file.
-
-To enable monitoring, install Prometheus into the cluster with the **Install**
-button.
-
-### Crossplane
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34702) in GitLab 12.5 for project-level clusters.
-
-[Crossplane](https://crossplane.github.io/docs/v0.9/) is a multi-cloud control plane
-to help you manage applications and infrastructure across multiple clouds. It extends the
-Kubernetes API using:
-
-- Custom resources.
-- Controllers that watch those custom resources.
-
-Crossplane allows provisioning and lifecycle management of infrastructure components
-across cloud providers in a uniform manner by abstracting cloud provider-specific
-configurations.
-
-The Crossplane GitLab-managed application:
-
-- Installs Crossplane with a provider of choice on a Kubernetes cluster attached to the
-  project repository.
-- Can then be used to provision infrastructure or managed applications such as
-  PostgreSQL (for example, CloudSQL from GCP or RDS from AWS) and other services
-  required by the application with the Auto DevOps pipeline.
-
-[`alpha/crossplane`](https://github.com/crossplane/crossplane/tree/v0.4.1/cluster/charts/crossplane) chart v0.4.1 is used to
-install Crossplane using the
-[`values.yaml`](https://github.com/crossplane/crossplane/blob/master/cluster/charts/crossplane/values.yaml.tmpl)
-file.
-
-For information about configuring Crossplane installed on the cluster, see
-[Crossplane configuration](crossplane.md).
-
-### Elastic Stack
-
-> Introduced in GitLab 12.7 for project- and group-level clusters.
-
-[Elastic Stack](https://www.elastic.co/elastic-stack) is a complete end-to-end
-log analysis solution which helps in deep searching, analyzing and visualizing the logs
-generated from different machines.
-
-GitLab can gather logs from pods in your cluster. Filebeat runs as a DaemonSet
-on each node in your cluster, and ships container logs to Elasticsearch for
-querying. GitLab then connects to Elasticsearch for logs, instead of the
-Kubernetes API, giving you access to more advanced querying capabilities. Log
-data is deleted after 30 days, using [Curator](https://www.elastic.co/guide/en/elasticsearch/client/curator/5.5/about.html).
-
-The Elastic Stack cluster application is intended as a log aggregation solution
-and is not related to our [Advanced Search](../search/advanced_search.md)
-functionality, which uses a separate Elasticsearch cluster.
-
-To enable log shipping:
-
-1. Ensure your cluster contains at least three nodes of instance types larger
-   than `f1-micro`, `g1-small`, or `n1-standard-1`.
-1. Navigate to **Operations > Kubernetes**.
-1. In **Kubernetes Cluster**, select a cluster.
-1. In the **Applications** section, find **Elastic Stack**, and then select
-   **Install**.
-
-The [`gitlab/elastic-stack`](https://gitlab.com/gitlab-org/charts/elastic-stack)
-chart is used to install this application with a
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/vendor/elastic_stack/values.yaml)
-file. The chart deploys three identical Elasticsearch pods which can't be
-colocated, and each requires one CPU and 2 GB of RAM, making them
-incompatible with clusters containing fewer than three nodes, or consisting of
-`f1-micro`, `g1-small`, `n1-standard-1`, or `*-highcpu-2` instance types.
-
-#### Optional: deploy Kibana to perform advanced queries
-
-If you are an advanced user and have direct access to your Kubernetes cluster
-using `kubectl` and `helm`, you can deploy Kibana manually. The following assumes
-that `helm` has been [initialized](https://v2.helm.sh/docs/helm/) with `helm init`.
-
-Save the following to `kibana.yml`:
-
-```yaml
-elasticsearch:
-  enabled: false
-
-filebeat:
-  enabled: false
-
-kibana:
-  enabled: true
-  elasticsearchHosts: http://elastic-stack-elasticsearch-master.gitlab-managed-apps.svc.cluster.local:9200
-```
-
-Then install it on your cluster:
-
-```shell
-helm repo add gitlab https://charts.gitlab.io
-helm install --name kibana gitlab/elastic-stack --values kibana.yml
-```
-
-To access Kibana, forward the port to your local machine:
-
-```shell
-kubectl port-forward svc/kibana-kibana 5601:5601
-```
-
-Then, you can visit Kibana at `http://localhost:5601`.
-
-## Upgrading applications
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24789) in GitLab 11.8.
-
-The applications below can be upgraded.
-
-| Application | GitLab version |
-| ----------- | -------------- |
-| GitLab Runner  | 11.8+          |
-
-To upgrade an application:
-
-1. For a:
-   - [Project-level cluster](../project/clusters/index.md),
-     navigate to your project's **Operations > Kubernetes**.
-   - [Group-level cluster](../group/clusters/index.md),
-     navigate to your group's **Kubernetes** page.
-1. Select your cluster.
-1. If an upgrade is available, the **Upgrade** button is displayed. Click the button to upgrade.
-
-Upgrades reset values back to the values built into the `runner` chart, plus the values set by
-[`values.yaml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/vendor/runner/values.yaml)
-
-## Uninstalling applications
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/60665) in GitLab 11.11.
-
-The applications below can be uninstalled.
-
-| Application | GitLab version | Notes |
-| ----------- | -------------- | ----- |
-| cert-manager | 12.2+         | The associated private key is deleted and cannot be restored. Deployed applications continue to use HTTPS, but certificates aren't renewed. Before uninstalling, you may want to [back up your configuration](https://cert-manager.io/docs/tutorials/backup/) or [revoke your certificates](https://letsencrypt.org/docs/revoking/). |
-| GitLab Runner  | 12.2+         | Any running pipelines are canceled. |
-| Helm  | 12.2+         | The associated Tiller pod, the `gitlab-managed-apps` namespace, and all of its resources are deleted and cannot be restored. |
-| Ingress  | 12.1+         | The associated load balancer and IP are deleted and cannot be restored. Furthermore, it can only be uninstalled if JupyterHub is not installed. |
-| JupyterHub  | 12.1+         | All data not committed to GitLab are deleted and cannot be restored. |
-| Knative  | 12.1+         | The associated IP are deleted and cannot be restored. |
-| Prometheus  | 11.11+         | All data are deleted and cannot be restored. |
-| Crossplane  | 12.5+         | All data are deleted and cannot be restored. |
-| Elastic Stack  | 12.7+         | All data are deleted and cannot be restored. |
-| Sentry  | 12.6+         | The PostgreSQL persistent volume remains and should be manually removed for complete uninstall.  |
-
-To uninstall an application:
-
-1. For a:
-   - [Project-level cluster](../project/clusters/index.md),
-     navigate to your project's **Operations > Kubernetes**.
-   - [Group-level cluster](../group/clusters/index.md),
-     navigate to your group's **Kubernetes** page.
-1. Select your cluster.
-1. Click the **Uninstall** button for the application.
-
-Support for uninstalling all applications is planned for progressive rollout.
-To follow progress, see the [relevant epic](https://gitlab.com/groups/gitlab-org/-/epics/1201).
-
-## Troubleshooting applications
-
-Applications can fail with the following error:
-
-```plaintext
-Error: remote error: tls: bad certificate
-```
-
-To avoid installation errors:
-
-- Before starting the installation of applications, make sure that time is synchronized
-  between your GitLab server and your Kubernetes cluster.
-- Ensure certificates are not out of sync. When installing applications, GitLab
-  expects a new cluster with no previous installation of Helm.
-
-  You can confirm that the certificates match by using `kubectl`:
-
-  ```shell
-  kubectl get configmaps/values-content-configuration-ingress -n gitlab-managed-apps -o \
-  "jsonpath={.data['cert\.pem']}" | base64 -d > a.pem
-  kubectl get secrets/tiller-secret -n gitlab-managed-apps -o "jsonpath={.data['ca\.crt']}" | base64 -d > b.pem
-  diff a.pem b.pem
-  ```
-
-### Error installing managed apps on EKS cluster
-
-If you're using a managed cluster on AWS EKS, and you are not able to install some of the managed
-apps, consider checking the logs.
-
-You can check the logs by running the following commands:
-
-```shell
-kubectl get pods --all-namespaces
-kubectl get services --all-namespaces
-```
-
-If you are getting the `Failed to assign an IP address to container` error, it's probably due to the
-instance type you've specified in the AWS configuration.
-The number and size of nodes might not have enough IP addresses to run or install those pods.
-
-For reference, all the AWS instance IP limits are found
-[in this AWS repository on GitHub](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/awsutils/vpc_ip_resource_limit.go) (search for `InstanceENIsAvailable`).
-
-### Unable to install Prometheus
-
-Installing Prometheus is failing with the following error:
-
-```shell
-# kubectl -n gitlab-managed-apps logs install-prometheus
-...
-Error: Could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: admission.certmanager.k8s.io/v1beta1: the server is currently unable to handle the request
-```
-
-This is a bug that was introduced in Helm `2.15` and fixed in `3.0.2`. As a workaround,
-ensure [`cert-manager`](#cert-manager) is installed successfully prior to installing Prometheus.
-
-### Unable to create a Persistent Volume Claim with DigitalOcean
-
-Trying to create additional block storage volumes might lead to the following error when using DigitalOcean:
+## Browse applications logs
 
-```plaintext
-Server requested
-[Warning] pod has unbound immediate PersistentVolumeClaims (repeated 2 times)
-[Normal] pod didn't trigger scale-up (it wouldn't fit if a new node is added):
-Spawn failed: Timeout
-```
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36769) in GitLab 13.2.
 
-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)
+Logs produced by pods running **GitLab Managed Apps** can be browsed using
+[**Log Explorer**](../project/clusters/kubernetes_pod_logs.md).
 
 ## 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,
+With the removal of the One-click install method in GitLab 14.0,
 the **Applications** tab (under your project's  **Operations > Kubernetes**)
 will no longer be displayed:
 
@@ -1665,10 +1117,10 @@ If you choose to keep using Helm v2 (B), follow the steps below to manage your a
 
 ### 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:
+Some applications were not only installed in your cluster by GitLab through
+Managed Apps but were also directly integrated with GitLab. If you had one of
+these applications installed before GitLab 14.0, then a corresponding [cluster
+integration](integrations.md) has been automatically enabled:
 
 - [Prometheus cluster integration](integrations.md#prometheus-cluster-integration)
 - [Elastic Stack cluster integration](integrations.md#elastic-stack-cluster-integration)

doc/user/clusters/crossplane.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Crossplane configuration **(FREE)**
 
-After [installing](applications.md#crossplane) Crossplane, you must configure it for use.
+After [installing](applications.md#install-crossplane-using-gitlab-cicd) Crossplane, you must configure it for use.
 The process of configuring Crossplane includes:
 
 1. [Configure RBAC permissions](#configure-rbac-permissions).

doc/user/clusters/integrations.md

@@ -54,10 +54,8 @@ it up using [Helm](https://helm.sh/) as follows:
 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
-# - 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
+# These are included in the Cluster Management project template.
+wget https://gitlab.com/gitlab-org/project-templates/cluster-management/-/raw/master/applications/prometheus/values.yaml
 
 # Add the Prometheus community Helm chart repository
 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
@@ -114,10 +112,8 @@ running:
 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
+# These are included in the Cluster Management project template.
+wget https://gitlab.com/gitlab-org/project-templates/cluster-management/-/raw/master/applications/elastic-stack/values.yaml
 
 # Add the GitLab Helm chart repository
 helm repo add gitlab https://charts.gitlab.io

doc/user/project/clusters/kubernetes_pod_logs.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4752) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.0.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26383) to [GitLab Free](https://about.gitlab.com/pricing/) 12.9.
 
-GitLab makes it easy to view the logs of running pods or managed applications in
+GitLab makes it easy to view the logs of running pods in
 [connected Kubernetes clusters](index.md). By displaying the logs directly in GitLab
 in the **Log Explorer**, developers can avoid managing console tools or jumping
 to a different interface. The **Log Explorer** interface provides a set of filters
@@ -18,10 +18,11 @@ above the log file data, depending on your configuration:
 ![Pod logs](img/kubernetes_pod_logs_v12_10.png)
 
 - **Namespace** - Select the environment to display. Users with Maintainer or
-  greater [permissions](../../permissions.md) can also select Managed Apps.
-- **Search** - Only available if the Elastic Stack managed application is installed.
-- **Select time range** - Select the range of time to display. Only available if the
-  Elastic Stack managed application is installed.
+  greater [permissions](../../permissions.md) can also see pods in the
+  `gitlab-managed-apps` namespace.
+- **Search** - Only available if the [Elastic Stack integration](../../clusters/integrations.md#elastic-stack-cluster-integration) is enabled.
+- **Select time range** - Select the range of time to display.
+  Only available if the [Elastic Stack integration](../../clusters/integrations.md#elastic-stack-cluster-integration) is enabled.
 - **Scroll to bottom** **{scroll_down}** - Scroll to the end of the displayed logs.
 - **Refresh** **{retry}** - Reload the displayed logs.
 

doc/user/project/clusters/protect/container_host_security/quick_start_guide.md

@@ -20,7 +20,6 @@ The following steps are recommended to install and use Container Host Security t
 1. Install and configure an Ingress node:
 
    - [Install the Ingress node via CI/CD (Cluster Management Project)](../../../../clusters/applications.md#install-ingress-using-gitlab-cicd).
-   - [Determine the external endpoint via the manual method](../../../../clusters/applications.md#determining-the-external-endpoint-manually).
    - Navigate to the Kubernetes page and enter the [DNS address for the external endpoint](../../index.md#base-domain)
      into the **Base domain** field on the **Details** tab. Save the changes to the Kubernetes
      cluster.

doc/user/project/clusters/protect/container_network_security/quick_start_guide.md

@@ -20,7 +20,6 @@ The following steps are recommended to install and use Container Network Securit
 1. Install and configure an Ingress node:
 
    - [Install the Ingress node via CI/CD (Cluster Management Project)](../../../../clusters/applications.md#install-ingress-using-gitlab-cicd).
-   - [Determine the external endpoint via the manual method](../../../../clusters/applications.md#determining-the-external-endpoint-manually).
    - Navigate to the Kubernetes page and enter the [DNS address for the external endpoint](../../index.md#base-domain)
      into the **Base domain** field on the **Details** tab. Save the changes to the Kubernetes
      cluster.

doc/user/project/integrations/prometheus.md

@@ -17,7 +17,7 @@ in the GitLab interface.
 
 There are two ways to set up Prometheus integration, depending on where your apps are running:
 
-- For deployments on Kubernetes, GitLab can automatically [deploy and manage Prometheus](#managed-prometheus-on-kubernetes).
+- For deployments on Kubernetes, GitLab can be [integrated with an in-cluster Prometheus](#prometheus-cluster-integration)
 - For other deployment targets, [specify the Prometheus server](#manual-configuration-of-prometheus).
 
 Once enabled, GitLab detects metrics from known services in the
@@ -27,137 +27,13 @@ Once enabled, GitLab detects metrics from known services in the
 
 ## Enabling Prometheus Integration
 
-### Managed Prometheus on Kubernetes
+### Prometheus cluster integration
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28916) in GitLab 10.5.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55244) in GitLab 13.11.
+> - [Replaced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62725) the Prometheus cluster applications in GitLab 14.0.
 
-**Deprecated:** Managed Prometheus on Kubernetes is deprecated, and
-scheduled for removal in [GitLab
-14.0](https://gitlab.com/groups/gitlab-org/-/epics/4280).
-
-GitLab can seamlessly deploy and manage Prometheus on a
-[connected Kubernetes cluster](../clusters/index.md), to help you monitor your apps.
-
-#### Requirements
-
-- A [connected Kubernetes cluster](../clusters/index.md)
-
-#### Getting started
-
-After you have a connected Kubernetes cluster, you can deploy a managed Prometheus with a single click.
-
-1. Go to the **Operations > Kubernetes** page to view your connected clusters
-1. Select the cluster you would like to deploy Prometheus to
-1. Click the **Install** button to deploy Prometheus to the cluster
-
-![Managed Prometheus Deploy](img/prometheus_deploy.png)
-
-#### About managed Prometheus deployments
-
-Prometheus is deployed into the `gitlab-managed-apps` namespace, using the
-[official Helm chart](https://github.com/helm/charts/tree/master/stable/prometheus).
-Prometheus is only accessible in the cluster, with GitLab communicating through the
-[Kubernetes API](https://kubernetes.io/docs/concepts/overview/kubernetes-api/).
-
-The Prometheus server
-[automatically detects and monitors](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config)
-nodes, pods, and endpoints. To configure a resource to be monitored by Prometheus,
-set the following [Kubernetes annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/):
-
-- `prometheus.io/scrape` to `true` to enable monitoring of the resource.
-- `prometheus.io/port` to define the port of the metrics endpoint.
-- `prometheus.io/path` to define the path of the metrics endpoint. Defaults to `/metrics`.
-
-CPU and Memory consumption is monitored, but requires
-[naming conventions](prometheus_library/kubernetes.md#specifying-the-environment)
-to determine the environment. If you are using
-[Auto DevOps](../../../topics/autodevops/index.md), this is handled automatically.
-
-##### Example of Kubernetes service annotations and labels
-
-As an example, to activate Prometheus monitoring of a service:
-
-1. Add at least this annotation: `prometheus.io/scrape: 'true'`.
-1. Add two labels so GitLab can retrieve metrics dynamically for any environment:
-   - `application: ${CI_ENVIRONMENT_SLUG}`
-   - `release: ${CI_ENVIRONMENT_SLUG}`
-1. Create a dynamic PromQL query. For example, a query like
-   `temperature{application="{{ci_environment_slug}}",release="{{ci_environment_slug}}"}` to either:
-   - Add [custom metrics](../../../operations/metrics/index.md#adding-custom-metrics).
-   - Add [custom dashboards](../../../operations/metrics/dashboards/index.md).
-
-The following is a service definition to accomplish this:
-
-```yaml
----
-# Service
-apiVersion: v1
-kind: Service
-metadata:
-  name: service-${CI_PROJECT_NAME}-${CI_COMMIT_REF_SLUG}
-  # === Prometheus annotations ===
-  annotations:
-    prometheus.io/scrape: 'true'
-  labels:
-    application: ${CI_ENVIRONMENT_SLUG}
-    release: ${CI_ENVIRONMENT_SLUG}
-  # === End of Prometheus ===
-spec:
-  selector:
-    app: ${CI_PROJECT_NAME}
-  ports:
-    - port: ${EXPOSED_PORT}
-      targetPort: ${CONTAINER_PORT}
-```
-
-#### Access the UI of a Prometheus managed application in Kubernetes
-
-You can connect directly to Prometheus, and view the Prometheus user interface, when
-using a Prometheus managed application in Kubernetes:
-
-1. Find the name of the Prometheus pod in the user interface of your Kubernetes
-   provider, such as GKE, or by running the following `kubectl` command in your
-   terminal:
-
-   ```shell
-   kubectl get pods -n gitlab-managed-apps | grep 'prometheus-prometheus-server'
-   ```
-
-   The command should return a result like the following example, where
-   `prometheus-prometheus-server-55b4bd64c9-dpc6b` is the name of the Prometheus pod:
-
-   ```plaintext
-   gitlab-managed-apps  prometheus-prometheus-server-55b4bd64c9-dpc6b  2/2  Running  0  71d
-   ```
-
-1. Run a `kubectl port-forward` command. In the following example, `9090` is the
-   Prometheus server's listening port:
-
-   ```shell
-    kubectl port-forward prometheus-prometheus-server-55b4bd64c9-dpc6b 9090:9090 -n gitlab-managed-apps
-   ```
-
-   The `port-forward` command forwards all requests sent to your system's `9090` port
-   to the `9090` port of the Prometheus pod. If the `9090` port on your system is used
-   by another application, you can change the port number before the colon to your
-   desired port. For example, to forward port `8080` of your local system, change the
-   command to:
-
-   ```shell
-   kubectl port-forward prometheus-prometheus-server-55b4bd64c9-dpc6b 8080:9090 -n gitlab-managed-apps
-   ```
-
-1. Open `localhost:9090` in your browser to display the Prometheus user interface.
-
-#### Script access to Prometheus
-
-You can script the access to Prometheus, extracting the name of the pod automatically like this:
-
-```shell
-POD_INFORMATION=$(kubectl get pods -n gitlab-managed-apps | grep 'prometheus-prometheus-server')
-POD_NAME=$(echo $POD_INFORMATION | awk '{print $1;}')
-kubectl port-forward $POD_NAME 9090:9090 -n gitlab-managed-apps
-```
+GitLab can query an in-cluster Prometheus for your metrics.
+See [Prometheus cluster integration](../../clusters/integrations.md#prometheus-cluster-integration) for details.
 
 ### Manual configuration of Prometheus
 
@@ -219,12 +95,12 @@ to integrate with.
 ### Precedence with multiple Prometheus configurations
 
 Although you can enable both a [manual configuration](#manual-configuration-of-prometheus)
-and [auto configuration](#managed-prometheus-on-kubernetes) of Prometheus, you
+and [cluster integration](#prometheus-cluster-integration) of Prometheus, you
 can use only one:
 
 - If you have enabled a
   [Prometheus manual configuration](#manual-configuration-of-prometheus)
-  and a [managed Prometheus on Kubernetes](#managed-prometheus-on-kubernetes),
+  and a [Prometheus cluster integration](#prometheus-cluster-integration),
   the manual configuration takes precedence and is used to run queries from
   [custom dashboards](../../../operations/metrics/dashboards/index.md) and
   [custom metrics](../../../operations/metrics/index.md#adding-custom-metrics).

doc/user/project/integrations/prometheus_library/kubernetes.md

@@ -33,7 +33,7 @@ integration services must be enabled.
 
 Prometheus needs to be deployed into the cluster and configured properly in order to gather Kubernetes metrics. GitLab supports two methods for doing so:
 
-- GitLab [integrates with Kubernetes](../../clusters/index.md), and can [deploy Prometheus into a connected cluster](../prometheus.md#managed-prometheus-on-kubernetes). It is automatically configured to collect Kubernetes metrics.
+- GitLab [integrates with Kubernetes](../../clusters/index.md), and can [query a Prometheus in a connected cluster](../../../clusters/integrations.md#prometheus-cluster-integration). The in-cluster Prometheus can be configured to automatically collect application metrics from your cluster.
 - To configure your own Prometheus server, you can follow the [Prometheus documentation](https://prometheus.io/docs/introduction/overview/).
 
 ## Specifying the Environment

locale/gitlab.pot

@@ -6901,13 +6901,13 @@ msgstr ""
 msgid "ClusterAgent|You have insufficient permissions to delete this cluster agent"
 msgstr ""
 
-msgid "ClusterIntegration|%{appList} was successfully installed on your Kubernetes cluster"
+msgid "ClusterApplicationsRemoved|One-click application management was removed in GitLab 14.0. Your applications are still installed in your cluster, and integrations continue working."
 msgstr ""
 
-msgid "ClusterIntegration|%{boldStart}Note:%{boldEnd} Requires Ingress to be installed."
+msgid "ClusterIntegration|%{appList} was successfully installed on your Kubernetes cluster"
 msgstr ""
 
-msgid "ClusterIntegration|%{externalIp}.nip.io"
+msgid "ClusterIntegration|%{boldStart}Note:%{boldEnd} Requires Ingress to be installed."
 msgstr ""
 
 msgid "ClusterIntegration|%{linkStart}More information%{linkEnd}"
@@ -6973,9 +6973,6 @@ msgstr ""
 msgid "ClusterIntegration|Allows GitLab to query a specifically configured in-cluster Prometheus for metrics."
 msgstr ""
 
-msgid "ClusterIntegration|Alternatively, "
-msgstr ""
-
 msgid "ClusterIntegration|Amazon EKS"
 msgstr ""
 
@@ -7861,9 +7858,6 @@ msgstr ""
 msgid "ClusterIntegration|access to Google Kubernetes Engine"
 msgstr ""
 
-msgid "ClusterIntegration|can be used instead of a custom domain. "
-msgstr ""
-
 msgid "ClusterIntegration|installed via %{linkStart}Cloud Run%{linkEnd}"
 msgstr ""
 

spec/features/admin/clusters/applications_spec.rb

-# frozen_string_literal: true
-
-require 'spec_helper'
-require_relative '../../../../spec/features/clusters/installing_applications_shared_examples'
-
-RSpec.describe 'Instance-level Cluster Applications', :js do
-  include GoogleApi::CloudPlatformHelpers
-
-  let(:user) { create(:admin) }
-
-  before do
-    sign_in(user)
-    gitlab_enable_admin_mode_sign_in(user)
-  end
-
-  describe 'Installing applications' do
-    include_examples "installing applications on a cluster" do
-      let(:cluster_path) { admin_cluster_path(cluster) }
-      let(:cluster_factory_args) { [:instance] }
-    end
-  end
-end

spec/features/clusters/cluster_detail_page_spec.rb

@@ -31,30 +31,6 @@ RSpec.describe 'Clusterable > Show page' do
       expect(page).to have_content('Kubernetes cluster was successfully updated.')
     end
 
-    context 'when there is a cluster with ingress and external ip', :js do
-      before do
-        cluster.create_application_ingress!(external_ip: '192.168.1.100')
-
-        visit cluster_path
-      end
-
-      it 'shows help text with the domain as an alternative to custom domain', :js do
-        within '.js-cluster-details-form' do
-          expect(find(cluster_ingress_help_text_selector).text).to include('192.168.1.100')
-        end
-      end
-    end
-
-    context 'when there is no ingress' do
-      it 'alternative to custom domain is not shown' do
-        visit cluster_path
-
-        within '.js-cluster-details-form' do
-          expect(page).not_to have_selector(cluster_ingress_help_text_selector)
-        end
-      end
-    end
-
     it 'does not show the environments tab' do
       visit cluster_path
 

spec/features/clusters/cluster_health_dashboard_spec.rb

@@ -27,8 +27,8 @@ RSpec.describe 'Cluster Health board', :js, :kubeclient, :use_clean_rails_memory
     expect(page).to have_css('.cluster-health-graphs')
   end
 
-  context 'no prometheus enabled' do
-    it 'shows install prometheus message' do
+  context 'no prometheus available' do
+    it 'shows enable Prometheus message' do
       visit cluster_path
 
       click_link 'Health'
@@ -82,12 +82,12 @@ RSpec.describe 'Cluster Health board', :js, :kubeclient, :use_clean_rails_memory
 
     def stub_empty_response
       stub_prometheus_request(/prometheus-prometheus-server/, status: 204, body: {})
-      stub_prometheus_request(/prometheus\/api\/v1/, status: 204, body: {})
+      stub_prometheus_request(%r{prometheus/api/v1}, status: 204, body: {})
     end
 
     def stub_connected
       stub_prometheus_request(/prometheus-prometheus-server/, body: prometheus_values_body)
-      stub_prometheus_request(/prometheus\/api\/v1/, body: prometheus_values_body)
+      stub_prometheus_request(%r{prometheus/api/v1}, body: prometheus_values_body)
     end
   end
 end

spec/features/clusters/installing_applications_shared_examples.rb

-# frozen_string_literal: true
-
-RSpec.shared_examples "installing applications for a cluster" do
-  before do
-    # Reduce interval from 10 seconds which is too long for an automated test
-    stub_const("#{Clusters::ClustersController}::STATUS_POLLING_INTERVAL", 500)
-
-    visit cluster_path
-  end
-
-  context 'when cluster is being created' do
-    let(:cluster) { create(:cluster, :providing_by_gcp, *cluster_factory_args) }
-
-    it 'user is unable to install applications' do
-      expect(page).not_to have_text('Helm')
-      expect(page).not_to have_text('Install')
-    end
-  end
-
-  context 'when cluster is created' do
-    let(:cluster) { create(:cluster, :provided_by_gcp, *cluster_factory_args) }
-
-    before do
-      page.within('.js-edit-cluster-form') do
-        click_link 'Applications'
-      end
-    end
-
-    it 'user can install applications' do
-      wait_for_requests
-
-      application_row = '.js-cluster-application-row-ingress'
-
-      page.within(application_row) do
-        expect(page).not_to have_css('.js-cluster-application-install-button[disabled]')
-        expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Install')
-      end
-    end
-
-    it 'does not show the Helm application' do
-      expect(page).not_to have_selector(:css, '.js-cluster-application-row-helm')
-    end
-
-    context 'when user installs Knative' do
-      context 'on an abac cluster' do
-        let(:cluster) { create(:cluster, :provided_by_gcp, :rbac_disabled, *cluster_factory_args) }
-
-        it 'shows info block and not be installable' do
-          page.within('.js-cluster-application-row-knative') do
-            expect(page).to have_css('.rbac-notice')
-            expect(page.find(:css, '.js-cluster-application-install-button')['disabled']).to eq('true')
-          end
-        end
-      end
-
-      context 'on an rbac cluster' do
-        let(:cluster) { create(:cluster, :provided_by_gcp, *cluster_factory_args) }
-
-        it 'does not show callout block and be installable' do
-          page.within('.js-cluster-application-row-knative') do
-            expect(page).not_to have_css('p', text: 'You must have an RBAC-enabled cluster', visible: :all)
-            expect(page).to have_css('.js-cluster-application-install-button:not([disabled])')
-          end
-        end
-
-        describe 'when user clicks install button' do
-          before do
-            allow(ClusterInstallAppWorker).to receive(:perform_async)
-            allow(ClusterWaitForIngressIpAddressWorker).to receive(:perform_in)
-            allow(ClusterWaitForIngressIpAddressWorker).to receive(:perform_async)
-
-            page.within('.js-cluster-application-row-knative') do
-              expect(page).to have_css('.js-cluster-application-install-button:not([disabled])')
-
-              page.find('.js-knative-domainname').set("domain.example.org")
-
-              click_button 'Install'
-
-              wait_for_requests
-
-              expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
-
-              Clusters::Cluster.last.application_knative.make_installing!
-              Clusters::Cluster.last.application_knative.make_installed!
-              Clusters::Cluster.last.application_knative.update_attribute(:external_ip, '127.0.0.1')
-            end
-          end
-
-          it 'shows status transition' do
-            page.within('.js-cluster-application-row-knative') do
-              expect(page).to have_field('Knative Domain Name:', with: 'domain.example.org')
-              expect(page).to have_css('.js-cluster-application-uninstall-button', exact_text: 'Uninstall')
-            end
-
-            expect(page).to have_content('Knative was successfully installed on your Kubernetes cluster')
-            expect(page).to have_css('.js-knative-save-domain-button'), exact_text: 'Save changes'
-          end
-
-          it 'can then update the domain' do
-            page.within('.js-cluster-application-row-knative') do
-              expect(ClusterPatchAppWorker).to receive(:perform_async)
-
-              expect(page).to have_field('Knative Domain Name:', with: 'domain.example.org')
-
-              page.find('.js-knative-domainname').set("new.domain.example.org")
-
-              click_button 'Save changes'
-
-              wait_for_requests
-
-              expect(page).to have_field('Knative Domain Name:', with: 'new.domain.example.org')
-            end
-          end
-        end
-      end
-    end
-
-    context 'when user installs Cert Manager' do
-      before do
-        allow(ClusterInstallAppWorker).to receive(:perform_async)
-        allow(ClusterWaitForIngressIpAddressWorker).to receive(:perform_in)
-        allow(ClusterWaitForIngressIpAddressWorker).to receive(:perform_async)
-      end
-
-      it 'shows status transition' do
-        page.within('.js-cluster-application-row-cert_manager') do
-          click_button 'Install'
-          wait_for_requests
-
-          expect(page).to have_field('Issuer Email', with: cluster.user.email)
-          expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
-
-          Clusters::Cluster.last.application_cert_manager.make_installing!
-
-          expect(page).to have_field('Issuer Email', with: cluster.user.email)
-          expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
-
-          Clusters::Cluster.last.application_cert_manager.make_installed!
-
-          expect(page).to have_field('Issuer Email', with: cluster.user.email)
-          expect(page).to have_css('.js-cluster-application-uninstall-button', exact_text: 'Uninstall')
-        end
-
-        expect(page).to have_content('Cert-Manager was successfully installed on your Kubernetes cluster')
-      end
-
-      it 'installs with custom email' do
-        custom_email = 'new_email@example.org'
-
-        page.within('.js-cluster-application-row-cert_manager') do
-          # Wait for the polling to finish
-          wait_for_requests
-
-          page.find('.js-email').set(custom_email)
-          click_button 'Install'
-          wait_for_requests
-
-          expect(page).to have_field('Issuer Email', with: custom_email)
-          expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
-
-          Clusters::Cluster.last.application_cert_manager.make_installing!
-
-          expect(page).to have_field('Issuer Email', with: custom_email)
-          expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
-
-          Clusters::Cluster.last.application_cert_manager.make_installed!
-
-          expect(page).to have_field('Issuer Email', with: custom_email)
-          expect(page).to have_css('.js-cluster-application-uninstall-button', exact_text: 'Uninstall')
-        end
-      end
-    end
-
-    context 'when user installs Elastic Stack' do
-      before do
-        allow(ClusterInstallAppWorker).to receive(:perform_async)
-
-        page.within('.js-cluster-application-row-elastic_stack') do
-          click_button 'Install'
-        end
-
-        wait_for_requests
-      end
-
-      it 'shows status transition' do
-        page.within('.js-cluster-application-row-elastic_stack') do
-          expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
-
-          Clusters::Cluster.last.application_elastic_stack.make_installing!
-
-          expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
-
-          Clusters::Cluster.last.application_elastic_stack.make_installed!
-
-          expect(page).to have_css('.js-cluster-application-uninstall-button', exact_text: 'Uninstall')
-        end
-
-        expect(page).to have_content('Elastic Stack was successfully installed on your Kubernetes cluster')
-      end
-    end
-
-    context 'when user installs Ingress' do
-      before do
-        allow(ClusterInstallAppWorker).to receive(:perform_async)
-        allow(ClusterWaitForIngressIpAddressWorker).to receive(:perform_in)
-        allow(ClusterWaitForIngressIpAddressWorker).to receive(:perform_async)
-
-        page.within('.js-cluster-application-row-ingress') do
-          expect(page).to have_css('.js-cluster-application-install-button:not([disabled])')
-          page.find(:css, '.js-cluster-application-install-button').click
-
-          wait_for_requests
-        end
-      end
-
-      it 'shows the status transition' do
-        page.within('.js-cluster-application-row-ingress') do
-          # FE sends request and gets the response, then the buttons is "Installing"
-          expect(page).to have_css('.js-cluster-application-install-button[disabled]', exact_text: 'Installing')
-
-          Clusters::Cluster.last.application_ingress.make_installing!
-
-          # FE starts polling and update the buttons to "Installing"
-          expect(page).to have_css('.js-cluster-application-install-button[disabled]', exact_text: 'Installing')
-
-          # The application becomes installed but we keep waiting for external IP address
-          Clusters::Cluster.last.application_ingress.make_installed!
-
-          expect(page).to have_css('.js-cluster-application-install-button[disabled]', exact_text: 'Installed')
-          expect(page).to have_selector('.js-no-endpoint-message')
-          expect(page).to have_selector('.js-ingress-ip-loading-icon')
-
-          # We receive the external IP address and display
-          Clusters::Cluster.last.application_ingress.update!(external_ip: '192.168.1.100')
-
-          expect(page).not_to have_css('button', exact_text: 'Install', visible: :all)
-          expect(page).not_to have_css('button', exact_text: 'Installing', visible: :all)
-          expect(page).to have_css('.js-cluster-application-uninstall-button:not([disabled])', exact_text: 'Uninstall')
-          expect(page).not_to have_css('p', text: 'The endpoint is in the process of being assigned', visible: :all)
-          expect(page.find('.js-endpoint').value).to eq('192.168.1.100')
-        end
-
-        expect(page).to have_content('Ingress was successfully installed on your Kubernetes cluster')
-      end
-    end
-  end
-end
-
-RSpec.shared_examples "installing applications on a cluster" do
-  it_behaves_like "installing applications for a cluster", false
-  it_behaves_like "installing applications for a cluster", true
-end

spec/features/groups/clusters/applications_spec.rb

-# frozen_string_literal: true
-
-require 'spec_helper'
-require_relative '../../../../spec/features/clusters/installing_applications_shared_examples'
-
-RSpec.describe 'Group-level Cluster Applications', :js do
-  include GoogleApi::CloudPlatformHelpers
-
-  let(:group) { create(:group) }
-  let(:user) { create(:user) }
-
-  before do
-    group.add_maintainer(user)
-    sign_in(user)
-  end
-
-  describe 'Installing applications' do
-    include_examples "installing applications on a cluster" do
-      let(:cluster_path) { group_cluster_path(group, cluster) }
-      let(:cluster_factory_args) { [:group, groups: [group]] }
-    end
-  end
-end

spec/features/projects/clusters/applications_spec.rb

-# frozen_string_literal: true
-
-require 'spec_helper'
-require_relative '../../../../spec/features/clusters/installing_applications_shared_examples'
-
-RSpec.describe 'Project-level Cluster Applications', :js do
-  include GoogleApi::CloudPlatformHelpers
-
-  let(:project) { create(:project) }
-  let(:user) { create(:user) }
-
-  before do
-    project.add_maintainer(user)
-    sign_in(user)
-  end
-
-  describe 'Installing applications' do
-    include_examples "installing applications on a cluster" do
-      let(:cluster_path) { project_cluster_path(project, cluster) }
-      let(:cluster_factory_args) { [projects: [project]] }
-    end
-  end
-end

spec/frontend/clusters/forms/components/integration_form_spec.js

@@ -15,7 +15,6 @@ describe('ClusterIntegrationForm', () => {
     editable: true,
     environmentScope: '*',
     baseDomain: 'testDomain',
-    applicationIngressExternalIp: null,
   };
 
   const createWrapper = (storeValues = defaultStoreValues) => {
@@ -72,18 +71,6 @@ describe('ClusterIntegrationForm', () => {
         expect(findSubmitButton().exists()).toBe(false);
       });
     });
-
-    it('does not render external IP block if applicationIngressExternalIp was not passed', () => {
-      createWrapper({ ...defaultStoreValues });
-
-      expect(wrapper.find('.js-ingress-domain-help-text').exists()).toBe(false);
-    });
-
-    it('renders external IP block if applicationIngressExternalIp was passed', () => {
-      createWrapper({ ...defaultStoreValues, applicationIngressExternalIp: '127.0.0.1' });
-
-      expect(wrapper.find('.js-ingress-domain-help-text').exists()).toBe(true);
-    });
   });
 
   describe('reactivity', () => {