Merge branch 'use-local-tiller-by-default' into 'master'

Use local Tiller by default

See merge request gitlab-org/gitlab!35562

app/models/clusters/cluster.rb

@@ -337,7 +337,7 @@ module Clusters
     end
 
     def local_tiller_enabled?
-      Feature.enabled?(:managed_apps_local_tiller, clusterable, default_enabled: false)
+      Feature.enabled?(:managed_apps_local_tiller, clusterable, default_enabled: true)
     end
 
     private

changelogs/unreleased/use-local-tiller-by-default.yml

+---
+title: Use local Tiller by default for GitLab-managed apps
+merge_request: 35562
+author:
+type: changed

doc/README.md

@@ -314,7 +314,7 @@ The following documentation relates to the DevOps **Configure** stage:
 | [Create Kubernetes clusters](user/project/clusters/add_remove_clusters.md#create-new-cluster)                                      | Use Kubernetes and GitLab.                                                |
 | [Executable Runbooks](user/project/clusters/runbooks/index.md)                                                                     | Documented procedures that explain how to carry out particular processes. |
 | [GitLab ChatOps](ci/chatops/README.md)                                                                                             | Interact with CI/CD jobs through chat services.                           |
-| [Installing Applications](user/project/clusters/index.md#installing-applications)                                                  | Deploy Helm, Ingress, and Prometheus on Kubernetes.                       |
+| [Installing Applications](user/project/clusters/index.md#installing-applications)                                                  | Install Helm charts such as Ingress and Prometheus on Kubernetes.         |
 | [Mattermost slash commands](user/project/integrations/mattermost_slash_commands.md)                                                | Enable and use slash commands from within Mattermost.                     |
 | [Multiple Kubernetes Clusters](user/project/clusters/index.md#multiple-kubernetes-clusters-premium) **(PREMIUM)**                  | Associate more than one Kubernetes clusters to your project.              |
 | [Protected variables](ci/variables/README.md#protect-a-custom-variable)                                                            | Restrict variables to protected branches and tags.                        |

doc/topics/autodevops/index.md

@@ -279,8 +279,8 @@ To add a different cluster for each environment:
 1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes**.
 1. Create the Kubernetes clusters with their respective environment scope, as
    described from the table above.
-1. After creating the clusters, navigate to each cluster and install Helm Tiller
-   and Ingress. Wait for the Ingress IP address to be assigned.
+1. After creating the clusters, navigate to each cluster and install
+   Ingress. Wait for the Ingress IP address to be assigned.
 1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the
    specified Auto DevOps domains.
 1. Navigate to each cluster's page, through **{cloud-gear}** **Operations > Kubernetes**,
@@ -301,9 +301,9 @@ No documented way of using private container registry with Auto DevOps exists.
 We strongly advise using GitLab Container Registry with Auto DevOps to
 simplify configuration and prevent any unforeseen issues.
 
-### Installing Helm behind a proxy
+### Install applications behind a proxy
 
-GitLab does not support installing [Helm as a GitLab-managed App](../../user/clusters/applications.md#helm) when
+GitLab's Helm integration does not support installing applications when
 behind a proxy. Users who want to do so must inject their proxy settings
 into the installation pods at runtime, such as by using a
 [`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/):

doc/topics/autodevops/quick_start_guide.md

@@ -98,24 +98,10 @@ status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
 Next, you will install some applications on your cluster that are needed
 to take full advantage of Auto DevOps.
 
-## Install the package manager
-
-After creating your Kubernetes cluster, GitLab's Kubernetes integration provides
-[pre-defined applications](../../user/project/clusters/index.md#installing-applications)
-for you to install. To install them, you must next install Helm Tiller, the
-Kubernetes package manager for Kubernetes, to enable the installation of other applications.
-
-Next to **Helm Tiller**, click **Install**.
-
-![Cluster applications](img/guide_cluster_apps_v12_3.png)
-
-After installation completes, the page reloads, and you can install other
-applications.
-
 ## Install Ingress and Prometheus
 
-After installing **Helm Tiller**, you can install other applications that rely on it,
-including Ingress and Prometheus, which we will install in this quick start guide:
+After your cluster is running, you can install your first applications.
+In this guide, we will install Ingress and Prometheus:
 
 - Ingress - Provides load balancing, SSL termination, and name-based virtual hosting,
   using NGINX behind the scenes.

doc/topics/web_application_firewall/quick_start_guide.md

@@ -92,7 +92,7 @@ status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
 The next step is to install some applications on your cluster that are needed
 to take full advantage of Auto DevOps.
 
-## Installing Helm and Ingress
+## Install Ingress
 
 GitLab's Kubernetes integration comes with some
 [pre-defined applications](../../user/project/clusters/index.md#installing-applications)
@@ -100,12 +100,6 @@ for you to install.
 
 ![Cluster applications](../autodevops/img/guide_cluster_apps_v12_3.png)
 
-The first one to install is Helm Tiller, a package manager for Kubernetes, which
-is needed in order to install the rest of the applications. Go ahead and click
-its **Install** button.
-Once it is installed, the other applications that rely on it will each have their
-**Install** buttons enabled.
-
 For this guide, we need to install Ingress. Ingress provides load balancing,
 SSL termination, and name-based virtual hosting, using NGINX behind
 the scenes. Make sure to switch the toogle to the enabled position before installing.

doc/user/clusters/applications.md

@@ -32,8 +32,6 @@ To see a list of available applications to install. For a:
 - [Group-level cluster](../group/clusters/index.md), navigate to your group's
   **{cloud-gear}** **Kubernetes** page.
 
-Install Helm first as it's used to install other applications.
-
 NOTE: **Note:**
 As of GitLab 11.6, Helm will be upgraded to the latest version supported
 by GitLab before installing any of the applications.
@@ -71,32 +69,30 @@ can lead to confusion during deployments.
 
 > - Introduced in GitLab 10.2 for project-level clusters.
 > - Introduced in GitLab 11.6 for group-level clusters.
-> - A local Tiller option was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2 behind a feature flag, disabled by default.
+> - A local Tiller option was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2 behind a feature flag, enabled by default.
 > - The feature flag for local Tiller is enabled on GitLab.com.
 
 [Helm](https://helm.sh/docs/) is a package manager for Kubernetes and is
-required to install all the other applications. It is installed in its
-own pod inside the cluster which can run the `helm` CLI in a safe
-environment.
+used to install the GitLab-managed apps. GitLab runs each `helm` command
+in a pod within the `gitlab-managed-apps` namespace inside the cluster.
 
-The [Tiller](https://v2.helm.sh/docs/glossary/#tiller) server used by Helm is
-installed into the `gitlab-managed-apps` namespace, but this is changing to
-instead use a *local Tiller* server. It can be enabled or disabled using the
-`managed_apps_local_tiller` feature flag. When the local Tiller feature is
-enabled, the Helm application does not need to be installed and will not be
-shown in the list of applications.
+As of GitLab 13.2, the integration uses a local
+[Tiller](https://v2.helm.sh/docs/glossary/#tiller) by default. When using a
+local Tiller, the Helm application does not need to be installed and will not
+be shown in the list of applications.
 
 NOTE: **Note:**
-Installing Helm as a GitLab-managed App behind a proxy is not supported,
-but a [workaround](../../topics/autodevops/index.md#installing-helm-behind-a-proxy)
+GitLab's Helm integration does not support installing applications behind a proxy,
+but a [workaround](../../topics/autodevops/index.md#install-applications-behind-a-proxy)
 is available.
 
 ### Enable or disable local Tiller **(CORE ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2
+> - The option to disable local Tiller is [planned for removal](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.3
 
 Local Tiller is under development, but is ready for production use. It is
-deployed behind a feature flag that is **disabled by default**.
+deployed behind a feature flag that is **enabled by default**.
 [GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
 can enable it for your instance.
 

doc/user/project/clusters/add_remove_clusters.md

@@ -57,14 +57,10 @@ to manage the newly created cluster.
 NOTE: **Note:**
 Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5.
 
-When you install Helm into your cluster, the `tiller` service account
-is created with `cluster-admin` privileges in the `gitlab-managed-apps`
-namespace.
-
-This service account will be:
-
-- Added to the installed Helm Tiller.
-- Used by Helm to install and run [GitLab managed applications](index.md#installing-applications).
+The first time you install an application into your cluster, the `tiller` service
+account is created with `cluster-admin` privileges in the
+`gitlab-managed-apps` namespace. This service account will be used by Helm to
+install and run [GitLab managed applications](index.md#installing-applications).
 
 Helm will also create additional service accounts and other resources for each
 installed application. Consult the documentation of the Helm charts for each application
@@ -93,8 +89,8 @@ GitLab creates the following resources for RBAC clusters.
 | `gitlab`              | `ServiceAccount`     | `default` namespace                                                                                        | Creating a new cluster |
 | `gitlab-admin`        | `ClusterRoleBinding` | [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) roleRef | Creating a new cluster |
 | `gitlab-token`        | `Secret`             | Token for `gitlab` ServiceAccount                                                                          | Creating a new cluster |
-| `tiller`              | `ServiceAccount`     | `gitlab-managed-apps` namespace                                                                            | Installing Helm Tiller |
-| `tiller-admin`        | `ClusterRoleBinding` | `cluster-admin` roleRef                                                                                    | Installing Helm Tiller |
+| `tiller`              | `ServiceAccount`     | `gitlab-managed-apps` namespace                                                                            | Installing Helm charts |
+| `tiller-admin`        | `ClusterRoleBinding` | `cluster-admin` roleRef                                                                                    | Installing Helm charts |
 | Environment namespace | `Namespace`          | Contains all environment-specific resources                                                                | Deploying to a cluster |
 | Environment namespace | `ServiceAccount`     | Uses namespace of environment                                                                              | Deploying to a cluster |
 | Environment namespace | `Secret`             | Token for environment ServiceAccount                                                                       | Deploying to a cluster |
@@ -108,8 +104,8 @@ GitLab creates the following resources for ABAC clusters.
 |:----------------------|:---------------------|:-------------------------------------|:---------------------------|
 | `gitlab`              | `ServiceAccount`     | `default` namespace                         | Creating a new cluster |
 | `gitlab-token`        | `Secret`             | Token for `gitlab` ServiceAccount           | Creating a new cluster |
-| `tiller`              | `ServiceAccount`     | `gitlab-managed-apps` namespace             | Installing Helm Tiller |
-| `tiller-admin`        | `ClusterRoleBinding` | `cluster-admin` roleRef                     | Installing Helm Tiller |
+| `tiller`              | `ServiceAccount`     | `gitlab-managed-apps` namespace             | Installing Helm charts |
+| `tiller-admin`        | `ClusterRoleBinding` | `cluster-admin` roleRef                     | Installing Helm charts |
 | Environment namespace | `Namespace`          | Contains all environment-specific resources | Deploying to a cluster |
 | Environment namespace | `ServiceAccount`     | Uses namespace of environment               | Deploying to a cluster |
 | Environment namespace | `Secret`             | Token for environment ServiceAccount        | Deploying to a cluster |

doc/user/project/clusters/runbooks/index.md

@@ -42,9 +42,6 @@ To create an executable runbook, you will need:
 - **Kubernetes** - A Kubernetes cluster is required to deploy the rest of the
   applications. The simplest way to get started is to add a cluster using one
   of [GitLab's integrations](../add_remove_clusters.md#create-new-cluster).
-- **Helm Tiller** - Helm is a package manager for Kubernetes and is required to
-  install all the other applications. It's installed in its own pod inside the
-  cluster which can run the Helm CLI in a safe environment.
 - **Ingress** - Ingress can provide load balancing, SSL termination, and name-based
   virtual hosting. It acts as a web proxy for your applications.
 - **JupyterHub** - [JupyterHub](https://jupyterhub.readthedocs.io/) is a multi-user
@@ -68,13 +65,8 @@ the components outlined above and the pre-loaded demo runbook.
 
 1. Add a Kubernetes cluster to your project by following the steps outlined in
    [Create new cluster](../add_remove_clusters.md#create-new-cluster).
-1. After the cluster has been provisioned in GKE, click the **Install** button
-   next to the **Helm Tiller** application to install Helm Tiller.
 
-   ![install helm](img/helm-install.png)
-
-1. After Helm Tiller has been installed successfully, click the **Install** button next
-   to the **Ingress** application.
+1. Click the **Install** button next to the **Ingress** application to install Ingress.
 
    ![install ingress](img/ingress-install.png)
 

doc/user/project/clusters/serverless/index.md

@@ -51,8 +51,6 @@ To run Knative on GitLab, you will need:
 1. **Kubernetes Cluster:** An RBAC-enabled Kubernetes cluster is required to deploy Knative.
    The simplest way to get started is to add a cluster using GitLab's [GKE integration](../add_remove_clusters.md).
    The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
-1. **Helm Tiller:** Helm is a package manager for Kubernetes and is required to install
-   Knative.
 1. **GitLab Runner:** A runner is required to run the CI jobs that will deploy serverless
    applications or functions onto your cluster. You can install the GitLab Runner
    onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information.
@@ -80,8 +78,8 @@ To run Knative on GitLab, you will need:
 NOTE: **Note:**
 The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB memory. **RBAC must be enabled.**
 
-1. [Add a Kubernetes cluster](../add_remove_clusters.md) and [install Helm](../index.md#installing-applications).
-1. Once Helm has been successfully installed, scroll down to the Knative app section. Enter the domain to be used with
+1. [Add a Kubernetes cluster](../add_remove_clusters.md).
+1. Select the **Applications** tab and scroll down to the Knative app section. Enter the domain to be used with
    your application/functions (e.g. `example.com`) and click **Install**.
 
    ![install-knative](img/install-knative.png)

doc/user/project/integrations/prometheus.md

@@ -32,11 +32,10 @@ GitLab can seamlessly deploy and manage Prometheus on a [connected Kubernetes cl
 #### Requirements
 
 - A [connected Kubernetes cluster](../clusters/index.md)
-- Helm Tiller [installed by GitLab](../clusters/index.md#installing-applications)
 
 #### Getting started
 
-Once you have a connected Kubernetes cluster with Helm installed, deploying a managed Prometheus is as easy as a single click.
+Once you have a connected Kubernetes cluster, deploying a managed Prometheus is as easy as 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
@@ -51,7 +50,7 @@ After completing the steps above, you will also need deployments in order to vie
 will help you to quickly create a deployment:
 
 1. Navigate to your project's **Operations > Kubernetes** page, and ensure that,
-   in addition to "Prometheus" and "Helm Tiller", you also have "Runner" and "Ingress"
+   in addition to "Prometheus", you also have "Runner" and "Ingress"
    installed. Once "Ingress" is installed, 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.