Add latest changes from gitlab-org/gitlab@13-7-stable-eev13.7.0-rc42

10 files changed, 148 insertions, 147 deletions

diff --git a/doc/user/project/clusters/add_eks_clusters.md b/doc/user/project/clusters/add_eks_clusters.md
index c3f2b96ce9f..07aa02db2b5 100644
--- a/doc/user/project/clusters/add_eks_clusters.md
+++ b/doc/user/project/clusters/add_eks_clusters.md
@@ -1,7 +1,7 @@
 ---
 stage: Configure
 group: Configure
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Adding EKS clusters
@@ -10,7 +10,7 @@ GitLab supports adding new and existing EKS clusters.
 
 ## EKS requirements
 
-Before creating your first cluster on Amazon EKS with GitLab's integration, make sure the following
+Before creating your first cluster on Amazon EKS with the GitLab integration, make sure the following
 requirements are met:
 
 - An [Amazon Web Services](https://aws.amazon.com/) account is set up and you are able to log in.
@@ -23,9 +23,9 @@ requirements are met:
 ### Additional requirements for self-managed instances **(CORE ONLY)**
 
 If you are using a self-managed GitLab instance, GitLab must first be configured with a set of
-Amazon credentials. These credentials will be used to assume an Amazon IAM role provided by the user
+Amazon credentials. These credentials are used to assume an Amazon IAM role provided by the user
 creating the cluster. Create an IAM user and ensure it has permissions to assume the role(s) that
-your users will use to create EKS clusters.
+your users need to create EKS clusters.
 
 For example, the following policy document allows assuming a role whose name starts with
 `gitlab-eks-` in account `123456789012`:
@@ -60,7 +60,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - Group's **Kubernetes** page, for a group-level cluster.
    - **Admin Area > Kubernetes**, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
-1. Under the **Create new cluster** tab, click **Amazon EKS**. You will be provided with an
+1. Under the **Create new cluster** tab, click **Amazon EKS** to display an
    `Account ID` and `External ID` needed for later steps.
 1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy:
    1. From the left panel, select **Policies**.
@@ -137,9 +137,9 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    1. Click **Next: Tags**, and optionally enter any tags you wish to associate with this role.
    1. Click **Next: Review**.
    1. Enter a role name and optional description into the fields provided.
-   1. Click **Create role**, the new role name will appear at the top. Click on its name and copy the `Role ARN` from the newly created role.
+   1. Click **Create role**, the new role name displays at the top. Click on its name and copy the `Role ARN` from the newly created role.
 1. In GitLab, enter the copied role ARN into the `Role ARN` field.
-1. In the **Cluster Region** field, enter the [region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) you plan to use for your new cluster. GitLab will authenticate you have access to this region when authenticating your role.
+1. In the **Cluster Region** field, enter the [region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) you plan to use for your new cluster. GitLab confirms you have access to this region when authenticating your role.
 1. Click **Authenticate with AWS**.
 1. Choose your cluster's settings:
    - **Kubernetes cluster name** - The name you wish to give the cluster.
@@ -148,7 +148,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - **Service role** - Select the **EKS IAM role** you created earlier to allow Amazon EKS
      and the Kubernetes control plane to manage AWS resources on your behalf.
 
-     NOTE: **Note:**
+     NOTE:
      This IAM role is _not_ the IAM role you created in the previous step. It should be
      the one you created much earlier by following the
      [Amazon EKS cluster IAM role](https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html)
@@ -158,7 +158,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - **VPC** - Select a [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
      to use for your EKS Cluster resources.
    - **Subnets** - Choose the [subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
-     in your VPC where your worker nodes will run. You must select at least two.
+     in your VPC where your worker nodes run. You must select at least two.
    - **Security group** - Choose the [security group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
      to apply to the EKS-managed Elastic Network Interfaces that are created in your worker node subnets.
    - **Instance type** - The [instance type](https://aws.amazon.com/ec2/instance-types/) of your worker nodes.
@@ -167,11 +167,11 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
      See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
 
-After about 10 minutes, your cluster will be ready to go. You can now proceed
+After about 10 minutes, your cluster is ready to go. You can now proceed
 to install some [pre-defined applications](index.md#installing-applications).
 
-NOTE: **Note:**
-You will need to add your AWS external ID to the
+NOTE:
+You must add your AWS external ID to the
 [IAM Role in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount)
 to manage your cluster using `kubectl`.
 
@@ -205,7 +205,7 @@ If the `Cluster` resource failed with the error
 `The provided role doesn't have the Amazon EKS Managed Policies associated with it.`,
 the role specified in **Role name** is not configured correctly.
 
-NOTE: **Note:**
+NOTE:
 This role should be the role you created by following the
 [EKS cluster IAM role](https://docs.aws.amazon.com/eks/latest/userguide/service_IAM_role.html) guide.
 In addition to the policies that guide suggests, you must also include the
@@ -219,9 +219,9 @@ For information on adding an existing EKS cluster, see
 ### Create a default Storage Class
 
 Amazon EKS doesn't have a default Storage Class out of the box, which means
-requests for persistent volumes will not be automatically fulfilled. As part
+requests for persistent volumes are not automatically fulfilled. As part
 of Auto DevOps, the deployed PostgreSQL instance requests persistent storage,
-and without a default storage class it will fail to start.
+and without a default storage class it cannot start.
 
 If a default Storage Class doesn't already exist and is desired, follow Amazon's
 [guide on storage classes](https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html)
@@ -239,18 +239,17 @@ to build, test, and deploy the app.
 [Enable Auto DevOps](../../../topics/autodevops/index.md#at-the-project-level)
 if not already enabled. If a wildcard DNS entry was created resolving to the
 Load Balancer, enter it in the `domain` field under the Auto DevOps settings.
-Otherwise, the deployed app will not be externally available outside of the cluster.
+Otherwise, the deployed app isn't externally available outside of the cluster.
 
 ![Deploy Pipeline](img/pipeline.png)
 
-A new pipeline will automatically be created, which will begin to build, test,
-and deploy the app.
+GitLab creates a new pipeline, which begins to build, test, and deploy the app.
 
-After the pipeline has finished, your app will be running in EKS and available
+After the pipeline has finished, your app runs in EKS, and is available
 to users. Click on **CI/CD > Environments**.
 
 ![Deployed Environment](img/environment.png)
 
-You will see a list of the environments and their deploy status, as well as
+GitLab displays a list of the environments and their deploy status, as well as
 options to browse to the app, view monitoring metrics, and even access a shell
 on the running pod.
diff --git a/doc/user/project/clusters/add_gke_clusters.md b/doc/user/project/clusters/add_gke_clusters.md
index 720f9bdf253..e3e6efc887f 100644
--- a/doc/user/project/clusters/add_gke_clusters.md
+++ b/doc/user/project/clusters/add_gke_clusters.md
@@ -1,7 +1,7 @@
 ---
 stage: Configure
 group: Configure
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Adding GKE clusters
@@ -10,7 +10,7 @@ GitLab supports adding new and existing GKE clusters.
 
 ## GKE requirements
 
-Before creating your first cluster on Google GKE with GitLab's integration, make sure the following
+Before creating your first cluster on Google GKE with GitLab integration, make sure the following
 requirements are met:
 
 - A [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account)
@@ -33,7 +33,7 @@ Note the following:
   created by GitLab are RBAC-enabled. Take a look at the [RBAC section](add_remove_clusters.md#rbac-cluster-resources) for
   more information.
 - Starting from [GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18341), the
-  cluster's pod address IP range will be set to /16 instead of the regular /14. /16 is a CIDR
+  cluster's pod address IP range is set to `/16` instead of the regular `/14`. `/16` is a CIDR
   notation.
 - GitLab requires basic authentication enabled and a client certificate issued for the cluster to
   set up an [initial service account](add_remove_clusters.md#access-controls). In [GitLab versions
@@ -57,20 +57,20 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - **Kubernetes cluster name** - The name you wish to give the cluster.
    - **Environment scope** - The [associated environment](index.md#setting-the-environment-scope) to this cluster.
    - **Google Cloud Platform project** - Choose the project you created in your GCP
-     console that will host the Kubernetes cluster. Learn more about
+     console to host the Kubernetes cluster. Learn more about
      [Google Cloud Platform projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects).
    - **Zone** - Choose the [region zone](https://cloud.google.com/compute/docs/regions-zones/)
-     under which the cluster will be created.
+     under which to create the cluster.
    - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
    - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
-     of the Virtual Machine instance that the cluster will be based on.
+     of the Virtual Machine instance to base the cluster on.
    - **Enable Cloud Run for Anthos** - Check this if you want to use Cloud Run for Anthos for this cluster.
      See the [Cloud Run for Anthos section](#cloud-run-for-anthos) for more information.
    - **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster.
      See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
 
-After a couple of minutes, your cluster will be ready to go. You can now proceed
+After a couple of minutes, your cluster is ready. You can now proceed
 to install some [pre-defined applications](index.md#installing-applications).
 
 ### Cloud Run for Anthos
@@ -79,7 +79,7 @@ to install some [pre-defined applications](index.md#installing-applications).
 
 You can choose to use Cloud Run for Anthos in place of installing Knative and Istio
 separately after the cluster has been created. This means that Cloud Run
-(Knative), Istio, and HTTP Load Balancing will be enabled on the cluster at
+(Knative), Istio, and HTTP Load Balancing are enabled on the cluster at
 create time and cannot be [installed or uninstalled](../../clusters/applications.md) separately.
 
 ## Existing GKE cluster
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index c96e38b1dfc..8ee9b1f37dd 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -1,7 +1,7 @@
 ---
 stage: Configure
 group: Configure
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Adding and removing Kubernetes clusters
@@ -13,16 +13,16 @@ GitLab offers integrated cluster creation for the following Kubernetes providers
 
 GitLab can also integrate with any standard Kubernetes provider, either on-premise or hosted.
 
-NOTE: **Note:**
+NOTE:
 Watch the webcast [Scalable app deployment with GitLab and Google Cloud Platform](https://about.gitlab.com/webcast/scalable-app-deploy/)
 and learn how to spin up a Kubernetes cluster managed by Google Cloud Platform (GCP)
 in a few clicks.
 
-TIP: **Tip:**
+NOTE:
 Every new Google Cloud Platform (GCP) account receives
 [$300 in credit upon sign up](https://console.cloud.google.com/freetrial).
 In partnership with Google, GitLab is able to offer an additional $200 for new GCP
-accounts to get started with GitLab's Google Kubernetes Engine Integration.
+accounts to get started with the GitLab integration with Google Kubernetes Engine.
 [Follow this link](https://cloud.google.com/partners/partnercredit/?pcn_code=0014M00001h35gDQAQ#contact-form)
 to apply for credit.
 
@@ -260,7 +260,7 @@ To add a Kubernetes cluster to your project, group, or instance:
          kubectl apply -f gitlab-admin-service-account.yaml --username=admin --password=<password>
          ```
 
-         NOTE: **Note:**
+         NOTE:
          Basic Authentication can be turned on and the password credentials
          can be obtained using the Google Cloud Console.
 
@@ -295,7 +295,7 @@ To add a Kubernetes cluster to your project, group, or instance:
          token:      <authentication_token>
          ```
 
-      NOTE: **Note:**
+      NOTE:
       For GKE clusters, you need the
       `container.clusterRoleBindings.create` permission to create a cluster
       role binding. You can follow the [Google Cloud
@@ -330,7 +330,7 @@ integration to work properly.
 
 ![RBAC](img/rbac_v13_1.png)
 
-CAUTION: **Caution:**
+WARNING:
 Disabling RBAC means that any application running in the cluster,
 or user who can authenticate to the cluster, has full API access. This is a
 [security concern](index.md#security-implications), and may not be desirable.
diff --git a/doc/user/project/clusters/eks_and_gitlab/index.md b/doc/user/project/clusters/eks_and_gitlab/index.md
index 895b51ea9bb..e38fbb871c1 100644
--- a/doc/user/project/clusters/eks_and_gitlab/index.md
+++ b/doc/user/project/clusters/eks_and_gitlab/index.md
@@ -3,3 +3,6 @@ redirect_to: '../add_eks_clusters.md#existing-eks-cluster'
 ---
 
 This document was moved to [another location](../add_eks_clusters.md#existing-eks-cluster).
+
+<!-- This redirect file can be deleted after February 1, 2021. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index 9273fb7b361..80db1c960db 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -1,7 +1,7 @@
 ---
 stage: Monitor
 group: Health
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Kubernetes clusters
@@ -20,7 +20,7 @@ Using the GitLab project Kubernetes integration, you can:
 - Detect and [monitor Kubernetes](#monitoring-your-kubernetes-cluster).
 - Use it with [Auto DevOps](#auto-devops).
 - Use [Web terminals](#web-terminals).
-- Use [Deploy Boards](#deploy-boards). **(PREMIUM)**
+- Use [Deploy Boards](#deploy-boards).
 - Use [Canary Deployments](#canary-deployments). **(PREMIUM)**
 - Use [deployment variables](#deployment-variables).
 - Use [role-based or attribute-based access controls](add_remove_clusters.md#access-controls).
@@ -45,18 +45,18 @@ versions at any given time. We regularly review the versions we support, and
 provide a three-month deprecation period before we remove support of a specific
 version. The range of supported versions is based on the evaluation of:
 
-- Our own needs.
 - The versions supported by major managed Kubernetes providers.
 - The versions [supported by the Kubernetes community](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions).
 
 GitLab supports the following Kubernetes versions, and you can upgrade your
 Kubernetes version to any supported version at any time:
 
-- 1.17
-- 1.16
-- 1.15
+- 1.19 (support ends on February 22, 2022)
+- 1.18 (support ends on November 22, 2021)
+- 1.17 (support ends on September 22, 2021)
+- 1.16 (support ends on July 22, 2021)
+- 1.15 (support ends on May 22, 2021)
 - 1.14 (deprecated, support ends on December 22, 2020)
-- 1.13 (deprecated, support ends on November 22, 2020)
 
 Some GitLab features may support versions outside the range provided here.
 
@@ -66,7 +66,7 @@ See [Adding and removing Kubernetes clusters](add_remove_clusters.md) for detail
 to:
 
 - Create a cluster in Google Cloud Platform (GCP) or Amazon Elastic Kubernetes Service
-  (EKS) using GitLab's UI.
+  (EKS) using the GitLab UI.
 - Add an integration to an existing cluster from any Kubernetes platform.
 
 ### Multiple Kubernetes clusters
@@ -79,8 +79,8 @@ project. That way you can have different clusters for different environments,
 like dev, staging, production, and so on.
 
 Simply add another cluster, like you did the first time, and make sure to
-[set an environment scope](#setting-the-environment-scope) that will
-differentiate the new cluster with the rest.
+[set an environment scope](#setting-the-environment-scope) that
+differentiates the new cluster from the rest.
 
 #### Setting the environment scope
 
@@ -89,9 +89,9 @@ them with an environment scope. The environment scope associates clusters with [
 [environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-environment-variables) work.
 
 The default environment scope is `*`, which means all jobs, regardless of their
-environment, will use that cluster. Each scope can only be used by a single
-cluster in a project, and a validation error will occur if otherwise.
-Also, jobs that don't have an environment keyword set will not be able to access any cluster.
+environment, use that cluster. Each scope can be used only by a single cluster
+in a project, and a validation error occurs if otherwise. Also, jobs that don't
+have an environment keyword set can't access any cluster.
 
 For example, let's say the following Kubernetes clusters exist in a project:
 
@@ -127,13 +127,13 @@ deploy to production:
     url: https://example.com/
 ```
 
-The result will then be:
+The results:
 
-- The Development cluster details will be available in the `deploy to staging`
+- The Development cluster details are available in the `deploy to staging`
   job.
-- The production cluster details will be available in the `deploy to production`
+- The production cluster details are available in the `deploy to production`
   job.
-- No cluster details will be available in the `test` job because it doesn't
+- No cluster details are available in the `test` job because it doesn't
   define any environment.
 
 ## Configuring your Kubernetes cluster
@@ -143,7 +143,7 @@ important considerations for configuring Kubernetes clusters with GitLab.
 
 ### Security implications
 
-CAUTION: **Important:**
+WARNING:
 The whole cluster security is based on a model where [developers](../../permissions.md)
 are trusted, so **only trusted users should be allowed to control your clusters**.
 
@@ -157,15 +157,15 @@ applications running on the cluster.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22011) in GitLab 11.5.
 > - Became [optional](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26565) in GitLab 11.11.
 
-You can choose to allow GitLab to manage your cluster for you. If your cluster is
-managed by GitLab, resources for your projects will be automatically created. See the
-[Access controls](add_remove_clusters.md#access-controls) section for details on which resources will
-be created.
+You can choose to allow GitLab to manage your cluster for you. If your cluster
+is managed by GitLab, resources for your projects are automatically created. See
+the [Access controls](add_remove_clusters.md#access-controls) section for
+details about the created resources.
 
-If you choose to manage your own cluster, project-specific resources will not be created
-automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.md), you will
-need to explicitly provide the `KUBE_NAMESPACE` [deployment variable](#deployment-variables)
-that will be used by your deployment jobs, otherwise a namespace will be created for you.
+If you choose to manage your own cluster, project-specific resources aren't created
+automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.md), you must
+explicitly provide the `KUBE_NAMESPACE` [deployment variable](#deployment-variables)
+for your deployment jobs to use; otherwise a namespace is created for you.
 
 #### Important notes
 
@@ -198,10 +198,10 @@ To clear the cache:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24580) in GitLab 11.8.
 
 You do not need to specify a base domain on cluster settings when using GitLab Serverless. The domain in that case
-will be specified as part of the Knative installation. See [Installing Applications](#installing-applications).
+is specified as part of the Knative installation. See [Installing Applications](#installing-applications).
 
-Specifying a base domain will automatically set `KUBE_INGRESS_BASE_DOMAIN` as an environment variable.
-If you are using [Auto DevOps](../../../topics/autodevops/index.md), this domain will be used for the different
+Specifying a base domain automatically sets `KUBE_INGRESS_BASE_DOMAIN` as an environment variable.
+If you are using [Auto DevOps](../../../topics/autodevops/index.md), this domain is used for the different
 stages. For example, Auto Review Apps and Auto Deploy.
 
 The domain should have a wildcard DNS configured to the Ingress IP address. After Ingress has been installed (see [Installing Applications](#installing-applications)),
@@ -224,7 +224,7 @@ Auto DevOps automatically detects, builds, tests, deploys, and monitors your
 applications.
 
 To make full use of Auto DevOps (Auto Deploy, Auto Review Apps, and
-Auto Monitoring) you will need the Kubernetes project integration enabled, but
+Auto Monitoring) the Kubernetes project integration must be enabled, but
 Kubernetes clusters can be used without Auto DevOps.
 
 [Read more about Auto DevOps](../../../topics/autodevops/index.md)
@@ -237,8 +237,8 @@ A Kubernetes cluster can be the destination for a deployment job. If
   [deployment variables](#deployment-variables) are made available to your job
   and configuration is not required. You can immediately begin interacting with
   the cluster from your jobs using tools such as `kubectl` or `helm`.
-- You don't use GitLab's cluster integration you can still deploy to your
-  cluster. However, you will need configure Kubernetes tools yourself
+- You don't use the GitLab cluster integration, you can still deploy to your
+  cluster. However, you must configure Kubernetes tools yourself
   using [environment variables](../../../ci/variables/README.md#custom-environment-variables)
   before you can interact with the cluster from your jobs.
 
@@ -257,14 +257,14 @@ The Kubernetes cluster integration exposes the following
 GitLab CI/CD build environment to deployment jobs, which are jobs that have
 [defined a target environment](../../../ci/environments/index.md#defining-environments).
 
-| Variable | Description |
-| -------- | ----------- |
-| `KUBE_URL` | Equal to the API URL. |
-| `KUBE_TOKEN` | The Kubernetes token of the [environment service account](add_remove_clusters.md#access-controls). Prior to GitLab 11.5, `KUBE_TOKEN` was the Kubernetes token of the main service account of the cluster integration. |
-| `KUBE_NAMESPACE` | The namespace associated with the project's deployment service account. In the format `<project_name>-<project_id>-<environment>`. For GitLab-managed clusters, a matching namespace is automatically created by GitLab in the cluster. If your cluster was created before GitLab 12.2, the default `KUBE_NAMESPACE` is set to `<project_name>-<project_id>`. |
-| `KUBE_CA_PEM_FILE` | Path to a file containing PEM data. Only present if a custom CA bundle was specified. |
-| `KUBE_CA_PEM` | (**deprecated**) Raw PEM data. Only if a custom CA bundle was specified. |
-| `KUBECONFIG` | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This configuration also embeds the same token defined in `KUBE_TOKEN` so you likely will only need this variable. This variable name is also automatically picked up by `kubectl` so you won't actually need to reference it explicitly if using `kubectl`. |
+| Variable                   | Description |
+|----------------------------|-------------|
+| `KUBE_URL`                 | Equal to the API URL. |
+| `KUBE_TOKEN`               | The Kubernetes token of the [environment service account](add_remove_clusters.md#access-controls). Prior to GitLab 11.5, `KUBE_TOKEN` was the Kubernetes token of the main service account of the cluster integration. |
+| `KUBE_NAMESPACE`           | The namespace associated with the project's deployment service account. In the format `<project_name>-<project_id>-<environment>`. For GitLab-managed clusters, a matching namespace is automatically created by GitLab in the cluster. If your cluster was created before GitLab 12.2, the default `KUBE_NAMESPACE` is set to `<project_name>-<project_id>`. |
+| `KUBE_CA_PEM_FILE`         | Path to a file containing PEM data. Only present if a custom CA bundle was specified. |
+| `KUBE_CA_PEM`              | (**deprecated**) Raw PEM data. Only if a custom CA bundle was specified. |
+| `KUBECONFIG`               | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This configuration also embeds the same token defined in `KUBE_TOKEN` so you likely need only this variable. This variable name is also automatically picked up by `kubectl` so you don't need to reference it explicitly if using `kubectl`. |
 | `KUBE_INGRESS_BASE_DOMAIN` | From GitLab 11.8, this variable can be used to set a domain per cluster. See [cluster domains](#base-domain) for more information. |
 
 ### Custom namespace
@@ -294,7 +294,7 @@ You can customize the deployment namespace in a few ways:
 When you customize the namespace, existing environments remain linked to their current
 namespaces until you [clear the cluster cache](#clearing-the-cluster-cache).
 
-CAUTION: **Warning:**
+WARNING:
 By default, anyone who can create a deployment job can access any CI variable within
 an environment's deployment job. This includes `KUBECONFIG`, which gives access to
 any secret available to the associated service account in your cluster.
@@ -316,9 +316,9 @@ the need to leave GitLab.
 
 [Read more about Canary Deployments](../canary_deployments.md)
 
-#### Deploy Boards **(PREMIUM)**
+#### Deploy Boards
 
-GitLab's Deploy Boards offer a consolidated view of the current health and
+GitLab Deploy Boards offer a consolidated view of the current health and
 status of each CI [environment](../../../ci/environments/index.md) running on Kubernetes,
 displaying the status of the pods in the deployment. Developers and other
 teammates can view the progress and status of a rollout, pod by pod, in the
@@ -362,7 +362,7 @@ the deployment job:
 - A namespace.
 - A service account.
 
-However, sometimes GitLab can not create them. In such instances, your job will fail with the message:
+However, sometimes GitLab can not create them. In such instances, your job can fail with the message:
 
 ```plaintext
 This job failed because the necessary resources were not successfully created.
@@ -376,9 +376,9 @@ Reasons for failure include:
   privileges required by GitLab.
 - Missing `KUBECONFIG` or `KUBE_TOKEN` variables. To be passed to your job, they must have a matching
   [`environment:name`](../../../ci/environments/index.md#defining-environments). If your job has no
-  `environment:name` set, it will not be passed the Kubernetes credentials.
+  `environment:name` set, the Kubernetes credentials are not passed to it.
 
-NOTE: **Note:**
+NOTE:
 Project-level clusters upgraded from GitLab 12.0 or older may be configured
 in a way that causes this error. Ensure you deselect the
 [GitLab-managed cluster](#gitlab-managed-clusters) option if you want to manage
@@ -396,6 +396,6 @@ Automatically detect and monitor Kubernetes metrics. Automatic monitoring of
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4701) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.6.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/208224) to GitLab Core in 13.2.
 
-When [Prometheus is deployed](#installing-applications), GitLab will automatically monitor the cluster's health. At the top of the cluster settings page, CPU and Memory utilization is displayed, along with the total amount available. Keeping an eye on cluster resources can be important, if the cluster runs out of memory pods may be shutdown or fail to start.
+When [Prometheus is deployed](#installing-applications), GitLab monitors the cluster's health. At the top of the cluster settings page, CPU and Memory utilization is displayed, along with the total amount available. Keeping an eye on cluster resources can be important, if the cluster runs out of memory pods may be shutdown or fail to start.
 
 ![Cluster Monitoring](img/k8s_cluster_monitoring.png)
diff --git a/doc/user/project/clusters/kubernetes_pod_logs.md b/doc/user/project/clusters/kubernetes_pod_logs.md
index 2e224208eb8..2523dc3e0a2 100644
--- a/doc/user/project/clusters/kubernetes_pod_logs.md
+++ b/doc/user/project/clusters/kubernetes_pod_logs.md
@@ -1,7 +1,7 @@
 ---
 stage: Monitor
 group: Health
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Kubernetes Logs
diff --git a/doc/user/project/clusters/runbooks/index.md b/doc/user/project/clusters/runbooks/index.md
index c1e4e821efd..332c1f35d89 100644
--- a/doc/user/project/clusters/runbooks/index.md
+++ b/doc/user/project/clusters/runbooks/index.md
@@ -1,7 +1,7 @@
 ---
 stage: Configure
 group: Configure
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Runbooks
@@ -25,7 +25,7 @@ pre-written code blocks or database queries against a given environment.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45912) in GitLab 11.4.
 
-The JupyterHub app offered via GitLab’s Kubernetes integration now ships
+The JupyterHub app offered via the GitLab Kubernetes integration now ships
 with Nurtch’s Rubix library, providing a simple way to create DevOps
 runbooks. A sample runbook is provided, showcasing common operations. While
 Rubix makes it simple to create common Kubernetes and AWS workflows, you can
@@ -37,11 +37,11 @@ for an overview of how this is accomplished in GitLab!
 
 ## Requirements
 
-To create an executable runbook, you will need:
+To create an executable runbook, you 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).
+  of the [GitLab integrations](../add_remove_clusters.md#create-new-cluster).
 - **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
@@ -71,7 +71,7 @@ the components outlined above and the pre-loaded demo runbook.
    ![install ingress](img/ingress-install.png)
 
 1. After Ingress has been installed successfully, click the **Install** button next
-   to the **JupyterHub** application. You will need the **Jupyter Hostname** provided
+   to the **JupyterHub** application. You need the **Jupyter Hostname** provided
    here in the next step.
 
    ![install JupyterHub](img/jupyterhub-install.png)
@@ -84,8 +84,8 @@ the components outlined above and the pre-loaded demo runbook.
 
    ![authorize Jupyter](img/authorize-jupyter.png)
 
-1. Click **Authorize**, and you will be redirected to the JupyterHub application.
-1. Click **Start My Server**, and the server will start in a few seconds.
+1. Click **Authorize**, and GitLab redirects you to the JupyterHub application.
+1. Click **Start My Server** to start the server in a few seconds.
 1. To configure the runbook's access to your GitLab project, you must enter your
    [GitLab Access Token](../../../profile/personal_access_tokens.md)
    and your Project ID in the **Setup** section of the demo runbook:
diff --git a/doc/user/project/clusters/securing.md b/doc/user/project/clusters/securing.md
index 2d74f67ba35..fa80bd6423b 100644
--- a/doc/user/project/clusters/securing.md
+++ b/doc/user/project/clusters/securing.md
@@ -1,7 +1,7 @@
 ---
 stage: Protect
 group: Container Security
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Securing your deployed applications
@@ -40,7 +40,7 @@ Minimum requirements (depending on the GitLab Manage Application you want to ins
 
 ### Understanding how GitLab Managed Apps are installed
 
-NOTE: **Note:**
+NOTE:
 These diagrams use the term _Kubernetes_ for simplicity. In practice, Sidekiq connects to a Helm
 command runner pod in the cluster.
 
diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md
index 0de0fd38336..a52d3400aa2 100644
--- a/doc/user/project/clusters/serverless/aws.md
+++ b/doc/user/project/clusters/serverless/aws.md
@@ -1,7 +1,7 @@
 ---
 stage: Configure
 group: Configure
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Deploying AWS Lambda function using GitLab CI/CD
@@ -29,7 +29,7 @@ Alternatively, you can quickly [create a new project with a template](../../../.
 
 ### Example
 
-In the following example, you will:
+This example shows you how to:
 
 1. Create a basic AWS Lambda Node.js function.
 1. Link the function to an API Gateway `GET` endpoint.
@@ -49,7 +49,7 @@ Lets take it step by step.
 
 #### Creating a Lambda handler function
 
-Your Lambda function will be the primary handler of requests. In this case we will create a very simple Node.js `hello` function:
+Your Lambda function is the primary handler of requests. In this case, create a very simple Node.js `hello` function:
 
 ```javascript
 'use strict';
@@ -72,13 +72,13 @@ Place this code in the file `src/handler.js`.
 
 `src` is the standard location for serverless functions, but is customizable should you desire that.
 
-In our case, `module.exports.hello` defines the `hello` handler that will be referenced later in the `serverless.yml`
+In our case, `module.exports.hello` defines the `hello` handler to reference later in the `serverless.yml`.
 
 You can learn more about the AWS Lambda Node.js function handler and all its various options here: <https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html>
 
 #### Creating a `serverless.yml` file
 
-In the root of your project, create a `serverless.yml` file that will contain configuration specifics for the Serverless Framework.
+In the root of your project, create a `serverless.yml` file containing configuration specifics for the Serverless Framework.
 
 Put the following code in the file:
 
@@ -97,9 +97,9 @@ functions:
 
 Our function contains a handler and a event.
 
-The handler definition will provision the Lambda function using the source code located `src/handler.hello`.
+The handler definition provisions the Lambda function using the source code located `src/handler.hello`.
 
-The `events` declaration will create a AWS API Gateway `GET` endpoint to receive external requests and hand them over to the Lambda function via a service integration.
+The `events` declaration creates an AWS API Gateway `GET` endpoint to receive external requests and hand them over to the Lambda function via a service integration.
 
 You can read more about the [available properties and additional configuration possibilities](https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml/) of the Serverless Framework.
 
@@ -141,10 +141,10 @@ For more information please see [Create a custom variable in the UI](../../../..
 
 #### Deploying your function
 
-`git push` the changes to your GitLab repository and the GitLab build pipeline will automatically deploy your function.
+`git push` the changes to your GitLab repository and the GitLab build pipeline deploys your function.
 
-In your GitLab deploy stage log, there will be output containing your AWS Lambda endpoint URL.
-The log line will look similar to this:
+Your GitLab deploy stage log contains output containing your AWS Lambda endpoint URL,
+with log lines similar to this:
 
 ```plaintext
 endpoints:
@@ -157,7 +157,7 @@ Running the following `curl` command should trigger your function.
 Your URL should be the one retrieved from the GitLab deploy stage log:
 
 ```shell
-curl https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello
+curl "https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello"
 ```
 
 That should output:
@@ -200,7 +200,7 @@ The `serverless-offline` plugin allows to run your code locally. To run your cod
 Running the following `curl` command should trigger your function.
 
 ```shell
-curl http://localhost:3000/hello
+curl "http://localhost:3000/hello"
 ```
 
 It should output:
@@ -227,9 +227,9 @@ provider:
 ```
 
 From there, you can reference them in your functions as well.
-Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
+Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables** to be picked up and deployed with your function.
 
-NOTE: **Note:**
+NOTE:
 Anyone with access to the AWS environment may be able to see the values of those
 variables persisted in the lambda definition.
 
@@ -309,7 +309,7 @@ GitLab allows developers to build and deploy serverless applications using the c
 
 ### Example
 
-In the following example, you will:
+This example shows you how to:
 
 - Install SAM CLI.
 - Create a sample SAM application including a Lambda function and API Gateway.
@@ -414,8 +414,8 @@ Let’s examine the configuration file more closely:
 
 ### Deploying your application
 
-Push changes to your GitLab repository and the GitLab build pipeline will automatically
-deploy your application. If your:
+Push changes to your GitLab repository and the GitLab build pipeline
+deploys your application. If your:
 
 - Build and deploy are successful, [test your deployed application](#testing-the-deployed-application).
 - Build fails, look at the build log to see why the build failed. Some common reasons
@@ -444,7 +444,7 @@ To test the application you deployed, please go to the build log and follow the
 1. Use curl to test the API. For example:
 
    ```shell
-   curl https://py4rg7qtlg.execute-api.us-east-1.amazonaws.com/Prod/hello/
+   curl "https://py4rg7qtlg.execute-api.us-east-1.amazonaws.com/Prod/hello/"
    ```
 
 Output should be:
@@ -496,7 +496,7 @@ listening on `localhost:3000`.
 Call the `hello` API by running:
 
 ```shell
-curl http://127.0.0.1:3000/hello
+curl "http://127.0.0.1:3000/hello"
 ```
 
 Output again should be:
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index 603c4bd73b1..fcbf85121b2 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -1,15 +1,15 @@
 ---
 stage: Configure
 group: Configure
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Serverless
 
 > Introduced in GitLab 11.5.
 
-CAUTION: **Caution:**
-Serverless is currently in [alpha](https://about.gitlab.com/handbook/product/#alpha).
+WARNING:
+Serverless is currently in [alpha](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha).
 
 ## Overview
 
@@ -39,9 +39,9 @@ With GitLab Serverless, you can deploy both functions-as-a-service (FaaS) and se
 
 ## Prerequisites
 
-To run Knative on GitLab, you will need:
+To run Knative on GitLab, you need:
 
-1. **Existing GitLab project:** You will need a GitLab project to associate all resources. The simplest way to get started:
+1. **Existing GitLab project:** You need a GitLab project to associate all resources. The simplest way to get started:
    - If you are planning on [deploying functions](#deploying-functions),
      clone the [functions example project](https://gitlab.com/knative-examples/functions) to get
      started.
@@ -49,21 +49,21 @@ To run Knative on GitLab, you will need:
      clone the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get
      started.
 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 simplest way to get started is to add a cluster using the GitLab [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. **GitLab Runner:** A runner is required to run the CI jobs that will deploy serverless
+1. **GitLab Runner:** A runner is required to run the CI jobs that deploy serverless
    applications or functions onto your cluster. You can install GitLab Runner
    onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information.
-1. **Domain Name:** Knative will provide its own load balancer using Istio. It will provide an
-   external IP address or hostname for all the applications served by Knative. You will be prompted to enter a
-   wildcard domain where your applications will be served. Configure your DNS server to use the
+1. **Domain Name:** Knative provides its own load balancer using Istio, and an
+   external IP address or hostname for all the applications served by Knative. Enter a
+   wildcard domain to serve your applications. Configure your DNS server to use the
    external IP address or hostname for that domain.
 1. **`.gitlab-ci.yml`:** GitLab uses [Kaniko](https://github.com/GoogleContainerTools/kaniko)
    to build the application. We also use [GitLab Knative tool](https://gitlab.com/gitlab-org/gitlabktl)
    CLI to simplify the deployment of services and functions to Knative.
 1. **`serverless.yml`** (for [functions only](#deploying-functions)): When using serverless to deploy functions, the `serverless.yml` file
-   will contain the information for all the functions being hosted in the repository as well as a reference to the
-   runtime being used.
+   contains the information for all the functions being hosted in the repository as well as a reference
+   to the runtime being used.
 1. **`Dockerfile`** (for [applications only](#deploying-serverless-applications)): Knative requires a
    `Dockerfile` in order to build your applications. It should be included at the root of your
    project's repository and expose port `8080`. `Dockerfile` is not require if you plan to build serverless functions
@@ -73,7 +73,7 @@ To run Knative on GitLab, you will need:
 1. **Logging** (optional): Configuring logging allows you to view and search request logs for your serverless function/application.
    See [Configuring logging](#configuring-logging) for more information.
 
-## Installing Knative via GitLab's Kubernetes integration
+## Installing Knative via the GitLab Kubernetes integration
 
 The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB
 memory. **RBAC must be enabled.**
@@ -87,12 +87,12 @@ memory. **RBAC must be enabled.**
 1. After the Knative installation has finished, you can wait for the IP address or hostname to be displayed in the
    **Knative Endpoint** field or [retrieve the Istio Ingress Endpoint manually](../../../clusters/applications.md#determining-the-external-endpoint-manually).
 
-   NOTE: **Note:**
+   NOTE:
    Running `kubectl` commands on your cluster requires setting up access to the cluster first.
    For clusters created on GKE, see [GKE Cluster Access](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl),
    for other platforms [Install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
 
-1. The Ingress is now available at this address and will route incoming requests to the proper service based on the DNS
+1. The Ingress is now available at this address and routes incoming requests to the proper service based on the DNS
    name in the request. To support this, a wildcard DNS record should be created for the desired domain name. For example,
    if your Knative base domain is `knative.info` then you need to create an A record or CNAME record with domain `*.knative.info`
    pointing the IP address or hostname of the Ingress.
@@ -107,7 +107,7 @@ on a given project, but not both. The current implementation makes use of a
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0.
 
-The _invocations_ monitoring feature of GitLab serverless won't work when
+The _invocations_ monitoring feature of GitLab serverless is unavailable when
 adding an existing installation of Knative.
 
 It's also possible to use GitLab Serverless with an existing Kubernetes cluster
@@ -121,9 +121,9 @@ which already has Knative installed. You must do the following:
    - For a non-GitLab managed cluster, ensure that the service account for the token
      provided can manage resources in the `serving.knative.dev` API group.
    - For a GitLab managed cluster, if you added the cluster in [GitLab 12.1 or later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30235),
-     then GitLab will already have the required access and you can proceed to the next step.
+     then GitLab already has the required access and you can proceed to the next step.
 
-     Otherwise, you need to manually grant GitLab's service account the ability to manage
+     Otherwise, you need to manually grant the GitLab service account the ability to manage
      resources in the `serving.knative.dev` API group. Since every GitLab service account
      has the `edit` cluster role, the simplest way to do this is with an
      [aggregated ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)
@@ -234,12 +234,12 @@ Follow these steps to deploy a function using the Node.js runtime to your
 Knative instance (you can skip these steps if you've cloned the example
 project):
 
-1. Create a directory that will house the function. In this example we will
+1. Create a directory to house the function. In this example we will
    create a directory called `echo` at the root of the project.
 
-1. Create the file that will contain the function code. In this example, our file is called `echo.js` and is located inside the `echo` directory. If your project is:
+1. Create the file to contain the function code. In this example, our file is called `echo.js` and is located inside the `echo` directory. If your project is:
    - Public, continue to the next step.
-   - Private, you will need to [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope.
+   - Private, you must [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope.
 
 1. `.gitlab-ci.yml`: this defines a pipeline used to deploy your functions.
    It must be included at the root of your repository:
@@ -304,7 +304,7 @@ Explanation of the fields used above:
 
 | Parameter | Description |
 |-----------|-------------|
-| `service` | Name for the Knative service which will serve the function. |
+| `service` | Name for the Knative service which serves the function. |
 | `description` | A short description of the `service`. |
 
 ### `provider`
@@ -349,9 +349,9 @@ The optional `runtime` parameter can refer to one of the following runtime alias
 | `openfaas/classic/ruby` | OpenFaaS |
 
 After the `gitlab-ci.yml` template has been added and the `serverless.yml` file
-has been created, pushing a commit to your project will result in a CI pipeline
-being executed which will deploy each function as a Knative service. Once the
-deploy stage has finished, additional details for the function will appear
+has been created, pushing a commit to your project results in a CI pipeline
+being executed which deploys each function as a Knative service. After the
+deploy stage has finished, additional details for the function display
 under **Operations > Serverless**.
 
 ![serverless page](img/serverless-page.png)
@@ -376,7 +376,7 @@ The sample function can now be triggered from any HTTP client using a simple `PO
      --header "Content-Type: application/json" \
      --request POST \
      --data '{"GitLab":"FaaS"}' \
-     http://functions-echo.functions-1.functions.example.com/
+     "http://functions-echo.functions-1.functions.example.com/"
      ```
 
   1. Using a web-based tool (such as Postman or Restlet)
@@ -443,14 +443,13 @@ To run a function locally:
 1. Invoke your function:
 
    ```shell
-   curl http://localhost:8080
+   curl "http://localhost:8080"
    ```
 
 ## Deploying Serverless applications
 
 > Introduced in GitLab 11.5.
 
-12345678901234567890123456789012345678901234567890123456789012345678901234567890
 Serverless applications are an alternative to [serverless functions](#deploying-functions).
 They're useful in scenarios where an existing runtime does not meet the needs of
 an application, such as one written in a language that has no runtime available.
@@ -482,7 +481,7 @@ A `serverless.yml` file is not required when deploying serverless applications.
 
 ### Deploy the application with Knative
 
-With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to
+With all the pieces in place, the next time a CI pipeline runs the Knative application deploys. Navigate to
 **CI/CD > Pipelines** and click the most recent pipeline.
 
 ### Function details
@@ -498,13 +497,13 @@ rows to bring up the function details page.
 
 ![function_details](img/function-details-loaded.png)
 
-The pod count will give you the number of pods running the serverless function instances on a given cluster.
+The pod count gives you the number of pods running the serverless function instances on a given cluster.
 
 For the Knative function invocations to appear,
 [Prometheus must be installed](../index.md#installing-applications).
 
 Once Prometheus is installed, a message may appear indicating that the metrics data _is
-loading or is not available at this time._  It will appear upon the first access of the
+loading or is not available at this time._  It appears upon the first access of the
 page, but should go away after a few seconds. If the message does not disappear, then it
 is possible that GitLab is unable to connect to the Prometheus instance running on the
 cluster.
@@ -558,7 +557,7 @@ Or:
 
 ## Enabling TLS for Knative services
 
-By default, a GitLab serverless deployment will be served over `http`. To serve
+By default, a GitLab serverless deployment is served over `http`. To serve
 over `https`, you must manually obtain and install TLS certificates.
 
 12345678901234567890123456789012345678901234567890123456789012345678901234567890
@@ -647,7 +646,7 @@ or with other versions of Python.
    ```
 
 1. Create certificate and private key files. Using the contents of the files
-   returned by Certbot, we'll create two files in order to create the
+   returned by Certbot, create two files in order to create the
    Kubernetes secret:
 
    Run the following command to see the contents of `fullchain.pem`:
@@ -767,7 +766,7 @@ or with other versions of Python.
 1. Create a Kubernetes secret to hold your TLS certificate, `cert.pem`, and
    the private key `cert.pk`:
 
-   NOTE: **Note:**
+   NOTE:
    Running `kubectl` commands on your cluster requires setting up access to the cluster first.
    For clusters created on GKE, see
    [GKE Cluster Access](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl).
@@ -828,8 +827,8 @@ or with other versions of Python.
    ```
 
    After your changes are running on your Knative cluster, you can begin using the HTTPS protocol for secure access your deployed Knative services.
-   In the event a mistake is made during this process and you need to update the cert, you will need to edit the gateway `knative-ingress-gateway`
-   to switch back to `PASSTHROUGH` mode. Once corrections are made, edit the file again so the gateway will use the new certificates.
+   In the event a mistake is made during this process and you need to update the cert, you must edit the gateway `knative-ingress-gateway`
+   to switch back to `PASSTHROUGH` mode. Once corrections are made, edit the file again so the gateway uses the new certificates.
 
 ## Using an older version of `gitlabktl`