Remove unsupported front matter fields

2026-09-28 22:18:52 +00:00 · 2022-09-23 10:11:24 -07:00
parent 5b064e6548
commit c390289797
1553 changed files with 871 additions and 4500 deletions
@@ -1,9 +1,5 @@
 ---
 title: API Tokens
-weight: 1
-aliases:
-  - /rancher/v2.5/en/cluster-admin/api/api-tokens/
-  - /rancher/v2.x/en/api/api-tokens/
 ---

 By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
@@ -23,7 +19,7 @@ Here is the complete list of tokens that are generated with `ttl=0`:

 | Token | Description |
 |-------|-------------|
-| `kubeconfig-*` | Kubeconfig token | 
+| `kubeconfig-*` | Kubeconfig token |
 | `kubectl-shell-*` | Access to `kubectl` shell in the browser |
 | `agent-*` | Token for agent deployment |
 | `compose-token-*` | Token for compose |
@@ -39,7 +35,7 @@ Admins can set a global TTL on Kubeconfig tokens. Once the token expires the kub

 1. Disable the kubeconfig-generate-token setting in the Rancher API view at `https://<Rancher-Server-IP/v3/settings/kubeconfig-generate-token`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. The kubeconfig file will now provide a command to login to Rancher.

-2. Edit the setting and set the value to `false`. 
+2. Edit the setting and set the value to `false`.

 3. Go to setting kubeconfig-token-ttl-minutes in the Rancher API view at `https://<Rancher-Server-IP/v3/settings/kubeconfig-token-ttl-minutes`. By default, kubeconfig-token-ttl-minutes is 960 (16 hours).

@@ -47,4 +43,3 @@ Admins can set a global TTL on Kubeconfig tokens. Once the token expires the kub
 _**Note:**_ This value cannot exceed max-ttl of API tokens.(`https://<Rancher-Server-IP/v3/settings/auth-token-max-ttl-minutes`). `auth-token-max-ttl-minutes` is set to 1440 (24 hours) by default.  `auth-token-max-ttl-minutes would default to 0 allowing tokens to never expire`.


- 
@@ -1,11 +1,10 @@
 ---
 title: Minimum EKS Permissions
-weight: 1
 ---

 Documented here is a minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. Additional permissions are required for Rancher to provision the `Service Role` and `VPC` resources. Optionally these resources can be created **before** the cluster creation and will be selectable when defining the cluster configuration.

-Resource | Description 
+Resource | Description
 ---------|------------
 Service Role | The service role provides Kubernetes the permissions it requires to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
 VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
@@ -1,10 +1,5 @@
 ---
 title: Backup Configuration
-shortTitle: Backup
-weight: 1
-aliases:
-  - /rancher/v2.5/en/backups/v2.5/configuration/backup-config
-  - /rancher/v2.x/en/backups/v2.5/configuration/backup-config/
 ---

 The Backup Create page lets you configure a schedule, enable encryption and specify the storage location for your backups.
@@ -1,9 +1,5 @@
 ---
 title: Examples
-weight: 5
-aliases:
-  - /rancher/v2.5/en/backups/v2.5/examples
-  - /rancher/v2.x/en/backups/v2.5/examples/
 ---

 This section contains examples of Backup and Restore custom resources.
@@ -1,10 +1,5 @@
 ---
 title: Restore Configuration
-shortTitle: Restore
-weight: 2
-aliases:
-  - /rancher/v2.5/en/backups/v2.5/configuration/restore-config
-  - /rancher/v2.x/en/backups/v2.5/configuration/restore-config/
 ---

 The Restore Create page lets you provide details of the backup to restore from
