Merge pull request #1803 from rancher/v2.9.10

Merge release branch v2.9.10 into main
Merge pull request #1804 from rancher/v2.10.6
2026-11-10 10:49:17 +00:00 · 2025-05-22 16:48:41 -07:00 · 2025-05-22 16:48:14 -07:00 · 2025-05-22 16:48:00 -07:00 · 2025-05-22 16:08:59 -07:00 · 2025-05-22 16:08:50 -07:00
1921 changed files with 152368 additions and 4389 deletions
@@ -0,0 +1,15 @@
+---
+name: Release Maintenance Task Checklist
+about: Track tasks that need to be done every release.
+title: '<VERSION> - Rancher Manager Release Maintenance Task Checklist'
+---
+
+This issue is to track tasks that need to be done every release regardless of whether the release has new feature content or not.
+
+- [ ] Update the [versions table](https://ranchermanager.docs.rancher.com/versions)
+- [ ] Update the [Rancher:webhook version mapping table](https://ranchermanager.docs.rancher.com/reference-guides/rancher-webhook)
+- [ ] Update the [CNI popularity table](https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers#cni-community-popularity)
+- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix):
+- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features):
+- [ ] Create a new [release](https://github.com/rancher/rancher-docs/releases)
+- [ ] Update Algolia search index
@@ -1,9 +1,6 @@
 ---
 name: Request a New Feature
 about: For requesting new feature(s) to be added to the docs.
-title: ''
-labels: ''
-assignees: ''
 ---

 ## Related Issues
@@ -1,9 +1,6 @@
 ---
 name: Request an Update
 about: For fixing docs errors/typos, adding needed/missing information, updating verbiage, deleting outdated info, etc.
-title: ''
-labels: ''
-assignees: ''
 ---

 ## Related Issues
@@ -0,0 +1 @@
+f288d286db3b7c65e02cb6635d0c048f0f7a88fa
@@ -0,0 +1,31 @@
+name: Create issue to track porting between Community and Product docs
+
+on:
+  pull_request_target:
+    types:
+      - closed
+    branches: 
+      - main
+    paths-ignore:
+      - '**/README.md'
+
+permissions:
+  issues: write
+  pull-requests: read
+
+jobs:
+  create_issue:
+    if: github.event.pull_request.merged == true && contains( github.event.pull_request.labels.*.name, 'port/community-product')
+    runs-on: ubuntu-latest
+    steps:
+    - name: Create issue
+      env:
+        GH_TOKEN: ${{ github.token }}
+        REPO_TYPE: ${{ contains( github.repository, 'product-docs') && 'Product' || 'Community' }}
+        PR_TITLE: ${{ github.event.pull_request.title }}
+      run: |
+        gh issue create \
+          --repo ${{ github.repository }} \
+          --title "Port $REPO_TYPE docs PR #${{ github.event.pull_request.number }}: $PR_TITLE" \
+          --body "Reference: https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}" \
+          --label port/community-product
@@ -6,6 +6,7 @@ on:
      - main
    paths-ignore:
      - '**/README.md'
+      - '**/.github/ISSUE_TEMPLATE/**'

 jobs:
  build:
@@ -4,6 +4,7 @@ on:
  pull_request:
    paths-ignore:
      - '**/README.md'
+      - '**/.github/ISSUE_TEMPLATE/**'

 jobs:
  test-deploy:
@@ -1 +1 @@
-* @btat @LucasSaintarbor @sunilarjun
+* @btat @LucasSaintarbor @pmkovar @sunilarjun
@@ -93,7 +93,7 @@ Subsequent executions will check for updated dependencies, if there are none, it

 License
 =======
-Copyright (c) 2014-2024 [Rancher Labs, Inc.](https://rancher.com)
+Copyright (c) 2014-2025 [SUSE, LLC.](https://www.suse.com/)

 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
@@ -52,7 +52,7 @@ As an [administrator](../../../how-to-guides/advanced-user-guides/authentication
 > | 10252 | Controlplane | Kube controller manager |
 > | 2379 | Etcd | Etcd server |

-> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)
+> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)

 1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring.

@@ -121,7 +121,7 @@ To test the overlay network, you can launch the following `DaemonSet` definition
          - image: alpine
            imagePullPolicy: Always
            name: alpine
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log
    ```

@@ -41,7 +41,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..

 The upgrade instructions assume you are using Helm 3.

-For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.

 ### For air gap installs: Populate private registry

@@ -16,12 +16,13 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
 - [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
 - At least 4GB of free RAM.

-### Note
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
+:::note 

-  `vagrant plugin install vagrant-vboxmanage`
+Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands: 
+- `vagrant plugin install vagrant-vboxmanage` 
+- `vagrant plugin install vagrant-vbguest` 

-  `vagrant plugin install vagrant-vbguest`
+:::

 ## Getting Started

@@ -111,7 +111,7 @@ If you are experiencing issues while testing the connection to the Keycloak serv
 When you click on **Authenticate with Keycloak**, your are not redirected to your IdP.

  * Verify your Keycloak client configuration.
-  * Make sure `Force Post Binding` set to `OFF`.
+  * Make sure `Force Post Binding` is set to `OFF`.


 ### Forbidden message displayed after IdP login
@@ -10,7 +10,7 @@ After installation, the [system administrator](manage-role-based-access-control-

 ## First Log In

-After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
+After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**. You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.

 >**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care.

@@ -38,7 +38,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl

 ### About the kube-api-auth Authentication Webhook

-The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint,](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
+The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.

 During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.

@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
 - The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
 - The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.

-<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
-
 ![High-availability Kubernetes Installation of Rancher](/img/ha/rancher2ha.svg)
 <sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
@@ -100,7 +100,7 @@ If you want to check resolving of domain names on all of the hosts, execute the
          - image: busybox:1.28
            imagePullPolicy: Always
            name: alpine
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log
    ```

@@ -43,7 +43,7 @@ To test the overlay network, you can launch the following `DaemonSet` definition
          - image: rancherlabs/swiss-army-knife
            imagePullPolicy: Always
            name: overlaytest
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log

    ```
@@ -8,10 +8,13 @@ title: Continuous Delivery with Fleet

 _Available as of Rancher v2.5_

-Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
+## What is Continuous Delivery with Fleet?

-Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
+Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.

+ - *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
+
+ - *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, 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 all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.

 ## Architecture

@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded

 - Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).

-<figcaption>How data flows through the monitoring application:</figcaption>
-
-
 ## 2. How Prometheus Works

 ### Storing Time Series Data