Merge pull request #225 from btat/clean-frontmatter

Remove unsupported front matter fields
2026-09-25 20:48:11 +00:00 · 2022-09-27 13:41:59 -07:00
parent 408c4c3998 c390289797
commit 1c0d662469
1553 changed files with 871 additions and 4500 deletions
@@ -1,7 +1,5 @@
 ---
 title: Backup and Restore for Rancher Installed with Docker
-shortTitle: Docker Installs
-weight: 10
 ---

 - [Backups](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
@@ -1,6 +1,5 @@
 ---
 title: RKE Cluster Configuration
-weight: 2300
 ---

 This page has moved [here.](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)
@@ -1,6 +1,5 @@
 ---
 title: Contributing to Rancher
-weight: 700
 ---

 This section explains the repositories used for Rancher, how to build the repositories, and what information to include when you file an issue.
@@ -88,7 +87,7 @@ Please remove any sensitive data as it will be publicly viewable.
        - Kubernetes install using `kubectl`

        :::note
-        
+
        Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if Rancher is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI.

        :::
@@ -109,7 +108,7 @@ Please remove any sensitive data as it will be publicly viewable.
        - Kubernetes Install with RKE Add-On

        :::note
-        
+
        Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI.

        :::
@@ -1,6 +1,5 @@
 ---
 title: Explanations
-weight: 400
 ---

 **Explanatory docs** are concerned primarily with providing theoretical knowledge for the "why" behind a task or a topic. Explanations are "understanding-oriented" in nature and will clarify a topic in order to broaden the user's knowledge. In this section, users can find additional context and background, alternatives or even opinions on topics, and often historical reasons, constraints, and insights into why a process works the way that it does.
@@ -1,6 +1,5 @@
 ---
 title: Configuration
-weight: 3
 ---

 This configuration reference is intended to help you manage the custom resources created by the `rancher-cis-benchmark` application. These resources are used for performing CIS scans on a cluster, skipping tests, setting the test profile that will be used during a scan, and other customization.
@@ -1,16 +1,15 @@
 ---
 title: Creating a Custom Benchmark Version for Running a Cluster Scan
-weight: 4
 ---

 Each Benchmark Version defines a set of test configuration files that define the CIS tests to be run by the <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> tool.
 The `rancher-cis-benchmark` application installs a few default Benchmark Versions which are listed under CIS Benchmark application menu.
- 
+
 But there could be some Kubernetes cluster setups that require custom configurations of the Benchmark tests. For example, the path to the Kubernetes config files or certs might be different than the standard location where the upstream CIS Benchmarks look for them.

 It is now possible to create a custom Benchmark Version for running a cluster scan using the `rancher-cis-benchmark` application.

-When a cluster scan is run, you need to select a Profile which points to a specific Benchmark Version. 
+When a cluster scan is run, you need to select a Profile which points to a specific Benchmark Version.

 Follow all the steps below to add a custom Benchmark Version and run a scan using it.

@@ -21,7 +20,7 @@ To create a custom benchmark version, first you need to create a ConfigMap conta
 To prepare a custom benchmark version ConfigMap, suppose we want to add a custom Benchmark Version named `foo`.

 1. Create a directory named `foo` and inside this directory, place all the config YAML files that the <a href="https://github.com/aquasecurity/kube-bench" target="_blank">kube-bench</a> tool looks for. For example, here are the config YAML files for a Generic CIS 1.5 Benchmark Version https://github.com/aquasecurity/kube-bench/tree/master/cfg/cis-1.5
-1. Place the complete `config.yaml` file, which includes all the components that should be tested. 
+1. Place the complete `config.yaml` file, which includes all the components that should be tested.
 1. Add the Benchmark version name to the `target_mapping` section of the `config.yaml`:

    ```yaml
@@ -1,7 +1,5 @@
 ---
 title: Roles-based Access Control
-shortTitle: RBAC
-weight: 3
 ---

 This section describes the permissions required to use the rancher-cis-benchmark App.
@@ -13,7 +11,7 @@ However, the `rancher-cis-benchmark` chart installs these two default `ClusterRo
 - cis-admin
 - cis-view

-In Rancher, only cluster owners and global administrators have `cis-admin` access by default. 
+In Rancher, only cluster owners and global administrators have `cis-admin` access by default.

 Note: If you were using the `cis-edit` role added in Rancher v2.5 setup, it has now been removed since
 Rancher v2.5.2 because it essentially is same as `cis-admin`. If you happen to create any clusterrolebindings
@@ -1,6 +1,5 @@
 ---
 title: Skipped and Not Applicable Tests
-weight: 3
 ---

 This section lists the tests that are skipped in the permissive test profile for RKE.
@@ -1,6 +1,5 @@
 ---
 title: Prerequisites
-weight: 1
 ---

 ### 1. Setting Up License Manager and Purchasing Support
@@ -1,6 +1,5 @@
 ---
 title: Common Issues
-weight: 4
 ---

 **After installing the adapter, a banner message appears in Rancher that says "AWS Marketplace Adapter: Unable to run the adapter, please check the adapter logs"**
@@ -1,6 +1,5 @@
 ---
 title: Installing the Adapter
-weight: 2
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: Uninstalling The Adapter
-weight: 3
 ---

 ### 1. Uninstall the adapter chart using helm.
@@ -1,6 +1,5 @@
 ---
 title: Supportconfig bundle
-weight: 100
 ---

 After installing the CSP adapter, you will have the ability to generate a supportconfig bundle. This bundle is a tar file which can be used to quickly provide information to support.
@@ -1,6 +1,5 @@
 ---
 title: Architecture
-weight: 1
 ---

 Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, or Kustomize or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy everything in the cluster. This gives you a high degree of control, consistency, and auditability. Fleet focuses not only on the ability to scale, but to give one a high degree of control and visibility to exactly what is installed on the cluster.
@@ -1,6 +1,5 @@
 ---
 title: Using Fleet Behind a Proxy
-weight: 3
 ---

 In this section, you'll learn how to enable Fleet in a setup that has a Rancher server with a public IP a Kubernetes cluster that has no public IP, but is configured to use a proxy.
@@ -1,6 +1,5 @@
 ---
 title: Windows Support
-weight: 2
 ---


@@ -1,6 +1,5 @@
 ---
 title: Harvester Integration
-weight: 10
 ---

 Introduced in Rancher v2.6.1, [Harvester](https://docs.harvesterhci.io/) is an open-source hyper-converged infrastructure (HCI) software built on Kubernetes. Harvester installs on bare metal servers and provides integrated virtualization and distributed storage capabilities. Although Harvester operates using Kubernetes, it does not require users to know Kubernetes concepts, making it a more user-friendly application.
@@ -15,15 +14,15 @@ Harvester is GA. Please refer to the [Harvester release notes](https://github.co

 The Harvester feature flag is used to manage access to the Virtualization Management (VM) page in Rancher where users can navigate directly to Harvester clusters and access the Harvester UI. The Harvester feature flag is enabled by default. Click [here](../../pages-for-subheaders/enable-experimental-features.md) for more information on feature flags in Rancher.

-To navigate to the Harvester cluster, click **☰ > Virtualization Management**. From Harvester Clusters page, click one of the clusters listed to go to the single Harvester cluster view. 
+To navigate to the Harvester cluster, click **☰ > Virtualization Management**. From Harvester Clusters page, click one of the clusters listed to go to the single Harvester cluster view.

 * If the Harvester feature flag is enabled, Harvester clusters will be filtered out from any pages or apps (such as Fleet and the multi-cluster app) that list Kubernetes clusters.

 * If the Harvester feature flag is disabled, and a Harvester cluster is imported, the Harvester cluster will be shown in the Rancher cluster list in the Cluster Management page. Harvester clusters will only be shown on the cluster list when the feature flag is off.

-* With the Harvester integration, Harvester clusters can now be imported into Rancher as a cluster type `Harvester`. 
+* With the Harvester integration, Harvester clusters can now be imported into Rancher as a cluster type `Harvester`.

-* Users may import a Harvester cluster only on the Virtualization Management page. Importing a cluster on the Cluster Management page is not supported, and a warning will advise you to return to the VM page to do so. 
+* Users may import a Harvester cluster only on the Virtualization Management page. Importing a cluster on the Cluster Management page is not supported, and a warning will advise you to return to the VM page to do so.

 ### Harvester Node Driver

@@ -1,6 +1,5 @@
 ---
 title: Additional Steps for Installing Istio on an RKE2 Cluster
-weight: 3
 ---

 When installing or upgrading the Istio Helm chart through **Apps & Marketplace,**
@@ -1,16 +1,15 @@
 ---
 title: Enable Istio with Pod Security Policies
-weight: 1
 ---

-If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin. 
+If you have restrictive Pod Security Policies enabled, then Istio may not be able to function correctly, because it needs certain permissions in order to install itself and manage pod infrastructure. In this section, we will configure a cluster with PSPs enabled for an Istio install, and also set up the Istio CNI plugin.

 The Istio CNI plugin removes the need for each application pod to have a privileged `NET_ADMIN` container. For further information, see the [Istio CNI Plugin docs](https://istio.io/docs/setup/additional-setup/cni). Please note that the [Istio CNI Plugin is in alpha](https://istio.io/about/feature-stages/).

 :::note Prerequisites:

 - The cluster must be an RKE Kubernetes cluster.
- The cluster must have been created with a default PodSecurityPolicy. 
+- The cluster must have been created with a default PodSecurityPolicy.

 To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.

@@ -1,6 +1,5 @@
 ---
 title: Additional Steps for Project Network Isolation
-weight: 4
 ---

 In clusters where:
@@ -1,11 +1,10 @@
 ---
 title: Selectors and Scrape Configs
-weight: 2
 ---

 The Monitoring app sets `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`, which enables monitoring across all namespaces by default.

-This ensures you can view traffic, metrics and graphs for resources deployed in a namespace with `istio-injection=enabled` label. 
+This ensures you can view traffic, metrics and graphs for resources deployed in a namespace with `istio-injection=enabled` label.

 If you would like to limit Prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources.

@@ -21,20 +20,20 @@ To limit monitoring to specific namespaces, you will edit the `ignoreNamespaceSe

 ### Enabling Prometheus to Detect Resources in Other Namespaces

-There are two different ways to enable Prometheus to detect resources in other namespaces when `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`: 
+There are two different ways to enable Prometheus to detect resources in other namespaces when `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`:

 - **Monitoring specific namespaces:** Add a Service Monitor or Pod Monitor in the namespace with the targets you want to scrape.
 - **Monitoring across namespaces:** Add an `additionalScrapeConfig` to your rancher-monitoring instance to scrape all targets in all namespaces.

 ### Monitoring Specific Namespaces: Create a Service Monitor or Pod Monitor

-This option allows you to define which specific services or pods you would like monitored in a specific namespace. 
+This option allows you to define which specific services or pods you would like monitored in a specific namespace.

 The usability tradeoff is that you have to create the service monitor or pod monitor per namespace since you cannot monitor across namespaces.

 :::note Prerequisite:

-Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example ServiceMonitor is provided below. 
+Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example ServiceMonitor is provided below.

 :::

@@ -42,10 +41,10 @@ Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example Service
 1. Go to the cluster that you created and click **Explore**.
 1. In the top navigation bar, open the kubectl shell.
 1. If the ServiceMonitor or PodMonitor file is stored locally in your cluster, in `kubectl create -f <name of service/pod monitor file>.yaml`.
-1. If the ServiceMonitor or PodMonitor is not stored locally, run `cat<< EOF | kubectl apply -f -`, paste the file contents into the terminal, then run `EOF` to complete the command. 
+1. If the ServiceMonitor or PodMonitor is not stored locally, run `cat<< EOF | kubectl apply -f -`, paste the file contents into the terminal, then run `EOF` to complete the command.
 1. Run `kubectl label namespace <your namespace> istio-injection=enabled` to enable the envoy sidecar injection.

-**Result:**  `<your namespace>` can be scraped by prometheus. 
+**Result:**  `<your namespace>` can be scraped by prometheus.

 <figcaption>Example Service Monitor for Istio Proxies</figcaption>

@@ -84,11 +83,11 @@ spec:

 ### Monitoring across namespaces: Set ignoreNamespaceSelectors to False

-This enables monitoring across namespaces by giving Prometheus additional scrape configurations. 
+This enables monitoring across namespaces by giving Prometheus additional scrape configurations.

-The usability tradeoff is that  all of Prometheus' `additionalScrapeConfigs` are maintained in a single Secret. This could make upgrading difficult if monitoring is already deployed with additionalScrapeConfigs before installing Istio. 
+The usability tradeoff is that  all of Prometheus' `additionalScrapeConfigs` are maintained in a single Secret. This could make upgrading difficult if monitoring is already deployed with additionalScrapeConfigs before installing Istio.

-1. When installing or upgrading the Monitoring Helm chart, edit the values.yml and set the `prometheus.prometheusSpec.additionalScrapeConfigs` array to the **Additional Scrape Config** provided below. 
+1. When installing or upgrading the Monitoring Helm chart, edit the values.yml and set the `prometheus.prometheusSpec.additionalScrapeConfigs` array to the **Additional Scrape Config** provided below.
 1. Complete the install or upgrade.

 **Result:** All namespaces with the `istio-injection=enabled` label will be scraped by prometheus.
@@ -118,4 +117,4 @@ The usability tradeoff is that  all of Prometheus' `additionalScrapeConfigs` are
    - source_labels: [__meta_kubernetes_pod_name]
      action: replace
      target_label: pod_name
-``` 
+```
@@ -1,6 +1,5 @@
 ---
 title: CPU and Memory Allocations
-weight: 1
 ---

 This section describes the minimum recommended computing resources for the Istio components in a cluster.
@@ -1,6 +1,5 @@
 ---
 title: Disabling Istio
-weight: 4
 ---

 This section describes how to uninstall Istio in a cluster or disable a namespace, or workload.
@@ -15,7 +14,7 @@ To uninstall Istio,
 1. In the `istio-system` namespace, go to `rancher-istio` and click **⋮ > Delete**.
 1. After `rancher-istio` is deleted, you can then select all the remaining apps in the `istio-system` namespace and click **Delete**.

-**Result:** The `rancher-istio` app in the cluster gets removed. The Istio sidecar cannot be deployed on any workloads in the cluster. 
+**Result:** The `rancher-istio` app in the cluster gets removed. The Istio sidecar cannot be deployed on any workloads in the cluster.

 :::note

@@ -1,6 +1,5 @@
 ---
 title: Role-based Access Control
-weight: 3
 ---

 This section describes the permissions required to access Istio features.
@@ -1,6 +1,5 @@
 ---
 title: Flows and ClusterFlows
-weight: 1
 ---

 For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/)
@@ -12,7 +11,7 @@ A `Flow` defines which logs to collect and filter and which output to send the l

 The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.

-`Flows` can be configured by filling out forms in the Rancher UI. 
+`Flows` can be configured by filling out forms in the Rancher UI.

 For more details about the `Flow` custom resource, see [FlowSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)

@@ -1,6 +1,5 @@
 ---
 title: Outputs and ClusterOutputs
-weight: 2
 ---

 For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)
@@ -11,7 +10,7 @@ The `Output` resource defines where your `Flows` can send the log messages. `Out

 The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.

-You can use secrets in these definitions, but they must also be in the same namespace. 
+You can use secrets in these definitions, but they must also be in the same namespace.

 `Outputs` can be configured by filling out forms in the Rancher UI.

@@ -1,6 +1,5 @@
 ---
 title: Architecture
-weight: 1
 ---

 This section summarizes the architecture of the Rancher logging application.
@@ -9,15 +8,15 @@ For more details about how the Banzai Cloud Logging operator works, see the [off

 ### How the Banzai Cloud 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. 
+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.

 Fluent Bit queries the Kubernetes API and enriches the logs with metadata about the pods, and transfers both the logs and the metadata to Fluentd. Fluentd receives, filters, and transfers logs to multiple `Outputs`.

-The following custom resources are used to define how logs are filtered and sent to their `Outputs`: 
+The following custom resources are used to define how logs are filtered and sent to their `Outputs`:

- A `Flow` is a namespaced custom resource that uses filters and selectors to route log messages to the appropriate `Outputs`. 
+- A `Flow` is a namespaced custom resource that uses filters and selectors to route log messages to the appropriate `Outputs`.
 - A `ClusterFlow` is used to route cluster-level log messages.
- An `Output` is a namespaced resource that defines where the log messages are sent. 
+- An `Output` is a namespaced resource that defines where the log messages are sent.
 - A `ClusterOutput` defines an `Output` that is available from all `Flows` and `ClusterFlows`.

 Each `Flow` must reference an `Output`, and each `ClusterFlow` must reference a `ClusterOutput`.
@@ -1,7 +1,5 @@
 ---
 title: rancher-logging Helm Chart Options
-shortTitle: Helm Chart Options
-weight: 4
 ---


@@ -73,7 +71,7 @@ If you're already using a cloud provider's own logging solution such as AWS Clou

 ### Systemd Configuration

-In Rancher logging, `SystemdLogPath` must be configured for K3s and RKE2 Kubernetes distributions. 
+In Rancher logging, `SystemdLogPath` must be configured for K3s and RKE2 Kubernetes distributions.

 K3s and RKE2 Kubernetes distributions log to journald, which is the subsystem of systemd that is used for logging. In order to collect these logs, the `systemdLogPath` needs to be defined. While the `run/log/journal` directory is used by default, some Linux distributions do not default to this path. For example, Ubuntu defaults to `var/log/journal`. To determine your `systemdLogPath` configuration, see steps below.

@@ -81,10 +79,10 @@ K3s and RKE2 Kubernetes distributions log to journald, which is the subsystem of

 * Run  `cat /etc/systemd/journald.conf | grep -E ^\#?Storage | cut -d"=" -f2` on one of your nodes.
 * If `persistent` is returned, your `systemdLogPath` should be `/var/log/journal`.
-* If `volatile` is returned, your `systemdLogPath` should be `/run/log/journal`. 
-* If `auto` is returned, check if `/var/log/journal` exists. 
-  * If `/var/log/journal` exists, then use `/var/log/journal`. 
-  * If `/var/log/journal` does not exist, then use `/run/log/journal`. 
+* If `volatile` is returned, your `systemdLogPath` should be `/run/log/journal`.
+* If `auto` is returned, check if `/var/log/journal` exists.
+  * If `/var/log/journal` exists, then use `/var/log/journal`.
+  * If `/var/log/journal` does not exist, then use `/run/log/journal`.

 :::note Notes:

@@ -1,10 +1,9 @@
 ---
 title: Migrating to Rancher v2.5 Logging
-weight: 2
 ---
 Starting in v2.5, the logging feature available within Rancher has been completely overhauled. The [logging operator](https://github.com/banzaicloud/logging-operator) from Banzai Cloud has been adopted; Rancher configures this tooling for use when deploying logging.

-Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ. 
+Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ.

 ## Installation

@@ -12,27 +11,27 @@ To install logging in Rancher v2.5+, refer to the [installation instructions](..

 ### Terminology

-In v2.5+, logging configuration in the **Cluster Dashboard**. To configure logging custom resources after the Logging application is installed, go to the left navigation bar and click **Logging**. It is from this menu option that logging for both cluster and namespace is configured. 
+In v2.5+, logging configuration in the **Cluster Dashboard**. To configure logging custom resources after the Logging application is installed, go to the left navigation bar and click **Logging**. It is from this menu option that logging for both cluster and namespace is configured.

 :::note

-Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster. 
+Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster.

 :::

 There are four key concepts to understand for v2.5+ logging:

 1. Outputs
-   
+
    `Outputs` are a configuration resource that determine a destination for collected logs. This is where settings for aggregators such as ElasticSearch, Kafka, etc. are stored. `Outputs` are namespaced resources.

 2. Flows

-    `Flows` are a configuration resource that determine collection, filtering, and destination rules for logs. It is within a flow that one will configure what logs to collect, how to mutate or filter them, and which `Outputs` to send the logs to. `Flows` are namespaced resources, and can connect either to an `Output` in the same namespace, or a `ClusterOutput`. 
+    `Flows` are a configuration resource that determine collection, filtering, and destination rules for logs. It is within a flow that one will configure what logs to collect, how to mutate or filter them, and which `Outputs` to send the logs to. `Flows` are namespaced resources, and can connect either to an `Output` in the same namespace, or a `ClusterOutput`.

 3. ClusterOutputs

-    `ClusterOutputs` serve the same functionality as `Outputs`, except they are a cluster-scoped resource. `ClusterOutputs` are necessary when collecting logs cluster-wide, or if you wish to provide an `Output` to all namespaces in your cluster. 
+    `ClusterOutputs` serve the same functionality as `Outputs`, except they are a cluster-scoped resource. `ClusterOutputs` are necessary when collecting logs cluster-wide, or if you wish to provide an `Output` to all namespaces in your cluster.

 4. ClusterFlows

@@ -40,7 +39,7 @@ There are four key concepts to understand for v2.5+ logging:

 ## Cluster Logging

-To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs. 
+To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs.

 :::note Important:

@@ -56,17 +55,17 @@ In legacy logging, in order to collect logs from across the entire cluster, one
   2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
   3. Define your cluster `Output` or `Outputs`

-This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`. 
+This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`.

 ## Project Logging

-Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces. 
+Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces.

 To collect logs from a specific namespace, follow these steps:

 1. Define an `Output` or `ClusterOutput` according to the instructions found under [Output Configuration](#output-configuration)
 2. Create a `Flow`, ensuring that it is set to be created in the namespace in which you want to gather logs.
-   1. If you wish to define _Include_ or _Exclude_ rules, you may do so. Otherwise, removal of all rules will result in all pods in the target namespace having their logs collected. 
+   1. If you wish to define _Include_ or _Exclude_ rules, you may do so. Otherwise, removal of all rules will result in all pods in the target namespace having their logs collected.
   2. You do not need to configure any filters if you do not wish - default behavior does not require their creation
   3. Define your outputs - these can be either `ClusterOutput` or `Output` objects.

@@ -79,7 +78,7 @@ To collect logs from a project, repeat the above steps for every namespace withi
 :::

 ## Output Configuration
-In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+. 
+In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+.


 ### Elasticsearch
@@ -164,7 +163,7 @@ _(1) These values are to be specified as paths to files. Those files must be mou

 ### Syslog

-As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging. 
+As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging.

 ## Custom Log Fields

@@ -185,5 +184,5 @@ spec:

 In legacy logging, collecting logs from system components was accomplished by checking a box labeled "Include System Log" when setting up cluster logging. In v2.5+ logging, system logs are gathered in one of two ways:

-1. Gather all cluster logs, not specifying any match or exclusion rules. This results in all container logs from the cluster being collected, which includes system logs. 
-2. Specifically target system logs by adding match rules for system components. Specific match rules depend on the component being collected. 
+1. Gather all cluster logs, not specifying any match or exclusion rules. This results in all container logs from the cluster being collected, which includes system logs.
+2. Specifically target system logs by adding match rules for system components. Specific match rules depend on the component being collected.
@@ -1,7 +1,5 @@
 ---
-shortTitle: Role-based Access Control
 title: Role-based Access Control for Logging
-weight: 3
 ---

 Rancher logging has two roles, `logging-admin` and `logging-view`.
@@ -1,13 +1,12 @@
 ---
 title: Working with Taints and Tolerations
-weight: 6
 ---

 "Tainting" a Kubernetes node causes pods to repel running on that node.

 Unless the pods have a `toleration` for that node's taint, they will run on other nodes in the cluster.

-[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint. 
+[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint.

 Using `nodeSelector` gives pods an affinity towards certain nodes.

@@ -1,7 +1,5 @@
 ---
 title: Longhorn - Cloud native distributed block storage for Kubernetes
-shortTitle: Longhorn Storage
-weight: 19
 ---

 [Longhorn](https://longhorn.io/) is a lightweight, reliable, and easy-to-use distributed block storage system for Kubernetes.
@@ -1,6 +1,5 @@
 ---
 title: Built-in Dashboards
-weight: 3
 ---


@@ -1,6 +1,5 @@
 ---
 title: How Monitoring Works
-weight: 1
 ---


@@ -1,6 +1,5 @@
 ---
 title: PromQL Expression Reference
-weight: 6
 ---

 The PromQL expressions in this doc can be used to configure alerts.
@@ -1,7 +1,5 @@
 ---
 title: Role-based Access Control
-shortTitle: RBAC
-weight: 2
 ---
 This section describes the expectations for RBAC for Rancher Monitoring.

@@ -77,10 +75,10 @@ Monitoring also creates additional `ClusterRoles` that are not assigned to users

 ### Assigning Roles and ClusterRoles with kubectl

-An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command. 
+An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command.


-* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes. You will need to fill in the name below, and name is case-sensitive. 
+* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes. You will need to fill in the name below, and name is case-sensitive.

 ```yaml
 # monitoring-config-view-role-binding.yaml
@@ -102,7 +100,7 @@ subjects:
 * **kubectl**: Below is an example of a `kubectl` command used to apply the binding you've created in the YAML file. As noted, you will need to fill in your YAML filename accordingly.

  * **`kubectl apply -f monitoring-config-view-role-binding.yaml`
- 
+

 ## Users with Rancher Based Permissions

@@ -1,7 +1,5 @@
 ---
 title: Windows Cluster Support for Monitoring V2
-shortTitle: Windows Support
-weight: 5
 ---

 _Available as of v2.5.8_
@@ -32,22 +30,22 @@ To facilitate this upgrade, Rancher 2.5.8 has released a brand new Helm chart ca
 1. Deploy `rancher-wins-upgrader` with the following override:
    ```yaml
    # Masquerading bootstraps the wins-upgrader installation via
-    # a previously whitelisted process path since the normal install path, 
-    # c:\etc\rancher\wins\wins-upgrade.exe is not normally whitelisted. 
-    # In this case, we are using the previously whitelisted process 
+    # a previously whitelisted process path since the normal install path,
+    # c:\etc\rancher\wins\wins-upgrade.exe is not normally whitelisted.
+    # In this case, we are using the previously whitelisted process
    # path used by Monitoring V1.
    masquerade:
      enabled: true
      as: c:\\etc\wmi-exporter\wmi-exporter.exe
    ```
    :::note Note for Non-Default Windows Prefix Path:
-    
-    - If you set up the RKE cluster with a `cluster.yml` that has a non-default `win_prefix_path`, you will need to update the `masquerade.as` field with your prefix path in place of  `c:\\`. 
-    
+
+    - If you set up the RKE cluster with a `cluster.yml` that has a non-default `win_prefix_path`, you will need to update the `masquerade.as` field with your prefix path in place of  `c:\\`.
+
    - For example, if you have `win_prefix_path: 'c:\host\opt\'`, then you will need to set `as: c:\host\opt\etc\wmi-exporter\wmi-exporter.exe`.

    :::
-    
+
 2. Once all your hosts have been successfully upgraded, please ensure that you deploy the Helm chart once again with default values to avoid conflicts with the following settings:
    ```yaml
    masquerade:
@@ -1,6 +1,5 @@
 ---
 title: NeuVector Integration
-weight: 22
 ---

 import Tabs from '@theme/Tabs';
@@ -1,9 +1,8 @@
 ---
 title: OPA Gatekeeper
-weight: 16
 ---

-To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates. 
+To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.

 OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.

@@ -57,7 +56,7 @@ When OPA Gatekeeper is enabled, Rancher installs some templates by default.
 To list the constraint templates installed in the cluster, go to the left side menu under OPA Gatekeeper and click on **Templates**.

 Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
-   
+
 ## Creating and Configuring Constraints

 [Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.
@@ -83,14 +82,14 @@ When a constraint is created, ensure that it does not apply to any Rancher or Ku
 To limit the scope of the constraint only to user namespaces, always specify these namespaces under the **Match** field of the constraint.

 Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
-   
+
 ## Enforcing Constraints in your Cluster

 When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny**.

 When the **Enforcement Action** is **Dryrun,** then any resources that violate the policy are only recorded under the constraint's status field.

-To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**. 
+To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**.

 ## Audit and Violations in your Cluster

@@ -1,6 +1,5 @@
 ---
 title: FAQ
-weight: 500
 ---

 This FAQ is a work in progress designed to answers the questions our users most frequently ask about Rancher v2.x.
@@ -1,7 +1,6 @@
 ---
 title: Container Network Interface (CNI) Providers
 description: Learn about Container Network Interface (CNI), the CNI providers Rancher provides, the features they offer, and how to choose a provider for you
-weight: 2300
 ---

 ## What is CNI?
@@ -1,6 +1,5 @@
 ---
 title: Deprecated Features in Rancher
-weight: 100
 ---

 ### What is Rancher's Deprecation policy?
@@ -14,7 +13,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
 | Patch Version |  Release Date |
 |---------------|---------------|
 | [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) |  Aug 31, 2021  |
-| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) |  Oct 11, 2021  | 
+| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) |  Oct 11, 2021  |
 | [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) |  Oct 19, 2021  |
 | [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) |  Dec 21, 2021  |
 | [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |  Mar 31, 2022  |
@@ -1,6 +1,5 @@
 ---
 title: Dockershim
-weight: 300
 ---

 The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Removal is currently scheduled for Kubernetes 1.24. For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
@@ -1,6 +1,5 @@
 ---
 title: Installing and Configuring kubectl
-weight: 100
 ---

 `kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.
@@ -1,6 +1,5 @@
 ---
 title: Networking
-weight: 8005
 ---

 Networking FAQ's
@@ -1,6 +1,5 @@
 ---
 title: Rancher is No Longer Needed
-weight: 8010
 ---

 This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted.
@@ -1,6 +1,5 @@
 ---
 title: Security
-weight: 8007

 ---

@@ -1,6 +1,5 @@
 ---
 title: Technical
-weight: 8006
 ---

 ### How can I reset the administrator password?
@@ -1,6 +1,5 @@
 ---
 title: Telemetry
-weight: 8008
 ---

 ### What is Telemetry?
@@ -1,6 +1,5 @@
 ---
 title: Docker Install with TLS Termination at Layer-7 NGINX Load Balancer
-weight: 252
 ---

 For development and testing environments that have a special requirement to terminate TLS/SSL at a load balancer instead of your Rancher Server container, deploy Rancher and configure a load balancer to work with it conjunction.
@@ -1,6 +1,5 @@
 ---
 title: Enabling the API Audit Log to Record System Events
-weight: 4
 ---

 You can enable the API audit log to record the sequence of system events initiated by individual users. You can know what happened, when it happened, who initiated it, and what cluster it affected. When you enable this feature, all requests to the Rancher API and all responses from it are written to a log.
@@ -1,6 +1,5 @@
 ---
 title: Opening Ports with firewalld
-weight: 1
 ---

 > We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
@@ -1,6 +1,5 @@
 ---
 title: Tuning etcd for Large Installations
-weight: 2
 ---

 When running larger Rancher installations with 15 or more clusters it is recommended to increase the default keyspace for etcd from the default 2GB. The maximum setting is 8GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
@@ -1,6 +1,5 @@
 ---
 title: Continuous Delivery
-weight: 3
 ---

 As of Rancher v2.5, [Fleet](../../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) comes preinstalled in Rancher, and as of Rancher v2.6, Fleet can no longer be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
@@ -1,6 +1,5 @@
 ---
 title: UI for Istio Virtual Services and Destination Rules
-weight: 2
 ---

 This feature enables a UI that lets you create, read, update and delete virtual services and destination rules, which are traffic management features of Istio.
@@ -20,7 +19,7 @@ A central advantage of Istio's traffic management features is that they allow dy

 When enabled, this feature turns on a page that lets you configure some traffic management features of Istio using the Rancher UI. Without this feature, you need to use `kubectl` to manage traffic with Istio.

-The feature enables two UI tabs: one tab for **Virtual Services** and another for **Destination Rules**. 
+The feature enables two UI tabs: one tab for **Virtual Services** and another for **Destination Rules**.

 - **Virtual services** intercept and direct traffic to your Kubernetes services, allowing you to direct percentages of traffic from a request to different services. You can use them to define a set of routing rules to apply when a host is addressed. For details, refer to the [Istio documentation.](https://istio.io/docs/reference/config/networking/v1alpha3/virtual-service/)
 - **Destination rules** serve as the single source of truth about which service versions are available to receive traffic from virtual services. You can use these resources to define policies that apply to traffic that is intended for a service after routing has occurred. For details, refer to the [Istio documentation.](https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule)
@@ -1,6 +1,5 @@
 ---
 title: "Running on ARM64 (Experimental)"
-weight: 3
 ---

 :::caution
@@ -1,6 +1,5 @@
 ---
 title: Allow Unsupported Storage Drivers
-weight: 1
 ---

 This feature allows you to use types for storage providers and provisioners that are not enabled by default.
@@ -1,7 +1,5 @@
 ---
 title: Rendering the Helm Template in an Air-Gapped Environment
-shortTitle: Air Gap Upgrade
-weight: 1
 ---

 :::note
@@ -1,7 +1,5 @@
 ---
 title: Installing Rancher on Azure Kubernetes Service
-shortTitle: AKS
-weight: 3
 ---

 This page covers how to install Rancher on Microsoft's Azure Kubernetes Service (AKS).
@@ -1,7 +1,5 @@
 ---
 title: Installing Rancher on Amazon EKS
-shortTitle: Amazon EKS
-weight: 3
 ---

 This page covers two ways to install Rancher on EKS.
@@ -1,7 +1,5 @@
 ---
 title: Installing Rancher on a Google Kubernetes Engine Cluster
-shortTitle: GKE
-weight: 3
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: Rollbacks
-weight: 3
 ---


@@ -1,6 +1,5 @@
 ---
 title: Troubleshooting the Rancher Server Kubernetes Cluster
-weight: 276
 ---

 This section describes how to troubleshoot an installation of Rancher on a Kubernetes cluster.
@@ -1,6 +1,5 @@
 ---
 title: Upgrades
-weight: 2
 ---
 The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air-gapped installs with Helm.

@@ -1,6 +1,5 @@
 ---
 title: Dockershim
-weight: 300
 ---

 The Dockershim is the CRI compliant layer between the Kubelet and the Docker daemon. As part of the Kubernetes 1.20 release, the [deprecation of the in-tree Dockershim was announced](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). For more information on the deprecation and its timelines, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed).
@@ -1,6 +1,5 @@
 ---
 title: Installing Docker
-weight: 1
 ---

 Docker is required to be installed on nodes where the Rancher server will be installed with Helm or Docker.
@@ -1,7 +1,6 @@
 ---
 title: Port Requirements
 description: Read about port requirements needed in order for Rancher to operate properly, both for Rancher nodes and downstream Kubernetes cluster nodes
-weight: 300
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: Docker Install Commands
-weight: 1
 ---

 The Docker installation is for Rancher users who want to test out Rancher.
@@ -1,6 +1,5 @@
 ---
 title: '1. Set up Infrastructure and Private Registry'
-weight: 100
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: '3. Install Kubernetes (Skip for Docker Installs)'
-weight: 300
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: 4. Install Rancher
-weight: 400
 ---

 This section is about how to deploy Rancher for your air gapped environment in a high-availability Kubernetes installation. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy.
@@ -1,6 +1,5 @@
 ---
 title: '2. Collect and Publish Images to your Private Registry'
-weight: 200
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: '2. Install Kubernetes'
-weight: 200
 ---

 Once the infrastructure is ready, you can continue with setting up an RKE cluster to install Rancher in.
@@ -1,6 +1,5 @@
 ---
 title: 3. Install Rancher
-weight: 300
 ---

 Now that you have a running RKE cluster, you can install Rancher in it. For security reasons all traffic to Rancher must be encrypted with TLS. For this tutorial you are going to automatically issue a self-signed certificate through [cert-manager](https://cert-manager.io/). In a real-world use-case you will likely use Let's Encrypt or provide your own certificate.
@@ -1,6 +1,5 @@
 ---
 title: '1. Set up Infrastructure'
-weight: 100
 ---

 In this section, you will provision the underlying infrastructure for your Rancher management server with internete access through a HTTP proxy.
@@ -1,6 +1,5 @@
 ---
 title: Certificate Troubleshooting
-weight: 4
 ---
 ### How Do I Know if My Certificates are in PEM Format?

@@ -1,6 +1,5 @@
 ---
 title: Rolling Back Rancher Installed with Docker
-weight: 1015
 ---

 If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Docker Upgrade](upgrade-docker-installed-rancher.md). Rolling back restores:
@@ -1,6 +1,5 @@
 ---
 title: Upgrading Rancher Installed with Docker
-weight: 1010
 ---

 import Tabs from '@theme/Tabs';
@@ -55,7 +54,7 @@ Write down or copy this information before starting the upgrade.

 You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by logging into your Rancher server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.

-## Upgrade 
+## Upgrade

 During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data.
 ### 1. Create a copy of the data from your Rancher server container
@@ -1,13 +1,12 @@
 ---
 title: Adding TLS Secrets
-weight: 2
 ---

 Kubernetes will create all the objects and services for Rancher, but it will not become available until we populate the `tls-rancher-ingress` secret in the `cattle-system` namespace with the certificate and key.

 Combine the server certificate followed by any intermediate certificate(s) needed into a file named `tls.crt`. Copy your certificate key into a file named `tls.key`.

-For example, [acme.sh](https://acme.sh) provides server certificate and CA chains in `fullchain.cer` file. 
+For example, [acme.sh](https://acme.sh) provides server certificate and CA chains in `fullchain.cer` file.
 This `fullchain.cer` should be renamed to `tls.crt` & certificate key file as `tls.key`.

 Use `kubectl` with the `tls` secret type to create the secrets.
@@ -1,6 +1,5 @@
 ---
 title: Bootstrap Password
-weight: 800
 ---

 When Rancher starts for the first time, a password is randomly generated for the first admin user. When the admin first logs in to Rancher, the UI shows commands that can be used to retrieve the bootstrap password. The admin needs to run those commands and log in with the bootstrap password. Then Rancher gives the admin an opportunity to reset the password.
@@ -1,6 +1,5 @@
 ---
 title: Choosing a Rancher Version
-weight: 1
 ---

 import Tabs from '@theme/Tabs';
@@ -1,6 +1,5 @@
 ---
 title: About Custom CA Root Certificates
-weight: 1
 ---

 If you're using Rancher in an internal production environment where you aren't exposing apps publicly, use a certificate from a private certificate authority (CA).
@@ -1,6 +1,5 @@
 ---
 title: Helm Version Requirements
-weight: 3
 ---

 This section contains the requirements for Helm, which is the tool used to install Rancher on a high-availability Kubernetes cluster.
@@ -1,6 +1,5 @@
 ---
 title: Setting up Local System Charts for Air Gapped Installations
-weight: 120
 ---

 The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS.
@@ -1,6 +1,5 @@
 ---
 title: Updating the Rancher Certificate
-weight: 10
 ---

 # Updating a Private CA Certificate
@@ -81,7 +80,7 @@ Also get the version string of the currently deployed Rancher chart:
 $ helm ls -A
 ```

-Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade.    
+Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade.

 If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using custom certificates.

@@ -228,7 +227,7 @@ Also get the version string of the currently deployed Rancher chart:
 $ helm ls -A
 ```

-Upgrade the Helm application instance using the original configuration values and making sure to specify the current chart version to prevent an application upgrade.    
+Upgrade the Helm application instance using the original configuration values and making sure to specify the current chart version to prevent an application upgrade.

 Also make sure to read the documentation describing the initial installation using custom certificates.

@@ -240,9 +239,9 @@ helm upgrade rancher rancher-stable/rancher \
  --set ...
 ```

-On upgrade, you can either 
+On upgrade, you can either

- remove `--set ingress.tls.source=secret \` from the Helm upgrade command, as shown above, or 
+- remove `--set ingress.tls.source=secret \` from the Helm upgrade command, as shown above, or

 - remove the `privateCA` parameter or set it to `false` because the CA is valid:

@@ -1,6 +1,5 @@
 ---
 title: Upgrading Cert-Manager
-weight: 4
 ---

 Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
@@ -1,6 +1,5 @@
 ---
 title: Upgrading and Rolling Back Kubernetes
-weight: 70
 ---

 Following an upgrade to the latest version of Rancher, downstream Kubernetes clusters can be upgraded to use the latest supported version of Kubernetes.
@@ -1,6 +1,5 @@
 ---
 title: Upgrading Kubernetes without Upgrading Rancher
-weight: 30
 ---

 The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
@@ -13,9 +12,9 @@ The Kubernetes API can change between minor versions. Therefore, we don't suppor

 Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters](../../pages-for-subheaders/launch-kubernetes-with-rancher.md). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates**. Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.

-This table below describes the CRDs that are affected by the periodic data sync. 
+This table below describes the CRDs that are affected by the periodic data sync.

-:::note 
+:::note

 Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.

@@ -1,6 +1,5 @@
 ---
 title: Overview
-weight: 1
 ---

 Rancher is a container management platform built for organizations that deploy containers in production. Rancher makes it easy to run Kubernetes everywhere, meet IT requirements, and empower DevOps teams.
@@ -1,7 +1,6 @@
 ---
 title: Rancher AWS Marketplace Quick Start
 description: Use Amazon EKS to deploy Rancher server.
-weight: 110
 ---

 There is now an additional way for you to deploy the Rancher server in AWS by using Amazon EKS. To learn more, see our [Amazon Marketplace listing](https://aws.amazon.com/marketplace/pp/prodview-2yzbnvagmi4as).
@@ -1,7 +1,6 @@
 ---
 title: Rancher AWS Quick Start Guide
 description: Read this step by step Rancher AWS guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 100
 ---
 The following steps will quickly deploy a Rancher server on AWS in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,7 +1,6 @@
 ---
 title: Rancher Azure Quick Start Guide
 description: Read this step by step Rancher Azure guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 115
 ---

 The following steps will quickly deploy a Rancher server on Azure in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.
@@ -1,7 +1,6 @@
 ---
 title: Rancher DigitalOcean Quick Start Guide
 description: Read this step by step Rancher DigitalOcean guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 120
 ---
 The following steps will quickly deploy a Rancher server on DigitalOcean in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,6 +1,5 @@
 ---
 title: Rancher Equinix Metal Quick Start
-weight: 250
 ---

 ## This tutorial walks you through the following:
@@ -1,7 +1,6 @@
 ---
 title: Rancher GCP Quick Start Guide
 description: Read this step by step Rancher GCP guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 130
 ---
 The following steps will quickly deploy a Rancher server on GCP in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,6 +1,5 @@
 ---
 title: Helm CLI Quick Start
-weight: 300
 ---

 import Tabs from '@theme/Tabs';
@@ -1,7 +1,6 @@
 ---
 title: Rancher Hetzner Cloud Quick Start Guide
 description: Read this step by step Rancher Hetzner Cloud guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 140
 ---
 The following steps will quickly deploy a Rancher server on Hetzner Cloud in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,7 +1,6 @@
 ---
 title: Rancher Outscale Quick Start Guide
 description: Read this step by step Rancher Outscale guide to quickly deploy a Rancher server with a single-node downstream Kubernetes cluster attached.
-weight: 140
 ---
 The following steps will quickly deploy a Rancher server on Outscale in a single-node K3s Kubernetes cluster, with a single-node downstream Kubernetes cluster attached.

@@ -1,6 +1,5 @@
 ---
 title: Vagrant Quick Start
-weight: 200
 ---
 The following steps quickly deploy a Rancher Server with a single node cluster attached.

@@ -1,6 +1,5 @@
 ---
 title: Workload with NodePort Quick Start
-weight: 200
 ---

 ### Prerequisite
--- a/Show More
+++ b/Show More