mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-06 05:03:27 +00:00
Merge branch 'rancher:main' into 2.7.11-webhook-version
This commit is contained in:
@@ -22,7 +22,7 @@ jobs:
|
||||
run: yarn install --frozen-lockfile
|
||||
- name: Build website
|
||||
env:
|
||||
NODE_OPTIONS: "--max_old_space_size=6144"
|
||||
NODE_OPTIONS: "--max_old_space_size=7168"
|
||||
run: yarn build --no-minify
|
||||
|
||||
# Popular action to deploy to GitHub Pages:
|
||||
|
||||
@@ -24,5 +24,5 @@ jobs:
|
||||
run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
|
||||
- name: Test build website
|
||||
env:
|
||||
NODE_OPTIONS: "--max_old_space_size=6144"
|
||||
NODE_OPTIONS: "--max_old_space_size=7168"
|
||||
run: yarn build --no-minify
|
||||
@@ -23,7 +23,7 @@ If a file is moved or renamed, you'll also need to edit the `sidebars.js` files
|
||||
|
||||
### Navigate the Repo
|
||||
|
||||
The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. Most index pages are found within the `/pages-for-subheaders` directory in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
|
||||
The file paths in the repo correspond to the URLs for pages on the docs website. The docs for the latest version of Rancher are located in `/docs`. All images are in `/static/img` in the top level of the repo. Older docs are found within `/versioned_docs` and generally follow the same structure as the files in `/docs`.
|
||||
|
||||
### Style & Formatting
|
||||
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: API Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-reference"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
At this time, not all Rancher resources are available through the Rancher Kubernetes API.
|
||||
|
||||
@@ -111,3 +111,5 @@ Delete the project under the cluster namespace:
|
||||
```bash
|
||||
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.
|
||||
|
||||
@@ -184,8 +184,6 @@ The following table summarizes the different features available for each CNI net
|
||||
|
||||
## CNI Community Popularity
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
|
||||
<CNIPopularityTable />
|
||||
|
||||
## Which CNI Provider Should I Use?
|
||||
|
||||
+3
@@ -28,10 +28,13 @@ The kubeconfig can also be manually targeted for the intended cluster with the `
|
||||
Review the list of known issues for each Rancher version, which can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
|
||||
|
||||
Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
|
||||
|
||||
### Helm Version
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air-gapped installs: Populate private registry
|
||||
|
||||
+2
@@ -10,6 +10,8 @@ Now that you have a running RKE cluster, you can install Rancher in it. For secu
|
||||
|
||||
### Install the Helm CLI
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:
|
||||
|
||||
```
|
||||
|
||||
@@ -10,6 +10,8 @@ This section contains the requirements for Helm, which is the tool used to insta
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
- Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
|
||||
- Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.
|
||||
- Helm v2.15.0 should not be used, because of an issue with converting/comparing numbers.
|
||||
|
||||
@@ -145,6 +145,8 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
|
||||
```
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
The Helm 2 command is as follows:
|
||||
|
||||
```plain
|
||||
|
||||
+190
-77
@@ -12,7 +12,7 @@ Global Permissions define user authorization outside the scope of any particular
|
||||
|
||||
- **Administrator:** These users have full control over the entire Rancher system and all clusters within it.
|
||||
|
||||
- **Restricted Admin:** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
|
||||
- **Restricted Admin (Deprecated) :** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
|
||||
|
||||
- **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.
|
||||
|
||||
@@ -20,77 +20,6 @@ Global Permissions define user authorization outside the scope of any particular
|
||||
|
||||
You cannot update or delete the built-in Global Permissions.
|
||||
|
||||
## Restricted Admin
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation from the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
|
||||
|
||||
The `restricted-admin` can create other `restricted-admin` users with an equal level of access.
|
||||
|
||||
A new setting was added to Rancher to set the initial bootstrapped administrator to have the `restricted-admin` role. This applies to the first user created when the Rancher server is started for the first time. If the environment variable is set, then no global administrator would be created, and it would be impossible to create the global administrator through Rancher.
|
||||
|
||||
To bootstrap Rancher with the `restricted-admin` as the initial user, the Rancher server should be started with the following environment variable:
|
||||
|
||||
```
|
||||
CATTLE_RESTRICTED_DEFAULT_ADMIN=true
|
||||
```
|
||||
### List of `restricted-admin` Permissions
|
||||
|
||||
The following table lists the permissions and actions that a `restricted-admin` should have in comparison with the `Administrator` and `Standard User` roles:
|
||||
|
||||
| Category | Action | Global Admin | Standard User | Restricted Admin | Notes for Restricted Admin role |
|
||||
| -------- | ------ | ------------ | ------------- | ---------------- | ------------------------------- |
|
||||
| Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
|
||||
| | Create Projects/namespaces | Yes | No | No | |
|
||||
| | Add cluster/project members | Yes | No | No | |
|
||||
| | Global DNS | Yes | No | No | |
|
||||
| | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
|
||||
| | Save as RKE Template | Yes | No | No | |
|
||||
| Security | | | | | |
|
||||
| Enable auth | Configure Authentication | Yes | No | Yes | |
|
||||
| Roles | Create/Assign GlobalRoles | Yes | No (Can list) | Yes | Auth webhook allows creating globalrole for perms already present |
|
||||
| | Create/Assign ClusterRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| | Create/Assign ProjectRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| Users | Add User/Edit/Delete/Deactivate User | Yes | No | Yes | |
|
||||
| Groups | Assign Global role to groups | Yes | No | Yes | As allowed by the webhook |
|
||||
| | Refresh Groups | Yes | No | Yes | |
|
||||
| PSP's | Manage PSP templates | Yes | No (Can list) | Yes | Same privileges as Global Admin for PSPs |
|
||||
| Tools | | | | | |
|
||||
| | Manage RKE Templates | Yes | No | Yes | |
|
||||
| | Manage Global Catalogs | Yes | No | Yes | Cannot edit/delete built-in system catalog. Can manage Helm library |
|
||||
| | Cluster Drivers | Yes | No | Yes | |
|
||||
| | Node Drivers | Yes | No | Yes | |
|
||||
| | GlobalDNS Providers | Yes | Yes (Self) | Yes | |
|
||||
| | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
|
||||
| Settings | | | | | |
|
||||
| | Manage Settings | Yes | No (Can list) | No (Can list) | |
|
||||
| User | | | | | |
|
||||
| | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
|
||||
| | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
|
||||
| | Manage Cloud Credentials | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own cloud credentials and not those created by other users |
|
||||
| Downstream Cluster | Create Cluster | Yes | Yes | Yes | |
|
||||
| | Edit Cluster | Yes | Yes | Yes | |
|
||||
| | Rotate Certificates | Yes | | Yes | |
|
||||
| | Snapshot Now | Yes | | Yes | |
|
||||
| | Restore Snapshot | Yes | | Yes | |
|
||||
| | Save as RKE Template | Yes | No | Yes | |
|
||||
| | Run CIS Scan | Yes | Yes | Yes | |
|
||||
| | Add Members | Yes | Yes | Yes | |
|
||||
| | Create Projects | Yes | Yes | Yes | |
|
||||
| Feature Charts since v2.5 | | | | | |
|
||||
| | Install Fleet | Yes | | Yes | Should not be able to run Fleet in local cluster |
|
||||
| | Deploy EKS cluster | Yes | Yes | Yes | |
|
||||
| | Deploy GKE cluster | Yes | Yes | Yes | |
|
||||
| | Deploy AKS cluster | Yes | Yes | Yes | |
|
||||
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
If Rancher already has a global administrator, they should change all global administrators over to the new `restricted-admin` role.
|
||||
|
||||
This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
|
||||
|
||||
Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
|
||||
|
||||
## Global Permission Assignment
|
||||
|
||||
Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.
|
||||
@@ -135,13 +64,15 @@ The default roles, Administrator and Standard User, each come with multiple glob
|
||||
|
||||
Administrators can enforce custom global permissions in multiple ways:
|
||||
|
||||
- [Changing the default permissions for new users](#configuring-default-global-permissions)
|
||||
- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users)
|
||||
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups)
|
||||
- [Creating custom global roles](#custom-globalroles).
|
||||
- [Changing the default permissions for new users](#configuring-default-global-permissions).
|
||||
- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users).
|
||||
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups).
|
||||
|
||||
### Custom Global Permissions Reference
|
||||
### Combining Built-in GlobalRoles
|
||||
|
||||
The following table lists each custom global permission available and whether it is included in the default global permissions, `Administrator`, `Standard User` and `User-Base`.
|
||||
Rancher provides several GlobalRoles which grant granular permissions for certain common use cases.
|
||||
The following table lists each built-in global permission and whether it is included in the default global permissions, `Administrator`, `Standard User` and `User-Base`.
|
||||
|
||||
| Custom Global Permission | Administrator | Standard User | User-Base |
|
||||
| ---------------------------------- | ------------- | ------------- |-----------|
|
||||
@@ -171,6 +102,112 @@ For details on which Kubernetes resources correspond to each global permission,
|
||||
|
||||
:::
|
||||
|
||||
### Custom GlobalRoles
|
||||
|
||||
You can create custom GlobalRoles to satisfy use cases not directly addressed by built-in GlobalRoles.
|
||||
|
||||
Create custom GlobalRoles through the UI or through automation (such as the Rancher Kubernetes API). You can specify the same type of rules as the rules for upstream roles and clusterRoles.
|
||||
|
||||
#### Escalate and Bind verbs
|
||||
|
||||
When giving permissions on GlobalRoles, keep in mind that Rancher respects the `escalate` and `bind` verbs, in a similar fashion to [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update).
|
||||
|
||||
Both of these verbs, which are given on the GlobalRoles resource, can grant users the permission to bypass Rancher's privilege escalation checks. This potentially allows users to become admins. Since this represents a serious security risk, `bind` and `escalate` should be distributed to users with great caution.
|
||||
|
||||
The `escalate` verb allows users to change a GlobalRole and add any permission, even if the users doesn't have the permissions in the current GlobalRole or the new version of the GlobalRole.
|
||||
|
||||
The `bind` verb allows users to create a GlobalRoleBinding to the specified GlobalRole, even if they do not have the permissions in the GlobalRole.
|
||||
|
||||
:::danger
|
||||
|
||||
The wildcard verb `*` also includes the `bind` and `escalate` verbs. This means that giving `*` on GlobalRoles to a user also gives them both `escalate` and `bind`.
|
||||
|
||||
:::
|
||||
|
||||
##### Custom GlobalRole Examples
|
||||
|
||||
To grant permission to escalate only the `test-gr` GlobalRole:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
resourceNames:
|
||||
- 'test-gr'
|
||||
verbs:
|
||||
- 'escalate'
|
||||
```
|
||||
|
||||
To grant permission to escalate all GlobalRoles:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
verbs:
|
||||
- 'escalate'
|
||||
```
|
||||
|
||||
To grant permission to create bindings (which bypass escalation checks) to only the `test-gr` GlobalRole:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
resourceNames:
|
||||
- 'test-gr'
|
||||
verbs:
|
||||
- 'bind'
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalrolebindings'
|
||||
verbs:
|
||||
- 'create'
|
||||
```
|
||||
|
||||
Granting `*` permissions (which includes both `escalate` and `bind`):
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
- apiGroups:
|
||||
- 'management.cattle.io'
|
||||
resources:
|
||||
- 'globalroles'
|
||||
verbs:
|
||||
- '*'
|
||||
```
|
||||
|
||||
#### GlobalRole Permissions on Downstream Clusters
|
||||
|
||||
GlobalRoles can grant one or more RoleTemplates on every downstream cluster through the `inheritedClusterRoles` field. Values in this field must refer to a RoleTemplate which exists and has a `context` of Cluster.
|
||||
|
||||
With this field, users gain the specified permissions on all current or future downstream clusters. For example, consider the following GlobalRole:
|
||||
|
||||
```yaml
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: GlobalRole
|
||||
displayName: All Downstream Owner
|
||||
metadata:
|
||||
name: all-downstream-owner
|
||||
inheritedClusterRoles:
|
||||
- cluster-owner
|
||||
```
|
||||
|
||||
Any user with this permission will be a cluster-owner on all downstream clusters. If a new cluster is added, regardless of type, the user will be an owner on that cluster as well.
|
||||
|
||||
:::danger
|
||||
|
||||
Using this field on [default GlobalRoles](#configuring-default-global-permissions) may result in users gaining excessive permissions.
|
||||
|
||||
:::
|
||||
|
||||
### Configuring Default Global Permissions
|
||||
|
||||
If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
|
||||
@@ -249,3 +286,79 @@ To refresh group memberships,
|
||||
1. Click **Refresh Group Memberships**.
|
||||
|
||||
**Result:** Any changes to the group members' permissions will take effect.
|
||||
|
||||
## Restricted Admin
|
||||
|
||||
:::warning Deprecated
|
||||
|
||||
The Restricted Admin role is deprecated, and will be removed in a future version of Rancher (2.10 or higher). You should make a custom role with the desired permissions instead of relying on this built-in role.
|
||||
|
||||
:::
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation on the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
|
||||
|
||||
The `restricted-admin` can create other `restricted-admin` users with an equal level of access.
|
||||
|
||||
A new setting was added to Rancher to set the initial bootstrapped administrator to have the `restricted-admin` role. This applies to the first user created when the Rancher server is started for the first time. If the environment variable is set, then no global administrator would be created, and it would be impossible to create the global administrator through Rancher.
|
||||
|
||||
To bootstrap Rancher with the `restricted-admin` as the initial user, the Rancher server should be started with the following environment variable:
|
||||
|
||||
```
|
||||
CATTLE_RESTRICTED_DEFAULT_ADMIN=true
|
||||
```
|
||||
### List of `restricted-admin` Permissions
|
||||
|
||||
The following table lists the permissions and actions that a `restricted-admin` should have in comparison with the `Administrator` and `Standard User` roles:
|
||||
|
||||
| Category | Action | Global Admin | Standard User | Restricted Admin | Notes for Restricted Admin role |
|
||||
| -------- | ------ | ------------ | ------------- | ---------------- | ------------------------------- |
|
||||
| Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
|
||||
| | Create Projects/namespaces | Yes | No | No | |
|
||||
| | Add cluster/project members | Yes | No | No | |
|
||||
| | Global DNS | Yes | No | No | |
|
||||
| | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
|
||||
| | Save as RKE Template | Yes | No | No | |
|
||||
| Security | | | | | |
|
||||
| Enable auth | Configure Authentication | Yes | No | Yes | |
|
||||
| Roles | Create/Assign GlobalRoles | Yes | No (Can list) | Yes | Auth webhook allows creating globalrole for perms already present |
|
||||
| | Create/Assign ClusterRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| | Create/Assign ProjectRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| Users | Add User/Edit/Delete/Deactivate User | Yes | No | Yes | |
|
||||
| Groups | Assign Global role to groups | Yes | No | Yes | As allowed by the webhook |
|
||||
| | Refresh Groups | Yes | No | Yes | |
|
||||
| PSP's | Manage PSP templates | Yes | No (Can list) | Yes | Same privileges as Global Admin for PSPs |
|
||||
| Tools | | | | | |
|
||||
| | Manage RKE Templates | Yes | No | Yes | |
|
||||
| | Manage Global Catalogs | Yes | No | Yes | Cannot edit/delete built-in system catalog. Can manage Helm library |
|
||||
| | Cluster Drivers | Yes | No | Yes | |
|
||||
| | Node Drivers | Yes | No | Yes | |
|
||||
| | GlobalDNS Providers | Yes | Yes (Self) | Yes | |
|
||||
| | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
|
||||
| Settings | | | | | |
|
||||
| | Manage Settings | Yes | No (Can list) | No (Can list) | |
|
||||
| User | | | | | |
|
||||
| | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
|
||||
| | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
|
||||
| | Manage Cloud Credentials | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own cloud credentials and not those created by other users |
|
||||
| Downstream Cluster | Create Cluster | Yes | Yes | Yes | |
|
||||
| | Edit Cluster | Yes | Yes | Yes | |
|
||||
| | Rotate Certificates | Yes | | Yes | |
|
||||
| | Snapshot Now | Yes | | Yes | |
|
||||
| | Restore Snapshot | Yes | | Yes | |
|
||||
| | Save as RKE Template | Yes | No | Yes | |
|
||||
| | Run CIS Scan | Yes | Yes | Yes | |
|
||||
| | Add Members | Yes | Yes | Yes | |
|
||||
| | Create Projects | Yes | Yes | Yes | |
|
||||
| Feature Charts since v2.5 | | | | | |
|
||||
| | Install Fleet | Yes | | Yes | Should not be able to run Fleet in local cluster |
|
||||
| | Deploy EKS cluster | Yes | Yes | Yes | |
|
||||
| | Deploy GKE cluster | Yes | Yes | Yes | |
|
||||
| | Deploy AKS cluster | Yes | Yes | Yes | |
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach.
|
||||
|
||||
This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
|
||||
|
||||
Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
|
||||
|
||||
+7
-5
@@ -27,7 +27,8 @@ Since Rancher can be installed on any Kubernetes cluster, you can use this backu
|
||||
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
Install the [rancher-backup chart](https://github.com/rancher/backup-restore-operator/tags), using a version in the 2.x.x major version range:
|
||||
|
||||
Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
|
||||
|
||||
1. Add the Helm repository:
|
||||
|
||||
@@ -36,13 +37,14 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. Select and set `CHART_VERSION` variable with a 2.x.x rancher-backup release version:
|
||||
1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
|
||||
|
||||
```bash
|
||||
helm search repo --versions rancher-charts/rancher-backup
|
||||
CHART_VERSION=<2.x.x>
|
||||
CHART_VERSION=<chart-version>
|
||||
```
|
||||
|
||||
1. Install the charts:
|
||||
|
||||
```bash
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
|
||||
@@ -50,7 +52,7 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
|
||||
:::note
|
||||
|
||||
The above assumes an environment with outbound connectivity to Docker Hub
|
||||
The above assumes an environment with outbound connectivity to Docker Hub.
|
||||
|
||||
For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.
|
||||
|
||||
|
||||
@@ -1,17 +1,13 @@
|
||||
---
|
||||
title: Integrations in Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher"/>
|
||||
</head>
|
||||
|
||||
import {Card, CardSection} from '@site/src/components/CardComponents';
|
||||
import {
|
||||
ReadingModeMobileRegular,
|
||||
QuestionRegular,
|
||||
ArrowUpRegular,
|
||||
PlayRegular,
|
||||
FlowchartRegular,
|
||||
RocketRegular
|
||||
} from '@fluentui/react-icons';
|
||||
import { FaAws, FaGoogle, FaCloud, FaServer, faGear } from "react-icons/fa6";
|
||||
import HarvesterIcon from '@site/static/img/harvester_logo_horizontal.svg';
|
||||
import {RocketRegular} from '@fluentui/react-icons';
|
||||
|
||||
Prime is the Rancher ecosystem’s enterprise offering, with additional security, extended lifecycles, and access to Prime-exclusive documentation. Rancher Prime installation assets are hosted on a trusted SUSE registry, owned and managed by Rancher. The trusted Prime registry includes only stable releases that have been community-tested.
|
||||
|
||||
|
||||
@@ -55,7 +55,13 @@ For a list of monitoring components exposed in the Rancher UI, along with common
|
||||
|
||||
## Role-based Access Control
|
||||
|
||||
For information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
|
||||
For more information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
|
||||
|
||||
:::note
|
||||
|
||||
Rancher and Project read permissions don't necessarily apply to monitoring resources. See [monitoring-ui-view](rbac-for-monitoring.md#additional-monitoring-clusterroles) for more details.
|
||||
|
||||
:::
|
||||
|
||||
## Guides
|
||||
|
||||
|
||||
@@ -112,7 +112,7 @@ Monitoring also creates additional `ClusterRoles` that aren't assigned to users
|
||||
|
||||
| Role | Purpose |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. |
|
||||
| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. <br/> <br/> This role doesn't grant access to monitoring endpoints. As a result, users with this role won't be able to view cluster monitoring graphs and dashboards in the Rancher UI; however, they are able to access the monitoring Grafana, Prometheus, and Alertmanager UIs if provided those links. |
|
||||
|
||||
:::note
|
||||
|
||||
@@ -216,7 +216,11 @@ In addition to these default roles, the following Rancher project roles can be a
|
||||
|--------------------------|-------------------------------|-------|------|
|
||||
| View Monitoring* | [monitoring-ui-view](#additional-monitoring-clusterroles) | 2.4.8+ | 9.4.204+ |
|
||||
|
||||
\* A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project.
|
||||
:::note
|
||||
|
||||
A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project.
|
||||
|
||||
:::
|
||||
|
||||
### Differences in 2.5.x
|
||||
|
||||
|
||||
@@ -6,6 +6,8 @@ title: OPA Gatekeeper
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/opa-gatekeeper"/>
|
||||
</head>
|
||||
|
||||
<DeprecationOPAGatekeeper link="kubewarden" />
|
||||
|
||||
To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.
|
||||
|
||||
OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.
|
||||
|
||||
@@ -68,18 +68,24 @@ The following commands are available for use in Rancher CLI.
|
||||
| `catalog` | Performs operations on [catalogs](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md). |
|
||||
| `clusters, [cluster]` | Performs operations on your [clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md). |
|
||||
| `context` | Switches between Rancher [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). For an example, see [Project Selection](#project-selection). |
|
||||
| `globaldns` | Performs operations on global DNS providers and entries. |
|
||||
| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]` | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) and [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md)). Specify resources by name or ID. |
|
||||
| `kubectl` |Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `kubectl` | Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `login, [l]` | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication). |
|
||||
| `namespaces, [namespace]` |Performs operations on namespaces. |
|
||||
| `nodes, [node]` |Performs operations on nodes. |
|
||||
| `machines, [machine]` | Performs operations on machines. |
|
||||
| `multiclusterapps, [multiclusterapp mcapps mcapp]` | Performs operations with multi-cluster apps. |
|
||||
| `namespaces, [namespace]` | Performs operations on [namespaces](../../how-to-guides/new-user-guides/manage-namespaces.md). |
|
||||
| `nodes, [node]` | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md). |
|
||||
| `projects, [project]` | Performs operations on [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). |
|
||||
| `ps` | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project. |
|
||||
| `server` | Performs operations for the server. |
|
||||
| `settings, [setting]` | Shows the current settings for your Rancher Server. |
|
||||
| `ssh` | Connects to one of your cluster nodes using the SSH protocol. |
|
||||
| `up` | Applies compose config. |
|
||||
| `wait` | Waits for resources cluster, app, project, multiClusterApp. |
|
||||
| `token` | Authenticates and generates new kubeconfig token. |
|
||||
| `help, [h]` | Shows a list of commands or help for one command. |
|
||||
|
||||
|
||||
### Rancher CLI Help
|
||||
|
||||
Once logged into Rancher Server using the CLI, enter `./rancher --help` for a list of commands.
|
||||
|
||||
@@ -24,8 +24,6 @@ This section assumes familiarity with how monitoring components work together. F
|
||||
|
||||
:::
|
||||
|
||||
To create notification receivers in the Rancher UI,
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
@@ -152,24 +150,20 @@ The Teams receiver is not a native receiver and must be enabled before it can be
|
||||
1. Select the **Teams** option and click **Install**.
|
||||
1. Take note of the namespace used as it will be required in a later step.
|
||||
|
||||
### Configure the Teams Receiver
|
||||
### Configuring the Teams Receiver
|
||||
|
||||
The Teams receiver can be configured by updating its ConfigMap. For example, the following is a minimal Teams receiver configuration.
|
||||
1. To configure the Teams receiver, update its ConfigMap. The following example is a minimal Teams receiver configuration:
|
||||
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
teams-instance-1: https://your-teams-webhook-url
|
||||
```
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
connector: https://your-teams-webhook-url
|
||||
```
|
||||
|
||||
When configuration is complete, add the receiver using the steps in [this section](#creating-receivers-in-the-rancher-ui).
|
||||
2. After you update the configuration, follow the instructions in [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui) to add the receiver. Use the example below to form your URL. Make sure to replace `<namespace>` with the namespace of the `rancher-alerting-drivers` app:
|
||||
|
||||
Use the example below as the URL where:
|
||||
|
||||
- `ns-1` is replaced with the namespace where the `rancher-alerting-drivers` app is installed
|
||||
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance-1
|
||||
```
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.<namespace>.svc:8089/v2/connector
|
||||
```
|
||||
|
||||
<!-- https://github.com/idealista/prom2teams -->
|
||||
|
||||
@@ -187,7 +181,7 @@ The SMS receiver is not a native receiver and must be enabled before it can be u
|
||||
1. Select the **SMS** option and click **Install**.
|
||||
1. Take note of the namespace used as it will be required in a later step.
|
||||
|
||||
### Configure the SMS Receiver
|
||||
### Configuring the SMS Receiver
|
||||
|
||||
The SMS receiver can be configured by updating its ConfigMap. For example, the following is a minimal SMS receiver configuration.
|
||||
|
||||
|
||||
@@ -41,8 +41,11 @@ For more information, refer to the monitoring documentation [here.](../integrati
|
||||
Rancher's integration with Istio was improved in Rancher v2.5.
|
||||
|
||||
For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md)
|
||||
|
||||
## OPA Gatekeeper
|
||||
|
||||
<DeprecationOPAGatekeeper link="../integrations-in-rancher/kubewarden" />
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../integrations-in-rancher/opa-gatekeeper.md)
|
||||
|
||||
## CIS Scans
|
||||
|
||||
@@ -10,6 +10,7 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | A vulnerability was discovered in Rancher's and Fleet's agents, currently deemed a medium to high severity CVE, that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker would need to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the server-url of the Rancher cluster). At the moment there is no fix available and it affects all supported versions of Rancher. Customers and users are advised to follow the recommendations and best practices described in our [blog post](https://www.suse.com/c/rancher-security-update/). | 16 Feb 2024 | Pending |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Norman). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI (Apiserver). | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | An issue was discovered in Rancher versions up to and including 2.6.13, 2.7.9 and 2.8.1, in which sensitive data may be leaked into Rancher's audit logs. | 8 Feb 2024 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2), [v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) and [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
@@ -9,7 +9,7 @@ title: Rancher Webhook
|
||||
Rancher-Webhook is an essential component of Rancher that works in conjunction with Kubernetes to enhance security and enable critical features for Rancher-managed clusters.
|
||||
|
||||
It integrates with Kubernetes' extensible admission controllers, as described in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), which allows Rancher-Webhook to inspect specific requests sent to the Kubernetes API server, and add custom, Rancher-specific validation and mutations to the requests that are specific to Rancher. Rancher-Webhook manages the resources to be validated using the `rancher.cattle.io` `ValidatingWebhookConfiguration` and the `rancher.cattle.io` `MutatingWebhookConfiguration`, and will override any manual edits.
|
||||
Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release.
|
||||
Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release. To safely modify these values see [Customizing Rancher-Webhook Configuration](#customizing-rancher-webhook-configuration).
|
||||
|
||||
Each Rancher version is designed to be compatible with a single version of the webhook. The compatible versions are provided below for convenience.
|
||||
|
||||
@@ -17,11 +17,11 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
<!-- releaseTask -->
|
||||
|
||||
| Rancher Version | Webhook Version |
|
||||
|-----------------|:---------------:|
|
||||
| v2.8.0 | v0.4.2 |
|
||||
| v2.8.1 | v0.4.2 |
|
||||
| v2.8.2 | v0.4.2 |
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.0 | v0.4.2 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
@@ -49,20 +49,59 @@ To bypass the webhook, impersonate both the `rancher-webhook-sudo` service accou
|
||||
kubectl create -f example.yaml --as=system:serviceaccount:cattle-system:rancher-webhook-sudo --as-group=system:masters
|
||||
```
|
||||
|
||||
## Customizing Rancher-Webhook Configuration
|
||||
|
||||
You can add custom Helm values when you install Rancher-Webhook via Helm. During a Helm install of the Rancher-Webhook chart, Rancher checks for custom Helm values. These custom values must be defined in a ConfigMap named `rancher-config`, in the `cattle-system` namespace, under the data key, `rancher-webhook`. The value of this key must be valid YAML.
|
||||
``` yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: rancher-config
|
||||
namespace: cattle-system
|
||||
labels:
|
||||
app.kubernetes.io/part-of: "rancher"
|
||||
data:
|
||||
rancher-webhook: '{"port": 9553, "priorityClassName": "system-node-critical"}'
|
||||
|
||||
```
|
||||
|
||||
Rancher redeploys the Rancher-Webhook chart when changes to the ConfigMap values are detected.
|
||||
|
||||
### Customizing Rancher-Webhook During Rancher Installation
|
||||
|
||||
When you use Helm to install the Rancher chart, you can add custom Helm values to the Rancher-Webhook of the local cluster. All values in the Rancher-Webhook chart are accessible as nested variables under the `webhook` name.
|
||||
These values are synced to the `rancher-config` ConfigMap during installation.
|
||||
|
||||
```bash
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
...
|
||||
--set webhook.port=9553 \
|
||||
--set webhook.priorityClassName="system-node-critical"
|
||||
```
|
||||
|
||||
## Common Issues
|
||||
|
||||
### EKS Cluster with Calico CNI
|
||||
|
||||
Users running an EKS cluster with Calico CNI may run into errors when the Kubernetes API server attempts to contact the Rancher-Webhook.
|
||||
One workaround for this issue [documented by Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks#install-eks-with-calico-networking) involves setting `hostNetwork=true` for the webhook deployment. Users can change this using the Helm commands below on the affected clusters.
|
||||
One workaround for this issue, as [documented by Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks#install-eks-with-calico-networking) involves setting `hostNetwork=true` for the webhook deployment. You can change this value by adding the Helm value `global.hostNetwork=true` to the `rancher-config` ConfigMap. See [Customizing Rancher-Webhook Configuration](#customizing-rancher-webhook-configuration) for more info.
|
||||
|
||||
``` bash
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
helm upgrade --reuse-values rancher-webhook rancher-charts/rancher-webhook -n cattle-system --set global.hostNetwork=true
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: rancher-config
|
||||
namespace: cattle-system
|
||||
labels:
|
||||
app.kubernetes.io/part-of: "rancher"
|
||||
data:
|
||||
rancher-webhook: '{"global": {"hostNetwork": true}}'
|
||||
```
|
||||
|
||||
**Note:** This temporary workaround may violate an environment's security policy. This workaround also requires that port 9443 is unused on the host network.
|
||||
|
||||
**Note:** Helm uses secrets by default. This is a datatype that some webhook versions validate to store information. In these cases, directly update the deployment with the hostNetwork=true value using kubectl, then run the Helm commands listed above to prevent drift between the Helm configuration and the actual state of the cluster.
|
||||
**Note:** By default, Helm stores information as secrets. Secrets are a resource that some webhook versions validate. In these cases, directly update the deployment with the `hostNetwork=true` value using kubectl, then update the webhook configuration as specified above.
|
||||
|
||||
### Private GKE Cluster
|
||||
|
||||
|
||||
@@ -1,19 +1,18 @@
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9100 | Default port required by Monitoring to scrape metrics from Linux node-exporters |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------------------|
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Linux and Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"copyright": {
|
||||
"message": "Copyright © 2023 SUSE Rancher. All Rights Reserved.",
|
||||
"message": "Copyright © 2024 SUSE Rancher. All Rights Reserved.",
|
||||
"description": "The footer copyright"
|
||||
}
|
||||
}
|
||||
|
||||
+1
-1
@@ -5,7 +5,7 @@
|
||||
"scripts": {
|
||||
"docusaurus": "docusaurus",
|
||||
"start": "docusaurus start",
|
||||
"build": "NODE_OPTIONS='--max-old-space-size=6144' docusaurus build",
|
||||
"build": "NODE_OPTIONS='--max-old-space-size=7168' docusaurus build",
|
||||
"swizzle": "docusaurus swizzle",
|
||||
"deploy": "docusaurus deploy",
|
||||
"clear": "docusaurus clear",
|
||||
|
||||
@@ -5,6 +5,6 @@ The following table summarizes different GitHub metrics to give you an idea of e
|
||||
| ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | https://github.com/projectcalico/canal | 708 | 103 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 8.4k | 2.9k | 231 |
|
||||
| Calico | https://github.com/projectcalico/calico | 5.3k | 1.2k | 335 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.5k | 670 | 87 |
|
||||
| Cilium | https://github.com/cilium/cilium | 17.8k | 2.6k | 699 |
|
||||
| Calico | https://github.com/projectcalico/calico | 5.3k | 1.2k | 336 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.6k | 679 | 87 |
|
||||
| Cilium | https://github.com/cilium/cilium | 18k | 2.6k | 706 |
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
:::warning
|
||||
|
||||
Helm v2 support is deprecated as of the Rancher v2.7 line and will be removed in Rancher v2.9.
|
||||
|
||||
:::
|
||||
@@ -0,0 +1,5 @@
|
||||
:::warning
|
||||
|
||||
OPA Gatekeeper is deprecated and will be removed in a future release. As a replacement for OPA Gatekeeper, consider switching to <a href={props.link}>Kubewarden</a>.
|
||||
|
||||
:::
|
||||
+91
-9
@@ -6,31 +6,57 @@ title: Rancher Documentation Versions
|
||||
|
||||
### Current versions
|
||||
|
||||
Below are the documentation and release notes for the currently released version of Rancher 2.8.x:
|
||||
Here you can find links to supporting documentation for the current released version of Rancher v2.8, and its availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.2</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.2">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-8-2/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Below are the documentation and release notes for the currently released version of Rancher 2.7.x:
|
||||
Here you can find links to supporting documentation for the current released version of Rancher v2.7, and its availability for [Rancher Prime](/v2.7/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.10</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.10">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-10/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Below are the documentation and release notes for the currently released version of Rancher 2.6.x:
|
||||
Here you can find links to supporting documentation for the current released version of Rancher v2.6:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.6.14</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.6">Documentation</a></td>
|
||||
@@ -41,95 +67,141 @@ Below are the documentation and release notes for the currently released version
|
||||
|
||||
### Past versions
|
||||
|
||||
Below are the documentation and release notes for previous versions of Rancher 2.8.x:
|
||||
Here you can find links to supporting documentation for previous versions of Rancher v2.8, and their availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.1</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.1">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-8-1/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.0</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.0">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<br/>
|
||||
|
||||
Below are the documentation and release notes for previous versions of Rancher 2.7.x:
|
||||
Here you can find links to supporting documentation for previous versions of Rancher v2.7, and their availability for [Rancher Prime](/v2.7/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.9</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.9">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-9/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.8</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.8">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.7</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.7">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.6</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.6">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-6/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.5</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.5">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-5/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.4</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.4">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-4/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.3</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.3">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-3/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.2</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.2">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-2/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.1</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.1">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-1/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.7.0</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.7">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.7.0">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-0/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<br/>
|
||||
|
||||
Below are the documentation and release notes for previous versions of Rancher 2.6.x:
|
||||
Here you can find links to supporting documentation for previous versions of Rancher v2.6:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.6.13</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.6">Documentation</a></td>
|
||||
@@ -220,9 +292,15 @@ Below are the documentation and release notes for previous versions of Rancher 2
|
||||
|
||||
### Legacy versions (EOL)
|
||||
|
||||
Below are the documentation and release notes for legacy versions of Rancher 2.5.x:
|
||||
Here you can find links to supporting documentation for legacy versions of Rancher v2.5:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.5.17</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.5">Documentation</a></td>
|
||||
@@ -335,11 +413,15 @@ Below are the documentation and release notes for legacy versions of Rancher 2.5
|
||||
|
||||
<br/>
|
||||
|
||||
Below is the documentation for legacy versions of Rancher 2.0 - 2.4.x:
|
||||
Here you can find links to supporting documentation for legacy versions of v2.0-v2.4:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td><b>v2.0 - v2.4</b></td>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.0-v2.4</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.0-v2.4">Documentation</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
@@ -6,6 +6,10 @@ import TabItem from '@theme/TabItem';
|
||||
|
||||
import { CardSection, Card } from '../components/CardComponents';
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
import DeprecationOPAGatekeeper from '/shared-files/_deprecation-opa-gatekeeper.md';
|
||||
import DeprecationHelm2 from '/shared-files/_deprecation-helm2.md';
|
||||
|
||||
export default {
|
||||
// Re-use the default mapping
|
||||
...MDXComponents,
|
||||
@@ -15,4 +19,8 @@ export default {
|
||||
|
||||
CardSection,
|
||||
Card,
|
||||
|
||||
CNIPopularityTable,
|
||||
DeprecationOPAGatekeeper,
|
||||
DeprecationHelm2,
|
||||
};
|
||||
|
||||
@@ -136,8 +136,6 @@ The following table summarizes the different features available for each CNI net
|
||||
|
||||
### CNI Community Popularity
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
|
||||
<CNIPopularityTable />
|
||||
|
||||
### Which CNI Provider Should I Use?
|
||||
|
||||
@@ -1,19 +1,18 @@
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9100 | Default port required by Monitoring to scrape metrics from Linux node-exporters |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | kubelet API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |-------------------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Linux and Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | kubelet API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
|
||||
@@ -134,8 +134,6 @@ The following table summarizes the different features available for each CNI net
|
||||
|
||||
### CNI Community Popularity
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
|
||||
<CNIPopularityTable />
|
||||
|
||||
### Which CNI Provider Should I Use?
|
||||
|
||||
@@ -1,19 +1,18 @@
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9100 | Default port required by Monitoring to scrape metrics from Linux node-exporters |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |-------------------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Linux and Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
|
||||
@@ -184,8 +184,6 @@ The following table summarizes the different features available for each CNI net
|
||||
|
||||
## CNI Community Popularity
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
|
||||
<CNIPopularityTable />
|
||||
|
||||
## Which CNI Provider Should I Use?
|
||||
|
||||
+7
-5
@@ -25,7 +25,8 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
|
||||
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
|
||||
Install the [rancher-backup chart](https://github.com/rancher/backup-restore-operator/tags), using a version in the 2.x.x major version range:
|
||||
|
||||
Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
|
||||
|
||||
1. Add the Helm repository:
|
||||
|
||||
@@ -34,13 +35,14 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. Select and set `CHART_VERSION` variable with a 2.x.x rancher-backup release version:
|
||||
1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
|
||||
|
||||
```bash
|
||||
helm search repo --versions rancher-charts/rancher-backup
|
||||
CHART_VERSION=<2.x.x>
|
||||
CHART_VERSION=<chart-version>
|
||||
```
|
||||
|
||||
1. Install the charts:
|
||||
|
||||
```bash
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
|
||||
@@ -48,7 +50,7 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
|
||||
:::note
|
||||
|
||||
The above assumes an environment with outbound connectivity to Docker Hub
|
||||
The above assumes an environment with outbound connectivity to Docker Hub.
|
||||
|
||||
For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.
|
||||
|
||||
|
||||
@@ -68,15 +68,22 @@ The following commands are available for use in Rancher CLI.
|
||||
| `catalog` | Performs operations on [catalogs](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md). |
|
||||
| `clusters, [cluster]` | Performs operations on your [clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md). |
|
||||
| `context` | Switches between Rancher [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). For an example, see [Project Selection](#project-selection). |
|
||||
| `globaldns` | Performs operations on global DNS providers and entries. |
|
||||
| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]` | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) and [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md)). Specify resources by name or ID. |
|
||||
| `kubectl` |Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `kubectl` | Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `login, [l]` | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication). |
|
||||
| `namespaces, [namespace]` |Performs operations on namespaces. |
|
||||
| `nodes, [node]` |Performs operations on nodes. |
|
||||
| `machines, [machine]` | Performs operations on machines. |
|
||||
| `multiclusterapps, [multiclusterapp mcapps mcapp]` | Performs operations with multi-cluster apps. |
|
||||
| `namespaces, [namespace]` | Performs operations on [namespaces](../../how-to-guides/new-user-guides/manage-namespaces.md). |
|
||||
| `nodes, [node]` | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md). |
|
||||
| `projects, [project]` | Performs operations on [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). |
|
||||
| `ps` | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project. |
|
||||
| `server` | Performs operations for the server. |
|
||||
| `settings, [setting]` | Shows the current settings for your Rancher Server. |
|
||||
| `ssh` | Connects to one of your cluster nodes using the SSH protocol. |
|
||||
| `up` | Applies compose config. |
|
||||
| `wait` | Waits for resources cluster, app, project, multiClusterApp. |
|
||||
| `token` | Authenticates and generates new kubeconfig token. |
|
||||
| `help, [h]` | Shows a list of commands or help for one command. |
|
||||
|
||||
|
||||
|
||||
+11
-15
@@ -167,24 +167,20 @@ The Teams receiver is not a native receiver and must be enabled before it can be
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Configure the Teams Receiver
|
||||
### Configuring the Teams Receiver
|
||||
|
||||
The Teams receiver can be configured by updating its ConfigMap. For example, the following is a minimal Teams receiver configuration.
|
||||
1. To configure the Teams receiver, update its ConfigMap. The following example is a minimal Teams receiver configuration:
|
||||
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
teams-instance-1: https://your-teams-webhook-url
|
||||
```
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
connector: https://your-teams-webhook-url
|
||||
```
|
||||
|
||||
When configuration is complete, add the receiver using the steps in [this section](#creating-receivers-in-the-rancher-ui).
|
||||
2. After you update the configuration, follow the instructions in [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui) to add the receiver. Use the example below to form your URL. Make sure to replace `<namespace>` with the namespace of the `rancher-alerting-drivers` app:
|
||||
|
||||
Use the example below as the URL where:
|
||||
|
||||
- `ns-1` is replaced with the namespace where the `rancher-alerting-drivers` app is installed
|
||||
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance-1
|
||||
```
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.<namespace>.svc:8089/v2/connector
|
||||
```
|
||||
|
||||
<!-- https://github.com/idealista/prom2teams -->
|
||||
|
||||
@@ -202,7 +198,7 @@ The SMS receiver is not a native receiver and must be enabled before it can be u
|
||||
1. Select the **SMS** option and click **Install**.
|
||||
1. Take note of the namespace used as it will be required in a later step.
|
||||
|
||||
### Configure the SMS Receiver
|
||||
### Configuring the SMS Receiver
|
||||
|
||||
The SMS receiver can be configured by updating its ConfigMap. For example, the following is a minimal SMS receiver configuration.
|
||||
|
||||
|
||||
@@ -1,19 +1,18 @@
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9100 | Default port required by Monitoring to scrape metrics from Linux node-exporters |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------------------|
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Linux and Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
|
||||
@@ -184,8 +184,6 @@ The following table summarizes the different features available for each CNI net
|
||||
|
||||
## CNI Community Popularity
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
|
||||
<CNIPopularityTable />
|
||||
|
||||
## Which CNI Provider Should I Use?
|
||||
|
||||
+3
@@ -28,8 +28,11 @@ The kubeconfig can also be manually targeted for the intended cluster with the `
|
||||
Review the list of known issues for each Rancher version, which can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
|
||||
|
||||
Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
|
||||
|
||||
### Helm Version
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
+2
@@ -10,6 +10,8 @@ Now that you have a running RKE cluster, you can install Rancher in it. For secu
|
||||
|
||||
### Install the Helm CLI
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:
|
||||
|
||||
```
|
||||
|
||||
+2
@@ -10,6 +10,8 @@ This section contains the requirements for Helm, which is the tool used to insta
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
- Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
|
||||
- Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.
|
||||
- Helm v2.15.0 should not be used, because of an issue with converting/comparing numbers.
|
||||
|
||||
+2
@@ -145,6 +145,8 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
|
||||
```
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
The Helm 2 command is as follows:
|
||||
|
||||
```plain
|
||||
|
||||
+7
-5
@@ -27,7 +27,8 @@ Since Rancher can be installed on any Kubernetes cluster, you can use this backu
|
||||
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
Install the [rancher-backup chart](https://github.com/rancher/backup-restore-operator/tags), using a version in the 2.x.x major version range:
|
||||
|
||||
Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
|
||||
|
||||
1. Add the Helm repository:
|
||||
|
||||
@@ -36,13 +37,14 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. Select and set `CHART_VERSION` variable with a 2.x.x rancher-backup release version:
|
||||
1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
|
||||
|
||||
```bash
|
||||
helm search repo --versions rancher-charts/rancher-backup
|
||||
CHART_VERSION=<2.x.x>
|
||||
CHART_VERSION=<chart-version>
|
||||
```
|
||||
|
||||
1. Install the charts:
|
||||
|
||||
```bash
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
|
||||
@@ -50,7 +52,7 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
|
||||
:::note
|
||||
|
||||
The above assumes an environment with outbound connectivity to Docker Hub
|
||||
The above assumes an environment with outbound connectivity to Docker Hub.
|
||||
|
||||
For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.
|
||||
|
||||
|
||||
+1
@@ -29,6 +29,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
| v2.7.7 | v2.0.2 |
|
||||
| v2.7.8 | v2.0.2 |
|
||||
| v2.7.9 | v2.0.2 |
|
||||
| v2.7.10 | v2.0.2 |
|
||||
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
+7
-1
@@ -55,7 +55,13 @@ For a list of monitoring components exposed in the Rancher UI, along with common
|
||||
|
||||
## Role-based Access Control
|
||||
|
||||
For information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
|
||||
For more information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
|
||||
|
||||
:::note
|
||||
|
||||
Rancher and Project read permissions don't necessarily apply to monitoring resources. See [monitoring-ui-view](rbac-for-monitoring.md#additional-monitoring-clusterroles) for more details.
|
||||
|
||||
:::
|
||||
|
||||
## Guides
|
||||
|
||||
|
||||
+6
-2
@@ -112,7 +112,7 @@ Monitoring also creates additional `ClusterRoles` that aren't assigned to users
|
||||
|
||||
| Role | Purpose |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Grafana, and Alertmanager UIs through the Rancher proxy. |
|
||||
| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. <br/> <br/> This role doesn't grant access to monitoring endpoints. As a result, users with this role won't be able to view cluster monitoring graphs and dashboards in the Rancher UI; however, they are able to access the monitoring Grafana, Prometheus, and Alertmanager UIs if provided those links. |
|
||||
|
||||
:::note
|
||||
|
||||
@@ -216,7 +216,11 @@ In addition to these default roles, the following Rancher project roles can be a
|
||||
|--------------------------|-------------------------------|-------|------|
|
||||
| View Monitoring* | [monitoring-ui-view](#additional-monitoring-clusterroles) | 2.4.8+ | 9.4.204+ |
|
||||
|
||||
\* A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project.
|
||||
:::note
|
||||
|
||||
A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project.
|
||||
|
||||
:::note
|
||||
|
||||
### Differences in 2.5.x
|
||||
|
||||
|
||||
@@ -68,15 +68,22 @@ The following commands are available for use in Rancher CLI.
|
||||
| `catalog` | Performs operations on [catalogs](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md). |
|
||||
| `clusters, [cluster]` | Performs operations on your [clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md). |
|
||||
| `context` | Switches between Rancher [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). For an example, see [Project Selection](#project-selection). |
|
||||
| `globaldns` | Performs operations on global DNS providers and entries. |
|
||||
| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]` | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) and [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md)). Specify resources by name or ID. |
|
||||
| `kubectl` |Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `kubectl` | Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `login, [l]` | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication). |
|
||||
| `namespaces, [namespace]` |Performs operations on namespaces. |
|
||||
| `nodes, [node]` |Performs operations on nodes. |
|
||||
| `machines, [machine]` | Performs operations on machines. |
|
||||
| `multiclusterapps, [multiclusterapp mcapps mcapp]` | Performs operations with multi-cluster apps. |
|
||||
| `namespaces, [namespace]` | Performs operations on [namespaces](../../how-to-guides/new-user-guides/manage-namespaces.md). |
|
||||
| `nodes, [node]` | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md). |
|
||||
| `projects, [project]` | Performs operations on [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). |
|
||||
| `ps` | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project. |
|
||||
| `server` | Performs operations for the server. |
|
||||
| `settings, [setting]` | Shows the current settings for your Rancher Server. |
|
||||
| `ssh` | Connects to one of your cluster nodes using the SSH protocol. |
|
||||
| `up` | Applies compose config. |
|
||||
| `wait` | Waits for resources cluster, app, project, multiClusterApp. |
|
||||
| `token` | Authenticates and generates new kubeconfig token. |
|
||||
| `help, [h]` | Shows a list of commands or help for one command. |
|
||||
|
||||
|
||||
|
||||
+11
-17
@@ -24,8 +24,6 @@ This section assumes familiarity with how monitoring components work together. F
|
||||
|
||||
:::
|
||||
|
||||
To create notification receivers in the Rancher UI,
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
@@ -152,24 +150,20 @@ The Teams receiver is not a native receiver and must be enabled before it can be
|
||||
1. Select the **Teams** option and click **Install**.
|
||||
1. Take note of the namespace used as it will be required in a later step.
|
||||
|
||||
### Configure the Teams Receiver
|
||||
### Configuring the Teams Receiver
|
||||
|
||||
The Teams receiver can be configured by updating its ConfigMap. For example, the following is a minimal Teams receiver configuration.
|
||||
1. To configure the Teams receiver, update its ConfigMap. The following example is a minimal Teams receiver configuration:
|
||||
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
teams-instance-1: https://your-teams-webhook-url
|
||||
```
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
connector: https://your-teams-webhook-url
|
||||
```
|
||||
|
||||
When configuration is complete, add the receiver using the steps in [this section](#creating-receivers-in-the-rancher-ui).
|
||||
2. After you update the configuration, follow the instructions in [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui) to add the receiver. Use the example below to form your URL. Make sure to replace `<namespace>` with the namespace of the `rancher-alerting-drivers` app:
|
||||
|
||||
Use the example below as the URL where:
|
||||
|
||||
- `ns-1` is replaced with the namespace where the `rancher-alerting-drivers` app is installed
|
||||
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance-1
|
||||
```
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.<namespace>.svc:8089/v2/connector
|
||||
```
|
||||
|
||||
<!-- https://github.com/idealista/prom2teams -->
|
||||
|
||||
@@ -187,7 +181,7 @@ The SMS receiver is not a native receiver and must be enabled before it can be u
|
||||
1. Select the **SMS** option and click **Install**.
|
||||
1. Take note of the namespace used as it will be required in a later step.
|
||||
|
||||
### Configure the SMS Receiver
|
||||
### Configuring the SMS Receiver
|
||||
|
||||
The SMS receiver can be configured by updating its ConfigMap. For example, the following is a minimal SMS receiver configuration.
|
||||
|
||||
|
||||
@@ -9,7 +9,8 @@ title: Rancher Webhook
|
||||
Rancher-Webhook is an essential component of Rancher that works in conjunction with Kubernetes to enhance security and enable critical features for Rancher-managed clusters.
|
||||
|
||||
It integrates with Kubernetes' extensible admission controllers, as described in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), which allows Rancher-Webhook to inspect specific requests sent to the Kubernetes API server, and add custom, Rancher-specific validation and mutations to the requests that are specific to Rancher. Rancher-Webhook manages the resources to be validated using the `rancher.cattle.io` `ValidatingWebhookConfiguration` and the `rancher.cattle.io` `MutatingWebhookConfiguration`, and will override any manual edits.
|
||||
Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release.
|
||||
|
||||
Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release. To safely modify these values see [Customizing Rancher-Webhook Configuration](#customizing-rancher-webhook-configuration).
|
||||
|
||||
Each Rancher version is designed to be compatible with a single version of the webhook. The compatible versions are provided below for convenience.
|
||||
|
||||
@@ -17,19 +18,19 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
<!-- releaseTask -->
|
||||
|
||||
| Rancher Version | Webhook Version |
|
||||
|-----------------|:---------------:|
|
||||
| v2.7.0 | v0.3.0 |
|
||||
| v2.7.1 | v0.3.0 |
|
||||
| v2.7.2 | v0.3.2 |
|
||||
| v2.7.3 | v0.3.3 |
|
||||
| v2.7.4 | v0.3.4 |
|
||||
| v2.7.5 | v0.3.5 |
|
||||
| v2.7.6 | v0.3.5 |
|
||||
| v2.7.7 | v0.3.6 |
|
||||
| v2.7.8 | v0.3.6 |
|
||||
| v2.7.9 | v0.3.6 |
|
||||
| v2.7.10 | v0.3.6 |
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.7.10 | v0.3.6 | ✓ | ✓ |
|
||||
| v2.7.9 | v0.3.6 | ✗ | ✓ |
|
||||
| v2.7.8 | v0.3.6 | ✗ | ✓ |
|
||||
| v2.7.7 | v0.3.6 | ✓ | ✓ |
|
||||
| v2.7.6 | v0.3.5 | ✓ | ✓ |
|
||||
| v2.7.5 | v0.3.5 | ✓ | ✓ |
|
||||
| v2.7.4 | v0.3.4 | ✓ | ✓ |
|
||||
| v2.7.3 | v0.3.3 | ✓ | ✓ |
|
||||
| v2.7.2 | v0.3.2 | ✓ | ✓ |
|
||||
| v2.7.1 | v0.3.0 | ✓ | ✓ |
|
||||
| v2.7.0 | v0.3.0 | ✓ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
@@ -57,6 +58,39 @@ To bypass the webhook, impersonate both the `rancher-webhook-sudo` service accou
|
||||
kubectl create -f example.yaml --as=system:serviceaccount:cattle-system:rancher-webhook-sudo --as-group=system:masters
|
||||
```
|
||||
|
||||
## Customizing Rancher-Webhook Configuration
|
||||
|
||||
You can add custom Helm values when you install Rancher-Webhook via Helm. During a Helm install of the Rancher-Webhook chart, Rancher checks for custom Helm values. These custom values must be defined in a ConfigMap named `rancher-config`, in the `cattle-system` namespace, under the data key, `rancher-webhook`. The value of this key must be valid YAML.
|
||||
|
||||
``` yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: rancher-config
|
||||
namespace: cattle-system
|
||||
labels:
|
||||
app.kubernetes.io/part-of: "rancher"
|
||||
data:
|
||||
rancher-webhook: '{"port": 9553, "priorityClassName": "system-node-critical"}'
|
||||
|
||||
```
|
||||
|
||||
Rancher redeploys the Rancher-Webhook chart when changes to the ConfigMap values are detected.
|
||||
|
||||
### Customizing Rancher-Webhook During Rancher Installation
|
||||
|
||||
When you use Helm to install the Rancher chart, you can add custom Helm values to the Rancher-Webhook of the local cluster. All values in the Rancher-Webhook chart are accessible as nested variables under the `webhook` name.
|
||||
|
||||
These values are synced to the `rancher-config` ConfigMap during installation.
|
||||
|
||||
```bash
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
...
|
||||
--set webhook.port=9553 \
|
||||
--set webhook.priorityClassName="system-node-critical"
|
||||
```
|
||||
|
||||
## Common Issues
|
||||
|
||||
### EKS Cluster with Calico CNI
|
||||
|
||||
@@ -1,19 +1,18 @@
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9100 | Default port required by Monitoring to scrape metrics from Linux node-exporters |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------------------|
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Linux and Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: API Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/api/api-reference"/>
|
||||
</head>
|
||||
|
||||
:::note
|
||||
|
||||
At this time, not all Rancher resources are available through the Rancher Kubernetes API.
|
||||
|
||||
@@ -111,3 +111,5 @@ Delete the project under the cluster namespace:
|
||||
```bash
|
||||
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.
|
||||
|
||||
@@ -184,8 +184,6 @@ The following table summarizes the different features available for each CNI net
|
||||
|
||||
## CNI Community Popularity
|
||||
|
||||
import CNIPopularityTable from '/shared-files/_cni-popularity.md';
|
||||
|
||||
<CNIPopularityTable />
|
||||
|
||||
## Which CNI Provider Should I Use?
|
||||
|
||||
+3
@@ -28,8 +28,11 @@ The kubeconfig can also be manually targeted for the intended cluster with the `
|
||||
Review the list of known issues for each Rancher version, which can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
|
||||
|
||||
Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
|
||||
|
||||
### Helm Version
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
+2
@@ -10,6 +10,8 @@ Now that you have a running RKE cluster, you can install Rancher in it. For secu
|
||||
|
||||
### Install the Helm CLI
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
Install the [Helm](https://helm.sh/docs/intro/install/) CLI on a host where you have a kubeconfig to access your Kubernetes cluster:
|
||||
|
||||
```
|
||||
|
||||
+2
@@ -10,6 +10,8 @@ This section contains the requirements for Helm, which is the tool used to insta
|
||||
|
||||
> The installation instructions have been updated for Helm 3. For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 Migration Docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) [This section](/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2.md) provides a copy of the older high-availability Rancher installation instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
- Helm v3.2.x or higher is required to install or upgrade Rancher v2.5.
|
||||
- Helm v2.16.0 or higher is required for Kubernetes v1.16. For the default Kubernetes version, refer to the [release notes](https://github.com/rancher/rke/releases) for the version of RKE that you are using.
|
||||
- Helm v2.15.0 should not be used, because of an issue with converting/comparing numbers.
|
||||
|
||||
+2
@@ -145,6 +145,8 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
--set cainjector.image.repository=<REGISTRY.YOURDOMAIN.COM:PORT>/quay.io/jetstack/cert-manager-cainjector
|
||||
```
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
The Helm 2 command is as follows:
|
||||
|
||||
```plain
|
||||
|
||||
+1
-4
@@ -64,6 +64,7 @@ The default roles, Administrator and Standard User, each come with multiple glob
|
||||
|
||||
Administrators can enforce custom global permissions in multiple ways:
|
||||
|
||||
- [Creating custom global roles](#custom-globalroles).
|
||||
- [Changing the default permissions for new users](#configuring-default-global-permissions).
|
||||
- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users).
|
||||
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups).
|
||||
@@ -207,7 +208,6 @@ Using this field on [default GlobalRoles](#configuring-default-global-permission
|
||||
|
||||
:::
|
||||
|
||||
|
||||
### Configuring Default Global Permissions
|
||||
|
||||
If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
|
||||
@@ -355,7 +355,6 @@ The following table lists the permissions and actions that a `restricted-admin`
|
||||
| | Deploy GKE cluster | Yes | Yes | Yes | |
|
||||
| | Deploy AKS cluster | Yes | Yes | Yes | |
|
||||
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach.
|
||||
@@ -363,5 +362,3 @@ In previous version, the docs recommended that all users should be changed over
|
||||
This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
|
||||
|
||||
Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
|
||||
|
||||
|
||||
|
||||
+7
-5
@@ -27,7 +27,8 @@ Since Rancher can be installed on any Kubernetes cluster, you can use this backu
|
||||
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
Install the [rancher-backup chart](https://github.com/rancher/backup-restore-operator/tags), using a version in the 2.x.x major version range:
|
||||
|
||||
Install the [`rancher-backup chart`](https://github.com/rancher/backup-restore-operator/tags):
|
||||
|
||||
1. Add the Helm repository:
|
||||
|
||||
@@ -36,13 +37,14 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
helm repo update
|
||||
```
|
||||
|
||||
1. Select and set `CHART_VERSION` variable with a 2.x.x rancher-backup release version:
|
||||
1. Set a `CHART_VERSION` variable, selecting a `rancher-backup` chart version compatible with your version of Rancher. See the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions), within the **Rancher Apps / Cluster Tools** section, to see which `rancher-backup` versions are supported:
|
||||
|
||||
```bash
|
||||
helm search repo --versions rancher-charts/rancher-backup
|
||||
CHART_VERSION=<2.x.x>
|
||||
CHART_VERSION=<chart-version>
|
||||
```
|
||||
|
||||
1. Install the charts:
|
||||
|
||||
```bash
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
|
||||
@@ -50,7 +52,7 @@ Install the [rancher-backup chart](https://github.com/rancher/backup-restore-ope
|
||||
|
||||
:::note
|
||||
|
||||
The above assumes an environment with outbound connectivity to Docker Hub
|
||||
The above assumes an environment with outbound connectivity to Docker Hub.
|
||||
|
||||
For an **air-gapped environment**, use the Helm value below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup Helm chart.
|
||||
|
||||
|
||||
@@ -1,17 +1,13 @@
|
||||
---
|
||||
title: Integrations in Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher"/>
|
||||
</head>
|
||||
|
||||
import {Card, CardSection} from '@site/src/components/CardComponents';
|
||||
import {
|
||||
ReadingModeMobileRegular,
|
||||
QuestionRegular,
|
||||
ArrowUpRegular,
|
||||
PlayRegular,
|
||||
FlowchartRegular,
|
||||
RocketRegular
|
||||
} from '@fluentui/react-icons';
|
||||
import { FaAws, FaGoogle, FaCloud, FaServer, faGear } from "react-icons/fa6";
|
||||
import HarvesterIcon from '@site/static/img/harvester_logo_horizontal.svg';
|
||||
import {RocketRegular} from '@fluentui/react-icons';
|
||||
|
||||
Prime is the Rancher ecosystem’s enterprise offering, with additional security, extended lifecycles, and access to Prime-exclusive documentation. Rancher Prime installation assets are hosted on a trusted SUSE registry, owned and managed by Rancher. The trusted Prime registry includes only stable releases that have been community-tested.
|
||||
|
||||
|
||||
+7
-1
@@ -55,7 +55,13 @@ For a list of monitoring components exposed in the Rancher UI, along with common
|
||||
|
||||
## Role-based Access Control
|
||||
|
||||
For information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
|
||||
For more information on configuring access to monitoring, see [this page.](rbac-for-monitoring.md)
|
||||
|
||||
:::note
|
||||
|
||||
Rancher and Project read permissions don't necessarily apply to monitoring resources. See [monitoring-ui-view](rbac-for-monitoring.md#additional-monitoring-clusterroles) for more details.
|
||||
|
||||
:::
|
||||
|
||||
## Guides
|
||||
|
||||
|
||||
+6
-2
@@ -112,7 +112,7 @@ Monitoring also creates additional `ClusterRoles` that aren't assigned to users
|
||||
|
||||
| Role | Purpose |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Grafana, and Alertmanager UIs through the Rancher proxy. |
|
||||
| monitoring-ui-view | _Available as of Monitoring v2 14.5.100+_ This ClusterRole allows users with write access to the project to view metrics graphs for the specified cluster in the Rancher UI. This is done by granting Read-only access to external Monitoring UIs. Users with this role have permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Alertmanager, and Grafana UIs through the Rancher proxy. <br/> <br/> This role doesn't grant access to monitoring endpoints. As a result, users with this role won't be able to view cluster monitoring graphs and dashboards in the Rancher UI; however, they are able to access the monitoring Grafana, Prometheus, and Alertmanager UIs if provided those links. |
|
||||
|
||||
:::note
|
||||
|
||||
@@ -216,7 +216,11 @@ In addition to these default roles, the following Rancher project roles can be a
|
||||
|--------------------------|-------------------------------|-------|------|
|
||||
| View Monitoring* | [monitoring-ui-view](#additional-monitoring-clusterroles) | 2.4.8+ | 9.4.204+ |
|
||||
|
||||
\* A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project.
|
||||
:::note
|
||||
|
||||
A user bound to the **View Monitoring** Rancher role and read-only project permissions can't view links in the Monitoring UI. They can still access external monitoring UIs if provided links to those UIs. If you wish to grant access to users with the **View Monitoring** role and read-only project permissions, move the `cattle-monitoring-system` namespace into the project.
|
||||
|
||||
:::
|
||||
|
||||
### Differences in 2.5.x
|
||||
|
||||
|
||||
@@ -6,6 +6,8 @@ title: OPA Gatekeeper
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/opa-gatekeeper"/>
|
||||
</head>
|
||||
|
||||
<DeprecationOPAGatekeeper link="kubewarden" />
|
||||
|
||||
To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.
|
||||
|
||||
OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.
|
||||
|
||||
@@ -68,18 +68,24 @@ The following commands are available for use in Rancher CLI.
|
||||
| `catalog` | Performs operations on [catalogs](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md). |
|
||||
| `clusters, [cluster]` | Performs operations on your [clusters](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/kubernetes-clusters-in-rancher-setup.md). |
|
||||
| `context` | Switches between Rancher [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). For an example, see [Project Selection](#project-selection). |
|
||||
| `globaldns` | Performs operations on global DNS providers and entries. |
|
||||
| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]` | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) and [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md)). Specify resources by name or ID. |
|
||||
| `kubectl` |Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `kubectl` | Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
|
||||
| `login, [l]` | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication). |
|
||||
| `namespaces, [namespace]` |Performs operations on namespaces. |
|
||||
| `nodes, [node]` |Performs operations on nodes. |
|
||||
| `machines, [machine]` | Performs operations on machines. |
|
||||
| `multiclusterapps, [multiclusterapp mcapps mcapp]` | Performs operations with multi-cluster apps. |
|
||||
| `namespaces, [namespace]` | Performs operations on [namespaces](../../how-to-guides/new-user-guides/manage-namespaces.md). |
|
||||
| `nodes, [node]` | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md). |
|
||||
| `projects, [project]` | Performs operations on [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). |
|
||||
| `ps` | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project. |
|
||||
| `server` | Performs operations for the server. |
|
||||
| `settings, [setting]` | Shows the current settings for your Rancher Server. |
|
||||
| `ssh` | Connects to one of your cluster nodes using the SSH protocol. |
|
||||
| `up` | Applies compose config. |
|
||||
| `wait` | Waits for resources cluster, app, project, multiClusterApp. |
|
||||
| `token` | Authenticates and generates new kubeconfig token. |
|
||||
| `help, [h]` | Shows a list of commands or help for one command. |
|
||||
|
||||
|
||||
### Rancher CLI Help
|
||||
|
||||
Once logged into Rancher Server using the CLI, enter `./rancher --help` for a list of commands.
|
||||
|
||||
+11
-17
@@ -24,8 +24,6 @@ This section assumes familiarity with how monitoring components work together. F
|
||||
|
||||
:::
|
||||
|
||||
To create notification receivers in the Rancher UI,
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.6.5+">
|
||||
|
||||
@@ -152,24 +150,20 @@ The Teams receiver is not a native receiver and must be enabled before it can be
|
||||
1. Select the **Teams** option and click **Install**.
|
||||
1. Take note of the namespace used as it will be required in a later step.
|
||||
|
||||
### Configure the Teams Receiver
|
||||
### Configuring the Teams Receiver
|
||||
|
||||
The Teams receiver can be configured by updating its ConfigMap. For example, the following is a minimal Teams receiver configuration.
|
||||
1. To configure the Teams receiver, update its ConfigMap. The following example is a minimal Teams receiver configuration:
|
||||
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
teams-instance-1: https://your-teams-webhook-url
|
||||
```
|
||||
```yaml
|
||||
[Microsoft Teams]
|
||||
connector: https://your-teams-webhook-url
|
||||
```
|
||||
|
||||
When configuration is complete, add the receiver using the steps in [this section](#creating-receivers-in-the-rancher-ui).
|
||||
2. After you update the configuration, follow the instructions in [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui) to add the receiver. Use the example below to form your URL. Make sure to replace `<namespace>` with the namespace of the `rancher-alerting-drivers` app:
|
||||
|
||||
Use the example below as the URL where:
|
||||
|
||||
- `ns-1` is replaced with the namespace where the `rancher-alerting-drivers` app is installed
|
||||
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance-1
|
||||
```
|
||||
```yaml
|
||||
url: http://rancher-alerting-drivers-prom2teams.<namespace>.svc:8089/v2/connector
|
||||
```
|
||||
|
||||
<!-- https://github.com/idealista/prom2teams -->
|
||||
|
||||
@@ -187,7 +181,7 @@ The SMS receiver is not a native receiver and must be enabled before it can be u
|
||||
1. Select the **SMS** option and click **Install**.
|
||||
1. Take note of the namespace used as it will be required in a later step.
|
||||
|
||||
### Configure the SMS Receiver
|
||||
### Configuring the SMS Receiver
|
||||
|
||||
The SMS receiver can be configured by updating its ConfigMap. For example, the following is a minimal SMS receiver configuration.
|
||||
|
||||
|
||||
@@ -41,8 +41,11 @@ For more information, refer to the monitoring documentation [here.](../integrati
|
||||
Rancher's integration with Istio was improved in Rancher v2.5.
|
||||
|
||||
For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md)
|
||||
|
||||
## OPA Gatekeeper
|
||||
|
||||
<DeprecationOPAGatekeeper link="../integrations-in-rancher/kubewarden" />
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../integrations-in-rancher/opa-gatekeeper.md)
|
||||
|
||||
## CIS Scans
|
||||
|
||||
@@ -9,7 +9,8 @@ title: Rancher Webhook
|
||||
Rancher-Webhook is an essential component of Rancher that works in conjunction with Kubernetes to enhance security and enable critical features for Rancher-managed clusters.
|
||||
|
||||
It integrates with Kubernetes' extensible admission controllers, as described in the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), which allows Rancher-Webhook to inspect specific requests sent to the Kubernetes API server, and add custom, Rancher-specific validation and mutations to the requests that are specific to Rancher. Rancher-Webhook manages the resources to be validated using the `rancher.cattle.io` `ValidatingWebhookConfiguration` and the `rancher.cattle.io` `MutatingWebhookConfiguration`, and will override any manual edits.
|
||||
Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release.
|
||||
|
||||
Rancher deploys Rancher-Webhook as a separate deployment and service in both local and downstream clusters. Rancher manages Rancher-Webhook using Helm. It's important to note that Rancher may override modifications made by users to the Helm release. To safely modify these values see [Customizing Rancher-Webhook Configuration](#customizing-rancher-webhook-configuration).
|
||||
|
||||
Each Rancher version is designed to be compatible with a single version of the webhook. The compatible versions are provided below for convenience.
|
||||
|
||||
@@ -17,11 +18,11 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
<!-- releaseTask -->
|
||||
|
||||
| Rancher Version | Webhook Version |
|
||||
|-----------------|:---------------:|
|
||||
| v2.8.0 | v0.4.2 |
|
||||
| v2.8.1 | v0.4.2 |
|
||||
| v2.8.2 | v0.4.2 |
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.0 | v0.4.2 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
@@ -49,6 +50,39 @@ To bypass the webhook, impersonate both the `rancher-webhook-sudo` service accou
|
||||
kubectl create -f example.yaml --as=system:serviceaccount:cattle-system:rancher-webhook-sudo --as-group=system:masters
|
||||
```
|
||||
|
||||
## Customizing Rancher-Webhook Configuration
|
||||
|
||||
You can add custom Helm values when you install Rancher-Webhook via Helm. During a Helm install of the Rancher-Webhook chart, Rancher checks for custom Helm values. These custom values must be defined in a ConfigMap named `rancher-config`, in the `cattle-system` namespace, under the data key, `rancher-webhook`. The value of this key must be valid YAML.
|
||||
|
||||
``` yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: rancher-config
|
||||
namespace: cattle-system
|
||||
labels:
|
||||
app.kubernetes.io/part-of: "rancher"
|
||||
data:
|
||||
rancher-webhook: '{"port": 9553, "priorityClassName": "system-node-critical"}'
|
||||
|
||||
```
|
||||
|
||||
Rancher redeploys the Rancher-Webhook chart when changes to the ConfigMap values are detected.
|
||||
|
||||
### Customizing Rancher-Webhook During Rancher Installation
|
||||
|
||||
When you use Helm to install the Rancher chart, you can add custom Helm values to the Rancher-Webhook of the local cluster. All values in the Rancher-Webhook chart are accessible as nested variables under the `webhook` name.
|
||||
|
||||
These values are synced to the `rancher-config` ConfigMap during installation.
|
||||
|
||||
```bash
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
...
|
||||
--set webhook.port=9553 \
|
||||
--set webhook.priorityClassName="system-node-critical"
|
||||
```
|
||||
|
||||
## Common Issues
|
||||
|
||||
### EKS Cluster with Calico CNI
|
||||
|
||||
@@ -1,19 +1,18 @@
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------- |
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9100 | Default port required by Monitoring to scrape metrics from Linux node-exporters |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
| Protocol | Port | Description |
|
||||
|:--------: |:----------------: |---------------------------------------------------------------------------------------------|
|
||||
| TCP | 22 | Node driver SSH provisioning |
|
||||
| TCP | 179 | Calico BGP Port |
|
||||
| TCP | 2376 | Node driver Docker daemon TLS port |
|
||||
| TCP | 2379 | etcd client requests |
|
||||
| TCP | 2380 | etcd peer communication |
|
||||
| UDP | 8472 | Canal/Flannel VXLAN overlay networking |
|
||||
| UDP | 4789 | Flannel VXLAN overlay networking on Windows cluster |
|
||||
| TCP | 8443 | Rancher webhook |
|
||||
| TCP | 9099 | Canal/Flannel livenessProbe/readinessProbe |
|
||||
| TCP | 9443 | Rancher webhook |
|
||||
| TCP | 9796 | Default port required by Monitoring to scrape metrics from Linux and Windows node-exporters |
|
||||
| TCP | 6783 | Weave Port |
|
||||
| UDP | 6783-6784 | Weave UDP Ports |
|
||||
| TCP | 10250 | Metrics server communication with all nodes API |
|
||||
| TCP | 10254 | Ingress controller livenessProbe/readinessProbe |
|
||||
| TCP/UDP | 30000-32767 | NodePort port range |
|
||||
|
||||
Reference in New Issue
Block a user