Remove version-latest dir

Originally added due to some unexpected versioning behavior that's no longer reproducible Apply suggestions from code review Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>
2026-09-25 20:48:11 +00:00 · 2023-10-12 10:26:54 -07:00
parent e60feac44c
commit 5c083c320a
915 changed files with 73 additions and 145857 deletions
@@ -154,7 +154,7 @@ helm upgrade --install \
  --namespace ingress-nginx \
  --set controller.service.type=LoadBalancer \
  --version 4.0.18 \
-  --create-namespace 
+  --create-namespace
 ```

 ## 8. Get the Load Balancer IP
@@ -202,4 +202,4 @@ In Rancher v2.7.5, if you intend to use the default GKE ingress on your cluster
 --set service.type=NodePort
 ```

-This is necessary because of compatibility issues between this setup and ClusterIP, the default type for `cattle-system/rancher`. 
+This is necessary because of compatibility issues between this setup and ClusterIP, the default type for `cattle-system/rancher`.
@@ -62,7 +62,7 @@ For information on enabling experimental features, refer to [this page.](../../.
 | `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/                   |
 | `tls`                          | "ingress"                                             | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external"                                           |
 | `useBundledSystemChart`        | `false`                                               | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.  |
-| `global.cattle.psp.enabled`        | `true`                                               | `bool` - select 'false' to disable PSPs for Kubernetes v1.25 and above when using Rancher v2.7.2-v2.7.4. When using Rancher v2.7.5 and above, Rancher attempts to detect if a cluster is running a Kubernetes version where PSPs are not supported, and will default it's usage of PSPs to false if it can determine that PSPs are not supported in the cluster. Users can still manually override this by explicitly providing `true` or `false` for this value. Rancher will still use PSPs by default in clusters which support PSPs (such as clusters running Kubernetes v1.24 or lower).|
+| `global.cattle.psp.enabled`        | `true`                                               | `bool` - select 'false' to disable PSPs for Kubernetes v1.25 and above when using Rancher v2.7.2-v2.7.4. When using Rancher v2.7.5 and above, Rancher attempts to detect if a cluster is running a Kubernetes version where PSPs are not supported, and will default it's usage of PSPs to false if it can determine that PSPs are not supported in the cluster. Users can still manually override this by explicitly providing `true` or `false` for this value. Rancher will still use PSPs by default in clusters which support PSPs (such as clusters running Kubernetes v1.24 or lower). |


 ### Bootstrap Password
@@ -96,7 +96,7 @@ To enable draining each node during a cluster upgrade,

 :::note

-There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show state of etcd and controlplane as drained, even though they are being drained.
+There is a [known issue](https://github.com/rancher/rancher/issues/25478) in which the Rancher UI doesn't show the state of etcd and controlplane as drained, even though they are being drained.

 :::

@@ -33,7 +33,7 @@ This Quick Start Guide is divided into different tasks for easier consumption.

 ### 1. Provision a Equinix Metal Host

-Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, CLI, or API. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://metal.equinix.com/developers/docs/deploy/on-demand/). You can find additional documentation on Equinix Metal server types and prices below:
+Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, API, or CLI. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://metal.equinix.com/developers/docs/deploy/on-demand/). You can find additional documentation on Equinix Metal server types and prices below:
  - [Equinix Metal Server Types](https://metal.equinix.com/developers/docs/servers/about/)
  - [Equinix Metal Pricing](https://metal.equinix.com/developers/docs/servers/server-specs/)

@@ -45,27 +45,6 @@ If the requested resources exceed the remaining capacity in the project for thos
 However, this is not the case with namespaces created **_outside_** of Rancher's UI. For namespaces created via `kubectl`, Rancher
 will assign a resource quota that has a **zero** amount for any resource that requested more capacity than what remains in the project.

-To create a project with a resource quota via `kubectl`, use the `spec.resourceQuota` and `spec.namespaceDefaultResourceQuota` fields:
-
-```
-apiVersion: management.cattle.io/v3
-kind: Project
-metadata:
-  generateName: p-
-  namespace: c-m-abcde
-spec:
-  clusterName: c-m-abcde
-  displayName: myproject
-  resourceQuota:
-    limit:
-      limitsCpu: 1000m
-  namespaceDefaultResourceQuota:
-    limit:
-      limitsCpu: 50m
-```
-
-Use `metadata.generateName` to ensure a unique project ID. Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.
-
 To create a namespace in an existing project via `kubectl`, use the `field.cattle.io/projectId` annotation. To override the default
 requested quota limit, use the `field.cattle.io/resourceQuota` annotation.

@@ -12,7 +12,7 @@ The steps for setting up monitoring for workloads depend on whether you want bas

 If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default. The resource usage time series data is in Prometheus's local time series database.

-Grafana shows the data in aggregate, but you can see the data for the individual workload by using a PromQL query that extracts the data for that workload. Once you have the PromQL query, you can execute the query individually in the Prometheus UI and see the time series visualized there, or you can use the query to customize a Grafana dashboard to display the workload metrics. For examples of PromQL queries for workload metrics, see [this section.](../../../integrations-in-rancher/monitoring-and-alerting/promql-expressions.md#workload-metrics)
+Grafana shows the data in aggregate, but you can see the data for the individual workload by using a PromQL query that extracts the data for that workload. Once you have the PromQL query, you can execute the query individually in the Prometheus UI and see the time series visualized there, or you can use the query to customize a Grafana dashboard to display the workload metrics. For examples of PromQL queries for workload metrics, see [this section](../../../integrations-in-rancher/monitoring-and-alerting/promql-expressions.md#workload-metrics).

 To set up custom metrics for your workload, you will need to set up an exporter and create a new ServiceMonitor custom resource to configure Prometheus to scrape metrics from your exporter.

@@ -108,4 +108,4 @@ The OpenLDAP service account is used for all searches. Rancher users will see us
 1. Click **Okta** or, if SAML is already configured, **Edit Config**
 1. Under **User and Group Search**, check **Configure an OpenLDAP server**

-If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
+If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
@@ -36,7 +36,7 @@ See the [rancher/rancher-cleanup repo](https://github.com/rancher/rancher-cleanu
 ### Rolling back from v2.6.4+ to lower versions of v2.6.x

 1. Follow these [instructions](https://github.com/rancher/rancher-cleanup/blob/main/README.md) to run the scripts.
-1. Follow these [instructions](../backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
+1. Follow these [instructions](./migrate-rancher-to-new-cluster.md) to install the rancher-backup Helm chart on the existing cluster and restore the previous state.
    1. Omit Step 3.
    1. When you reach Step 4, install the Rancher v2.6.x version on the local cluster you intend to roll back to.

@@ -111,4 +111,4 @@ After creating your cluster, you can access it through the Rancher UI. As a best

 - **Access your cluster with the kubectl CLI:** Follow [these steps](../../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-from-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
 - **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
- **Provision Storage:** For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../../../../../pages-for-subheaders/provisioning-storage-examples.md) In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. For details, refer to [in-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md) and [out-of-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md).
+- **Provision Storage:** For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../../../../../pages-for-subheaders/provisioning-storage-examples.md) In order to dynamically provision storage in vSphere, the vSphere provider must be enabled. For details, refer to [in-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-in-tree-vsphere.md) and [out-of-tree vSphere cloud provider docs](../../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/configure-out-of-tree-vsphere.md).
@@ -156,4 +156,4 @@ Finally, restart the rancher-csp-adapter deployment to ensure that the updated v
 kubectl rollout restart deploy rancher-csp-adapter -n cattle-csp-adapter-system
 ```

-> **Note:** There are methods such as cert-manager's [trust operator](https://cert-manager.io/docs/projects/trust/) which can help reduce the number of manual rotation tasks over time. While these options are not officially supported, they may be useful to users wishing to automate some of these tasks.
+> **Note:** There are methods such as cert-manager's [trust operator](https://cert-manager.io/docs/projects/trust/) which can help reduce the number of manual rotation tasks over time. While these options are not officially supported, they may be useful to users wishing to automate some of these tasks.
@@ -103,4 +103,4 @@ Configure the settings for the OpenLDAP server, groups and users. For help filli

 ## Troubleshooting

-If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
+If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
@@ -8,7 +8,7 @@ description: "Rancher adds significant value on top of Kubernetes: managing hund
 <head>
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com"/>
 </head>
-
+ 
 Rancher is a Kubernetes management tool to deploy and run clusters anywhere and on any provider.

 Rancher can provision Kubernetes from a hosted provider, provision compute nodes and then install Kubernetes onto them, or import existing Kubernetes clusters running anywhere.
@@ -17,7 +17,7 @@ Your cloud credential has these fields:
 | Credential Field | Description |
 |-----------------|--------------|
 | vCenter or ESXi Server |  Enter the vCenter or ESXi hostname/IP. ESXi is the virtualization platform where you create and run virtual machines and virtual appliances. vCenter Server is the service through which you manage multiple hosts connected in a network and pool host resources. |
-| Port | Optional: configure configure the port of the vCenter or ESXi server. |
+| Port | Configure the port of the vCenter or ESXi server. |
 | Username and password | Enter your vSphere login username and password. |

 ## Scheduling
@@ -96,4 +96,4 @@ In the **Engine Options** section of the node template, you can configure the co
 If you're provisioning Red Hat Enterprise Linux (RHEL) or CentOS nodes, leave the **Docker Install URL** field as the default value, or select **none**. This will bypass a check for Docker installation, as Docker is already installed on these node types.

 If you set **Docker Install URL** to a value other than the default or **none**, you might see an error message such as the following: `Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories.`
-:::
+:::
@@ -152,4 +152,3 @@ The syncing interval can be changed by running `kubectl edit setting eks-refresh
 If the `eks-refresh-cron` setting was previously set, the migration will happen automatically.

 The shorter the refresh window, the less likely any race conditions will occur, but it does increase the likelihood of encountering request limits that may be in place for AWS APIs.
-
@@ -46,7 +46,7 @@ The route needs to refer to a [receiver](./receivers.md) that has already been c

 | Field |    Default | Description |
 |-------|--------------|---------|
-| Group By |  N/a | List of labels to group by. All labels must be unique. Special label "..." (aggregate by all possible labels), if provided, must be the only element in the list. Accepts a list of strings. See the [upstream documentation](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route) for details. |
+| Group By |  N/a | List of labels to group by. Labels must be unique. Special label "..." (aggregate by all possible labels), if provided, must be the only element in the list. Accepts a list of strings. See the [upstream documentation](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route) for details. |
 | Group Wait | 30s | How long to wait to buffer alerts of the same group before sending initially. |
 | Group Interval | 5m | How long to wait before sending an alert that has been added to a group of alerts for which an initial notification has already been sent. |
 | Repeat Interval |  4h | How long to wait before re-sending a given alert that has already been sent. |
@@ -64,7 +64,6 @@ An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes A

 > ACE is available on RKE, RKE2, and K3s clusters that are provisioned or registered with Rancher. It's not available on  clusters in a hosted Kubernetes provider, such as Amazon's EKS.

-
 There are two main reasons why a user might need the authorized cluster endpoint:

 - To access a downstream user cluster while Rancher is down
@@ -1,133 +0,0 @@
---
-title: Hardening the Rancher Webhook
---
-
-Rancher Webhook is an important component within Rancher, playing a role in enforcing security requirements for Rancher and its workloads. To decrease its attack surface, access to it should be limited to the only valid caller it has: the Kubernetes API server. This can be done by using network policies and authentication independently or in conjunction with each other to harden the webhook against attacks.
-
-## Block External Traffic Using Network Policies
-
-The webhook is only expected to accept requests from the Kubernetes API server. By default, however, the webhook can accept traffic from any source. If you are using a CNI that supports Network Policies, you can create a policy that blocks traffic that doesn't originate from the API server.
-
-The built-in NetworkPolicy resource in Kubernetes can't block or admit traffic from the cluster hosts, and the `kube-apiserver` process is always running on the host network. Therefore, you must use the advanced network policy resources from the CNI in use. Examples for Calico and Cilium follow. Consult the documentation for your CNI for more details.
-
-### Calico
-
-Use the NetworkPolicy resource in the `crd.projectcalico.org/v1` API group. Use the selector `app == 'rancher-webhook'` to create a rule for the webhook, and set the CIDR of the control plane hosts as the ingress source:
-
-```yaml
-apiVersion: crd.projectcalico.org/v1
-kind: NetworkPolicy
-metadata:
-  name: allow-k8s
-  namespace: cattle-system
-spec:
-  selector: app == 'rancher-webhook'
-  types:
-    - Ingress
-  ingress:
-    - action: Allow
-      protocol: TCP
-      source:
-        nets:
-        - 192.168.42.0/24 # CIDR of the control plane host. May list more than 1 if the hosts are in different subnets.
-      destination:
-        selector:
-          app == 'rancher-webhook'
-```
-
-### Cilium
-
-Use the CiliumNetworkPolicy resource in the `cilium.io/v2` API group. Add the `host` and `remote-node` keys to the `fromEntities` ingress rule. This blocks in-cluster and external traffic while allowing traffic from the hosts.
-
-```yaml
-apiVersion: "cilium.io/v2"
-kind: CiliumNetworkPolicy
-metadata:
-  name: allow-k8s
-  namespace: cattle-system
-spec:
-  endpointSelector:
-    matchLabels:
-      app: rancher-webhook
-  ingress:
-    - fromEntities:
-      - host
-      - remote-node
-```
-
-## Require the Kubernetes API Server to Authenticate to the Webhook
-
-The webhook should only accept requests from the Kubernetes API server. By default, the webhook doesn't require clients to authenticate to it. It will accept any request. You can configure the webhook to require credentials so that only the API server can access it. More information can be found in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers).
-
-1. Configure the API server to present a client certificate to the webhook, pointing to an AdmissionConfiguration file to configure the ValidatingAdmissionWebhook and MutatingAdmissionWebhook plugins:
-
-    ```yaml
-    # /etc/rancher/admission/admission.yaml
-    apiVersion: apiserver.config.k8s.io/v1
-    kind: AdmissionConfiguration
-    plugins:
-    - name: ValidatingAdmissionWebhook
-      configuration:
-        apiVersion: apiserver.config.k8s.io/v1
-        kind: WebhookAdmissionConfiguration
-        kubeConfigFile: "/etc/rancher/admission/kubeconfig"
-    - name: MutatingAdmissionWebhook
-      configuration:
-        apiVersion: apiserver.config.k8s.io/v1
-        kind: WebhookAdmissionConfiguration
-        kubeConfigFile: "/etc/rancher/admission/kubeconfig"
-    ```
-
-    This is also the same config file where other admission plugins are configured, such as PodSecurity. If your distro or your setup uses additional admission plugins, configure those as well. For example, add [RKE2's PodSecurity configuration](https://docs.rke2.io/security/pod_security_standards) to this file.
-
-2. Create the kubeconfig file that the admission plugins refer to. Rancher Webhook only supports client certificate authentication, so generate a TLS key pair, and set the kubeconfig to use either `client-certificate` and `client-key` or `client-certificate-data` and `client-key-data`. For example:
-
-    ```yaml
-    # /etc/rancher/admission/kubeconfig
-    apiVersion: v1
-    kind: Config
-    users:
-    - name: 'rancher-webhook.cattle-system.svc'
-      user:
-        client-certificate: /path/to/client/cert
-        client-key: /path/to/client/key
-    ```
-
-3. Start the kube-apiserver binary with the flag `--admission-control-config-file` pointing to your AdmissionConfiguration file. The way to do this varies by distro, and it isn't supported universally, such as in hosted Kubernetes providers. Consult the documentation for your Kubernetes distribution.
-
-    For RKE2, `rke2-server` can be started with a config file like so:
-
-    ```yaml
-    # /etc/rancher/rke2/config.yaml
-    kube-apiserver-arg:
-    - admission-control-config-file=/etc/rancher/admission/admission.yaml
-    kube-apiserver-extra-mount:
-    - /etc/rancher/admission:/etc/rancher/admission:ro
-    ```
-
-    :::danger
-    Some distros set this flag by default. If your distro provisions its own AdmissionConfiguration, you must include it in your custom admission control config file. For example, RKE2 installs an AdmissionConfiguration file at `/etc/rancher/rke2/rke2-pss.yaml`, which configures the PodSecurity admission plugin. Setting `admission-control-config-file` in config.yaml will override this essential security setting. To include both plugins, consult [the Default Pod Security Standards documentation](https://docs.rke2.io/security/pod_security_standards) and copy the appropriate plugin configuration to your admission.yaml.
-    :::
-
-4. If you're using Rancher to provision your cluster using existing nodes, create these files on the node before you provision them.
-
-    If you're using Rancher to provision your cluster on new nodes, allow the provisioning to complete, then use the provided SSH key and IP address to connect to the nodes, and place the RKE2 config file in the `/etc/rancher/rke2/config.yaml.d/` directory.
-
-5. After the cluster is configured with these credentials, configure the Rancher cluster agent to enable authentication in the webhook. Create a file containing these chart values:
-
-    ```yaml
-    # values.yaml
-    auth:
-      clientCA: <base64-encoded certificate authority that signed the kube-apiserver's client certificates>
-      allowedCNs:
-      - <list of Common Names identifying the kube-apiserver's client certificates.>
-      - <if not provided, any cert signed by the given CA will be accepted.>
-    ```
-
-6. Create a configmap in the `cattle-system` namespace on the provisioned cluster with these values:
-
-    ```
-    kubectl --namespace cattle-system create configmap --from-file=rancher-webhook=values.yaml
-    ```
-
-    The webhook will restart with these values.