Merge release branch v2.11.1 into main (#1753 )

* v2.11.1 Maintenance Items (#1748) * [v2.11.1] version update * [v2.11.1] webhook update * [v2.11.1] webhook update * [v2.11.1] deprecated features update * [v2.11.1] CSP adapter update * Fix date typo in deprecated features table * [2.11.1] CNI community popularity table * [v2.11.1] (zh) webhook update * [v2.11.1] (zh) CSP adapter update * [v2.11.1] (zh) deprecated features update * [2.11.1] Update date and sync to zh Also remove duplicate file --------- Co-authored-by: Billy Tat <btat@suse.com>
Merge release branch v2.10.5 into main (#1752 )
2026-09-29 22:49:17 +00:00 · 2025-04-24 17:04:36 -07:00 · 2025-04-24 17:04:16 -07:00 · 2025-04-24 17:03:32 -07:00 · 2025-04-24 17:03:17 -07:00 · 2025-04-23 16:24:41 -07:00
1818 changed files with 151780 additions and 4222 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:
@@ -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
    ```

@@ -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
--- a/Show More
+++ b/Show More