mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-28 05:59:03 +00:00
Merge remote-tracking branch 'upstream/main' into move-pages-for-subheaders-latest
This commit is contained in:
Billy Tat
@@ -24,7 +24,7 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| <a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.<br/>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
| `AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.<br/>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
| `AUDIT_LOG_PATH` | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host. <br/><br/>Usage Example: `AUDIT_LOG_PATH=/my/custom/path/`<br/> |
|
||||
| `AUDIT_LOG_MAXAGE` | Defined the maximum number of days to retain old audit log files. Default is 10 days. |
|
||||
| `AUDIT_LOG_MAXBACKUP` | Defines the maximum number of audit log files to retain. Default is 10. |
|
||||
@@ -34,7 +34,7 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
### Audit Log Levels
|
||||
|
||||
The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#audit-level) setting.
|
||||
The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#api-audit-log-options) setting.
|
||||
|
||||
| `AUDIT_LEVEL` Setting | Request Metadata | Request Body | Response Metadata | Response Body |
|
||||
| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Allow Unsupported Storage Drivers
|
||||
title: Allowing Unsupported Storage Drivers
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 1. Enable Istio in the Cluster
|
||||
title: Enable Istio in the Cluster
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 2. Enable Istio in a Namespace
|
||||
title: Enable Istio in a Namespace
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 6. Generate and View Traffic
|
||||
title: Generate and View Traffic from Istio
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 4. Set up the Istio Gateway
|
||||
title: Set up the Istio Gateway
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 5. Set up Istio's Components for Traffic Management
|
||||
title: Set up Istio's Components for Traffic Management
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: 3. Add Deployments and Services with the Istio Sidecar
|
||||
title: Add Deployments and Services with the Istio Sidecar
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Pod Security Policies
|
||||
title: Applying Pod Security Policies to Projects
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Monitoring Guides
|
||||
title: Monitoring/Alerting Guides
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Provisioning Drivers
|
||||
title: About Provisioning Drivers
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Template Enforcement
|
||||
title: Enforcing Templates
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Authentication Config
|
||||
title: Configuring Authentication
|
||||
weight: 10
|
||||
---
|
||||
|
||||
|
||||
+1
-3
@@ -33,7 +33,6 @@ Before you start, open two browser tabs: one for Rancher, and one for the Azure
|
||||
|
||||
:::
|
||||
|
||||
|
||||
#### 1. Register Rancher with Azure
|
||||
|
||||
Before enabling Azure AD within Rancher, you must register Rancher with Azure.
|
||||
@@ -47,7 +46,6 @@ Before enabling Azure AD within Rancher, you must register Rancher with Azure.
|
||||
|
||||
|
||||
1. Enter a **Name** (something like `Rancher`).
|
||||
<a id="3.2"></a>
|
||||
|
||||
1. From **Supported account types**, select "Accounts in this organizational directory only (AzureADTest only - Single tenant)" This corresponds to the legacy app registration options.
|
||||
|
||||
@@ -264,7 +262,7 @@ Admins should create a [Rancher backup](../../../new-user-guides/backup-restore-
|
||||
|
||||
#### Air-Gapped Environments
|
||||
|
||||
In air-gapped environments, admins should ensure that their endpoints are [whitelisted](#3.2) since the Graph Endpoint URL is changing.
|
||||
In air-gapped environments, admins should ensure that their endpoints are whitelisted (see note on [Step 3.2 of Register Rancher with Azure](#1-register-rancher-with-azure)) since the Graph Endpoint URL is changing.
|
||||
|
||||
#### Rolling Back the Migration
|
||||
|
||||
|
||||
+2
-7
@@ -41,18 +41,13 @@ After you complete [Configuring Microsoft AD FS for Rancher](configure-ms-adfs-f
|
||||
| UID Field | An AD attribute that is unique to every user. <br/><br/>Example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn` |
|
||||
| Groups Field | Make entries for managing group memberships. <br/><br/>Example: `http://schemas.xmlsoap.org/claims/Group` |
|
||||
| Rancher API Host | The URL for your Rancher Server. |
|
||||
| Private Key / Certificate | This is a key-certificate pair to create a secure shell between Rancher and your AD FS. Ensure you set the Common Name (CN) to your Rancher Server URL.<br/><br/>[Certificate creation command](#cert-command) |
|
||||
| Private Key / Certificate | This is a key-certificate pair to create a secure shell between Rancher and your AD FS. Ensure you set the Common Name (CN) to your Rancher Server URL.<br/><br/>[Certificate creation command](#example-certificate-creation-command) |
|
||||
| Metadata XML | The `federationmetadata.xml` file exported from your AD FS server. <br/><br/>You can find this file at `https://<AD_SERVER>/federationmetadata/2007-06/federationmetadata.xml`. |
|
||||
|
||||
|
||||
<a id="cert-command"></a>
|
||||
|
||||
:::tip
|
||||
### Example Certificate Creation Command
|
||||
|
||||
You can generate a certificate using an openssl command. For example:
|
||||
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
:::
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Pod Security Policies
|
||||
title: Creating Pod Security Policies
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Role-Based Access Control (RBAC)
|
||||
title: Managing Role-Based Access Control (RBAC)
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+4
-4
@@ -19,12 +19,12 @@ Ensure that you migrate all PSPs to another workload security mechanism. This in
|
||||
You must add your new policy enforcement mechanisms _before_ you remove the PodSecurityPolicy objects. If you don't, you may create an opportunity for privilege escalation attacks within the cluster.
|
||||
:::
|
||||
|
||||
### Removing PodSecurityPolicies from Rancher-Maintained Apps & Marketplace Workloads {#remove-psp-rancher-workloads}
|
||||
### Removing PodSecurityPolicies from Rancher-Maintained Apps & Marketplace Workloads
|
||||
|
||||
Rancher v2.7.2 offers a new major version of Rancher-maintained Helm charts. v102.x.y allows you to remove PSPs that were installed with previous versions of the chart. This new version replaces non-standard PSPs switches with the standardized `global.cattle.psp.enabled` switch, which is turned off by default.
|
||||
|
||||
You must perform the following steps _while still in Kubernetes v1.24_:
|
||||
1. Configure the PSA controller to suit your needs. You can use one of Rancher's built-in [PSA Configuration Templates](#psa-config-templates), or create a custom template and apply it to the clusters that you are migrating.
|
||||
1. Configure the PSA controller to suit your needs. You can use one of Rancher's built-in [PSA Configuration Templates](#pod-security-admission-configuration-templates), or create a custom template and apply it to the clusters that you are migrating.
|
||||
|
||||
1. Map your active PSPs to Pod Security Standards:
|
||||
1. See which PSPs are still active in your cluster:
|
||||
@@ -112,14 +112,14 @@ After you install the `helm-mapkubeapis` plugin, clean up the releases that beca
|
||||
|
||||
#### Upgrading Charts to a Version That Supports Kubernetes v1.25
|
||||
|
||||
You can proceed with your upgrade once any releases that had lingering PSPs are cleaned up. For Rancher-maintained workloads, follow the steps outlined in the [Removing PodSecurityPolicies from Rancher-maintained Apps & Marketplace workloads](#remove-psp-rancher-workloads) section of this document.
|
||||
You can proceed with your upgrade once any releases that had lingering PSPs are cleaned up. For Rancher-maintained workloads, follow the steps outlined in the [Removing PodSecurityPolicies from Rancher-maintained Apps & Marketplace workloads](#removing-podsecuritypolicies-from-rancher-maintained-apps--marketplace-workloads) section of this document.
|
||||
For workloads not maintained by Rancher, refer to the vendor documentation.
|
||||
|
||||
:::caution
|
||||
Do not skip this step. Applications incompatible with Kubernetes v1.25 aren't guaranteed to work after a cleanup.
|
||||
:::
|
||||
|
||||
## Pod Security Admission Configuration Templates {#psa-config-templates}
|
||||
## Pod Security Admission Configuration Templates
|
||||
|
||||
Rancher offers PSA configuration templates. These are pre-defined security configurations that you can apply to a cluster. Rancher admins (or those with the right permissions) can [create, manage, and edit](./psa-config-templates.md) PSA templates.
|
||||
|
||||
|
||||
+3
-6
@@ -11,7 +11,7 @@ If you are migrating Rancher to a new Kubernetes cluster, you don't need to inst
|
||||
|
||||
### Prerequisites
|
||||
|
||||
These instructions assume that you have [created a backup](back-up-rancher.md) and already installed a new Kubernetes cluster where Rancher will be deployed. The backup is specific to the Rancher application and can only migrate the Rancher application.
|
||||
These instructions assume that you have [created a backup](back-up-rancher.md) and already installed a new Kubernetes cluster where Rancher will be deployed. The backup is specific to the Rancher application and can only migrate the Rancher application.
|
||||
|
||||
:::caution
|
||||
|
||||
@@ -21,12 +21,9 @@ It is required to use the same hostname that was set as the server URL in the fi
|
||||
|
||||
Rancher version must be v2.5.0 and up
|
||||
|
||||
Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes clusters such as Amazon EKS clusters. For help installing Kubernetes, refer to the documentation of the Kubernetes distribution. One of Rancher's Kubernetes distributions may also be used:
|
||||
Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes clusters such as Amazon EKS clusters. For help installing Kubernetes, refer to the documentation of the Kubernetes distribution. A Rancher-created Kubernetes distributions such as, but not limited to, [RKE](https://rke.docs.rancher.com/installation) or [K3s](https://docs.k3s.io/installation) may also be used.
|
||||
|
||||
- [RKE Kubernetes installation docs](https://rancher.com/docs/rke/latest/en/installation/)
|
||||
- [K3s Kubernetes installation docs](https://rancher.com/docs/k3s/latest/en/installation/)
|
||||
|
||||
Since Rancher can be installed on any Kubernetes cluster, you can use this backup and restore method to migrate Rancher from one Kubernetes cluster to any other Kubernetes cluster. This method *only* migrates Rancher-related resources and won't affect other applications on the cluster. Refer to the [support matrix](https://www.suse.com/lifecycle/) to identify which Kubernetes cluster types and versions are supported for your Rancher version.
|
||||
Since Rancher can be installed on any Kubernetes cluster, you can use this backup and restore method to migrate Rancher from one Kubernetes cluster to any other Kubernetes cluster. This method *only* migrates Rancher-related resources and won't affect other applications on the cluster. Refer to the [support matrix](https://www.suse.com/lifecycle/) to identify which Kubernetes cluster types and versions are supported for your Rancher version.
|
||||
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
|
||||
+7
-3
@@ -6,12 +6,16 @@ title: Deploying Applications across Clusters
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/deploy-apps-across-clusters"/>
|
||||
</head>
|
||||
|
||||
Rancher uses Fleet to deploy applications across clusters.
|
||||
Rancher offers several ways to deploy applications across clusters, depending on version.
|
||||
|
||||
## Fleet
|
||||
|
||||
Rancher v2.5 and later uses Fleet to deploy applications across clusters.
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. For more information, refer to the [Fleet section](fleet.md).
|
||||
|
||||
### Multi-cluster Apps
|
||||
## Multi-cluster Apps
|
||||
|
||||
In Rancher before v2.5, the multi-cluster apps feature was used to deploy applications across clusters. The multi-cluster apps feature is deprecated, but still available in Rancher v2.5.
|
||||
In Rancher before v2.5, the multi-cluster apps feature was used to deploy applications across clusters. The multi-cluster apps feature is deprecated, but still available as a legacy feature.
|
||||
|
||||
See the [multi-cluster app documentation](multi-cluster-apps.md) for more details.
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Set up Infrastructure for a High Availability K3s Kubernetes Cluster
|
||||
title: Setting up Infrastructure for a High Availability K3s Kubernetes Cluster
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Set up Infrastructure for a High Availability RKE Kubernetes Cluster
|
||||
title: Setting up Infrastructure for a High Availability RKE Kubernetes Cluster
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Set up Infrastructure for a High Availability RKE2 Kubernetes Cluster
|
||||
title: Setting up Infrastructure for a High Availability RKE2 Kubernetes Cluster
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+4
-6
@@ -3,7 +3,7 @@ title: Migrating Amazon In-tree to Out-of-tree
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/migrate-to-out-of-tree-amazon"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-amazon"/>
|
||||
</head>
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. In Kubernetes 1.27 and later, the in-tree cloud providers have been removed.
|
||||
@@ -12,7 +12,7 @@ You can migrate from an in-tree to an out-of-tree AWS cloud provider on Kubernet
|
||||
|
||||
To migrate from the in-tree cloud provider to the out-of-tree AWS cloud provider, you must stop the existing cluster's kube controller manager and install the AWS cloud controller manager. There are many ways to do this. Refer to the official AWS documentation on the [external cloud controller manager](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for details.
|
||||
|
||||
If it's acceptable to have some downtime, you can [switch to an external cloud provider](./amazon.md#using-the-out-of-tree-aws-cloud-provider), which removes in-tree components and then deploy charts to install the AWS cloud controller manager.
|
||||
If it's acceptable to have some downtime, you can [switch to an external cloud provider](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider), which removes in-tree components and then deploy charts to install the AWS cloud controller manager.
|
||||
|
||||
If your setup can't tolerate any control plane downtime, you must enable leader migration. This facilitates a smooth transition from the controllers in the kube controller manager to their counterparts in the cloud controller manager. Refer to the official AWS documentation on [Using leader migration](https://cloud-provider-aws.sigs.k8s.io/getting_started/) for more details.
|
||||
|
||||
@@ -55,9 +55,7 @@ spec:
|
||||
kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
|
||||
```
|
||||
|
||||
3. To install the AWS cloud controller manager with leader migration enabled, follow Steps 1-3 for [deploying the cloud controller manager chart](./amazon.md#using-the-out-of-tree-aws-cloud-provider)
|
||||
From Kubernetes 1.22 onwards, the kube-controller-manager will utilize a default configuration which will satisfy the controller-to-manager migration.
|
||||
Update container args of the `aws-cloud-controller-manager` under `spec.rkeConfig.additionalManifest` to enable leader migration:
|
||||
3. To install the AWS cloud controller manager with leader migration enabled, follow Steps 1-3 for [deploying the cloud controller manager chart](../set-up-cloud-providers/amazon.md#using-the-out-of-tree-aws-cloud-provider). From Kubernetes 1.22 onwards, the kube-controller-manager will utilize a default configuration which will satisfy the controller-to-manager migration. Update container args of the `aws-cloud-controller-manager` under `spec.rkeConfig.additionalManifest` to enable leader migration:
|
||||
|
||||
```shell
|
||||
- '--enable-leader-migration=true'
|
||||
@@ -151,7 +149,7 @@ cloud_provider:
|
||||
kubectl cordon -l "node-role.kubernetes.io/controlplane=true"
|
||||
```
|
||||
|
||||
3. To install the AWS cloud controller manager, you must enable leader migration and follow the same steps as when installing AWS on a new cluster. To enable leader migration, add the following to the container arguments in step 7 while following the [steps to install the chart](./amazon.md#helm-chart-installation-from-ui):
|
||||
3. To install the AWS cloud controller manager, you must enable leader migration and follow the same steps as when installing AWS on a new cluster. To enable leader migration, add the following to the container arguments in step 7 while following the [steps to install the chart](../set-up-cloud-providers/amazon.md#helm-chart-installation-from-ui):
|
||||
|
||||
```yaml
|
||||
- '--enable-leader-migration=true'
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Migrating vSphere In-tree to Out-of-tree
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/migrate-from-in-tree-to-out-of-tree"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-vsphere"/>
|
||||
</head>
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
+1
-1
@@ -11,7 +11,7 @@ weight: 1
|
||||
|
||||
In Kubernetes 1.27 and later, you must use an out-of-tree AWS cloud provider. In-tree cloud providers have been deprecated. The Amazon cloud provider has been removed completely, and won't work after an upgrade to Kubernetes 1.27. The steps listed below are still required to set up an Amazon cloud provider. You can [set up an out-of-tree cloud provider](#using-the-out-of-tree-aws-cloud-provider) after creating an IAM role and configuring the ClusterID.
|
||||
|
||||
You can also [migrate from an in-tree to an out-of-tree AWS cloud provider](./migrate-to-out-of-tree-amazon.md) on Kubernetes 1.26 and earlier. All existing clusters must migrate prior to upgrading to v1.27 in order to stay functional.
|
||||
You can also [migrate from an in-tree to an out-of-tree AWS cloud provider](../migrate-to-an-out-of-tree-cloud-provider/migrate-to-out-of-tree-amazon.md) on Kubernetes 1.26 and earlier. All existing clusters must migrate prior to upgrading to v1.27 in order to stay functional.
|
||||
|
||||
Starting with Kubernetes 1.23, you must deactivate the `CSIMigrationAWS` feature gate to use the in-tree AWS cloud provider. You can do this by setting `feature-gates=CSIMigrationAWS=false` as an additional argument for the cluster's Kubelet, Controller Manager, API Server and Scheduler in the advanced cluster configuration.
|
||||
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: How to Configure an In-tree vSphere Cloud Provider
|
||||
title: Setting Up an In-tree vSphere Cloud Provider
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: How to Configure an Out-of-tree vSphere Cloud Provider
|
||||
title: Setting Up an Out-of-tree vSphere Cloud Provider
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Configuration for Storage Classes in Azure
|
||||
title: Configuring Storage Classes in Azure
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
+2
-2
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Ingress Configuration
|
||||
description: Ingress configuration
|
||||
title: Configuring an Ingress
|
||||
description: Configuring an Ingress
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
Reference in New Issue
Block a user