Adjust heading levels

doc/user/project/clusters/index.md

@@ -76,12 +76,66 @@ Simply add another cluster, like you did the first time, and make sure to
 [set an environment scope](#setting-the-environment-scope-premium) that will
 differentiate the new cluster with the rest.
 
-### Cluster configuration
+#### Setting the environment scope **(PREMIUM)**
+
+When adding more than one Kubernetes cluster to your project, you need to differentiate
+them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments/index.md) similar to how the
+[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.
+
+For example, let's say the following Kubernetes clusters exist in a project:
+
+| Cluster     | Environment scope |
+| ----------- | ----------------- |
+| Development | `*`               |
+| Production  | `production`      |
+
+And the following environments are set in
+[`.gitlab-ci.yml`](../../../ci/yaml/README.md):
+
+```yaml
+stages:
+- test
+- deploy
+
+test:
+  stage: test
+  script: sh test
+
+deploy to staging:
+  stage: deploy
+  script: make deploy
+  environment:
+    name: staging
+    url: https://staging.example.com/
+
+deploy to production:
+  stage: deploy
+  script: make deploy
+  environment:
+    name: production
+    url: https://example.com/
+```
+
+The result will then be:
+
+- The Development cluster details will be available in the `deploy to staging`
+  job.
+- The production cluster details will be available in the `deploy to production`
+  job.
+- No cluster details will be available in the `test` job because it doesn't
+  define any environment.
+
+## Configuring your Kubernetes cluster
 
 After [adding a Kubernetes cluster](add_remove_clusters.md) to GitLab, read this section that covers
 important considerations for configuring Kubernetes clusters with GitLab.
 
-#### Security implications
+### Security implications
 
 CAUTION: **Important:**
 The whole cluster security is based on a model where [developers](../../permissions.md)
@@ -92,7 +146,7 @@ functionalities needed to successfully build and deploy a containerized
 application. Bear in mind that the same credentials are used for all the
 applications running on the cluster.
 
-#### GitLab-managed clusters
+### GitLab-managed clusters
 
 > - [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.
@@ -107,7 +161,7 @@ automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.m
 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.
 
-##### Important notes
+#### Important notes
 
 Note the following with GitLab and clusters:
 
@@ -118,7 +172,7 @@ Note the following with GitLab and clusters:
   namespaces and service accounts, can cause unexpected errors. If this occurs, try
   [clearing the cluster cache](#clearing-the-cluster-cache).
 
-##### Clearing the cluster cache
+#### Clearing the cluster cache
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31759) in GitLab 12.6.
 
@@ -133,7 +187,7 @@ To clear the cache:
 1. Expand the **Advanced settings** section.
 1. Click **Clear cluster cache**.
 
-#### Base domain
+### Base domain
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24580) in GitLab 11.8.
 
@@ -151,60 +205,6 @@ you can either:
 - Create an `A` record that points to the Ingress IP address with your domain provider.
 - Enter a wildcard DNS address using a service such as nip.io or xip.io. For example, `192.168.1.1.xip.io`.
 
-#### Setting the environment scope **(PREMIUM)**
-
-When adding more than one Kubernetes cluster to your project, you need to differentiate
-them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments/index.md) similar to how the
-[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.
-
-For example, let's say the following Kubernetes clusters exist in a project:
-
-| Cluster     | Environment scope |
-| ----------- | ----------------- |
-| Development | `*`               |
-| Production  | `production`      |
-
-And the following environments are set in
-[`.gitlab-ci.yml`](../../../ci/yaml/README.md):
-
-```yaml
-stages:
-- test
-- deploy
-
-test:
-  stage: test
-  script: sh test
-
-deploy to staging:
-  stage: deploy
-  script: make deploy
-  environment:
-    name: staging
-    url: https://staging.example.com/
-
-deploy to production:
-  stage: deploy
-  script: make deploy
-  environment:
-    name: production
-    url: https://example.com/
-```
-
-The result will then be:
-
-- The Development cluster details will be available in the `deploy to staging`
-  job.
-- The production cluster details will be available in the `deploy to production`
-  job.
-- No cluster details will be available in the `test` job because it doesn't
-  define any environment.
-
 ## Installing applications
 
 GitLab can install and manage some applications like Helm, GitLab Runner, Ingress,