@@ -37,13 +32,13 @@ Select this option if you are restoring from a backup file that exists in the de

 Select this option if no default storage location is configured at the operator-level, OR if the backup file exists in a different S3 bucket than the one configured as the default storage location. Provide the exact filename in the **Backup Filename** field. Refer to [this section](#getting-the-backup-filename-from-s3) for exact steps on getting the backup filename from s3. Fill in all the details for the S3 compatible object store. Its fields are exactly same as ones for the `backup.StorageLocation` configuration in the [Backup custom resource.](backup-configuration.md#storage-location)

-![](/img/backup_restore/restore/s3store.png) 
+![](/img/backup_restore/restore/s3store.png)

 ## Encryption

 If the backup was created with encryption enabled, its file will have `.enc` suffix. Choosing such a Backup, or providing a backup filename with `.enc` suffix will display another dropdown named **Encryption Config Secret**.

-![](/img/backup_restore/restore/encryption.png) 
+![](/img/backup_restore/restore/encryption.png)

 The Secret selected from this dropdown must have the same contents as the one used for the Backup custom resource while performing the backup. If the encryption configuration doesn't match, the restore will fail

@@ -1,10 +1,5 @@
 ---
 title: Backup Storage Location Configuration
-shortTitle: Storage
-weight: 3
-aliases:
-  - /rancher/v2.5/en/backups/v2.5/configuration/storage-config
-  - /rancher/v2.x/en/backups/v2.5/configuration/storage-config/
 ---

 Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible object store.
@@ -1,10 +1,7 @@
 ---
 title: Logging Best Practices
-weight: 1
-aliases:
-  - /rancher/v2.5/en/best-practices/v2.5/rancher-managed/logging
-  - /rancher/v2.x/en/best-practices/v2.5/rancher-managed/logging/
 ---
+
 In this guide, we recommend best practices for cluster-level logging and application logging.

 - [Changes in Logging in Rancher v2.5](#changes-in-logging-in-rancher-v2-5)
@@ -16,9 +13,9 @@ In this guide, we recommend best practices for cluster-level logging and applica

 Before Rancher v2.5, logging in Rancher has historically been a pretty static integration. There were a fixed list of aggregators to choose from (ElasticSearch, Splunk, Kafka, Fluentd and Syslog), and only two configuration points to choose (Cluster-level and Project-level).

-Logging in 2.5 has been completely overhauled to provide a more flexible experience for log aggregation. With the new logging feature, administrators and users alike can deploy logging that meets fine-grained collection criteria while offering a wider array of destinations and configuration options. 
+Logging in 2.5 has been completely overhauled to provide a more flexible experience for log aggregation. With the new logging feature, administrators and users alike can deploy logging that meets fine-grained collection criteria while offering a wider array of destinations and configuration options.

-"Under the hood", Rancher logging uses the Banzai Cloud logging operator. We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters. 
+"Under the hood", Rancher logging uses the Banzai Cloud logging operator. We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters.

 ## Cluster-level Logging

@@ -28,13 +25,13 @@ For some users, it is desirable to scrape logs from every container running in t

 In this scenario, it is recommended to create at least two _ClusterOutput_ objects - one for your security team (if you have that requirement), and one for yourselves, the cluster administrators. When creating these objects take care to choose an output endpoint that can handle the significant log traffic coming from the entire cluster. Also make sure to choose an appropriate index to receive all these logs.

-Once you have created these _ClusterOutput_ objects, create a _ClusterFlow_ to collect all the logs. Do not define any _Include_ or _Exclude_ rules on this flow. This will ensure that all logs from across the cluster are collected. If you have two _ClusterOutputs_, make sure to send logs to both of them. 
+Once you have created these _ClusterOutput_ objects, create a _ClusterFlow_ to collect all the logs. Do not define any _Include_ or _Exclude_ rules on this flow. This will ensure that all logs from across the cluster are collected. If you have two _ClusterOutputs_, make sure to send logs to both of them.

 ### Kubernetes Components

 _ClusterFlows_ have the ability to collect logs from all containers on all hosts in the Kubernetes cluster. This works well in cases where those containers are part of a Kubernetes pod; however, RKE containers exist outside of the scope of Kubernetes.

-Currently (as of v2.5.1) the logs from RKE containers are collected, but are not able to easily be filtered. This is because those logs do not contain information as to the source container (e.g. `etcd` or `kube-apiserver`). 
+Currently (as of v2.5.1) the logs from RKE containers are collected, but are not able to easily be filtered. This is because those logs do not contain information as to the source container (e.g. `etcd` or `kube-apiserver`).

 A future release of Rancher will include the source container name which will enable filtering of these component logs. Once that change is made, you will be able to customize a _ClusterFlow_ to retrieve **only** the Kubernetes component logs, and direct them to an appropriate output.

@@ -42,15 +39,15 @@ A future release of Rancher will include the source container name which will en

 Best practice not only in Kubernetes but in all container-based applications is to direct application logs to `stdout`/`stderr`. The container runtime will then trap these logs and do **something** with them - typically writing them to a file. Depending on the container runtime (and its configuration), these logs can end up in any number of locations.

-In the case of writing the logs to a file, Kubernetes helps by creating a `/var/log/containers` directory on each host. This directory symlinks the log files to their actual destination (which can differ based on configuration or container runtime). 
+In the case of writing the logs to a file, Kubernetes helps by creating a `/var/log/containers` directory on each host. This directory symlinks the log files to their actual destination (which can differ based on configuration or container runtime).

-Rancher logging will read all log entries in `/var/log/containers`, ensuring that all log entries from all containers (assuming a default configuration) will have the opportunity to be collected and processed. 
+Rancher logging will read all log entries in `/var/log/containers`, ensuring that all log entries from all containers (assuming a default configuration) will have the opportunity to be collected and processed.

 ### Specific Log Files

 Log collection only retrieves `stdout`/`stderr` logs from pods in Kubernetes. But what if we want to collect logs from other files that are generated by applications? Here, a log streaming sidecar (or two) may come in handy.

-The goal of setting up a streaming sidecar is to take log files that are written to disk, and have their contents streamed to `stdout`. This way, the Banzai Logging Operator can pick up those logs and send them to your desired output. 
+The goal of setting up a streaming sidecar is to take log files that are written to disk, and have their contents streamed to `stdout`. This way, the Banzai Logging Operator can pick up those logs and send them to your desired output.

 To set this up, edit your workload resource (e.g. Deployment) and add the following sidecar definition:

@@ -87,8 +84,8 @@ spec:

 ## General Best Practices

- Where possible, output structured log entries (e.g. `syslog`, JSON). This makes handling of the log entry easier as there are already parsers written for these formats. 
- Try to provide the name of the application that is creating the log entry, in the entry itself. This can make troubleshooting easier as Kubernetes objects do not always carry the name of the application as the object name. For instance, a pod ID may be something like `myapp-098kjhsdf098sdf98` which does not provide much information about the application running inside the container. 
+- Where possible, output structured log entries (e.g. `syslog`, JSON). This makes handling of the log entry easier as there are already parsers written for these formats.
+- Try to provide the name of the application that is creating the log entry, in the entry itself. This can make troubleshooting easier as Kubernetes objects do not always carry the name of the application as the object name. For instance, a pod ID may be something like `myapp-098kjhsdf098sdf98` which does not provide much information about the application running inside the container.
 - Except in the case of collecting all logs cluster-wide, try to scope your _Flow_ and _ClusterFlow_ objects tightly. This makes it easier to troubleshoot when problems arise, and also helps ensure unrelated log entries do not show up in your aggregator. An example of tight scoping would be to constrain a _Flow_ to a single _Deployment_ in a namespace, or perhaps even a single container within a _Pod_.
- Keep the log verbosity down except when troubleshooting. High log verbosity poses a number of issues, chief among them being **noise**: significant events can be drowned out in a sea of `DEBUG` messages. This is somewhat mitigated with automated alerting and scripting, but highly verbose logging still places an inordinate amount of stress on the logging infrastructure. 
- Where possible, try to provide a transaction or request ID with the log entry. This can make tracing application activity across multiple log sources easier, especially when dealing with distributed applications. 
+- Keep the log verbosity down except when troubleshooting. High log verbosity poses a number of issues, chief among them being **noise**: significant events can be drowned out in a sea of `DEBUG` messages. This is somewhat mitigated with automated alerting and scripting, but highly verbose logging still places an inordinate amount of stress on the logging infrastructure.
+- Where possible, try to provide a transaction or request ID with the log entry. This can make tracing application activity across multiple log sources easier, especially when dealing with distributed applications.
@@ -1,9 +1,5 @@
 ---
 title: Monitoring Best Practices
-weight: 2
-aliases:
-  - /rancher/v2.5/en/best-practices/v2.5/rancher-managed/monitoring
-  - /rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/
 ---

 Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. This is not different when using Kubernetes and Rancher. Fortunately the integrated monitoring and alerting functionality makes this whole process a lot easier.
@@ -1,9 +1,5 @@
 ---
 title: Best Practices for Rancher Managed vSphere Clusters
-shortTitle: Rancher Managed Clusters in vSphere
-aliases:
-  - /rancher/v2.5/en/best-practices/v2.5/rancher-managed/managed-vsphere
-  - /rancher/v2.x/en/best-practices/v2.5/rancher-managed/managed-vsphere/
 ---

 This guide outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -35,7 +31,7 @@ Doing so will ensure node VM's are spread across multiple datastores - preventin

 It’s important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double-checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node.

-# 2. Network Considerations 
+# 2. Network Considerations

 ### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes

@@ -49,7 +45,7 @@ Each node used should have a static IP configured. In the case of DHCP, each nod

 ### Leverage SSD Drives for ETCD Nodes

-ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible. 
+ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.

 # 4. Backups and Disaster Recovery

@@ -1,10 +1,5 @@
 ---
 title: Tips for Setting Up Containers
-weight: 100
-aliases:
-  - /rancher/v2.5/en/best-practices/containers
-  - /rancher/v2.5/en/best-practices/v2.5/rancher-managed/containers
-  - /rancher/v2.x/en/best-practices/v2.5/rancher-managed/containers/
 ---

 Running well-built containers can greatly impact the overall performance and security of your environment.
@@ -15,14 +10,14 @@ For a more detailed discussion of security for containers, you can also refer to

 ### Use a Common Container OS

-When possible, you should try to standardize on a common container base OS. 
+When possible, you should try to standardize on a common container base OS.

 Smaller distributions such as Alpine and BusyBox reduce container image size and generally have a smaller attack/vulnerability surface.

 Popular distributions such as Ubuntu, Fedora, and CentOS are more field-tested and offer more functionality.

 ### Start with a FROM scratch container
-If your microservice is a standalone static binary, you should use a FROM scratch container. 
+If your microservice is a standalone static binary, you should use a FROM scratch container.

 The FROM scratch container is an [official Docker image](https://hub.docker.com/_/scratch) that is empty so that you can use it to design minimal images.

@@ -1,10 +1,5 @@
 ---
 title: Installing Rancher in a vSphere Environment
-shortTitle: On-Premises Rancher in vSphere
-weight: 3
-aliases:
-  - /rancher/v2.5/en/best-practices/v2.5/rancher-server/rancher-in-vsphere
-  - /rancher/v2.x/en/best-practices/v2.5/rancher-server/rancher-in-vsphere/
 ---

 This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
@@ -30,7 +25,7 @@ In the event of a Disaster Recovery activity, availability of the Load balancer

 Configure the Load balancer to automatically mark nodes as unavailable if a health check is failed. For example, NGINX can facilitate this with:

-`max_fails=3 fail_timeout=5s` 
+`max_fails=3 fail_timeout=5s`

 ### Leverage an External Load Balancer

@@ -62,7 +57,7 @@ Doing so will ensure node VM's are spread across multiple datastores - preventin

 It’s important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double-checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node.

-## 3. Network Considerations 
+## 3. Network Considerations

 ### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes

@@ -76,7 +71,7 @@ Each node used should have a static IP configured. In the case of DHCP, each nod

 ### Leverage SSD Drives for ETCD Nodes

-ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible. 
+ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.

 ## 5. Backups and Disaster Recovery

@@ -1,9 +1,5 @@
 ---
 title: Rancher Deployment Strategy
-weight: 100
-aliases:
-  - /rancher/v2.5/en/best-practices/v2.5/rancher-server/deployment-strategies
-  - /rancher/v2.x/en/best-practices/v2.5/rancher-server/deployment-strategies/
 ---

 There are two recommended deployment strategies for a Rancher server that manages downstream Kubernetes clusters. Each one has its own pros and cons. Read more about which one would fit best for your use case:
@@ -1,10 +1,5 @@
 ---
 title: Tips for Running Rancher
-weight: 100
-aliases:
-  - /rancher/v2.5/en/best-practices/deployment-types
-  - /rancher/v2.5/en/best-practices/v2.5/rancher-server/deployment-types
-  - /rancher/v2.x/en/best-practices/v2.5/rancher-server/deployment-types/
 ---

 This guide is geared toward use cases where Rancher is used to manage downstream Kubernetes clusters. The high-availability setup is intended to prevent losing access to downstream clusters if the Rancher server is not available.
@@ -22,7 +17,7 @@ Don't run other workloads or microservices in the Kubernetes cluster that Ranche
 It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.4/op-guide/performance/).

 ### When using RKE: Back up the Statefile
-RKE keeps record of the cluster state in a file called `cluster.rkestate`. This file is important for the recovery of a cluster and/or the continued maintenance of the cluster through RKE. Because this file contains certificate material, we strongly recommend encrypting this file before backing up. After each run of `rke up` you should backup the state file. 
+RKE keeps record of the cluster state in a file called `cluster.rkestate`. This file is important for the recovery of a cluster and/or the continued maintenance of the cluster through RKE. Because this file contains certificate material, we strongly recommend encrypting this file before backing up. After each run of `rke up` you should backup the state file.

 ### Run All Nodes in the Cluster in the Same Datacenter
 For best performance, run all three of your nodes in the same geographic datacenter. If you are running nodes in the cloud, such as AWS, run each node in a separate Availability Zone. For example, launch node 1 in us-west-2a, node 2 in us-west-2b, and node 3 in us-west-2c.
@@ -35,6 +30,6 @@ The Rancher server's Kubernetes cluster should run within the [system and hardwa

 However, metrics-driven capacity planning analysis should be the ultimate guidance for scaling Rancher, because the published requirements take into account a variety of workload types.

-Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution, and Grafana, which lets you visualize the metrics from Prometheus. 
+Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution, and Grafana, which lets you visualize the metrics from Prometheus.

 After you [enable monitoring](../../../pages-for-subheaders/monitoring-and-alerting.md) in the cluster, you can set up [a notification channel](../../../pages-for-subheaders/monitoring-and-alerting.md) and alerts to let you know if your cluster is approaching its capacity. You can also use the Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale.
@@ -1,8 +1,5 @@
 ---
 title: EC2 Node Template Configuration
-weight: 1
-aliases:
-  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/ec2-node-template-config/
 ---

 For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
@@ -1,13 +1,10 @@
 ---
 title: Azure Node Template Configuration
-weight: 1
-aliases:
-  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/azure/azure-node-template-config/
 ---

 For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)

-Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one. 
+Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.

 - **Placement** sets the geographical region where your cluster is hosted and other location metadata.
 - **Network** configures the networking used in your cluster.
@@ -1,8 +1,5 @@
 ---
 title: DigitalOcean Node Template Configuration
-weight: 1
-aliases:
-  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/digital-ocean/do-node-template-config/
 ---

 Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
@@ -1,10 +1,5 @@
 ---
 title: VSphere Node Template Configuration
-weight: 2
-aliases:
-  - /rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/node-template-reference
-  - /rancher/v2.5/en/cluster-provisionin/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/enabling-uuids
-  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/
 ---

 The following node template configuration reference applies to Rancher v2.3.3+.
@@ -26,7 +21,7 @@ Your cloud credential has these fields:

 # Scheduling

-Choose what hypervisor the virtual machine will be scheduled to. 
+Choose what hypervisor the virtual machine will be scheduled to.

 The fields in the **Scheduling** section should auto-populate with the data center and other scheduling options that are available to you in vSphere.

@@ -1,7 +1,5 @@
 ---
 title: EKS Cluster Configuration Reference
-shortTitle: EKS Cluster Configuration
-weight: 2
 ---

 import Tabs from '@theme/Tabs';
@@ -1,8 +1,5 @@
 ---
 title: Private Clusters
-weight: 2
-aliases:
-  - /rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/gke/private-clusters
 ---

 _Available as of v2.5.8_
@@ -1,9 +1,5 @@
 ---
 title: RancherD Configuration Reference
-weight: 1
-aliases:
-  - /rancher/v2.5/en/installation/install-rancher-on-linux/rancherd-configuration
-  - /rancher/v2.x/en/installation/install-rancher-on-linux/rancherd-configuration/
 ---

 > **Note:** RancherD was an experimental feature available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
@@ -230,7 +226,7 @@ It can be run with the following options:
 |  `--server value, -s value`   | Server to connect to, used to join a cluster |
 |  `--cluster-reset`  | Forget all peers and become sole member of a new cluster |
 | `--secrets-encryption`  | Enable Secret encryption at rest |
- 
+


 # RancherD Agent CLI Options
@@ -1,6 +1,5 @@
 ---
 title: RKE Cluster Configuration
-weight: 1
 ---

 In [clusters launched by RKE](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md), you can edit any of the remaining options that follow.
@@ -1,8 +1,5 @@
 ---
 title: Syncing
-weight: 10
-aliases:
-  - /rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/syncing
 ---

 Syncing is the feature for EKS and GKE clusters that causes Rancher to update the clusters' values so they are up to date with their corresponding cluster object in the hosted Kubernetes provider. This enables Rancher to not be the sole owner of a hosted cluster’s state. Its largest limitation is that processing an update from Rancher and another source at the same time or within 5 minutes of one finishing may cause the state from one source to completely overwrite the other.
@@ -1,10 +1,5 @@
 ---
 title: Rancher Agent Options
-weight: 2500
-aliases:
-  - /rancher/v2.5/en/admin-settings/agent-options/
-  - /rancher/v2.5/en/cluster-provisioning/custom-clusters/agent-options
-  - /rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/agent-options/
 ---

 Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](../../../../pages-for-subheaders/use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
@@ -1,8 +1,5 @@
 ---
 title: OpenLDAP Configuration Reference
-weight: 2
-aliases:
-  - /rancher/v2.x/en/admin-settings/authentication/openldap/openldap-config/
 ---

 This section is intended to be used as a reference when setting up an OpenLDAP authentication provider in Rancher.
@@ -1,12 +1,5 @@
 ---
 title: Rancher Helm Chart Options
-weight: 1
-aliases:
-  - /rancher/v2.5/en/installation/options/
-  - /rancher/v2.5/en/installation/options/chart-options/
-  - /rancher/v2.5/en/installation/options/helm2/helm-rancher/chart-options/
-  - /rancher/v2.5/en/installation/resources/chart-options
-  - /rancher/v2.x/en/installation/install-rancher-on-k8s/chart-options/
 ---

 This page is a configuration reference for the Rancher Helm chart.
@@ -1,11 +1,5 @@
 ---
 title: TLS Settings
-weight: 3
-aliases:
-  - /rancher/v2.5/en/installation/options/tls-settings/ 
-  - /rancher/v2.5/en/admin-settings/tls-settings
-  - /rancher/v2.5/en/installation/resources/encryption/tls-settings
-  - /rancher/v2.x/en/installation/resources/tls-settings/
 ---

 Changing the default TLS settings depends on the chosen installation method.
@@ -1,8 +1,5 @@
 ---
 title: Kubernetes Concepts
-weight: 4
-aliases:
-  - /rancher/v2.x/en/overview/concepts/
 ---

 This page explains concepts related to Kubernetes that are important for understanding how Rancher works. The descriptions below provide a simplified interview of Kubernetes components. For more details, refer to the [official documentation on Kubernetes components.](https://kubernetes.io/docs/concepts/overview/components/)
@@ -36,7 +33,7 @@ Rancher uses etcd as a data store in both single node and high-availability inst

 The state of a Kubernetes cluster is maintained in [etcd.](https://kubernetes.io/docs/concepts/overview/components/#etcd)  The etcd nodes run the etcd database.

-The etcd database component is a distributed key-value store used as Kubernetes storage for all cluster data, such as cluster coordination and state management. It is recommended to run etcd on multiple nodes so that there's always a backup available for failover. 
+The etcd database component is a distributed key-value store used as Kubernetes storage for all cluster data, such as cluster coordination and state management. It is recommended to run etcd on multiple nodes so that there's always a backup available for failover.

 Although you can run etcd on just one node, etcd requires a majority of nodes, a quorum, to agree on updates to the cluster state. The cluster should always contain enough healthy etcd nodes to form a quorum. For a cluster with n members, a quorum is (n/2)+1. For any odd-sized cluster, adding one node will always increase the number of nodes necessary for a quorum.

@@ -47,7 +44,7 @@ Three etcd nodes is generally sufficient for smaller clusters and five etcd node
 Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although three or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles.

 ### Worker Nodes
-    
+
 Each [worker node](https://kubernetes.io/docs/concepts/architecture/nodes/) runs the following:

 - **Kubelets:** An agent that monitors the state of the node, ensuring your containers are healthy.
@@ -1,11 +1,10 @@
 ---
 title: Examples
-weight: 400
 ---

 ### ServiceMonitor

-An example ServiceMonitor custom resource can be found [here.](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml) 
+An example ServiceMonitor custom resource can be found [here.](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml)

 ### PodMonitor

@@ -1,6 +1,5 @@
 ---
 title: Helm Chart Options
-weight: 8
 ---


@@ -1,13 +1,5 @@
 ---
 title: Receiver Configuration
-shortTitle: Receivers
-weight: 1
-aliases:
-  - /rancher/v2.5/en/monitoring-alerting/configuration/alertmanager
-  - rancher/v2.5/en/monitoring-alerting/legacy/notifiers/
-  - /rancher/v2.5/en/cluster-admin/tools/notifiers
-  - /rancher/v2.5/en/cluster-admin/tools/alerts
-  - /rancher/v2.5/en/monitoring-alerting/configuration/alertmanager
 ---

 import Tabs from '@theme/Tabs';
@@ -1,7 +1,5 @@
 ---
 title: Route Configuration
-shortTitle: Routes
-weight: 5
 ---

 import Tabs from '@theme/Tabs';
@@ -1,7 +1,5 @@
 ---
 title: ServiceMonitor and PodMonitor Configuration
-shortTitle: ServiceMonitors and PodMonitors
-weight: 7
 ---

 ServiceMonitors and PodMonitors are both pseudo-CRDs that map the scrape configuration of the Prometheus custom resource.
@@ -14,7 +12,7 @@ ServiceMonitors are more commonly used than PodMonitors, and we recommend them f

 ### ServiceMonitors

-This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how groups of Kubernetes services should be monitored. 
+This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how groups of Kubernetes services should be monitored.

 When a ServiceMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the ServiceMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the ServiceMonitor.

@@ -24,7 +22,7 @@ For more information about how ServiceMonitors work, refer to the [Prometheus Op

 ### PodMonitors

-This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how group of pods should be monitored. 
+This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how group of pods should be monitored.

 When a PodMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the PodMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the PodMonitor.

@@ -1,9 +1,5 @@
 ---
 title: Concepts
-weight: 1
-aliases:
-  - /rancher/v2.5/en/k8s-in-rancher/pipelines/concepts
-  - /rancher/v2.x/en/pipelines/concepts/
 ---

 The purpose of this page is to explain common concepts and terminology related to pipelines.
@@ -1,9 +1,5 @@
 ---
 title: Configuring Persistent Data for Pipeline Components
-weight: 600
-aliases:
-  - /rancher/v2.5/en/k8s-in-rancher/pipelines/storage
-  - /rancher/v2.x/en/pipelines/storage/
 ---

 import Tabs from '@theme/Tabs';
@@ -1,10 +1,5 @@
 ---
 title: Example Repositories
-weight: 500
-aliases:
-  - /rancher/v2.5/en/tools/pipelines/quick-start-guide/
-  - /rancher/v2.5/en/k8s-in-rancher/pipelines/example-repos 
-  - /rancher/v2.x/en/pipelines/example-repos/
 ---

 Rancher ships with several example repositories that you can use to familiarize yourself with pipelines. We recommend configuring and testing the example repository that most resembles your environment before using pipelines with your own repositories in a production environment. Use this example repository as a sandbox for repo configuration, build demonstration, etc. Rancher includes example repositories for:
@@ -1,10 +1,5 @@
 ---
 title: Example YAML File
-weight: 501
-aliases:
-  - /rancher/v2.5/en/tools/pipelines/reference/
-  - /rancher/v2.5/en/k8s-in-rancher/pipelines/example
-  - /rancher/v2.x/en/pipelines/example/
 ---

 Pipelines can be configured either through the UI or using a yaml file in the repository, i.e. `.rancher-pipeline.yml` or `.rancher-pipeline.yaml`.
@@ -1,9 +1,5 @@
 ---
 title: Pipeline Configuration Reference
-weight: 1
-aliases:
-  - /rancher/v2.5/en/k8s-in-rancher/pipelines/config
-  - /rancher/v2.x/en/pipelines/config/
 ---

 In this section, you'll learn how to configure pipelines.
@@ -1,9 +1,5 @@
 ---
 title: Tools for Logging, Monitoring, and Visibility
-weight: 2033
-aliases:
-  - /rancher/v2.5/en/tools/notifiers-and-alerts/
-  - /rancher/v2.x/en/cluster-admin/tools/
 ---

 Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently.
@@ -1,8 +1,5 @@
 ---
 title: Architecture Recommendations
-weight: 3
-aliases:
-  - /rancher/v2.x/en/overview/architecture-recommendations/
 ---

 Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)
@@ -1,8 +1,5 @@
 ---
 title: Tools for Logging, Monitoring, and Visibility
-weight: 2525
-aliases:
-  - /rancher/v2.x/en/project-admin/tools/
 ---

 Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently.
@@ -1,6 +1,5 @@
 ---
 title: Kubernetes Security Best Practices
-weight: 5
 ---

 ### Restricting cloud metadata API access
@@ -1,8 +1,5 @@
 ---
 title: Hardening Guide with CIS 1.5 Benchmark
-weight: 200
-aliases:
-  - /rancher/v2.x/en/security/rancher-2.5/1.5-hardening-2.5/
 ---

 This document provides prescriptive guidance for hardening a production installation of a RKE cluster to be used with Rancher v2.5. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
@@ -65,7 +62,7 @@ services:
 ```

 #### Set `automountServiceAccountToken` to `false` for `default` service accounts
-Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.  
+Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.

 For each namespace including **default** and **kube-system** on a standard RKE install the **default** service account must include this value:

@@ -1,8 +1,5 @@
 ---
 title: Hardening Guide with CIS 1.6 Benchmark
-weight: 100
-aliases:
-  - /rancher/v2.x/en/security/rancher-2.5/1.6-hardening-2.5/
 ---

 This document provides prescriptive guidance for hardening a production installation of a RKE cluster to be used with Rancher v2.5.4. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
@@ -67,7 +64,7 @@ services:
 ```

 #### Set `automountServiceAccountToken` to `false` for `default` service accounts
-Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.  
+Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.

 For each namespace including **default** and **kube-system** on a standard RKE install the **default** service account must include this value:

@@ -431,48 +428,48 @@ RKE Templates are used to provision Kubernetes and define Rancher settings. Foll
 [documentaion](https://rancher.com/docs/rancher/v2.5/en/installation) for additional installation and RKE Template details.

 ```yaml
-# 
+#
 # Cluster Config
-# 
+#
 default_pod_security_policy_template_id: restricted
 docker_root_dir: /var/lib/docker
 enable_cluster_alerting: false
 enable_cluster_monitoring: false
 enable_network_policy: true
-# 
+#
 # Rancher Config
-# 
+#
 rancher_kubernetes_engine_config:
  addon_job_timeout: 45
  ignore_docker_version: true
  kubernetes_version: v1.18.12-rancher1-1
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
  network:
    mtu: 0
    plugin: canal
  rotate_encryption_key: false
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -482,7 +479,7 @@ rancher_kubernetes_engine_config:
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
  services:
    etcd:
      backup_config:
@@ -1,8 +1,5 @@
 ---
 title: CIS 1.5 Benchmark - Self-Assessment Guide - Rancher v2.5
-weight: 201
-aliases:
-  - /rancher/v2.x/en/security/rancher-2.5/1.5-benchmark-2.5/
 ---

 ### CIS v1.5 Kubernetes Benchmark - Rancher v2.5 with Kubernetes v1.15
@@ -1,8 +1,5 @@
 ---
 title: CIS 1.6 Benchmark - Self-Assessment Guide - Rancher v2.5.4
-weight: 101
-aliases:
-  - /rancher/v2.x/en/security/rancher-2.5/1.6-benchmark-2.5/
 ---

 ### CIS 1.6 Kubernetes Benchmark - Rancher v2.5.4 with Kubernetes v1.18
@@ -1,6 +1,5 @@
 ---
 title: Security Advisories and CVEs
-weight: 300
 ---

 Rancher is committed to informing the community of security issues in our products. Rancher will publish security advisories and CVEs (Common Vulnerabilities and Exposures) for issues we have resolved. New security advisories are also published in Rancher's GitHub [security page](https://github.com/rancher/rancher/security/advisories).
@@ -1,8 +1,5 @@
 ---
 title: RKE1 Example YAML
-weight: 60
-aliases:
-  - /rancher/v2.x/en/admin-settings/rke-templates/example-yaml/
 ---

 Below is an example RKE template configuration file for reference.
@@ -10,9 +7,9 @@ Below is an example RKE template configuration file for reference.
 The YAML in the RKE template uses the same customization that is used when you create an RKE cluster. However, since the YAML is within the context of a Rancher provisioned RKE cluster, the customization from the RKE docs needs to be nested under the `rancher_kubernetes_engine` directive.

 ```yaml
-# 
+#
 # Cluster Config
-# 
+#
 docker_root_dir: /var/lib/docker

 enable_cluster_alerting: false
@@ -22,7 +19,7 @@ enable_cluster_alerting: false
 # but end users could still turn alerting
 # on or off.

-enable_cluster_monitoring: true 
+enable_cluster_monitoring: true
 # This setting is not enforced. Clusters
 # created with this sample template
 # would have monitoring turned on
@@ -32,54 +29,54 @@ enable_cluster_monitoring: true
 enable_network_policy: false
 local_cluster_auth_endpoint:
  enabled: true
-# 
+#
 # Rancher Config
-# 
+#
 rancher_kubernetes_engine_config: # Your RKE template config goes here.
  addon_job_timeout: 30
  authentication:
    strategy: x509
  ignore_docker_version: true
-# 
+#
 # # Currently only nginx ingress provider is supported.
 # # To disable ingress controller, set `provider: none`
 # # To enable ingress on specific nodes, use the node_selector, eg:
 #    provider: nginx
 #    node_selector:
 #      app: ingress
-# 
+#
  ingress:
    provider: nginx
  kubernetes_version: v1.15.3-rancher3-1
  monitoring:
    provider: metrics-server
-# 
+#
 #   If you are using calico on AWS
-# 
+#
 #    network:
 #      plugin: calico
 #      calico_network_provider:
 #        cloud_provider: aws
-# 
+#
 # # To specify flannel interface
-# 
+#
 #    network:
 #      plugin: flannel
 #      flannel_network_provider:
 #      iface: eth1
-# 
+#
 # # To specify flannel interface for canal plugin
-# 
+#
 #    network:
 #      plugin: canal
 #      canal_network_provider:
 #        iface: eth1
-# 
+#
  network:
    options:
      flannel_backend_type: vxlan
    plugin: canal
-# 
+#
 #    services:
 #      kube-api:
 #        service_cluster_ip_range: 10.43.0.0/16
@@ -89,7 +86,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here.
 #      kubelet:
 #        cluster_domain: cluster.local
 #        cluster_dns_server: 10.43.0.10
-# 
+#
  services:
    etcd:
      backup_config:
@@ -1,8 +1,5 @@
 ---
 title: Advanced Options for Docker Installs
-weight: 5
-aliases:
-  - /rancher/v2.x/en/installation/other-installation-methods/single-node-docker/advanced/
 ---

 When installing Rancher, there are several [advanced options](../../pages-for-subheaders/resources.md) that can be enabled:
@@ -1,10 +1,5 @@
 ---
 title: HTTP Proxy Configuration
-weight: 251
-aliases:
-  - /rancher/v2.5/en/installation/proxy-configuration/
-  - /rancher/v2.5/en/installation/single-node/proxy
-  - /rancher/v2.x/en/installation/other-installation-methods/single-node-docker/proxy/
 ---

 If you operate Rancher behind a proxy and you want to access services through the proxy (such as retrieving catalogs), you must provide Rancher information about your proxy. As Rancher is written in Go, it uses the common proxy environment variables as shown below.
@@ -1,8 +1,5 @@
 ---
 title: System Tools
-weight: 22
-aliases:
-  - /rancher/v2.x/en/system-tools/
 ---

 System Tools is a tool to perform operational tasks on [Rancher Launched Kubernetes](../pages-for-subheaders/launch-kubernetes-with-rancher.md) clusters or [installations of Rancher on an RKE cluster.](../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md) The tasks include:
@@ -1,10 +1,5 @@
 ---
 title: API Keys
-weight: 7005
-aliases:
-  - /rancher/v2.5/en/concepts/api-keys/
-  - /rancher/v2.5/en/tasks/user-settings/api-keys/
-  - /rancher/v2.x/en/user-settings/api-keys/
 ---

 ## API Keys and User Authentication
@@ -31,7 +26,7 @@ API Keys are composed of four components:
    The API key won't be valid after expiration. Shorter expiration periods are more secure.

    Expiration period will be bound by `v3/settings/auth-token-max-ttl-minutes`. If it exceeds the max-ttl, API key will be created with max-ttl as the expiration period.
-    
+
    A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) for more information.

 4. Click **Create**.
@@ -1,8 +1,5 @@
 ---
 title: Managing Cloud Credentials
-weight: 7011
-aliases:
-  - /rancher/v2.x/en/user-settings/cloud-credentials/
 ---

 When you create a cluster [hosted by an infrastructure provider](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), [node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node.
@@ -31,7 +28,7 @@ All cloud credentials are bound to the user profile of who created it. They **ca

 ## Updating a Cloud Credential

-When access credentials are changed or compromised, updating a cloud credential allows you to rotate those credentials while keeping the same node template.  
+When access credentials are changed or compromised, updating a cloud credential allows you to rotate those credentials while keeping the same node template.

 1. From your user settings, select **User Avatar > Cloud Credentials**.
 1. Choose the cloud credential you want to edit and click the **&#8942; > Edit**.
@@ -1,8 +1,5 @@
 ---
 title: Managing Node Templates
-weight: 7010
-aliases:
-  - /rancher/v2.x/en/user-settings/node-templates/
 ---

 When you provision a cluster [hosted by an infrastructure provider](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), [node templates](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:
@@ -26,7 +23,7 @@ When you create a node template, it is bound to your user profile. Node template
 1. Choose the node template that you want to edit and click the **&#8942; > Edit**.

    :::note
-    
+
    As of v2.2.0, the default `active` [node drivers](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md) and any node driver, that has fields marked as `password`, are required to use [cloud credentials](../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#cloud-credentials). If you have upgraded to v2.2.0, existing node templates will continue to work with the previous account access  information, but when you edit the node template, you will be required to create a cloud credential and the node template will start using it.
    :::

@@ -1,8 +1,5 @@
 ---
 title: User Preferences
-weight: 7012
-aliases:
-  - /rancher/v2.x/en/user-settings/preferences/
 ---

 import Tabs from '@theme/Tabs';