Merge pull request #2127 from rancher/v2.13.1

Merge release v2.13.1 into main
Merge pull request #2126 from rancher/v2.12.5
2026-09-29 06:29:34 +00:00 · 2025-12-18 19:28:07 -08:00 · 2025-12-18 19:27:48 -08:00 · 2025-12-18 19:27:32 -08:00 · 2025-12-18 18:03:09 +01:00 · 2025-12-18 18:02:29 +01:00
990 changed files with 103902 additions and 481 deletions
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -0,0 +1,320 @@
+#!/bin/bash
+
+# backport_docs.sh
+#
+# A script to backport changes (added, modified, and removed files)
+# from 'docs/' and 'sidebars.js' to their versioned counterparts.
+
+# --- Configuration ---
+DOCS_DIR="docs"
+VERSIONED_DIR="versioned_docs"
+SIDEBARS_SOURCE_FILE="sidebars.js"
+SIDEBARS_VERSIONED_DIR="versioned_sidebars"
+
+# --- Colors ---
+GREEN="\033[0;32m"
+RED="\033[0;31m"
+YELLOW="\033[0;33m"
+BLUE="\033[0;34m"
+RESET="\033[0m"
+
+# --- Help Message ---
+usage() {
+    echo -e "${GREEN}Usage:${RESET} $0 [version1] [version2] ..."
+    echo
+    echo -e "${YELLOW}Description:${RESET}"
+    echo "  Backports changes (added, modified, removed) from the '$DOCS_DIR/' directory"
+    echo "  and modifications from '$SIDEBARS_SOURCE_FILE' to specified versioned directories."
+    echo
+    echo -e "${YELLOW}Arguments:${RESET}"
+    echo "  [version]   (Optional) One or more specific versions to backport to."
+    echo "              If no versions are provided, the script attempts to backport"
+    echo "              to all valid versions found in '$VERSIONED_DIR/'."
+    echo
+    echo -e "${YELLOW}Options:${RESET}"
+    echo "  -h, --help  Show this help message."
+    echo
+    echo -e "${YELLOW}Example (all versions):${RESET}"
+    echo "  $0"
+    echo
+    echo -e "${YELLOW}Example (specific versions):${RESET}"
+    echo "  $0 version-2.12 version-2.13"
+}
+
+# --- Argument Parsing ---
+if [[ "$1" == "-h" || "$1" == "--help" ]]; then
+    usage
+    exit 0
+fi
+
+TARGET_VERSIONS=("$@")
+
+# --- Sanity Checks ---
+if [ ! -d "$DOCS_DIR" ]; then
+    echo -e "${RED}Error:${RESET} Directory '$DOCS_DIR' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+if [ ! -d "$VERSIONED_DIR" ]; then
+    echo -e "${RED}Error:${RESET} Directory '$VERSIONED_DIR' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+if [ ! -f "$SIDEBARS_SOURCE_FILE" ]; then
+    echo -e "${RED}Error:${RESET} Source file '$SIDEBARS_SOURCE_FILE' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+if [ ! -d "$SIDEBARS_VERSIONED_DIR" ]; then
+    echo -e "${RED}Error:${RESET} Directory '$SIDEBARS_VERSIONED_DIR' not found."
+    echo "Please run this script from the repository root."
+    exit 1
+fi
+
+# --- Validate Provided Versions ---
+# This block only runs if arguments were passed
+if [ ${#TARGET_VERSIONS[@]} -gt 0 ]; then
+    echo -e "${BLUE}Validating provided versions...${RESET}"
+    for version in "${TARGET_VERSIONS[@]}"; do
+        # Fail if the argument looks like an option (starts with -)
+        if [[ "$version" == -* ]]; then
+            echo -e "${RED}Error:${RESET} Unknown option '$version'."
+            echo "Use -h or --help for usage."
+            exit 1
+        fi
+        
+        if [ ! -d "$VERSIONED_DIR/$version" ]; then
+            echo -e "${RED}Error:${RESET} Provided version '$version' is not a valid directory under '$VERSIONED_DIR/'."
+            exit 1
+        fi
+    done
+    echo -e "${GREEN}All provided versions are valid.${RESET}"
+    echo # Newline
+fi
+
+# --- Find Target Versions (if not specified) ---
+# This block only runs if NO arguments were passed
+if [ ${#TARGET_VERSIONS[@]} -eq 0 ]; then
+    echo -e "${BLUE}No versions specified. Detecting all valid versions in '$VERSIONED_DIR'...${RESET}"
+    # Find all subdirectories
+    for dir in "$VERSIONED_DIR"/*/; do
+        # Check if the directory exists and is a directory
+        if [ -d "$dir" ]; then
+            # Check if the directory contains any file *other* than notice.md
+            # We use -print -quit to stop find immediately after the first match
+            if find "$dir" -type f -not -name "notice.md" -print -quit | grep -q .; then
+                # It's a valid version, add its basename
+                TARGET_VERSIONS+=("$(basename "$dir")")
+            fi
+        fi
+    done
+fi
+
+if [ ${#TARGET_VERSIONS[@]} -eq 0 ]; then
+    echo -e "${RED}Error:${RESET} No target versions found or specified."
+    exit 1
+fi
+
+echo -e "${GREEN}Target versions:${RESET} ${TARGET_VERSIONS[*]}"
+echo # Newline
+
+# --- Find Files to Backport (Docs) ---
+echo -e "${BLUE}Finding modified/new/removed files in '$DOCS_DIR'...${RESET}"
+# Find staged (cached) and unstaged (HEAD) changes (Added, Modified, or Deleted)
+FILES_TO_BACKPORT=$( (git diff --name-only --diff-filter=AMD HEAD -- "$DOCS_DIR"; \
+                       git diff --name-only --diff-filter=AMD --cached -- "$DOCS_DIR") \
+                       | sort -u)
+
+if [ -z "$FILES_TO_BACKPORT" ]; then
+    echo -e "${GREEN}No modified, new, or removed files found in '$DOCS_DIR'. Nothing to do.${RESET}"
+else
+    echo -e "${GREEN}Files to backport:${RESET}"
+    echo -e "${FILES_TO_BACKPORT}"
+    echo # Newline
+
+    # --- Main Logic (Docs) ---
+    echo -e "${BLUE}Starting backport process for docs...${RESET}"
+
+    # Use 'read' to handle file paths
+    echo "$FILES_TO_BACKPORT" | while IFS= read -r file; do
+        if [ -z "$file" ]; then # Skip empty lines
+            continue
+        fi
+
+        echo -e "${YELLOW}Processing file:${RESET} $file"
+
+        # Get the relative path inside 'docs/'
+        # e.g., 'docs/guides/intro.md' -> 'guides/intro.md'
+        REL_PATH="${file#$DOCS_DIR/}"
+        if [ "$REL_PATH" == "$file" ]; then
+            echo -e "  ${RED}Error:${RESET} Could not determine relative path for '$file'. Skipping."
+            continue
+        fi
+
+        # Check if the file exists in the source.
+        # If it does, it's ADDED or MODIFIED.
+        # If it doesn't, it's DELETED.
+        if [ -f "$file" ]; then
+            # --- LOGIC FOR ADDED/MODIFIED FILES ---
+            
+            PATCH_DATA_STAGED=$(git diff --cached -- "$file")
+            PATCH_DATA_UNSTAGED=$(git diff -- "$file")
+
+            # Loop through each target version
+            for version in "${TARGET_VERSIONS[@]}"; do
+                TARGET_FILE="$VERSIONED_DIR/$version/$REL_PATH"
+                TARGET_DIR=$(dirname "$TARGET_FILE")
+
+                # Check if the target *versioned file* exists
+                if [ ! -f "$TARGET_FILE" ]; then
+                    # File doesn't exist in the versioned directory.
+                    # This is a NEW file. Copy it directly.
+                    echo -e "  ${BLUE}Backporting as new file to version:${RESET} $version"
+                    # Ensure target directory exists
+                    mkdir -p "$TARGET_DIR"
+                    if [ $? -ne 0 ]; then
+                        echo -e "    ${RED}Error:${RESET} Could not create directory '$TARGET_DIR'. Skipping."
+                        continue
+                    fi
+                    # Copy the new file
+                    cp "$file" "$TARGET_FILE"
+                    if [ $? -eq 0 ]; then
+                        echo -e "    ${GREEN}Copied:${RESET} $file -> $TARGET_FILE"
+                    else
+                        echo -e "    ${RED}Error:${RESET} Failed to copy '$file' to '$TARGET_FILE'."
+                    fi
+                else
+                    # File *does* exist. Patch it using the deltas.
+                    echo -e "  ${BLUE}Backporting changes to version:${RESET} $version"
+                    
+                    patch_applied=false
+                    patch_failed=false
+
+                    if [ -n "$PATCH_DATA_STAGED" ]; then
+                        echo "$PATCH_DATA_STAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+                        if [ $? -eq 0 ]; then
+                            echo -e "    ${GREEN}Patched (staged):${RESET} $TARGET_FILE"
+                            patch_applied=true
+                        else
+                            echo -e "    ${RED}Error (staged):${RESET} Failed to patch '$TARGET_FILE'."
+                            patch_failed=true
+                        fi
+                    fi
+
+                    if [ -n "$PATCH_DATA_UNSTAGED" ]; then
+                        echo "$PATCH_DATA_UNSTAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+                        if [ $? -eq 0 ]; then
+                            echo -e "    ${GREEN}Patched (unstaged):${RESET} $TARGET_FILE"
+                            patch_applied=true
+                        else
+                            echo -e "    ${RED}Error (unstaged):${RESET} Failed to patch '$TARGET_FILE'."
+                            patch_failed=true
+                        fi
+                    fi
+
+                    if [ "$patch_failed" = true ]; then
+                        echo -e "    ${YELLOW}Tip:${RESET} This file may have diverged. Please review manually."
+                    elif [ "$patch_applied" = false ]; then
+                        echo -e "    ${GREEN}Skipped:${RESET} $TARGET_FILE (already in sync)"
+                    fi
+                fi
+            done # end version loop
+        
+        else
+            # --- LOGIC FOR DELETED FILES ---
+            echo -e "  ${BLUE}File was deleted. Propagating deletion...${RESET}"
+
+            # Loop through each target version
+            for version in "${TARGET_VERSIONS[@]}"; do
+                TARGET_FILE="$VERSIONED_DIR/$version/$REL_PATH"
+                
+                if [ -f "$TARGET_FILE" ]; then
+                    rm "$TARGET_FILE"
+                    if [ $? -eq 0 ]; then
+                        echo -e "    ${GREEN}Deleted:${RESET} $TARGET_FILE"
+                    else
+                        echo -e "    ${RED}Error:${RESET} Failed to delete '$TARGET_FILE'."
+                    fi
+                else
+                    echo -e "    ${GREEN}Skipped:${RESET} $TARGET_FILE (already deleted)"
+                fi
+            done # end version loop
+        fi # end add/modify/delete check
+
+        echo # Add a newline for readability
+    done # end file loop
+fi
+
+echo # Newline
+
+# --- Main Logic (Sidebars) ---
+echo -e "${BLUE}Checking for sidebars changes...${RESET}"
+
+# Check for staged or unstaged MODIFICATIONS to the source sidebars file
+# We only care about modifications (M), not additions or deletions.
+SIDEBARS_CHANGED=$( (git diff --name-only --diff-filter=M HEAD -- "$SIDEBARS_SOURCE_FILE"; \
+                     git diff --name-only --diff-filter=M --cached -- "$SIDEBARS_SOURCE_FILE") \
+                     | sort -u)
+
+if [ -z "$SIDEBARS_CHANGED" ]; then
+    echo -e "${GREEN}No modifications found in '$SIDEBARS_SOURCE_FILE'. Skipping sidebars backport.${RESET}"
+else
+    echo -e "${YELLOW}Processing file:${RESET} $SIDEBARS_SOURCE_FILE"
+    
+    # Get the patch data for STAGED changes (vs. HEAD)
+    PATCH_DATA_STAGED=$(git diff --cached -- "$SIDEBARS_SOURCE_FILE")
+    # Get the patch data for UNSTAGED changes (vs. Index)
+    PATCH_DATA_UNSTAGED=$(git diff -- "$SIDEBARS_SOURCE_FILE")
+
+    for version in "${TARGET_VERSIONS[@]}"; do
+
+        # The $version variable already contains "version-X.Y"
+        TARGET_FILE="$SIDEBARS_VERSIONED_DIR/${version}-sidebars.json"
+
+        # Check if the corresponding versioned sidebars file exists
+        if [ ! -f "$TARGET_FILE" ]; then
+            echo -e "  ${YELLOW}Skipped:${RESET} $TARGET_FILE (not found)"
+            continue
+        fi
+
+        echo -e "  ${BLUE}Backporting changes to:${RESET} $TARGET_FILE"
+        
+        patch_applied=false
+        patch_failed=false
+
+        if [ -n "$PATCH_DATA_STAGED" ]; then
+            echo "$PATCH_DATA_STAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+            if [ $? -eq 0 ]; then
+                echo -e "    ${GREEN}Patched (staged):${RESET} $TARGET_FILE"
+                patch_applied=true
+            else
+                echo -e "    ${RED}Error (staged):${RESET} Failed to patch '$TARGET_FILE'."
+                patch_failed=true
+            fi
+        fi
+
+        if [ -n "$PATCH_DATA_UNSTAGED" ]; then
+            echo "$PATCH_DATA_UNSTAGED" | patch --no-backup "$TARGET_FILE" - > /dev/null 2>&1
+            if [ $? -eq 0 ]; then
+                echo -e "    ${GREEN}Patched (unstaged):${RESET} $TARGET_FILE"
+                patch_applied=true
+            else
+                echo -e "    ${RED}Error (unstaged):${RESET} Failed to patch '$TARGET_FILE'."
+                patch_failed=true
+            fi
+        fi
+
+        if [ "$patch_failed" = true ]; then
+            echo -e "    ${YELLOW}Tip:${RESET} This file may have diverged. Please review manually."
+        elif [ "$patch_applied" = false ]; then
+            echo -e "    ${GREEN}Skipped:${RESET} $TARGET_FILE (already in sync)"
+        fi
+        echo # Add a newline
+    done # end version loop
+fi
+
+echo # Newline
+echo -e "${GREEN}Backport complete.${RESET}"
@@ -15,4 +15,4 @@ At this time, not all Rancher resources are available through the Rancher Kubern

 import ApiDocMdx from '@theme/ApiDocMdx';

-<ApiDocMdx id="rancher-api-v2-12" />
+<ApiDocMdx id="rancher-api-v2-13" />
@@ -60,17 +60,23 @@ This feature affects all tokens which include, but are not limited to, the follo

 These global settings affect Rancher token behavior.

-| Setting                                                                         | Description                                                                                                                                                                                                                    |
-| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes)               | TTL in minutes on a user auth session token.                                                                                                                                                                                   |
-| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs).                                                 |
-| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes)                     | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes).                                                                                                           |
-| [`kubeconfig-generate-token`](#kubeconfig-generate-token)                       | If true, automatically generate tokens when a user downloads a kubeconfig.                                                                                                                                                     |
+| Setting | Description |
+| ------- | ----------- |
+| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | TTL in minutes on a user auth session token. |
+| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
+| [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) | Default TTL applied to all kubeconfig tokens except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). |
+| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | Max TTL for all tokens except those controlled by [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes). |
+| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | If true, automatically generate tokens when a user downloads a kubeconfig. |

 ### auth-user-session-ttl-minutes

 Time to live (TTL) duration in minutes, used to determine when a user auth session token expires. When expired, the user must log in and obtain a new token. This setting is not affected by [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). Session tokens are created when a user logs into Rancher.

+### auth-user-session-idle-ttl-minutes
+
+Time to live (TTL) without user activity for login sessions tokens, in minutes.
+By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
+
 ### kubeconfig-default-token-ttl-minutes

 Time to live (TTL) duration in minutes, used to determine when a kubeconfig token expires. When the token is expired, the API rejects the token. This setting can't be larger than [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes). This setting applies to tokens generated in a requested kubeconfig file, except for tokens [generated by Rancher CLI](#disable-tokens-in-generated-kubeconfigs). As of Rancher v2.8, the default duration is `43200`, which means that tokens expire in 30 days.
@@ -20,14 +20,6 @@ To get a description of the fields and structure of the Kubeconfig resource, run
 kubectl explain kubeconfigs.ext.cattle.io
 ```

-## Feature Flag
-
-The Kubeconfigs Public API is available since Rancher v2.12.0 and is enabled by default. It can be disabled by setting the `ext-kubeconfigs` feature flag to `false`.
-
-```sh
-kubectl patch feature ext-kubeconfigs -p '{"spec":{"value":false}}'
-```
-
 ## Creating a Kubeconfig

 Only a **valid and active** Rancher user can create a Kubeconfig. For example, trying to create a Kubeconfig using a `system:admin` service account will lead to an error:
@@ -25,11 +25,15 @@ spec:
 EOF
 ```

-Use `metadata.generateName` to ensure a unique project ID, but note that `kubectl apply` does not work with `metadata.generateName`, so `kubectl create` must be used instead.
+When creating a new project, you have two primary options for setting the name:
+
+- **Automatic Generation:** Use `metadata.generateName` to ensure a unique project ID. However, note that you must use `kubectl create` (instead of `kubectl apply`) with this option, as `kubectl apply` does not support it.
+- **Manual Naming:** You can explicitly set the project ID using `metadata.name`. If a project with that exact name already exists, the name request is denied.
+The display name seen in the UI is set by `spec.displayName`. If `spec.displayName` is not provided, the field `metadata.name` is used instead.

 Set `metadata.namespace` and `spec.clusterName` to the ID for the cluster the project belongs to.

-If you create a project through a cluster member account, you must include the annotation, `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.
+If you create a project through a cluster member account and want that account to be able to access the project, you must include the annotation `field.cattle.io/creatorId`, and set it to the cluster member account's user ID.

 ```bash
 kubectl create -f - <<EOF
@@ -37,8 +41,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -47,7 +50,7 @@ spec:
 EOF
 ```

-Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
+Setting the `field.cattle.io/creatorId` field creates a `ProjectRoleTemplateBinding` that grants the specified user the ability to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.

 Setting the  `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.

@@ -98,9 +101,13 @@ spec:
 EOF
 ```

+### Backing Namespace
+
+After creating the project, the field `status.backingNamespace` gets populated. This represents the namespace in the management cluster that is created to manage project related resources. Examples of resources stored in the backing namespace are [project scoped secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) and [project role template bindings](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles).
+
 ## Adding a Member to a Project

-Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
+Look up the project's [backing namespace](#backing-namespace) to specify the `metadata.namespace` field value and look up the project's ID to specify the `projectName` field value.

 ```bash
 kubectl --namespace c-m-abcde get projects
@@ -120,7 +127,7 @@ apiVersion: management.cattle.io/v3
 kind: ProjectRoleTemplateBinding
 metadata:
  generateName: prtb-
-  namespace: p-vwxyz
+  namespace: c-m-abcde-p-vwxyz
 projectName: c-m-abcde:p-vwxyz
 roleTemplateName: project-member
 userPrincipalName: keycloak_user://user
@@ -146,16 +153,16 @@ Create a projectroletemplatebinding for each role you want to assign to the proj

 ## Listing Project Members

-Look up the project ID:
+Look up the project backing namespace:

 ```bash
 kubectl --namespace c-m-abcde get projects
 ```

-to list projectroletemplatebindings in the project's namespace:
+To list projectroletemplatebindings in the project's backing namespace:

 ```bash
-kubectl --namespace p-vwxyz get projectroletemplatebindings
+kubectl --namespace c-m-abcde-p-vwxyz get projectroletemplatebindings
 ```

 ## Deleting a Member From a Project
@@ -165,14 +172,14 @@ Lookup the projectroletemplatebinding IDs containing the member in the project's
 Delete the projectroletemplatebinding from the project's namespace:

 ```bash
-kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
+kubectl --namespace c-m-abcde-p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
 ```

 ## Creating a Namespace in a Project

 The Project resource resides in the management cluster, even if the Project is for a managed cluster. The namespaces under the project reside in the managed cluster.

-On the management cluster, look up the project ID for the cluster you are administrating since it generated using `metadata.generateName`:
+On the management cluster, look up the project ID for the cluster you are administrating if generated using `metadata.generateName`:

 ```bash
 kubectl --namespace c-m-abcde get projects
@@ -208,3 +215,5 @@ kubectl --namespace c-m-abcde delete project p-vwxyz
 ```

 Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
+
+It does delete all project role template bindings for the projects, so recreating the project will not restore members added to the project, and you have to add users as members again.
@@ -20,20 +20,14 @@ To get a description of the fields and structure of the Token resource, run:
 kubectl explain tokens.ext.cattle.io
 ```

-## Feature Flag
-
-The Tokens Public API is available for Rancher v2.12.0 and later, and is enabled by default. You can disable the Tokens Public API by setting the `ext-tokens` feature flag to `false` as shown in the example `kubectl` command below:
-
-```sh
-kubectl patch feature ext-tokens -p '{"spec":{"value":false}}'
-```
-
 ## Creating a Token

 :::caution
 The Token value is only returned once in the `status.value` field.
 :::

+Since Rancher v2.13.0 the `status.bearerToken` now contains a fully formed and ready-to-use Bearer token that can be used to authenticate to [Rancher API](../v3-rancher-api-guide.md).
+
 Only a **valid and active** Rancher user can create a Token. Otherwise, you will get an error displayed (`Error from server (Forbidden)...`) when attempting to create a Token.

 ```bash
@@ -0,0 +1,187 @@
+---
+title: Users
+---
+
+## User Resource
+
+The `User` resource (users.management.cattle.io) represents a user account in Rancher.
+
+To get a description of the fields and structure of the `User` resource, run:
+
+```sh
+kubectl explain users.management.cattle.io
+```
+
+## Creating a User
+
+Creating a local user is a two-step process: you must create the `User` resource, then provide a password via a Kubernetes `Secret`.
+
+Only a user with sufficient permissions can create a `User` resource.
+
+```bash
+kubectl create -f -<<EOF
+apiVersion: management.cattle.io/v3
+kind: User
+metadata:
+ name: testuser     
+displayName: "Test User"             
+username: "testuser"
+EOF
+```
+The user's password must be provided in a `Secret` object within the `cattle-local-user-passwords` namespace. The Rancher webhook will automatically hash the password and update the `Secret`.
+
+:::important
+
+Important: The `Secret` must have the same name as the metadata.name (and username) of the `User` resource. 
+
+:::
+
+```bash
+kubectl create -f -<<EOF
+apiVersion: v1
+kind: Secret
+metadata:
+ name: testuser
+ namespace: cattle-local-user-passwords
+type: Opaque
+stringData:
+ password: Pass1234567!
+EOF
+```
+
+After the plaintext password is submitted, the Rancher-Webhook automatically hashes it, replacing the content of the `Secret`, ensuring that the plaintext password is never stored:
+
+```yaml
+apiVersion: v1
+data:
+  password: 1c1Y4CdjlehGWFz26F414x2qoj4gch5L5OXsx35MAa8=
+  salt: m8Co+CfMDo5XwVl0FqYzGcRIOTgRrwFSqW8yurh5DcE=
+kind: Secret
+metadata:
+  annotations:
+    cattle.io/password-hash: pbkdf2sha3512
+  name: testuser
+  namespace: cattle-local-user-passwords
+  ownerReferences:
+  - apiVersion: management.cattle.io/v3
+    kind: User
+    name: testuser
+    uid: 663ffb4f-8178-46c8-85a3-337f4d5cbc2e
+  uid: bade9f0a-b06f-4a77-9a39-4284dc2349c5
+type: Opaque
+```
+
+## Updating User's Password
+
+To change a user's password, use the `PasswordChangeRequest` resource, which handles secure password updates.
+
+```yaml
+kubectl create  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: PasswordChangeRequest
+spec:
+  userID: "testuser"
+  currentPassword: "Pass1234567!"
+  newPassword: "NewPass1234567!"
+EOF
+```
+
+## Listing Users
+
+List all `User` resources in the cluster:
+
+```sh
+kubectl get users
+NAME           AGE
+testuser       3m54s
+user-4n5ws     12m
+```
+
+## Viewing a User
+
+View a specific `User` resource by name:
+
+```sh
+kubectl get user testuser
+NAME           AGE
+testuser       3m54s
+```
+
+## Deleting a User
+
+Deleting a user will automatically delete the corresponding password `Secret`.
+
+```sh
+kubectl delete user testuser
+user.management.cattle.io "testuser" deleted
+```
+
+## Get a Current User's Information
+
+A client uses the `SelfUser` resource to retrieve information about the currently authenticated user without knowing their ID. The user ID is returned in the `.status.userID` field.
+
+```bash
+kubectl create -o jsonpath='{.status.userID}'  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: SelfUser
+EOF
+
+testuser
+```
+
+## Refreshing a User's Group Membership
+
+Updates to user group memberships are triggered by the `GroupMembershipRefreshRequest` resource.
+
+:::note
+Group membership is only supported for external authentication providers.
+:::
+
+### For a Single User
+
+```bash
+kubectl create -o jsonpath='{.status}'  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: GroupMembershipRefreshRequest
+spec:
+  userId: testuser
+EOF
+
+{
+    "conditions": [
+        {
+            "lastTransitionTime": "2025-11-10T12:01:03Z",
+            "message": "",
+            "reason": "",
+            "status": "True",
+            "type": "UserRefreshInitiated"
+        }
+    ],
+    "summary": "Completed"
+}
+```
+
+### For All Users
+
+```bash
+
+kubectl create -o jsonpath='{.status}'  -f -<<EOF
+apiVersion: ext.cattle.io/v1
+kind: GroupMembershipRefreshRequest
+spec:
+   userId: "*"
+EOF
+
+{
+    "conditions": [
+        {
+            "lastTransitionTime": "2025-11-10T12:01:59Z",
+            "message": "",
+            "reason": "",
+            "status": "True",
+            "type": "UserRefreshInitiated"
+        }
+    ],
+    "summary": "Completed"
+}
+```
@@ -16,10 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://

 | Patch Version |  Release Date |
 |---------------|---------------|
-| [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | October 23, 2025 |
-| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | September 25, 2025 |
-| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | August 28, 2025 |
-| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | July 30, 2025 |
+| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | December 18, 2025 |
+| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | November 25, 2025 |

 ## What can I expect when a feature is marked for deprecation?

@@ -18,7 +18,7 @@ Some feature flags require a restart of the Rancher container. Features that req

 The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)):

- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [Cluster Role Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation.md) for more information.
+- `aggregated-roletemplates`: Use cluster role aggregation architecture for RoleTemplates, ProjectRoleTemplateBindings, and ClusterRoleTemplateBindings. See [RoleTemplate Aggregation](../../../how-to-guides/advanced-user-guides/enable-experimental-features/role-template-aggregation.md) for more information.
 - `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
 - `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
 - `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
@@ -61,7 +61,7 @@ The following table shows the availability and default values for some feature f

 | Feature Flag Name             | Default Value | Status       | Available As Of | Additional Information |
 | ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
-| `aggregated-roletemplates` | `Disabled` | Highly experimental | v2.11.0 | This flag value is locked on install and can't be changed. |
+| `aggregated-roletemplates` | `Disabled` | Experimental | v2.11.0 | This flag value is locked on install and can't be changed. |
 | `clean-stale-secrets` | `Active` | GA | v2.10.2 | |
 | `continuous-delivery` | `Active` | GA | v2.6.0 | |
 | `external-rules` | v2.7.14: `Disabled`, v2.8.5: `Active` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
@@ -6,4 +6,4 @@ title: Installation References
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references"/>
 </head>

-Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
+Please see the following reference guides for other installation resources: [Rancher Helm chart options](helm-chart-options.md), [TLS settings](tls-settings.md), and [feature flags](feature-flags.md).
@@ -25,10 +25,16 @@ Rancher needs to be installed on a supported Kubernetes version. Consult the [Ra

 Regardless of version and distribution, the Kubernetes cluster must have the aggregation API layer properly configured to support the [extension API](../../../api/extension-apiserver.md) used by Rancher.

-### Install Rancher on a Hardened Kubernetes cluster
+### Install Rancher on a Hardened Kubernetes Cluster

 If you install Rancher on a hardened Kubernetes cluster, check the [Exempting Required Rancher Namespaces](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#exempting-required-rancher-namespaces) section for detailed requirements.

+### Install Rancher on an IPv6-only or Dual-stack Kubernetes Cluster
+
+You can deploy Rancher on an IPv6-only or dual-stack Kubernetes cluster.
+
+For details on Rancher’s IPv6-only and dual-stack support, see the [IPv4/IPv6 Dual-stack](../../../reference-guides/dual-stack.md) page.
+
 ## Operating Systems and Container Runtime Requirements

 All supported operating systems are 64-bit x86. Rancher should work with any modern Linux distribution.
@@ -238,21 +238,23 @@ In these cases, you have to explicitly allow this traffic in your host firewall,

 When using the [AWS EC2 node driver](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) to provision cluster nodes in Rancher, you can choose to let Rancher create a security group called `rancher-nodes`. The following rules are automatically added to this security group.

-|       Type      | Protocol |  Port Range | Source/Destination     | Rule Type |
+| Type            | Protocol | Port Range  | Source/Destination     | Rule Type |
 |-----------------|:--------:|:-----------:|------------------------|:---------:|
-|       SSH       |    TCP   | 22          | 0.0.0.0/0              | Inbound   |
-|       HTTP      |    TCP   | 80          | 0.0.0.0/0              | Inbound   |
-| Custom TCP Rule |    TCP   | 443         | 0.0.0.0/0              | Inbound   |
-| Custom TCP Rule |    TCP   | 2376        | 0.0.0.0/0              | Inbound   |
-| Custom TCP Rule |    TCP   | 2379-2380   | sg-xxx (rancher-nodes) | Inbound   |
-| Custom UDP Rule |    UDP   | 4789        | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 6443        | 0.0.0.0/0              | Inbound   |
-| Custom UDP Rule |    UDP   | 8472        | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 10250-10252 | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 10256       | sg-xxx (rancher-nodes) | Inbound   |
-| Custom TCP Rule |    TCP   | 30000-32767 | 0.0.0.0/0              | Inbound   |
-| Custom UDP Rule |    UDP   | 30000-32767 | 0.0.0.0/0              | Inbound   |
-| All traffic     |    All   | All         | 0.0.0.0/0              | Outbound  |
+| SSH             |   TCP    |     22      | 0.0.0.0/0 and ::/0     |  Inbound  |
+| HTTP            |   TCP    |     80      | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |     443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    2376     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |    6443     | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom TCP Rule |   TCP    |     179     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    9345     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |  2379-2380  | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    | 10250-10252 | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    |    10256    | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom UDP Rule |   UDP    |    4789     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom UDP Rule |   UDP    |    8472     | sg-xxx (rancher-nodes) |  Inbound  |
+| Custom TCP Rule |   TCP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
+| Custom UDP Rule |   UDP    | 30000-32767 | 0.0.0.0/0 and ::/0     |  Inbound  |
+| All traffic     |   All    |     All     | 0.0.0.0/0 and ::/0     | Outbound  |

 ### Opening SUSE Linux Ports

@@ -42,8 +42,24 @@ kubectl -n cattle-system create secret generic tls-ca \

 The configured `tls-ca` secret is retrieved when Rancher starts. On a running Rancher installation the updated CA will take effect after new Rancher pods are started.

+The certificate chain must be properly formatted, or components may fail to download resources from the Rancher server. 
+
 :::

+## Adding Additional CA Certificates
+
+If you are using a node driver that makes API requests with a different CA than the one configured for Rancher, you can add additional root certificates and certificate chains. 
+
+Create a unique file ending in `.pem` for each certificate that is required, and use kubectl to create the 
+`tls-additional` secret in the `cattle-system` namespace.
+
+```console
+kubectl -n cattle-system create secret generic tls-additional \
+  --from-file=cacerts1.pem=cacerts1.pem --from-file=cacerts2.pem=cacerts2.pem
+```
+
+Rancher mounts these CA root certificates and certificate chains into the node driver pod during provisioning.
+
 ## Updating a Private CA Certificate

 Follow the steps on [this page](update-rancher-certificate.md) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) or to switch from the default self-signed certificate to a custom certificate.
@@ -1,19 +0,0 @@
---
-title: ClusterRole Aggregation
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/cluster-role-aggregation"/>
-</head>
-
-:::caution
-ClusterRole aggregation is a highly experimental feature that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. This feature is meant exclusively for internal testing in v2.11 and v2.12. It is expected to be available as a beta for users in v2.13.
-:::
-
-ClusterRole aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
-
-| Environment Variable Key | Default Value | Description |
-| --- | --- | --- |
-| `aggregated-roletemplates` | `false` | [Experimental] Make RoleTemplates use aggregation for generated RBAC roles. |
-
-The value of this feature flag is locked on installation, which shows up in the UI as a lock symbol beside the feature flag. That means the feature can only be set on the first ever installation of Rancher. After that, attempting to modify the value will be denied.
@@ -0,0 +1,21 @@
+---
+title: RoleTemplate Aggregation
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/role-template-aggregation"/>
+</head>
+
+:::caution
+RoleTemplate aggregation is an experimental feature in v2.13 that changes the RBAC architecture used for RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings. **It is not supported for production environments**. Breaking changes may occur between v2.13 and v2.14.
+:::
+
+RoleTemplate aggregation implements RoleTemplates, ClusterRoleTemplateBindings and ProjectRoleTemplateBindings using the Kubernetes feature [Aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles). The new architecture results in a net reduction in RBAC objects (Roles, RoleBindings, ClusterRoles and ClusterRoleBindings) both in the Rancher cluster and the downstream clusters.
+
+For more information on how the feature can improve scalability and performance, please see the [Rancher Blog post](https://www.suse.com/c/rancher_blog/fewer-bindings-more-power-ranchers-rbac-boost-for-enhanced-performance-and-scalability/).
+
+| Environment Variable Key | Default Value | Description |
+| --- | --- | --- |
+| `aggregated-roletemplates` | `false` | [Beta] Make RoleTemplates use aggregation for generated RBAC roles. |
+
+The value of this feature flag is locked on installation, which shows up in the UI as a lock symbol beside the feature flag. That means the feature can only be set on the first ever installation of Rancher. After that, attempting to modify the value will be denied.
@@ -58,3 +58,7 @@ if the user has not yet logged in to Rancher. However, if the user has previousl
 ### You are not redirected to your authentication provider

 If you fill out the **Configure an Amazon Cognito account** form and click on **Enable**, and you are not redirected to Amazon Cognito, verify your Amazon Cognito configuration.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -363,3 +363,22 @@ Since the filter prevents Rancher from seeing that the user belongs to an exclud
 >- If you don't wish to upgrade to v2.7.0+ after the Azure AD Graph API is retired, you'll need to either:
    - Use the built-in Rancher auth or
    - Use another third-party auth system and set that up in Rancher. Please see the [authentication docs](authentication-config.md) to learn how to configure other open authentication providers.
+
+## Azure AD Roles Claims
+
+Rancher supports the Roles claim provided by the Azure AD OIDC provider token, allowing for complete delegation of Role-Based Access Control (RBAC) to Azure AD. Previously, Rancher only processed the `Groups` claim to determine a user's `group` membership. This enhancement extends the logic to also include the Roles claim within the user's OIDC token.
+
+By including the Roles claim, administrators can:
+
+- Define specific high-level roles in Azure AD.
+- Bind these Azure AD Roles directly to ProjectRoles or ClusterRoles within Rancher.
+- Centralize and fully delegate access control decisions to the external OIDC provider.
+
+For example, consider the following role structure in Azure AD:
+
+| Azure AD Role Name | Members        |
+|--------------------|----------------|
+| project-alpha-dev  | User A, User C |
+
+
+User A logs into Rancher via Azure AD. The OIDC token includes a Roles claim, [`project-alpha-dev`]. The Rancher logic processes the token, and the internal list of `groups`/roles for User A which includes `project-alpha-dev`. An administrator has created a Project Role Binding that maps the Azure AD Role `project-alpha-dev` to the Project Role `Dev Member` for Project Alpha. User A is automatically granted the `Dev Member` role in Project Alpha.
@@ -7,60 +7,69 @@ description: Create an OpenID Connect (OIDC) client and configure Rancher to wor
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-generic-oidc"/>
 </head>

-If your organization uses an OIDC provider for user authentication, you can configure Rancher to allow login using Identity Provider (IdP) credentials. Rancher supports integration with the OpenID Connect (OIDC) protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to configure Rancher to work using the OIDC protocol.
+Generic OpenID Connect (OIDC) allows users to sign in to Rancher using their credentials from their existing account at an OIDC Identity Provider (IdP). Rancher supports integration with the OIDC protocol and the SAML protocol. Both implementations are functionally equivalent when used with Rancher. The following instructions describe how to create an OIDC client and configure Rancher to work with your authentication provider. Users can then sign into Rancher using their login from the OIDC IdP.

 ## Prerequisites

- In Rancher:
-  - Generic OIDC is disabled.
+### Identity Provider
+
+In Rancher, Generic OIDC is disabled.

 :::note
+
 Consult the documentation for your specific IdP to complete the listed prerequisites.
+
 :::

- In your IdP:
-  - Create a new client with the settings below:
+#### OIDC Client
+
+In your IdP, create a new client with the settings below:
+
+  Setting | Value
+  ------------|------------
+  `Client ID` | <CLIENT_ID> (e.g. `rancher`)
+  `Name` | <CLIENT_NAME> (e.g. `rancher`)
+  `Client Protocol` | `openid-connect`
+  `Access Type` | `confidential`
+  `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
+
+In the new OIDC client, create mappers to expose the user's fields.
+
+  1. Create a new `Groups Mapper` with the settings below:

    Setting | Value
    ------------|------------
-    `Client ID` | <CLIENT_ID> (e.g. `rancher`)
-    `Name` | <CLIENT_NAME> (e.g. `rancher`)
-    `Client Protocol` | `openid-connect`
-    `Access Type` | `confidential`
-    `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth`
+    `Name` | `Groups Mapper`
+    `Mapper Type` | `Group Membership`
+    `Token Claim Name` | `groups`
+    `Add to ID token` | `OFF`
+    `Add to access token` | `OFF`
+    `Add to user info` | `ON`

-  - In the new OIDC client, create mappers to expose the users fields.
-    - Create a new Groups Mapper with the settings below:
+  1. Create a new `Client Audience` with the settings below:

-      Setting | Value
-      ------------|------------
-      `Name` | `Groups Mapper`
-      `Mapper Type` | `Group Membership`
-      `Token Claim Name` | `groups`
-      `Add to ID token` | `OFF`
-      `Add to access token` | `OFF`
-      `Add to user info` | `ON`
+    Setting | Value
+    ------------|------------
+    `Name` | `Client Audience`
+    `Mapper Type` | `Audience`
+    `Included Client Audience` | `CLIENT_NAME`
+    `Add to access token` | `ON`

-    - Create a new Client Audience with the settings below:
+  1. Create a new `Groups Path` with the settings below.

-      Setting | Value
-      ------------|------------
-      `Name` | `Client Audience`
-      `Mapper Type` | `Audience`
-      `Included Client Audience` | <CLIENT_NAME>
-      `Add to access token` | `ON`
+    Setting | Value
+    ------------|------------
+    `Name` | `Group Path`
+    `Mapper Type` | `Group Membership`
+    `Token Claim Name` | `full_group_path`
+    `Full group path` | `ON`
+    `Add to user info` | `ON`

-    - Create a new "Groups Path" with the settings below.
+:::warning

-      Setting | Value
-      ------------|------------
-      `Name` | `Group Path`
-      `Mapper Type` | `Group Membership`
-      `Token Claim Name` | `full_group_path`
-      `Full group path` | `ON`
-      `Add to user info` | `ON`
+Rancher uses the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher.  It is important to make this a value that is unique and immutable.

- Important:  Rancher will use the value received in the "sub" claim to form the PrincipalID which is the unique identifier in Rancher.  It is important to make this a value that will be unique and immutable.
+:::

 ## Configuring Generic OIDC in Rancher

@@ -80,7 +89,31 @@ Consult the documentation for your specific IdP to complete the listed prerequis

 **Result:** Rancher is configured to work with your provider using the OIDC protocol. Your users can now sign into Rancher using their IdP logins.

-## Configuration Reference
+### Custom Claim Mapping
+
+Custom claim mapping within the Generic OIDC configuration is supported for `name`, `email` and `groups` claims. This allows you to manually map these OIDC claims when your IdP doesn't use standard names in tokens.
+
+#### How a Custom Groups Claim Works
+
+A custom groups claim influences how user groups work:
+
+- If both the standard OIDC `groups` claim and the custom groups claim are present in the user's token, the custom claim supplements the list of groups provided by the standard claim.
+- If there is no standard groups claim in the token, the groups listed in the custom claim will form the user's only groups.
+
+:::note
+There is no search functionality available for groups sourced from a custom claim. To assign a role to one of these groups, you must manually enter the group's exact name into the RBAC field.
+:::
+
+#### Configuring Custom Claims
+
+When on the **Configure an OIDC account** form:
+
+1. Select **Add custom claims**.
+1. Add your custom `name`, `email` or `groups` claims to the appropriate **Custom Claims** field.
+
+For example, if your IdP sends `groups` in a claim called `custom_roles`, enter `custom_roles` into the **Custom Groups Claim** field. Rancher then supplements the standard OIDC `groups` claim or looks for that specific claim when processing the user's token.
+
+### Configuration Reference

 | Field                     | Description                                                                                                                                        |
 | ------------------------- |----------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -91,6 +124,15 @@ Consult the documentation for your specific IdP to complete the listed prerequis
 | Rancher URL               | The URL for your Rancher Server.                                                                                                                   |
 | Issuer                    | The URL of your IdP.  If your provider has discovery enabled, Rancher uses the Issuer URL to fetch all of the required URLs.                   |
 | Auth Endpoint             | The URL where users are redirected to authenticate.                                                                                                |
+
+#### Custom Claims
+
+| Custom Claim Field | Default OIDC Claim | Custom Claim Description |
+| ------------- | ------------------ | ------------------------ |
+| Custom Name Claim | `name`           | The name of the claim in the OIDC token that contains the user's full name or display name. |
+| Custom Email Claim | `email` | The name of the claim in the OIDC token that contains the user's email address. |
+| Custom Groups Claim | `groups` | The name of the claim in the OIDC token that contains the user's group memberships (used for RBAC). |
+
 ## Troubleshooting

 If you are experiencing issues while testing the connection to the OIDC server, first double-check the configuration options of your OIDC client. You can also inspect the Rancher logs to help pinpoint what's causing issues. 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.
@@ -108,3 +150,7 @@ If the `Issuer` and `Auth Endpoint` are generated incorrectly, open the **Config
 ### Error: "Invalid grant_type"

 In some cases, the "Invalid grant_type" error message may be misleading and is actually caused by setting the `Valid Redirect URI` incorrectly.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -0,0 +1,84 @@
+---
+title: Configure GitHub App
+---
+
+<head> 
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-github-app"/>
+</head>
+
+In environments using GitHub, you can configure the new GitHub App authentication provider in Rancher, which allows users to authenticate against a GitHub Organization account using a dedicated [GitHub App](https://docs.github.com/en/apps/overview). This new provider runs alongside the existing standard GitHub authentication provider, offering increased security and better management of permissions based on GitHub Organization teams.
+
+## Prerequisites
+
+:::warning
+
+The GitHub App authentication provider only works with [GitHub Organization accounts](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#organization-accounts). It does not function with individual [GitHub User accounts](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#user-accounts).
+
+:::
+
+Before configuring the provider in Rancher, you must first create a GitHub App for your organization, generate a client secret for your GitHub App and generate a private key for your GitHub App. Refer to [Registering a GitHub App](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/registering-a-github-app) for details.
+
+### Create GitHub App
+
+1. Open your [GitHub organization settings](https://github.com/settings/organizations).
+1. To the right of the organization, select **Settings**.
+1. In the left sidebar, click **Developer settings** > **GitHub Apps**.
+1. Click **New Github App**.
+1. Fill in the GitHub App configuration form with these values:
+
+    - **GitHub App name**: Anything you like, e.g. `My Rancher`.
+    - **Application description**: Optional, can be left blank.
+    - **Homepage URL**: `https://localhost:8443`.
+    - **Callback URL**: `https://localhost:8443/verify-auth`.
+
+1. Select **Create Github App**.
+
+### Generate a Client Secret
+
+Generate a [client secret](https://docs.github.com/en/rest/authentication/authenticating-to-the-rest-api#using-basic-authentication) on the settings page for your app.
+
+1. Go to your GitHub App.
+1. Next to **Client Secrets**, select **Generate a new client secret**.
+
+### Generate a Private Key
+
+Generate a [private key](https://docs.github.com/en/enterprise-server/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#generating-private-keys) on the settings page for your app.
+
+1. Go to your GitHub App.
+1. Next to **Private Keys**, click **Generate a private key**.
+
+## GitHub App Auth Provider Configuration
+
+To set up the GitHub App Auth Provider in Rancher, follow these steps:
+
+1. Navigate to the **Users & Authentication** section in the Rancher UI.
+1. Select **Auth Providers**.
+1. Select the **GitHub App** tile.
+1. Gather and enter the details of your GitHub App into the configuration form fields.
+
+    | Field Name | Description |
+    | ---------- | ----------- |
+    | **Client ID** (Required) | The client ID of your GitHub App. |
+    | **Client Secret** (Required) | The client secret of your GitHub App. |
+    | **GitHub App ID** (Required) | The numeric ID associated with your GitHub App. |
+    | **Installation ID** (Optional) | If you want to restrict authentication to a single installation of the App, provide its specific numeric Installation ID. |
+    | **Private Key** (Required) | The contents of the Private Key file (in PEM format) generated by GitHub for your App. |
+
+  :::note
+
+  A GitHub App can be installed across multiple Organizations, and each installation has a unique Installation ID. If you want to restrict authentication to a single App installation and GitHub Organization, provide the Installation ID during configuration. If you do not provide an Installation ID, the user's permissions are aggregated across all installations.
+
+  :::
+
+1. Select **Enable**. Rancher attempts to validate the credentials and, upon success, activates the GitHub App provider.
+
+After it is enabled, users logging in via the GitHub App provider are automatically identified and you can leverage your GitHub Organization's teams and users to configure Role-Based Access Control (RBAC) and to assign permissions to projects and clusters.
+
+:::note
+
+Ensure that the users and teams you intend to use for authorization exist within the GitHub organization managed by the App.
+
+:::
+
+- **Users**: Individual GitHub users who are members of the GitHub Organization where the App is installed can log in.
+- **Groups**: GitHub Organization teams are mapped to Rancher Groups, allowing you to assign entire teams permissions within Rancher projects and clusters.
@@ -203,3 +203,7 @@ To resolve this, you can either:
    3. Save your changes.
 
 2. Reconfigure your Keycloak OIDC setup using a user that is assigned to at least one group in Keycloak.
+
+## Configuring OIDC Single Logout (SLO)
+
+<ConfigureSLOOidc />
@@ -197,3 +197,32 @@ helm install rancher rancher-latest/rancher -n cattle-system -f rancher-values.y
 After migration completes, update your DNS records and any load balancers, so that traffic is routed correctly to the migrated cluster. Remember that you must use the same hostname that was set as the server URL in the original cluster.

 Full instructions on how to redirect traffic to the migrated cluster differ based on your specific environment. Refer to your hosting provider's documentation for more details.
+
+### 6. Scale Down the Original Rancher Instance
+
+After redirecting traffic to the new Rancher environment, **scale the original Rancher instance to 0 replicas** so it no longer contacts your managed clusters.  
+
+Leaving the old server up can cause agents to keep contacting the original `server-url`, which often leaves clusters stuck in **Updating** in the new environment.
+
+```bash
+kubectl scale deployment rancher -n cattle-system --replicas=0
+```
+
+If you originally ran Rancher in Docker:
+
+```bash
+docker stop <original-rancher-container>
+```
+
+:::note
+
+If you wish to keep the original Rancher environment running, you can also restart the cattle-cluster-agent pods on each cluster connected to your Rancher environment.
+
+```bash
+kubectl rollout restart deployment cattle-cluster-agent -n cattle-system
+```
+
+This triggers a rolling restart of the agent so it re-establishes the connection to the new Rancher environment.
+
+:::
+
@@ -120,6 +120,18 @@ For a breakdown of the port requirements for etcd nodes, controlplane nodes, and

 Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#downstream-kubernetes-cluster-nodes).

+### IPv6 Address Requirements
+
+Rancher supports clusters configured with IPv4-only, IPv6-only, or dual-stack networking.
+
+You must provision each node with at least one valid IPv4 address, one IPv6 address, or both, according to the cluster networking configuration.
+
+For IPv6-only environments, ensure you correctly configure the operating system and that the `/etc/hosts` file includes a valid localhost entry, for example:
+
+```
+::1       localhost
+```
+
 :::caution

 You should never register a node with the same hostname or IP address as an existing node. Doing so causes RKE to prevent the node from joining, and provisioning to hang. This can occur for both node driver and custom clusters. If a node must reuse a hostname or IP of an existing node, you must set the `hostname_override` [RKE option](https://rke.docs.rancher.com/config-options/nodes#overriding-the-hostname) before registering the node, so that it can join correctly.
@@ -299,7 +299,7 @@ rancher_kubernetes_engine_config:
    useInstanceMetadataHostname: true
 ```

-You must not enable `useInstanceMetadataHostname` when setting custom values for `hostname-override` for custom clusters. When you create a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md), add [`--node-name`](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) to the `docker run` node registration command to set `hostname-override` — for example, `"$(hostname -f)"`. This can be done manually or by using **Show Advanced Options** in the Rancher UI to add **Node Name**.
+You must not enable `useInstanceMetadataHostname` when setting custom values for `hostname-override` for custom clusters. When you create a [custom cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md), add `--node-name` to the `docker run` node registration command to set `hostname-override` — for example, `"$(hostname -f)"`. This can be done manually or by using **Show Advanced Options** in the Rancher UI to add **Node Name**.

 2. Select the cloud provider. 

@@ -12,7 +12,7 @@ In Kubernetes 1.30 and later, you must use an out-of-tree Azure cloud provider.

 You can also [migrate from an in-tree to an out-of-tree Azure cloud provider](../migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-azure.md) on Kubernetes 1.29 and earlier. All existing clusters must migrate prior to upgrading to v1.30 in order to stay functional.

-Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must disable `DisableCloudProviders` and `DisableKubeletCloudCredentialProvider` to use the in-tree Azure cloud provider. You can do this by setting `feature-gates=DisableCloudProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Additionally, set `DisableKubeletCloudCredentialProvider=false` in the Kubelet's arguments to enable in-tree functionality for authenticating to Azure container registries for image pull credentials. See [upstream docs](https://github.com/kubernetes/kubernetes/pull/117503) for more details.
+Starting with Kubernetes 1.29, in-tree cloud providers have been disabled. You must set `DisableCloudProviders` and `DisableKubeletCloudCredentialProviders` feature gates to `false` to use the in-tree Azure cloud provider. You can do this by setting `feature-gates=DisableCloudProviders=false,DisableKubeletCloudCredentialProviders=false` as an additional argument for the cluster's Kubelet, Controller Manager, and API Server in the advanced cluster configuration. Setting `DisableKubeletCloudCredentialProviders=false` in the Kubelet, Controller Manager, and API Server arguments enables in-tree functionality for authenticating to Azure container registries for image pull credentials. See the [Kubernetes 1.29: Mandala release notes](https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/#in-tree-cloud-provider-integration-removal) and this [blog post](https://kubernetes.io/blog/2023/12/14/cloud-provider-integration-changes/#continue-using-in-tree-provider-code) for more details.

 Starting with Kubernetes version 1.26, in-tree persistent volume types `kubernetes.io/azure-disk` and `kubernetes.io/azure-file` are deprecated and will no longer be supported. For new clusters, [install the CSI drivers](#installing-csi-drivers), or migrate to the corresponding CSI drivers `disk.csi.azure.com` and `file.csi.azure.com` by following the [upstream migration documentation](https://learn.microsoft.com/en-us/azure/aks/csi-migrate-in-tree-volumes).
 :::
@@ -103,11 +103,11 @@ The `worker` nodes, which is where your workloads will be deployed on, will typi

 We recommend the minimum three-node architecture listed in the table below, but you can always add more Linux and Windows workers to scale up your cluster for redundancy:

-| Node   | Operating System                                    | Kubernetes Cluster Role(s)                                                                                                                                                                                                                         | Purpose                                                                             |
-| ------ | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
-| Node 1 | Linux (Ubuntu Server 18.04 recommended)             | Control plane, etcd, worker | Manage the Kubernetes cluster                                                       |
-| Node 2 | Linux (Ubuntu Server 18.04 recommended)             | Worker                                                                                                                                                                       | Support the Rancher Cluster agent, Metrics server, DNS, and Ingress for the cluster |
-| Node 3 | Windows (Windows Server core version 1809 or above) | Worker                                                                                                                                                                       | Run your Windows containers                                                         |
+| Node   | Operating System                                                                       | Kubernetes Cluster Role(s)  | Purpose                                                                             |
+|--------|----------------------------------------------------------------------------------------|-----------------------------|-------------------------------------------------------------------------------------|
+| Node 1 | Linux (Ubuntu Server 18.04 recommended)                                                | Control plane, etcd, worker | Manage the Kubernetes cluster                                                       |
+| Node 2 | Linux (Ubuntu Server 18.04 recommended)                                                | Worker                      | Support the Rancher Cluster agent, Metrics server, DNS, and Ingress for the cluster |
+| Node 3 | Windows (Windows Server core version 1809 or above required, version 2022 recommended) | Worker                      | Run your Windows containers                                                         |

 ### Container Requirements

@@ -126,8 +126,6 @@ If you are using the GCE (Google Compute Engine) cloud provider, you must do the

 This tutorial describes how to create a Rancher-provisioned cluster with the three nodes in the [recommended architecture.](#recommended-architecture)

-When you provision a cluster with Rancher on existing nodes, you add nodes to the cluster by installing the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) on each one. To create or edit your cluster from the Rancher UI, run the **Registration Command** on each server to add it to your cluster.
-
 To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below.

 ### 1. Provision Hosts
@@ -142,15 +140,15 @@ Your hosts can be:

 You will provision three nodes:

- One Linux node, which manages the Kubernetes control plane and stores your `etcd`
+- One Linux node, which manages the Kubernetes control plane, stores your `etcd`, and optionally be a worker node
 - A second Linux node, which will be another worker node
 - The Windows node, which will run your Windows containers as a worker node

-| Node   | Operating System                                             |
-| ------ | ------------------------------------------------------------ |
-| Node 1 | Linux (Ubuntu Server 18.04 recommended)                      |
-| Node 2 | Linux (Ubuntu Server 18.04 recommended)                      |
-| Node 3 | Windows (Windows Server core version 1809 or above required) |
+| Node   | Operating System                                                                       |
+|--------|----------------------------------------------------------------------------------------|
+| Node 1 | Linux (Ubuntu Server 18.04 recommended)                                                |
+| Node 2 | Linux (Ubuntu Server 18.04 recommended)                                                |
+| Node 3 | Windows (Windows Server core version 1809 or above required, version 2022 recommended) |

 If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.](../set-up-cloud-providers/set-up-cloud-providers.md)

@@ -164,11 +162,11 @@ The instructions for creating a Windows cluster on existing nodes are very simil
 1. Enter a name for your cluster in the **Cluster Name** field.
 1. In the **Kubernetes Version** dropdown menu, select a supported Kubernetes version.
 1. In the **Container Network** field, select either **Calico** or **Flannel**.
-1. Click **Next**.
+1. Click **Create**.

 ### 3. Add Nodes to the Cluster

-This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the Rancher agent and allow Rancher to manage each node.
+This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the rancher system agent and allow Rancher to manage each node.

 #### Add Linux Master Node

@@ -177,23 +175,18 @@ In this section, we fill out a form on the Rancher UI to get a custom command to
 The first node in your cluster should be a Linux host that has both the **Control Plane** and **etcd** roles. At a minimum, both of these roles must be enabled for this node, and this node must be added to your cluster before you can add Windows hosts.

 1. After cluster creation, navigate to the **Registration** tab.
-1. In **Step 1** under the **Node Role** section, select at least **etcd** and **Control Plane**. We recommend selecting all three.
-1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. In **Step 1** under the **Node Role** section, select all three roles. Although you can choose only the **etcd** and **Control Plane** roles, we recommend selecting all three.
+1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
 1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
 1. SSH into your Linux host and run the command that you copied to your clipboard.

-**Result:**
+**Results:**

-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+Your cluster is created and assigned a state of **Updating**. Rancher is standing up your cluster.

-You can access your cluster after its state is updated to **Active**.
+It may take a few minutes for the node to register and appear under the **Machines** tab.

-**Active** clusters are assigned two Projects:
-
- `Default`, containing the `default` namespace
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
-
-It may take a few minutes for the node to be registered in your cluster.
+You’ll be able to access the cluster once its state changes to **Active**.

 #### Add Linux Worker Node

@@ -203,11 +196,13 @@ After the initial provisioning of your cluster, your cluster only has a single L

 1. After cluster creation, navigate to the **Registration** tab.
 1. In **Step 1** under the **Node Role** section, select **Worker**.
-1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
 1. In **Step 2**, under the **Registration** section, copy the command displayed on the screen to your clipboard.
 1. SSH into your Linux host and run the command that you copied to your clipboard.

-**Result:** The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.
+**Results:** 
+
+The **Worker** role is installed on your Linux host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster.

 :::note

@@ -216,7 +211,7 @@ Taints on Linux Worker Nodes
 For each Linux worker node added into the cluster, the following taints will be added to Linux worker node. By adding this taint to the Linux worker node, any workloads added to the Windows cluster will be automatically scheduled to the Windows worker node. If you want to schedule workloads specifically onto the Linux worker node, you will need to add tolerations to those workloads.

 | Taint Key      | Taint Value | Taint Effect |
-| -------------- | ----------- | ------------ |
+|----------------|-------------|--------------|
 | `cattle.io/os` | `linux`     | `NoSchedule` |

 :::
@@ -231,12 +226,16 @@ The registration command to add the Windows workers only appears after the clust

 1. After cluster creation, navigate to the **Registration** tab.
 1. In **Step 1** under the **Node Role** section, select **Worker**.
-1. Optional: If you click **Show advanced options,** you can customize the settings for the [Rancher agent](../../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md) and [node labels.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
+1. Optional: If you click **Show Advanced**, you can configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
 1. In **Step 2**, under the **Registration** section, copy the command for Windows workers displayed on the screen to your clipboard.
-1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
+1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **PowerShell Console** as an Administrator.
 1. Optional: Repeat these instructions if you want to add more Windows nodes to your cluster.

-**Result:** The **Worker** role is installed on your Windows host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster. You now have a Windows Kubernetes cluster.
+**Results:** 
+
+The **Worker** role is installed on your Windows host, and the node registers with Rancher. It may take a few minutes for the node to be registered in your cluster. 
+
+You now have a Windows Kubernetes cluster.

 ### Optional Next Steps

@@ -20,7 +20,8 @@ Then you will create an EC2 cluster in Rancher, and when configuring the new clu
  - [Example IAM Policy](#example-iam-policy)
  - [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider](../../kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) or want to pass an IAM Profile to an instance)
  - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes)
- **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user.
+- **IAM Policy added as Permission** to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to a user.
+- **IPv4-only or IPv6-only or dual-stack subnet and/or VPC** where nodes can be provisioned and assigned IPv4 and/or IPv6 addresses. See [Amazon Documentation: IPv6 support for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html).

 ## Creating an EC2 Cluster

@@ -141,7 +141,8 @@ You need to remove the following components from Rancher-provisioned RKE2 nodes:
 To remove the rancher-system-agent, run the [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) script:

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### Removing RKE2
@@ -165,7 +166,8 @@ You need to remove the following components from Rancher-provisioned K3s nodes:
 To remove the rancher-system-agent, run the [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) script:

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh 
 ```

 ### Removing K3s
@@ -13,7 +13,7 @@ A project is a group of namespaces, and it is a concept introduced by Rancher. P

 :::note

-Projects are de-emphasized on the UI because it is not required to create Kubernetes resources within a project scope. However, resources such as [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) can still be created in a project scope if the legacy feature flag is enabled.
+Projects are de-emphasized on the UI because it is not required to create Kubernetes resources within a project scope. However, resources such as [Secrets](../../new-user-guides/kubernetes-resources-setup/secrets.md#creating-secrets-in-projects) can still be created in a project scope.

 :::

@@ -196,3 +196,7 @@ To add a resource quota,
 1. Select **Delete**.

 When you delete a project, any namespaces that were formerly associated with the project will remain on the cluster. You can find these namespaces in the Rancher UI, in the **Not in a Project** tab of the **Projects/Namespaces** page. You can reassign these namespaces to a project by [moving](../manage-namespaces.md#moving-namespaces-to-another-project) them.
+
+## Further Reading
+
+You can create projects and project members more programmatically via the [Public API](../../../api/quickstart.md). See the [project workflow doc](../../../api/workflows/projects.md) for more information.
@@ -19,10 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers

 | Rancher Version | Adapter Version  |
 |-----------------|------------------|
-| v2.12.3         |  107.0.0+up7.0.0 |
-| v2.12.2         |  107.0.0+up7.0.0 |
-| v2.12.1         |  107.0.0+up7.0.0 |
-| v2.12.0         |  107.0.0+up7.0.0 |
+| v2.13.1         |  108.0.0+up8.0.0 |
+| v2.13.0         |  108.0.0+up8.0.0 |

 ### 1. Gain Access to the Local Cluster

@@ -80,3 +80,18 @@ Use [Instance Metadata Service Version 2 (IMDSv2)](https://docs.aws.amazon.com/A

 Add metadata using [tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) to categorize resources.

+### IPv6 Address Count
+
+Specify how many IPv6 addresses to assign to the instance’s network interface.
+
+### IPv6 Address Only
+
+Enable this option if the instance should use IPv6 exclusively. IPv6-only VPCs or subnets require this. When enabled, the instance will have IPv6 as its sole address, and the IPv6 Address Count must be greater than zero.
+
+### HTTP Protocol IPv6
+
+Enable or disable IPv6 endpoints for the instance metadata service.
+
+### Enable Primary IPv6
+
+Enable this option to designate the first assigned IPv6 address as the primary address. This ensures a consistent, non-changing IPv6 address for the instance. It does not control whether IPv6 addresses are assigned.
@@ -28,6 +28,8 @@ Enable the DigitalOcean agent for additional [monitoring](https://docs.digitaloc

 Enable IPv6 for Droplets.

+For more information, refer to the [Digital Ocean IPv6 documentation](https://docs.digitalocean.com/products/networking/ipv6).
+
 ### Private Networking

 Enable private networking for Droplets.
@@ -71,7 +71,7 @@ Tags is a list of _network tags_, which can be used to associate preexisting Fir

 ### Labels

-A comma seperated list of custom labels to be attached to all VMs within a given machine pool. Unlike Tags, Labels do not influence networking behavior and only serve to organize cloud resources.
+A comma separated list of custom labels to be attached to all VMs within a given machine pool. Unlike Tags, Labels do not influence networking behavior and only serve to organize cloud resources.

 ## Advanced Options

@@ -6,4 +6,4 @@ title: Machine Configuration
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration"/>
 </head>

-Machine configuration is the arrangement of resources assigned to a virtual machine. Please see the docs for [Amazon EC2](amazon-ec2.md), [DigitalOcean](digitalocean.md), and [Azure](azure.md) to learn more.
+Machine configuration is the arrangement of resources assigned to a virtual machine. Please see the docs for [Amazon EC2](amazon-ec2.md), [DigitalOcean](digitalocean.md), [Google GCE](google-gce.md), and [Azure](azure.md) to learn more.
@@ -6,4 +6,6 @@ title: Node Template Configuration
  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration"/>
 </head>

+<EOLRKE1Warning />
+
 To learn about node template config, refer to [EC2 Node Template Configuration](amazon-ec2.md), [DigitalOcean Node Template Configuration](digitalocean.md), [Azure Node Template Configuration](azure.md), [vSphere Node Template Configuration](vsphere.md), and [Nutanix Node Template Configuration](nutanix.md).
@@ -63,7 +63,15 @@ Enable network policy enforcement on the cluster. A network policy defines the l

 _Mutable: yes_

-choose whether to enable or disable inter-project communication. Note that enabling Project Network Isolation will automatically enable Network Policy and Network Policy Config, but not vice versa.
+Choose whether to enable or disable inter-project communication.
+
+#### Imported Clusters
+
+For imported clusters, Project Network Isolation (PNI) requires Kubernetes Network Policy to be enabled on the cluster beforehand.
+For clusters created by Rancher, Rancher enables Kubernetes Network Policy automatically.
+
+1. In GKE, enable Network Policy at the cluster level. Refer to the [official GKE guide](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy) for instructions.
+1. After enabling Network Policy, import the cluster into Rancher and enable PNI for project-level isolation.

 ### Node Ipv4 CIDR Block

@@ -13,7 +13,7 @@ This section covers the configuration options that are available in Rancher for
 You can configure the Kubernetes options one of two ways:

 - [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster.
- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation.
+- [Cluster Config File](#cluster-config-file-reference): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file lets you set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available during a K3s installation.

 ## Editing Clusters in the Rancher UI

@@ -32,7 +32,7 @@ To edit your cluster,

 ### Editing Clusters in YAML

-For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
+For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation](https://docs.k3s.io/installation/configuration).

 To edit your cluster with YAML:

@@ -48,7 +48,8 @@ This subsection covers generic machine pool configurations. For specific infrast

 - [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
 - [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Amazon EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Google GCE](../downstream-cluster-configuration/machine-configuration/google-gce.md)

 ##### Pool Name

@@ -86,9 +87,9 @@ Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-tolerat
 #### Basics
 ##### Kubernetes Version

-The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
+The version of Kubernetes installed on your cluster nodes.

-For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
+For details on upgrading or rolling back Kubernetes, refer to [this guide](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).

 ##### Pod Security Admission Configuration Template

@@ -108,7 +109,7 @@ Option to enable or disable [SELinux](https://rancher.com/docs/k3s/latest/en/adv

 ##### CoreDNS

-By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#coredns) for details..
+By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/networking/#coredns) for details.

 ##### Klipper Service LB

@@ -148,15 +149,49 @@ Option to choose whether to expose etcd metrics to the public or only within the

 ##### Cluster CIDR

-IPv4/IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
+IPv4/IPv6 network CIDRs to use for pod IPs (default: `10.42.0.0/16`).
+
+Example values:
+
+- IPv4-only: `10.42.0.0/16`
+- IPv6-only: `2001:cafe:42::/56`
+- Dual-stack: `10.42.0.0/16,2001:cafe:42::/56`
+
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [K3s documentation: Dual-stack (IPv4 + IPv6) Networking](https://docs.k3s.io/networking/basic-network-options#dual-stack-ipv4--ipv6-networking)
+- [K3s documentation: Single-stack IPv6 Networking](https://docs.k3s.io/networking/basic-network-options#single-stack-ipv6-networking)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::

 ##### Service CIDR

-IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
+IPv4/IPv6 network CIDRs to use for service IPs (default: `10.43.0.0/16`).
+
+Example values:
+
+- IPv4-only: `10.43.0.0/16` 
+- IPv6-only: `2001:cafe:43::/112` 
+- Dual-stack: `10.43.0.0/16,2001:cafe:43::/112`
+
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [K3s documentation: Dual-stack (IPv4 + IPv6) Networking](https://docs.k3s.io/networking/basic-network-options#dual-stack-ipv4--ipv6-networking)
+- [K3s documentation: Single-stack IPv6 Networking](https://docs.k3s.io/networking/basic-network-options#single-stack-ipv6-networking)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::

 ##### Cluster DNS

-IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
+IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: `10.43.0.10`).

 ##### Cluster Domain

@@ -168,11 +203,11 @@ Option to change the range of ports that can be used for [NodePort services](htt

 ##### Truncate Hostnames

-Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
+Option to truncate hostnames to 15 characters or fewer. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15-character limit after cluster creation.

 This setting only affects machine-provisioned clusters. Since custom clusters set hostnames during their own node creation process, which occurs outside of Rancher, this field doesn't restrict custom cluster hostname length.

-Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
+Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or fewer.

 ##### TLS Alternate Names

@@ -186,6 +221,33 @@ For more detail on how an authorized cluster endpoint works and why it is used,

 We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)

+##### Stack Preference
+
+Choose the networking stack for the cluster. This option affects:
+
+- The address used for health and readiness probes of components such as Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager, and kubelet.
+- The server URL in the `authentication-token-webhook-config-file` for the Authorized Cluster Endpoint.
+- The `advertise-client-urls` setting for etcd during snapshot restoration.
+
+Options are `ipv4`, `ipv6`, `dual`:
+
+- When set to `ipv4`, the cluster uses `127.0.0.1`
+- When set to `ipv6`, the cluster uses `[::1]`
+- When set to `dual`, the cluster uses `localhost`
+
+The stack preference must match the cluster’s networking configuration:
+
+- Set to `ipv4` for IPv4-only clusters
+- Set to `ipv6` for IPv6-only clusters
+- Set to `dual` for dual-stack clusters
+
+:::caution
+
+Ensuring the loopback address configuration is correct is critical for successful cluster provisioning.
+For more information, refer to the [Node Requirements](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) page.
+
+:::
+
 #### Registries

 Select the image repository to pull Rancher images from. For more details and configuration options, see the [K3s documentation](https://rancher.com/docs/k3s/latest/en/installation/private-registry/).
@@ -32,7 +32,7 @@ To edit your cluster,

 ### Editing Clusters in YAML

-For a complete reference of configurable options for K3s clusters in YAML, see the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
+For a complete reference of configurable options for RKE2 clusters in YAML, see the [RKE2 documentation](https://docs.rke2.io/install/configuration).

 To edit your cluster in YAML:

@@ -48,7 +48,8 @@ This subsection covers generic machine pool configurations. For specific infrast

 - [Azure](../downstream-cluster-configuration/machine-configuration/azure.md)
 - [DigitalOcean](../downstream-cluster-configuration/machine-configuration/digitalocean.md)
- [EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Amazon EC2](../downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [Google GCE](../downstream-cluster-configuration/machine-configuration/google-gce.md)

 ##### Pool Name

@@ -86,9 +87,9 @@ Add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-tolerat
 #### Basics
 ##### Kubernetes Version

-The version of Kubernetes installed on your cluster nodes. Rancher packages its own version of Kubernetes based on [hyperkube](https://github.com/rancher/hyperkube).
+The version of Kubernetes installed on your cluster nodes.

-For more detail, see [Upgrading Kubernetes](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).
+For details on upgrading or rolling back Kubernetes, refer to [this guide](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md).

 ##### Container Network Provider

@@ -105,20 +106,19 @@ Out of the box, Rancher is compatible with the following network providers:
 - [Canal](https://github.com/projectcalico/canal)
 - [Cilium](https://cilium.io/)*
 - [Calico](https://docs.projectcalico.org/v3.11/introduction/)
+- [Flannel](https://github.com/flannel-io/flannel)
 - [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)

 \* When using [project network isolation](#project-network-isolation) in the [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium), it is possible to enable cross-node ingress routing. Click the [CNI provider docs](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium) to learn more.

-For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options).
+For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/networking/basic_network_options).

-###### Dual-stack Networking
-
-[Dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
-
-###### Dual-stack Additional Configuration
+:::caution

 When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.

+:::
+
 ##### Cloud Provider

 You can configure a [Kubernetes cloud provider](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md). If you want to use dynamically provisioned [volumes and storage](../../../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) in Kubernetes, typically you must select the specific cloud provider in order to use it. For example, if you want to use Amazon EBS, you would need to select the `aws` cloud provider.
@@ -181,27 +181,62 @@ Option to choose whether to expose etcd metrics to the public or only within the

 ##### Cluster CIDR

-IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
+IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: `10.42.0.0/16`).

-###### Dual-stack Networking
+Example values:

-To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
+- IPv4-only: `10.42.0.0/16`
+- IPv6-only: `2001:cafe:42::/56`
+- Dual-stack: `10.42.0.0/16,2001:cafe:42::/56`

-[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
+
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [RKE2 documentation: Dual-stack configuration](https://docs.rke2.io/networking/basic_network_options#dual-stack-configuration)
+- [RKE2 documentation: IPv6-only setup](https://docs.rke2.io/networking/basic_network_options#ipv6-setup)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::
+
+:::caution
+
+When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
+
+:::

 ##### Service CIDR

-IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
+IPv4/IPv6 network CIDRs to use for service IPs (default: `10.43.0.0/16`).

-###### Dual-stack Networking
+Example values:

-To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
+- IPv4-only: `10.43.0.0/16`
+- IPv6-only: `2001:cafe:43::/112`
+- Dual-stack: `10.43.0.0/16,2001:cafe:43::/112`

-[Additional configuration](#dual-stack-additional-configuration) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network-provider) interface provider.
+For additional requirements and limitations related to dual-stack or IPv6-only networking, see the following resources:
+
+- [RKE2 documentation: Dual-stack configuration](https://docs.rke2.io/networking/basic_network_options#dual-stack-configuration)
+- [RKE2 documentation: IPv6-only setup](https://docs.rke2.io/networking/basic_network_options#ipv6-setup)
+
+:::caution
+
+You must configure the Service CIDR when you first create the cluster. You cannot enable the Service CIDR on an existing cluster after it starts.
+
+:::
+
+:::caution
+
+When using `cilium` or `multus,cilium` as your container network interface provider, ensure the **Enable IPv6 Support** option is also enabled.
+
+:::

 ##### Cluster DNS

-IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10).
+IPv4 Cluster IP for coredns service. Should be in your service-cidr range (default: `10.43.0.10`).

 ##### Cluster Domain

@@ -213,11 +248,11 @@ Option to change the range of ports that can be used for [NodePort services](htt

 ##### Truncate Hostnames

-Option to truncate hostnames to 15 characters or less. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15 character limit after cluster creation.
+Option to truncate hostnames to 15 characters or fewer. You can only set this field during the initial creation of the cluster. You can't enable or disable the 15-character limit after cluster creation.

 This setting only affects machine-provisioned clusters. Since custom clusters set hostnames during their own node creation process, which occurs outside of Rancher, this field doesn't restrict custom cluster hostname length.

-Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or less.
+Truncating hostnames in a cluster improves compatibility with Windows-based systems. Although Kubernetes allows hostnames up to 63 characters in length, systems that use NetBIOS restrict hostnames to 15 characters or fewer.

 ##### TLS Alternate Names

@@ -233,6 +268,33 @@ For more detail on how an authorized cluster endpoint works and why it is used,

 We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint-ace)

+##### Stack Preference
+
+Choose the networking stack for the cluster. This option affects:
+
+- The address used for health and readiness probes of components such as Calico, etcd, kube-apiserver, kube-scheduler, kube-controller-manager, and kubelet.
+- The server URL in the `authentication-token-webhook-config-file` for the Authorized Cluster Endpoint.
+- The `advertise-client-urls` setting for etcd during snapshot restoration.
+
+Options are `ipv4`, `ipv6`, `dual`:
+
+- When set to `ipv4`, the cluster uses `127.0.0.1`
+- When set to `ipv6`, the cluster uses `[::1]`
+- When set to `dual`, the cluster uses `localhost`
+
+The stack preference must match the cluster’s networking configuration:
+
+- Set to `ipv4` for IPv4-only clusters
+- Set to `ipv6` for IPv6-only clusters
+- Set to `dual` for dual-stack clusters
+
+:::caution
+
+Ensuring the loopback address configuration is correct is critical for successful cluster provisioning.
+For more information, refer to the [Node Requirements](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) page.
+
+:::
+
 #### Registries

 Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/private_registry).
@@ -1,57 +0,0 @@
---
-title: Rancher Agent Options
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
-</head>
-
-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](use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
-
-For an overview of how Rancher communicates with downstream clusters using node agents, refer to the [architecture section.](../../../rancher-manager-architecture/communicating-with-downstream-user-clusters.md#3-node-agents)
-
-## General options
-
-| Parameter  | Environment variable | Description |
-| ---------- | -------------------- | ----------- |
-| `--server` | `CATTLE_SERVER` | The configured Rancher `server-url` setting which the agent connects to |
-| `--token`  | `CATTLE_TOKEN` | Token that is needed to register the node in Rancher |
-| `--ca-checksum`  | `CATTLE_CA_CHECKSUM` | The SHA256 checksum of the configured Rancher `cacerts` setting to validate |
-| `--node-name` | `CATTLE_NODE_NAME` | Override the hostname that is used to register the node (defaults to `hostname -s`) |
-| `--label` | `CATTLE_NODE_LABEL` | Add node labels to the node. For multiple labels, pass additional `--label` options. (`--label key=value`) |
-| `--taints` | `CATTLE_NODE_TAINTS` | Add node taints to the node. For multiple taints, pass additional `--taints` options.  (`--taints key=value:effect`) |
-
-## Role options
-
-| Parameter  | Environment variable | Description |
-| ---------- | -------------------- | ----------- |
-| `--all-roles` | `ALL=true` | Apply all roles (`etcd`,`controlplane`,`worker`) to the node |
-| `--etcd`  | `ETCD=true` | Apply the role `etcd` to the node |
-| `--controlplane`  | `CONTROL=true` | Apply the role `controlplane` to the node |
-| `--worker`  | `WORKER=true` | Apply the role `worker` to the node |
-
-## IP address options
-
-| Parameter  | Environment variable | Description |
-| ---------- | -------------------- | ----------- |
-| `--address` | `CATTLE_ADDRESS` | The IP address the node will be registered with (defaults to the IP used to reach `8.8.8.8`) |
-| `--internal-address` | `CATTLE_INTERNAL_ADDRESS` | The IP address used for inter-host communication on a private network |
-
-### Dynamic IP address options
-
-For automation purposes, you can't have a specific IP address in a command as it has to be generic to be used for every node. For this, we have dynamic IP address options. They are used as a value to the existing IP address options. This is supported for `--address` and `--internal-address`.
-
-| Value  | Example | Description |
-| ---------- | -------------------- | ----------- |
-| Interface name | `--address eth0` | The first configured IP address will be retrieved from the given interface |
-| `ipify` | `--address ipify` | Value retrieved from `https://api.ipify.org` will be used |
-| `awslocal` | `--address awslocal` | Value retrieved from `http://169.254.169.254/latest/meta-data/local-ipv4` will be used |
-| `awspublic` | `--address awspublic` | Value retrieved from `http://169.254.169.254/latest/meta-data/public-ipv4` will be used |
-| `doprivate` | `--address doprivate` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address` will be used |
-| `dopublic` | `--address dopublic` | Value retrieved from `http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address` will be used |
-| `azprivate` | `--address azprivate` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/privateIpAddress?api-version=2017-08-01&format=text` will be used |
-| `azpublic` | `--address azpublic` | Value retrieved from `http://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-08-01&format=text` will be used |
-| `gceinternal` | `--address gceinternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip` will be used |
-| `gceexternal` | `--address gceexternal` | Value retrieved from `http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip` will be used |
-| `packetlocal` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/local-ipv4` will be used |
-| `packetpublic` | `--address packetlocal` | Value retrieved from `https://metadata.packet.net/2009-04-04/meta-data/public-ipv4` will be used |
@@ -9,7 +9,7 @@ description: To create a cluster with custom nodes, you’ll need to access serv

 When you create a custom cluster, Rancher can use RKE2/K3s to create a Kubernetes cluster in on-prem bare-metal servers, on-prem virtual machines, or in any node hosted by an infrastructure provider.

-To use this option you'll need access to servers you intend to use in your Kubernetes cluster. Provision each server according to the [requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md), which includes some hardware specifications and Docker. After you install Docker on each server, you willl also run the command provided in the Rancher UI on each server to turn each one into a Kubernetes node.
+To use this option, you need access to the servers that will be part of your Kubernetes cluster. Provision each server according to the [requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md). Then, run the command provided in the Rancher UI on each server to convert it into a Kubernetes node.

 This section describes how to set up a custom cluster.

@@ -33,7 +33,15 @@ If you want to reuse a node from a previous custom cluster, [clean the node](../

 Provision the host according to the [installation requirements](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md) and the [checklist for production-ready clusters.](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md)

-If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) when provisioning the host.
+:::note IPv6-only cluster
+
+For an IPv6-only cluster, ensure that your operating system correctly configures the `/etc/hosts` file.
+
+```
+::1       localhost
+```
+
+:::

 ### 2. Create the Custom Cluster

@@ -41,39 +49,43 @@ If you're using Amazon EC2 as your host and want to use the [dual-stack](https:/
 1. On the **Clusters** page, click **Create**.
 1. Click **Custom**.
 1. Enter a **Cluster Name**.
-1. Use **Cluster Configuration** section to choose the version of Kubernetes, what network provider will be used and if you want to enable project network isolation. To see more cluster options, click on **Show advanced options**.
+1. Use the **Cluster Configuration** section to set up the cluster. For more information, see [RKE2 Cluster Configuration Reference](../rke2-cluster-configuration.md) and [K3s Cluster Configuration Reference](../k3s-cluster-configuration.md).

-    :::note Using Windows nodes as Kubernetes workers?
+   :::note Windows nodes

-    - See [Enable the Windows Support Option](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).
-    - The only Network Provider available for clusters with Windows support is Flannel.
+   To learn more about using Windows nodes as Kubernetes workers, see [Launching Kubernetes on Windows Clusters](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).

-    :::
+   :::

-    :::note Dual-stack on Amazon EC2:
+1. Click **Create**.

-    If you're using Amazon EC2 as your host and want to use the [dual-stack](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) feature, there are additional [requirements](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements) when configuring RKE.
+**Result:** The UI redirects to the **Registration** page, where you can generate the registration command for your nodes.

-    :::
+1. From **Node Role**, select the roles you want a cluster node to fill. You must provision at least one node for each role: etcd, worker, and control plane. A custom cluster requires all three roles to finish provisioning. For more information on roles, see [Roles for Nodes in Kubernetes Clusters](../../../kubernetes-concepts.md#roles-for-nodes-in-kubernetes-clusters).

-6. Click **Next**.
+   :::note  Bare-Metal Server

-4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
+   If you plan to dedicate bare-metal servers to each role, you must provision a bare-metal server for each role (i.e., provision multiple bare-metal servers).

-7.	From **Node Role**, choose the roles that you want filled by a cluster node. You must provision at least one node for each role: `etcd`, `worker`, and `control plane`. All three roles are required for a custom cluster to finish provisioning. For more information on roles, see [this section.](../../../kubernetes-concepts.md#roles-for-nodes-in-kubernetes-clusters)
+   :::note

-:::note
+1. **Optional**: Click **Show Advanced** to configure additional settings such as specifying the IP address(es), overriding the node hostname, or adding [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node

- Using Windows nodes as Kubernetes workers? See [this section](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md).
- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
+   :::note

-:::
+   The **Node Public IP** and **Node Private IP** fields can accept either a single address or a comma-separated list of addresses (for example: `10.0.0.5,2001:db8::1`). 

-8. **Optional**: Click **[Show advanced options](rancher-agent-options.md)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
+   :::

-9. Copy the command displayed on screen to your clipboard.
+   :::note Ipv6-only or Dual-stack Cluster

-10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
+   In both IPv6-only and dual-stack clusters, you should specify the node’s **IPv6 address** as the **Node Private IP**.
+
+   :::
+
+1. Copy the command displayed on screen to your clipboard.
+
+1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.

 :::note

@@ -81,11 +93,9 @@ Repeat steps 7-10 if you want to dedicate specific hosts to specific node roles.

 :::

-11. When you finish running the command(s) on your Linux host(s), click **Done**.
-
 **Result:**

-Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+The cluster is created and transitions to the **Updating** state while Rancher initializes and provisions cluster components.

 You can access your cluster after its state is updated to **Active**.

@@ -0,0 +1,122 @@
+---
+title: IPv4/IPv6 Dual-stack
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/dual-stack/"/>
+</head>
+
+Kubernetes supports IPv4-only, IPv6-only, and dual-stack networking configurations.
+For more details, refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/).
+
+## Installing Rancher on IPv6-Only or Dual-Stack Clusters
+
+Rancher can run on clusters using:
+
+- IPv4-only
+- IPv6-only
+- Dual-stack (IPv4 + IPv6)
+
+When you install Rancher on an **IPv6-only cluster**, it can communicate externally **only over IPv6**. This means it can provision:
+
+- IPv6-only clusters
+- Dual-stack clusters  
+  _(IPv4-only downstream clusters are not possible in this case)_
+
+When you install Rancher on a **dual-stack cluster**, it can communicate over both IPv4 and IPv6, and can therefore provision:
+
+- IPv4-only clusters
+- IPv6-only clusters
+- Dual-stack clusters
+
+For installation steps, see the guide: **[Installing and Upgrading Rancher](../getting-started/installation-and-upgrade/installation-and-upgrade.md)**.
+
+### Requirement for the Rancher Server URL
+
+When provisioning IPv6-only downstream clusters, the **Rancher Server URL must be reachable over IPv6** because downstream nodes connect back to the Rancher server using IPv6.
+
+## Provisioning IPv6-Only or Dual-Stack Clusters
+
+You can provision RKE2 and K3s **Node driver** (machine pools) or **Custom cluster** (existing hosts) clusters using IPv4-only, IPv6-only, or dual-stack networking.
+
+### Network Configuration
+
+To enable IPv6-only or dual-stack networking, you must configure:
+
+- Cluster CIDR
+- Service CIDR
+- Stack Preference
+
+Configuration references:
+
+- [K3s Cluster Configuration Reference](cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md)
+- [RKE2 Cluster Configuration Reference](cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md)
+
+### Support for Windows
+
+Kubernetes on Windows:
+
+| Feature             | Support Status                |
+|---------------------|-------------------------------|
+| IPv6-only clusters  | Not supported                 |
+| Dual-stack clusters | Supported                     |
+| Services            | Limited to a single IP family |
+
+For more information, see the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/#windows-support).
+
+K3s does **not** support Windows ([FAQ](https://docs.k3s.io/faq#does-k3s-support-windows))
+
+RKE2 supports Windows, but requires using either `Calico` or `Flannel` as the CNI.  
+Note that Windows installations of RKE2 do not support dual-stack clusters using BGP.
+For more details, see [RKE2 Network Options](https://docs.rke2.io/networking/basic_network_options).
+
+
+### Provisioning Node Driver Clusters
+
+Rancher currently supports assigning IPv6 addresses in **node driver** clusters with:
+
+- [Amazon EC2](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md)
+- [DigitalOcean](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md)
+
+Support for additional providers will be introduced in future releases.
+
+:::note DigitalOcean Limitation
+
+Creating an **IPv6-only cluster** using the DigitalOcean node driver is currently **not supported**.
+For more details, please see [rancher/rancher#52523](https://github.com/rancher/rancher/issues/52523#issuecomment-3457803572).
+
+:::
+
+#### Infrastructure Requirements
+
+Cluster nodes must meet the requirements listed in the [Node Requirements for Rancher Managed Clusters](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
+
+Machine pool configuration guides:
+
+- [Amazon EC2 Configuration](cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2.md)
+- [DigitalOcean Configuration](cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean.md)
+
+### Provisioning Custom Clusters
+
+To provision on your own nodes, follow the instructions in [Provision Kubernetes on Existing Nodes](cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md).
+
+:::note
+
+- **Node Public IP** and **Node Private IP** fields accept IPv4, IPv6, or both (comma-separated).  
+    >   Example: `10.0.0.5,2001:db8::1`
+- In **IPv6-only** and **dual-stack** clusters, specify the node’s **IPv6 address** as the **Private IP**.
+
+:::
+
+#### Infrastructure Requirements
+
+Infrastructure requirements are the same as above for node-driver clusters.
+
+## Other Limitations
+
+### GitHub.com
+
+GitHub.com does **not** support IPv6. As a result:
+
+- Any application repositories ( `ClusterRepo.catalog.cattle.io/v1` CR) hosted on GitHub.com will **not be reachable** from IPv6-only clusters.
+- Similarly, any **non-builtin node drivers** hosted on GitHub.com will also **not be accessible** in IPv6-only environments.
@@ -1,15 +0,0 @@
---
-title: Kubernetes Security Best Practices
---
-
-<head>
-  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
-</head>
-
-## Restricting Cloud Metadata API Access
-
-Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.
-
-It is advised to consult your cloud provider's security best practices for further recommendations and specific details on how to restrict access to cloud instance metadata API.
-
-Further references: MITRE ATT&CK knowledge base on - [Unsecured Credentials: Cloud Instance Metadata API](https://attack.mitre.org/techniques/T1552/005/).
@@ -55,6 +55,7 @@ plugins:
                     cert-manager,
                     cis-operator-system,
                     fleet-default,
+                     fleet-local,
                     ingress-nginx,
                     istio-system,
                     kube-node-lease,
@@ -63,5 +64,6 @@ plugins:
                     longhorn-system,
                     rancher-alerting-drivers,
                     security-scan,
+                     sr-operator-system,
                     tigera-operator]
 ```
@@ -41,9 +41,7 @@ For details, refer to the section on [security scans](../../how-to-guides/advanc
 `
 ## SELinux RPM

-[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
-
-We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux` and `rke2-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).
+We provide three RPMs (RPM Package Manager) that enable Rancher products to function properly on SELinux-enforcing hosts: `rancher-selinux`, `rke2-selinux` and `k3s-selinux`. For details, see [this page](selinux-rpm/selinux-rpm.md).

 ## Rancher Hardening Guide

@@ -80,8 +78,39 @@ Rancher is committed to informing the community of security issues in our produc

 ## Kubernetes Security Best Practices

-For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Security Best Practices](kubernetes-security-best-practices.md) guide.
+For recommendations on securing your Kubernetes cluster, refer to the [Kubernetes Cluster Security Best Practices](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/) guide.

 ## Rancher Security Best Practices

 For recommendations on securing your Rancher Manager deployments, refer to the [Rancher Security Best Practices](rancher-security-best-practices.md) guide.
+
+## Rancher Kubernetes Distributions (K3s/RKE2) Self-Assessment and Hardening Guides
+
+Rancher uses the following Kubernetes distributions:
+
+- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
+- [**K3s**](https://docs.k3s.io/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory requirement of upstream Kubernetes, all in a binary of less than 100 MB.
+
+To harden a Kubernetes cluster that's running a distribution other than those listed, refer to your Kubernetes provider's docs.
+
+### Hardening Guides and Benchmark Versions
+
+Each self-assessment guide is accompanied by a hardening guide. These guides were tested alongside the listed Rancher releases. Each self-assessment guide was tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can use the existing guides until a guide for your version is added.
+
+### RKE2 Guides
+
+| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guide |
+|------|--------------------|-----------------------|-----------------------|------------------|
+| Standalone RKE2 | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.rke2.io/security/cis_self_assessment18) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.rke2.io/security/cis_self_assessment19) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.rke2.io/security/cis_self_assessment110) | [Link](https://docs.rke2.io/security/hardening_guide) |
+| Standalone RKE2 | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.rke2.io/security/cis_self_assessment111) | [Link](https://docs.rke2.io/security/hardening_guide) |
+
+### K3s Guides
+
+| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guide |
+|------|--------------------|-----------------------|-----------------------|------------------|
+| Standalone K3s | Kubernetes v1.26 | CIS v1.8 | [Link](https://docs.k3s.io/security/self-assessment-1.8) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.27 | CIS v1.9 | [Link](https://docs.k3s.io/security/self-assessment-1.9) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.28 | CIS v1.10 | [Link](https://docs.k3s.io/security/self-assessment-1.10) | [Link](https://docs.k3s.io/security/hardening-guide) |
+| Standalone K3s | Kubernetes v1.29 and above | CIS v1.11 | [Link](https://docs.k3s.io/security/self-assessment-1.11) | [Link](https://docs.k3s.io/security/hardening-guide) |
@@ -0,0 +1,13 @@
+---
+title: About k3s-selinux
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/selinux-rpm/about-k3s-selinux"/>
+</head>
+
+`k3s-selinux` provides policies for K3s. It is installed automatically when the K3s installer script detects that it is running on an RPM-based distro.
+
+The `k3s-selinux` GitHub repository is [here](https://github.com/rancher/k3s-selinux).
+
+For more information about installing K3s on SELinux-enabled hosts, see the [K3s documentation](https://docs.k3s.io/advanced#selinux-support).
@@ -16,7 +16,7 @@ The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/ra

 :::note Requirement:

-The rancher-selinux RPM was tested with CentOS 7, 8 and 9.
+The `rancher-selinux` RPM was tested on openSUSE Tumbleweed and RHEL-based distributions including Centos/RockyLinux 8 and 9. 

 :::

@@ -24,19 +24,6 @@ The rancher-selinux RPM was tested with CentOS 7, 8 and 9.

 Set up the yum repo to install `rancher-selinux` directly on all hosts in the cluster.

-In order to use the RPM repository, on a CentOS 7 or RHEL 7 system, run the following bash snippet:
-
-```
-# cat << EOF > /etc/yum.repos.d/rancher.repo 
-[rancher] 
-name=Rancher 
-baseurl=https://rpm.rancher.io/rancher/production/centos/7/noarch
-enabled=1 
-gpgcheck=1 
-gpgkey=https://rpm.rancher.io/public.key 
-EOF
-```
-
 In order to use the RPM repository, on a CentOS 8 or RHEL 8 system, run the following bash snippet:

 ```
@@ -71,14 +58,14 @@ Install the RPM:
 yum -y install rancher-selinux
 ```

-## Configuring the Logging Application to Work with SELinux
+## Configuring the Logging and Monitoring Applications to Work with SELinux

 :::note Requirement:

-Logging v2 was tested with SELinux on RHEL/CentOS 7, 8 and 9.
+Logging v2 and Monitoring v2 were tested with SELinux on RHEL/CentOS 8, 9, and Tumbleweed.

 :::

 Applications do not automatically work once the `rancher-selinux` RPM is installed on the host. They need to be configured to run in an allowed SELinux container domain provided by the RPM. 

-To configure the `rancher-logging` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the chart.
+To configure the `rancher-logging` or the `rancher-monitoring` chart to be SELinux aware, change `global.seLinux.enabled` to true in the `values.yaml` when installing the charts.
@@ -10,11 +10,14 @@ title: SELinux RPM

 Developed by Red Hat, it is an implementation of mandatory access controls (MAC) on Linux. Mandatory access controls allow an administrator of a system to define how applications and users can access different resources such as files, devices, networks and inter-process communication. SELinux also enhances security by making an OS restrictive by default.

-After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8. To check whether SELinux is enabled and enforcing on your system, use `getenforce`:
+After being historically used by government agencies, SELinux is now an industry standard and enabled by default on SUSE distributions such as SUSE Linux Enterprise 16, openSUSE distributions such as openSUSE Tumbleweed, and RHEL-based OS such as Rocky Linux. To check whether SELinux is enabled and enforced on your system, use `getenforce`:

 ```
 # getenforce
 Enforcing
 ```

-We provide two RPMs (Red Hat packages) that enable Rancher products to function properly on SELinux-enforcing hosts: [`rancher-selinux`](about-rancher-selinux.md) and [`rke2-selinux`](about-rke2-selinux.md).
+We provide three RPMs (RPM Package Manager) that enable Rancher products to function properly on SELinux-enforcing hosts: 
+- [`rancher-selinux`](about-rancher-selinux.md)
+- [`rke2-selinux`](about-rke2-selinux.md)
+- [`k3s-selinux`](about-k3s-selinux.md)
@@ -20,10 +20,8 @@ Each Rancher version is designed to be compatible with a single version of the w

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
-| v2.12.3         |     v0.8.3      | &check;               | &check;                   |
-| v2.12.2         |     v0.8.2      | &check;               | &check;                   |
-| v2.12.1         |     v0.8.1      | &check;               | &check;                   |
-| v2.12.0         |     v0.8.0      | &cross;               | &check;                   |
+| v2.13.1         |     v0.9.1      | &check;               | &check;                   |
+| v2.13.0         |     v0.9.0      | &cross;               | &check;                   |

 ## Why Do We Need It?

@@ -184,7 +184,12 @@ module.exports = {
            current: {
              label: "Latest",
            },
-            '2.12': {
+            "2.13": {
+              label: "v2.13",
+              path: "v2.13",
+              banner: 'none'
+            },
+            "2.12": {
              label: "v2.12",
              path: "v2.12",
              banner: "none"
@@ -251,6 +256,11 @@ module.exports = {
      {
        // Plugin Options for loading OpenAPI files
        specs: [
+          {
+            id: "rancher-api-v2-13",
+            spec: "openapi/swagger-v2.13.json",
+            // route: '/api/',
+          },
          {
            id: "rancher-api-v2-12",
            spec: "openapi/swagger-v2.12.json",
@@ -14,4 +14,4 @@ title: API 参考

 import ApiDocMdx from '@theme/ApiDocMdx';

-<ApiDocMdx id="rancher-api-v2-12" />
+<ApiDocMdx id="rancher-api-v2-13" />
@@ -63,6 +63,7 @@ title: API 令牌
 | 设置 | 描述 |
 | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | 用户认证会话令牌的 TTL（单位：分钟）。 |
+| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
 | [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | 默认 TTL，应用于所有 kubeconfig 令牌（除了[由 Rancher CLI 生成的令牌](#在生成的-kubeconfig-中禁用令牌)）。**此设置从 2.6.6 版本开始引入。** |
 | [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes) | 在 CLI 中生成的令牌 TTL。**自 2.6.6 起已弃用，并将在 2.8.0 中删除**。请知悉，`kubeconfig-default-token-TTL-minutes` 将用于所有 kubeconfig 令牌。 |
 | [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | 除了由 [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) 控制的令牌外，所有令牌的最大 TTL。 |
@@ -71,6 +72,11 @@ title: API 令牌
 ### auth-user-session-ttl-minutes
 存活时间（TTL）（单位：分钟），用于确定用户身份验证会话令牌的到期时间。过期后，用户将需要登录并获取新令牌。此设置不受 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的影响。会话令牌是在用户登录 Rancher 时创建的。

+### auth-user-session-idle-ttl-minutes
+
+Time to live (TTL) without user activity for login sessions tokens, in minutes.
+By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
+
 ### kubeconfig-default-token-TTL-minutes
 存活时间（TTL）（单位：分钟），用于确定 kubeconfig 令牌的到期时间。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。此设置适用于在请求的 kubeconfig 文件中生成的令牌，不包括[由 Rancher CLI 生成的](#在生成的-kubeconfig-中禁用令牌)令牌。
 **此设置从 2.6.6 版本开始引入**。
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -16,10 +16,7 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                         | 发布时间            |
 | ----------------------------------------------------------------- | ------------------ |
-| [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | 2025 年 10 月 23 日 |
-| [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | 2025 年 9 月 25 日  |
-| [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | 2025 年 8 月 28 日  |
-| [2.12.0](https://github.com/rancher/rancher/releases/tag/v2.12.0) | 2025 年 7 月 30 日  |
+| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | 2025 年 11 月 25 日  |

 ## 当一个功能被标记为弃用我可以得到什么样的预期？

@@ -137,7 +137,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -161,7 +162,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -14,11 +14,8 @@ title: 安装 Adapter
 :::

 | Rancher 版本 | Adapter 版本 |
-|-----------------|:----------------:|
-| v2.12.3         |  107.0.0+up7.0.0 |
-| v2.12.2         |  107.0.0+up7.0.0 |
-| v2.12.1         |  107.0.0+up7.0.0 |
-| v2.12.0         |  107.0.0+up7.0.0 |
+|-----------------|------------------|
+| v2.13.0         |  108.0.0+up8.0.0 |

 ## 1. 获取对 Local 集群的访问权限

@@ -20,10 +20,7 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
-| v2.12.3         |     v0.8.3      | &check;               | &check;                   |
-| v2.12.2         |     v0.8.2      | &check;               | &check;                   |
-| v2.12.1         |     v0.8.1      | &check;               | &check;                   |
-| v2.12.0         |     v0.8.0      | &cross;               | &check;                   |
+| v2.13.0         |     v0.9.0      | &cross;               | &check;                   |

 ## 为什么我们需要它？

@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -196,7 +196,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -220,7 +221,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -16,6 +16,8 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                      | 发布时间           |
 | --------------------------------------------------------------- | ------------------ |
+| [2.11.9](https://github.com/rancher/rancher/releases/tag/v2.11.9) | 2025 年 12 月 18 日 |
+| [2.11.8](https://github.com/rancher/rancher/releases/tag/v2.11.8) | 2025 年 11 月 24 日 |
 | [2.11.7](https://github.com/rancher/rancher/releases/tag/v2.11.7) | 2025 年 10 月 23 日 |
 | [2.11.6](https://github.com/rancher/rancher/releases/tag/v2.11.6) | 2025 年 9 月 25 日  |
 | [2.11.5](https://github.com/rancher/rancher/releases/tag/v2.11.5) | 2025 年 8 月 28 日  |
@@ -196,7 +196,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -220,7 +221,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -15,6 +15,8 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| v2.11.9         | v106.0.0+up6.0.0 |
+| v2.11.8         | v106.0.0+up6.0.0 |
 | v2.11.7         | v106.0.0+up6.0.0 |
 | v2.11.6         | v106.0.0+up6.0.0 |
 | v2.11.5         | v106.0.0+up6.0.0 |
@@ -20,6 +20,8 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.11.9         |     v0.7.8      | &check;               | &cross;                   |
+| v2.11.8         |     v0.7.8      | &check;               | &cross;                   |
 | v2.11.7         |     v0.7.7      | &check;               | &cross;                   |
 | v2.11.6         |     v0.7.6      | &check;               | &cross;                   |
 | v2.11.5         |     v0.7.5      | &check;               | &cross;                   |
@@ -37,8 +37,7 @@ apiVersion: management.cattle.io/v3
 kind: Project
 metadata:
  annotations: 
-  field.cattle.io/creatorId:
-    user-id
+    field.cattle.io/creatorId: user-id
  generateName: p-
  namespace: c-m-abcde
 spec:
@@ -16,6 +16,8 @@ Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/

 | Patch 版本                                                         | 发布时间            |
 | ----------------------------------------------------------------- | ------------------ |
+| [2.12.5](https://github.com/rancher/rancher/releases/tag/v2.12.5) | 2025 年 12 月 18 日 |
+| [2.12.4](https://github.com/rancher/rancher/releases/tag/v2.12.4) | 2025 年 11 月 24 日 |
 | [2.12.3](https://github.com/rancher/rancher/releases/tag/v2.12.3) | 2025 年 10 月 23 日 |
 | [2.12.2](https://github.com/rancher/rancher/releases/tag/v2.12.2) | 2025 年 9 月 25 日  |
 | [2.12.1](https://github.com/rancher/rancher/releases/tag/v2.12.1) | 2025 年 8 月 28 日  |
@@ -137,7 +137,8 @@ For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Ran
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 RKE2
@@ -161,7 +162,8 @@ sudo rke2-uninstall.sh
 要删除 rancher-system-agent，请运行 [system-agent-uninstall.sh](https://github.com/rancher/system-agent/blob/main/system-agent-uninstall.sh) 脚本：

 ```
-curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh | sudo sh
+curl https://raw.githubusercontent.com/rancher/system-agent/main/system-agent-uninstall.sh > system-agent-uninstall.sh
+sudo sh system-agent-uninstall.sh
 ```

 ### 删除 K3s
@@ -15,6 +15,8 @@ title: 安装 Adapter

 | Rancher 版本 | Adapter 版本 |
 |-----------------|:----------------:|
+| v2.12.5         |  107.0.0+up7.0.0 |
+| v2.12.4         |  107.0.0+up7.0.0 |
 | v2.12.3         |  107.0.0+up7.0.0 |
 | v2.12.2         |  107.0.0+up7.0.0 |
 | v2.12.1         |  107.0.0+up7.0.0 |
@@ -20,6 +20,8 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local

 | Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
 |-----------------|-----------------|-----------------------|---------------------------|
+| v2.12.5         |     v0.8.4      | &check;               | &cross;                   |
+| v2.12.4         |     v0.8.4      | &check;               | &cross;                   |
 | v2.12.3         |     v0.8.3      | &check;               | &check;                   |
 | v2.12.2         |     v0.8.2      | &check;               | &check;                   |
 | v2.12.1         |     v0.8.1      | &check;               | &check;                   |
@@ -0,0 +1,17 @@
+---
+title: API 参考
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/api-reference"/>
+</head>
+
+:::note
+
+目前，并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
+
+:::
+
+import ApiDocMdx from '@theme/ApiDocMdx';
+
+<ApiDocMdx id="rancher-api-v2-13" />
@@ -0,0 +1,93 @@
+---
+title: API 令牌
+---
+
+默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。令牌不会因为更改密码而失效。
+
+要停用 API 令牌，你可以删除令牌或停用用户账号。
+
+## 删除令牌
+要删除令牌：
+
+1. 转到 `https://<Rancher-Server-IP>/v3/tokens`，在 Rancher API 视图中查看包含所有令牌的列表。
+
+1. 通过 ID 访问要删除的令牌。例如，`https://<Rancher-Server-IP>/v3/tokens/kubectl-shell-user-vqkqt`。
+
+1. 单击**删除**。
+
+以下是使用 `ttl=0` 生成的完整令牌列表：
+
+| 令牌 | 描述 |
+| ----------------- | -------------------------------------------------------------------------------------- |
+| `kubeconfig-*` | Kubeconfig 令牌 |
+| `kubectl-shell-*` | 在浏览器中访问 `kubectl` shell |
+| `agent-*` | Agent deployment 令牌 |
+| `compose-token-*` | compose 令牌 |
+| `helm-token-*` | Helm Chart deployment 令牌 |
+| `telemetry-*` | 遥测令牌 |
+| `drain-node-*` | 用于清空的令牌（由于没有原生 Kubernetes API，我们使用 `kubectl` 来清空） |
+
+
+## 在 Kubeconfig 令牌上设置 TTL
+
+管理员可以在 Kubeconfig 令牌上设置全局存活时间 (time-to-live，TTL)。如需更改默认 kubeconfig TTL，你可以导航到全局设置并将 [`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 设置为所需的持续时间（单位：分钟）。[`kubeconfig-default-token-ttl-minutes`](#kubeconfig-default-token-ttl-minutes) 的默认值为 0，表示令牌永不过期。
+
+:::note
+
+除了由 CLI 创建的用于[生成 kubeconfig 令牌](#在生成的-kubeconfig-中禁用令牌)的令牌之外，所有 kubeconfig 令牌都使用此设置。
+
+:::
+
+## 在生成的 Kubeconfig 中禁用令牌
+
+1. 将 `kubeconfig-generate-token` 设置为 `false`。此设置让 Rancher 不再在用户单击下载 kubeconfig 文件时自动生成令牌。如果停用此设置，生成的 kubeconfig 将引用 [Rancher CLI](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证) 来检索集群的短期令牌。当这个 kubeconfig 在客户端（例如 `kubectl`）中使用时，你需要安装 Rancher CLI 来完成登录请求。
+
+2. 将 `kubeconfig-token-ttl-minutes` 设置为所需的时长（单位：分钟）。`kubeconfig-token-ttl-minutes` 默认设置为 960（即 16 小时）。
+
+## 令牌哈希
+
+你可以启用令牌哈希，令牌将使用 SHA256 算法进行单向哈希。这是一个不可逆的操作，一旦启用，此功能将无法禁用。在启用功能或在测试环境中评估之前，建议你先进行备份。
+
+要启用令牌哈希，请参阅[本节](../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
+
+此功能将影响所有令牌，包括但不限于以下内容：
+
+- Kubeconfig 令牌
+- 持有者令牌 API 密钥/调用
+- 内部操作使用的令牌
+
+## 令牌设置
+
+以下全局设置会影响 Rancher 令牌的行为：
+
+| 设置 | 描述 |
+| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) | 用户认证会话令牌的 TTL（单位：分钟）。 |
+| [`auth-user-session-idle-ttl-minutes`](#auth-user-session-idle-ttl-minutes) | TTL in minutes on a user auth session token, without user activity. |
+| [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) | 默认 TTL，应用于所有 kubeconfig 令牌（除了[由 Rancher CLI 生成的令牌](#在生成的-kubeconfig-中禁用令牌)）。**此设置从 2.6.6 版本开始引入。** |
+| [`kubeconfig-token-ttl-minutes`](#kubeconfig-token-ttl-minutes) | 在 CLI 中生成的令牌 TTL。**自 2.6.6 起已弃用，并将在 2.8.0 中删除**。请知悉，`kubeconfig-default-token-TTL-minutes` 将用于所有 kubeconfig 令牌。 |
+| [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) | 除了由 [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) 控制的令牌外，所有令牌的最大 TTL。 |
+| [`kubeconfig-generate-token`](#kubeconfig-generate-token) | 如果为 true，则在用户下载 kubeconfig 时自动生成令牌。 |
+
+### auth-user-session-ttl-minutes
+存活时间（TTL）（单位：分钟），用于确定用户身份验证会话令牌的到期时间。过期后，用户将需要登录并获取新令牌。此设置不受 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的影响。会话令牌是在用户登录 Rancher 时创建的。
+
+### auth-user-session-idle-ttl-minutes
+
+Time to live (TTL) without user activity for login sessions tokens, in minutes.
+By default, `auth-user-session-idle-ttl-minutes` is set to the same value as [`auth-user-session-ttl-minutes`](#auth-user-session-ttl-minutes) (for backward compatibility). It must never exceed the value of `auth-user-session-ttl-minutes`.
+
+### kubeconfig-default-token-TTL-minutes
+存活时间（TTL）（单位：分钟），用于确定 kubeconfig 令牌的到期时间。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。此设置适用于在请求的 kubeconfig 文件中生成的令牌，不包括[由 Rancher CLI 生成的](#在生成的-kubeconfig-中禁用令牌)令牌。
+**此设置从 2.6.6 版本开始引入**。
+
+### kubeconfig-token-ttl-minutes
+存活时间（TTL）（单位：分钟），用于确定由 CLI 生成的 kubeconfig 令牌的到期时间。当 [`kubeconfig-generate-token`](#kubeconfig-generate-token) 设为 false 时，则由 CLI 生成令牌。令牌过期后，API 将拒绝令牌。此设置的值不能大于 [`auth-token-max-ttl-minutes`](#auth-token-max-ttl-minutes) 的值。
+**自版本 2.6.6 起已弃用，并将在 2.8.0 中删除。请知悉，此设置将被 [`kubeconfig-default-token-TTL-minutes`](#kubeconfig-default-token-ttl-minutes) 的值替换**。
+
+### auth-token-max-ttl-minutes
+身份验证令牌的最大生存时间 (TTL)（单位：分钟）。如果用户尝试创建一个 TTL 大于 `auth-token-max-ttl-minutes` 的令牌，Rancher 会将令牌 TTL 设置为 `auth-token-max-ttl-minutes` 的值。身份验证令牌是为验证 API 请求而创建的。
+**2.6.6 版本更改：适用于所有 kubeconfig 令牌和 API 令牌。**
+
+### kubeconfig-generate-token
+如果设置为 true，则通过 UI 请求的 kubeconfig 将包含一个有效的令牌。如果设置为 false，kubeconfig 将包含一个使用 Rancher CLI 提示用户登录的命令。然后，[CLI 将为用户检索和缓存令牌](../reference-guides/cli-with-rancher/kubectl-utility.md#使用-kubectl-和-kubeconfig-令牌进行-ttl-认证)。
@@ -0,0 +1,152 @@
+---
+title: API 快速入门指南
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/quickstart"/>
+</head>
+
+你可以通过 Kubernetes API 访问 Rancher 的资源。本指南将帮助你以 Rancher 用户的身份开始使用此 API。
+
+1. 在左上角，点击 **☰ > 全局设置**.
+2. 找到 `server-url` 字段并复制其地址。
+3. [创建](../reference-guides/user-settings/api-keys.md#创建-api-密钥)一个没有作用域的 Rancher API 密钥。
+
+  :::danger
+
+  没有作用域的 Rancher API 密钥授予用户可以访问的所有资源的无限制的访问权限。为防止未经授权的使用，此密钥应安全存储并经常轮换。
+
+  :::
+
+4. 创建一个 `kubeconfig.yaml` 文件，将 `$SERVER_URL` 替换成上面从全局设置中复制的地址，并且将 `$API_KEY` 替换为上面创建的 Rancher API 密钥：
+
+    ```yaml
+    apiVersion: v1
+    kind: Config
+    clusters:
+    - name: "rancher"
+      cluster:
+        server: "$SERVER_URL"
+    
+    users:
+    - name: "rancher"
+      user:
+        token: "$API_KEY"
+
+    contexts:
+    - name: "rancher"
+      context:
+        user: "rancher"
+        cluster: "rancher"
+
+    current-context: "rancher"
+    ```
+
+你可以使用任何兼容的工具来引用这个文件，例如 kubectl 或 [client-go](https://github.com/kubernetes/client-go)。快速演示内容请参阅 [kubectl 示例](#api-kubectl-示例)
+
+更多有关处理更复杂证书的设置信息，请参阅[指定 CA 证书](#指定-ca-证书)。
+
+更多关于可用的 kubeconfig 选项，请参阅[上游文档](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。
+
+## API kubectl 示例
+
+在此示例中，我们将展示如何使用 kubectl 创建一个项目，然后删除它。关于其他可用的 Rancher 资源列表，请参阅 [API 参考](./api-reference.mdx)。
+
+:::note
+
+目前，并非所有的 Rancher 资源都可以通过 Rancher Kubernetes API 操作。
+
+:::
+
+1. 将 KUBECONFIG 环境变量设置为刚才创建的 kubeconfig 文件：
+
+  ```bash
+  export KUBECONFIG=$(pwd)/kubeconfig.yaml
+  ```
+
+2. 使用 `kubectl explain` 查看项目的可用字段，或者复杂资源的子字段：
+
+  ```bash
+  kubectl explain projects
+  kubectl explain projects.spec
+  ```
+  
+不是所有的资源都有详细的输出。
+
+3. 在名称为 `project.yaml` 的文件中添加以下内容：
+
+  ```yaml
+  apiVersion: management.cattle.io/v3
+  kind: Project
+  metadata:
+    # name 应在每个集群的所有项目中都是唯一的
+    name: p-abc123
+    # generateName 可以替代 `name` 来随机生成一个名称
+    # generateName: p-
+    # namespace 应与 spec.ClusterName 匹配
+    namespace: local
+  spec:
+    # clusterName 应与目标集群的 `metadata.Name` 匹配
+    clusterName: local
+    description: Example Project 
+    # displayName 是人类可读的名称并且从 UI 中显示
+    displayName: Example
+  ```
+
+4. 创建项目：
+
+  ```bash
+  kubectl create -f project.yaml
+  ```
+
+5. 删除项目：
+
+  项目删除的方式取决于项目名称的创建方式。
+
+  **A. 如果在创建项目时使用 `name`**：
+
+    ```bash
+    kubectl delete -f project.yaml
+    ```
+
+  **B. 如果你使用 `generateName`**：
+
+    将 `$PROJECT_NAME` 替换为 kubectl 创建项目后随机生成的项目名称。
+
+    ```bash
+    kubectl delete project $PROJECT_NAME -n local
+    ```
+
+## 指定 CA 证书
+
+为确保你的工具能够识别 Rancher 的 CA 证书，大多数设置都需要对上述模板进行额外修改。
+
+1. 在左上角点击 **☰ > 全局设置**.
+2. 查找并复制 `ca-certs` 字段中的值。
+3. 将复制的值保存在名称为 `rancher.crt` 的文件中。
+
+  :::note
+  如果你的 Rancher 实例由其他服务代理，你必须提取该服务正在使用的证书，并将其添加到 kubeconfig 文件中，如步骤 5 所示。
+  :::
+
+4. 以下命令会将 `rancher.crt` 转换为 base64 输出，除去所有换行符，并使用证书内容更新 kubeconfig 中的 cluster 选项，然后删除 `rancher.crt` 文件：
+
+  ```bash
+  export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
+  kubectl config set clusters.rancher.certificate-authority-data $(cat rancher.crt | base64 -i - | tr -d '\n')
+  rm rancher.crt
+  ```
+5. （可选项）如果你使用不受系统信任的自签名证书，则可以通过 kubectl 在 kubeconfig 中设置不安全选项：
+
+  :::danger
+
+  此选项不应该在生产环境中使用，因为它存在安全风险。
+
+  :::
+
+  ```bash
+  export KUBECONFIG=$PATH_TO_RANCHER_KUBECONFIG
+  kubectl config set clusters.rancher.insecure-skip-tls-verify true
+  ```
+
+  如果你的 Rancher 实例由其他服务代理，你必须提取该服务正在使用的证书，并如上面演示的方法，将其添加到 kubeconfig 文件中。
@@ -0,0 +1,93 @@
+---
+title: API
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/about-the-api"/>
+</head>
+
+## 如何使用 API
+
+API 有自己的用户界面，你可以从 Web 浏览器访问它。这是查看资源、执行操作以及查看等效 cURL 或 HTTP 请求和响应的一种简单的方法。要访问它：
+
+<Tabs>
+<TabItem value="Rancher v2.6.4+">
+
+1. 单击右上角的用户头像。
+1. 单击**账号 & API 密钥**。
+1. 在 **API 密钥**下，找到 **API 端点**字段并单击链接。该链接类似于 `https://<RANCHER_FQDN>/v3`，其中 `<RANCHER_FQDN>` 是 Rancher deployment 的完全限定域名。
+
+</TabItem>
+<TabItem value="Rancher 版本低于 v2.6.4">
+
+转到位于 `https://<RANCHER_FQDN>/v3` 的 URL 端点，其中 `<RANCHER_FQDN>` 是你的 Rancher deployment 的完全限定域名。
+
+</TabItem>
+</Tabs>
+
+## 认证
+
+API 请求必须包含认证信息。认证是通过 [API 密钥](../reference-guides/user-settings/api-keys.md)使用 HTTP 基本认证完成的。API 密钥可以创建新集群并通过 `/v3/clusters/` 访问多个集群。[集群和项目角色](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)会应用于这些键，并限制账号可以查看的集群和项目以及可以执行的操作。
+
+默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。有关如何使 API 令牌失效的详细信息，请参阅 [API 令牌](api-tokens.md)。
+
+## 发出请求
+
+该 API 通常是 RESTful 的，但是还具有多种功能。这些功能可以使客户端发现所有内容，因此可以编写通用客户端，而不必为每种资源编写特定代码。有关通用 API 规范的详细信息，请参阅[此处](https://github.com/rancher/api-spec/blob/master/specification.md)。
+
+- 每种类型都有一个 Schema，这个 Schema 描述了以下内容：
+   - 用于获取此类资源集合的 URL
+   - 资源可以具有的每个字段及其类型、基本验证规则、是必填还是可选字段等
+   - 在此类资源上可以执行的每个操作，以及它们的输入和输出（也作为 schema）
+   - 允许过滤的每个字段
+   - 集合本身或集合中的单个资源可以使用的 HTTP 操作方法
+
+
+- 因此，你可以只加载 schema 列表并了解 API 的所有信息。实际上，这是 API 的 UI 工作方式，它不包含特定于 Rancher 本身的代码。每个 HTTP 响应中的 `X-Api-Schemas` 标头都会发送获取 Schemas 的 URL。你可以按照每个 schema 上的 `collection` 链接了解要在哪里列出资源，并在返回资源中的其他 `links` 中获取其他信息。
+
+- 在实践中，你可能只想构造 URL 字符串。我们强烈建议将此限制为在顶层列出的集合 (`/v3/<type>`)，或获取特定资源 (`/v3/<type>/<id>`)。除此之外的任何内容都可能在将来的版本中发生更改。
+
+- 资源之间相互之间有联系，称为链接（links）。每个资源都包含一个 `links` 映射，其中包含链接名称和用于检索该信息的 URL。同样，你应该 `GET` 资源并遵循 `links` 映射中的 URL，而不是自己构造这些字符串。
+
+- 大多数资源都有操作（action），表示可以执行某个操作或改变资源的状态。要使用操作，请将 HTTP `POST` 请求发送到 `actions` 映射中你想要的操作的 URL。某些操作需要输入或生成输出，请参阅每种类型的独立文档或 schema 以获取具体信息。
+
+- 要编辑资源，请将 HTTP `PUT` 请求发送到资源上的 `links.update` 链接，其中包含要更改的字段。如果链接丢失，则你无权更新资源。未知字段和不可编辑的字段将被忽略。
+
+- 要删除资源，请将 HTTP `DELETE` 请求发送到资源上的 `links.remove` 链接。如果链接丢失，则你无权更新资源。
+
+- 要创建新资源，HTTP `POST` 到 schema（即 `/v3/<type>`）中的集合 URL。
+
+## 过滤
+
+你可以使用 HTTP 查询参数的公共字段在服务器端过滤大多数集合。`filters` 映射显示了可以过滤的字段，以及过滤后的值在你发起的请求中是什么。API UI 具有设置过滤和显示适当请求的控件。对于简单的 "equals" 匹配，它只是 `field=value`。你可以将修饰符添加到字段名称，例如 `field_gt=42` 表示“字段大于 42”。详情请参阅 [API 规范](https://github.com/rancher/api-spec/blob/master/specification.md#filtering)。
+
+## 排序
+
+你可以使用 HTTP 查询参数的公共字段在服务器端排序大多数集合。`sortLinks` 映射显示了可用的排序，以及用于获取遵循该排序的集合的 URL。它还包括当前响排序依据的信息（如果指定）。
+
+## 分页
+
+默认情况下，API 响应以每页 100 个资源的限制进行分页。你可以通过 `limit` 查询参数进行更改，最大为 1000，例如 `/v3/pods?limit=1000`。集合响应中的 `pagination` 映射能让你知道你是否拥有完整的结果集，如果没有，则会指向下一页的链接。
+
+## 捕获 Rancher API 调用
+
+You can use browser developer tools to capture how the v3 API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning a Rancher Kubernetes distribution cluster:
+
+1. 在 Rancher UI 中，转到**集群管理**并单击**创建**。
+1. 单击某个集群类型。此示例使用 Digital Ocean。
+1. 使用集群名称和节点模板填写表单，但不要单击**创建**。
+1. 在创建集群之前，你需要打开开发人员工具才能看到正在记录的 API 调用。要打开工具，右键单击 Rancher UI，然后单击**检查**。
+1. 在开发者工具中，单击 **Network** 选项卡。
+1. 在 **Network** 选项卡上，确保选择了 **Fetch/XHR**。
+1. 在 Rancher UI 中，单击**创建**。在开发者工具中，你应该会看到一个名为 `cluster?_replace=true` 的新网络请求。
+1. 右键单击 `cluster?_replace=true` 并单击**复制 > 复制为 cURL**。
+1. 将结果粘贴到文本编辑器中。你将能够看到 POST 请求，包括被发送到的 URL、所有标头以及请求的完整正文。此命令可用于从命令行创建集群。请注意，请求包含凭证，因此请将请求存储在安全的地方。
+
+### 启用在 API 中查看
+
+你还可以查看针对各自集群和资源捕获的 Rancher API 调用。 默认情况下不启用此功能。 要启用它：
+
+1. 单击 UI 右上角的 **用户图标**，然后从下拉菜单中选择 **偏好设置**
+1. 在**高级功能**部分下，单击**启用"在 API 中查看"**
+
+选中后，**在 API 中查看**链接现在将显示在 UI 资源页面上的 **⋮** 子菜单下。
@@ -0,0 +1,134 @@
+---
+title: 项目
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/api/workflows/projects"/>
+</head>
+
+## 创建项目
+
+项目资源只能在管理集群上创建，请参考下文了解如何[在管理集群中的项目下创建命名空间](#在项目中创建命名空间)
+
+### 创建一个基本项目
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+使用 `metadata.generateName` 来确保一个唯一的项目 ID，但是需要注意 `kubectl apply` 不能与 `metadata.generateName` 一起使用，因此必须使用 `kubectl create` 来替代。
+
+将 `metadata.namespace` 和 `spec.clusterName` 设置为项目所属的集群 ID。
+
+如果你通过集群成员账户创建项目，则必须包含注释 `field.cattle.io/creatorId`，并将注释值设置为集群成员账号的用户 ID。
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  annotations: 
+    field.cattle.io/creatorId: user-id
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+EOF
+```
+
+设置 `field.cattle.io/creatorId` 字段允许集群成员账户通过 `get` 命令查看项目资源，并可以在 Rancher UI 中查看项目。集群所有者和管理员账号不需要设置此注释。
+
+### 创建一个具有 Resource Quota 的项目
+
+请查看 [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/)。
+
+```bash
+kubectl create -f - <<EOF
+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
+EOF
+```
+
+### 创建一个具有 Container Limit Ranges 的项目
+
+请查看 [Kubernetes Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/)。
+
+```bash
+kubectl create -f - <<EOF
+apiVersion: management.cattle.io/v3
+kind: Project
+metadata:
+  generateName: p-
+  namespace: c-m-abcde
+spec:
+  clusterName: c-m-abcde
+  displayName: myproject
+  containerDefaultResourceLimit:
+    limitsCpu:    100m
+    limitsMemory: 100Mi
+    requestsCpu:  50m
+    requestsMemory: 50Mi
+```
+
+## 在项目中创建命名空间
+
+项目资源保存在管理集群中，即使该项目使用于托管集群也是如此。项目下的命名空间保存在托管集群中。
+
+在管理集群上查找你正在管理的集群的项目 ID，因为它是使用 `metadata.generateName` 生成的：
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+在托管集群上，使用项目注释创建命名空间:
+
+```bash
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: mynamespace
+  annotations:
+    field.cattle.io/projectId: c-m-abcde:p-vwxyz
+EOF
+```
+
+注意格式：`<cluster ID>:<project ID>`
+
+## 删除项目
+
+在集群命名空间中查找要删除的项目：
+
+```bash
+kubectl --namespace c-m-abcde get projects
+```
+
+删除集群命名空间下的项目：
+
+```bash
+kubectl --namespace c-m-abcde delete project p-vwxyz
+```
+
+请注意此命令不会删除以前属于该项目的命名空间和资源。
@@ -0,0 +1,114 @@
+---
+title: 参与 Rancher 社区贡献
+---
+
+本文介绍了 Rancher 仓库和 Rancher 文档、如何构建 Rancher 仓库以及提交 issue 时要包含哪些信息。
+
+有关如何为 Rancher 项目开发做出贡献的更多详细信息，请参阅 [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki)。Wiki 包含以下主题的资源：
+
+- 如何搭建 Rancher 开发环境并运行测试
+- Issue 在开发生命周期中的典型流程
+- 编码指南和开发最佳实践
+- 调试和故障排除
+- 开发 Rancher API
+
+在 Rancher Users Slack 上，开发者的频道是 **#developer**。
+
+## Rancher 文档
+
+如果你对此网站上的文档有建议，请在主 [Rancher 文档](https://github.com/rancher/rancher-docs)仓库中[提交 issue](https://github.com/rancher/rancher-docs/issues/new/choose)。此仓库包含 Rancher v2.0 及更高版本的文档。
+
+有关贡献和构建 Rancher v2.x 文档仓库的更多详细信息，请参阅 [Rancher 文档 README](https://github.com/rancher/rancher-docs#readme)。
+
+有关 Rancher v1.6 及更早版本的文档，请参阅 [Rancher 1.x docs](https://github.com/rancher/rancher.github.io) 仓库，其中包含 https://rancher.com/docs/rancher/v1.6/en/ 的源文件。
+
+## Rancher 仓库
+
+所有仓库都位于我们的主要 GitHub 组织内。Rancher 使用了很多仓库，以下是部分主要仓库的描述：
+
+| 仓库 | URL | 描述 |
+-----------|-----|-------------
+| Rancher | https://github.com/rancher/rancher | Rancher 2.x 的主要源码仓库。 |
+| Types | https://github.com/rancher/types | 包含 Rancher 2.x 的所有 API 类型的仓库。 |
+| API Framework | https://github.com/rancher/norman | API 框架，用于构建由 Kubernetes 自定义资源支持的 Rancher 风格的 API。 |
+| User Interface | https://github.com/rancher/dashboard/ | Dashboard UI 源码仓库。 |
+| (Rancher) Docker Machine | https://github.com/rancher/machine | 使用主机驱动时使用的 Docker Machine 二进制文件的源码仓库。这是 `docker/machine` 仓库的一个 fork。 |
+| machine-package | https://github.com/rancher/machine-package | 用于构建 Rancher Docker Machine 二进制文件。 |
+| kontainer-engine | https://github.com/rancher/kontainer-engine | kontainer-engine 的源码仓库，它是配置托管 Kubernetes 集群的工具。 |
+| CLI | https://github.com/rancher/cli | Rancher 2.x 中使用的 Rancher CLI 的源码仓库。 |
+| (Rancher) Helm repository | https://github.com/rancher/helm | 打包的 Helm 二进制文件的源码仓库。这是 `helm/helm` 仓库的一个 fork。 |
+| Telemetry repository | https://github.com/rancher/telemetry | Telemetry 二进制文件的源码仓库。 |
+| loglevel repository | https://github.com/rancher/loglevel | loglevel 二进制文件的源码仓库，用于动态更改日志级别。 |
+
+要查看 Rancher 使用的所有库/项目，请查看 `rancher/rancher` 仓库中的 [`go.mod` 文件](https://github.com/rancher/rancher/blob/master/go.mod)。
+
+![Rancher diagram](/img/ranchercomponentsdiagram-2.6.svg)<br/>
+<sup>用于配置/管理 Kubernetes 集群的 Rancher 组件。</sup>
+
+### 构建 Rancher 仓库
+
+每个仓库都应该有一个 Makefile，并且可以使用 `make` 命令进行构建。`make` 目标基于仓库中 `/scripts` 目录中的脚本，每个目标都使用 [Dapper](https://github.com/rancher/dapper) 在孤立的环境中运行。`Dockerfile.dapper` 将用于此操作，它包含了所需的所有构建工具。
+
+默认目标是 `ci`，它将运行 `./scripts/validate`、`./scripts/build`、`./scripts/test ` 和 `./scripts/package`。生成的二进制文件将在 `./build/bin` 中，通常也打包在 Docker 镜像中。
+
+### Rancher Bug、Issue 或疑问
+
+如果你发现任何 bug 或问题，由于有人可能遇到过同样的问题，或者我们已经正在寻找解决方案，因此请先在[已报告 issue](https://github.com/rancher/rancher/issues) 中搜索。
+
+如果找不到与你的问题相关的内容，请通过[提出 issue](https://github.com/rancher/rancher/issues/new) 与我们联系。与 Rancher 相关的仓库有很多，但请将 issue 提交到 Rancher 仓库中，这样能确保我们能看到这些 issue。如果你想就一个用例提出问题或询问其他用户，你可以在 [Rancher 论坛](https://forums.rancher.com)上发帖。
+
+#### 提交 Issue 的检查清单
+
+提交问题时请遵循此清单，以便我们调查和解决问题。如果你能提供更多信息，我们就可以使用更多数据来确定导致问题的原因或发现更多相关的内容。
+
+:::note
+
+如果数据量很大，请使用 [GitHub Gist](https://gist.github.com/) 或类似工具，并在 issue 中链接你创建的资源。
+
+:::
+
+:::note 重要提示：
+
+请删除所有敏感数据。
+
+:::
+
+- **资源**：请尽量详细地提供所使用的资源。导致问题的原因可能很多，因此请尽量提供更多细节来帮助我们确定根本原因。下面是一些参考示例：
+   - **主机**：主机的规格（例如 CPU/内存/磁盘），运行在什么云厂商上，使用的 Amazon Machine Image，使用的 DigitalOcean droplet，配置的镜像（复现时用于重新构建或使用）。
+   - **操作系统**：使用的是什么操作系统。在此处提供详细信息，例如 `cat /etc/os-release` 的输出（确切的操作系统版本）和 `uname -r` 的输出（确切的内核）。
+   - **Docker**：使用的 Docker 版本以及安装的方法。Docker 的大部分详情都可以在 `docker version` 和 `docker info` 的输出中找到。
+   - **环境**：是否使用了代理，是否使用可信的 CA/自签名证书，是否使用了外部负载均衡器。
+   - **Rancher**：使用的 Rancher 版本，可以在 UI 左下角或者从主机运行的 image 标签中获取。
+   - **集群**：创建了什么样的集群，如何创建的，在创建时指定了什么参数。
+- **复现 issue 的步骤**：尽量详细地说明你是如何触发所报告的情况的。这有助于复现你的情况。
+   - 提供从创建到你报告的情况使用的手动步骤或自动化脚本。
+- **日志**：提供使用资源的数据/日志。
+   - Rancher
+      - Docker 安装
+
+      ```
+      docker logs \
+      --timestamps \
+      $(docker ps | grep -E "rancher/rancher:|rancher/rancher " | awk '{ print $1 }')
+      ```
+      - 使用 `kubectl` 的 Kubernetes 安装
+
+      :::note
+
+      确保你配置了正确的 kubeconfig（例如，如果 Rancher 安装在 Kubernetes 集群上，则 `export KUBECONFIG=$PWD/kube_config_cluster.yml`）或通过 UI 使用了嵌入式 kubectl。
+
+      :::
+
+      ```
+      kubectl -n cattle-system \
+      logs \
+      -l app=rancher \
+      --timestamps=true
+      ```
+   - 系统日志记录（可能不存在，取决于操作系统）
+      - `/var/log/messages`
+      - `/var/log/syslog`
+      - `/var/log/kern.log`
+   - Docker Daemon 日志记录（可能并不全部存在，取决于操作系统）
+      - `/var/log/docker.log`
+- **指标**：如果你遇到性能问题，请提供尽可能多的指标数据（文件或屏幕截图）来帮助我们确定问题。如果你遇到主机相关的问题，你可以提供 `top`、`free -m`、`df` 的输出，这些输出会显示进程/内存/磁盘的使用情况。
@@ -0,0 +1,169 @@
+---
+title: CNI 网络插件
+description: 了解容器网络接口 (CNI)、Rancher 提供的 CNI 网络插件、提供商的功能，以及如何选择网络提供商
+---
+
+## 什么是 CNI？
+
+CNI（容器网络接口）是一个[云原生计算基金会项目](https://cncf.io/)，它包含了一些规范和库，用于编写在 Linux 容器中配置网络接口的一系列插件。CNI 只关注容器的网络连接，并在容器被删除时移除所分配的资源。
+
+Kubernetes 使用 CNI 作为网络提供商和 Kubernetes Pod 网络之间的接口。
+
+![CNI Logo](/img/cni-logo.png)
+
+有关更多信息，请访问 [CNI GitHub 项目](https://github.com/containernetworking/cni)。
+
+## CNI 使用了哪些网络模型？
+
+CNI 网络插件使用封装网络模型（例如 Virtual Extensible Lan，缩写是 [VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan)）或非封装网络模型（例如 Border Gateway Protocol，缩写是 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)）来实现网络结构。
+
+### 什么是封装网络？
+
+此网络模型提供了一个逻辑二层（L2）网络，该网络封装在跨 Kubernetes 集群节点的现有三层（L3）网络拓扑上。使用此模型，你可以为容器提供一个隔离的 L2 网络，而无需分发路由。封装网络带来了少量的处理开销以及由于覆盖封装生成 IP header 造成的 IP 包大小增加。封装信息由 Kubernetes worker 之间的 UDP 端口分发，交换如何访问 MAC 地址的网络控制平面信息。此类网络模型中常用的封装是 VXLAN、Internet 协议安全性 (IPSec) 和 IP-in-IP。
+
+简单来说，这种网络模型在 Kubernetes worker 之间生成了一种扩展网桥，其中连接了 pod。
+
+如果你偏向使用扩展 L2 网桥，则可以选择此网络模型。此网络模型对 Kubernetes worker 的 L3 网络延迟很敏感。如果数据中心位于不同的地理位置，请确保它们之间的延迟较低，以避免最终的网络分段。
+
+使用这种网络模型的 CNI 网络插件包括 Flannel、Canal、Weave 和 Cilium。默认情况下，Calico 不会使用此模型，但你可以对其进行配置。
+
+![封装网络](/img/encapsulated-network.png)
+
+### 什么是非封装网络？
+
+该网络模型提供了一个 L3 网络，用于在容器之间路由数据包。此模型不会生成隔离的 L2 网络，也不会产生开销。这些好处的代价是，Kubernetes worker 必须管理所需的所有路由分发。该网络模型不使用 IP header 进行封装，而是使用 Kubernetes Worker 之间的网络协议来分发路由信息以实现 Pod 连接，例如 [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)。
+
+简而言之，这种网络模型在 Kubernetes worker 之间生成了一种扩展网络路由器，提供了如何连接 Pod 的信息。
+
+如果你偏向使用 L3 网络，则可以选择此网络模型。此模型在操作系统级别为 Kubernetes Worker 动态更新路由。对延迟较不敏感。
+
+使用这种网络模型的 CNI 网络插件包括 Calico 和 Cilium。Cilium 可以使用此模型进行配置，即使这不是默认模式。
+
+![非封装网络](/img/unencapsulated-network.png)
+
+## Rancher 提供哪些 CNI 插件？
+
+### RKE2 Kubernetes 集群
+
+Rancher 开箱即用地为 RKE2 Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Calico 和 Cilium。
+
+如果你使用 Rancher 创建新的 Kubernetes 集群，你可以选择你的 CNI 网络插件。
+
+#### Calico
+
+![Calico Logo](/img/calico-logo.png)
+
+Calico 在云上的 Kubernetes 集群中启用网络和网络策略。默认情况下，Calico 使用纯净、未封装的 IP 网络结构和策略引擎为 Kubernetes 工作负载提供网络。工作负载能够使用 BGP 在云上和本地进行通信。
+
+Calico 还提供了一种无状态的 IP-in-IP 或 VXLAN 封装模式。如果需要，你可以使用它。Calico 还支持策略隔离，让你使用高级 ingress 和 egress 策略保护和管理 Kubernetes 工作负载。
+
+如果使用 BGP，Kubernetes Worker 需要打开 TCP 端口 `179`，如果使用 VXLAN 封装，则需要打开 UDP 端口 `4789`。另外，使用 Typha 时需要 TCP 端口 `5473`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#网络要求)。
+
+:::note 重要提示：
+
+在 Rancher 2.6.3 中，Calico 探测到在安装 RKE2 时 Windows 节点会失败。<b>请注意，此问题已在 v2.6.4 中解决。</b>
+
+- 要解决此问题，请先导航到 `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`。
+
+- 在那里，将当前设置 `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` 更改为新设置 `https://raw.githubusercontent .com/rancher/rke2/master/windows/rke2-install.ps1`。
+
+:::
+
+![Calico Diagram](/img/calico-diagram.svg)
+
+有关详细信息，请参阅以下页面：
+
+- [Project Calico 官方网站](https://www.projectcalico.org/)
+- [Calico 项目 GitHub 页面](https://github.com/projectcalico/calico)
+
+#### Canal
+
+![Canal Logo](/img/canal-logo.png)
+
+Canal 是一个 CNI 网络插件，它很好地结合了 Flannel 和 Calico 的优点。它让你轻松地将 Calico 和 Flannel 网络部署为统一的网络解决方案，将 Calico 的网络策略执行与 Calico（未封装）和 Flannel（封装）丰富的网络连接选项结合起来。
+
+Canal 是 Rancher 默认的 CNI 网络插件，并采用了 Flannel 和 VXLAN 封装。
+
+Kubernetes Worker 需要打开 UDP 端口 `8472` (VXLAN) 和 TCP 端口 `9099`（健康检查）。如果使用 Wireguard，则需要打开 UDP 端口 `51820` 和 `51821`。有关详细信息，请参阅[下游集群的端口要求](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)。
+
+![](/img/canal-diagram.png)
+
+有关详细信息，请参阅 [Canal GitHub 页面](https://github.com/projectcalico/canal)
+
+#### Cilium
+
+![Cilium Logo](/img/cilium-logo.png)
+
+Cilium 在 Kubernetes 中启用网络和网络策略（L3、L4 和 L7）。默认情况下，Cilium 使用 eBPF 技术在节点内部路由数据包，并使用 VXLAN 将数据包发送到其他节点。你也可以配置非封装的技术。
+
+Cilium 推荐大于 5.2 的内核版本，从而充分利用 eBPF 的能力。Kubernetes worker 需要打开 TCP 端口 `8472`（VXLAN）和 TCP 端口 `4240`（健康检查）。此外，还必须为健康检查启用 ICMP 8/0。有关详细信息，请查看 [Cilium 系统要求](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements)。
+
+##### Cilium 中跨节点的 Ingress 路由
+<br/>
+默认情况下，Cilium 不允许 Pod 与其他节点上的 Pod 通信。要解决此问题，请启用 Ingress Controller 以使用 “CiliumNetworkPolicy” 进行跨节点路由请求。
+
+选择 Cilium CNI 并为新集群启用项目网络隔离后，配置如下：
+
+```
+apiVersion: cilium.io/v2
+kind: CiliumNetworkPolicy
+metadata:
+  name: hn-nodes
+  namespace: default
+spec:
+  endpointSelector: {}
+  ingress:
+    - fromEntities:
+      - remote-node
+```
+
+## 各个网络插件的 CNI 功能
+
+下表总结了 Rancher 中每个 CNI 网络插件支持的不同功能：
+
+| 提供商 | 网络模型 | 路线分发 | 网络策略 | 网格 | 外部数据存储 | 加密 | Ingress/Egress 策略 |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| Canal | 封装 (VXLAN) | 否 | 是 | 否 | K8s API | 是 | 是 |
+| Flannel | 封装 (VXLAN) | 否 | 否 | 否 | K8s API | 是 | 否 |
+| Calico | 封装（VXLAN，IPIP）或未封装 | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
+| Weave | 封装 | 是 | 是 | 是 | 否 | 是 | 是 |
+| Cilium | 封装 (VXLAN) | 是 | 是 | 是 | Etcd 和 K8s API | 是 | 是 |
+
+- 网络模型：封装或未封装。如需更多信息，请参阅 [CNI 中使用的网络模型](#cni-使用了哪些网络模型)。
+
+- 路由分发：一种外部网关协议，用于在互联网上交换路由和可达性信息。BGP 可以帮助进行跨集群 pod 之间的网络。此功能对于未封装的 CNI 网络插件是必须的，并且通常由 BGP 完成。如果你想构建跨网段拆分的集群，路由分发是一个很好的功能。
+
+- 网络策略：Kubernetes 提供了强制执行规则的功能，这些规则决定了哪些 service 可以使用网络策略进行相互通信。这是从 Kubernetes 1.7 起稳定的功能，可以与某些网络插件一起使用。
+
+- 网格：允许在不同的 Kubernetes 集群间进行 service 之间的网络通信。
+
+- 外部数据存储：具有此功能的 CNI 网络插件需要一个外部数据存储来存储数据。
+
+- 加密：允许加密和安全的网络控制和数据平面。
+
+- Ingress/Egress 策略：允许你管理 Kubernetes 和非 Kubernetes 通信的路由控制。
+
+
+## CNI 社区人气
+
+下表总结了不同的 GitHub 指标，让你了解每个项目的受欢迎程度和活动。数据收集于 2022 年 1 月。
+
+| 提供商 | 项目 | Stars | Forks | Contributors |
+| ---- | ---- | ---- | ---- | ---- |
+| Canal | https://github.com/projectcalico/canal | 679 | 100 | 21 |
+| Flannel | https://github.com/flannel-io/flannel | 7k | 2.5k | 185 |
+| Calico | https://github.com/projectcalico/calico | 3.1k | 741 | 224 |
+| Weave | https://github.com/weaveworks/weave/ | 6.2k | 635 | 84 |
+| Cilium | https://github.com/cilium/cilium | 10.6k | 1.3k | 352 |
+
+<br/>
+
+## 使用哪个 CNI 插件？
+
+这取决于你的项目需求。各个提供商都有不同的功能和选项。没有一个提供商可以满足所有用户的需求。
+
+Canal 是默认的 CNI 网络插件。对于大多数用例，我们推荐你使用它。它使用 Flannel 为容器提供封装网络，同时添加 Calico 网络策略，可以在网络方面提供项目/命名空间隔离。
+
+## 如何配置 CNI 网络插件？
+
+如需了解如何为你的集群配置网络插件，请参阅[集群选项](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md)。有关更高级的配置选项，请参阅有关使用[配置文件](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-集群配置文件参考)和[网络插件](https://rancher.com/docs/rke/latest/en/config-options/add-ons/network-plugins/)选项来配置集群的说明。
@@ -0,0 +1,24 @@
+---
+title: Rancher 中已弃用的功能
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/deprecated-features"/>
+</head>
+
+## Rancher 的弃用策略是什么？
+
+我们已经在支持的[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方的弃用策略。
+
+## 在哪里可以了解 Rancher 中已弃用哪些功能？
+
+Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：
+
+| Patch 版本                                                         | 发布时间            |
+| ----------------------------------------------------------------- | ------------------ |
+| [2.13.1](https://github.com/rancher/rancher/releases/tag/v2.13.1) | 2025 年 12 月 18 日 |
+| [2.13.0](https://github.com/rancher/rancher/releases/tag/v2.13.0) | 2025 年 11 月 25 日 |
+
+## 当一个功能被标记为弃用我可以得到什么样的预期？
+
+当功能被标记为“已弃用”时，它依然可用并得到支持，允许按照常规的流程进行升级。一旦升级完成，用户/管理员应开始计划在升级到标记为已移除的版本之前放弃使用已弃用的功能。对于新的部署，建议不要使用已弃用的功能。
@@ -0,0 +1,51 @@
+---
+title: 一般常见问题解答
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/faq/general-faq"/>
+</head>
+
+本文包含了用户常见的 Rancher 2.x 问题。
+
+有关常见技术问题，请参阅[常见技术问题解答](technical-items.md)。
+
+## Rancher 2.x 支持 Docker Swarm 和 Mesos 作为环境类型吗？
+
+如果你在 Rancher 2.x 中创建环境，Swarm 和 Mesos 将不再是可选的标准选项。但是，Swarm 和 Mesos 还能继续作为可以部署的商店应用程序。这是一个艰难的决定，但这是大势所趋。比如说，15,000 多个集群可能只有大约 200 个在运行 Swarm。
+
+## 是否可以使用 Rancher 2.x 管理 Azure Kubernetes 服务？
+
+是的。请参阅我们的[集群管理](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md)指南，了解 AKS 上可用的 Rancher 功能，以及相关的 [AKS 的文档](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)
+
+## Rancher 是否支持 Windows？
+
+Rancher 支持 Windows Server 1809 容器。有关如何使用 Windows Worker 节点设置集群的详细信息，请参阅[为 Windows 配置自定义集群](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)。
+
+## Rancher 是否支持 Istio？
+
+Rancher 支持 [Istio](../integrations-in-rancher/istio/istio.md)。
+
+## Rancher 2.x 是否支持使用 Hashicorp 的 Vault 来存储密文？
+
+密文管理已在我们的 roadmap 上，但我们尚未将该功能分配给特定版本。
+
+## Rancher 2.x 是否也支持 RKT 容器？
+
+目前，我们只支持 Docker。
+
+## Rancher 2.x 是否支持将 Calico、Contiv、Contrail、Flannel、Weave net 等网络插件用于嵌入和已注册的 Kubernetes？
+
+Rancher 开箱即用地为 Kubernetes 集群提供了几个 CNI 网络插件，分别是 Canal、Flannel、Calico 和 Weave。有关官方支持的详细信息，请参阅 [Rancher 支持矩阵](https://rancher.com/support-maintenance-terms/)。
+
+## Rancher 是否计划支持 Traefik？
+
+目前，我们不打算提供嵌入式 Traefik 支持，但我们仍在探索负载均衡方案。
+
+## 我可以将 OpenShift Kubernetes 集群导入 2.x 吗？
+
+我们的目标是运行任何上游 Kubernetes 集群。因此，Rancher 2.x 应该可以与 OpenShift 一起使用，但我们尚未对此进行测试。
+
+## Rancher 会集成 Longhorn 吗？
+
+是的。Longhorn 已集成到 Rancher 2.5+ 中。
@@ -0,0 +1,23 @@
+---
+title: 安装和配置 kubectl
+---
+
+`kubectl` 是一个 CLI 工具，用于运行 Kubernetes 集群相关的命令。Rancher 2.x 中的许多维护和管理任务都需要它。
+
+## 安装
+
+请参阅 [kubectl 安装](https://kubernetes.io/docs/tasks/tools/install-kubectl/)将 kubectl 安装到你的操作系统上。
+
+## 配置
+
+When you create a Kubernetes cluster with RKE2/K3s, the Kubeconfig file is stored at `/etc/rancher/rke2/rke2.yaml` or `/etc/rancher/k3s/k3s.yaml` depending on your chosen distribution. These files are used to configure access to the Kubernetes cluster.
+
+使用 `kubectl` 测试你的连接性，并查看你是否可以获取节点列表：
+
+```shell
+kubectl get nodes
+ NAME                          STATUS    ROLES                      AGE       VERSION
+165.227.114.63                Ready     controlplane,etcd,worker   11m       v1.10.1
+165.227.116.167               Ready     controlplane,etcd,worker   11m       v1.10.1
+165.227.127.226               Ready     controlplane,etcd,worker   11m       v1.10.1
+```
@@ -0,0 +1,60 @@
+---
+title: 卸载 Rancher
+---
+
+本文介绍了如果你不再需要 Rancher、不想再由 Rancher 管理集群、或想删除 Rancher Server 需要怎么做。
+
+## 如果 Rancher Server 被删除，下游集群中的工作负载会怎样？
+
+如果 Rancher 删除了或无法恢复，Rancher 管理的下游 Kubernetes 集群中的所有工作负载将继续正常运行。
+
+## 如果删除了 Rancher Server，该如何访问下游集群？
+
+如果删除了 Rancher，访问下游集群的方式取决于集群的类型和集群的创建方式。总而言之：
+
+- **Registered/Imported clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
+- **托管的 Kubernetes 集群**：如果你在 Kubernetes 云提供商（例如 EKS、GKE 或 AKS）中创建集群，你可以继续使用提供商的云凭证来管理集群。
+- **Rancher provisioned clusters:** To access an [RKE2/K3s cluster](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
+
+## 如果我不想再使用 Rancher 了该怎么做？
+
+:::note
+
+之前推荐的 [System Tools](../reference-guides/system-tools.md) 自 2022 年 6 月起已弃用。
+
+:::
+
+如果你[在 Kubernetes 集群上安装了 Rancher](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)，你可以使用 [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) 工具删除 Rancher。
+
+在高可用 (HA) 模式下卸载 Rancher 还将删除所有 `helm-operation-*` Pod 和以下应用程序：
+
+- fleet
+- fleet-agent
+- rancher-operator
+- rancher-webhook
+
+自定义资源 (CRD) 和自定义命名空间仍需要手动删除。
+
+如果你在 Docker 中安装 Rancher，则可以通过删除运行 Rancher 的单个 Docker 容器来卸载 Rancher。
+
+移除 Rancher 不会影响导入的集群。有关其他集群类型，请参考[移除 Rancher 后访问下游集群](#如果删除了-rancher-server该如何访问下游集群)。
+
+## 如果我不想 Rancher 管理我的注册集群该怎么办？
+
+如果你在 Rancher UI 中删除了已注册的集群，则该集群将与 Rancher 分离，集群不会发生改变，你可以使用注册集群之前的方法访问该集群。
+
+要分离集群：
+
+1. 在左上角，单击 **☰ > 集群管理**。
+2. 转到要与 Rancher 分离的已注册集群，然后单击 **⋮ > 删除**。
+3. 单击**删除**。
+
+**结果**：注册的集群已与 Rancher 分离，并在 Rancher 外正常运行。
+
+## What if I don't want my hosted Kubernetes cluster managed by Rancher?
+
+目前，我们没有将这些集群从 Rancher 中分离出来的功能。在这种情况下，“分离”指的是将 Rancher 组件移除出集群，并独立于 Rancher 管理对集群的访问。
+
+[此 issue](https://github.com/rancher/rancher/issues/25234) 跟踪了在没有 Rancher 的情况下管理这些集群的功能。
+
+有关如何在删除 Rancher Server 后访问集群的更多信息，请参阅[本节](#如果删除了-rancher-server该如何访问下游集群)。
@@ -0,0 +1,14 @@
+---
+title: 安全
+
+---
+
+**是否有强化指南？**
+
+强化指南现在位于[安全](../reference-guides/rancher-security/rancher-security.md)部分。
+
+<br/>
+
+**Rancher Kubernetes 集群 CIS Benchmark 测试的结果是什么？**
+
+我们已经针对强化的 Rancher Kubernetes 集群运行了 CIS Kubernetes Benchmark 测试。你可以在[安全](../reference-guides/rancher-security/rancher-security.md)中找到该评估的结果。
@@ -0,0 +1,180 @@
+---
+title: 技术
+---
+
+## 如何重置管理员密码？
+
+Docker 安装：
+
+```
+$ docker exec -ti <container_id> reset-password
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+Kubernetes 安装（Helm）：
+
+```
+$ KUBECONFIG=./kube_config_cluster.yml
+$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+## 我删除/停用了最后一个 admin，该如何解决？
+
+Docker 安装：
+
+```
+$ docker exec -ti <container_id> ensure-default-admin
+New default administrator (user-xxxxx)
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+Kubernetes 安装（Helm）：
+
+```
+$ KUBECONFIG=./kube_config_cluster.yml
+$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
+New password for default administrator (user-xxxxx):
+<new_password>
+```
+
+## 如何启用调试日志记录？
+
+请参阅[故障排除：日志记录](../troubleshooting/other-troubleshooting-tips/logging.md)。
+
+## 我的 ClusterIP 不响应 ping，该如何解决？
+
+ClusterIP 是一个虚拟 IP，不会响应 ping。要测试 ClusterIP 是否配置正确，最好的方法是使用 `curl` 访问 IP 和端口并检查它是否响应。
+
+## 在哪里管理节点模板？
+
+打开你的账号菜单（右上角）并选择`节点模板`。
+
+## 为什么我的四层负载均衡器处于 `Pending` 状态？
+
+四层负载均衡器创建为 `type: LoadBalancer`。Kubernetes 需要一个可以满足这些请求的云提供商或控制器，否则这些请求将永远处于 `Pending` 状态。有关更多信息，请参阅[云提供商](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md)或[创建外部负载均衡器](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)。
+
+## Rancher 的状态存储在哪里？
+
+- Docker 安装：在 `rancher/rancher` 容器的嵌入式 etcd 中，位于 `/var/lib/rancher`。
+- Kubernetes install: default location is in the `/var/lib/rancher/rke2` or `/var/lib/rancher/k3s` directories of the respective RKE2/K3s cluster created to run Rancher.
+
+## 支持的 Docker 版本是如何确定的？
+
+我们遵循上游 Kubernetes 版本验证过的 Docker 版本。如果需要获取验证过的版本，请查看 Kubernetes 版本 CHANGELOG.md 中的 [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies)。
+
+## 如何访问 Rancher 创建的节点？
+
+你可以转到**节点**视图，然后下载用于访问 Rancher 创建的节点的 SSH 密钥。选择要访问的节点并单击行尾 **⋮** 按钮，然后选择**下载密钥**，如下图所示。
+
+![下载密钥](/img/downloadsshkeys.png)
+
+解压缩下载的 zip 文件，并使用 `id_rsa` 文件连接到你的主机。请务必使用正确的用户名（如果是 RancherOS，则使用 `rancher` 或 `docker`；如果是 Ubuntu，则使用 `ubuntu`；如果是 Amazon Linux，则使用 `ec2-user`）。
+
+```
+$ ssh -i id_rsa user@ip_of_node
+```
+
+## 如何在 Rancher 中自动化任务 X？
+
+UI 由静态文件组成，并根据 API 的响应工作。换言之，UI 中可以执行的每个操作/任务都可以通过 API 进行自动化。有两种方法可以实现这一点：
+
+* 访问 `https://your_rancher_ip/v3` 并浏览 API 选项。
+* 在使用 UI 时捕获 API 调用（通常使用 [Chrome 开发者工具](https://developers.google.com/web/tools/chrome-devtools/#network)，但你也可以使用其他工具）。
+
+## 节点的 IP 地址改变了，该如何恢复？
+
+节点需要配置静态 IP（或使用 DHCP 保留的 IP）。如果节点的 IP 已更改，你必须在集群中删除并重新添加它。删除后，Rancher 会将集群更新为正确的状态。如果集群不再处于 `Provisioning` 状态，则已从集群删除该节点。
+
+节点的 IP 地址发生变化时，Rancher 会失去与节点的连接，因此无法正常清理节点。请参阅[清理集群节点](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md)来清理节点。
+
+在集群中移除并清理节点时，你可以将节点重新添加到集群中。
+
+## 如何将其他参数/绑定/环境变量添加到 Rancher 启动的 Kubernetes 集群的 Kubernetes 组件中？
+
+You can add more arguments/binds/environment variables via the respective [RKE2 Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md#cluster-configuration) or [K3s Config File](../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md#cluster-configuration).
+
+## 如何检查证书链是否有效？
+
+使用 `openssl verify` 命令来验证你的证书链：
+
+:::tip
+
+将 `SSL_CERT_DIR` 和 `SSL_CERT_FILE` 配置到虚拟位置，从而确保在手动验证时不使用操作系统安装的证书。
+
+:::
+
+```
+SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem rancher.yourdomain.com.pem
+rancher.yourdomain.com.pem: OK
+```
+
+如果你看到 `unable to get local issuer certificate` 错误，则表示链不完整。通常情况下，这表示你的服务器证书由中间 CA 颁发。如果你已经拥有此证书，你可以在证书的验证中使用它，如下所示：
+
+```
+SSL_CERT_DIR=/dummy SSL_CERT_FILE=/dummy openssl verify -CAfile ca.pem -untrusted intermediate.pem rancher.yourdomain.com.pem
+rancher.yourdomain.com.pem: OK
+```
+
+如果你已成功验证证书链，你需要在服务器证书中包含所需的中间 CA 证书，从而完成与 Rancher 连接的证书链（例如，使用 Rancher Agent）。服务器证书文件中证书的顺序首先是服务器证书本身（`rancher.yourdomain.com.pem` 的内容），然后是中间 CA 证书（`intermediate.pem` 的内容）：
+
+```
+-----BEGIN CERTIFICATE-----
+%YOUR_CERTIFICATE%
+-----END CERTIFICATE-----
+-----BEGIN CERTIFICATE-----
+%YOUR_INTERMEDIATE_CERTIFICATE%
+-----END CERTIFICATE-----
+```
+
+如果在验证过程中仍然出现错误，你可以运行以下命令，检索服务器证书的主题和颁发者：
+
+```
+openssl x509 -noout -subject -issuer -in rancher.yourdomain.com.pem
+subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com
+issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
+```
+
+## 如何在服务器证书中检查 `Common Name` 和 `Subject Alternative Names`？
+
+虽然技术上仅需要 `Subject Alternative Names` 中有一个条目，但在 `Common Name` 和 `Subject Alternative Names` 中都包含主机名可以最大程度地提高与旧版浏览器/应用程序的兼容性。
+
+检查 `Common Name`：
+
+```
+openssl x509 -noout -subject -in cert.pem
+subject= /CN=rancher.my.org
+```
+
+检查 `Subject Alternative Names`：
+
+```
+openssl x509 -noout -in cert.pem -text | grep DNS
+                DNS:rancher.my.org
+```
+
+## 为什么节点发生故障时重新调度一个 pod 需要 5 分钟以上的时间？
+
+这是以下默认 Kubernetes 设置的组合导致的：
+
+* kubelet
+   * `node-status-update-frequency`：指定 kubelet 将节点状态发布到 master 的频率（默认 10s）。
+* kube-controller-manager
+   * `node-monitor-period`：在 NodeController 中同步 NodeStatus 的周期（默认 5s）。
+   * `node-monitor-grace-period`：在将节点标记为不健康之前，允许节点无响应的时间长度（默认 40s）。
+   * `pod-eviction-timeout`：在故障节点上删除 pod 的宽限期（默认 5m0s）。
+
+有关这些设置的更多信息，请参阅 [Kubernetes：kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 和 [Kubernetes：kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)。
+
+Kubernetes 1.13 默认启用 `TaintBasedEvictions` 功能。有关详细信息，请参阅 [Kubernetes：基于污点的驱逐](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions)。
+
+* kube-apiserver（Kubernetes 1.13 及更高版本）
+   * `default-not-ready-toleration-seconds`：表示 `notReady:NoExecute` 的容忍度的 `tolerationSeconds`，该设置默认添加到还没有该容忍度的 pod。
+   * `default-unreachable-toleration-seconds`：表示 `unreachable:NoExecute` 的容忍度的 `tolerationSeconds`，该设置默认添加到还没有该容忍度的 pod。
+
+## 我可以在 UI 中使用键盘快捷键吗？
+
+是的，你可以使用键盘快捷键访问 UI 的大部分内容。要查看快捷方式的概览，请在 UI 任意位置按 `?`。
@@ -0,0 +1,31 @@
+---
+title: 遥测
+---
+
+## 什么是遥测？
+
+遥测（Telemetry）收集 Rancher 安装大小、使用的组件版本以及使用功能的汇总信息。Rancher Labs 会使用此信息来改进产品，我们不会与第三方共享此信息。
+
+## 收集什么信息？
+
+我们不会收集任何识别信息（如用户名、密码或用户资源的名称或地址）。
+
+收集的主要内容包括：
+
+- 每个集群的节点总数（最小、平均、最大、总数）及其大小（例如 CPU 核心数和 RAM）。
+- 集群、项目、命名空间和 Pod 等逻辑资源的聚合计数。
+- 用于部署集群和节点的驱动程序计数（例如 GKE、EC2、导入与自定义）。
+- 部署在节点上的 Kubernetes 组件、操作系统和 Docker 的版本。
+- 是否启用了某些可选组件（例如，使用了哪些身份验证提供程序）。
+- 运行的 Rancher 的镜像名称和版本。
+- 此安装的唯一随机标识符。
+
+## 我可以看到发送的信息吗？
+
+如果启用了遥测，你可以转到 `https://<your rancher server>/v1-telemetry` 查看当前数据。
+
+如果未启用遥测，则收集数据的进程未运行，因此没有可供查看的内容。
+
+## 如何打开或关闭它？
+
+完成初始设置后，管理员可以转到 UI `全局`中的`设置`页面，单击**编辑**，然后将 `telemetry-opt` 更改为 `in` 或 `out`。
@@ -0,0 +1,98 @@
+---
+title: 在离线环境中升级
+---
+
+:::note
+
+以下说明假设你已经按照[本页](upgrades.md)的 Kubernetes 升级说明操作（包括先决条件）到步骤 3：升级 Rancher。
+
+:::
+
+## Rancher Helm 模板选项
+
+使用安装 Rancher 时选择的选项来渲染 Rancher 模板。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库，以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
+
+根据你在安装过程中做出的选择，完成以下步骤之一。
+
+| 占位符 | 描述 |
+------------|-------------
+| `<VERSION>` | 输出压缩包的版本号。 |
+| `<RANCHER.YOURDOMAIN.COM>` | 指向负载均衡器的 DNS 名称。 |
+| `<REGISTRY.YOURDOMAIN.COM:PORT>` | 你的私有镜像仓库的 DNS 名称。 |
+| `<CERTMANAGER_VERSION>` | 在 K8s 集群上运行的 cert-manager 版本。 |
+
+### 选项 A：使用默认的自签名证书
+
+```
+helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
+    --no-hooks \ # prevent files for Helm hooks from being generated
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set certmanager.version=<CERTMANAGER_VERSION> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+#### 解决 UPGRADE FAILED 错误
+
+如果你遇到错误消息 `Error: UPGRADE FAILED: "rancher" has no deployed releases`，Rancher 可能是通过 `helm template` 命令安装的。要成功升级 Rancher，请改用以下命令：
+
+```
+helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
+    --no-hooks \ # prevent files for Helm hooks from being generated
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set certmanager.version=<CERTMANAGER_VERSION> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+执行 Helm 命令后，需要应用渲染后的模板：
+
+```
+kubectl -n cattle-system apply -R -f ./rancher
+```
+### 选项 B：使用 Kubernetes 密文从文件中获取证书
+
+```plain
+helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
+	--no-hooks \ # prevent files for Helm hooks from being generated
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set ingress.tls.source=secret \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+如果你使用的是私有 CA 签名的证书，请在 `--set ingress.tls.source=secret` 后加上 `--set privateCA=true`：
+
+```plain
+helm template rancher ./rancher-<VERSION>.tgz --output-dir . \
+	--no-hooks \ # prevent files for Helm hooks from being generated
+	--namespace cattle-system \
+	--set hostname=<RANCHER.YOURDOMAIN.COM> \
+	--set rancherImage=<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher \
+	--set ingress.tls.source=secret \
+	--set privateCA=true \
+	--set systemDefaultRegistry=<REGISTRY.YOURDOMAIN.COM:PORT> \ # Set a default private registry to be used in Rancher
+	--set useBundledSystemChart=true # Use the packaged Rancher system charts
+```
+
+## 验证升级
+
+登录 Rancher 以确认升级成功。
+
+:::tip
+
+升级后出现网络问题？
+
+请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
+
+:::
+
+## 已知升级问题
+
+你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 Rancher 版本的已知问题。
@@ -0,0 +1,347 @@
+---
+title: 在 Kubernetes 集群上安装/升级 Rancher
+description: 了解如何在开发和生产环境中安装 Rancher。了解单节点和高可用安装
+---
+
+在本节中，你将学习如何使用 Helm CLI 在 Kubernetes 集群上部署 Rancher。
+
+
+## 先决条件
+
+- [Kubernetes 集群](#kubernetes-集群)
+- [Ingress Controller](#ingress-controller)
+- [CLI 工具](#cli-工具)
+
+### Kubernetes 集群
+
+设置 Rancher Server 的本地 Kubernetes 集群。
+
+Rancher 可以安装在任何 Kubernetes 集群上。这个集群可以使用上游 Kubernetes，也可以使用 Rancher 的 Kubernetes 发行版之一，也可以是来自 Amazon EKS 等提供商的托管 Kubernetes 集群。
+
+你可参考以下教程，以获得设置 Kubernetes 集群的帮助：
+
+- **K3s**：[安装 K3s Kubernetes 集群的教程](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/k3s-for-rancher.md)；[设置高可用 K3s 集群的基础设施的教程](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-k3s-kubernetes-cluster.md)。
+- **RKE2:** ：[安装 RKE2 Kubernetes 集群的教程](../../../how-to-guides/new-user-guides/kubernetes-cluster-setup/rke2-for-rancher.md)；[设置高可用 RKE2 集群的基础设施的教程](../../../how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md)。
+- **Amazon EKS**：[在 Amazon EKS 上安装 Rancher 以及如何安装 Ingress Controller 以访问 Rancher Server](rancher-on-amazon-eks.md)。
+- **AKS**：[使用 Azure Kubernetes 服务安装 Rancher 以及如何安装 Ingress Controller 以访问 Rancher Server](rancher-on-aks.md)。
+- **GKE**：有关如何使用 GKE 安装 Rancher，包括如何安装 Ingress Controller 以便可以访问 Rancher Server，请参阅[此页面](rancher-on-gke.md)。GKE 创建 Kubernetes 集群时有两种运行模式，分别是 Autopilot 和 Standard 模式。Autopilot 模式的集群配置对编辑 kube-system 命名空间有限制。但是，Rancher 在安装时需要在 kube-system 命名空间中创建资源。因此，你将无法在以 Autopilot 模式创建的 GKE 集群上安装 Rancher。
+
+
+### Ingress Controller
+
+Rancher UI 和 API 通过 Ingress 公开。换言之，安装 Rancher 的 Kubernetes 集群必须包含一个 Ingress Controller。
+
+对于 RKE2 和 K3s，你不需要手动安装 Ingress Controller，因为它是默认安装的。
+
+对于默认不包含 Ingress Controller 的发行版（例如 EKS、GKE 或 AKS 等托管 Kubernetes 集群），你必须先部署 Ingress Controller。请注意，Rancher Helm Chart 默认情况下不会在 Ingress 上设置 `ingressClassName`。因此，你必须将 Ingress Controller 配置为在没有 `ingressClassName` 的情况下也可以监视 Ingress。
+
+上面的 **Amazon EKS**、**AKS** 和 **GKE** 教程中包含了示例。
+
+### CLI 工具
+
+设置 Kubernetes 集群需要以下 CLI 工具。请确保这些工具已安装并在你的 `$PATH` 中可用。
+
+- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes 命令行工具。
+- [Helm](https://docs.helm.sh/using_helm/#installing-helm) - Kubernetes 的包管理器。请参见 [Helm 版本要求](../resources/helm-version-requirements.md)选择 Helm 版本来安装 Rancher。请为你的具体平台参见 [Helm 项目提供的说明](https://helm.sh/docs/intro/install/)。
+
+## 安装 Rancher Helm Chart
+
+Rancher 是使用 Kubernetes 的 [Helm](https://helm.sh/) 包管理器安装的。Helm Chart 为 Kubernetes YAML 清单文件提供了模板语法。通过 Helm，用户可以创建可配置的 deployment，而不仅仅只能使用静态文件。
+
+如果系统无法直接访问互联网，请参见[离线环境：Kubernetes 安装](../other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)。
+
+如果要指定安装的 Rancher 版本，请参见[选择 Rancher 版本](../resources/choose-a-rancher-version.md)。
+
+如果要指定用于安装 Rancher 的 Helm 版本，请参见[Helm 版本要求](../resources/helm-version-requirements.md)。
+
+:::note
+
+本安装指南假定你使用的是 Helm 3。
+
+:::
+
+要设置 Rancher：
+
+1. [添加 Helm Chart 仓库](#1-添加-helm-chart-仓库)
+2. [为 Rancher 创建命名空间](#2-为-rancher-创建命名空间)
+3. [选择 SSL 配置](#3-选择-ssl-配置)
+4. [安装 cert-manager](#4-安装-cert-manager)（除非你自带证书，否则 TLS 将在负载均衡器上终止）
+5. [使用 Helm 和你选择的证书选项安装 Rancher](#5-根据你选择的证书选项通过-helm-安装-rancher)
+6. [验证 Rancher Server 是否部署成功](#6-验证-rancher-server-是否部署成功)
+7. [保存选项](#7-保存选项)
+
+### 1. 添加 Helm Chart 仓库
+
+执行 `helm repo add` 命令，以添加包含安装 Rancher 的 Chart 的 Helm Chart 仓库。有关如何选择仓库，以及哪个仓库最适合你的用例，请参见[选择 Rancher 版本](../resources/choose-a-rancher-version.md)。
+
+- Latest：建议用于试用最新功能
+   ```
+   helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+   ```
+- Stable：建议用于生产环境
+   ```
+   helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+   ```
+- Alpha：即将发布的实验性预览。
+   ```
+   helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
+   ```
+   注意：不支持升级到 Alpha 版、从 Alpha 版升级或在 Alpha 版之间升级。
+
+### 2. 为 Rancher 创建命名空间
+
+你需要定义一个 Kubernetes 命名空间，用于安装由 Chart 创建的资源。这个命名空间的名称为 `cattle-system`：
+
+```
+kubectl create namespace cattle-system
+```
+
+### 3. 选择 SSL 配置
+
+Rancher Management Server 默认需要 SSL/TLS 配置来保证访问的安全性。
+
+:::note
+
+如果你想在外部终止 SSL/TLS，请参见[外部负载均衡器的 TLS 终止](../installation-references/helm-chart-options.md#外部-tls-终止)。
+
+:::
+
+你可以从以下三种证书来源中选择一种，用于在 Rancher Server 中终止 TLS：
+
+- **Rancher 生成的 TLS 证书**：要求你在集群中安装 `cert-manager`。Rancher 使用 `cert-manager` 签发并维护证书。Rancher 会生成自己的 CA 证书，并使用该 CA 签署证书。然后 `cert-manager`负责管理该证书。
+- **Let's Encrypt**：Let's Encrypt 选项也需要使用 `cert-manager`。但是，在这种情况下，cert-manager 与 Let's Encrypt 的特殊颁发者相结合，该颁发者执行获取 Let's Encrypt 颁发的证书所需的所有操作（包括请求和验证）。此配置使用 HTTP 验证（`HTTP-01`），因此负载均衡器必须具有可以从互联网访问的公共 DNS 记录。
+- **你已有的证书**：使用已有的 CA 颁发的公有或私有证书。Rancher 将使用该证书来保护 WebSocket 和 HTTPS 流量。在这种情况下，你必须上传名称分别为 `tls.crt` 和 `tls.key`的 PEM 格式的证书以及相关的密钥。如果你使用私有 CA，则还必须上传该 CA 证书。这是由于你的节点可能不信任此私有 CA。Rancher 将获取该 CA 证书，并从中生成一个校验和，各种 Rancher 组件将使用该校验和来验证其与 Rancher 的连接。
+
+
+| 配置 | Helm Chart 选项 | 是否需要 cert-manager |
+| ------------------------------ | ----------------------- | ------------------------------------- |
+| Rancher 生成的证书（默认） | `ingress.tls.source=rancher` | [是](#4-安装-cert-manager) |
+| Let’s Encrypt | `ingress.tls.source=letsEncrypt` | [是](#4-安装-cert-manager) |
+| 你已有的证书 | `ingress.tls.source=secret` | 否 |
+
+### 4. 安装 cert-manager
+
+> 如果你使用自己的证书文件（`ingress.tls.source=secret`）或使用[外部负载均衡器的 TLS 终止](../installation-references/helm-chart-options.md#外部-tls-终止)，你可以跳过此步骤。
+
+仅在使用 Rancher 生成的证书（`ingress.tls.source=rancher`）或 Let's Encrypt 颁发的证书（`ingress.tls.source=letsEncrypt`）时，才需要安装 cert-manager。
+
+<details id="cert-manager">
+  <summary>单击展开</summary>
+
+:::note 重要提示：
+
+由于 cert-manager 的最新改动，你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.11.0 的 cert-manager 版本，请参见[升级文档](../resources/upgrade-cert-manager.md)。
+
+:::
+
+这些说明来自 [cert-manager 官方文档](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm)。
+
+:::note
+
+要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
+
+:::
+
+```
+# 如果你手动安装了CRD，而不是在 Helm 安装命令中添加了 `--set installCRDs=true` 选项，你应该在升级 Helm Chart 之前升级 CRD 资源。
+kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
+
+# 添加 Jetstack Helm 仓库
+helm repo add jetstack https://charts.jetstack.io
+
+# 更新本地 Helm Chart 仓库缓存
+helm repo update
+
+# 安装 cert-manager Helm Chart
+helm install cert-manager jetstack/cert-manager \
+  --namespace cert-manager \
+  --create-namespace
+```
+
+安装完 cert-manager 后，你可以通过检查 cert-manager 命名空间中正在运行的 Pod 来验证它是否已正确部署：
+
+```
+kubectl get pods --namespace cert-manager
+
+NAME                                       READY   STATUS    RESTARTS   AGE
+cert-manager-5c6866597-zw7kh               1/1     Running   0          2m
+cert-manager-cainjector-577f6d9fd7-tr77l   1/1     Running   0          2m
+cert-manager-webhook-787858fcdb-nlzsq      1/1     Running   0          2m
+```
+
+</details>
+
+### 5. 根据你选择的证书选项，通过 Helm 安装 Rancher
+
+不同的证书配置需要使用不同的 Rancher 安装命令。
+
+但是，无论证书如何配置，Rancher 在 `cattle-system` 命名空间中的安装名称应该总是 `rancher`。
+
+:::tip 测试和开发：
+
+这个安装 Rancher 的最终命令需要一个将流量转发到 Rancher 的域名。如果你使用 Helm CLI 设置概念证明，则可以在传入 `hostname` 选项时使用伪域名。伪域名的一个例子是 `<IP_OF_LINUX_NODE>.sslip.io`，这会把 Rancher 暴露在它运行的 IP 上。生产安装中要求填写真实的域名。
+
+:::
+
+<Tabs>
+<TabItem value="Rancher 生成的证书">
+
+默认情况是使用 Rancher 生成 CA，并使用 `cert-manager` 颁发用于访问 Rancher Server 接口的证书。
+
+由于 `rancher` 是 `ingress.tls.source` 的默认选项，因此在执行 `helm install` 命令时，我们不需要指定 `ingress.tls.source`。
+
+- 将 `hostname` 设置为解析到你的负载均衡器的 DNS 名称。
+- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
+- 如果你需要安装指定的 Rancher 版本，使用 `--version` 标志，例如 `--version 2.7.0`。
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin
+```
+
+如果你安装的是 alpha 版本，Helm 会要求你在安装命令中添加 `--devel` 选项：
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```
+
+等待 Rancher 运行：
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+</TabItem>
+<TabItem value="Let's Encrypt">
+
+此选项使用 `cert-manager` 来自动请求和续订 [Let's Encrypt](https://letsencrypt.org/) 证书。Let's Encrypt 是免费的，而且是受信的 CA，因此可以为你提供有效的证书。
+
+:::note
+
+由于 HTTP-01 质询只能在端口 80 上完成，因此你需要打开端口 80。
+
+:::
+
+在以下命令中，
+
+- 将 `hostname` 设置为公有 DNS 记录。
+- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
+- 将 `ingress.tls.source` 设置为 `letsEncrypt`。
+- 将 `letsEncrypt.email` 设置为可通讯的电子邮件地址，用于发送通知（例如证书到期的通知）。
+- 将 `letsEncrypt.ingress.class` 设为你的 Ingress Controller（例如 `traefik`，`nginx`，`haproxy`）
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin \
+  --set ingress.tls.source=letsEncrypt \
+  --set letsEncrypt.email=me@example.org \
+  --set letsEncrypt.ingress.class=nginx
+```
+
+如果你安装的是 alpha 版本，Helm 会要求你在安装命令中添加 `--devel` 选项：
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```
+
+等待 Rancher 运行：
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+</TabItem>
+<TabItem value="证书文件">
+在此选项中，你使用你自己的证书来创建 Kubernetes 密文，以供 Rancher 使用。
+
+运行这个命令时，`hostname` 选项必须与服务器证书中的 `Common Name` 或 `Subject Alternative Names` 条目匹配，否则 Ingress controller 将无法正确配置。
+
+虽然技术上仅需要 `Subject Alternative Names` 中有一个条目，但是拥有一个匹配的 `Common Name` 可以最大程度地提高与旧版浏览器/应用的兼容性。
+
+:::note
+
+如果你想检查证书是否正确，请查看[如何在服务器证书中检查 Common Name 和 Subject Alternative Names](../../../faq/technical-items.md#如何在服务器证书中检查-common-name-和-subject-alternative-names)。
+
+:::
+
+- 设置 `hostname`。
+- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
+- 将 `ingress.tls.source` 设置为 `secret`。
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin \
+  --set ingress.tls.source=secret
+```
+如果你安装的是 alpha 版本，Helm 会要求你在安装命令中添加 `--devel` 选项：
+
+```
+helm install rancher rancher-alpha/rancher --devel
+```
+
+如果你使用的是私有 CA 证书，请在命令中增加 `--set privateCA=true`。
+
+```
+helm install rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org \
+  --set bootstrapPassword=admin \
+  --set ingress.tls.source=secret \
+  --set privateCA=true
+```
+
+**添加 TLS 密文（千万不要遗漏此步骤）**：现在 Rancher 已经完成部署，你还需要参考[添加 TLS 密文](../resources/add-tls-secrets.md)发布证书文件，以便 Rancher 和 Ingress Controller 可以使用它们。
+
+</TabItem>
+</Tabs>
+
+Rancher Chart 有许多选项，用于为你的具体环境自定义安装。以下是一些常见的高级方案：
+
+- [HTTP 代理](../installation-references/helm-chart-options.md#http-代理)
+- [私有容器镜像仓库](../installation-references/helm-chart-options.md#私有仓库和离线安装)
+- [外部负载均衡器上的 TLS 终止](../installation-references/helm-chart-options.md#外部-tls-终止)
+
+如需获取完整的选项列表，请参见 [Chart 选项](../installation-references/helm-chart-options.md)。
+
+
+### 6. 验证 Rancher Server 是否部署成功
+
+添加密文后，检查 Rancher 是否已成功运行：
+
+```
+kubectl -n cattle-system rollout status deploy/rancher
+Waiting for deployment "rancher" rollout to finish: 0 of 3 updated replicas are available...
+deployment "rancher" successfully rolled out
+```
+
+如果你看到 `error: deployment "rancher" exceeded its progress deadline` 这个错误，可运行以下命令来检查 deployment 的状态：
+
+```
+kubectl -n cattle-system get deploy rancher
+NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+rancher   3         3         3            3           3m
+```
+
+`DESIRED` 和 `AVAILABLE`的个数应该相同。
+
+### 7. 保存选项
+
+请保存你使用的 `--set` 选项。使用 Helm 升级 Rancher 到新版本时，你将需要使用相同的选项。
+
+### 安装完成
+
+安装已完成。现在 Rancher Server 应该已经可以正常运行了。
+
+使用浏览器打开把流量转发到你的负载均衡器的 DNS 域名。然后，你就会看到一个漂亮的登录页面了。
+
+如果遇到任何问题，请参见[故障排除](troubleshooting.md)。
@@ -0,0 +1,147 @@
+---
+title: 在 Azure Kubernetes Service 上安装 Rancher
+---
+
+本文介绍了如何在微软的 Azure Kubernetes Service (AKS) 上安装 Rancher。
+
+本指南使用命令行工具来配置一个带有 Ingress 的 AKS 集群。如果你更喜欢使用 Azure 门户来配置集群，请参见[官方文档](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal)。
+
+如果你已有一个 AKS Kubernetes 集群，请直接跳到[安装 Ingress](#5-安装-ingress) 的步骤，然后按照[此页](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。
+
+## 先决条件
+
+:::caution
+
+部署到 Microsoft Azure 会产生费用。
+
+:::
+
+- [Microsoft Azure 账号](https://azure.microsoft.com/en-us/free/)：用于创建部署 Rancher 和 Kubernetes 的资源。
+- [Microsoft Azure 订阅](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal)：如果你没有的话，请访问此链接查看如何创建 Microsoft Azure 订阅。
+- [Micsoroft Azure 租户](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant)：访问此链接并参考教程以创建 Microsoft Azure 租户。
+- 你的订阅有足够的配额，至少有 2 个 vCPU。有关 Rancher Server 资源要求的详情，请参见[此节](../installation-requirements/installation-requirements.md)。
+- 在 Azure 中用 Helm 安装 Rancher 时，请使用 L7 负载均衡器来避免网络问题。详情请参见 [Azure 负载均衡器限制](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations)。
+
+## 1. 准备你的工作站
+
+在工作站上安装以下命令行工具：
+
+- **az**，Azure CLI：如需获得帮助，请参见[安装步骤](https://docs.microsoft.com/en-us/cli/azure/)。
+- **kubectl**：如需获得帮助，请参见[安装步骤](https://kubernetes.io/docs/tasks/tools/#kubectl)。
+- **helm**：如需获取帮助，请参见[安装步骤](https://helm.sh/docs/intro/install/)。
+
+## 2. 创建资源组
+
+安装 CLI 后，你需要用你的 Azure 账户登录：
+
+```
+az login
+```
+
+创建一个 [资源组](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal) 来保存集群的所有相关资源。使用一个适用于你实际情况的位置：
+
+```
+az group create --name rancher-rg --location eastus
+```
+
+## 3. 创建 AKS 集群
+
+运行以下命令创建一个 AKS 集群。选择适用于你实际情况的虚拟机大小。如需获得可用的大小和选项，请参见[此处](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes)。在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
+
+:::note
+
+如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
+
+:::
+
+```
+az aks create \
+  --resource-group rancher-rg \
+  --name rancher-server \
+  --kubernetes-version <VERSION> \
+  --node-count 3 \
+  --node-vm-size Standard_D2_v3
+```
+
+集群部署需要一些时间才能完成。
+
+## 4. 获取访问凭证
+
+集群部署完成后，获取访问凭证。
+
+```
+az aks get-credentials --resource-group rancher-rg --name rancher-server
+```
+
+此命令把集群的凭证合并到现有的 kubeconfig 中，并允许 `kubectl` 与集群交互。
+
+## 5. 安装 Ingress
+
+集群需要一个 Ingress，以从集群外部访问 Rancher。要 Ingress，你需要分配一个公共 IP 地址。请确保你有足够的配额，否则它将无法分配 IP 地址。公共 IP 地址的限制在每个订阅的区域级别生效。
+
+为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
+
+然后，运行以下命令列出可用的 Helm Chart：
+
+```
+helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
+helm repo update
+helm search repo ingress-nginx -l
+```
+
+`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.24，则可以选择 v4.6.0 Helm Chart，因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起，而 v1.7.0 与 Kubernetes v1.24 兼容。如有疑问，请选择最新的兼容版本。
+
+了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
+
+```
+helm search repo ingress-nginx -l
+helm upgrade --install \
+  ingress-nginx ingress-nginx/ingress-nginx \
+  --namespace ingress-nginx \
+  --set controller.service.type=LoadBalancer \
+  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz \
+  --set controller.service.externalTrafficPolicy=Local \
+  --version 4.6.0 \
+  --create-namespace
+```
+
+## 6. 获取负载均衡器的 IP
+
+运行以下命令获取负载均衡器的 IP 地址：
+
+```
+kubectl get service ingress-nginx-controller --namespace=ingress-nginx
+```
+
+返回的结果应与以下内容类似：
+
+```
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
+ AGE
+ingress-nginx-controller   LoadBalancer   10.0.116.18    40.31.180.83   80:31229/TCP,443:31050/TCP
+ 67s
+```
+
+保存 `EXTERNAL-IP`。
+
+## 7. 设置 DNS
+
+到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
+
+创建指向你保存的 `EXTERNAL-IP` 的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
+
+设置 DNS 的有效方法有很多。如需获取帮助，请参见 [Azure DNS 文档中心](https://docs.microsoft.com/en-us/azure/dns/)。
+
+## 8. 安装 Rancher Helm Chart
+
+按照[本页](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
+
+安装 Rancher 时，使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如，如果 DNS 名称是 `rancher.my.org`，你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
+
+在此设置之上安装 Rancher 时，你还需要将以下值传递到 Rancher Helm 安装命令，以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称：
+
+```
+--set ingress.ingressClassName=nginx
+```
+
+请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
@@ -0,0 +1,151 @@
+---
+title: 在 Amazon EKS 上安装 Rancher
+---
+
+本文介绍了如何在 Amazon EKS 集群上安装 Rancher。你也可以[通过 AWS Marketplace 安装 Rancher](../../quick-start-guides/deploy-rancher-manager/aws-marketplace.md)。
+
+如果你已经有一个 EKS Kubernetes 集群，请直接跳转到[安装 Ingress](#5-安装-ingress)这个步骤。然后按照[此处](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
+
+## 为 Rancher Server 创建 EKS 集群
+
+在本节中，你将使用命令行工具安装一个带有 Ingress 的 EKS 集群。如果你想在 EKS 上使用 Rancher 时使用较少的资源，请使用此方法。
+
+:::note 先决条件：
+
+- 已有一个 AWS 账户。
+- 建议使用 IAM 用户而不是 AWS 根账户。你将需要 IAM 用户的访问密钥 (access key) 和密文秘钥 (secret key) 来配置 AWS 命令行界面。
+- IAM 用户需要具备[eksctl 文档](https://eksctl.io/usage/minimum-iam-policies/)中描述的最低 IAM 策略。
+
+:::
+
+### 1. 准备你的工作站
+
+在工作站上安装以下命令行工具：
+
+- **AWS CLI v2**：如需获取帮助，请参见[安装步骤](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)。
+- **eksctl**：如需获取帮助，请参见[安装步骤](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)。
+- **kubectl**：如需获得帮助，请参见[安装步骤](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)。
+- **helm**：如需获取帮助，请参见[安装步骤](https://helm.sh/docs/intro/install/)。
+
+### 2. 配置 AWS CLI
+
+运行以下命令，配置 AWS CLI：
+
+```
+aws configure
+```
+
+输入以下参数：
+
+| 值 | 描述 |
+|-------|-------------|
+| AWS Access Key ID | 具有 EKS 权限的 IAM 用户的访问密钥凭证。 |
+| AWS Secret Access Key | 具有 EKS 权限的 IAM 用户的密文密钥凭证。 |
+| Default region name | 集群节点所在的 [AWS 区域](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html#Concepts.RegionsAndAvailabilityZones.Regions)。 |
+| Default output format | 输入 `json`。 |
+
+### 3. 创建 EKS 集群
+
+运行以下命令创建一个 EKS 集群。使用适用于你的用例的 AWS 区域。在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
+
+**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
+
+```
+eksctl create cluster \
+  --name rancher-server \
+  --version <VERSION> \
+  --region us-west-2 \
+  --nodegroup-name ranchernodes \
+  --nodes 3 \
+  --nodes-min 1 \
+  --nodes-max 4 \
+  --managed
+```
+
+使用 CloudFormation 进行的集群部署可能需要一些时间才能完成。
+
+### 4. 测试集群
+
+运行以下命令测试集群：
+
+```
+eksctl get cluster
+```
+
+返回的结果应与以下内容类似：
+
+```
+eksctl get cluster
+2021-03-18 15:09:35 [ℹ]  eksctl version 0.40.0
+2021-03-18 15:09:35 [ℹ]  using region us-west-2
+NAME		REGION		EKSCTL CREATED
+rancher-server-cluster		us-west-2	True
+```
+
+### 5. 安装 Ingress
+
+集群需要一个 Ingress，以从集群外部访问 Rancher。
+
+为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
+
+然后，运行以下命令列出可用的 Helm Chart：
+
+```
+helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
+helm repo update
+helm search repo ingress-nginx -l
+```
+
+`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.23，则可以选择 v4.6.0 Helm Chart，因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起，而 v1.7.0 与 Kubernetes v1.23 兼容。如有疑问，请选择最新的兼容版本。
+
+了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
+
+```
+helm upgrade --install \
+  ingress-nginx ingress-nginx/ingress-nginx \
+  --namespace ingress-nginx \
+  --set controller.service.type=LoadBalancer \
+  --version 4.6.0 \
+  --create-namespace
+```
+
+### 6. 获取负载均衡器的 IP
+
+运行以下命令获取负载均衡器的 IP 地址：
+
+```
+kubectl get service ingress-nginx-controller --namespace=ingress-nginx
+```
+
+返回的结果应与以下内容类似：
+
+```
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP                                                              PORT(S)
+ AGE
+ingress-nginx-controller   LoadBalancer   10.100.90.18   a904a952c73bf4f668a17c46ac7c56ab-962521486.us-west-2.elb.amazonaws.com   80:31229/TCP,443:31050/TCP
+ 27m
+```
+
+保存 `EXTERNAL-IP`。
+
+### 7. 设置 DNS
+
+到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
+
+创建指向你保存的外部 IP 地址的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
+
+设置 DNS 的有效方法有很多。如需获得帮助，请参见 AWS 文档中心的[转发流量到 ELB 负载均衡器](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html)。
+
+### 8. 安装 Rancher Helm Chart
+
+按照[本页](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
+
+安装 Rancher 时，使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如，如果 DNS 名称是 `rancher.my.org`，你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
+
+在此设置之上安装 Rancher 时，你还需要将以下值传递到 Rancher Helm 安装命令，以设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称：
+
+```
+--set ingress.ingressClassName=nginx
+```
+
+请参阅[Helm 安装命令](install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
@@ -0,0 +1,201 @@
+---
+title: 在 GKE 集群上安装 Rancher
+---
+
+在本节中，你将学习如何使用 GKE 安装 Rancher。
+
+如果你已经有一个 GKE Kubernetes 集群，请直接跳转到[安装 Ingress](#7-安装-ingress)这个步骤。然后按照[此处](install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的步骤安装 Rancher Helm Chart。
+
+## 先决条件
+
+- 你需要有一个 Google 账号。
+- 你需要有一个 Google Cloud Billing 账号。你可使用 Google Cloud Console 来管理你的 Cloud Billing 账号。有关 Cloud Console 的详情，请参见 [ Console 通用指南](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599)。
+- 你需要至少一个在用的 IP 地址和至少 2 个 CPU 的云配额。有关 Rancher Server 的硬件要求，请参见[本节](../installation-requirements/installation-requirements.md)。
+
+## 1. 启用 Kubernetes Engine API
+
+按照以下步骤启用 Kubernetes Engine API：
+
+1. 访问 Google Cloud Console 中的 [Kubernetes Engine 页面](https://console.cloud.google.com/projectselector/kubernetes?_ga=2.169595943.767329331.1617810440-856599067.1617343886)。
+1. 创建或选择一个项目。
+1. 打开项目，并为项目启用 Kubernetes Engine API。等待 API 和相关服务的启用。这可能需要几分钟时间。
+1. 确保为你的云项目启用了计费。有关如何为你的项目启用计费，请参见 [Google Cloud 文档中心](https://cloud.google.com/billing/docs/how-to/modify-project#enable_billing_for_a_project)。
+
+## 2. 打开 Cloud Shell
+
+Cloud Shell 是一个 shell 环境，用于管理托管在 Google Cloud 上的资源。Cloud Shell 预装了 `gcloud` 命令行工具和 kubectl 命令行工具中。`gcloud` 工具为 Google Cloud 提供主要的命令行界面，而`kubectl` 则提供针对 Kubernetes 集群的主要命令行界面。
+
+下文描述了如何从 Google Cloud Console 或从本地工作站启动 Cloud Shell。
+
+### Cloud Shell
+
+如需从 [Google Cloud Console](https://console.cloud.google.com) 启动 shell，请在控制台的右上角点击终端按钮。鼠标悬停在按钮上时，它会标记为 **Activate Cloud Shell**。
+
+### 本地 Shell
+
+执行以下步骤以安装 `gcloud` 和 `kubectl`：
+
+1. 按照[这些步骤](https://cloud.google.com/sdk/docs/install)安装 Cloud SDK。The Cloud SDK 包括 `gcloud` 命令行工具。不同操作系统对应的步骤有所不同。
+1. 安装 Cloud SDK 后，运行以下命令以安装 `kubectl` 命令行工具：
+
+   ```
+   gcloud components install kubectl
+   ```
+   后面的步骤会配置 `kubectl`，使其用于使用新的 GKE 集群。
+1. 如果 Helm 3 未安装的话，[安装 Helm 3](https://helm.sh/docs/intro/install/)。
+1. 使用 `HELM_EXPERIMENTAL_OCI` 变量来启用 Helm 的实验功能 [OCI 镜像支持](https://github.com/helm/community/blob/master/hips/hip-0006.md)。把以下行添加到 `~/.bashrc` （或 macOS 中的 `~/.bash_profile`，或者你的 shell 存储环境变量的地方）：
+
+   ```
+   export HELM_EXPERIMENTAL_OCI=1
+   ```
+1. 运行以下命令来加载你更新的 `.bashrc` 文件：
+
+   ```
+   source ~/.bashrc
+   ```
+   如果你运行的是 macOS，使用这个命令:
+   ```
+   source ~/.bash_profile
+   ```
+
+
+
+## 3. 配置 gcloud CLI
+
+选择以下方法之一配置默认的 gcloud 设置：
+
+- 如果你想了解默认值，请使用 gcloud init。
+- 如需单独设置你的项目 ID、地区和区域，使用 gcloud config。
+
+<Tabs>
+<TabItem value="使用 gcloud init">
+
+1. 运行 gcloud init 并按照指示操作：
+
+   ```
+   gcloud init
+   ```
+   如果你在远程服务器上使用 SSH，使用 --console-only 标志，以防止该命令启动浏览器。
+
+   ```
+   gcloud init --console-only
+   ```
+2. 按照指示，以授权 gcloud 使用你的 Google Cloud 账户，并选择你创建的新项目。
+
+
+</TabItem>
+<TabItem value="使用 gcloud config">
+</TabItem>
+</Tabs>
+
+## 4. 确认 gcloud 的配置是否正确
+
+运行：
+
+```
+gcloud config list
+```
+
+返回的结果应与以下内容类似：
+
+```
+[compute]
+region = us-west1 # Your chosen region
+zone = us-west1-b # Your chosen zone
+[core]
+account = <Your email>
+disable_usage_reporting = True
+project = <Your project ID>
+
+Your active configuration is: [default]
+```
+
+## 5. 创建一个 GKE 集群
+
+下面的命令创建了一个三节点的集群。
+
+把 `cluster-name` 替换为你新集群的名称。
+
+在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
+
+要使用 Rancher 成功创建 GKE 集群，GKE 必须处于 Standard 模式。GKE 在创建 Kubernetes 集群时有两种运行模式，分别是 Autopilot 和 Standard 模式。Autopilot 模式的集群配置对编辑 kube-system 命名空间有限制。但是，Rancher 在安装时需要在 kube-system 命名空间中创建资源。因此，你将无法在以 Autopilot 模式创建的 GKE 集群上安装 Rancher。如需详细了解 GKE Autopilot 模式和 Standard 模式之间的差异，请访问[比较 GKE Autopilot 和 Standard ](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)。
+
+**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
+
+```
+gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
+```
+
+## 6. 获取验证凭证
+
+创建集群后，你需要获得认证凭证才能与集群交互：
+
+```
+gcloud container clusters get-credentials cluster-name
+```
+
+此命令将 `kubectl` 配置成使用你创建的集群。
+
+## 7. 安装 Ingress
+
+集群需要一个 Ingress，以从集群外部访问 Rancher。
+
+以下命令安装带有 LoadBalancer 服务的 `nginx-ingress-controller`：
+
+```
+helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
+helm repo update
+helm upgrade --install \
+  ingress-nginx ingress-nginx/ingress-nginx \
+  --namespace ingress-nginx \
+  --set controller.service.type=LoadBalancer \
+  --version 4.0.18 \
+  --create-namespace
+```
+
+## 8. 获取负载均衡器的 IP
+
+运行以下命令获取负载均衡器的 IP 地址：
+
+```
+kubectl get service ingress-nginx-controller --namespace=ingress-nginx
+```
+
+返回的结果应与以下内容类似：
+
+```
+NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)                      AGE
+ingress-nginx-controller   LoadBalancer   10.3.244.156   35.233.206.34   80:31876/TCP,443:32497/TCP   81s
+```
+
+保存 `EXTERNAL-IP`。
+
+## 9. 设置 DNS
+
+到 Rancher Server 的外部流量需要重定向到你创建的负载均衡器。
+
+创建指向你保存的外部 IP 地址的 DNS。这个 DNS 会用作 Rancher Server 的 URL。
+
+设置 DNS 的有效方法有很多。如需获取帮助，请参见 Google Cloud 文档中的[管理 DNS 记录](https://cloud.google.com/dns/docs/records)部分。
+
+## 10. 安装 Rancher Helm Chart
+
+按照[本页](./install-upgrade-on-a-kubernetes-cluster.md#安装-rancher-helm-chart)的说明安装 Rancher Helm Chart。任何 Kubernetes 发行版上安装的 Rancher 的 Helm 说明都是一样的。
+
+安装 Rancher 时，使用上一步获取的 DNS 名称作为 Rancher Server 的 URL。它可以作为 Helm 选项传递进来。例如，如果 DNS 名称是 `rancher.my.org`，你需要使用 `--set hostname=rancher.my.org` 选项来运行 Helm 安装命令。
+
+在此设置之上安装 Rancher 时，你还需要设置与 Rancher 的 Ingress 资源一起使用的 Ingress Controller 的名称：
+
+```
+--set ingress.ingressClassName=nginx
+```
+
+请参阅[Helm 安装命令](./install-upgrade-on-a-kubernetes-cluster.md#5-根据你选择的证书选项通过-helm-安装-rancher)了解你的证书选项。
+
+在 Rancher v2.7.5 中，如果你打算在集群上使用默认的 GKE Ingress 而不启用 VPC 原生的集群模式，则需要设置以下标志：
+
+```
+--set service.type=NodePort
+```
+
+此设置是必要的，这考虑了与 ClusterIP（`cattle-system/rancher` 的默认类型）之间的兼容性问题。
@@ -0,0 +1,37 @@
+apiVersion: apiserver.config.k8s.io/v1
+kind: AdmissionConfiguration
+plugins:
+- configuration:
+    apiVersion: pod-security.admission.config.k8s.io/v1
+    defaults:
+      audit: restricted
+      audit-version: latest
+      enforce: restricted
+      enforce-version: latest
+      warn: restricted
+      warn-version: latest
+    exemptions:
+      namespaces:
+      - ingress-nginx
+      - kube-system
+      - cattle-system
+      - cattle-epinio-system
+      - cattle-fleet-system
+      - longhorn-system
+      - cattle-neuvector-system
+      - cattle-monitoring-system
+      - rancher-alerting-drivers
+      - cis-operator-system
+      - cattle-csp-adapter-system
+      - cattle-externalip-system
+      - cattle-gatekeeper-system
+      - istio-system
+      - cattle-istio-system
+      - cattle-logging-system
+      - cattle-windows-gmsa-system
+      - cattle-sriov-system
+      - cattle-ui-plugin-system
+      - tigera-operator
+    kind: PodSecurityConfiguration
+  name: PodSecurity
+  path: ""
@@ -0,0 +1,154 @@
+---
+title: 回滚
+---
+
+本页概述了如何在升级 Rancher 后将 Rancher 回滚到之前的版本。
+
+请在以下情况时按照本页的说明进行操作：
+- 正在运行的 Rancher 实例在备份完成后升级到了更新的版本。
+- 上游（本地）集群与进行备份的集群相同。
+
+:::tip
+
+* [请参阅这些步骤来迁移 Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md).
+* 如果你需要还原 Rancher 到同一版本的之前的状态, 请参阅[还原 Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md).
+
+:::
+
+## 特殊场景下的操作
+
+在以下场景中需要执行替代步骤来进行回滚：
+- 从 v2.6.4 及更高版本回滚到 v2.6.x 的早期版本。
+- 从 v2.7.7 及更高版本回滚到 v2.7.x 的早期版本。
+
+Rancher v2.6.4 将 cluster-api 模块从 v0.4.4 升级到 v1.0.2。反过来，cluster-api 的 v1.0.2 版本将集群 API 的自定义资源定义 (CRD) 从 `cluster.x-k8s.io/v1alpha4` 升级到 `cluster.x-k8s.io/v1beta1`。当你尝试将 Rancher v2.6.4 回滚到以前版本的 Rancher v2.6.x 时，CRD 升级到 v1beta1 会导致回滚失败。这是因为使用旧 apiVersion (v1alpha4) 的 CRD 与 v1beta1 不兼容。
+
+在 Rancher v2.7.7 版本中，应用 `rancher-provisioning-capi` 会自动安装在上游（本地）集群上，来替代嵌入的 cluster-api 控制器。 如果上游集群同时包含该应用和 Rancher v2.7.6 及更早版本，则会发生冲突和意外错误。 因此，如果你尝试从 Rancher v2.7.7 回滚到 Rancher v2.7.x 的任何早期版本，需要执行替代的步骤。
+
+### 步骤 1： 清理上游（本地）集群
+
+要避免回滚失败，你需要在尝试恢复操作或回滚**之前**根据该[说明](https://github.com/rancher/rancher-cleanup/blob/main/README.md)运行以下 Rancher 脚本：
+
+
+* `cleanup.sh`：清理集群。
+* `verify.sh`：检查集群中是否有任何与 Rancher 相关的资源。
+
+
+:::caution
+
+`cleanup.sh` 运行的时候会有停机时间，这是因为脚本会删除 Rancher 创建的资源。
+
+:::
+
+**结果：** 上游（本地）集群中所有 Rancher 关联的资源将被清理。
+
+请参阅 [rancher/rancher-cleanup 仓库](https://github.com/rancher/rancher-cleanup) 以获取更多细节和源码。
+
+### 步骤 2： 还原备份并启动 Rancher
+
+此时上游集群上应该已经没有 Rancher 相关的资源了。 因此，下一步与将 Rancher 迁移到不包含 Rancher 资源的新集群相同。
+
+按照[说明](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)安装 Rancher-Backup Helm Chart 并恢复 Rancher 到之前的状态。请记住：
+1. 步骤 3 可以跳过，因为之前安装的 Cert-Manager 应用应该还在上游（本地）集群中。
+2. 执行到步骤 4 时，在要回滚到的 local 集群上安装你需要的 Rancher 版本。
+
+## 回滚到 Rancher 2.5.0+
+
+要回滚到 Rancher 2.5.0+，使用 **Rancher 备份**应用并通过备份来恢复 Rancher。
+
+回滚后，Rancher 必须以较低/较早的版本启动。
+
+还原是通过创建 Restore 自定义资源实现的。
+
+:::note 重要提示：
+
+* 请按照此页面上的说明在已备份的同一集群上还原 Rancher。要把 Rancher 迁移到新集群，请参照步骤[迁移 Rancher](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
+
+* 在使用相同设置恢复 Rancher 时，Rancher deployment 在恢复开始前被手动缩减，然后 Operator 将在恢复完成后将其缩回。因此，在恢复完成之前，Rancher 和 UI 都将不可用。如果 UI 不可用时，你可使用 `kubectl create -f restore.yaml`YAML 恢复文件来使用初始的集群 kubeconfig。
+
+:::
+
+### 步骤 1 ：创建 Restore 自定义资源
+
+1. 点击 **☰ > 集群管理**。
+1. 找到你的本地集群，并点击 **Explore**。
+1. 在左侧导航栏中，点击 **Rancher 备份 > 还原**。
+   :::note
+
+   如果 Rancher Backups 应用不可见，你需要到 **Apps** 的 Charts 页面中安装应用。详情请参见[此处](../../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md#访问-charts)。
+
+   :::
+
+1. 单击**创建**。
+1. 使用表单或 YAML 创建 Restore。如需获取使用表单创建 Restore 资源的更多信息，请参见[配置参考](../../../reference-guides/backup-restore-configuration/restore-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md)。
+1. 如需使用 YAML 编辑器，点击**创建 > 使用 YAML 文件创建**。然后输入 Restore YAML。以下是 Restore 自定义资源示例：
+
+   ```yaml
+   apiVersion: resources.cattle.io/v1
+   kind: Restore
+   metadata:
+     name: restore-migration
+   spec:
+     backupFilename: backup-b0450532-cee1-4aa1-a881-f5f48a007b1c-2020-09-15T07-27-09Z.tar.gz
+     encryptionConfigSecretName: encryptionconfig
+     storageLocation:
+       s3:
+         credentialSecretName: s3-creds
+         credentialSecretNamespace: default
+         bucketName: rancher-backups
+         folder: rancher
+         region: us-west-2
+         endpoint: s3.us-west-2.amazonaws.com
+   ```
+   如需获得配置 Restore 的帮助，请参见[配置参考](../../../reference-guides/backup-restore-configuration/restore-configuration.md)和[示例](../../../reference-guides/backup-restore-configuration/examples.md)。
+
+1. 单击**创建**。
+
+**结果**：已创建备份文件并更新到目标存储位置。资源还原顺序如下：
+
+1. 自定义资源定义（CRD）
+2. 集群范围资源
+3. 命名空间资源
+
+如需查看还原的处理方式，请检查 Operator 的日志。按照如下步骤获取日志：
+
+```yaml
+kubectl get pods -n cattle-resources-system
+kubectl logs -n cattle-resources-system -f
+```
+
+### 步骤 2：回滚到上一个 Rancher 版本
+
+你可以使用 Helm CLI 回滚 Rancher。要回滚到上一个版本：
+
+```yaml
+helm rollback rancher -n cattle-system
+```
+
+如果你不是想回滚到上一个版本，你也可以指定回滚的版本。查看部署历史记录：
+
+```yaml
+helm history rancher -n cattle-system
+```
+
+确定目标版本后，执行回滚。此示例回滚到版本 `3`：
+
+```yaml
+helm rollback rancher 3 -n cattle-system
+```
+
+## 回滚到 Rancher 2.2-2.4
+
+要回滚到 2.5 之前的 Rancher 版本，参考此处的步骤[恢复备份 — Kubernetes 安装](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)。如果恢复 Rancher Server 的集群的某个快照，Rancher 的版本以及状态均会恢复回到快照时的版本和状态。
+
+有关回滚 Docker 安装的 Rancher，请参见[本页](../other-installation-methods/rancher-on-a-single-node-with-docker/roll-back-docker-installed-rancher.md)。
+
+:::note
+
+托管集群对其状态具有权威性。因此，恢复 Rancher Server 不会恢复快照后对托管集群进行的工作负载部署或更改。
+
+:::
+
+## 回滚到 Rancher 2.0-2.1
+
+我们不再支持回滚到 Rancher 2.0-2.1。回滚到这些版本的说明保留在[此处](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md)，仅用于无法升级到 v2.2 的情况。
@@ -0,0 +1,180 @@
+---
+title: Rancher Server Kubernetes 集群的问题排查
+---
+
+本文介绍如何对安装在 Kubernetes 集群上的 Rancher 进行故障排除。
+
+## 相关命名空间
+
+故障排除主要针对以下 3 个命名空间中的对象：
+
+- `cattle-system`：`rancher` deployment 和 Pod。
+- `ingress-nginx`：Ingress Controller Pod 和 services。
+- `cert-manager`：`cert-manager` Pod。
+
+## "default backend - 404"
+
+很多操作都有可能导致 Ingress Controller 无法将流量转发到你的 Rancher 实例。但是大多数情况下都是由错误的 SSL 配置导致的。
+
+检查事项：
+
+- [Rancher 是否正在运行](#检查-rancher-是否正在运行)
+- [证书的 Common Name（CN）是 "Kubernetes Ingress Controller Fake Certificate"](#证书的-cn-是-kubernetes-ingress-controller-fake-certificate)
+
+## 检查 Rancher 是否正在运行
+
+使用 `kubectl` 检查 `cattle-system` 系统命名空间，并查看 Rancher Pod 的状态是否是 **Running**：
+
+```
+kubectl -n cattle-system get pods
+
+NAME                           READY     STATUS    RESTARTS   AGE
+pod/rancher-784d94f59b-vgqzh   1/1       Running   0          10m
+```
+
+如果状态不是 `Running`，在 Pod 上运行 `describe`，并检查 **Events**：
+
+```
+kubectl -n cattle-system describe pod
+
+...
+Events:
+  Type     Reason                 Age   From                Message
+  ----     ------                 ----  ----                -------
+  Normal   Scheduled              11m   default-scheduler   Successfully assigned rancher-784d94f59b-vgqzh to localhost
+  Normal   SuccessfulMountVolume  11m   kubelet, localhost  MountVolume.SetUp succeeded for volume "rancher-token-dj4mt"
+  Normal   Pulling                11m   kubelet, localhost  pulling image "rancher/rancher:v2.0.4"
+  Normal   Pulled                 11m   kubelet, localhost  Successfully pulled image "rancher/rancher:v2.0.4"
+  Normal   Created                11m   kubelet, localhost  Created container
+  Normal   Started                11m   kubelet, localhost  Started container
+```
+
+## 检查 Rancher 日志
+
+使用 `kubectl` 列出 Pod：
+
+```
+kubectl -n cattle-system get pods
+
+NAME                           READY     STATUS    RESTARTS   AGE
+pod/rancher-784d94f59b-vgqzh   1/1       Running   0          10m
+```
+
+使用 `kubectl` 和 Pod 名称列出该 Pod 的日志：
+
+```
+kubectl -n cattle-system logs -f rancher-784d94f59b-vgqzh
+```
+
+## 证书的 CN 是 "Kubernetes Ingress Controller Fake Certificate"
+
+使用浏览器检查证书的详细信息。如果显示 CN 是 "Kubernetes Ingress Controller Fake Certificate"，则说明读取或颁发 SSL 证书时出现了问题。
+
+:::note
+
+如果你使用的是 Let's Encrypt 证书，证书颁发的过程可能需要几分钟。
+
+:::
+
+## 排查 Cert-Manager 颁发的证书（Rancher 或 Let's Encrypt 生成的）问题
+
+`cert-manager` 有 3 部分：
+
+- `cert-manager` 命名空间中的 `cert-manager` Pod。
+- `cattle-system` 命名空间中的 `Issuer` 对象。
+- `cattle-system` 命名空间中的 `Certificate` 对象。
+
+往后操作，对每个对象运行 `kubectl describe` 并检查事件。这样，你可以追踪可能丢失的内容。
+
+以下是 Issuer 有问题的示例：
+
+```
+kubectl -n cattle-system describe certificate
+...
+Events:
+  Type     Reason          Age                 From          Message
+  ----     ------          ----                ----          -------
+  Warning  IssuerNotReady  18s (x23 over 19m)  cert-manager  Issuer rancher not ready
+```
+
+```
+kubectl -n cattle-system describe issuer
+...
+Events:
+  Type     Reason         Age                 From          Message
+  ----     ------         ----                ----          -------
+  Warning  ErrInitIssuer  19m (x12 over 19m)  cert-manager  Error initializing issuer: secret "tls-rancher" not found
+  Warning  ErrGetKeyPair  9m (x16 over 19m)   cert-manager  Error getting keypair for CA issuer: secret "tls-rancher" not found
+```
+
+## 排查你自己提供的 SSL 证书问题
+
+你的证书直接应用于 `cattle-system` 命名空间中的 Ingress 对象。
+
+检查 Ingress 对象的状态，并查看它是否准备就绪：
+
+```
+kubectl -n cattle-system describe ingress
+```
+
+如果 Ingress 对象已就绪，但是 SSL 仍然无法正常工作，你的证书或密文的格式可能不正确。
+
+这种情况下，请检查 nginx-ingress-controller 的日志。nginx-ingress-controller 的 Pod 中有多个容器，因此你需要指定容器的名称：
+
+```
+kubectl -n ingress-nginx logs -f nginx-ingress-controller-rfjrq nginx-ingress-controller
+...
+W0705 23:04:58.240571       7 backend_ssl.go:49] error obtaining PEM from secret cattle-system/tls-rancher-ingress: error retrieving secret cattle-system/tls-rancher-ingress: secret cattle-system/tls-rancher-ingress was not found
+```
+
+## 没有匹配的 "Issuer"
+
+你所选的 SSL 配置要求在安装 Rancher 之前先安装 Cert-Manager，否则会出现以下错误:
+
+```
+Error: validation failed: unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1"
+```
+
+在这种情况下，先安装 Cert-Manager，然后再重新安装 Rancher。
+
+
+## Canal Pod 显示 READY 2/3
+
+此问题的最常见原因是端口 8472/UDP 在节点之间未打开。因此，你可以检查你的本地防火墙、网络路由或安全组。
+
+解决网络问题后，`canal` Pod 会超时并重启以建立连接。
+
+## nginx-ingress-controller Pod 显示 RESTARTS
+
+此问题的最常见原因是 `canal` pod 未能建立覆盖网络。参见 [canal Pod 显示 READY `2/3`](#canal-pod-显示-ready-23) 进行排查。
+
+
+## Failed to dial to /var/run/docker.sock: ssh: rejected: administratively prohibited (open failed)
+
+此错误的原因可能是：
+
+* 指定连接的用户无权访问 Docker Socket。如果是这个原因，你通过登录主机并运行 `docker ps` 命令来检查：
+
+```
+$ ssh user@server
+user@server$ docker ps
+CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
+```
+
+如果需要了解如何进行正确设置，请参见[以非 root 用户身份管理 Docker](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)。
+
+* 你使用的操作系统是 RedHat 或 CentOS：由于 [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565)，你不能使用 `root` 用户连接到节点。因此，你需要添加一个单独的用户并配置其访问 Docker Socket。如果需要了解如何进行正确设置，请参见[以非 root 用户身份管理 Docker](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user)。
+
+* SSH 服务器版本不是 6.7 或更高版本：高版本是 Socket 转发所必须的，用于通过 SSH 连接到 Docker Socket。你可以在你要连接的主机上使用 `sshd -V` 或使用 netcat 进行检查：
+```
+$ nc xxx.xxx.xxx.xxx 22
+SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
+```
+
+## Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
+
+`ssh_key_path` 密钥文件不是访问节点的正确文件：请仔细检查，确保你已为节点指定了正确的 `ssh_key_path` 和连接用户。
+
+## Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
+
+节点无法通过配置的 `address` 和 `port` 访问。
@@ -0,0 +1,202 @@
+---
+title: 升级
+---
+
+本文介绍如何升级使用 Helm 安装在 Kubernetes 集群上的 Rancher Server。这些步骤也适用于使用 Helm 进行的离线安装。
+
+有关使用 Docker 安装的 Rancher 的升级说明，请参见[本页。](../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)
+
+## 先决条件
+
+### 访问 Kubeconfig
+
+Helm 的运行位置，应该与你的 Kubeconfig 文件，或你运行 kubectl 命令的位置相同。
+
+If you installed Kubernetes with RKE2/K3s, the Kubeconfig is stored in the `/etc/rancher/rke2/rke2.yaml` or `/etc/rancher/k3s/k3s.yaml` directory depending on your chosen distribution.
+
+Kubeconfig 也可以通过 `--kubeconfig` 标签（详情请参见 https://helm.sh/docs/helm/helm/ ）来手动指定所需的集群。
+
+### 查看已知问题
+
+如需查看每个 Rancher 版本的已知问题，请参见 [GitHub](https://github.com/rancher/rancher/releases) 中的发行说明，或查看 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)。
+
+不支持 _升级_ 或 _升级到_ [rancher-alpha 仓库](../resources/choose-a-rancher-version.md#helm-chart-仓库)中的任何 Chart。
+### Helm 版本
+
+本安装指南假定你使用的是 Helm 3。
+
+<DeprecationHelm2 />
+
+如果你使用 Helm 2，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3，[Helm 2 升级页面](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) 提供了使用 Helm 2 升级的旧升级指南。
+
+### 离线安装：推送镜像到私有镜像仓库
+
+[仅适用于离线安装](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)：为新的 Rancher Server 版本收集和推送镜像。使用你需要针对 Rancher 版本升级的镜像，按照步骤[推送镜像到私有镜像仓库](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md)。
+
+### 使用 cert-manager 0.8.0 之前的版本升级
+
+[从 2019 年 11 月 1 日开始，Let's Encrypt 已屏蔽早于 0.8.0 的 cert-manager 实例](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)。因此，请参见[说明](../resources/upgrade-cert-manager.md)把 cert-manager 升级到最新版本。
+
+## 升级概要
+
+按照以下步骤升级 Rancher Server：
+
+
+### 1. 备份运行 Rancher Server 的 Kubernetes 集群
+
+使用[备份应用](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)来备份 Rancher。
+
+如果升级过程中出现问题，你将使用备份作为还原点。
+
+### 2. 更新 Helm Chart 仓库
+
+1. 更新本地 Helm 仓库缓存。
+
+   ```
+   helm repo update
+   ```
+
+1. 获取你用来安装 Rancher 的仓库名称。
+
+   关于仓库及其区别，请参见 [Helm Chart 仓库](../resources/choose-a-rancher-version.md#helm-chart-仓库)。
+
+   - Latest：建议用于试用最新功能
+      ```
+      helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+      ```
+   - Stable：建议用于生产环境
+      ```
+      helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+      ```
+   - Alpha：即将发布的实验性预览。
+      ```
+      helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
+      ```
+      注意：不支持升级到 Alpha 版、从 Alpha 版升级或在 Alpha 版之间升级。
+
+   ```
+   helm repo list
+
+   NAME          	       URL
+   stable        	       https://charts.helm.sh/stable
+   rancher-<CHART_REPO>	 https://releases.rancher.com/server-charts/<CHART_REPO>
+   ```
+
+   :::note
+
+   如果你想切换到不同的 Helm Chart 仓库，请按照[切换仓库步骤](../resources/choose-a-rancher-version.md#切换到不同-helm-chart-仓库)进行操作。如果你要切换仓库，请先再次列出仓库，再继续执行步骤 3，以确保添加了正确的仓库。
+
+   :::
+
+1. 从 Helm Chart 仓库获取最新的 Chart 来安装 Rancher。
+
+   该命令将提取最新的 Chart，并将其作为 `.tgz`文件保存在当前目录中。
+
+   ```plain
+   helm fetch rancher-<CHART_REPO>/rancher
+   ```
+   你可以通过 `--version=` 标记，来指定要升级的目标 Chart 版本。例如：
+
+   ```plain
+   helm fetch rancher-<CHART_REPO>/rancher --version=2.6.8
+   ```
+
+### 3. 升级 Rancher
+
+本节介绍了如何使用 Helm 升级 Rancher 的一般（互联网连接）或离线安装。
+
+:::note 离线说明：
+
+如果你在离线环境中安装 Rancher，请跳过本页的其余部分，按照[本页](air-gapped-upgrades.md)上的说明渲染 Helm 模板。
+
+:::
+
+
+从当前安装的 Rancher Helm Chart 中获取用 `--set`传递的值。
+
+```
+helm get values rancher -n cattle-system
+
+hostname: rancher.my.org
+```
+
+:::note
+
+这个命令会列出更多的值。此处展示的只是其中一个值的例子。
+
+:::
+
+:::tip
+
+Deployment 的名称可能会有所不同。例如，如果你通过 AWS Marketplace 部署 Rancher，则 Deployment 的名称为“rancher-stable”。
+因此：
+```
+helm get values rancher-stable -n cattle-system
+
+hostname: rancher.my.org
+```
+
+:::
+
+如果要将 cert-manager 从 v1.5 或更早的版本升级到最新版本，请参阅 [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#选项-c升级-15-及以下版本的-cert-manager) 了解如何在不卸载或重新安装 Rancher 的情况下升级 cert-manager。否则，请按照以下[ Rancher 升级步骤](#rancher-升级步骤)进行操作。
+
+#### Rancher 升级步骤
+
+保留你的所有设置把 Rancher 升级到最新版本。
+
+将上一步中的所有值用 `--set key=value` 追加到命令中。
+
+```
+helm upgrade rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+:::note
+
+以上是一个例子，可能有更多上一步的值需要追加。
+
+:::
+
+:::tip
+
+如果你通过 AWS Marketplace 部署 Rancher，则 Deployment 的名称为“rancher-stable”。
+因此：
+```
+helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+:::
+
+另外，你也可以将当前的值导出到一个文件中，并在升级时引用该文件。例如，如果你只需要改变 Rancher 的版本：
+
+1. 将当前值导出到文件：
+   ```
+   helm get values rancher -n cattle-system -o yaml > values.yaml
+   ```
+1. 只更新 Rancher 版本：
+
+   ```
+   helm upgrade rancher rancher-<CHART_REPO>/rancher \
+     --namespace cattle-system \
+     -f values.yaml \
+     --version=2.6.8
+   ```
+
+### 4. 验证升级
+
+登录 Rancher 以确认升级成功。
+
+:::tip
+
+升级后出现网络问题？
+
+请参见[恢复集群网络](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md)。
+
+:::
+
+## 已知升级问题
+
+你可以在 [GitHub](https://github.com/rancher/rancher/releases) 发布说明以及 [Rancher 论坛](https://forums.rancher.com/c/announcements/12)中找到每个 Rancher 版本的已知问题。
@@ -0,0 +1,94 @@
+---
+title: 安装/升级 Rancher
+description: 了解如何在开发和生产环境中安装 Rancher。了解单节点和高可用安装
+---
+
+本节介绍了 Rancher 各种安装方式以及每个安装方式的优点。
+
+## 名词解释
+
+本章节涉及以下名词：
+
+- **Rancher Server**：用于管理和配置 Kubernetes 集群。你可以通过 Rancher Server 的 UI 与下游 Kubernetes 集群进行交互。Rancher Management Server 可以安装到任意 Kubernetes 集群上，包括托管的集群，如 Amazon EKS 集群。
+- **RKE（Rancher Kubernetes Engine）**：是经过认证的 Kubernetes 发行版，也是用于创建和管理 Kubernetes 集群的 CLI 工具和库。
+- **K3s（轻量级 Kubernetes）**：也是经过认证的 Kubernetes 发行版。它比 RKE 更新，更易用且更轻量，其所有组件都在一个小于 100 MB 的二进制文件中。
+- **RKE2**：一个完全合规的 Kubernetes 发行版，专注于安全和合规性。
+
+`restrictedAdmin` Helm Chart 选项在 **Rancher Server** 可用。如果该选项设置为 true，初始的 Rancher 用户访问本地 Kubernetes 集群会受到限制，以避免权限升级。详情请参见 [restricted-admin 角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#受限管理员)。
+
+## 安装方式概述
+
+Rancher 可以安装在以下主要架构上：
+
+### 使用 Helm CLI 安装的高可用 Kubernetes
+
+我们建议使用 Kubernetes 包管理器 Helm 在专用的 Kubernetes 集群上安装 Rancher。在 RKE 集群中，需要使用三个节点才能实现高可用集群。在 K3s 集群中，只需要两个节点即可。
+
+### 通过 AWS Marketplace 在 EKS 上安装 Rancher
+
+你可以[通过 AWS Marketplace](../quick-start-guides/deploy-rancher-manager/aws-marketplace.md) 将 Rancher 安装到 Amazon Elastic Kubernetes Service (EKS) 上。部署的 EKS 集群已生产就绪，并遵循 AWS 最佳实践。
+
+### 单节点 Kubernetes 安装
+
+Rancher 可以安装在单节点 Kubernetes 集群上。但是，在单节点安装的情况下，Rancher Server 没有高可用性。而高可用性对在生产环境中运行 Rancher 非常重要。
+
+但是，如果你想要短期内使用单节点节省资源，同时又保留高可用性迁移路径，那么单节点 Kubernetes 安装也是合适的。你也可以之后向集群中添加节点，获得高可用的 Rancher Server。
+
+### Docker 安装
+
+如果你的目的是测试或演示，你可以使用 Docker 把 Rancher 安装到单个节点中。本地 Kubernetes 集群是安装到单个 Docker 容器中的，而 Rancher 是安装到本地集群中的。
+
+Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。详情请参见[把 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
+
+### 其他方式
+
+如果你需要在离线环境中或使用 HTTP 代理安装 Rancher，请参见以下独立的说明文档：
+
+| 网络访问方式 | 基于 Kubernetes 安装（推荐）	 | 基于 Docker 安装 |
+| ---------------------------------- | ------------------------------ | ---------- |
+| 可直接访问互联网 | [文档](install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md) | [文档](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md) |
+| 使用 HTTP 代理 | [文档](other-installation-methods/rancher-behind-an-http-proxy/rancher-behind-an-http-proxy.md) | [文档](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md)及[配置](../../reference-guides/single-node-rancher-in-docker/http-proxy-configuration.md) |
+| 离线环境 | [文档](other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) | [文档](other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) |
+
+我们建议在 Kubernetes 集群上安装 Rancher，因为在多节点集群中，Rancher Server 可以实现高可用。高可用配置可以提升 Rancher 访问其管理的下游 Kubernetes 集群的稳定性。
+
+因此，我们建议在生产级别的架构中，设置一个高可用的 Kubernetes 集群，然后在这个集群上安装 Rancher。安装 Rancher 后，你可以使用 Rancher 部署和管理 Kubernetes 集群。
+
+如果你的目的是测试或演示，你可以将 Rancher 安装到单个 Docker 容器中。Docker 安装可以让你实现开箱即用，以使用 Rancher 设置 Kubernetes 集群。Docker 安装主要是用于探索 Rancher Server 的功能，只适用于开发和测试。
+
+[在 Kubernetes 上安装 Rancher 的说明](install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)介绍了如何首先使用 K3s 或 RKE 创建和管理 Kubernetes 集群，然后再将 Rancher 安装到该集群上。
+
+如果 Kubernetes 集群中的节点正在运行且满足[节点要求](installation-requirements/installation-requirements.md)，你可以使用 Helm 将 Rancher 部署到 Kubernetes 上。Helm 使用 Rancher 的 Helm Chart 在 Kubernetes 集群的每个节点上安装 Rancher 的副本。我们建议使用负载均衡器将流量定向到集群中的每个 Rancher 副本上。
+
+如需进一步了解 Rancher 架构，请参见[架构概述](../../reference-guides/rancher-manager-architecture/rancher-manager-architecture.md)，[生产级别架构推荐](../../reference-guides/rancher-manager-architecture/architecture-recommendations.md)或[最佳实践指南](../../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md)。
+
+## 先决条件
+
+安装 Rancher 之前，请确保你的节点满足所有[安装要求](installation-requirements/installation-requirements.md)。
+
+## 架构建议
+
+为了达到最佳性能和安全性，我们建议你为 Rancher Management Server 使用单独的专用 Kubernetes 集群。不建议在此集群上运行用户工作负载。部署 Rancher 后，你可以[创建或导入集群](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md)来运行你的工作负载。
+
+详情请参见[架构推荐](../../reference-guides/rancher-manager-architecture/architecture-recommendations.md)。
+
+### 在 Kubernetes 上安装 Rancher 的更多选项
+
+参见 [Helm Chart 选项](installation-references/helm-chart-options.md)以了解在 Kubernetes 集群上安装 Rancher 的其他配置，包括：
+
+- [开启 API 审计日志来记录所有事务](installation-references/helm-chart-options.md#api-审计日志)
+- [负载均衡器上的 TLS 终止](installation-references/helm-chart-options.md#外部-tls-终止)
+- [自定义 Ingress](installation-references/helm-chart-options.md#自定义-ingress)
+
+在 Rancher 的安装指南中，我们推荐使用 K3s 或 RKE 来配置 Kubernetes 集群，然后再在这个集群中安装 Rancher。K3s 和 RKE 均提供许多配置选项，用于为你的具体环境自定义 Kubernetes 集群。有关选项和功能的完整列表，请参见：
+
+- [RKE 配置选项](https://rancher.com/docs/rke/latest/en/config-options/)
+- [K3s 配置选项](https://rancher.com/docs/k3s/latest/en/installation/install-options/)
+
+### 在 Docker 上安装 Rancher 的更多选项
+
+参见 [Docker 安装选项](other-installation-methods/rancher-on-a-single-node-with-docker/rancher-on-a-single-node-with-docker.md)了解其他配置，包括：
+
+- [开启 API 审计日志来记录所有事务](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-审计日志)
+- [外部负载均衡器](../../how-to-guides/advanced-user-guides/configure-layer-7-nginx-load-balancer.md)
+- [持久化数据存储](../../reference-guides/single-node-rancher-in-docker/advanced-options.md#持久化数据)
@@ -0,0 +1,43 @@
+---
+title: 功能开关
+---
+
+使用功能开关（Feature Flag），你可以试用可选或实验性的功能并启用正在逐步淘汰的旧版功能。
+
+要了解功能的值以及如何启用它们，请参阅[启用实验性功能](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
+
+:::note
+
+某些功能要求重新启动 Rancher 容器。Rancher UI 中标记了要求重启的功能。
+
+:::
+
+以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的，你可能会在 Rancher UI 中看到其他功能，例如 `proxy` 或 `dashboard`（均[已中断](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)）：
+
+- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
+- `continuous-delivery`：允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息，请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
+- `fleet`：v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志，该标志也将在升级时自动启用。有关详细信息，请参阅 [Fleet - GitOps at Scale](../../../integrations-in-rancher/fleet/fleet.md)。
+- `harvester`：管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息，请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester/overview.md)。
+- `istio-virtual-service-ui`：启用[可视界面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)来创建、读取、更新和删除 Istio 虚拟服务和目标规则，这些都是 Istio 流量管理功能。
+- `legacy`：启用 2.5.x 及更早版本的一组功能，这些功能正逐渐被新的实现淘汰。它们是已弃用以及后续可用于新版本的功能组合。新的 Rancher 安装会默认禁用此标志。如果你从以前版本的 Rancher 升级，此标志会启用。
+- `multi-cluster-management`：允许配置和管理多个 Kubernetes 集群。此标志只能在安装时设置。后续无法启用或禁用它。
+- `rke2`：启用配置 RKE2 集群。此标志默认启用。
+- `token-hashing`：启用令牌哈希。启用后，会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理，就无法撤消操作。此标志在启用后无法禁用。有关详细信息，请参阅 [API 令牌](../../../api/api-tokens.md#令牌哈希)。
+- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists. 
+- `unsupported-storage-drivers`：允许启用非默认启用的存储提供程序和卷插件。有关详细信息，请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
+- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
+
+下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用：
+
+| 功能开关名称 | 默认值 | 状态 | 可用于 |
+| ----------------------------- | ------------- | ------------ | --------------- |
+| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
+| `continuous-delivery` | `true` | GA | v2.6.0 |
+| `fleet` | `true` | 不能禁用 | v2.6.0 |
+| `fleet` | `true` | GA | v2.5.0 |
+| `harvester` | `true` | 实验功能 | v2.6.1 |
+| `legacy` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
+| `rke2` | `true` | 实验功能 | v2.6.0 |
+| `token-hashing` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
+| `uiextension` | `true` | GA | v2.9.0 | |
+| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
@@ -0,0 +1,308 @@
+---
+title: Rancher Helm Chart 选项
+keywords: [rancher helm chart, rancher helm 选项, rancher helm chart 选项, helm chart rancher, helm 选项 rancher, helm chart 选项 rancher]
+---
+
+本文提供了 Rancher Helm Chart 的配置参考。
+
+如需选择 Helm Chart 版本，请参见[本页](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)。
+
+了解开启实验性功能的详情，请参见[本页](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)。
+
+## 常用选项
+
+| 选项 | 默认值 | 描述 |
+| ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
+| `bootstrapPassword` | " " | `string` - 为第一个管理员用户设置[引导密码](#引导密码)。登录后，管理员需要重置密码。如不设置，会使用随机生成的引导密码。 |
+| `hostname` | " " | `string` - 你的 Rancher Server 的完全限定的域名（FQDN) |
+| `ingress.tls.source` | "rancher" | `string` - 从哪里获取 Ingress 的证书- "rancher, letsEncrypt, secret" |
+| `letsEncrypt.email` | " " | `string` - 你的邮箱地址 |
+| `letsEncrypt.environment` | "production" | `string` - 可选项："staging, production" |
+| `privateCA` | false | `bool` - 如果你的证书是由私有 CA 签发的，把这个值设置为 true |
+
+<br/>
+
+## 高级选项
+
+| 选项 | 默认值 | 描述 |
+| ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `additionalTrustedCAs` | false | `bool` - 请参见[额外的授信 CA](#额外的授信-ca) |
+| `addLocal` | "true" | `string` - 让 Rancher 检测并导入 “local” Rancher Server 集群。_注意：此选项在 2.5.0 中已不可用。你可考虑使用 `restrictedAdmin` 选项，来避免用户修改本地集群。_ |
+| `antiAffinity` | "preferred" | `string` - Rancher Pod 的反亲和性规则 - "preferred, required" |
+| `auditLog.destination` | "sidecar" | `string` - 发送审计日志到 Sidecar 容器的控制台或 hostPath 卷 - "sidecar, hostPath" |
+| `auditLog.hostPath` | "/var/log/rancher/audit" | `string` - 主机上的日志文件目标地址（仅当`auditLog.destination` 的值是 `hostPath` 时生效） |
+| `auditLog.level` | 0 | `int` - 设置 [API 审计日志](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md)等级。0 代表关闭。[0-3] |
+| `auditLog.maxAge` | 1 | `int` - 旧审计日志文件最多可保留的天数（仅当`auditLog.destination` 的值是 `hostPath` 时生效） |
+| `auditLog.maxBackup` | 1 | `int` - 审计文件最大可保留的个数（仅当 `auditLog.destination` 的值是 `hostPath` 时生效） |
+| `auditLog.maxSize` | 100 | `int` - 在审计日志被轮换前的最大容量，单位是 MB（仅当 `auditLog.destination` 的值是 `hostPath` 时生效） |
+| `auditLog.image.repository` | "registry.suse.com/bci/bci-micro" | `string` - 用于收集审计日志的镜像的位置。 |
+| `auditLog.image.tag` | "15.4.14.3" | `string` - 用于收集审计日志的镜像的标签。 |
+| `auditLog.image.pullPolicy` | "IfNotPresent" | `string` - 覆盖 auditLog 镜像的 imagePullPolicy - “Always”、“Never”、“IfNotPresent”。 |
+| `busyboxImage` | "" | `string` - 用于收集审计日志的 busybox 镜像位置。_注意：此选项已弃用，请使用 `auditLog.image.repository` 来控制审计 sidecar 镜像_。 |
+| `certmanager.version` | "" | `string` - 设置 cert-manager compatibility |
+| `debug` | false | `bool` - 在 Rancher Server 设置 debug 参数 |
+| `extraEnv` | [] | `list` - 为 Rancher 额外设置环境变量 |
+| `imagePullSecrets` | [] | `list` - 私有镜像仓库凭证的密文名称列表 |
+| `ingress.configurationSnippet` | "" | `string` - 添加额外的 Nginx 配置。可用于代理配置。 |
+| `ingress.extraAnnotations` | {} | `map` - 用于自定义 Ingress 的额外注释 |
+| `ingress.enabled` | true | 如果值为 false，Helm 不会安装 Rancher Ingress。你可把值设为 false 以部署你自己的 Ingress。 |
+| `letsEncrypt.ingress.class` | "" | `string` - cert-manager acmesolver ingress 的可选 ingress 类，用于响应 Let's Encrypt ACME 质询。选项：traefik，nginx。 |                      |
+| `noProxy` | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - 不使用代理的主机名或 IP 地址的逗号分隔列表 |                                     |
+| `proxy` | "" | `string` - 给 Rancher 配置的 HTTP[S] 代理 |
+| `rancherImage` | "rancher/rancher" | `string` - Rancher 镜像源 |
+| `rancherImagePullPolicy` | "IfNotPresent" | `string` - 覆盖 Rancher Server 镜像的 imagePullPolicy - "Always", "Never", "IfNotPresent" |
+| `rancherImageTag` | 和 Chart 版本一致 | `string` - rancher/rancher 镜像标签 |
+| `replicas` | 3 | `int` - Rancher Server 副本数。如果设为 -1，会根据集群中的可用节点数自动选择 1，2或3。 |
+| `resources` | {} | `map` - Rancher Pod 资源请求和限制 |
+| `restrictedAdmin` | `false` | `bool` - 如果值为 true，初始的 Rancher 用户访问本地 Kubernetes 集群会受到限制，以避免权限升级。详情请参见 [restricted-admin 角色](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#受限管理员)。 |
+| `systemDefaultRegistry` | "" | `string` - 用于所有系统容器镜像的私有仓库，例如 http://registry.example.com/ |
+| `tls` | "ingress" | `string` - 详情请参见[外部 TLS 终止](#外部-tls-终止)。- "ingress, external" |
+| `useBundledSystemChart` | `false` | `bool` - 选择 Rancher Server 打包的 system-charts。此参数用于离线环境安装。 |
+
+### 引导密码
+
+Rancher 首次启动时，会为第一个管理员用户随机生成一个密码。当管理员首次登录 Rancher 时，用于获取引导密码（Bootstrap）的命令会在 UI 上显示。管理员需要运行命令并使用引导密码登录。然后 Rancher 会让管理员重置密码。
+
+如果你想指定引导密码而不使用随机生成的密码，请参考以下命令设置密码。
+
+```plain
+--set bootstrapPassword="rancher"
+```
+
+无论你是使用提供的密码还是生成的密码，密码均存储在 Kubernetes 密文中。安装 Rancher 后，如何使用 kubectl 获取密码的说明将会在 UI 中显示：
+
+```
+kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{ .data.bootstrapPassword|base64decode}}{{ "\n" }}'
+```
+
+### API 审计日志
+
+启用 [API 审计日志](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md)。
+
+你可以像收集其他容器日志一样收集此日志。在 Rancher Server 集群上为 `System` 项目启用 [Logging](../../../integrations-in-rancher/logging/logging.md)。
+
+```plain
+--set auditLog.level=1
+```
+
+默认情况下，启用审计日志会在 Rancher pod 中创建一个 Sidecar 容器。这个容器（`rancher-audit-log`）会把日志流传输到 `stdout`。你可以像收集其他容器日志一样收集此日志。如果你使用 Sidecar 作为审计日志的目标时， `hostPath`，`maxAge`，`maxBackups` 和 `maxSize` 选项不会生效。建议使用你的操作系统或 Docker Daemon 的日志轮换功能来控制磁盘空间的使用。请为 Rancher Server 集群或 System 项目启用 [Logging](../../../integrations-in-rancher/logging/logging.md)。
+
+将 `auditLog.destination` 的值设为 `hostPath`，可以将日志转发到与主机系统共享的卷，而不是传输到 Sidecar 容器。如果目标设置为 `hostPath`，你可能需要调整其他 auditLog 参数以进行日志轮换。
+
+### 额外设置环境变量
+
+你可以使用 `extraEnv` 为 Rancher Server 额外设置环境变量。该列表以 YAML 格式传递给 Rancher 部署，它嵌入在 Rancher 容器的 `env` 下。你可以参考 Kubernetes 文档设置容器环境变量。`extraEnv` 可以使用 [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container) 中引用的任何键。
+
+使用 `name` 和 `value` 键的示例：
+
+```plain
+--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
+--set 'extraEnv[0].value=1.0'
+```
+
+如果将敏感数据（例如代理认证凭证）作为环境变量的值传递，则强烈建议使用 Secret 引用。这将防止敏感数据在 Helm 或 Rancher 部署中暴露。
+
+你可以参考使用 `name`、`valueFrom.secretKeyRef.name` 和 `valueFrom.secretKeyRef.key` 键的示例。详见 [HTTP 代理](#http-代理)中的示例。
+
+### TLS 设置
+
+当你在 Kubernetes 集群内安装 Rancher 时，TLS 会在集群的 Ingress Controller 上卸载。支持的 TLS 设置取决于使用的 Ingress Controller。
+
+参见 [TLS 设置](tls-settings.md)了解更多信息和选项。
+
+### 导入 `local` 集群
+
+默认情况下，Rancher Server 会检测并导入其所在的 `local` 集群。有权访问 `local` 集群的用户对 Rancher Server 管理的所有集群具有“root”访问权限。
+
+:::caution
+
+如果你关闭 addLocal，大多数 Rancher 2.5 功能都不能使用，包括 EKS Provisioner。
+
+:::
+
+如果这在你的环境中是一个问题，你可以在初始安装时将此选项设置为“false”。
+
+此选项仅在首次安装 Rancher 时有效。详情请参见 [Issue 16522](https://github.com/rancher/rancher/issues/16522)。
+
+```plain
+--set addLocal="false"
+```
+
+### 自定义 Ingress
+
+要自定义或使用 Rancher Server 的其他 Ingress，你可以设置自己的 Ingress 注释。
+
+设置自定义证书颁发者的示例：
+
+```plain
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
+```
+
+以下是使用 `ingress.configurationSnippet`设置静态代理标头的示例。该值像模板一样进行解析，因此可以使用变量。
+
+```plain
+--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'
+```
+
+### HTTP 代理
+
+Rancher 的一些功能（Helm Chart）需要使用互联网才能使用。你可以使用 `proxy` 设置代理服务器，或使用 `extraEnv` 设置 `HTTPS_PROXY` 环境变量来指向代理服务器。
+
+将要排除的 IP 使用逗号分隔列表添加到 `noProxy` Chart value 中。确保添加了以下值：
+- Pod 集群 IP 范围（默认值：`10.42.0.0/16`）。
+- Service Cluster IP 范围（默认值：`10.43.0.0/16`）。
+- 内部集群域（默认值：`.svc,.cluster.local`）。
+- 任何 Worker 集群 `controlplane` 节点。
+   Rancher 支持在此列表中使用 CIDR 表示法来表示范围。
+
+不包括敏感数据时，可以使用 `proxy` 或 `extraEnv` Chart 选项。使用 `extraEnv` 时将忽略 `noProxy` Helm 选项。因此，`NO_PROXY` 环境变量也必须设置为 `extraEnv`。
+
+以下是使用 `proxy` Chart 选项设置代理的示例：
+
+```plain
+--set proxy="http://<proxy_url:proxy_port>/"
+```
+
+使用 `extraEnv` Chart 选项设置代理的示例：
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+包含敏感数据（例如代理认证凭证）时，请使用 `extraEnv` 选项和 `valueFrom.secretRef` 来防止敏感数据在 Helm 或 Rancher 部署中暴露。
+
+下面是使用 `extraEnv` 配置代理的示例。此示例 Secret 在 Secret 的 `"https-proxy-url"` 键中包含 `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` 值：
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
+--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+有关如何配置环境变量的更多信息，请参阅[为容器定义环境变量](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container)。
+
+### 额外的授信 CA
+
+如果你有私有镜像仓库（registries）、应用商店（catalogs）或拦截证书的代理，则可能需要向 Rancher 添加额外的授信 CA。
+
+```plain
+--set additionalTrustedCAs=true
+```
+
+创建完 Rancher deployment 后，将 pem 格式的 CA 证书复制到一个名为 `ca-additional.pem` 的文件中，并使用 `kubectl` 在 `cattle-system` 命名空间中创建 `tls-ca-additional` 密文。
+
+```plain
+kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-additional.pem=./ca-additional.pem
+```
+
+### 私有仓库和离线安装
+
+有关使用私有仓库安装 Rancher 的详情，请参见[离线安装](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)。
+
+## 外部 TLS 终止
+
+我们建议将负载均衡器配置为 4 层均衡，将普通 80/tcp 和 443/tcp 转发到 Rancher Management 集群节点。集群上的 Ingress Controller 会将端口 80 上的 HTTP 流量重定向到端口 443 上的 HTTPS。
+
+你可以在 Rancher 集群（Ingress）外部的 L7 负载均衡器上终止 SSL/TLS。使用 `--set tls=external` 选项，将负载均衡器指向所有 Rancher 集群节点上的端口 HTTP 80。这将在 HTTP 端口 80 上暴露 Rancher 接口。请注意，允许直接连接到 Rancher 集群的客户端不会被加密。如果你选择这样做，我们建议你将网络级别的直接访问限制为仅你的负载均衡器。
+
+:::note
+
+如果你使用的是私有 CA 签名的证书，请添加 `--set privateCA=true` 并参见[添加 TLS 密文 - 使用私有 CA 签名证书](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md)，为 Rancher 添加 CA 证书。
+
+:::
+
+你的负载均衡器必须支持长期存在的 Websocket 连接，并且需要插入代理头，以便 Rancher 可以正确传送链接。
+
+### 使用 NGINX v0.25 为外部 TLS 配置 Ingress
+
+在 NGINX 0.25 中，NGINX 关于转发头和外部 TLS 终止的行为[已更改](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0220)。因此，如果你同时使用 NGINX 0.25 和外部 TLS 终止配置，你必须编辑 `cluster.yml` 来为 Ingress 启用 `use-forwarded-headers` 选项。
+
+```yaml
+ingress:
+  provider: nginx
+  options:
+    use-forwarded-headers: 'true'
+```
+
+### 必须的 Header
+
+- `Host`
+- `X-Forwarded-Proto`
+- `X-Forwarded-Port`
+- `X-Forwarded-For`
+
+### 建议的超时时间
+
+- 读超时：`1800 seconds`
+- 写超时：`1800 seconds`
+- 连接超时：`30 seconds`
+
+### 健康检查
+
+Rancher 将对 `/healthz` 端点的健康检查响应`200`。
+
+### 示例 NGINX 配置
+
+此 NGINX 配置已在 NGINX 1.14 上进行了测试。
+
+:::caution
+
+此 NGINX 配置只是一个示例，可能不适合你的环境。如需查阅完整文档，请参见 [NGINX 负载均衡 - HTTP 负载均衡](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/)。
+
+:::
+
+- 将 `IP_NODE1`，`IP_NODE2` 和 `IP_NODE3` 替换为你集群中节点的 IP 地址。
+- 将两处的 `FQDN` 均替换为 Rancher 的 DNS 名称。
+- 把 `/certs/fullchain.pem` 和 `/certs/privkey.pem` 分别替换为服务器证书和服务器证书密钥的位置。
+
+```
+worker_processes 4;
+worker_rlimit_nofile 40000;
+
+events {
+    worker_connections 8192;
+}
+
+http {
+    upstream rancher {
+        server IP_NODE_1:80;
+        server IP_NODE_2:80;
+        server IP_NODE_3:80;
+    }
+
+    map $http_upgrade $connection_upgrade {
+        default Upgrade;
+        ''      close;
+    }
+
+    server {
+        listen 443 ssl http2;
+        server_name FQDN;
+        ssl_certificate /certs/fullchain.pem;
+        ssl_certificate_key /certs/privkey.pem;
+
+        location / {
+            proxy_set_header Host $host;
+            proxy_set_header X-Forwarded-Proto $scheme;
+            proxy_set_header X-Forwarded-Port $server_port;
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_pass http://rancher;
+            proxy_http_version 1.1;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection $connection_upgrade;
+            # 此项允许执行的 shell 窗口保持开启，最长可达15分钟。不使用此参数的话，默认1分钟后自动关闭。
+            proxy_read_timeout 900s;
+            proxy_buffering off;
+        }
+    }
+
+    server {
+        listen 80;
+        server_name FQDN;
+        return 301 https://$server_name$request_uri;
+    }
+}
+```
@@ -0,0 +1,5 @@
+---
+title: 安装参考
+---
+
+有关其他安装资源，请参阅以下参考指南：[Rancher Helm Chart 选项](helm-chart-options.md)、[TLS 设置](tls-settings.md)和[功能开关](feature-flags.md)。
@@ -0,0 +1,21 @@
+---
+title: TLS 设置
+---
+
+更改默认 TLS 设置的方法取决于它的安装方式。
+
+## 在高可用 Kubernetes 集群中运行 Rancher
+
+当你在 Kubernetes 集群内安装 Rancher 时，TLS 会在集群的 Ingress Controller 上卸载。可用的 TLS 设置取决于使用的 Ingress Controller：
+
+* nginx-ingress-controller（default RKE2 默认）：[默认的 TLS 版本和密码](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers)。
+* traefik（K3s 默认）：[TLS 选项](https://doc.traefik.io/traefik/https/tls/#tls-options)。
+
+## 在单个 Docker 容器中运行 Rancher
+
+默认 TLS 配置仅支持 TLS 1.2 和安全的 TLS 密码套件。你可以通过设置以下环境变量来更改此配置：
+
+| 参数 | 描述 | 默认 | 可用选项 |
+|-----|-----|-----|-----|
+| `CATTLE_TLS_MIN_VERSION` | 最小 TLS 版本 | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
+| `CATTLE_TLS_CIPHERS` | 支持的 TLS 密码套件 | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | 详情请参见 [Golang TLS 常量](https://golang.org/pkg/crypto/tls/#pkg-constants)。 |
@@ -0,0 +1,187 @@
+---
+title: 安装要求
+description: Learn the node requirements for each node running Rancher server when you’re configuring  Rancher to run either in a Kubernetes setup
+---
+
+本文描述了对需要安装 Rancher Server 的节点的软件、硬件和网络要求。Rancher Server 可以安装在单个节点或高可用的 Kubernetes 集群上。
+
+:::note 重要提示：
+
+如果你需要在 Kubernetes 集群上安装 Rancher，该节点的要求与用于运行应用和服务的[下游集群的节点要求](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)不同。
+
+:::
+
+Rancher UI 在基于 Firefox 或 Chromium 的浏览器（Chrome、Edge、Opera、Brave）中效果最佳。
+
+查看我们的[最佳实践](../../../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md)页面，获取在生产环境中运行 Rancher Server 的建议。
+
+## Kubernetes 与 Rancher 的兼容性
+
+Rancher 需要安装在支持的 Kubernetes 版本上。请查阅 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)，确保你的 Kubernetes 版本受支持。
+
+## 在安全加固的 Kubernetes 集群上安装 Rancher
+
+如果你在安全加固的 Kubernetes 集群上安装 Rancher，请查看[豁免必须的 Rancher 命名空间](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#豁免必须的-rancher-命名空间)以了解详细的要求。
+
+## 操作系统和容器运行时要求
+
+所有支持的操作系统都使用 64-bit x86 架构。Rancher 兼容当前所有的主流 Linux 发行版。
+
+The [Rancher support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions) lists which OS versions were tested for each Rancher version.
+
+运行 RKE 集群的节点需要安装 Docker。RKE2 或 K3s 集群不需要它。
+
+请安装 `ntp`（Network Time Protocol），以防止在客户端和服务器之间由于时间不同步造成的证书验证错误。
+
+某些 Linux 发行版的默认防火墙规则可能会阻止 Kubernetes 集群内的通信。从 Kubernetes v1.19 开始，你必须关闭 firewalld，因为它与 Kubernetes 网络插件冲突。
+
+如果你不太想这样做的话，你可以查看[相关问题](https://github.com/rancher/rancher/issues/28840)中的建议。某些用户已能成功[使用 ACCEPT 策略 为 Pod CIDR 创建一个独立的 firewalld 区域](https://github.com/rancher/rancher/issues/28840#issuecomment-787404822)。
+
+如果你需要在 ARM64 上使用 Rancher，请参见[在 ARM64（实验功能）上运行 Rancher](../../../how-to-guides/advanced-user-guides/enable-experimental-features/rancher-on-arm64.md)。
+
+### RKE2 要求
+
+对于容器运行时，RKE2 附带了自己的 containerd.
+
+如需了解 RKE2 通过了哪些操作系统版本的测试，请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)。
+
+
+### K3s 要求
+
+对于容器运行时，K3s 默认附带了自己的 containerd。你也可以将 K3s 配置为使用已安装的 Docker 运行时。有关在 Docker 中使用 K3s 的更多信息，请参阅 [K3s 文档](https://docs.k3s.io/advanced#using-docker-as-the-container-runtime)。
+
+Rancher 需要安装在支持的 Kubernetes 版本上。如需了解你使用的 Rancher 版本支持哪些 Kubernetes 版本，请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)。如需指定 K3s 版本，在运行 K3s 安装脚本时，使用 `INSTALL_K3S_VERSION` 环境变量。
+
+如果你使用 **Raspbian Buster** 在 K3s 集群上安装 Rancher，请按照[这些步骤](https://rancher.com/docs/k3s/latest/en/advanced/#enabling-legacy-iptables-on-raspbian-buster)切换到旧版 iptables。
+
+如果你使用 Alpine Linux 的 K3s 集群上安装 Rancher，请按照[这些步骤](https://rancher.com/docs/k3s/latest/en/advanced/#additional-preparation-for-alpine-linux-setup)进行其他设置。
+
+### RKE 要求
+
+RKE 需要 Docker 容器运行时。支持的 Docker 版本请参见 [Rancher 支持矩阵](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions)
+
+有关详细信息，请参阅[安装 Docker](install-docker.md)。
+
+## 硬件要求
+
+本节描述安装 Rancher Server 的节点的 CPU、内存和磁盘要求。硬件要求根据你的 Rancher 部署规模而定。
+
+### 实际考虑
+
+Rancher 的硬件占用空间取决于许多因素，包括：
+
+ - 托管的基础设施规模 (例如： 节点数量，集群数量)。
+ - 所需访问控制规则的复杂性（例如：RoleBinding 对象计数）。
+ - 工作负载数量 (例如： Kubernetes 部署，Fleet 部署)。
+ - 使用模式 (例如：主动使用的功能集合，使用频率，并发用户数量).
+
+由于存在许多可能随时间变化的影响因素，因此此处列出的要求为适合大多数用例的起点。 然而，你的用例可能有不同的要求。 若你需要对于特定场景的咨询，请[联系 Rancher](https://rancher.com/contact/) 以获得进一步指导。
+
+
+特别指出，本页面中的要求基于以下假设的环境提出，包括：
+ - 每种类型的 Kubernetes 资源数量小于 60,000 个。
+ - 每个节点最多 120 个 Pod。
+ - 上游（本地）集群中最多 200 个 CRD。
+ - 下游集群中最多 100 个 CRD。
+ - 最多 50 个 Fleet 部署。
+
+更多的数量也是能够达到的，但需要更高的硬件要求。 如果你有超过 20,000 个相同类型的资源，通过 Rancher UI 加载整个列表的时间可能需要几秒钟。
+
+:::note Evolution:
+
+Rancher 的代码库不断发展，用例不断变化，Rancher 积累的经验也在不断增长。
+
+随着指导方针的准确性不断的提高并且变得更加具体，硬件要求也会发生变化。
+
+如果你发现你的 Rancher 部署不再符合列出的建议，请[联系 Rancher](https://rancher.com/contact/) 进行重新评估。
+
+:::
+
+### RKE2 Kubernetes
+
+下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
+
+请注意，生产环境下的高可用安装最少需要 3 个节点。
+
+| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存 |
+| --------------- | -------- | --------- | ----- | ---- |
+| 小                       | 150                        | 1500                    | 4     | 16 GB |
+| 中                      | 300                        | 3000                    | 8     | 32 GB |
+| 大 (*)                   | 500                        | 5000                    | 16    | 64 GB |
+| 更大 (†)                  | (†)                        | (†)                     | (†)   | (†)   |
+
+(*)： 大规模的部署需要你[遵循最佳实践](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md)以获得足够的性能。
+
+(†)： 通过特别的硬件建议和调整能够实现更大的部署规模。 你可以[联系 Rancher](https://rancher.com/contact/) 进行定制评估。
+
+有关 RKE2 一般要求的更多详细信息，请参见 [RKE2 文档](https://docs.rke2.io/install/requirements)。
+
+### K3s Kubernetes
+
+下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
+
+请注意，生产环境下的高可用安装最少需要 3 个节点。
+
+| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存 | 外部数据库(*) |
+| --------------- | ---------- | ------------ | -------| ---------| ------------------------- |
+| Small                       | 150                        | 1500                    | 4     | 16 GB | 2 vCPUs, 8 GB + 1000 IOPS  |
+| Medium                      | 300                        | 3000                    | 8     | 32 GB | 4 vCPUs, 16 GB + 2000 IOPS |
+| Large (†)                   | 500                        | 5000                    | 16    | 64 GB | 8 vCPUs, 32 GB + 4000 IOPS |
+
+(*)：外部数据库是指将 K3s 集群数据存储在[专用的外部主机](https://docs.k3s.io/datastore)上。 这是可选的。 具体要求取决于使用的外部数据库。
+
+(†)：大规模的部署需要你[遵循最佳实践](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md)以获得足够的性能。
+
+有关 K3s 一般要求的更多详细信息，请参见 [K3s 文档](https://docs.k3s.io/installation/requirements)。
+
+### 托管 Kubernetes
+
+下面的表格列出了[上游集群](../install-upgrade-on-a-kubernetes-cluster/install-upgrade-on-a-kubernetes-cluster.md)中每个节点最小的 CPU 和内存要求。
+
+请注意，生产环境下的高可用安装最少需要 3 个节点。
+
+这些要求适用于托管 Kubernetes 集群，例如 Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS) 或 Google Kubernetes Engine (GKE)。 它们不适用于 Rancher SaaS 解决方案，例如 [Rancher Prime Hosted](https://www.rancher.com/products/rancher)。
+
+| 部署规模 | 最大集群数量 | 最大节点数量 | vCPUs | 内存   |
+|-----------------------------|----------------------------|-------------------------|-------|-------|
+| 小                       | 150                        | 1500                    | 4     | 16 GB |
+| 中                      | 300                        | 3000                    | 8     | 32 GB |
+| 大 (*)                   | 500                        | 5000                    | 16    | 64 GB |
+
+(*)：大规模的部署需要你[遵循最佳实践](../../../reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale.md)以获得足够的性能。
+
+## Ingress
+
+安装 Rancher 的 Kubernetes 集群中的每个节点都应该运行一个 Ingress。
+
+Ingress 需要部署为 DaemonSet 以确保负载均衡器能成功把流量转发到各个节点。
+
+如果是 RKE2 和 K3s 安装，你不需要手动安装 Ingress，因为它是默认安装的。
+
+对于托管的 Kubernetes 集群（EKS、GKE、AKS），你需要设置 Ingress。
+
+- **Amazon EKS**：[在 Amazon EKS 上安装 Rancher 以及如何安装 Ingress 以访问 Rancher Server](../install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md)。
+- **AKS**：[使用 Azure Kubernetes 服务安装 Rancher 以及如何安装 Ingress 以访问 Rancher Server](../install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md)。
+- **GKE**：[使用 GKE 安装 Rancher 以及如何安装 Ingress 以访问 Rancher Server](../install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md)。
+
+## 磁盘
+
+etcd 在集群中的性能决定了 Rancher 的性能。因此，为了获得最佳速度，我们建议使用 SSD 磁盘来支持 Rancher 管理的 Kubernetes 集群。在云提供商上，你还需使用能获得最大 IOPS 的最小大小。在较大的集群中，请考虑使用专用存储设备存储 etcd 数据和 wal 目录。
+
+## 网络要求
+
+本节描述了安装 Rancher Server 的节点的网络要求。
+
+:::caution
+
+如果包含 Rancher 的服务器带有 `X-Frame-Options=DENY` 标头，在升级旧版 UI 之后，Rancher UI 中的某些页面可能无法渲染。这是因为某些旧版页面在新 UI 中是以 iFrames 模式嵌入的。
+
+:::
+
+### 节点 IP 地址
+
+无论你是在单个节点还是高可用集群上安装 Rancher，每个节点都应配置一个静态 IP。如果使用 DHCP，则每个节点都应该有一个 DHCP 预留，以确保节点分配到相同的 IP 地址。
+
+### 端口要求
+
+为了确保能正常运行，Rancher 需要在 Rancher 节点和下游 Kubernetes 集群节点上开放一些端口。不同集群类型的 Rancher 和下游集群的所有必要端口，请参见[端口要求](port-requirements.md)。
@@ -0,0 +1,295 @@
+---
+title: 端口要求
+description: 了解 Rancher 正常运行所需的端口要求，包括 Rancher 节点和下游 Kubernetes 集群节点
+---
+
+import PortsIaasNodes from '@site/src/components/PortsIaasNodes'
+import PortsCustomNodes from '@site/src/components/PortsCustomNodes'
+import PortsImportedHosted from '@site/src/components/PortsImportedHosted'
+
+为了确保能正常运行，Rancher 需要在 Rancher 节点和下游 Kubernetes 集群节点上开放一些端口。
+
+## Rancher 节点
+
+下表列出了运行 Rancher Server 的节点之间需要开放的端口。
+
+不同的 Rancher Server 架构有不同的端口要求。
+
+Rancher 可以安装在任何 Kubernetes 集群上。如果你的 Rancher 安装在 K3s 或 RKE2 Kubernetes 集群上，请参考下面的标签页。对于其他 Kubernetes 发行版，请参见该发行版的文档，了解集群节点的端口要求。
+
+:::note 注意事项：
+
+- Rancher 节点可能要求额外出站访问已配置的外部验证提供程序（如 LDAP）。
+- Kubernetes 建议节点端口服务使用 TCP 30000-32767。
+- 对于防火墙，可能需要在集群和 Pod CIDR 内启用流量。
+- Rancher 节点可能还需要出站访问用于存储集群备份（如 Minio）的外部 S3 上的位置。
+
+:::
+
+### K3s 上 Rancher Server 节点的端口
+
+<details>
+  <summary>单击展开</summary>
+
+K3s server 需要开放端口 6443 才能供节点访问。
+
+使用 Flannel VXLAN 时，节点需要能够通过 UDP 端口 8472 访问其他节点。节点不应监听任何其他端口。K3s 使用反向隧道，建立节点与 Server 的出站连接，所有 kubelet 流量都通过该隧道进行。但是，如果你不使用 Flannel，而是使用自定义的 CNI，K3s 则不需要打开 8472 端口。
+
+如果要使用 Metrics Server，则需要在每个节点上打开端口 10250。
+
+:::note 重要提示：
+
+节点上的 VXLAN 端口会开放集群网络，让任何人均能访问集群。因此，不要将 VXLAN 端口暴露给外界。请使用禁用 8472 端口的防火墙/安全组来运行节点。
+
+:::
+
+下表描述了入站和出站流量的端口要求：
+
+<figcaption>Rancher Server 节点的入站规则</figcaption>
+
+| 协议 | 端口 | 源 | 描述 |
+|-----|-----|----------------|---|
+| TCP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
+| TCP | 443 | <ul><li>Server 节点</li><li>Agent 节点</li><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent，Rancher UI/API，kubectl |
+| TCP | 6443 | K3s Server 节点 | Kubernetes API |
+| UDP | 8472 | K3s Server 和 Agent 节点 | 仅 Flannel VXLAN 需要 |
+| TCP | 10250 | K3s Server 和 Agent 节点 | kubelet |
+
+<figcaption>Rancher 节点的出站规则</figcaption>
+
+| 协议 | 端口 | 目标 | 描述 |
+| -------- | ---- | -------------------------------------------------------- | --------------------------------------------- |
+| TCP | 22 | 使用 Node Driver 创建的节点的任何节点 IP | 使用 Node Driver SSH 配置节点 |
+| TCP | 443 | git.rancher.io | Rancher catalog |
+| TCP | 2376 | 使用 Node Driver 创建的节点的任何节点 IP | Docker Machine 使用的 Docker daemon TLS 端口 |
+| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
+
+</details>
+
+### RKE2 上 Rancher Server 节点的端口
+
+<details>
+  <summary>单击展开</summary>
+
+RKE2 server 需要开放端口 6443 和 9345 才能供集群中的其他节点访问。
+
+使用 Flannel VXLAN 时，所有节点都需要能够通过 UDP 端口 8472 访问其他节点。
+
+如果要使用 Metrics Server，则需要在每个节点上打开端口 10250。
+
+:::note 重要提示：
+
+节点上的 VXLAN 端口会开放集群网络，让任何人均能访问集群。因此，不要将 VXLAN 端口暴露给外界。请使用禁用 8472 端口的防火墙/安全组来运行节点。
+
+:::
+
+<figcaption>RKE2 Server 节点的入站规则</figcaption>
+
+| 协议 | 端口 | 源 | 描述 |
+|-----|-----|----------------|---|
+| TCP | 9345 | RKE2 Server 和 Agent 节点 | 节点注册。需要在所有 Server 节点上将端口开放给集群中的所有其他节点。 |
+| TCP | 6443 | RKE2 Agent 节点 | Kubernetes API |
+| UDP | 8472 | RKE2 Server 和 Agent 节点 | 仅 Flannel VXLAN 需要 |
+| TCP | 10250 | RKE2 Server 和 Agent 节点 | kubelet |
+| TCP | 2379 | RKE2 Server 节点 | etcd 客户端端口 |
+| TCP | 2380 | RKE2 Server 节点 | etcd 对等端口 |
+| TCP | 30000-32767 | RKE2 Server 和 Agent 节点 | NodePort 端口范围。可以使用 TCP 或 UDP。 |
+| TCP | 5473 | Calico-node pod 连接到 typha pod | 使用 Calico 部署时需要 |
+| HTTP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
+| HTTPS | 443 | <ul><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent，Rancher UI/API，kubectl。如果负载均衡器执行 TLS 终止，则不需要。 |
+
+所有出站流量通常都是允许的。
+</details>
+
+### Docker 安装的 Rancher Server 的端口
+
+<details>
+  <summary>单击展开</summary>
+
+下表描述了 Rancher 节点入站和出站流量的端口要求：
+
+<figcaption>Rancher 节点的入站规则</figcaption>
+
+| 协议 | 端口 | 源 | 描述 |
+|-----|-----|----------------|---|
+| TCP | 80 | 执行外部 SSL 终止的负载均衡器/代理 | 使用外部 SSL 终止时的 Rancher UI/API |
+| TCP | 443 | <ul><li>托管/注册的 Kubernetes</li><li>任何需要使用 Rancher UI 或 API 的源</li></ul> | Rancher Agent，Rancher UI/API，kubectl |
+
+<figcaption>Rancher 节点的出站规则</figcaption>
+
+| 协议 | 端口 | 源 | 描述 |
+|-----|-----|----------------|---|
+| TCP | 22 | 使用 Node Driver 创建的节点的任何节点 IP | 使用 Node Driver SSH 配置节点 |
+| TCP | 443 | git.rancher.io | Rancher catalog |
+| TCP | 2376 | 使用 Node Driver 创建的节点的任何节点 IP | Docker Machine 使用的 Docker daemon TLS 端口 |
+| TCP | 6443 | 托管/导入的 Kubernetes API | Kubernetes API Server |
+
+</details>
+
+## 下游 Kubernetes 集群节点
+
+下游 Kubernetes 集群用于运行你的应用和服务。本节介绍了哪些端口需要在下游集群的节点上打开，以便 Rancher 能够与它们进行通信。
+
+不同的下游集群的启动方式有不同的端口要求。下面的每个标签都列出了不同[集群类型](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md)所需打开的端口。
+
+下图描述了为每个[集群类型](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md)打开的端口。
+
+<figcaption>Rancher 管理面板的端口要求</figcaption>
+
+![基本端口要求](/img/port-communications.svg)
+
+:::tip
+
+如果你对安全性的关注不是太高，而且也愿意多打开几个端口，你可以参考[常用端口](#常用端口)中列出的端口，而不是参考下方的表格。
+
+:::
+
+### Harvester 集群的端口
+
+有关 Harvester 端口要求的更多信息，请参阅[此处](../../../integrations-in-rancher/harvester.md#端口要求)。
+
+
+### Rancher 使用节点池启动 Kubernetes 集群的端口
+
+<details>
+  <summary>单击展开</summary>
+
+下表描述了节点在[云提供商](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)中创建的情况下，[Rancher 启动 Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 的端口要求。
+
+:::note
+
+在 AWS EC2 或 DigitalOcean 等云提供商中创建集群期间，Rancher 会自动打开所需的端口。
+
+:::
+
+<PortsIaasNodes/>
+
+</details>
+
+### Rancher 使用自定义节点启动 Kubernetes 集群的端口
+
+<details>
+  <summary>单击展开</summary>
+
+下表描述了使用[自定义节点](../../../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/use-existing-nodes.md)的情况下，[Rancher 启动 Kubernetes](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 的端口要求。
+
+<PortsCustomNodes/>
+
+</details>
+
+### 托管 Kubernetes 集群的端口
+
+<details>
+  <summary>单击展开</summary>
+
+下表描述了[托管集群](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md)的端口要求。
+
+<PortsImportedHosted/>
+
+</details>
+
+### 已注册集群的端口
+
+:::note
+
+在 Rancher 2.5 之前，注册集群被称为导入集群。
+
+:::
+
+<details>
+  <summary>单击展开</summary>
+
+下表描述了[注册集群](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md)的端口要求。
+
+<PortsImportedHosted/>
+
+</details>
+
+
+## 其他端口注意事项
+
+### 常用端口
+
+无论集群是什么类型，常用端口通常在你的 Kubernetes 节点上打开。
+
+import CommonPortsTable from '../../../shared-files/_common-ports-table.md';
+
+<CommonPortsTable />
+
+----
+
+### 本地节点流量
+
+上述要求中标记为`本地流量`（例如 `9099 TCP`）的端口会用于 Kubernetes 健康检查 （`livenessProbe` 和 `readinessProbe`）。
+这些健康检查是在节点本身执行的。在大多数云环境中，这种本地流量是默认允许的。
+
+但是，在以下情况下可能会阻止此流量：
+
+- 你已在节点上应用了严格的主机防火墙策略。
+- 你正在使用有多个接口（多宿主）的节点。
+
+在这些情况下，你必须在你的主机防火墙中主动允许这种流量，如果是公共/私有云托管的主机（例如 AWS 或 OpenStack），你需要在你的安全组配置中主动允许此流量。请记住，如果你在安全组中使用安全组作为源或目标，主动开放端口只适用于节点/实例的私有接口。
+
+### Rancher AWS EC2 安全组
+
+当你使用 [AWS EC2 Node Driver](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) 在 Rancher 中配置集群节点时，你可以让 Rancher 创建一个名为 `rancher-nodes` 的安全组。以下规则会自动添加到该安全组中。
+
+| 类型 | 协议 | 端口范围 | 源/目标 | 规则类型 |
+|-----------------|:--------:|:-----------:|------------------------|:---------:|
+| SSH | TCP | 22 | 0.0.0.0/0 | 入站 |
+| HTTP | TCP | 80 | 0.0.0.0/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 443 | 0.0.0.0/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 2376 | 0.0.0.0/0 | 入站 |
+| 自定义 TCP 规则 | TCP | 2379-2380 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 UDP 规则 | UDP | 4789 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 6443 | 0.0.0.0/0 | 入站 |
+| 自定义 UDP 规则 | UDP | 8472 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 10250-10252 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 10256 | sg-xxx (rancher-nodes) | 入站 |
+| 自定义 TCP 规则 | TCP | 30000-32767 | 0.0.0.0/0 | 入站 |
+| 自定义 UDP 规则 | UDP | 30000-32767 | 0.0.0.0/0 | 入站 |
+| 所有流量 | 全部 | 全部 | 0.0.0.0/0 | 出站 |
+
+### 打开 SUSE Linux 端口
+
+SUSE Linux 可能有一个防火墙，默认情况下会阻止所有端口。要打开将主机添加到自定义集群所需的端口：
+
+<Tabs>
+<TabItem value="SLES 15 / openSUSE Leap 15">
+
+1. SSH 进入实例。
+1. 以文本模式启动 YaST：
+   ```
+   sudo yast2
+   ```
+
+1. 导航到**安全和用户** > **防火墙** > **区域：公共** > **端口**。要在界面内导航，请参照[说明](https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-yast-text.html#sec-yast-cli-navigate)。
+1. 要打开所需的端口，把它们输入到 **TCP 端口** 和 **UDP 端口** 字段。在这个例子中，端口 9796 和 10250 也被打开，用于监控。由此产生的字段应类似于以下内容：
+   ```yaml
+   TCP Ports
+   22, 80, 443, 2376, 2379, 2380, 6443, 9099, 9796, 10250, 10254, 30000-32767
+   UDP Ports
+   8472, 30000-32767
+   ```
+
+1. 所有必须端口都输入后，选择**接受**。
+
+</TabItem>
+<TabItem value="SLES 12 / openSUSE Leap 42">
+
+1. SSH 进入实例。
+1. 编辑 `/etc/sysconfig/SuSEfirewall2` 并打开所需的端口。在这个例子中，端口 9796 和 10250 也被打开，用于监控。
+   ```
+   FW_SERVICES_EXT_TCP="22 80 443 2376 2379 2380 6443 9099 9796 10250 10254 30000:32767"
+   FW_SERVICES_EXT_UDP="8472 30000:32767"
+   FW_ROUTE=yes
+   ```
+1. 用新的端口重启防火墙：
+   ```
+   SuSEfirewall2
+   ```
+
+</TabItem>
+</Tabs>
+
+**结果** ：该节点已打开添加到自定义集群所需的端口。
@@ -0,0 +1,31 @@
+---
+title: 离线 Helm CLI 安装
+---
+
+本文介绍如何使用 Helm CLI 在离线环境中安装 Rancher Server。离线环境可以是 Rancher Server 离线安装、防火墙后面或代理后面。
+
+Rancher 安装在 K3s Kubernetes 集群，或单个 Docker 容器上对应的安装步骤会有所不同。
+
+如需了解各个安装方式的更多信息，请参见[本页](../../installation-and-upgrade.md)。
+
+在安装指导中，我们为不同的安装选项提供对应的 _选项卡_ 。
+
+:::note 重要提示：
+
+如果你按照 Docker 安装指南安装 Rancher，你将没有把 Docker 安装转换为 Kubernetes 安装的升级途径。
+
+:::
+
+## 安装概要
+
+1. [设置基础设施和私有镜像仓库](infrastructure-private-registry.md)
+2. [收集镜像到私有镜像仓库](publish-images.md)
+3. [设置 Kubernetes 集群（如果你使用 Docker 安装，请跳过此步骤）](install-kubernetes.md)
+4. [安装 Rancher](install-rancher-ha.md)
+
+## 升级
+
+如需在离线环境中使用 Helm CLI 升级 Rancher，请按照[升级步骤](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md)进行操作。
+
+### 后续操作
+[准备节点](infrastructure-private-registry.md)
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Sunil Singh	50de72dac8	Merge pull request #2127 from rancher/v2.13.1 Merge release v2.13.1 into main	2025-12-18 19:28:07 -08:00
Sunil Singh	bd5ce6a698	Merge pull request #2126 from rancher/v2.12.5 Merge release v2.12.5 into main	2025-12-18 19:27:48 -08:00
Sunil Singh	6b578c03b8	Merge pull request #2125 from rancher/v2.11.9 Merge release v2.11.9 into main	2025-12-18 19:27:32 -08:00
Petr Kovar	3e84995a70	Merge pull request #2123 from pmkovar/v2.11.9-maintenance v2.11.9 - Rancher Manager Release Maintenance	2025-12-18 18:03:09 +01:00
Petr Kovar	73eba84c8f	Merge pull request #2122 from pmkovar/v2.12.5-maintenance v2.12.5 - Rancher Manager Release Maintenance	2025-12-18 18:02:29 +01:00
Petr Kovar	83169414e0	Merge pull request #2121 from pmkovar/v2.13.1-maintenance v2.13.1 - Rancher Manager Release Maintenance	2025-12-18 18:01:58 +01:00
Petr Kovar	59c6d18303	Apply suggestions from code review	2025-12-18 16:19:48 +01:00
Petr Kovar	cc971f12cd	Apply suggestions from code review	2025-12-18 16:18:45 +01:00
Petr Kovar	56217388e0	Apply suggestions from code review	2025-12-18 16:17:39 +01:00
Petr Kovar	4038b6b6a0	Update _cni-popularity.md	2025-12-16 20:13:07 +01:00
Petr Kovar	f3ebddde6e	v2.11.9 - Rancher Manager Release Maintenance Helps #2106.	2025-12-16 19:35:49 +01:00
Petr Kovar	8dc10af3d1	v2.12.5 - Rancher Manager Release Maintenance Helps #2107.	2025-12-16 19:22:53 +01:00
Petr Kovar	8a705b1d66	v2.13.1 - Rancher Manager Release Maintenance Helps #2108.	2025-12-16 17:44:38 +01:00
Jonathan Crowther	033a6ecb52	Make the projects workflow page reference the backingNamespace field (#2075 ) * Make the projects workflow page reference the backingNamespace field * Add suggestions * Fix typo	2025-12-15 12:56:35 -08:00
Billy Tat	d69bad7fd4	Merge pull request #2114 from btat/self-ref-link Remove self-referencing link	2025-12-03 09:09:46 -08:00
Billy Tat	cb8c124163	Remove self-referencing link	2025-11-28 16:38:25 -08:00
Jake Hyde	abf80148ac	Add docs for tls-additional (#1981 ) * Add docs for tls-additional * Address review comments * Add tls-additional docs to previous versions	2025-11-26 15:15:30 -08:00
Meza	49fa9264c4	Fix broken indentation in api workflow docs (#2110 ) Signed-off-by: Meza <meza-xyz@proton.me>	2025-11-26 11:32:19 -08:00
+4 Billy Tat Tejeev Andy Pitcher Sunil Singh Andreas Kupries Peter Matseykanets Lucas Saintarbor Petr Kovar Jonathan Crowther Peter Matseykanets Petr Kovar Krunal Hingu Raul Cabello Martin Jack Luo	24fc5a657c	Merge release v2.13.0 to main (#2091 ) * Sync main to v2.13.0 (#2065) * It's bad form to ask users to pass something they just curled from the internet directly to sh Updated the instructions for uninstalling the rancher-system-agent to use a temporary script file instead of piping directly to sh. * doc(rancher-security): improve structure and content to latest, v2.13-preview and v2.12 (#2024) - add Rancher Kubernetes Distributions (K3s/RKE2) Self-Assessment and Hardening Guide section - add kubernetes cluster security best practices link to rancher-security section - add k3s-selinux and update selinux-rpm details - remove rhel/centos 7 support Signed-off-by: Andy Pitcher <andy.pitcher@suse.com> * Updating across supported versions and translations. Signed-off-by: Sunil Singh <sunil.singh@suse.com> --------- Signed-off-by: Andy Pitcher <andy.pitcher@suse.com> Signed-off-by: Sunil Singh <sunil.singh@suse.com> Co-authored-by: Tejeev <tj@rancher.com> Co-authored-by: Andy Pitcher <andy.pitcher@suse.com> Co-authored-by: Sunil Singh <sunil.singh@suse.com> * Update roletemplate aggregation doc and version information * Add versioned docs * Remove ext token and kubeconfig feature flag sections and document bearer Token * Update corresponding v2.13 pages * update doc for pni in gke * Adding reverted session idle information from PR 1653 Signed-off-by: Sunil Singh <sunil.singh@suse.com> * [2.13.0] Add versions table entry * [2.13.0] Add webhook version * [2.13.0] Add CSP Adapter version * [2.13.0] Add deprecated feature table entry * [2.13.0] Update CNI popularity stats * Update GKE Cluster Configuration for Project Network Isolation instructions * Fix link and port to 2.13 * [2.13.0] Add Swagger JSON * [v2.13.0] Add info about Azure AD Roles claims (#2079) * Add info about Azure AD roles claims compatibility * Apply suggestions from code review Co-authored-by: Sunil Singh <sunil.singh@suse.com> * Add suggestions to v2.13 --------- Co-authored-by: Sunil Singh <sunil.singh@suse.com> * [2.13.0] Remove preview designation * user public api docs (#2069) * user public api docs * Apply suggestions from code review Co-authored-by: Andreas Kupries <akupries@suse.com> * Apply suggestions from code review Co-authored-by: Peter Matseykanets <pmatseykanets@gmail.com> * explain plaintext is never stored * add users 2.13 versioned docs * remove extra ``` * Apply suggestions from code review Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com> * add space before code block --------- Co-authored-by: Andreas Kupries <akupries@suse.com> Co-authored-by: Peter Matseykanets <pmatseykanets@gmail.com> Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com> * support IPv6 (#2041) * [v2.13.0] Add Configure GitHub App page (#2081) * Add Configure GitHub App page * Apply suggestions from code review Co-authored-by: Billy Tat <btat@suse.com> * Fix header/GH URL & add suggestions to v2.13 * Apply suggestions from code review Co-authored-by: Petr Kovar <pknbe@volny.cz> * Apply suggestions from code review to v2.13 * Add note describing why to use Installation ID * Apply suggestions from code review Co-authored-by: Billy Tat <btat@suse.com> --------- Co-authored-by: Billy Tat <btat@suse.com> Co-authored-by: Petr Kovar <pknbe@volny.cz> * [v2.13.0] Add info about Generic OIDC Custom Mapping (#2080) * Add info about Generic OIDC Custom Mapping * Apply suggestions from code review Co-authored-by: Sunil Singh <sunil.singh@suse.com> Co-authored-by: Billy Tat <btat@suse.com> * Apply suggestions from code review Co-authored-by: Sunil Singh <sunil.singh@suse.com> Co-authored-by: Billy Tat <btat@suse.com> * Add suggestions to v2.13 * Remove repetitive statement in intro * Move Prereq intro/note to appropriate section * Fix formatting, UI typo, add Custom Claims section under Configuration Reference section * Add section about how a custom groups claim works / note about search limitations for groups in RBAC --------- Co-authored-by: Sunil Singh <sunil.singh@suse.com> Co-authored-by: Billy Tat <btat@suse.com> * [v2.13.0] Add info about OIDC SLO support (#2086) * Add shared file covering OIDC SLO support to OIDC auth pages * Ad How to get the End Session Endpoint steps * Add generic curl exampleto retrieve end_session_endpoint * [2.13.0] Bump release date --------- Signed-off-by: Andy Pitcher <andy.pitcher@suse.com> Signed-off-by: Sunil Singh <sunil.singh@suse.com> Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com> Co-authored-by: Tejeev <tj@rancher.com> Co-authored-by: Andy Pitcher <andy.pitcher@suse.com> Co-authored-by: Sunil Singh <sunil.singh@suse.com> Co-authored-by: Jonathan Crowther <jonathan.crowther@suse.com> Co-authored-by: Peter Matseykanets <peter.matseykanets@suse.com> Co-authored-by: Petr Kovar <petr.kovar@suse.com> Co-authored-by: Krunal Hingu <krunal.hingu222@gmail.com> Co-authored-by: Raul Cabello Martin <raul.cabello@suse.com> Co-authored-by: Andreas Kupries <akupries@suse.com> Co-authored-by: Peter Matseykanets <pmatseykanets@gmail.com> Co-authored-by: Jack Luo <jiaqi.luo@suse.com> Co-authored-by: Petr Kovar <pknbe@volny.cz>	2025-11-25 10:51:39 -08:00
Billy TatandLucas Saintarbor	94197793cb	Merge release v2.12.4 to main (#2090 ) * [2.12.4] Add versions table entry * [2.12.4] Bump webhook table entry * [2.12.4] Add deprecated feature table entry * [2.12.4] Add CSP Adapter table entry * Fix version availability - no longer has Community Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com> --------- Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>	2025-11-24 17:43:12 -08:00
Billy Tat	28fa33e752	Merge pull request #2089 from rancher/v2.11.8 Merge release v2.11.8 to main	2025-11-24 17:04:13 -08:00
Petr Kovar	b3c79206b3	Merge pull request #1953 from OdedNeuhaus/patch-1 Scale down the original Rancher server	2025-11-24 19:56:49 +01:00
Billy Tat	81f32d6a4c	Merge pull request #2083 from btat/v2.11.8-maintenance v2.11.8 maintenance tasks	2025-11-19 15:00:33 -08:00
Billy Tat	ccdc8cecfa	Merge pull request #2072 from pmkovar/backport_docs.sh Add backport_docs.sh	2025-11-19 14:45:13 -08:00
Billy TatandLucas Saintarbor	ea88c5ed74	Fix version typo Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>	2025-11-19 07:59:10 -08:00
Billy Tat	f10c1c630a	[2.11.8] Add CSP Adapter table entry	2025-11-18 17:12:21 -08:00
Billy Tat	efd1a027cc	[2.11.8] Add deprecated feature table entry	2025-11-18 17:12:21 -08:00
Billy Tat	592c6e02cb	[2.11.8] Bump webhook version	2025-11-18 17:12:16 -08:00
Billy Tat	2ca8417958	[2.11.8] Add versions table entry	2025-11-18 15:54:11 -08:00
Petr Kovar	6e2f0ddfc0	Add backport_docs.sh A script to backport changes (added, modified, and removed files) from 'docs/' and 'sidebars.js' to their versioned counterparts.	2025-11-11 17:23:07 +01:00
Petr Kovar	4372563bb6	Merge pull request #2055 from masap/fix-2054 Fix difference beteween `psa-config-templates.md` and `psa-restricted-exemptions.md`	2025-11-10 19:31:08 +01:00
Petr Kovar	c899b6563b	Backport changes	2025-11-10 19:09:24 +01:00
Petr Kovar	ce6faea156	Merge branch 'main' into patch-1	2025-11-10 19:08:11 +01:00
Gabriel Blais-DuchesneandLucas Saintarbor	764dbfd2e2	Fix v1.29 in-tree provider usage instructions for Azure (#2033 ) * Update azure.md for in-tree cloud providers in v1.29 Correct 'DisableKubeletCloudCredentialProvider' feature gate name to 'DisableKubeletCloudCredentialProviders'. Add both feature gates in the argument for Kubelet, Controller Manager and API Server since both are required in all of these components in v1.29. Also added the Cloud Provider Integration changes blog post for more details along with an example of the argument. * Add v1.29 Azure in-tree provider details on versioned docs compatible with v1.29 * Apply new link to upstream documentation Apply new link to upstream documentation for the Azure in-tree cloud providers. Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com> * Added Azure in-tree provider corrections to 2.13 docs --------- Co-authored-by: Lucas Saintarbor <lucas.saintarbor@suse.com>	2025-11-07 15:21:49 -08:00
Petr Kovar	0167f01846	Merge branch 'main' into fix-2054	2025-11-05 18:49:57 +01:00
Sunil Singh	53df2febeb	Merge pull request #2052 from Tejeev/patch-6 It's bad form to ask users to pass something they just curled from th…	2025-11-03 15:44:23 -08:00
Sunil Singh	2a36becbeb	Updating across supported versions and translations. Signed-off-by: Sunil Singh <sunil.singh@suse.com>	2025-11-03 15:11:31 -08:00
Andy Pitcher	dae5fda314	doc(rancher-security): improve structure and content to latest, v2.13-preview and v2.12 (#2024 ) - add Rancher Kubernetes Distributions (K3s/RKE2) Self-Assessment and Hardening Guide section - add kubernetes cluster security best practices link to rancher-security section - add k3s-selinux and update selinux-rpm details - remove rhel/centos 7 support Signed-off-by: Andy Pitcher <andy.pitcher@suse.com>	2025-10-31 09:25:39 -07:00
Masashi Honma	85eada02ef	Fix difference beteween psa-config-templates.md and psa-restricted-exemptions.md Fixes #2054. Signed-off-by: Masashi Honma <masashi.honma@gmail.com>	2025-10-29 17:12:48 +09:00
Billy Tat	56deac4918	Merge pull request #2053 from btat/v2.13-preview Add v2.13 preview docs	2025-10-27 15:37:47 -07:00
Billy Tat	51a03551a5	Add v2.13 preview docs	2025-10-24 16:06:44 -07:00
Tejeev	adb2726735	It's bad form to ask users to pass something they just curled from the internet directly to sh Updated the instructions for uninstalling the rancher-system-agent to use a temporary script file instead of piping directly to sh.	2025-10-24 16:26:42 -06:00
Petr Kovar	7d899ad89e	Merge branch 'main' into patch-1	2025-09-29 22:11:54 +02:00
Oded Neuhaus	73363534e8	Merge branch 'main' into patch-1	2025-08-21 23:31:41 +03:00
Oded NeuhausandPetr Kovar	73a2dc4671	Update docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md Co-authored-by: Petr Kovar <pknbe@volny.cz>	2025-08-21 23:31:17 +03:00
Oded NeuhausandPetr Kovar	b43b19fda2	Update docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md Co-authored-by: Petr Kovar <pknbe@volny.cz>	2025-08-21 23:31:03 +03:00
OdedNeuhaus	5046e36283	Update migrate-rancher-to-new-cluster.md I was migrating my Rancher instance to a new cluster running RKE2 (the original local cluster was running RKE1), if followed the steps as described in https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster I found out that after i made the change on my DNS server - all the clusters that were registrated to my original Rancher server - were stuck on updating in the new Rancher server. I figured out that the cattle-cluster-agents were still communicating with the old Rancher server, and had to be restarted, or fail their connection with it - in order to make them communicate with the new Rancher server. I assume that more Rancher users can experience this problem, and this add to the Rancher migration guide will make their migrating operation easier.	2025-08-11 20:20:22 +03:00