Fix order of headings (#1465)

* Fix 'title out of sequence' errors

fixed Dockershim.md

* fixed deprecated-features.md

* fixed install-and-configure-kubectl.md

* fixed rancher-is-no-longer-needed.md

* fixed security.md

* fixed technical-items.md + spacing, duplicate section, admonitions

* fixed telemetry.md

* fixed upgrades.md

* fixed upgrade-kubernetes-without-upgrading-rancher.md

* fixed air-gapped-upgrades.md

* fixed dockershim.md

* fixed docker-install-commands.md

* fixed install-kubernetes.md

* fixed infrastructure-private-registry.md

* fixed install-rancher-ha

* fixed manage-namespaces and tune-etcd-for-large-installs.md

* fixed cis-scans/configuration-reference.md

* fixed custom-benchmark.md

* fixed supportconfig.md

* fixed harvester/overview.md

* fixed logging-architecture.md

* fixed logging-helm-chart-options.md + rm'd unnecessary annotation title

* fixed taints-and-tolerances.md

* fixed longhorn/overview.md

* fixed neuvector/overview.md

* fixed monitoring-and-alerting

* fixed rancher-cli.md

* fixed cluster-configuration.md

* fixed monitoring-v2-configuration/examples.md

* fixed servicemonitors-and-podmonitors.md

* fixed other-troubleshooting-tips/dns.md

versioned_docs/version-2.7/integrations-in-rancher/cis-scans/configuration-reference.md

@@ -14,7 +14,7 @@ To configure the custom resources, go to the **Cluster Dashboard** To configure
 1. On the **Clusters** page, go to the cluster where you want to configure CIS scans and click **Explore**.
 1. In the left navigation bar, click **CIS Benchmark**.
 
-### Scans
+## Scans
 
 A scan is created to trigger a CIS scan on the cluster based on the defined profile. A report is created after the scan is completed.
 
@@ -31,7 +31,7 @@ spec:
   scanProfileName: rke-profile-hardened
 ```
 
-### Profiles
+## Profiles
 
 A profile contains the configuration for the CIS scan, which includes the benchmark version to use and any specific tests to skip in that benchmark.
 
@@ -66,7 +66,7 @@ spec:
     - "1.1.21"
 ```
 
-### Benchmark Versions
+## Benchmark Versions
 
 A benchmark version is the name of benchmark to run using `kube-bench`, as well as the valid configuration parameters for that benchmark.
 

versioned_docs/version-2.7/integrations-in-rancher/cis-scans/custom-benchmark.md

@@ -17,7 +17,7 @@ When a cluster scan is run, you need to select a Profile which points to a speci
 
 Follow all the steps below to add a custom Benchmark Version and run a scan using it.
 
-### 1. Prepare the Custom Benchmark Version ConfigMap
+## 1. Prepare the Custom Benchmark Version ConfigMap
 
 To create a custom benchmark version, first you need to create a ConfigMap containing the benchmark version's config files and upload it to your Kubernetes cluster where you want to run the scan.
 
@@ -42,7 +42,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom
     kubectl create configmap -n <namespace> foo --from-file=<path to directory foo>
     ```
 
-### 2. Add a Custom Benchmark Version to a Cluster
+## 2. Add a Custom Benchmark Version to a Cluster
 
 1. In the upper left corner, click **☰ > Cluster Management**.
 1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
@@ -54,7 +54,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom
 1. Add the minimum and maximum Kubernetes version limits applicable, if any.
 1. Click **Create**.
 
-### 3. Create a New Profile for the Custom Benchmark Version
+## 3. Create a New Profile for the Custom Benchmark Version
 
 To run a scan using your custom benchmark version, you need to add a new Profile pointing to this benchmark version.
 
@@ -66,7 +66,7 @@ To run a scan using your custom benchmark version, you need to add a new Profile
 1. Choose the Benchmark Version from the dropdown.
 1. Click **Create**.
 
-### 4. Run a Scan Using the Custom Benchmark Version
+## 4. Run a Scan Using the Custom Benchmark Version
 
 Once the Profile pointing to your custom benchmark version `foo` has been created, you can create a new Scan to run the custom test configs in the Benchmark Version.
 

versioned_docs/version-2.7/integrations-in-rancher/cloud-marketplace/supportconfig.md

@@ -1,5 +1,5 @@
 ---
-title: Supportconfig bundle
+title: Supportconfig Bundle
 ---
 
 <head>
@@ -12,7 +12,7 @@ These bundles can be created through Rancher or through direct access to the clu
 
 > **Note:** Only admin users can generate/download supportconfig bundles, regardless of method.
 
-### Accessing through Rancher
+## Accessing Through Rancher
 
 First, click on the hamburger menu. Then click the `Get Support` button.
 
@@ -24,7 +24,7 @@ In the next page, click on the `Generate Support Config` button.
 
 ![Get Support](/img/generate-support-config.png)
 
-### Accessing without rancher
+## Accessing Without Rancher
 
 First, generate a kubeconfig for the cluster that Rancher is installed on.
 

versioned_docs/version-2.7/integrations-in-rancher/logging/logging-architecture.md

@@ -10,7 +10,7 @@ This section summarizes the architecture of the Rancher logging application.
 
 For more details about how the Logging operator works, see the [official documentation.](https://kube-logging.github.io/docs/#architecture)
 
-### How the Logging Operator Works
+## How the Logging Operator Works
 
 The Logging operator automates the deployment and configuration of a Kubernetes logging pipeline. It deploys and configures a Fluent Bit DaemonSet on every node to collect container and application logs from the node file system.
 

versioned_docs/version-2.7/integrations-in-rancher/logging/logging-helm-chart-options.md

@@ -6,7 +6,7 @@ title: rancher-logging Helm Chart Options
   <link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/logging/logging-helm-chart-options"/>
 </head>
 
-### Enable/Disable Windows Node Logging
+## Enable/Disable Windows Node Logging
 
 You can enable or disable Windows node logging by setting `global.cattle.windows.enabled` to either `true` or `false` in the `values.yaml`.
 
@@ -21,7 +21,7 @@ Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists whe
 
 :::
 
-### Working with a Custom Docker Root Directory
+## Working with a Custom Docker Root Directory
 
 If using a custom Docker root directory, you can set `global.dockerRootDirectory` in `values.yaml`.
 
@@ -31,11 +31,11 @@ Note that this only affects Linux nodes.
 
 If there are any Windows nodes in the cluster, the change will not be applicable to those nodes.
 
-### Adding NodeSelector Settings and Tolerations for Custom Taints
+## Adding NodeSelector Settings and Tolerations for Custom Taints
 
 You can add your own `nodeSelector` settings and add `tolerations` for additional taints by editing the logging Helm chart values. For details, see [this page.](taints-and-tolerations.md)
 
-### Enabling the Logging Application to Work with SELinux
+## Enabling the Logging Application to Work with SELinux
 
 :::note Requirements:
 
@@ -49,7 +49,7 @@ To use Logging v2 with SELinux, we recommend installing the `rancher-selinux` RP
 
 Then, when installing the logging application, configure the chart to be SELinux aware by changing `global.seLinux.enabled` to `true` in the `values.yaml`.
 
-### Additional Logging Sources
+## Additional Logging Sources
 
 By default, Rancher collects logs for [control plane components](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) and [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for all cluster types.
 
@@ -72,7 +72,7 @@ When enabled, Rancher collects all additional node and control plane logs the pr
 
 If you're already using a cloud provider's own logging solution such as AWS CloudWatch or Google Cloud operations suite (formerly Stackdriver), it is not necessary to enable this option as the native solution will have unrestricted access to all logs.
 
-### Systemd Configuration
+## Systemd Configuration
 
 In Rancher logging, `SystemdLogPath` must be configured for K3s and RKE2 Kubernetes distributions.
 

versioned_docs/version-2.7/integrations-in-rancher/logging/taints-and-tolerations.md

@@ -20,7 +20,7 @@ Both provide choice for the what node(s) the pod will run on.
 - [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints)
 
 
-### Default Implementation in Rancher's Logging Stack
+## Default Implementation in Rancher's Logging Stack
 
 By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
 The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
@@ -47,7 +47,7 @@ In the above example, we ensure that our pod only runs on Linux nodes, and we ad
 
 You can do the same with Rancher's existing taints, or with your own custom ones.
 
-### Adding NodeSelector Settings and Tolerations for Custom Taints
+## Adding NodeSelector Settings and Tolerations for Custom Taints
 
 If you would like to add your own `nodeSelector` settings, or if you would like to add `tolerations` for additional taints, you can pass the following to the chart's values.
 

versioned_docs/version-2.7/integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md

@@ -15,7 +15,7 @@ For information on V1 monitoring and alerting, available in Rancher v2.2 up to v
 
 Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
 
-### Features
+## Features
 
 Prometheus lets you view metrics from your Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or Grafana, which is an analytics viewing platform deployed along with Prometheus.
 
@@ -97,7 +97,6 @@ To be able to fully deploy Monitoring V2 for Windows, all of your Windows hosts
 
 For more details on how to upgrade wins on existing Windows hosts, see [Windows cluster support for Monitoring V2.](windows-support.md).
 
-
 ## Known Issues
 
 There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more than the allotted default memory. If you enable monitoring on a K3s cluster, set `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.