mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
resolving merging conflict
This commit is contained in:
martyav
@@ -96,7 +96,7 @@ Kubernetes workers should open TCP port `6783` (control port), UDP port `6783` a
|
||||
|
||||
For more information, see the following pages:
|
||||
|
||||
- [Weave Net Official Site](https://www.weave.works/)
|
||||
- [Weave Net Official Site](https://github.com/weaveworks/weave/blob/master/site/overview.md)
|
||||
|
||||
### RKE2 Kubernetes clusters
|
||||
|
||||
|
||||
@@ -16,6 +16,7 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.8.4](https://github.com/rancher/rancher/releases/tag/v2.8.4) | May 16, 2024 |
|
||||
| [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | Mar 28, 2024 |
|
||||
| [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | Feb 8, 2024 |
|
||||
| [2.8.1](https://github.com/rancher/rancher/releases/tag/v2.8.1) | Jan 22, 2024 |
|
||||
|
||||
@@ -10,10 +10,6 @@ This FAQ is a work in progress designed to answer the questions most frequently
|
||||
|
||||
See the [Technical FAQ](technical-items.md) for frequently asked technical questions.
|
||||
|
||||
## Does Rancher v2.x support Docker Swarm and Mesos as environment types?
|
||||
|
||||
Swarm and Mesos are no longer selectable options when you create a new environment in Rancher v2.x. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 were running Swarm.
|
||||
|
||||
## Is it possible to manage Azure Kubernetes Services with Rancher v2.x?
|
||||
|
||||
Yes. See our [Cluster Administration](../how-to-guides/new-user-guides/manage-clusters/manage-clusters.md) guide for what Rancher features are available on AKS, as well as our [documentation on AKS](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md).
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Glossary
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/glossary"/>
|
||||
</head>
|
||||
|
||||
This page covers Rancher-specific terminology and symbols which might be unfamiliar, or which differ between Rancher versions.
|
||||
|
||||
```mdx-code-block
|
||||
import Glossary, {toc as GlossaryTOC} from "/shared-files/_glossary.md"
|
||||
|
||||
<Glossary />
|
||||
|
||||
export const toc = GlossaryTOC;
|
||||
```
|
||||
+115
-9
@@ -14,20 +14,46 @@ For configuration details, refer to the [official Kubernetes documentation](http
|
||||
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2/K3s" default>
|
||||
<TabItem value="RKE2" default>
|
||||
|
||||
### Method 1 (Recommended): Set `audit-policy-file` in `machineGlobalConfig`
|
||||
|
||||
You can set `audit-policy-file` in the configuration file. Rancher delivers the file to the path `/var/lib/rancher/rke2/etc/config-files/audit-policy-file` in control plane nodes, and sets the proper options in the RKE2 server.
|
||||
|
||||
Example:
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
audit-policy-file: |
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: RequestResponse
|
||||
resources:
|
||||
- group: ""
|
||||
resources:
|
||||
- pods
|
||||
```
|
||||
|
||||
### Method 2: Use the Directives, `machineSelectorFiles` and `machineGlobalConfig`
|
||||
|
||||
:::note
|
||||
|
||||
This feature is available in Rancher v2.7.2 and above.
|
||||
This feature is available in Rancher v2.7.2 and later.
|
||||
|
||||
:::
|
||||
|
||||
As a prerequisite, you need to create a secret or configmap which will be the source of the audit policy.
|
||||
You can use `machineSelectorFiles` to deliver the audit policy file to the control plane nodes, and `machineGlobalConfig` to set the options on kube-apiserver.
|
||||
|
||||
The secret or configmap must meet the following two requirements:
|
||||
As a prerequisite, you must create a [secret](../new-user-guides/kubernetes-resources-setup/secrets.md) or [configmap](../new-user-guides/kubernetes-resources-setup/configmaps.md) to be the source of the audit policy.
|
||||
|
||||
The secret or configmap must meet the following requirements:
|
||||
|
||||
1. It must be in the `fleet-default` namespace where the Cluster object exists.
|
||||
2. It must have the annotation `rke.cattle.io/object-authorized-for-clusters: cluster-name1,cluster-name2` which permits the target clusters to use it.
|
||||
2. It must have the annotation `rke.cattle.io/object-authorized-for-clusters: <cluster-name1>,<cluster-name2>` which permits the target clusters to use it.
|
||||
|
||||
:::tip
|
||||
|
||||
@@ -46,11 +72,11 @@ kind: Secret
|
||||
metadata:
|
||||
annotations:
|
||||
rke.cattle.io/object-authorized-for-clusters: cluster1
|
||||
name: name1
|
||||
name: <name1>
|
||||
namespace: fleet-default
|
||||
```
|
||||
|
||||
The audit log can be enabled and configured by editing the cluster in YAML and utilizing the `machineSelectorFiles` and `machineGlobalConfig` directives.
|
||||
Enable and configure the audit log by editing the cluster in YAML, and utilizing the `machineSelectorFiles` and `machineGlobalConfig` directives.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -77,7 +103,88 @@ spec:
|
||||
rke.cattle.io/control-plane-role: 'true'
|
||||
```
|
||||
|
||||
For more information about cluster configuration, refer to the REK2 or K3s cluster configuration reference pages.
|
||||
:::tip
|
||||
|
||||
You can also use the directive `machineSelectorConfig` with proper machineLabelSelectors to achieve the same effect.
|
||||
|
||||
:::
|
||||
|
||||
For more information about cluster configuration, refer to the [RKE2 cluster configuration reference](../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md) pages.
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="K3s">
|
||||
|
||||
:::note
|
||||
|
||||
This feature is available in Rancher v2.7.2 and later.
|
||||
|
||||
:::
|
||||
|
||||
You can use `machineSelectorFiles` to deliver the audit policy file to the control plane nodes, and `machineGlobalConfig` to set the options on kube-apiserver.
|
||||
|
||||
As a prerequisite, you must create a [secret](../new-user-guides/kubernetes-resources-setup/secrets.md) or [configmap](../new-user-guides/kubernetes-resources-setup/configmaps.md) to be the source of the audit policy.
|
||||
|
||||
The secret or configmap must meet the following requirements:
|
||||
|
||||
1. It must be in the `fleet-default` namespace where the Cluster object exists.
|
||||
2. It must have the annotation `rke.cattle.io/object-authorized-for-clusters: <cluster-name1>,<cluster-name2>` which permits the target clusters to use it.
|
||||
|
||||
:::tip
|
||||
|
||||
Rancher Dashboard provides an easy-to-use form for creating the [secret](../new-user-guides/kubernetes-resources-setup/secrets.md) or [configmap](../new-user-guides/kubernetes-resources-setup/configmaps.md).
|
||||
|
||||
:::
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
audit-policy: >-
|
||||
IyBMb2cgYWxsIHJlcXVlc3RzIGF0IHRoZSBNZXRhZGF0YSBsZXZlbC4KYXBpVmVyc2lvbjogYXVkaXQuazhzLmlvL3YxCmtpbmQ6IFBvbGljeQpydWxlczoKLSBsZXZlbDogTWV0YWRhdGE=
|
||||
kind: Secret
|
||||
metadata:
|
||||
annotations:
|
||||
rke.cattle.io/object-authorized-for-clusters: cluster1
|
||||
name: <name1>
|
||||
namespace: fleet-default
|
||||
```
|
||||
|
||||
Enable and configure the audit log by editing the cluster in YAML, and utilizing the `machineSelectorFiles` and `machineGlobalConfig` directives.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=<customized-path>/dev-audit-policy.yaml
|
||||
- audit-log-path=<customized-path>/dev-audit.logs
|
||||
machineSelectorFiles:
|
||||
- fileSources:
|
||||
- configMap:
|
||||
name: ''
|
||||
secret:
|
||||
items:
|
||||
- key: audit-policy
|
||||
path: <customized-path>/dev-audit-policy.yaml
|
||||
name: dev-audit-policy
|
||||
machineLabelSelector:
|
||||
matchLabels:
|
||||
rke.cattle.io/control-plane-role: 'true'
|
||||
```
|
||||
|
||||
:::tip
|
||||
|
||||
You can also use the directive `machineSelectorConfig` with proper machineLabelSelectors to achieve the same effect.
|
||||
|
||||
:::
|
||||
|
||||
For more information about cluster configuration, refer to the [K3s cluster configuration reference](../../reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md) pages.
|
||||
|
||||
</TabItem>
|
||||
|
||||
@@ -139,4 +246,3 @@ For configuration details, refer to the official [RKE1 documentation](https://rk
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
+6
-6
@@ -36,12 +36,12 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#api-audit-log-options) setting.
|
||||
|
||||
| `AUDIT_LEVEL` Setting | Request Metadata | Request Body | Response Metadata | Response Body |
|
||||
| --------------------- | ---------------- | ------------ | ----------------- | ------------- |
|
||||
| `0` | | | | |
|
||||
| `1` | ✓ | | | |
|
||||
| `2` | ✓ | ✓ | | |
|
||||
| `3` | ✓ | ✓ | ✓ | ✓ |
|
||||
| `AUDIT_LEVEL` Setting | Metadata | Request Body | Response Body |
|
||||
| --------------------- | -------- | ------------ | ------------- |
|
||||
| `0` | | | |
|
||||
| `1` | ✓ | | |
|
||||
| `2` | ✓ | ✓ | |
|
||||
| `3` | ✓ | ✓ | ✓ |
|
||||
|
||||
## Viewing API Audit Logs
|
||||
|
||||
|
||||
+76
@@ -77,3 +77,79 @@ key.pfx=`base64-content`
|
||||
```
|
||||
|
||||
Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`.
|
||||
|
||||
## Rancher Performance Dashboard
|
||||
|
||||
When monitoring is installed on the upstream (local) cluster, you are given basic health metrics about the Rancher pods, such as CPU and memory data. To get advanced metrics for your local Rancher server, you must additionally enable the Rancher Performance Dashboard for Grafana.
|
||||
|
||||
This dashboard provides access to the following advanced metrics:
|
||||
|
||||
- Handler Average Execution Times Over Last 5 Minutes
|
||||
- Rancher API Average Request Times Over Last 5 Minutes
|
||||
- Subscribe Average Request Times Over Last 5 Minutes
|
||||
- Lasso Controller Work Queue Depth (Top 20)
|
||||
- Number of Rancher Requests (Top 20)
|
||||
- Number of Failed Rancher API Requests (Top 20)
|
||||
- K8s Proxy Store Average Request Times Over Last 5 Minutes (Top 20)
|
||||
- K8s Proxy Client Average Request Times Over Last 5 Minutes (Top 20)
|
||||
- Cached Objects by GroupVersionKind (Top 20)
|
||||
- Lasso Handler Executions (Top 20)
|
||||
- Handler Executions Over Last 2 Minutes (Top 20)
|
||||
- Total Handler Executions with Error (Top 20)
|
||||
- Data Transmitted by Remote Dialer Sessions (Top 20)
|
||||
- Errors for Remote Dialer Sessions (Top 20)
|
||||
- Remote Dialer Connections Removed (Top 20)
|
||||
- Remote Dialer Connections Added by Client (Top 20)
|
||||
|
||||
:::note
|
||||
|
||||
Profiling data (such as advanced memory or CPU analysis) is not present as it is a very context-dependent technique that's meant for debugging and not intended for normal observation.
|
||||
|
||||
:::
|
||||
|
||||
### Enabling the Rancher Performance Dashboard
|
||||
|
||||
To enable the Rancher Performance Dashboard:
|
||||
|
||||
<Tabs groupid="UIorCLI">
|
||||
<TabItem value="Helm">
|
||||
|
||||
Use the following options with the Helm CLI:
|
||||
|
||||
```bash
|
||||
--set extraEnv\[0\].name="CATTLE_PROMETHEUS_METRICS" --set-string extraEnv\[0\].value=true
|
||||
```
|
||||
|
||||
You can also include the following snippet in your Rancher Helm chart's values.yaml file:
|
||||
|
||||
```yaml
|
||||
extraEnv:
|
||||
- name: "CATTLE_PROMETHEUS_METRICS"
|
||||
value: "true"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="UI">
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the row of the `local` cluster and click **Explore**.
|
||||
1. Click **Workloads > Deployments**.
|
||||
1. Use the dropdown menu at the top to filter for **All Namespaces**.
|
||||
1. Under the `cattle-system` namespace, go to the `rancher` row and click **⋮ > Edit Config**
|
||||
1. Under **Environment Variables**, click **Add Variable**.
|
||||
1. For **Type**, select `Key/Value Pair`.
|
||||
1. For **Variable Name**, enter `CATTLE_PROMETHEUS_METRICS`.
|
||||
1. For **Value**, enter `true`.
|
||||
1. Click **Save** to apply the change.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Accessing the Rancher Performance Dashboard
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the row of the `local` cluster and click **Explore**.
|
||||
1. Click **Monitoring**
|
||||
1. Select the **Grafana** dashboard.
|
||||
1. From the sidebar, click **Search dashboards**.
|
||||
1. Enter `Rancher Performance Debugging` and select it.
|
||||
|
||||
+11
-1
@@ -6,7 +6,17 @@ title: Opening Ports with firewalld
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/open-ports-with-firewalld"/>
|
||||
</head>
|
||||
|
||||
> We recommend disabling firewalld. For Kubernetes 1.19.x and higher, firewalld must be turned off.
|
||||
:::danger
|
||||
|
||||
Enabling firewalld can cause serious network communication problems.
|
||||
|
||||
For proper network function, firewalld must be disabled on systems running RKE2. [Firewalld conflicts with Canal](https://docs.rke2.io/known_issues#firewalld-conflicts-with-default-networking), RKE2's default networking stack.
|
||||
|
||||
Firewalld must also be disabled on systems running Kubernetes 1.19 and later.
|
||||
|
||||
If you enable firewalld on systems running Kubernetes 1.18 or earlier, understand that this may cause networking issues. CNIs in Kubernetes dynamically update iptables and networking rules independently of any external firewalls, such as firewalld. This can cause unexpected behavior when the CNI and the external firewall conflict.
|
||||
|
||||
:::
|
||||
|
||||
Some distributions of Linux [derived from RHEL,](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds) including Oracle Linux, may have default firewall rules that block communication with Helm.
|
||||
|
||||
|
||||
+3
-1
@@ -56,4 +56,6 @@ If you want to use a node driver that Rancher doesn't support out-of-the-box, yo
|
||||
|
||||
### Developing Your Own Node Drivers
|
||||
|
||||
Node drivers are implemented with [Docker Machine](https://docs.docker.com/machine/).
|
||||
Node drivers are implemented with [Rancher Machine](https://github.com/rancher/machine), a fork of [Docker Machine](https://github.com/docker/machine). Docker Machine is no longer under active development.
|
||||
|
||||
Refer to the original [Docker Machine documentation](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) for details on how to develop your own node drivers.
|
||||
|
||||
-1
@@ -51,7 +51,6 @@ You can integrate Okta with Rancher, so that authenticated users can access Ranc
|
||||
|
||||
:::
|
||||
|
||||
|
||||
1. After you complete the **Configure Okta Account** form, click **Enable**.
|
||||
|
||||
Rancher redirects you to the IdP login page. Enter credentials that authenticate with Okta IdP to validate your Rancher Okta configuration.
|
||||
|
||||
+16
-3
@@ -79,15 +79,20 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
|
||||
1. In the **Clusters** page, go to the cluster where you want to remove nodes.
|
||||
1. In the **Machines** tab, click **⋮ > Delete** on each node you want to delete. Initially, you will see the nodes hang in a `deleting` state, but once all etcd nodes are deleting, they will be removed together. This is due to the fact that Rancher sees all etcd nodes deleting and proceeds to "short circuit" the etcd safe-removal logic.
|
||||
|
||||
1. After all etcd nodes are removed, add a new etcd node that you are planning to restore from.
|
||||
1. After all etcd nodes are removed, add the new etcd node that you are planning to restore from. Assign the new node the role of `all` (etcd, controlplane, and worker).
|
||||
|
||||
- For custom clusters, go to the **Registration** tab then copy and run the registration command on your node. If the node has previously been used in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
|
||||
- If the node was previously in a cluster, [clean the node](../manage-clusters/clean-cluster-nodes.md#cleaning-up-nodes) first.
|
||||
- For custom clusters, go to the **Registration** tab and check the box for `etcd, controlplane, and worker`. Then copy and run the registration command on your node.
|
||||
- For node driver clusters, a new node is provisioned automatically.
|
||||
|
||||
At this point, Rancher will indicate that restoration from etcd snapshot is required.
|
||||
|
||||
1. Restore from an etcd snapshot.
|
||||
|
||||
:::note
|
||||
As the etcd node is a clean node, you may need to manually create the `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/` path.
|
||||
:::
|
||||
|
||||
- For S3 snapshots, restore using the UI.
|
||||
1. Click the **Snapshots** tab to view the list of saved snapshots.
|
||||
1. Go to the snapshot you want to restore and click **⋮ > Restore**.
|
||||
@@ -95,7 +100,15 @@ If you are using [local snapshots](./back-up-rancher-launched-kubernetes-cluster
|
||||
1. Click **Restore**.
|
||||
- For local snapshots, restore using the UI is **not** available.
|
||||
1. In the upper right corner, click **⋮ > Edit YAML**.
|
||||
1. Define `spec.cluster.rkeConfig.etcdSnapshotRestore.name` as the filename of the snapshot on disk in `/var/lib/rancher/<k3s/rke2>/server/db/snapshots/`.
|
||||
1. The example YAML below can be added under your `rkeConfig` to configure the etcd restore:
|
||||
|
||||
```yaml
|
||||
...
|
||||
rkeConfig:
|
||||
etcdSnapshotRestore:
|
||||
name: <string> # This field is required. Refers to the filename of the associated etcdsnapshot object.
|
||||
...
|
||||
```
|
||||
|
||||
1. After restoration is successful, you can scale your etcd nodes back up to the desired redundancy.
|
||||
|
||||
|
||||
+17
@@ -166,6 +166,23 @@ spec:
|
||||
|
||||
Only Helm 3 compatible charts are supported.
|
||||
|
||||
### Refresh Chart Repositories
|
||||
|
||||
The **Refresh** button can be used to sync changes from selected Helm chart repositories on the **Repositories** page.
|
||||
|
||||
To refresh a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Use the toggle next to the **State** field to select all repositories, or toggle specified chart repositories to sync changes.
|
||||
1. Click **Refresh**.
|
||||
1. The **⋮** at the end of each chart repository row also includes a **Refresh** option, which can be clicked to refresh the respective repository.
|
||||
|
||||
Non-Airgap Rancher installations upon refresh will reflect any chart repository changes immediately and you will see the **State** field for updated repositories move from `In Progress` to `Active` once the action is completed.
|
||||
|
||||
Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
To install and deploy a chart:
|
||||
|
||||
+20
-36
@@ -21,65 +21,48 @@ To interact with Azure APIs, an AKS cluster requires an Azure Active Directory (
|
||||
Before creating the service principal, you need to obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com):
|
||||
|
||||
- Subscription ID
|
||||
- Client ID
|
||||
- Client ID (also known as app ID)
|
||||
- Client secret
|
||||
|
||||
The below sections describe how to set up these prerequisites using either the Azure command line tool or the Azure portal.
|
||||
|
||||
### Setting Up the Service Principal with the Azure Command Line Tool
|
||||
|
||||
You can create the service principal by running this command:
|
||||
You must assign roles to the service principal so that it has communication privileges with the AKS API. It also needs access to create and list virtual networks.
|
||||
|
||||
In the following example, the command creates the service principal and gives it the Contributor role. The Contributor role can manage anything on AKS but cannot give access to others. Note that you must provide `scopes` a full path to at least one Azure resource:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac --skip-assignment
|
||||
az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>
|
||||
```
|
||||
|
||||
The result should show information about the new service principal:
|
||||
|
||||
```
|
||||
{
|
||||
"appId": "xxxx--xxx",
|
||||
"displayName": "<SERVICE-PRINCIPAL-NAME>",
|
||||
"name": "http://<SERVICE-PRINCIPAL-NAME>",
|
||||
"password": "<SECRET>",
|
||||
"tenant": "<TENANT NAME>"
|
||||
"displayName": "<service-principal-name>",
|
||||
"name": "http://<service-principal-name>",
|
||||
"password": "<secret>",
|
||||
"tenant": "<tenant-name>"
|
||||
}
|
||||
```
|
||||
|
||||
You also need to add roles to the service principal so that it has privileges for communication with the AKS API. It also needs access to create and list virtual networks.
|
||||
|
||||
Below is an example command for assigning the Contributor role to a service principal. Contributors can manage anything on AKS but cannot give access to others:
|
||||
The following creates a [Resource Group](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-cli) to contain your Azure resources:
|
||||
|
||||
```
|
||||
az role assignment create \
|
||||
--assignee $appId \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
You can also create the service principal and give it Contributor privileges by combining the two commands into one. In this command, the scope needs to provide a full path to an Azure resource:
|
||||
|
||||
```
|
||||
az ad sp create-for-rbac \
|
||||
--scope /subscriptions/$<SUBSCRIPTION-ID>/resourceGroups/$<GROUP> \
|
||||
--role Contributor
|
||||
```
|
||||
|
||||
Create the Resource Group by running this command:
|
||||
|
||||
```
|
||||
az group create --location AZURE_LOCATION_NAME --resource-group AZURE_RESOURCE_GROUP_NAME
|
||||
az group create --location <azure-location-name> --resource-group <resource-group-name>
|
||||
```
|
||||
|
||||
### Setting Up the Service Principal from the Azure Portal
|
||||
|
||||
You can also follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
|
||||
Follow these instructions to set up a service principal and give it role-based access from the Azure Portal.
|
||||
|
||||
1. Go to the Microsoft Azure Portal [home page](https://portal.azure.com).
|
||||
|
||||
1. Click **Azure Active Directory**.
|
||||
1. Click **App registrations**.
|
||||
1. Click **New registration**.
|
||||
1. Enter a name. This will be the name of your service principal.
|
||||
1. Enter a name for your service principal.
|
||||
1. Optional: Choose which accounts can use the service principal.
|
||||
1. Click **Register**.
|
||||
1. You should now see the name of your service principal under **Azure Active Directory > App registrations**.
|
||||
@@ -101,7 +84,7 @@ To give role-based access to your service principal,
|
||||
|
||||
**Result:** Your service principal now has access to AKS.
|
||||
|
||||
## 1. Create the AKS Cloud Credentials
|
||||
## Create the AKS Cloud Credentials
|
||||
|
||||
1. In the Rancher UI, click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
@@ -110,7 +93,7 @@ To give role-based access to your service principal,
|
||||
1. Fill out the form. For help with filling out the form, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md#cloud-credentials)
|
||||
1. Click **Create**.
|
||||
|
||||
## 2. Create the AKS Cluster
|
||||
## Create the AKS Cluster
|
||||
|
||||
Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
@@ -124,7 +107,8 @@ Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
## Role-based Access Control
|
||||
## Configure Role-based Access Control
|
||||
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled.
|
||||
|
||||
RBAC is required for AKS clusters that are registered or imported into Rancher.
|
||||
@@ -135,8 +119,8 @@ Assign the Rancher AKSv2 role to the service principal with the Azure Command Li
|
||||
|
||||
```
|
||||
az role assignment create \
|
||||
--assignee CLIENT_ID \
|
||||
--scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME" \
|
||||
--assignee <client-id> \
|
||||
--scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>" \
|
||||
--role "Rancher AKSv2"
|
||||
```
|
||||
|
||||
|
||||
+2
-2
@@ -70,7 +70,7 @@ StatefulSets manage the deployment and scaling of Pods while maintaining a stick
|
||||
1. Click **StatefulSet**.
|
||||
1. In the **Volume Claim Templates** tab, click **Add Claim Template**.
|
||||
1. Enter a name for the persistent volume.
|
||||
1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Launch**.
|
||||
|
||||
@@ -84,7 +84,7 @@ To attach the PVC to an existing workload,
|
||||
1. Go to the workload that will use storage provisioned with the StorageClass that you cared at click **⋮ > Edit Config**.
|
||||
1. In the **Volume Claim Templates** section, click **Add Claim Template**.
|
||||
1. Enter a persistent volume name.
|
||||
1. In the **StorageClass* field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **StorageClass** field, select the StorageClass that will dynamically provision storage for pods managed by this StatefulSet.
|
||||
1. In the **Mount Point** field, enter the path that the workload will use to access the volume.
|
||||
1. Click **Save**.
|
||||
|
||||
|
||||
+1
-1
@@ -304,7 +304,7 @@ cloud-provider|-|Cloud provider type|
|
||||
|max-node-provision-time|"15m"|Maximum time CA waits for node to be provisioned|
|
||||
|nodes|-|sets min,max size and other configuration data for a node group in a format accepted by cloud provider. Can be used multiple times. Format: `<min>:<max>:<other...>`|
|
||||
|node-group-auto-discovery|-|One or more definition(s) of node group auto-discovery. A definition is expressed `<name of discoverer>:[<key>[=<value>]]`|
|
||||
|estimator|-|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|
||||
|estimator|"binpacking"|Type of resource estimator to be used in scale up. Available values: ["binpacking"]|
|
||||
|expander|"random"|Type of node group expander to be used in scale up. Available values: `["random","most-pods","least-waste","price","priority"]`|
|
||||
|ignore-daemonsets-utilization|false|Should CA ignore DaemonSet pods when calculating resource utilization for scaling down|
|
||||
|ignore-mirror-pods-utilization|false|Should CA ignore Mirror pods when calculating resource utilization for scaling down|
|
||||
|
||||
+4
-3
@@ -19,10 +19,11 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:----------------:|
|
||||
| v2.8.0 | v103.0.0+up3.0.0 |
|
||||
| v2.8.1 | v103.0.0+up3.0.0 |
|
||||
| v2.8.2 | v103.0.0+up3.0.0 |
|
||||
| v2.8.4 | v103.0.1+up3.0.1 |
|
||||
| v2.8.3 | v103.0.1+up3.0.1 |
|
||||
| v2.8.2 | v103.0.0+up3.0.0 |
|
||||
| v2.8.1 | v103.0.0+up3.0.0 |
|
||||
| v2.8.0 | v103.0.0+up3.0.0 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
@@ -185,7 +185,7 @@ For detailed information on the values supported by the chart and their usage, r
|
||||
|
||||
:::note
|
||||
|
||||
Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/tasks/capi-operator/intro) in the Rancher Turtles documentation for assistance.
|
||||
Remember that if you opt for this installation option, you must manage the CAPI Operator installation yourself. You can follow the [CAPI Operator guide](https://turtles.docs.rancher.com/contributing/install_capi_operator) in the Rancher Turtles documentation for assistance.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+24
-1
@@ -49,7 +49,6 @@ This is typical in Rancher, as many operations create new `RoleBinding` objects
|
||||
|
||||
You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
|
||||
* Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) role. Apply other roles wherever possible.
|
||||
* If you use [external authentication](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md), use groups to assign roles.
|
||||
* Only add users to clusters and projects when necessary.
|
||||
* Remove clusters and projects when they are no longer needed.
|
||||
* Only use custom roles if necessary.
|
||||
@@ -59,6 +58,12 @@ You can reduce the number of `RoleBindings` in the upstream cluster in the follo
|
||||
* Kubernetes permissions are always "additive" (allow-list) rather than "subtractive" (deny-list). Try to minimize configurations that gives access to all but one aspect of a cluster, project, or namespace, as that will result in the creation of a high number of `RoleBinding` objects.
|
||||
* Experiment to see if creating new projects or clusters manifests in fewer `RoleBindings` for your specific use case.
|
||||
|
||||
### Using External Authentication
|
||||
|
||||
If you have fifty or more users, you should configure an [external authentication provider](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md). This is necessary for better performance.
|
||||
|
||||
After you configure external authentication, make sure to assign permissions to groups instead of to individual users. This helps reduce the `RoleBinding` object count.
|
||||
|
||||
### RoleBinding Count Estimation
|
||||
|
||||
Predicting how many `RoleBinding` objects a given configuration will create is complicated. However, the following considerations can offer a rough estimate:
|
||||
@@ -105,6 +110,14 @@ Although managed Kubernetes services make it easier to deploy and run Kubernetes
|
||||
|
||||
Use RKE2 for large scale use cases.
|
||||
|
||||
### Keep all Upstream Cluster Nodes co-located
|
||||
|
||||
To provide high availability, Kubernetes is designed to run nodes and control components in different zones. However, if nodes and control plane components are located in different zones, network traffic may be slower.
|
||||
|
||||
Traffic between Rancher components and the Kubernetes API is especially sensitive to network latency, as is etcd traffic between nodes.
|
||||
|
||||
To improve performance, run all upstream node clusters in the same location. In particular, make sure that latency between etcd nodes and Rancher is as low as possible.
|
||||
|
||||
### Keeping Kubernetes Versions Up to Date
|
||||
|
||||
You should keep the local Kubernetes cluster up to date. This will ensure that your cluster has all available performance enhancements and bug fixes.
|
||||
@@ -118,3 +131,13 @@ The two main bottlenecks to [etcd performance](https://etcd.io/docs/v3.4/op-guid
|
||||
It's best to run etcd on exactly three nodes, as adding more nodes will reduce operation speed. This may be counter-intuitive to common scaling approaches, but it's due to etcd's [replication mechanisms](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size).
|
||||
|
||||
Etcd performance will also be negatively affected by network latency between nodes as that will slow down network communication. Etcd nodes should be located together with Rancher nodes.
|
||||
|
||||
### Browser Requirements
|
||||
|
||||
At high scale, Rancher transfers more data from the upstream cluster to UI components running in the browser, and those components also need to perform more processing.
|
||||
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
+3
-3
@@ -149,13 +149,13 @@ Project network isolation is available if you are using any RKE2 network plugin
|
||||
|
||||
##### CoreDNS
|
||||
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#coredns) for additional CoreDNS configurations.
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#coredns) for additional CoreDNS configurations.
|
||||
|
||||
##### NGINX Ingress
|
||||
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking/networking_services#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
##### Metrics Server
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ Logging is helpful because it allows you to:
|
||||
- Look for trends in your environment
|
||||
- Save your logs to a safe location outside of your cluster
|
||||
- Stay informed of events like a container crashing, a pod eviction, or a node dying
|
||||
- More easily debugg and troubleshoot problems
|
||||
- More easily debug and troubleshoot problems
|
||||
|
||||
Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Logging is helpful because it allows you to:
|
||||
- Look for trends in your environment
|
||||
- Save your logs to a safe location outside of your cluster
|
||||
- Stay informed of events like a container crashing, a pod eviction, or a node dying
|
||||
- More easily debugg and troubleshoot problems
|
||||
- More easily debug and troubleshoot problems
|
||||
|
||||
Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
|
||||
|
||||
|
||||
+1
-1
@@ -102,7 +102,7 @@ The `rancher-restricted` template is provided by Rancher to enforce the highly-r
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 and Older">
|
||||
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
|
||||
K3s v1.24 and older support [Pod Security Policy (PSP)](https://github.com/kubernetes/website/blob/release-1.24/content/en/docs/concepts/security/pod-security-policy.md) for controlling pod security.
|
||||
|
||||
You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
|
||||
|
||||
|
||||
+1
-1
@@ -27,7 +27,7 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where a flaw with authorization logic allows privilege escalation in downstream clusters through cluster role template binding (CRTB) and project role template binding (PRTB). The vulnerability can be exploited by any user who has permissions to create/edit CRTB or PRTB (such as `cluster-owner`, `manage cluster members`, `project-owner`, and `manage project members`) to gain owner permission in another project in the same cluster or in another project on a different downstream cluster. | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | It was discovered that in Rancher versions up to and including 2.5.12 and 2.6.3, there is a failure to properly sanitize credentials in cluster template answers. This failure can lead to plaintext storage and exposure of credentials, passwords, and API tokens. The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners`, and `Project Members` on the endpoints `/v1/management.cattle.io.clusters`, `/v3/clusters`, and `/k8s/clusters/local/apis/management.cattle.io/v3/clusters`. | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where sensitive fields like passwords, API keys, and Rancher's service account token (used to provision clusters) were stored in plaintext directly on Kubernetes objects like `Clusters` (e.g., `cluster.management.cattle.io`). Anyone with read access to those objects in the Kubernetes API could retrieve the plaintext version of those sensitive data. The issue was partially found and reported by Florian Struck (from [Continum AG](https://www.continum.net/)) and [Marco Stuurman](https://github.com/fe-ax) (from [Shock Media B.V.](https://www.shockmedia.nl/)). | 18 August 2022 | [Rancher v2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) and [Rancher v2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | This vulnerability only affects customers using [Weave](../../faq/container-network-interface-providers.md#weave) Container Network Interface (CNI) when configured through [RKE templates](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/about-rke1-templates.md). A vulnerability was discovered in Rancher versions 2.5.0 up to and including 2.5.13, and 2.6.0 up to and including 2.6.4, where a user interface (UI) issue with RKE templates does not include a value for the Weave password when Weave is chosen as the CNI. If a cluster is created based on the mentioned template, and Weave is configured as the CNI, no password will be created for [network encryption](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/) in Weave; therefore, network traffic in the cluster will be sent unencrypted. | 24 May 2022 | [Rancher v2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) and [Rancher v2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | This vulnerability only affects customers using [Weave](../../faq/container-network-interface-providers.md#weave) Container Network Interface (CNI) when configured through [RKE templates](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/about-rke1-templates.md). A vulnerability was discovered in Rancher versions 2.5.0 up to and including 2.5.13, and 2.6.0 up to and including 2.6.4, where a user interface (UI) issue with RKE templates does not include a value for the Weave password when Weave is chosen as the CNI. If a cluster is created based on the mentioned template, and Weave is configured as the CNI, no password will be created for [network encryption](https://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md) in Weave; therefore, network traffic in the cluster will be sent unencrypted. | 24 May 2022 | [Rancher v2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) and [Rancher v2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 which allows users who have create or update permissions on [Global Roles](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md) to escalate their permissions, or those of another user, to admin-level permissions. Global Roles grant users Rancher-wide permissions, such as the ability to create clusters. In the identified versions of Rancher, when users are given permission to edit or create Global Roles, they are not restricted to only granting permissions which they already posses. This vulnerability affects customers who utilize non-admin users that are able to create or edit Global Roles. The most common use case for this scenario is the `restricted-admin` role. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-4200](https://github.com/rancher/rancher/security/advisories/GHSA-hx8w-ghh8-r4xf) | This vulnerability only affects customers using the `restricted-admin` role in Rancher. A vulnerability was discovered in Rancher versions from 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3 where the `global-data` role in `cattle-global-data` namespace grants write access to the Catalogs. Since each user with any level of catalog access was bound to the `global-data` role, this grants write access to templates (`CatalogTemplates`) and template versions (`CatalogTemplateVersions`) for any user with any level of catalog access. New users created in Rancher are by default assigned to the `user` role (standard user), which is not designed to grant write catalog access. This vulnerability effectively elevates the privilege of any user to write access for the catalog template and catalog template version resources. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | This vulnerability only affects customers using [Continuous Delivery with Fleet](../../integrations-in-rancher/fleet/fleet.md) for continuous delivery with authenticated Git and/or Helm repositories. An issue was discovered in `go-getter` library in versions prior to [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) that exposes SSH private keys in base64 format due to a failure in redacting such information from error messages. The vulnerable version of this library is used in Rancher through Fleet in versions of Fleet prior to [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9). This issue affects Rancher versions 2.5.0 up to and including 2.5.12 and from 2.6.0 up to and including 2.6.3. The issue was found and reported by Dagan Henderson from Raft Engineering. | 14 Apr 2022 | [Rancher v2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) and [Rancher v2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
|
||||
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.8.4 | v0.4.5 | ✓ | ✓ |
|
||||
| v2.8.3 | v0.4.3 | ✓ | ✓ |
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
|
||||
@@ -106,20 +106,3 @@ When the MTU is incorrectly configured (either on hosts running Rancher, nodes i
|
||||
* `read tcp: i/o timeout`
|
||||
|
||||
See [Google Cloud VPN: MTU Considerations](https://cloud.google.com/vpn/docs/concepts/mtu-considerations#gateway_mtu_vs_system_mtu) for an example how to configure MTU correctly when using Google Cloud VPN between Rancher and cluster nodes.
|
||||
|
||||
### Resolved issues
|
||||
|
||||
#### Overlay network broken when using Canal/Flannel due to missing node annotations
|
||||
|
||||
| | |
|
||||
|------------|------------|
|
||||
| GitHub issue | [#13644](https://github.com/rancher/rancher/issues/13644) |
|
||||
| Resolved in | v2.1.2 |
|
||||
|
||||
To check if your cluster is affected, the following command will list nodes that are broken (this command requires `jq` to be installed):
|
||||
|
||||
```
|
||||
kubectl get nodes -o json | jq '.items[].metadata | select(.annotations["flannel.alpha.coreos.com/public-ip"] == null or .annotations["flannel.alpha.coreos.com/kube-subnet-manager"] == null or .annotations["flannel.alpha.coreos.com/backend-type"] == null or .annotations["flannel.alpha.coreos.com/backend-data"] == null) | .name'
|
||||
```
|
||||
|
||||
If there is no output, the cluster is not affected.
|
||||
|
||||
Reference in New Issue
Block a user