mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 13:08:11 +00:00
Merge branch 'rancher:main' into windows_clusters
This commit is contained in:
+5
-5
@@ -80,11 +80,11 @@ If you use a certificate signed by a recognized CA, installing your certificate
|
||||
|
||||
1. Enter the following command.
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
rancher/rancher:latest --no-cacerts
|
||||
```
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
-p 80:80 -p 443:443 \
|
||||
rancher/rancher:latest --no-cacerts
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
+6
-6
@@ -36,12 +36,12 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
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 |
|
||||
| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
|
||||
| `0` | | | | |
|
||||
| `1` | ✓ | | | |
|
||||
| `2` | ✓ | ✓ | | |
|
||||
| `3` | ✓ | ✓ | ✓ | ✓ |
|
||||
| `AUDIT_LEVEL` Setting | Metadata | Request Body | Response Body |
|
||||
| --------------------- | -------- | ------------ | ------------- |
|
||||
| `0` | | | |
|
||||
| `1` | ✓ | | |
|
||||
| `2` | ✓ | ✓ | |
|
||||
| `3` | ✓ | ✓ | ✓ |
|
||||
|
||||
## Viewing API Audit Logs
|
||||
|
||||
|
||||
+1
-1
@@ -6,7 +6,7 @@ title: Continuous Delivery
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery"/>
|
||||
</head>
|
||||
|
||||
[Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md) comes preinstalled in Rancher and can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
|
||||
[Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet.md) comes preinstalled in Rancher and can't be fully disabled. However, the Fleet feature for GitOps continuous delivery may be disabled using the `continuous-delivery` feature flag.
|
||||
|
||||
To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.](enable-experimental-features.md)
|
||||
|
||||
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Enabling User Retention
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-user-retention"/>
|
||||
</head>
|
||||
|
||||
In Rancher v2.7.14 and later, you can enable user retention to automatically disable or delete inactive user accounts after a configurable time period.
|
||||
|
||||
The user retention feature is off by default. It is considered experimental at this time.
|
||||
|
||||
## Enabling User Retention with kubectl
|
||||
|
||||
To enable user retention, you must set `user-retention-cron`. You must also set at least one of `disable-inactive-user-after` or `delete-inactive-user-after`. You can use `kubectl edit setting <name-of-setting>` to open your editor of choice and set these values.
|
||||
|
||||
## Configuring Rancher to Delete Users, Disable Users, or Combine Operations
|
||||
|
||||
Rancher uses two global user retention settings to determine if and when users are disabled or deleted after a certain period of inactivity. Disabled accounts must be re-enabled before users can log in again. If an account is deleted without being disabled, users may be able to log in through external authentication and the deleted account will be recreated.
|
||||
|
||||
The global settings, `disable-inactive-user-after` and `delete-inactive-user-after`, do not block one another from running.
|
||||
|
||||
For example, you can set both operations to run. If you give `disable-inactive-user-after` a shorter duration than `delete-inactive-user-after`, the user retention process disables inactive accounts before deleting them.
|
||||
|
||||
You can also edit some user retention settings on a specific user's `UserAttribute`. Setting these values overrides the global settings. See [User-specific User Retention Overrides](#user-specific-user-retention-overrides) for more details.
|
||||
|
||||
### Required User Retention Settings
|
||||
|
||||
The following are global settings:
|
||||
|
||||
- `user-retention-cron`: Describes how often the user retention process runs. The value is a cron expression (for example, `0 * * * *` for every hour).
|
||||
- `disable-inactive-user-after`: The amount of time that a user account can be inactive before the process disables an account. Disabling an account forces the user to request that an administrator re-enable the account before they can log in to use it. Values are expressed in [time.Duration units](https://pkg.go.dev/time#ParseDuration) (for example, `720h` for 720 hours or 30 days). The value must be greater than `auth-user-session-ttl-minutes`, which is `16h` by default. If the value is not set, set to the empty string, or is equal to 0, the process does not disable any inactive accounts.
|
||||
- `delete-inactive-user-after`: The amount of time that a user account can be inactive before the process deletes the account. Values are expressed in time.Duration units (for example, `720h` for 720 hours or 30 days). The value must be greater than `auth-user-session-ttl-minutes`, which is `16h` by default. The value should be greater than `336h` (14 days), otherwise it is rejected by the Rancher webhook. If you need the value to be lower than 14 days, you can [bypass the webhook](../../reference-guides/rancher-webhook.md#bypassing-the-webhook). If the value is not set, set to the empty string, or is equal to 0, the process does not delete any inactive accounts.
|
||||
|
||||
### Optional User Retention Settings
|
||||
|
||||
The following are global settings:
|
||||
|
||||
- `user-retention-dry-run`: If set to `true`, the user retention process runs without actually deleting or disabling any user accounts. This can help test user retention behavior before allowing the process to disable or delete user accounts in a production environment.
|
||||
- `user-last-login-default`: If a user does not have `UserAttribute.LastLogin` set on their account, this setting is used instead. It provides a predetermined last login time for the account. The value is expressed as an [RFC 3339 date-time](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) truncated to the last second; for example, `2023-03-01T00:00:00Z`. If the value is set to the empty string or is equal to 0, this setting is not used.
|
||||
|
||||
#### User-specific User Retention Overrides
|
||||
|
||||
The following are user-specific overrides to the global settings for special cases. These settings are applied by editing the `UserAttribute` associated with a given account:
|
||||
|
||||
```
|
||||
kubectl edit userattribute <user-name>
|
||||
```
|
||||
|
||||
- `disableAfter`: The user-specific override for `disable-inactive-user-after`. The value is expressed in [time.Duration units](https://pkg.go.dev/time#ParseDuration) and truncated to the second. If the value is set to `0s` then the account won't be subject to disabling.
|
||||
- `deleteAfter`: The user-specific override for `delete-inactive-user-after`. The value is expressed in [time.Duration units](https://pkg.go.dev/time#ParseDuration) and truncated to the second. If the value is set to `0s` then the account won't be subject to deletion.
|
||||
|
||||
## Viewing User Retention Settings in the Rancher UI
|
||||
|
||||
You can see which user retention settings are applied to which users.
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation menu, select **Users**.
|
||||
|
||||
The **Disable After** and **Delete After** columns for each user account indicate how long the account can be inactive before it is disabled or deleted from Rancher. There is also a **Last Login** column roughly indicating when the account was last active.
|
||||
|
||||
The same information is available if you click a user's name in the **Users** table and select the **Detail** tab.
|
||||
+9
-7
@@ -6,19 +6,21 @@ title: Generate and View Traffic from Istio
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/istio-setup-guide/generate-and-view-traffic"/>
|
||||
</head>
|
||||
|
||||
This section describes how to view the traffic that is being managed by Istio.
|
||||
|
||||
## The Kiali Traffic Graph
|
||||
|
||||
The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you are able to view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
|
||||
The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you can view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
|
||||
|
||||
:::note Prerequisites:
|
||||
## Prerequisites
|
||||
|
||||
To enable traffic to show up in the graph, ensure you have prometheus installed in the cluster. Rancher-istio installs Kiali configured by default to work with the rancher-monitoring chart. You can use rancher-monitoring or install your own monitoring solution. Optional: you can change configuration on how data scraping occurs by setting the [Selectors & Scrape Configs](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) options.
|
||||
To enable traffic to show up in the graph, ensure that you have Prometheus installed in the cluster. `Rancher-istio` installs Kiali, and configures it by default to work with the `rancher-monitoring` chart. You can use `rancher-monitoring` or install your own monitoring solution.
|
||||
|
||||
:::
|
||||
Additionally, for Istio installations version `103.1.0+up1.19.6` and later, Kiali uses a token value for its authentication strategy. If you are trying to generate or retrieve the token (e.g. for login), note that the name of the Kiali service account in Rancher is `kiali`. For more information, refer to the [Kiali token authentication FAQ](https://kiali.io/docs/faq/authentication/).
|
||||
|
||||
To see the traffic graph,
|
||||
Optional: You can configure which namespaces data scraping occurs in by setting the Helm chart options described in [Selectors & Scrape Configs](../../../integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md).
|
||||
|
||||
## Traffic Visualization
|
||||
|
||||
To see the traffic graph follow the steps below:
|
||||
|
||||
1. In the cluster where Istio is installed, click **Istio** in the left navigation bar.
|
||||
1. Click the **Kiali** link.
|
||||
|
||||
+77
@@ -77,3 +77,80 @@ key.pfx=`base64-content`
|
||||
```
|
||||
|
||||
Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
|
||||
|
||||
## Rancher Performance Dashboard
|
||||
|
||||
When monitoring is installed on the upstream (local) cluster, you are given basic health metrics about the Rancher pods, such as CPU and memory data. To get advanced metrics for your local Rancher server, you must additionally enable the Rancher Performance Dashboard for Grafana.
|
||||
|
||||
This dashboard provides access to the following advanced metrics:
|
||||
|
||||
- Handler Average Execution Times Over Last 5 Minutes
|
||||
- Rancher API Average Request Times Over Last 5 Minutes
|
||||
- Subscribe Average Request Times Over Last 5 Minutes
|
||||
- Lasso Controller Work Queue Depth (Top 20)
|
||||
- Number of Rancher Requests (Top 20)
|
||||
- Number of Failed Rancher API Requests (Top 20)
|
||||
- K8s Proxy Store Average Request Times Over Last 5 Minutes (Top 20)
|
||||
- K8s Proxy Client Average Request Times Over Last 5 Minutes (Top 20)
|
||||
- Cached Objects by GroupVersionKind (Top 20)
|
||||
- Lasso Handler Executions (Top 20)
|
||||
- Handler Executions Over Last 2 Minutes (Top 20)
|
||||
- Total Handler Executions with Error (Top 20)
|
||||
- Data Transmitted by Remote Dialer Sessions (Top 20)
|
||||
- Errors for Remote Dialer Sessions (Top 20)
|
||||
- Remote Dialer Connections Removed (Top 20)
|
||||
- Remote Dialer Connections Added by Client (Top 20)
|
||||
|
||||
:::note
|
||||
|
||||
Profiling data (such as advanced memory or CPU analysis) is not present as it is a very context-dependent technique that's meant for debugging and not intended for normal observation.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
### Enabling the Rancher Performance Dashboard
|
||||
|
||||
To enable the Rancher Performance Dashboard:
|
||||
|
||||
<Tabs groupId="UIorCLI">
|
||||
<TabItem value="Helm">
|
||||
|
||||
Use the following options with the Helm CLI:
|
||||
|
||||
```bash
|
||||
--set extraEnv\[0\].name="CATTLE_PROMETHEUS_METRICS" --set-string extraEnv\[0\].value=true
|
||||
```
|
||||
|
||||
You can also include the following snippet in your Rancher Helm chart's values.yaml file:
|
||||
|
||||
```yaml
|
||||
extraEnv:
|
||||
- name: "CATTLE_PROMETHEUS_METRICS"
|
||||
value: "true"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="UI">
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the row of the `local` cluster and click **Explore**.
|
||||
1. Click **Workloads > Deployments**.
|
||||
1. Use the dropdown menu at the top to filter for **All Namespaces**.
|
||||
1. Under the `cattle-system` namespace, go to the `rancher` row and click **⋮ > Edit Config**
|
||||
1. Under **Environment Variables**, click **Add Variable**.
|
||||
1. For **Type**, select `Key/Value Pair`.
|
||||
1. For **Variable Name**, enter `CATTLE_PROMETHEUS_METRICS`.
|
||||
1. For **Value**, enter `true`.
|
||||
1. Click **Save** to apply the change.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Accessing the Rancher Performance Dashboard
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the row of the `local` cluster and click **Explore**.
|
||||
1. Click **Monitoring**
|
||||
1. Select the **Grafana** dashboard.
|
||||
1. From the sidebar, click **Search dashboards**.
|
||||
1. Enter `Rancher Performance Debugging` and select it.
|
||||
|
||||
+11
-1
@@ -6,7 +6,17 @@ title: Opening Ports with firewalld
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/open-ports-with-firewalld"/>
|
||||
</head>
|
||||
|
||||
> We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
|
||||
:::danger
|
||||
|
||||
Enabling firewalld can cause serious network communication problems.
|
||||
|
||||
For proper network function, firewalld must be disabled on systems running RKE2. [Firewalld conflicts with Canal](https://docs.rke2.io/known_issues#firewalld-conflicts-with-default-networking), RKE2's default networking stack.
|
||||
|
||||
Firewalld must also be disabled on systems running Kubernetes 1.19 and later.
|
||||
|
||||
If you enable firewalld on systems running Kubernetes 1.18 or earlier, understand that this may cause networking issues. CNIs in Kubernetes dynamically update iptables and networking rules independently of any external firewalls, such as firewalld. This can cause unexpected behavior when the CNI and the external firewall conflict.
|
||||
|
||||
:::
|
||||
|
||||
Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
|
||||
|
||||
|
||||
+4
-4
@@ -8,9 +8,9 @@ title: Tuning etcd for Large Installations
|
||||
|
||||
When Rancher is used to manage [a large infrastructure](../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) it is recommended to increase the default keyspace for etcd from the default 2 GB. The maximum setting is 8 GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
|
||||
|
||||
The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota) setting on the etcd servers.
|
||||
The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.5/op-guide/maintenance/#space-quota) setting on the etcd servers.
|
||||
|
||||
### Example: This snippet of the RKE cluster.yml file increases the keyspace size to 5GB
|
||||
## Example: This Snippet of the RKE Cluster.yml file Increases the Keyspace Size to 5GB
|
||||
|
||||
```yaml
|
||||
# RKE cluster.yml
|
||||
@@ -21,9 +21,9 @@ services:
|
||||
quota-backend-bytes: 5368709120
|
||||
```
|
||||
|
||||
## Scaling etcd disk performance
|
||||
## Scaling etcd Disk Performance
|
||||
|
||||
You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.4.0/tuning/#disk) on how to tune the disk priority on the host.
|
||||
You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.5/tuning/#disk) on how to tune the disk priority on the host.
|
||||
|
||||
Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use striping RAID configurations to increase available IOPS.
|
||||
|
||||
|
||||
@@ -16,11 +16,11 @@ Want to provide a user with access to _all_ projects within a cluster? See [Addi
|
||||
|
||||
:::
|
||||
|
||||
### Adding Members to a New Project
|
||||
## Adding Members to a New Project
|
||||
|
||||
You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md)
|
||||
|
||||
### Adding Members to an Existing Project
|
||||
## Adding Members to an Existing Project
|
||||
|
||||
Following project creation, you can add users as project members so that they can access its resources.
|
||||
|
||||
|
||||
+3
-1
@@ -56,4 +56,6 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo
|
||||
|
||||
### Developing Your Own Node Drivers
|
||||
|
||||
Node drivers are implemented with [Docker Machine](https://docs.docker.com/machine/).
|
||||
Node drivers are implemented with [Rancher Machine](https://github.com/rancher/machine), a fork of [Docker Machine](https://github.com/docker/machine). Docker Machine is no longer under active development.
|
||||
|
||||
Refer to the original [Docker Machine documentation](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) for details on how to develop your own node drivers.
|
||||
|
||||
+1
-1
@@ -60,4 +60,4 @@ To convert an existing cluster to use an RKE template,
|
||||
|
||||
- A new RKE template is created.
|
||||
- The cluster is converted to use the new template.
|
||||
- New clusters can be [created from the new template.](apply-templates.md#creating-a-cluster-from-an-rke-template)
|
||||
- New clusters can be [created from the new template.](#creating-a-cluster-from-an-rke-template)
|
||||
+6
@@ -62,6 +62,12 @@ After you configure Rancher to allow sign on using an external authentication se
|
||||
| Allow members of Clusters, Projects, plus Authorized Users and Organizations | Any user in the authorization service and any group added as a **Cluster Member** or **Project Member** can log in to Rancher. Additionally, any user in the authentication service or group you add to the **Authorized Users and Organizations** list may log in to Rancher. |
|
||||
| Restrict access to only Authorized Users and Organizations | Only users in the authentication service or groups added to the Authorized Users and Organizations can log in to Rancher. |
|
||||
|
||||
:::warning
|
||||
|
||||
Only trusted admin-level users should have access to the local cluster, which manages all of the other clusters in a Rancher instance. Rancher is directly installed on the local cluster, and Rancher's management features allow admins on the local cluster to provision, modify, connect to, and view details about downstream clusters. Since the local cluster is key to a Rancher instance's architecture, inappropriate access carries security risks.
|
||||
|
||||
:::
|
||||
|
||||
To set the Rancher access level for users in the authorization service, follow these steps:
|
||||
|
||||
1. In the upper left corner, click **☰ > Users & Authentication**.
|
||||
|
||||
-1
@@ -51,7 +51,6 @@ You can integrate Okta with Rancher, so that authenticated users can access Ranc
|
||||
|
||||
:::
|
||||
|
||||
|
||||
1. After you complete the **Configure Okta Account** form, click **Enable**.
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.
|
||||
|
||||
+8
@@ -30,6 +30,14 @@ Within Rancher, each person authenticates as a _user_, which is a login that gra
|
||||
|
||||
For more information how authorization works and how to customize roles, see [Roles Based Access Control (RBAC)](manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md).
|
||||
|
||||
## User Retention
|
||||
|
||||
In Rancher v2.7.14 and later, you can enable user retention. This feature automatically removes inactive users after a configurable period of time.
|
||||
|
||||
The user retention feature is disabled by default.
|
||||
|
||||
For more information, see [Enabling User Retention](../../advanced-user-guides/enable-user-retention.md).
|
||||
|
||||
## Pod Security Policies
|
||||
|
||||
_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification, e.g. root privileges. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message.
|
||||
|
||||
+1
-1
@@ -23,7 +23,7 @@ This option replaces "Rancher" with the value you provide in most places. Files
|
||||
|
||||
### Support Links
|
||||
|
||||
Use a url address to send new "File an Issue" reports instead of sending users to the Github issues page. Optionally show Rancher community support links.
|
||||
Use a url address to send new "File an Issue" reports instead of sending users to the GitHub issues page. Optionally show Rancher community support links.
|
||||
|
||||
### Logo
|
||||
|
||||
|
||||
+1
-1
@@ -40,7 +40,7 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio,
|
||||
|
||||
:::note
|
||||
|
||||
There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../../../integrations-in-rancher/fleet/overview.md#troubleshooting) for a workaround.
|
||||
There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here](../../../integrations-in-rancher/fleet-gitops-at-scale/fleet-gitops-at-scale.md#troubleshooting) for a workaround.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
-15
@@ -62,21 +62,6 @@ Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-o
|
||||
|
||||
### 2. Restore from backup using a Restore custom resource
|
||||
|
||||
:::note Important:
|
||||
|
||||
Kubernetes v1.22, available as an experimental feature of v2.6.3, does not support restoring from backup files containing CRDs with the apiVersion `apiextensions.k8s.io/v1beta1`. In v1.22, the default `resourceSet` in the rancher-backup app is updated to collect only CRDs that use `apiextensions.k8s.io/v1`. There are currently two ways to work around this issue:
|
||||
|
||||
1. Update the default `resourceSet` to collect the CRDs with the apiVersion v1.
|
||||
1. Update the default `resourceSet` and the client to use the new APIs internally, with `apiextensions.k8s.io/v1` as the replacement.
|
||||
|
||||
:::note
|
||||
|
||||
When making or restoring backups for v1.22, the Rancher version and the local cluster's Kubernetes version should be the same. The Kubernetes version should be considered when restoring a backup since the supported apiVersion in the cluster and in the backup file could be different.
|
||||
|
||||
:::
|
||||
|
||||
:::
|
||||
|
||||
1. When using S3 object storage as the backup source for a restore that requires credentials, create a `Secret` object in this cluster to add the S3 credentials. The secret data must have two keys - `accessKey`, and `secretKey`, that contain the S3 credentials.
|
||||
|
||||
The secret can be created in any namespace, this example uses the default namespace.
|
||||
|
||||
+16
-3
@@ -79,15 +79,20 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
|
||||
1. In the **Clusters** page, go to the cluster where you want to remove nodes.
|
||||
1. In the **Machines** tab, click **⋮ > Delete** on each node you want to delete. Initially, you will see the nodes hang in a `deleting` state, but once all etcd nodes are deleting, they will be removed together. This is due to the fact that Rancher sees all etcd nodes deleting and proceeds to "short circuit" the etcd safe-removal logic.
|
||||
|
||||
1. After all etcd nodes are removed, add a new etcd node that you are planning to restore from.
|
||||
1. After all etcd nodes are removed, add the new etcd node that you are planning to restore from. Assign the new node the role of `all` (etcd, controlplane, and worker).
|
||||
|
||||
- For custom clusters, go to the **Registration** tab then copy and run the registration command on your node. If the node has previously been used in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
|
||||
- If the node was previously in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
|
||||
- For custom clusters, go to the **Registration** tab and check the box for `etcd, controlplane, and worker`. Then copy and run the registration command on your node.
|
||||
- For node driver clusters, a new node is provisioned automatically.
|
||||
|
||||
At this point, Rancher will indicate that restoration from etcd snapshot is required.
|
||||
|
||||
1. Restore from an etcd snapshot.
|
||||
|
||||
:::note
|
||||
As the etcd node is a clean node, you may need to manually create the `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` path.
|
||||
:::
|
||||
|
||||
- For S3 snapshots, restore using the UI.
|
||||
1. Click the **Snapshots** tab to view the list of saved snapshots.
|
||||
1. Go to the snapshot you want to restore and click **⋮ > Restore**.
|
||||
@@ -95,7 +100,15 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
|
||||
1. Click **Restore**.
|
||||
- For local snapshots, restore using the UI is **not** available.
|
||||
1. In the upper right corner, click **⋮ > Edit YAML**.
|
||||
1. Define `spec.cluster.rkeConfig.etcdSnapshotRestore.name` as the filename of the snapshot on disk in `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`.
|
||||
1. The example YAML below can be added under your `rkeConfig` to configure the etcd restore:
|
||||
|
||||
```yaml
|
||||
...
|
||||
rkeConfig:
|
||||
etcdSnapshotRestore:
|
||||
name: <string> # This field is required. Refers to the filename of the associated etcdsnapshot object.
|
||||
...
|
||||
```
|
||||
|
||||
1. After restoration is successful, you can scale your etcd nodes back up to the desired redundancy.
|
||||
|
||||
|
||||
+17
@@ -167,6 +167,23 @@ spec:
|
||||
|
||||
Only Helm 3 compatible charts are supported.
|
||||
|
||||
### Refresh Chart Repositories
|
||||
|
||||
The **Refresh** button can be used to sync changes from selected Helm chart repositories on the **Repositories** page.
|
||||
|
||||
To refresh a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Use the toggle next to the **State** field to select all repositories, or toggle specified chart repositories to sync changes.
|
||||
1. Click **Refresh**.
|
||||
1. The **⋮** at the end of each chart repository row also includes a **Refresh** option, which can be clicked to refresh the respective repository.
|
||||
|
||||
Non-Airgap Rancher installations upon refresh will reflect any chart repository changes immediately and you will see the **State** field for updated repositories move from `In Progress` to `Active` once the action is completed.
|
||||
|
||||
Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
To install and deploy a chart:
|
||||
|
||||
+2
-2
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
- **A load balancer** to direct traffic to the two nodes.
|
||||
- **A load balancer** to direct traffic to the nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
@@ -59,4 +59,4 @@ Depending on your environment, this may be an A record pointing to the load bala
|
||||
|
||||
You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
+1
-1
@@ -49,5 +49,5 @@ number of nodes for each Kubernetes role, refer to the section on [recommended a
|
||||
|
||||
### Networking
|
||||
|
||||
* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://coreos.com/etcd/docs/latest/tuning.html) allow etcd to run in most networks (except really high latency networks).
|
||||
* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://etcd.io/docs/v3.5/tuning/) allow etcd to run in most networks (except really high latency networks).
|
||||
* Cluster nodes should be located within a single region. Most cloud providers provide multiple availability zones within a region, which can be used to create higher availability for your cluster. Using multiple availability zones is fine for nodes with any role. If you are using [Kubernetes Cloud Provider](../set-up-cloud-providers/set-up-cloud-providers.md) resources, consult the documentation for any restrictions (i.e. zone storage restrictions).
|
||||
|
||||
+1
-1
@@ -57,7 +57,7 @@ The number of nodes that you can lose at once while maintaining cluster availabi
|
||||
|
||||
References:
|
||||
|
||||
* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
|
||||
* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance)
|
||||
* [Official Kubernetes documentation on operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
|
||||
|
||||
### Number of Worker Nodes
|
||||
|
||||
+1
-1
@@ -108,7 +108,7 @@ Regarding CPU and memory, it is recommended that the different planes of Kuberne
|
||||
|
||||
For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/)
|
||||
|
||||
For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/)
|
||||
For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.5/op-guide/hardware/)
|
||||
|
||||
## Networking Requirements
|
||||
|
||||
|
||||
+1
-3
@@ -184,9 +184,7 @@ To prevent issues when upgrading, the [Kubernetes upgrade best practices](https:
|
||||
|
||||
## Authorized Cluster Endpoint Support for RKE2 and K3s Clusters
|
||||
|
||||
_Available as of v2.6.3_
|
||||
|
||||
Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here](../manage-clusters/access-clusters/authorized-cluster-endpoint.md).
|
||||
Rancher supports Authorized Cluster Endpoints (ACE) for registered RKE2 and K3s clusters. This support includes manual steps you will perform on the downstream cluster to enable the ACE. For additional information on the authorized cluster endpoint, click [here](../manage-clusters/access-clusters/authorized-cluster-endpoint.md).
|
||||
|
||||
:::note Notes:
|
||||
|
||||
|
||||
+2
-2
@@ -332,7 +332,7 @@ Refer to the offical AWS upstream documentation for the [cloud controller manage
|
||||
<Tabs>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on Github.
|
||||
Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on GitHub.
|
||||
|
||||
1. Add the Helm repository:
|
||||
|
||||
@@ -465,7 +465,7 @@ kubectl rollout status daemonset -n kube-system aws-cloud-controller-manager
|
||||
|
||||
<TabItem value="RKE">
|
||||
|
||||
Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on Github.
|
||||
Official upstream docs for [Helm chart installation](https://github.com/kubernetes/cloud-provider-aws/tree/master/charts/aws-cloud-controller-manager) can be found on GitHub.
|
||||
|
||||
1. Add the Helm repository:
|
||||
|
||||
|
||||
+19
-35
@@ -21,65 +21,48 @@ To interact with Azure APIs, an AKS cluster requires an Azure Active Directory (
|
||||
Before creating the service principal, you need to obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com):
|
||||
|
||||
- Subscription ID
|
||||
- Client ID
|
||||
- Client ID (also known as app ID)
|
||||
- Client secret
|
||||
|
||||
The below sections describe how to set up these prerequisites using either the Azure command line tool or the Azure portal.
|
||||
|
||||
### Setting Up the Service Principal with the Azure Command Line Tool
|
||||
|
||||
You can create the service principal by running this command:
|
||||
You must assign roles to the service principal so that it has communication privileges with the AKS API. It also needs access to create and list virtual networks.
|
||||
|
||||
In the following example, the command creates the service principal and gives it the Contributor role. The Contributor role can manage anything on AKS but cannot give access to others. Note that you must provide `scopes` a full path to at least one Azure resource:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac --skip-assignment
|
||||
az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>
|
||||
```
|
||||
|
||||
The result should show information about the new service principal:
|
||||
```
|
||||
{
|
||||
"appId": "xxxx--xxx",
|
||||
"displayName": "<SERVICE-PRINCIPAL-NAME>",
|
||||
"name": "http://<SERVICE-PRINCIPAL-NAME>",
|
||||
"password": "<SECRET>",
|
||||
"tenant": "<TENANT NAME>"
|
||||
"displayName": "<service-principal-name>",
|
||||
"name": "http://<service-principal-name>",
|
||||
"password": "<secret>",
|
||||
"tenant": "<tenant-name>"
|
||||
}
|
||||
```
|
||||
|
||||
You also need to add roles to the service principal so that it has privileges for communication with the AKS API. It also needs access to create and list virtual networks.
|
||||
|
||||
Below is an example command for assigning the Contributor role to a service principal. Contributors can manage anything on AKS but cannot give access to others:
|
||||
The following creates a [Resource Group](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-cli) to contain your Azure resources:
|
||||
|
||||
```
|
||||
az role assignment create \
|
||||
--assignee $appId \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
You can also create the service principal and give it Contributor privileges by combining the two commands into one. In this command, the scope needs to provide a full path to an Azure resource:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
Create the Resource Group by running this command:
|
||||
|
||||
```
|
||||
az group create --location AZURE_LOCATION_NAME --resource-group AZURE_RESOURCE_GROUP_NAME
|
||||
az group create --location <azure-location-name> --resource-group <resource-group-name>
|
||||
```
|
||||
|
||||
### Setting Up the Service Principal from the Azure Portal
|
||||
|
||||
You can also follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
|
||||
Follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
|
||||
|
||||
1. Go to the Microsoft Azure Portal [home page](https://portal.azure.com).
|
||||
|
||||
1. Click **Azure Active Directory**.
|
||||
1. Click **App registrations**.
|
||||
1. Click **New registration**.
|
||||
1. Enter a name. This will be the name of your service principal.
|
||||
1. Enter a name for your service principal.
|
||||
1. Optional: Choose which accounts can use the service principal.
|
||||
1. Click **Register**.
|
||||
1. You should now see the name of your service principal under **Azure Active Directory > App registrations**.
|
||||
@@ -101,7 +84,7 @@ To give role-based access to your service principal,
|
||||
|
||||
**Result:** Your service principal now has access to AKS.
|
||||
|
||||
## 1. Create the AKS Cloud Credentials
|
||||
## Create the AKS Cloud Credentials
|
||||
|
||||
1. In the Rancher UI, click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
@@ -110,7 +93,7 @@ To give role-based access to your service principal,
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md#cloud-credentials)
|
||||
1. Click **Create**.
|
||||
|
||||
## 2. Create the AKS Cluster
|
||||
## Create the AKS Cluster
|
||||
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
@@ -124,7 +107,8 @@ Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
## Role-based Access Control
|
||||
## Configure Role-based Access Control
|
||||
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.
|
||||
|
||||
RBAC is required for AKS clusters that are registered or imported into Rancher.
|
||||
@@ -135,8 +119,8 @@ Assign the Rancher AKSv2 role to the service principal with the Azure Command Li
|
||||
|
||||
```
|
||||
az role assignment create \
|
||||
--assignee CLIENT_ID \
|
||||
--scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME" \
|
||||
--assignee <client-id> \
|
||||
--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>" \
|
||||
--role "Rancher AKSv2"
|
||||
```
|
||||
|
||||
|
||||
+2
-2
@@ -46,7 +46,7 @@ If you need to create a private registry, refer to the documentation pages for y
|
||||
:::
|
||||
|
||||
1. Select a namespace for the registry.
|
||||
1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password.
|
||||
1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use Docker Hub, provide your Docker Hub username and password.
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:**
|
||||
@@ -89,7 +89,7 @@ Before v2.6, secrets were required to be in a project scope. Projects are no lon
|
||||
:::
|
||||
|
||||
1. Select a namespace for the registry.
|
||||
1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password.
|
||||
1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use Docker Hub, provide your Docker Hub username and password.
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:**
|
||||
|
||||
+2
-8
@@ -15,9 +15,9 @@ Rancher can provision nodes in vSphere and install Kubernetes on them. When crea
|
||||
|
||||
A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.
|
||||
|
||||
## VMware vSphere Enhancements in Rancher v2.3
|
||||
## VMware vSphere Enhancements
|
||||
|
||||
The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements:
|
||||
The vSphere node templates allow you to bring cloud operations on-premises with the following enhancements:
|
||||
|
||||
### Self-healing Node Pools
|
||||
|
||||
@@ -39,12 +39,6 @@ For the fields to be populated, your setup needs to fulfill the [prerequisites.]
|
||||
|
||||
You can provision VMs with any operating system that supports `cloud-init`. Only YAML format is supported for the [cloud config.](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)
|
||||
|
||||
### Video Walkthrough of v2.3.3 Node Template Features
|
||||
|
||||
In this YouTube video, we demonstrate how to set up a node template with the new features designed to help you bring cloud operations to on-premises clusters.
|
||||
|
||||
<YouTube id="dPIwg6x1AlU"/>
|
||||
|
||||
## Creating a VMware vSphere Cluster
|
||||
|
||||
In [this section,](provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere.
|
||||
|
||||
+1
-1
@@ -23,7 +23,7 @@ You will need a separate kubeconfig file for each cluster that you have access t
|
||||
|
||||
After you download the kubeconfig file, you will be able to use the kubeconfig file and its Kubernetes [contexts](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration) to access your downstream cluster.
|
||||
|
||||
If admins have [kubeconfig token generation turned off](../../../../reference-guides/about-the-api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires [rancher cli](./authorized-cluster-endpoint.md) to be present in your PATH.
|
||||
If admins have [kubeconfig token generation turned off](../../../../reference-guides/about-the-api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires [rancher cli](../../../../reference-guides/cli-with-rancher/rancher-cli.md) to be present in your PATH.
|
||||
|
||||
### Two Authentication Methods for RKE Clusters
|
||||
|
||||
|
||||
+1
-1
@@ -122,7 +122,7 @@ Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
|
||||
|
||||
## Cleaning up Nodes
|
||||
|
||||
<Tabs>
|
||||
<Tabs groupId="k8s-distro" queryString>
|
||||
<TabItem value="RKE1">
|
||||
|
||||
Before you run the following commands, first remove the node through the Rancher UI.
|
||||
|
||||
+5
-5
@@ -19,7 +19,7 @@ To provision new storage for your workloads, follow these steps:
|
||||
1. [Add a storage class and configure it to use your storage.](#1-add-a-storage-class-and-configure-it-to-use-your-storage)
|
||||
2. [Use the Storage Class for Pods Deployed with a StatefulSet.](#2-use-the-storage-class-for-pods-deployed-with-a-statefulset)
|
||||
|
||||
### Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
- To set up persistent storage, the `Manage Volumes` [role](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference) is required.
|
||||
- If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
|
||||
@@ -42,7 +42,7 @@ hostPath | `host-path`
|
||||
|
||||
To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](../../../../advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)
|
||||
|
||||
### 1. Add a storage class and configure it to use your storage
|
||||
## 1. Add a storage class and configure it to use your storage
|
||||
|
||||
These steps describe how to set up a storage class at the cluster level.
|
||||
|
||||
@@ -59,7 +59,7 @@ These steps describe how to set up a storage class at the cluster level.
|
||||
|
||||
For full information about the storage class parameters, refer to the official [Kubernetes documentation.](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).
|
||||
|
||||
### 2. Use the Storage Class for Pods Deployed with a StatefulSet
|
||||
## 2. Use the Storage Class for Pods Deployed with a StatefulSet
|
||||
|
||||
StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the StorageClass that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound to dynamically provisioned storage using the StorageClass defined in its PersistentVolumeClaim.
|
||||
|
||||
@@ -70,7 +70,7 @@ StatefulSets manage the deployment and scaling of Pods while maintaining a stick
|
||||
1. Click **StatefulSet**.
|
||||
1. In the **Volume Claim Templates** tab, click **Add Claim Template**.
|
||||
1. Enter a name for the persistent volume.
|
||||
1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Launch**.
|
||||
|
||||
@@ -84,7 +84,7 @@ To attach the PVC to an existing workload,
|
||||
1. Go to the workload that will use storage provisioned with the StorageClass that you cared at click **⋮ > Edit Config**.
|
||||
1. In the **Volume Claim Templates** section, click **Add Claim Template**.
|
||||
1. Enter a persistent volume name.
|
||||
1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Save**.
|
||||
|
||||
|
||||
+5
-6
@@ -20,12 +20,12 @@ To set up storage, follow these steps:
|
||||
2. [Add a PersistentVolume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
|
||||
3. [Use the Storage Class for Pods Deployed with a StatefulSet.](#3-use-the-storage-class-for-pods-deployed-with-a-statefulset)
|
||||
|
||||
### Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
- To create a persistent volume as a Kubernetes resource, you must have the `Manage Volumes` [role.](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference)
|
||||
- If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
|
||||
|
||||
### 1. Set up persistent storage
|
||||
## 1. Set up persistent storage
|
||||
|
||||
Creating a persistent volume in Rancher will not create a storage volume. It only creates a Kubernetes resource that maps to an existing volume. Therefore, before you can create a persistent volume as a Kubernetes resource, you must have storage provisioned.
|
||||
|
||||
@@ -33,7 +33,7 @@ The steps to set up a persistent storage device will differ based on your infras
|
||||
|
||||
If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [this page.](../../../../../integrations-in-rancher/longhorn.md)
|
||||
|
||||
### 2. Add a PersistentVolume that refers to the persistent storage
|
||||
## 2. Add a PersistentVolume that refers to the persistent storage
|
||||
|
||||
These steps describe how to set up a PersistentVolume at the cluster level in Kubernetes.
|
||||
|
||||
@@ -51,8 +51,7 @@ These steps describe how to set up a PersistentVolume at the cluster level in Ku
|
||||
|
||||
**Result:** Your new persistent volume is created.
|
||||
|
||||
|
||||
### 3. Use the Storage Class for Pods Deployed with a StatefulSet
|
||||
## 3. Use the Storage Class for Pods Deployed with a StatefulSet
|
||||
|
||||
StatefulSets manage the deployment and scaling of Pods while maintaining a sticky identity for each Pod. In this StatefulSet, we will configure a VolumeClaimTemplate. Each Pod managed by the StatefulSet will be deployed with a PersistentVolumeClaim based on this VolumeClaimTemplate. The PersistentVolumeClaim will refer to the PersistentVolume that we created. Therefore, when each Pod managed by the StatefulSet is deployed, it will be bound a PersistentVolume as defined in its PersistentVolumeClaim.
|
||||
|
||||
@@ -86,4 +85,4 @@ The following steps describe how to assign persistent storage to an existing wor
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Launch**.
|
||||
|
||||
**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
|
||||
**Result:** The workload will make a request for the specified amount of disk space to the Kubernetes master. If a PV with the specified resources is available when the workload is deployed, the Kubernetes master will bind the PV to the PVC.
|
||||
|
||||
+1
-1
@@ -304,7 +304,7 @@ cloud-provider|-|Cloud provider type|
|
||||
|max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
|
||||
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
|
||||
|node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
|
||||
|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|
||||
|estimator|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|
||||
|expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
|
||||
|ignore-daemonsets-utilization|false|Should CA ignore DaemonSet pods when calculating resource utilization for scaling down|
|
||||
|ignore-mirror-pods-utilization|false|Should CA ignore Mirror pods when calculating resource utilization for scaling down|
|
||||
|
||||
+2
-2
@@ -173,12 +173,12 @@ To add members:
|
||||
|
||||
### 4. Optional: Add Resource Quotas
|
||||
|
||||
Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](projects-and-namespaces.md).
|
||||
Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md).
|
||||
|
||||
To add a resource quota,
|
||||
|
||||
1. In the **Resource Quotas** tab, click **Add Resource**.
|
||||
1. Select a **Resource Type**. For more information, see [Resource Quotas.](projects-and-namespaces.md).
|
||||
1. Select a **Resource Type**. For more information, see [Resource Quotas.](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md).
|
||||
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
|
||||
1. **Optional:** Specify **Container Default Resource Limit**, which will be applied to every container started in the project. The parameter is recommended if you have CPU or Memory limits set by the Resource Quota. It can be overridden on per an individual namespace or a container level. For more information, see [Container Default Resource Limit](../../advanced-user-guides/manage-projects/manage-project-resource-quotas/manage-project-resource-quotas.md)
|
||||
1. Click **Create**.
|
||||
|
||||
@@ -25,11 +25,11 @@ To manage permissions in a vanilla Kubernetes cluster, cluster admins configure
|
||||
|
||||
:::note
|
||||
|
||||
If you create a namespace with `kubectl`, it may be unusable because `kubectl` doesn't require your new namespace to be scoped within a project that you have access to. If your permissions are restricted to the project level, it is better to [create a namespace through Rancher](manage-namespaces.md) to ensure that you will have permission to access the namespace.
|
||||
If you create a namespace with `kubectl`, it may be unusable because `kubectl` doesn't require your new namespace to be scoped within a project that you have access to. If your permissions are restricted to the project level, it is better to [create a namespace through Rancher](#creating-namespaces) to ensure that you will have permission to access the namespace.
|
||||
|
||||
:::
|
||||
|
||||
### Creating Namespaces
|
||||
## Creating Namespaces
|
||||
|
||||
Create a new namespace to isolate apps and resources in a project.
|
||||
|
||||
@@ -50,7 +50,7 @@ When working with project resources that you can assign to a namespace (i.e., [w
|
||||
|
||||
**Result:** Your namespace is added to the project. You can begin assigning cluster resources to the namespace.
|
||||
|
||||
### Moving Namespaces to Another Project
|
||||
## Moving Namespaces to Another Project
|
||||
|
||||
Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.
|
||||
|
||||
@@ -71,7 +71,7 @@ Cluster admins and members may occasionally need to move a namespace to another
|
||||
|
||||
**Result:** Your namespace is moved to a different project (or is unattached from all projects). If any project resources are attached to the namespace, the namespace releases them and then attached resources from the new project.
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
## Editing Namespace Resource Quotas
|
||||
|
||||
You can always override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user