mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 21:18:04 +00:00
Merge pull request #3645 from btat/merge-master-to-staging
Merge master to staging
This commit is contained in:
+1
-1
@@ -209,4 +209,4 @@ pre = "<i class='material-icons'>keyboard_arrow_down</i>"
|
||||
[[menu.main]]
|
||||
name = "Partners"
|
||||
url = "https://rancher.com/partners/"
|
||||
parent = "about"
|
||||
parent = "about"
|
||||
@@ -24,6 +24,7 @@ This section contains advanced information describing the different ways you can
|
||||
- [SELinux Support](#selinux-support)
|
||||
- [Additional preparation for (Red Hat/CentOS) Enterprise Linux](#additional-preparation-for-red-hat-centos-enterprise-linux)
|
||||
- [Enabling Lazy Pulling of eStargz (Experimental)](#enabling-lazy-pulling-of-estargz-experimental)
|
||||
- [Additional Logging Sources](#additional-logging-sources)
|
||||
|
||||
# Certificate Rotation
|
||||
|
||||
@@ -344,7 +345,7 @@ sudo reboot
|
||||
|
||||
Standard Raspbian Buster installations do not start with `cgroups` enabled. **K3S** needs `cgroups` to start the systemd service. `cgroups`can be enabled by appending `cgroup_memory=1 cgroup_enable=memory` to `/boot/cmdline.txt`.
|
||||
|
||||
## example of /boot/cmdline.txt
|
||||
### example of /boot/cmdline.txt
|
||||
```
|
||||
console=serial0,115200 console=tty1 root=PARTUUID=58b06195-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait cgroup_memory=1 cgroup_enable=memory
|
||||
```
|
||||
@@ -417,7 +418,7 @@ reboot
|
||||
|
||||
# Enabling Lazy Pulling of eStargz (Experimental)
|
||||
|
||||
## What's lazy pulling and eStargz?
|
||||
### What's lazy pulling and eStargz?
|
||||
|
||||
Pulling images is known as one of the time-consuming steps in the container lifecycle.
|
||||
According to [Harter, et al.](https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter),
|
||||
@@ -436,7 +437,7 @@ Because of the compatibility, eStargz can be pushed to standard container regist
|
||||
eStargz is developed based on the [stargz format proposed by Google CRFS project](https://github.com/google/crfs) but comes with practical features including content verification and performance optimization.
|
||||
For more details about lazy pulling and eStargz, please refer to [Stargz Snapshotter project repository](https://github.com/containerd/stargz-snapshotter).
|
||||
|
||||
## Configure k3s for lazy pulling of eStargz
|
||||
### Configure k3s for lazy pulling of eStargz
|
||||
|
||||
As shown in the following, `--snapshotter=stargz` option is needed for k3s server and agent.
|
||||
|
||||
@@ -468,3 +469,14 @@ spec:
|
||||
ports:
|
||||
- containerPort: 80
|
||||
```
|
||||
|
||||
# Additional Logging Sources
|
||||
|
||||
[Rancher logging]({{<baseurl>}}//rancher/v2.6/en/logging/helm-chart-options/) for K3s can be installed without using Rancher. The following instructions should be executed to do so:
|
||||
|
||||
```
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
helm repo update
|
||||
helm install --create-namespace -n cattle-logging-system rancher-logging-crd rancher-charts/rancher-logging-crd
|
||||
helm install --create-namespace -n cattle-logging-system rancher-logging --set additionalLoggingSources.k3s.enabled=true rancher-charts/rancher-logging
|
||||
```
|
||||
@@ -26,6 +26,8 @@ _Available as of v1.19.1+k3s1_
|
||||
|
||||
In this section, you'll learn how to create backups of the K3s cluster data and to restore the cluster from backup.
|
||||
|
||||
>**Note on Single-Server with embedded SQLite:** Currently, backups of SQLite are not supported. Instead, make a copy of `/var/lib/rancher/k3s/server` and then delete K3s.
|
||||
|
||||
### Creating Snapshots
|
||||
|
||||
Snapshots are enabled by default.
|
||||
|
||||
@@ -66,6 +66,20 @@ spec:
|
||||
|
||||
Content placed in `/var/lib/rancher/k3s/server/static/` can be accessed anonymously via the Kubernetes APIServer from within the cluster. This URL can be templated using the special variable `%{KUBERNETES_API}%` in the `spec.chart` field. For example, the packaged Traefik component loads its chart from `https://%{KUBERNETES_API}%/static/charts/traefik-1.81.0.tgz`.
|
||||
|
||||
**Note:** The `name` field should follow the Helm chart naming conventions. Refer [here](https://helm.sh/docs/chart_best_practices/conventions/#chart-names) to learn more.
|
||||
|
||||
>**Notice on File Naming Requirements:** `HelmChart` and `HelmChartConfig` manifest filenames should adhere to Kubernetes object [naming restrictions](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/). The Helm Controller uses filenames to create objects; therefore, the filename must also align with the restrictions. Any related errors can be observed in the rke2-server logs. The example below is an error generated from using underscores:
|
||||
```
|
||||
level=error msg="Failed to process config: failed to process
|
||||
/var/lib/rancher/rke2/server/manifests/rke2_ingress_daemonset.yaml:
|
||||
Addon.k3s.cattle.io \"rke2_ingress_daemonset\" is invalid: metadata.name:
|
||||
Invalid value: \"rke2_ingress_daemonset\": a lowercase RFC 1123 subdomain
|
||||
must consist of lower case alphanumeric characters, '-' or '.', and must
|
||||
start and end with an alphanumeric character (e.g. 'example.com', regex
|
||||
used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]
|
||||
([-a-z0-9]*[a-z0-9])?)*')"
|
||||
```
|
||||
|
||||
### Customizing Packaged Components with HelmChartConfig
|
||||
|
||||
To allow overriding values for packaged components that are deployed as HelmCharts (such as Traefik), K3s versions starting with v1.19.0+k3s1 support customizing deployments via a HelmChartConfig resources. The HelmChartConfig resource must match the name and namespace of its corresponding HelmChart, and supports providing additional `valuesContent`, which is passed to the `helm` command as an additional value file.
|
||||
|
||||
@@ -7,6 +7,9 @@ weight: 40
|
||||
K3s has added full support for embedded etcd as of release v1.19.5+k3s1. Versions v1.19.1 thru v1.19.4 provide only experimental support for embedded etcd.
|
||||
Embedded etcd replaced experimental Dqlite in the K3s v1.19.1 release. This is a breaking change. Please note that upgrades from experimental Dqlite to embedded etcd are not supported. If you attempt an upgrade it will not succeed and data will be lost.
|
||||
|
||||
>**Warning:**
|
||||
Embedded etcd (HA) may have performance issues on slower disks such as Raspberry Pis running with SD cards.
|
||||
|
||||
To run K3s in this mode, you must have an odd number of server nodes. We recommend starting with three nodes.
|
||||
|
||||
To get started, first launch a server node with the `cluster-init` flag to enable clustering and a token that will be used as a shared secret to join additional servers to the cluster.
|
||||
|
||||
@@ -69,3 +69,18 @@ You should see that IP forwarding is set to true.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
### Dual-stack installation
|
||||
|
||||
To enable dual-stack in k3s, you must provide valid dual-stack `cluster-cidr` and `service-cidr`, and set `disable-network-policy` on all server nodes. Both servers and agents must provide valid dual-stack `node-ip` settings. Node address auto-detection and network policy enforcement are not supported on dual-stack clusters when using the default flannel CNI. Besides, only vxlan backend is supported at the moment. This is an example of a valid configuration:
|
||||
|
||||
```
|
||||
node-ip: 10.0.10.7,2a05:d012:c6f:4611:5c2:5602:eed2:898c
|
||||
cluster-cidr: 10.42.0.0/16,2001:cafe:42:0::/56
|
||||
service-cidr: 10.43.0.0/16,2001:cafe:42:1::/112
|
||||
disable-network-policy: true
|
||||
```
|
||||
|
||||
Note that you can choose whatever `cluster-cidr` and `service-cidr` value, however the `node-ip` values must correspond to the ip addresses of your main interface. Remember to allow ipv6 traffic if you are deploying in a public cloud.
|
||||
|
||||
If you are using a custom cni plugin, i.e. a cni plugin different from flannel, the previous configuration might not be enough to enable dual-stack in the cni plugin. Please check how to enable dual-stack in its documentation and verify if network policies can be enabled.
|
||||
|
||||
@@ -5,7 +5,7 @@ description: RancherOS is a simplified Linux distribution built from containers,
|
||||
weight: 1
|
||||
---
|
||||
|
||||
> RancherOS 1.x is currently in a maintain-only-as-essential mode. It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see [this page.](https://rancher.zendesk.com/hc/en-us/articles/360041771072-Could-you-help-us-understan[…]opment-and-support-status-of-RancherOS-for-2020-and-beyond-)
|
||||
> RancherOS 1.x is currently in a maintain-only-as-essential mode. It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see [this page.](https://rancher.com/docs/os/v1.x/en/support/)
|
||||
|
||||
RancherOS is the smallest, easiest way to run Docker in production. Every process in RancherOS is a container managed by Docker. This includes system services such as `udev` and `syslog`. Because it only includes the services necessary to run Docker, RancherOS is significantly smaller than most traditional operating systems. By removing unnecessary libraries and services, requirements for security patches and other maintenance are also reduced. This is possible because, with Docker, users typically package all necessary libraries into their containers.
|
||||
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Support
|
||||
weight: 170
|
||||
---
|
||||
|
||||
## Development and Maintenance Status
|
||||
|
||||
|
||||
RancherOS 1.x is no longer being actively maintained. There are two significant reasons behind this product decision:
|
||||
|
||||
**1. Docker:** The current industry requirements for a container runtime are very much evolving. Container runtimes like containerd and CRIO are now being actively considered as the default choices. RancherOS 1.x, which was specifically designed around using Docker engine only, unfortunately does not lend itself, in its current design, to this new evolving requirement.
|
||||
|
||||
**2. ISV Support:** RancherOS was specifically designed as a minimalistic OS to support purpose-built containerized applications. It was not designed to be used as a general purpose OS (such as CentOS or Ubuntu). As such, most ISVs have not certified their software to run on RancherOS, nor does RancherOS even contain the necessary components for many of these applications to run.
|
||||
|
||||
We're working on a replacement. Stay tuned!
|
||||
@@ -63,13 +63,13 @@ The following commands are available for use in Rancher CLI.
|
||||
| `apps, [app]` | Performs operations on catalog applications (i.e. individual [Helm charts](https://docs.helm.sh/developing_charts/) or Rancher charts. |
|
||||
| `catalog` | Performs operations on [catalogs]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/). |
|
||||
| `clusters, [cluster]` | Performs operations on your [clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/). |
|
||||
| `context` | Switches between Rancher [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/). For an example, see [Project Selection](#project-selection). |
|
||||
| `context` | Switches between Rancher [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/). For an example, see [Project Selection](#project-selection). |
|
||||
| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]` | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/) and [workloads]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/)). Specify resources by name or ID. |
|
||||
| `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. |
|
||||
| `projects, [project]` | Performs operations on [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/). |
|
||||
| `projects, [project]` | Performs operations on [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/). |
|
||||
| `ps` | Displays [workloads]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads) in a project. |
|
||||
| `settings, [setting]` | Shows the current settings for your Rancher Server. |
|
||||
| `ssh` | Connects to one of your cluster nodes using the SSH protocol. |
|
||||
|
||||
@@ -8,6 +8,7 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging/splunk
|
||||
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/splunk
|
||||
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/cluster-logging/splunk/
|
||||
- /rancher/v2.x/en/cluster-admin/tools/logging/splunk
|
||||
---
|
||||
|
||||
If your organization uses [Splunk](https://www.splunk.com/), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Splunk server to view logs.
|
||||
|
||||
+7
@@ -12,6 +12,13 @@ First, you will set up your Azure cloud credentials in Rancher. Then you will us
|
||||
|
||||
Then you will create an Azure cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
>**Warning:** When the Rancher RKE cluster is running in Azure and has an Azure load balancer in front, the outbound flow will fail. The workaround for this problem is as follows:
|
||||
|
||||
> - Terminate the SSL/TLS on the internal load balancer
|
||||
> - Use the L7 load balancer
|
||||
|
||||
> For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
For more information on configuring the Kubernetes cluster that Rancher will install on the Azure nodes, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
For more information on configuring Azure node templates, refer to the [Azure node template configuration reference.](./azure-node-template-config)
|
||||
|
||||
+2
-1
@@ -9,7 +9,8 @@ This tutorial is intended to help you create a high-availability RKE cluster tha
|
||||
|
||||
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in an infrastructure provider such as Amazon's EC2, Google Compute Engine, or vSphere.
|
||||
- **Three Linux nodes,** typically virtual machines, in an infrastructure provider such as Amazon's EC2, Google Compute Engine, Azure, or vSphere.
|
||||
* **Note:** When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. Please refer [here](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations) for more information on Azure load balancer limitations.
|
||||
- **A load balancer** to direct front-end traffic to the three nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
|
||||
@@ -89,7 +89,7 @@ The S3 storage location contains the following configuration fields:
|
||||
1. **Credential Secret** (optional): If you need to use the AWS Access keys Secret keys to access s3 bucket, create a secret with your credentials with keys and the directives `accessKey` and `secretKey`. It can be in any namespace. An example secret is [here.](#example-credentialsecret) This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) The Credential Secret dropdown lists the secrets in all namespaces.
|
||||
1. **Bucket Name**: The name of the S3 bucket where backup files will be stored.
|
||||
1. **Region** (optional): The AWS [region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) where the S3 bucket is located. This field isn't needed for configuring MinIO.
|
||||
1. **Folder** (optional): The name of the folder in the S3 bucket where backup files will be stored.
|
||||
1. **Folder** (optional): The name of the folder in the S3 bucket where backup files will be stored. Nested folders (e.g., `rancher/cluster1`) are not supported.
|
||||
1. **Endpoint**: The [endpoint](https://docs.aws.amazon.com/general/latest/gr/s3.html) that is used to access S3 in the region of your bucket.
|
||||
1. **Endpoint CA** (optional): This should be the Base64 encoded CA cert. For an example, refer to the [example S3 compatible configuration.](#example-s3-storage-configuration)
|
||||
1. **Skip TLS Verifications** (optional): Set to true if you are not using TLS.
|
||||
@@ -100,7 +100,7 @@ The S3 storage location contains the following configuration fields:
|
||||
| `credentialSecretName` | If you need to use the AWS Access keys Secret keys to access s3 bucket, create a secret with your credentials with keys and the directives `accessKey` and `secretKey`. It can be in any namespace as long as you provide that namespace in `credentialSecretNamespace`. An example secret is [here.](#example-credentialsecret) This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) | |
|
||||
| `credentialSecretNamespace` | The namespace of the secret containing the credentials to access S3. This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) | |
|
||||
| `bucketName` | The name of the S3 bucket where backup files will be stored. | ✓ |
|
||||
| `folder` | The name of the folder in the S3 bucket where backup files will be stored. | |
|
||||
| `folder` | The name of the folder in the S3 bucket where backup files will be stored. Nested folders (e.g., `rancher/cluster1`) are not supported. | |
|
||||
| `region` | The AWS [region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) where the S3 bucket is located. | ✓ |
|
||||
| `endpoint` | The [endpoint](https://docs.aws.amazon.com/general/latest/gr/s3.html) that is used to access S3 in the region of your bucket. | ✓ |
|
||||
| `endpointCA` | This should be the Base64 encoded CA cert. For an example, refer to the [example S3 compatible configuration.](#example-s3-storage-configuration) | |
|
||||
@@ -136,8 +136,8 @@ metadata:
|
||||
name: creds
|
||||
type: Opaque
|
||||
data:
|
||||
accessKey: <Enter your access key>
|
||||
secretKey: <Enter your secret key>
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
### IAM Permissions for EC2 Nodes to Access S3
|
||||
@@ -183,4 +183,4 @@ After the role is created, and you have attached the corresponding instance prof
|
||||
|
||||
# Examples
|
||||
|
||||
For example Backup custom resources, refer to [this page.](../../examples/#backup)
|
||||
For example Backup custom resources, refer to [this page.](../../examples/#backup)
|
||||
|
||||
@@ -269,8 +269,8 @@ metadata:
|
||||
name: creds
|
||||
type: Opaque
|
||||
data:
|
||||
accessKey: <Enter your access key>
|
||||
secretKey: <Enter your secret key>
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
# Example EncryptionConfiguration
|
||||
|
||||
@@ -21,11 +21,12 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
|
||||
- [K3s Kubernetes installation docs]({{<baseurl>}}/k3s/latest/en/installation/)
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
Install version 1.x.x of the rancher-backup chart.
|
||||
```
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
helm repo update
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system
|
||||
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
|
||||
```
|
||||
|
||||
### 2. Restore from backup using a Restore custom resource
|
||||
@@ -39,8 +40,8 @@ metadata:
|
||||
name: s3-creds
|
||||
type: Opaque
|
||||
stringData:
|
||||
accessKey: <Enter your access key>
|
||||
secretKey: <Enter your secret key>
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
This secret can be created in any namespace, with the above example it will get created in the default namespace
|
||||
|
||||
@@ -56,8 +56,17 @@ To check how the restore is progressing, you can check the logs of the operator.
|
||||
|
||||
```
|
||||
kubectl logs -n cattle-resources-system -l app.kubernetes.io/name=rancher-backup -f
|
||||
|
||||
```
|
||||
|
||||
### Cleanup
|
||||
|
||||
If you created the restore resource with kubectl, remove the resource to prevent a naming conflict with future restores.
|
||||
If you created the restore resource with kubectl, remove the resource to prevent a naming conflict with future restores.
|
||||
|
||||
### Known Issues
|
||||
In some cases, after restoring the backup, Rancher logs will show errors similar to the following:
|
||||
```
|
||||
2021/10/05 21:30:45 [ERROR] error syncing 'c-89d82/m-4067aa68dd78': handler rke-worker-upgrader: clusters.management.cattle.io "c-89d82" not found, requeuing
|
||||
```
|
||||
This happens because one of the resources that was just restored has finalizers but the related resources have been deleted so the handler cannot find it.
|
||||
|
||||
To eliminate the errors, we need to find and delete the resource that causes the error. See more information [here](https://github.com/rancher/rancher/issues/35050#issuecomment-937968556)
|
||||
|
||||
@@ -13,6 +13,13 @@ First, you will set up your Azure cloud credentials in Rancher. Then you will us
|
||||
|
||||
Then you will create an Azure cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
>**Warning:** When the Rancher RKE cluster is running in Azure and has an Azure load balancer in front, the outbound flow will fail. The workaround for this problem is as follows:
|
||||
|
||||
> - Terminate the SSL/TLS on the internal load balancer
|
||||
> - Use the L7 load balancer
|
||||
|
||||
> For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
For more information on configuring the Kubernetes cluster that Rancher will install on the Azure nodes, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
For more information on configuring Azure node templates, refer to the [Azure node template configuration reference.](./azure-node-template-config)
|
||||
|
||||
@@ -15,6 +15,7 @@ Fleet is a separate project from Rancher, and can be installed on any Kubernetes
|
||||
- [Accessing Fleet in the Rancher UI](#accessing-fleet-in-the-rancher-ui)
|
||||
- [Windows Support](#windows-support)
|
||||
- [GitHub Repository](#github-repository)
|
||||
- [Using Fleet Behind a Proxy](#using-fleet-behind-a-proxy)
|
||||
- [Documentation](#documentation)
|
||||
|
||||
# Architecture
|
||||
@@ -46,8 +47,3 @@ For details on using Fleet behind a proxy, see [this page.](./proxy)
|
||||
# Documentation
|
||||
|
||||
The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/)
|
||||
|
||||
|
||||
### Using Fleet Behind a Proxy
|
||||
|
||||
For details on using Fleet with a proxy, see [this page.](./proxy)
|
||||
@@ -34,6 +34,7 @@ For help setting up a Kubernetes cluster, we provide these tutorials:
|
||||
- **K3s:** For the tutorial to install a K3s Kubernetes cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-with-external-db) For help setting up the infrastructure for a high-availability K3s cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-ha-with-external-db)
|
||||
- **RKE2:** For the tutorial to install an RKE2 Kubernetes cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2) For help setting up the infrastructure for a high-availability RKE2 cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
- **Amazon EKS:** For details on how to install Rancher on Amazon EKS, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/amazon-eks)
|
||||
- **AKS:** For details on how to install Rancher with Azure Kubernetes Service, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/aks)
|
||||
- **GKE:** For details on how to install Rancher with Google Kubernetes Engine, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/gke)
|
||||
|
||||
### CLI Tools
|
||||
|
||||
@@ -4,7 +4,7 @@ shortTitle: AKS
|
||||
weight: 4
|
||||
---
|
||||
|
||||
This page covers how to install Rancher on Microsoft's Azure Kubernetes Servcice (AKS).
|
||||
This page covers how to install Rancher on Microsoft's Azure Kubernetes Service (AKS).
|
||||
|
||||
The guide uses command line tools to provision an AKS cluster with an ingress. If you prefer to provision your cluster using the Azure portal, refer to the [official documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal).
|
||||
|
||||
@@ -19,6 +19,7 @@ If you already have an AKS Kubernetes cluster, skip to the step about [installin
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section]({{<baseurl>}}/rancher/v2.5/en/installation/requirements/#rke-and-hosted-kubernetes)
|
||||
- When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
# 1. Prepare your Workstation
|
||||
|
||||
@@ -44,13 +45,13 @@ az group create --name rancher-rg --location eastus
|
||||
|
||||
# 3. Create the AKS Cluster
|
||||
|
||||
To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options.
|
||||
To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
```
|
||||
az aks create \
|
||||
--resource-group rancher-rg
|
||||
--resource-group rancher-rg \
|
||||
--name rancher-server \
|
||||
--kubernetes-version 1.18.14 \
|
||||
--kubernetes-version 1.20.5 \
|
||||
--node-count 3 \
|
||||
--node-vm-size Standard_D2_v3
|
||||
```
|
||||
|
||||
@@ -81,12 +81,12 @@ Then enter the following values:
|
||||
|
||||
### 3. Create the EKS Cluster
|
||||
|
||||
To create an EKS cluster, run the following command. Use the AWS region that applies to your use case:
|
||||
To create an EKS cluster, run the following command. Use the AWS region that applies to your use case. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
```
|
||||
eksctl create cluster \
|
||||
--name rancher-server \
|
||||
--version 1.18 \
|
||||
--version 1.20 \
|
||||
--region us-west-2 \
|
||||
--nodegroup-name ranchernodes \
|
||||
--nodes 3 \
|
||||
@@ -163,4 +163,4 @@ There are many valid ways to set up the DNS. For help, refer to the AWS document
|
||||
|
||||
Next, install the Rancher Helm chart by following the instructions on [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
|
||||
|
||||
Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
|
||||
@@ -99,14 +99,9 @@ You can set extra environment variables for Rancher server using `extraEnv`. Thi
|
||||
|
||||
### TLS Settings
|
||||
|
||||
To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:
|
||||
When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller.
|
||||
|
||||
```plain
|
||||
--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
|
||||
--set 'extraEnv[0].value=1.0'
|
||||
```
|
||||
|
||||
See [TLS settings]({{<baseurl>}}/rancher/v2.5/en/admin-settings/tls-settings) for more information and options.
|
||||
See [TLS settings]({{<baseurl>}}/rancher/v2.5/en/installation/resources/tls-settings) for more information and options.
|
||||
|
||||
### Import `local` Cluster
|
||||
|
||||
|
||||
@@ -117,8 +117,10 @@ The following command creates a three-node cluster.
|
||||
|
||||
Replace `cluster-name` with the name of your new cluster.
|
||||
|
||||
When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
```
|
||||
gcloud container clusters create cluster-name --num-nodes=3
|
||||
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=1.20.10-gke.301
|
||||
```
|
||||
|
||||
# 6. Get Authentication Credentials
|
||||
@@ -177,4 +179,4 @@ There are many valid ways to set up the DNS. For help, refer to the Google Cloud
|
||||
|
||||
Next, install the Rancher Helm chart by following the instructions on [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
|
||||
|
||||
Use the DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
Use the DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
title: Rancher Helm Chart Options
|
||||
weight: 50
|
||||
aliases:
|
||||
- /rancher/v2.x/en/installation/resources/chart-options/
|
||||
---
|
||||
|
||||
The Rancher Helm chart options reference moved to [this page.]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/)
|
||||
@@ -29,7 +29,13 @@ If you do not specify a pre-shared secret, RKE2 will generate one and place it a
|
||||
|
||||
To avoid certificate errors with the fixed registration address, you should launch the server with the tls-san parameter set. This option adds an additional hostname or IP as a Subject Alternative Name in the server's TLS cert, and it can be specified as a list if you would like to access via both the IP and the hostname.
|
||||
|
||||
Here is an example of what the RKE2 config file (at /etc/rancher/rke2/config.yaml) would look like if you are following this guide:
|
||||
First, you must create the directory where the RKE2 config file is going to be placed:
|
||||
|
||||
```
|
||||
mkdir -p /etc/rancher/rke2/
|
||||
```
|
||||
|
||||
Next, create the RKE2 config file at `/etc/rancher/rke2/config.yaml` using the following example:
|
||||
|
||||
```
|
||||
token: my-shared-secret
|
||||
@@ -37,7 +43,7 @@ tls-san:
|
||||
- my-kubernetes-domain.com
|
||||
- another-kubernetes-domain.com
|
||||
```
|
||||
After that you need to run the install command and enable and start rke2:
|
||||
After that, you need to run the install command and enable and start rke2:
|
||||
|
||||
```
|
||||
curl -sfL https://get.rke2.io | INSTALL_RKE2_CHANNEL=v1.20 sh -
|
||||
@@ -51,7 +57,7 @@ systemctl start rke2-server.service
|
||||
tls-san:
|
||||
- my-kubernetes-domain.com
|
||||
- another-kubernetes-domain.com
|
||||
After that you need to run the installer and enable then start rke2
|
||||
After that, you need to run the installer and enable, then start, rke2:
|
||||
|
||||
curl -sfL https://get.rke2.io | sh -
|
||||
systemctl enable rke2-server.service
|
||||
|
||||
@@ -8,30 +8,20 @@ aliases:
|
||||
- /rancher/v2.x/en/installation/resources/tls-settings/
|
||||
---
|
||||
|
||||
The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites. TLS 1.3 and TLS 1.3 exclusive cipher suites are not supported.
|
||||
Changing the default TLS settings depends on the chosen installation method.
|
||||
|
||||
# Configuring TLS settings
|
||||
# Running Rancher in a highly available Kubernetes cluster
|
||||
|
||||
The Audit Log is enabled and configured by passing environment variables to the Rancher server container. See the following to enable on your installation.
|
||||
When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller:
|
||||
|
||||
- [TLS settings in Docker options]({{<baseurl>}}/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/advanced/#tls-settings)
|
||||
* nginx-ingress-controller (default for RKE1 and RKE2): [Default TLS Version and Ciphers](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers).
|
||||
* traefik (default for K3s): [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options).
|
||||
|
||||
- [TLS settings in Helm chart options]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/chart-options/#tls-settings)
|
||||
# Running Rancher in a single Docker container
|
||||
|
||||
# TLS Environment Variables
|
||||
The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites. You can change this by setting the following environment variables:
|
||||
|
||||
| Parameter | Description | Default | Available options |
|
||||
|-----|-----|-----|-----|
|
||||
| `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2` |
|
||||
| `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,`<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
|
||||
|
||||
|
||||
# Legacy configuration
|
||||
|
||||
If you need to configure TLS the same way as it was before Rancher v2.1.7, please use the following settings:
|
||||
|
||||
|
||||
| Parameter | Legacy value |
|
||||
|-----|-----|
|
||||
| `CATTLE_TLS_MIN_VERSION` | `1.0` |
|
||||
| `CATTLE_TLS_CIPHERS` | `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,`<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,`<br/>`TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,`<br/>`TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,`<br/>`TLS_RSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_RSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_RSA_WITH_AES_128_CBC_SHA,`<br/>`TLS_RSA_WITH_AES_256_CBC_SHA,`<br/>`TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,`<br/>`TLS_RSA_WITH_3DES_EDE_CBC_SHA`
|
||||
| `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
|
||||
| `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
|
||||
|
||||
@@ -19,7 +19,7 @@ Before enabling Istio, we recommend that you confirm that your Rancher worker no
|
||||
|
||||
The table below shows a summary of the minimum recommended resource requests and limits for the CPU and memory of each core Istio component.
|
||||
|
||||
In Kubernetes, the resource request indicates that the workload will not deployed on a node unless the node has at least the specified amount of memory and CPU available. If the workload surpasses the limit for CPU or memory, it can be terminated or evicted from the node. For more information on managing resource limits for containers, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
In Kubernetes, the resource request indicates that the workload will not be deployed on a node unless the node has at least the specified amount of memory and CPU available. If the workload surpasses the limit for CPU or memory, it can be terminated or evicted from the node. For more information on managing resource limits for containers, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "v2.5.6+" %}}
|
||||
|
||||
@@ -34,13 +34,14 @@ Here is the complete list of tokens that are generated with `ttl=0`:
|
||||
|
||||
Admins can set a global TTL on Kubeconfig tokens. Once the token expires the kubectl command will require the user to authenticate to Rancher.
|
||||
|
||||
1. Disable the kubeconfig-generate-token setting in the Rancher API view at `https://<Rancher-Server-IP/v3/settings/kubeconfig-generate-token`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. The kubeconfig file will now provide a command to login to Rancher.
|
||||
Go to the global settings and:
|
||||
|
||||
2. Edit the setting and set the value to `false`.
|
||||
1. Set the `kubeconfig-generate-token` setting to `false`. This setting instructs Rancher to no longer automatically generate a token when a user clicks on download a kubeconfig file. The kubeconfig file will now provide a command to login to Rancher.
|
||||
|
||||
3. Go to setting kubeconfig-token-ttl-minutes in the Rancher API view at `https://<Rancher-Server-IP/v3/settings/kubeconfig-token-ttl-minutes`. By default, kubeconfig-token-ttl-minutes is 960 (16 hours).
|
||||
_**Note:**_ Once this setting is deactivated, a generated kubeconfig will reference the [Rancher CLI]({{<baseurl>}}/rancher/v2.6/en/cli) to retrieve a short lived token for the cluster. When you use this kubeconfig in a client, such as `kubectl`, the Rancher CLI needs to be installed as well.
|
||||
|
||||
2. Set the `kubeconfig-token-ttl-minutes` setting to the desired duration in minutes. By default, `kubeconfig-token-ttl-minutes` is 960 (16 hours).
|
||||
|
||||
4. Edit the setting and set the value to desired duration in minutes.
|
||||
_**Note:**_ This value cannot exceed max-ttl of API tokens.(`https://<Rancher-Server-IP/v3/settings/auth-token-max-ttl-minutes`). `auth-token-max-ttl-minutes` is set to 1440 (24 hours) by default. `auth-token-max-ttl-minutes would default to 0 allowing tokens to never expire`.
|
||||
|
||||
### Token Hashing
|
||||
|
||||
@@ -79,7 +79,7 @@ The S3 storage location contains the following configuration fields:
|
||||
1. **Credential Secret** (optional): If you need to use the AWS Access keys Secret keys to access s3 bucket, create a secret with your credentials with keys and the directives `accessKey` and `secretKey`. It can be in any namespace. An example secret is [here.](#example-credentialsecret) This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) The Credential Secret dropdown lists the secrets in all namespaces.
|
||||
1. **Bucket Name**: The name of the S3 bucket where backup files will be stored.
|
||||
1. **Region** (optional): The AWS [region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) where the S3 bucket is located. This field isn't needed for configuring MinIO.
|
||||
1. **Folder** (optional): The name of the folder in the S3 bucket where backup files will be stored.
|
||||
1. **Folder** (optional): The name of the folder in the S3 bucket where backup files will be stored. Nested folders (e.g., `rancher/cluster1`) are not supported.
|
||||
1. **Endpoint**: The [endpoint](https://docs.aws.amazon.com/general/latest/gr/s3.html) that is used to access S3 in the region of your bucket.
|
||||
1. **Endpoint CA** (optional): This should be the Base64 encoded CA cert. For an example, refer to the [example S3 compatible configuration.](#example-s3-storage-configuration)
|
||||
1. **Skip TLS Verifications** (optional): Set to true if you are not using TLS.
|
||||
@@ -90,7 +90,7 @@ The S3 storage location contains the following configuration fields:
|
||||
| `credentialSecretName` | If you need to use the AWS Access keys Secret keys to access s3 bucket, create a secret with your credentials with keys and the directives `accessKey` and `secretKey`. It can be in any namespace as long as you provide that namespace in `credentialSecretNamespace`. An example secret is [here.](#example-credentialsecret) This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) | |
|
||||
| `credentialSecretNamespace` | The namespace of the secret containing the credentials to access S3. This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) | |
|
||||
| `bucketName` | The name of the S3 bucket where backup files will be stored. | ✓ |
|
||||
| `folder` | The name of the folder in the S3 bucket where backup files will be stored. | |
|
||||
| `folder` | The name of the folder in the S3 bucket where backup files will be stored. Nested folders (e.g., `rancher/cluster1`) are not supported. | |
|
||||
| `region` | The AWS [region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) where the S3 bucket is located. | ✓ |
|
||||
| `endpoint` | The [endpoint](https://docs.aws.amazon.com/general/latest/gr/s3.html) that is used to access S3 in the region of your bucket. | ✓ |
|
||||
| `endpointCA` | This should be the Base64 encoded CA cert. For an example, refer to the [example S3 compatible configuration.](#example-s3-storage-configuration) | |
|
||||
@@ -126,8 +126,8 @@ metadata:
|
||||
name: creds
|
||||
type: Opaque
|
||||
data:
|
||||
accessKey: <Enter your access key>
|
||||
secretKey: <Enter your secret key>
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
### IAM Permissions for EC2 Nodes to Access S3
|
||||
@@ -173,4 +173,4 @@ After the role is created, and you have attached the corresponding instance prof
|
||||
|
||||
# Examples
|
||||
|
||||
For example Backup custom resources, refer to [this page.](../../examples/#backup)
|
||||
For example Backup custom resources, refer to [this page.](../../examples/#backup)
|
||||
|
||||
@@ -266,8 +266,8 @@ metadata:
|
||||
name: creds
|
||||
type: Opaque
|
||||
data:
|
||||
accessKey: <Enter your access key>
|
||||
secretKey: <Enter your secret key>
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
# Example EncryptionConfiguration
|
||||
|
||||
@@ -19,11 +19,12 @@ Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes
|
||||
- [K3s Kubernetes installation docs]({{<baseurl>}}/k3s/latest/en/installation/)
|
||||
|
||||
### 1. Install the rancher-backup Helm chart
|
||||
Install version 2.x.x of the rancher-backup chart.
|
||||
```
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
helm repo update
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system
|
||||
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
|
||||
```
|
||||
|
||||
### 2. Restore from backup using a Restore custom resource
|
||||
@@ -37,8 +38,8 @@ metadata:
|
||||
name: s3-creds
|
||||
type: Opaque
|
||||
stringData:
|
||||
accessKey: <Enter your access key>
|
||||
secretKey: <Enter your secret key>
|
||||
accessKey: <Enter your base64-encoded access key>
|
||||
secretKey: <Enter your base64-encoded secret key>
|
||||
```
|
||||
|
||||
This secret can be created in any namespace, with the above example it will get created in the default namespace
|
||||
|
||||
@@ -57,4 +57,13 @@ kubectl logs -n cattle-resources-system -l app.kubernetes.io/name=rancher-backup
|
||||
|
||||
### Cleanup
|
||||
|
||||
If you created the restore resource with kubectl, remove the resource to prevent a naming conflict with future restores.
|
||||
If you created the restore resource with kubectl, remove the resource to prevent a naming conflict with future restores.
|
||||
|
||||
### Known Issues
|
||||
In some cases, after restoring the backup, Rancher logs will show errors similar to the following:
|
||||
```
|
||||
2021/10/05 21:30:45 [ERROR] error syncing 'c-89d82/m-4067aa68dd78': handler rke-worker-upgrader: clusters.management.cattle.io "c-89d82" not found, requeuing
|
||||
```
|
||||
This happens because one of the resources that was just restored has finalizers but the related resources have been deleted so the handler cannot find it.
|
||||
|
||||
To eliminate the errors, we need to find and delete the resource that causes the error. See more information [here](https://github.com/rancher/rancher/issues/35050#issuecomment-937968556)
|
||||
|
||||
@@ -16,3 +16,5 @@ Certificates can be rotated for the following services:
|
||||
- kube-scheduler
|
||||
- kube-controller-manager
|
||||
|
||||
> **Note:** For users who didn't rotate their webhook certificates, and they have expired after one year, please see this [page]({{<baseurl>}}/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/) for help.
|
||||
|
||||
|
||||
@@ -21,10 +21,6 @@ Rancher can configure member roles for AKS clusters in the same way as any other
|
||||
|
||||
> The configuration information in this section assumes you have already set up a service principal for Rancher. For step-by-step instructions for how to set up the service principal, see [this section.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/#prerequisites-in-microsoft-azure)
|
||||
|
||||
### Tenant ID
|
||||
|
||||
To get the tenant ID, go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations**, then click the name of the service principal. The tenant ID is listed on the app registration detail page as **Directory (tenant) ID**.
|
||||
|
||||
### Subscription ID
|
||||
|
||||
To get the subscription ID, click **All Services** in the left navigation bar. Then click **Subscriptions**. Go to the name of the subscription that you want to associate with your Kubernetes cluster and copy the **Subscription ID**.
|
||||
|
||||
@@ -12,11 +12,11 @@ headless: true
|
||||
| [Managing Persistent Volumes and Storage Classes]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Managing Projects, Namespaces and Workloads]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/projects-and-namespaces/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Using App Catalogs]({{<baseurl>}}/rancher/v2.6/en/helm-charts/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| Configuring Tools (Alerts, Notifiers, Logging, Monitoring, Istio) | ✓ | ✓ | ✓ | ✓ |
|
||||
| Configuring Tools ([Alerts, Notifiers, Monitoring]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/), [Logging]({{<baseurl>}}/rancher/v2.6/en/logging/), [Istio]({{<baseurl>}}/rancher/v2.6/en/istio/)) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Running Security Scans]({{<baseurl>}}/rancher/v2.6/en/security/security-scan/) | ✓ | ✓ | ✓ | ✓ |
|
||||
| [Use existing configuration to create additional clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cloning-clusters/)| ✓ | ✓ | ✓ | |
|
||||
| [Ability to rotate certificates]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/certificate-rotation/) | ✓ | ✓ | | |
|
||||
| [Ability to [backup]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/backing-up-etcd/) and [restore]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/restoring-etcd/) Rancher-launched clusters | ✓ | ✓ | | ✓<sup>4</sup> |
|
||||
| Ability to [backup]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/backing-up-etcd/) and [restore]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/restoring-etcd/) Rancher-launched clusters | ✓ | ✓ | | ✓<sup>4</sup> |
|
||||
| [Cleaning Kubernetes components when clusters are no longer reachable from Rancher]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cleaning-cluster-nodes/) | ✓ | | | |
|
||||
| [Configuring Pod Security Policies]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/pod-security-policy/) | ✓ | ✓ | ||
|
||||
|
||||
|
||||
+1
-2
@@ -27,7 +27,6 @@ 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
|
||||
- Tenant ID
|
||||
- Client ID
|
||||
- Client secret
|
||||
|
||||
@@ -84,7 +83,7 @@ You can also follow these instructions to set up a service principal and give it
|
||||
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**.
|
||||
1. Click the name of your service principal. Take note of the tenant ID and application ID (also called app ID or client ID) so that you can use it when provisioning your AKS cluster. Then click **Certificates & secrets**.
|
||||
1. Click the name of your service principal. Take note of the application ID (also called app ID or client ID) so that you can use it when provisioning your AKS cluster. Then click **Certificates & secrets**.
|
||||
1. Click **New client secret**.
|
||||
1. Enter a short description, pick an expiration time, and click **Add**. Take note of the client secret so that you can use it when provisioning the AKS cluster.
|
||||
|
||||
|
||||
+9
-2
@@ -10,6 +10,13 @@ First, you will set up your Azure cloud credentials in Rancher. Then you will us
|
||||
|
||||
Then you will create an Azure cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
>**Warning:** When the Rancher RKE cluster is running in Azure and has an Azure load balancer in front, the outbound flow will fail. The workaround for this problem is as follows:
|
||||
|
||||
> - Terminate the SSL/TLS on the internal load balancer
|
||||
> - Use the L7 load balancer
|
||||
|
||||
> For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
For more information on configuring the Kubernetes cluster that Rancher will install on the Azure nodes, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options)
|
||||
|
||||
For more information on configuring Azure node templates, refer to the [Azure node template configuration reference.](./azure-node-template-config)
|
||||
@@ -32,7 +39,7 @@ az ad sp create-for-rbac \
|
||||
--scopes="/subscriptions/<subscription Id>"
|
||||
```
|
||||
|
||||
The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, *The client secret*, and *The tenant ID*. This information will be used when you create a node template for Azure.
|
||||
The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, and *The client secret*. This information will be used when you create a node template for Azure.
|
||||
|
||||
# Creating an Azure Cluster
|
||||
|
||||
@@ -91,4 +98,4 @@ You can access your cluster after its state is updated to **Active**.
|
||||
After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.
|
||||
|
||||
+1
-3
@@ -34,9 +34,7 @@ _Tech Preview_
|
||||
|
||||
Rancher v2.6 introduces provisioning for [RKE2](https://docs.rke2.io/) clusters directly from the Rancher UI. RKE2, also known as RKE Government, is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
The RKE2 provisioning tech preview also includes installing RKE2 on Windows clusters. When provisioning a new Windows cluster, users can select "Windows" and then choose the appropriate options to configure the custom cluster under the Cluster Management page. Only Windows worker nodes may be registered.
|
||||
|
||||
Windows features for RKE2 include:
|
||||
The RKE2 provisioning tech preview also includes installing RKE2 on Windows clusters. Windows features for RKE2 include:
|
||||
|
||||
- Windows Containers with RKE2 powered by containerd
|
||||
- Added provisioning of Windows RKE2 custom clusters directly from the Rancher UI
|
||||
|
||||
@@ -11,6 +11,7 @@ Fleet is a separate project from Rancher, and can be installed on any Kubernetes
|
||||
- [Accessing Fleet in the Rancher UI](#accessing-fleet-in-the-rancher-ui)
|
||||
- [Windows Support](#windows-support)
|
||||
- [GitHub Repository](#github-repository)
|
||||
- [Using Fleet Behind a Proxy](#using-fleet-behind-a-proxy)
|
||||
- [Documentation](#documentation)
|
||||
|
||||
# Architecture
|
||||
|
||||
@@ -27,6 +27,7 @@ For help setting up a Kubernetes cluster, we provide these tutorials:
|
||||
- **K3s:** For the tutorial to install a K3s Kubernetes cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/ha-with-external-db) For help setting up the infrastructure for a high-availability K3s cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-ha-with-external-db)
|
||||
- **RKE2:** For the tutorial to install an RKE2 Kubernetes cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/ha-rke2) For help setting up the infrastructure for a high-availability RKE2 cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
- **Amazon EKS:** For details on how to install Rancher on Amazon EKS, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/amazon-eks)
|
||||
- **AKS:** For details on how to install Rancher with Azure Kubernetes Service, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/aks)
|
||||
- **GKE:** For details on how to install Rancher with Google Kubernetes Engine, including how to install an ingress so that the Rancher server can be accessed, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/gke)
|
||||
|
||||
### CLI Tools
|
||||
|
||||
@@ -4,7 +4,7 @@ shortTitle: AKS
|
||||
weight: 4
|
||||
---
|
||||
|
||||
This page covers how to install Rancher on Microsoft's Azure Kubernetes Servcice (AKS).
|
||||
This page covers how to install Rancher on Microsoft's Azure Kubernetes Service (AKS).
|
||||
|
||||
The guide uses command line tools to provision an AKS cluster with an ingress. If you prefer to provision your cluster using the Azure portal, refer to the [official documentation](https://docs.microsoft.com/en-us/azure/aks/kubernetes-walkthrough-portal).
|
||||
|
||||
@@ -19,6 +19,7 @@ If you already have an AKS Kubernetes cluster, skip to the step about [installin
|
||||
- [Microsoft Azure Subscription](https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription#create-a-subscription-in-the-azure-portal): Use this link to follow a tutorial to create a Microsoft Azure subscription if you don't have one yet.
|
||||
- [Micsoroft Azure Tenant](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant): Use this link and follow instructions to create a Microsoft Azure tenant.
|
||||
- Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/#rke-and-hosted-kubernetes)
|
||||
- When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
|
||||
|
||||
# 1. Prepare your Workstation
|
||||
|
||||
@@ -44,13 +45,13 @@ az group create --name rancher-rg --location eastus
|
||||
|
||||
# 3. Create the AKS Cluster
|
||||
|
||||
To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options.
|
||||
To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
```
|
||||
az aks create \
|
||||
--resource-group rancher-rg
|
||||
--resource-group rancher-rg \
|
||||
--name rancher-server \
|
||||
--kubernetes-version 1.18.14 \
|
||||
--kubernetes-version 1.20.7 \
|
||||
--node-count 3 \
|
||||
--node-vm-size Standard_D2_v3
|
||||
```
|
||||
|
||||
@@ -79,12 +79,12 @@ Then enter the following values:
|
||||
|
||||
### 3. Create the EKS Cluster
|
||||
|
||||
To create an EKS cluster, run the following command. Use the AWS region that applies to your use case:
|
||||
To create an EKS cluster, run the following command. Use the AWS region that applies to your use case. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
```
|
||||
eksctl create cluster \
|
||||
--name rancher-server \
|
||||
--version 1.18 \
|
||||
--version 1.20 \
|
||||
--region us-west-2 \
|
||||
--nodegroup-name ranchernodes \
|
||||
--nodes 3 \
|
||||
@@ -161,4 +161,4 @@ There are many valid ways to set up the DNS. For help, refer to the AWS document
|
||||
|
||||
Next, install the Rancher Helm chart by following the instructions on [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
|
||||
|
||||
Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
Use that DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Rancher Helm Chart Options
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.6/en/installation/resources/chart-options
|
||||
---
|
||||
|
||||
This page is a configuration reference for the Rancher Helm chart.
|
||||
@@ -110,12 +112,7 @@ You can set extra environment variables for Rancher server using `extraEnv`. Thi
|
||||
|
||||
### TLS Settings
|
||||
|
||||
To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version:
|
||||
|
||||
```plain
|
||||
--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
|
||||
--set 'extraEnv[0].value=1.0'
|
||||
```
|
||||
When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller.
|
||||
|
||||
See [TLS settings]({{<baseurl>}}/rancher/v2.6/en/installation/resources/tls-settings) for more information and options.
|
||||
|
||||
|
||||
@@ -117,8 +117,10 @@ The following command creates a three-node cluster.
|
||||
|
||||
Replace `cluster-name` with the name of your new cluster.
|
||||
|
||||
When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version.
|
||||
|
||||
```
|
||||
gcloud container clusters create cluster-name --num-nodes=3
|
||||
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=1.20.8-gke.900
|
||||
```
|
||||
|
||||
# 6. Get Authentication Credentials
|
||||
@@ -177,4 +179,4 @@ There are many valid ways to set up the DNS. For help, refer to the Google Cloud
|
||||
|
||||
Next, install the Rancher Helm chart by following the instructions on [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution.
|
||||
|
||||
Use the DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
Use the DNS name from the previous step as the Rancher server URL when you install Rancher. It can be passed in as a Helm option. For example, if the DNS name is `rancher.my.org`, you could run the Helm installation command with the option `--set hostname=rancher.my.org`.
|
||||
|
||||
@@ -35,6 +35,7 @@ Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3
|
||||
> - Rancher nodes may also require additional outbound access for any external authentication provider which is configured (LDAP for example).
|
||||
> - Kubernetes recommends TCP 30000-32767 for node port services.
|
||||
> - For firewalls, traffic may need to be enabled within the cluster and pod CIDR.
|
||||
> - Rancher nodes may also need outbound access to an external S3 location which is used for storing cluster backups (Minio for example).
|
||||
|
||||
### Ports for Rancher Server Nodes on K3s
|
||||
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
---
|
||||
title: Rancher Helm Chart Options
|
||||
weight: 50
|
||||
---
|
||||
|
||||
The Rancher Helm chart options reference moved to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/chart-options/)
|
||||
@@ -26,7 +26,13 @@ If you do not specify a pre-shared secret, RKE2 will generate one and place it a
|
||||
|
||||
To avoid certificate errors with the fixed registration address, you should launch the server with the tls-san parameter set. This option adds an additional hostname or IP as a Subject Alternative Name in the server's TLS cert, and it can be specified as a list if you would like to access via both the IP and the hostname.
|
||||
|
||||
Here is an example of what the RKE2 config file (at /etc/rancher/rke2/config.yaml) would look like if you are following this guide:
|
||||
First, you must create the directory where the RKE2 config file is going to be placed:
|
||||
|
||||
```
|
||||
mkdir -p /etc/rancher/rke2/
|
||||
```
|
||||
|
||||
Next, create the RKE2 config file at `/etc/rancher/rke2/config.yaml` using the following example:
|
||||
|
||||
```
|
||||
token: my-shared-secret
|
||||
@@ -34,7 +40,7 @@ tls-san:
|
||||
- my-kubernetes-domain.com
|
||||
- another-kubernetes-domain.com
|
||||
```
|
||||
After that you need to run the install command and enable and start rke2:
|
||||
After that, you need to run the install command and enable and start rke2:
|
||||
|
||||
```
|
||||
curl -sfL https://get.rke2.io | INSTALL_RKE2_CHANNEL=v1.20 sh -
|
||||
@@ -42,19 +48,18 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
```
|
||||
1. To join the rest of the nodes, you need to configure each additional node with the same shared token or the one generated automatically. Here is an example of the configuration file:
|
||||
```
|
||||
token: my-shared-secret
|
||||
server: https://<DNS-DOMAIN>:9345
|
||||
tls-san:
|
||||
- my-kubernetes-domain.com
|
||||
- another-kubernetes-domain.com
|
||||
```
|
||||
After that you need to run the installer and enable then start rke2
|
||||
```
|
||||
curl -sfL https://get.rke2.io | sh -
|
||||
systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
```
|
||||
|
||||
token: my-shared-secret
|
||||
server: https://<DNS-DOMAIN>:9345
|
||||
tls-san:
|
||||
- my-kubernetes-domain.com
|
||||
- another-kubernetes-domain.com
|
||||
After that, you need to run the installer and enable, then start, rke2:
|
||||
|
||||
curl -sfL https://get.rke2.io | sh -
|
||||
systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
|
||||
|
||||
1. Repeat the same command on your third RKE2 server node.
|
||||
|
||||
|
||||
@@ -3,30 +3,20 @@ title: TLS Settings
|
||||
weight: 3
|
||||
---
|
||||
|
||||
The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites. TLS 1.3 and TLS 1.3 exclusive cipher suites are not supported.
|
||||
Changing the default TLS settings depends on the chosen installation method.
|
||||
|
||||
# Configuring TLS settings
|
||||
# Running Rancher in a highly available Kubernetes cluster
|
||||
|
||||
The Audit Log is enabled and configured by passing environment variables to the Rancher server container. See the following to enable on your installation.
|
||||
When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller:
|
||||
|
||||
- [TLS settings in Docker options]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/advanced/#tls-settings)
|
||||
* nginx-ingress-controller (default for RKE1 and RKE2): [Default TLS Version and Ciphers](https://kubernetes.github.io/ingress-nginx/user-guide/tls/#default-tls-version-and-ciphers).
|
||||
* traefik (default for K3s): [TLS Options](https://doc.traefik.io/traefik/https/tls/#tls-options).
|
||||
|
||||
- [TLS settings in Helm chart options]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/chart-options/#tls-settings)
|
||||
# Running Rancher in a single Docker container
|
||||
|
||||
# TLS Environment Variables
|
||||
The default TLS configuration only accepts TLS 1.2 and secure TLS cipher suites. You can change this by setting the following environment variables:
|
||||
|
||||
| Parameter | Description | Default | Available options |
|
||||
|-----|-----|-----|-----|
|
||||
| `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2` |
|
||||
| `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,`<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
|
||||
|
||||
|
||||
# Legacy configuration
|
||||
|
||||
If you need to configure TLS the same way as it was before Rancher v2.1.7, please use the following settings:
|
||||
|
||||
|
||||
| Parameter | Legacy value |
|
||||
|-----|-----|
|
||||
| `CATTLE_TLS_MIN_VERSION` | `1.0` |
|
||||
| `CATTLE_TLS_CIPHERS` | `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,`<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,`<br/>`TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,`<br/>`TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,`<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,`<br/>`TLS_RSA_WITH_AES_128_GCM_SHA256,`<br/>`TLS_RSA_WITH_AES_256_GCM_SHA384,`<br/>`TLS_RSA_WITH_AES_128_CBC_SHA,`<br/>`TLS_RSA_WITH_AES_256_CBC_SHA,`<br/>`TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,`<br/>`TLS_RSA_WITH_3DES_EDE_CBC_SHA`
|
||||
| `CATTLE_TLS_MIN_VERSION` | Minimum TLS version | `1.2` | `1.0`, `1.1`, `1.2`, `1.3` |
|
||||
| `CATTLE_TLS_CIPHERS` | Allowed TLS cipher suites | `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305`,<br/>`TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`,<br/>`TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`,<br/>`TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305` | See [Golang tls constants](https://golang.org/pkg/crypto/tls/#pkg-constants) |
|
||||
|
||||
@@ -16,9 +16,17 @@ When installing or upgrading the Istio Helm chart through **Apps & Marketplace,*
|
||||
components:
|
||||
cni:
|
||||
enabled: true
|
||||
k8s:
|
||||
overlays:
|
||||
- apiVersion: "apps/v1"
|
||||
kind: "DaemonSet"
|
||||
name: "istio-cni-node"
|
||||
patches:
|
||||
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
|
||||
value: true
|
||||
values:
|
||||
cni:
|
||||
image: rancher/istio-install-cni:1.7.3
|
||||
image: rancher/mirrored-istio-install-cni:1.9.3
|
||||
excludeNamespaces:
|
||||
- istio-system
|
||||
- kube-system
|
||||
@@ -26,10 +34,5 @@ When installing or upgrading the Istio Helm chart through **Apps & Marketplace,*
|
||||
cniBinDir: /opt/cni/bin
|
||||
cniConfDir: /etc/cni/net.d
|
||||
```
|
||||
1. After installing or upgrading Istio, you'll notice the cni-node pods in the istio-system namespace in a CrashLoopBackoff error. Manually edit the `istio-cni-node` daemonset to include the following on the `install-cni` container:
|
||||
```yaml
|
||||
securityContext:
|
||||
privileged: true
|
||||
```
|
||||
|
||||
**Result:** Now you should be able to utilize Istio as desired, including sidecar injection and monitoring via Kiali.
|
||||
|
||||
@@ -5,7 +5,7 @@ weight: 3045
|
||||
|
||||
Pod configuration is managed by Deployments, StatefulSets and Daemonsets, whereas services direct traffic to pods using selectors.
|
||||
|
||||
For every workload created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
|
||||
For every workload (with at least one port configured) created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
|
||||
`<workload>.<namespace>.svc.cluster.local`.
|
||||
|
||||
You can create additional services so that a given namespace resolves with one or more external IP addresses, an external hostname, an alias to another DNS record, other workloads, or a set of pods that match a selector that you create.
|
||||
|
||||
@@ -9,7 +9,7 @@ Rancher is a container management platform built for organizations that deploy c
|
||||
|
||||
Kubernetes has become the container orchestration standard. Most cloud and virtualization vendors now offer it as standard infrastructure. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE) or cloud Kubernetes services, such as GKE, AKS, and EKS. Rancher users can also import and manage their existing Kubernetes clusters created using any Kubernetes distribution or installer.
|
||||
|
||||
# Meet IT requirements
|
||||
# Meet IT Requirements
|
||||
|
||||
Rancher supports centralized authentication, access control, and monitoring for all Kubernetes clusters under its control. For example, you can:
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Architecture Recommendations
|
||||
weight: 3
|
||||
---
|
||||
|
||||
Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)
|
||||
If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
@@ -48,7 +48,7 @@ In an RKE installation, the cluster data is replicated on each of three etcd nod
|
||||
|
||||
We recommend the following configurations for the load balancer and Ingress controllers:
|
||||
|
||||
* The DNS for Rancher should resolve to a Layer 4 load balancer (TCP)
|
||||
* The DNS for Rancher should resolve to a Layer 4 load balancer (TCP).
|
||||
* The Load Balancer should forward port TCP/80 and TCP/443 to all 3 nodes in the Kubernetes cluster.
|
||||
* The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
* The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
@@ -108,4 +108,4 @@ For more best practices for downstream clusters, refer to the [production checkl
|
||||
|
||||
If you are using an [authorized cluster endpoint,]({{<baseurl>}}/rancher/v2.6/en/overview/architecture/#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role.
|
||||
|
||||
If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) and [API keys]({{<baseurl>}}/rancher/v2.6/en/user-settings/api-keys/#creating-an-api-key) for more information.
|
||||
If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) and [API keys]({{<baseurl>}}/rancher/v2.6/en/user-settings/api-keys/#creating-an-api-key) for more information.
|
||||
|
||||
@@ -43,9 +43,9 @@ You can install Rancher on a single node, or on a high-availability Kubernetes c
|
||||
|
||||
A high-availability Kubernetes installation is recommended for production.
|
||||
|
||||
A Docker installation of Rancher is recommended only for development and testing purposes. The ability to migrate Rancher to a high-availability cluster depends on the Rancher version:
|
||||
A Docker installation of Rancher is recommended only for development and testing purposes. The ability to migrate Rancher to a high-availability cluster depends on the Rancher version.
|
||||
|
||||
The Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher)
|
||||
The Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher).
|
||||
|
||||
The Rancher server, regardless of the installation method, should always run on nodes that are separate from the downstream user clusters that it manages. If Rancher is installed on a high-availability Kubernetes cluster, it should run on a separate cluster from the cluster(s) it manages.
|
||||
|
||||
@@ -73,7 +73,7 @@ the pods. Bob is authenticated through Rancher's authentication proxy.
|
||||
|
||||
The authentication proxy forwards all Kubernetes API calls to downstream clusters. It integrates with authentication services like local authentication, Active Directory, and GitHub. On every Kubernetes API call, the authentication proxy authenticates the caller and sets the proper Kubernetes impersonation headers before forwarding the call to Kubernetes masters.
|
||||
|
||||
Rancher communicates with Kubernetes clusters using a [service account,](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) which provides an identity for processes that run in a pod.
|
||||
Rancher communicates with Kubernetes clusters using a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/), which provides an identity for processes that run in a pod.
|
||||
|
||||
By default, Rancher generates a [kubeconfig file]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Kubernetes Concepts
|
||||
weight: 4
|
||||
---
|
||||
|
||||
This page explains concepts related to Kubernetes that are important for understanding how Rancher works. The descriptions below provide a simplified interview of Kubernetes components. For more details, refer to the [official documentation on Kubernetes components.](https://kubernetes.io/docs/concepts/overview/components/)
|
||||
This page explains concepts related to Kubernetes that are important for understanding how Rancher works. The descriptions below provide a simplified overview of Kubernetes components. For more details, refer to the [official documentation on Kubernetes components.](https://kubernetes.io/docs/concepts/overview/components/)
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
@@ -69,4 +69,4 @@ For high-availability installations of Rancher, Helm is the tool used to install
|
||||
|
||||
Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh).
|
||||
|
||||
For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
|
||||
For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
|
||||
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
title: Rancher Equinix Metal Quick Start
|
||||
weight: 300
|
||||
---
|
||||
|
||||
## This tutorial walks you through the following:
|
||||
|
||||
- Provisioning an Equinix Metal Server
|
||||
- Installation of Rancher 2.x
|
||||
- Creation of your first cluster
|
||||
- Deployment of an application, Nginx
|
||||
|
||||
## Quick Start Outline
|
||||
|
||||
This Quick Start Guide is divided into different tasks for easier consumption.
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
|
||||
1. [Provision a Equinix Metal Host](#1-provision-a-equinix-metal-host)
|
||||
|
||||
1. [Install Rancher](#2-install-rancher)
|
||||
|
||||
1. [Log In](#3-log-in)
|
||||
|
||||
1. [Create the Cluster](#4-create-the-cluster)
|
||||
|
||||
<!-- /TOC -->
|
||||
<br/>
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- An [Equinix Metal account](https://metal.equinix.com/developers/docs/accounts/users/)
|
||||
- An [Equinix Metal project](https://metal.equinix.com/developers/docs/accounts/projects/)
|
||||
|
||||
|
||||
### 1. Provision a Equinix Metal Host
|
||||
|
||||
Begin deoploying an Equinix Metal Host. Equinix Metal Servers can be provisioned by either the Equinix Metal console, api, or cli. You can find instructions on how to deploy with each deployment type on the [Equinix Metal deployment documentation](https://metal.equinix.com/developers/docs/deploy/on-demand/). Yopu can find additional documentation on Equinix Metal server types and prices below.
|
||||
- [Equinix Metal Server Types](https://metal.equinix.com/developers/docs/servers/about/)
|
||||
- [Equinix Metal Pricing](https://metal.equinix.com/developers/docs/servers/server-specs/)
|
||||
|
||||
**Note:**
|
||||
> When provisioning a new Equinix Metal Server via the CLI or API you will need to be able to provide the following information: project-id, plan, metro, and the operating-system
|
||||
> When using a cloud-hosted virtual machine you need to allow inbound TCP communication to ports 80 and 443. Please see your cloud-host's documentation for information regarding port configuration.
|
||||
> For a full list of port requirements, refer to [Docker Installation]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/).
|
||||
> Provision the host according to our [Requirements]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/).
|
||||
|
||||
### 2. Install Rancher
|
||||
|
||||
To install Rancher on your Equinix Metal host, connect to it and then use a shell to install.
|
||||
|
||||
1. Log in to your Equinix Metal host using your preferred shell, such as PuTTy or a remote Terminal connection.
|
||||
|
||||
2. From your shell, enter the following command:
|
||||
|
||||
```
|
||||
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher
|
||||
```
|
||||
|
||||
**Result:** Rancher is installed.
|
||||
|
||||
### 3. Log In
|
||||
|
||||
Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations.
|
||||
|
||||
1. Open a web browser and enter the IP address of your host: `https://<SERVER_IP>`.
|
||||
|
||||
Replace `<SERVER_IP>` with your host IP address.
|
||||
|
||||
2. When prompted, create a password for the default `admin` account there cowpoke!
|
||||
|
||||
3. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.<br/><br/>If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
|
||||
|
||||
<br/>
|
||||
|
||||
### 4. Create the Cluster
|
||||
|
||||
Welcome to Rancher! You are now able to create your first Kubernetes cluster.
|
||||
|
||||
In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-prem VM, or bare-metal) to be used in a cluster.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. From the **Clusters** page, click **Create**.
|
||||
2. Choose **Custom**.
|
||||
|
||||
3. Enter a **Cluster Name**.
|
||||
|
||||
4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later.
|
||||
|
||||
5. Click **Next**.
|
||||
|
||||
6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
|
||||
|
||||
7. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
|
||||
|
||||
8. Skip the **Labels** stuff. It's not important for now.
|
||||
|
||||
9. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
|
||||
|
||||
11. When you finish running the command on your Linux host, click **Done**.
|
||||
|
||||
**Result:**
|
||||
|
||||
Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
#### Finished
|
||||
|
||||
Congratulations! You have created your first cluster.
|
||||
|
||||
#### What's Next?
|
||||
|
||||
Use Rancher to create a deployment. For more information, see [Creating Deployments]({{<baseurl>}}/rancher/v2.6/en/quick-start-guide/workload).
|
||||
@@ -286,6 +286,36 @@ addons: |
|
||||
- configMap
|
||||
- projected
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:restricted
|
||||
rules:
|
||||
- apiGroups:
|
||||
- extensions
|
||||
resourceNames:
|
||||
- restricted
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: psp:restricted
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:restricted
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:serviceaccounts
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:authenticated
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
|
||||
@@ -39,3 +39,7 @@ This section contains information to help you troubleshoot issues when using Ran
|
||||
- [User ID Tracking in Audit Logs]({{<baseurl>}}/rancher/v2.6/en/troubleshooting/userid-tracking-in-audit-logs/)
|
||||
|
||||
Read more about how a Rancher Admin can trace an event from the Rancher audit logs and into the Kubernetes audit logs using the external Identity Provider username.
|
||||
|
||||
- [Expired Webhook Certificates]({{<baseurl>}}/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/)
|
||||
|
||||
Read more about how to rotate a Rancher webhook certificate secret after it expires on an annual basis.
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Rotation of Expired Webhook Certificates
|
||||
weight: 120
|
||||
---
|
||||
|
||||
For Rancher versions that have `rancher-webhook` installed, these certificates will expire after one year. It will be necessary for you to rotate your webhook certificate when this occurs.
|
||||
|
||||
Rancher will advise the community once there is a permanent solution in place for this known issue. Currently, there are two methods to work around this issue:
|
||||
|
||||
##### 1. Users with cluster access, run the following commands:
|
||||
```
|
||||
kubectl delete secret -n cattle-system cattle-webhook-tls
|
||||
kubectl delete pod -n cattle-system -l app=rancher-webhook
|
||||
```
|
||||
|
||||
##### 2. Users with no cluster access via `kubectl`:
|
||||
|
||||
1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster.
|
||||
|
||||
1. Delete the `rancher-webhook` pod in the `cattle-system` namespace in the local cluster.
|
||||
|
||||
**Note:** The webhook certificate expiration issue is not specific to `cattle-webhook-tls` as listed in the examples. You will fill in your expired certificate secret accordingly.
|
||||
@@ -113,7 +113,7 @@ You can define [add-ons]({{<baseurl>}}/rke/latest/en/config-options/add-ons/) to
|
||||
|
||||
### cri-dockerd
|
||||
|
||||
Kubernetes will remove code in the kubelet that interacts with Docker (dockershim) in Kubernetes 1.23. For more information, see [Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/). The component that replaces this code is called `cri-dockerd` and can be enabled using the following configuration:
|
||||
Kubernetes will remove code in the kubelet that interacts with Docker (dockershim) in a future Kubernetes release. For more information, see [Dockershim Deprecation FAQ: When will dockershim be removed?](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed). The component that replaces this code is called `cri-dockerd` and can be enabled using the following configuration:
|
||||
|
||||
```
|
||||
enable_cri_dockerd: true
|
||||
|
||||
@@ -39,33 +39,36 @@ nodes:
|
||||
|
||||
Besides the minimum set of options, there are many other options that are supported in RKE:
|
||||
|
||||
| Azure Configuration Options | Type | Required |
|
||||
|:----------------------------: |:------: |:---------:|
|
||||
| tenantId | string | * |
|
||||
| subscriptionId | string | * |
|
||||
| aadClientId | string | * |
|
||||
| aadClientSecret | string | * |
|
||||
| cloud | string | |
|
||||
| resourceGroup | string | |
|
||||
| location | string | |
|
||||
| vnetName | string | |
|
||||
| vnetResourceGroup | string | |
|
||||
| subnetName | string | |
|
||||
| securityGroupName | string | |
|
||||
| routeTableName | string | |
|
||||
| primaryAvailabilitySetName | string | |
|
||||
| vmType | string | |
|
||||
| primaryScaleSetName | string | |
|
||||
| aadClientCertPath | string | |
|
||||
| aadClientCertPassword | string | |
|
||||
| cloudProviderBackoff | bool | |
|
||||
| cloudProviderBackoffRetries | int | |
|
||||
| cloudProviderBackoffExponent | int | |
|
||||
| cloudProviderBackoffDuration | int | |
|
||||
| cloudProviderBackoffJitter | int | |
|
||||
| cloudProviderRateLimit | bool | |
|
||||
| cloudProviderRateLimitQPS | int | |
|
||||
| cloudProviderRateLimitBucket | int | |
|
||||
| useInstanceMetadata | bool | |
|
||||
| useManagedIdentityExtension | bool | |
|
||||
| maximumLoadBalancerRuleCount | int | |
|
||||
| Azure Configuration Options | Type | Required | Description |
|
||||
|:----------------------------: |:------: |:---------:|:-----------:|
|
||||
| tenantId | string | * | The Azure Active Directory (Azure AD) tenant ID for the subscription that the cluster is deployed in. |
|
||||
| subscriptionId | string | * | The ID of the Azure subscription that the cluster is deployed in. |
|
||||
| aadClientId | string | * | The client ID for an Azure AD application with RBAC access to talk to Azure Resource Manager APIs. This is used for [service principal](https://github.com/Azure/aks-engine/blob/master/docs/topics/service-principals.md) authentication. |
|
||||
| aadClientSecret | string | * | The client secret for an Azure AD application with RBAC access to talk to Azure Resource Manager APIs. This is used for [service principal](https://github.com/Azure/aks-engine/blob/master/docs/topics/service-principals.md) authentication. |
|
||||
| cloud | string | | The cloud environment identifier. Takes values from [here](https://github.com/Azure/go-autorest/blob/ec5f4903f77ed9927ac95b19ab8e44ada64c1356/autorest/azure/environments.go#L13). |
|
||||
| resourceGroup | string | | The name of the resource group that the Vnet is deployed in. |
|
||||
| location | string | | The location of the resource group that the cluster is deployed in. |
|
||||
| vnetName | string | | The name of the virtual network that the cluster is deployed in. |
|
||||
| vnetResourceGroup | string | | The name of the resource group that the virtual network is deployed in. |
|
||||
| subnetName | string | | The name of the subnet that the cluster is deployed in. |
|
||||
| securityGroupName | string | | The name of the security group attached to the cluster's subnet. |
|
||||
| routeTableName | string | | The name of the route table attached to the subnet that the cluster is deployed in. |
|
||||
| primaryAvailabilitySetName | string | | The name of the availability set that should be used as the load balancer backend. If this is set, the Azure cloud provider will only add nodes from that availability set to the load balancer backend pool. If this is not set, and multiple agent pools (availability sets) are used, then the cloud provider will try to add all nodes to a single backend pool which is forbidden. In other words, if you use multiple agent pools (availability sets), you **must** set this field. |
|
||||
| vmType | string | | The type of Azure nodes. Candidate values are: `vmss` and `standard`. If not set, it will be default to `standard`. Set to `vmss` if the cluster is running on [Azure virtual machine scale sets](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview) instead of standard machines. |
|
||||
| primaryScaleSetName | string | | The name of the scale set that should be used as the load balancer backend. If this is set, the Azure cloud provider will only add nodes from that scale set to the load balancer backend pool. If this is not set, and multiple agent pools (scale sets) are used, then the cloud provider will try to add all nodes to a single backend pool which is forbidden. In other words, if you use multiple agent pools (scale sets), you **must** set this field. |
|
||||
| aadClientCertPath | string | | The path of a client certificate for an Azure AD application with RBAC access to talk to Azure Resource Manager APIs. This is used for [client certificate authentication](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service). |
|
||||
| aadClientCertPassword | string | | The password of the client certificate for an Azure AD application with RBAC access to talk to Azure Resource Manager APIs. This is used for [client certificate authentication](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service). |
|
||||
| cloudProviderBackoff | bool | | Enable exponential backoff to manage resource request retries. |
|
||||
| cloudProviderBackoffRetries | int | | Backoff retry limit. |
|
||||
| cloudProviderBackoffExponent | int | | Backoff exponent. |
|
||||
| cloudProviderBackoffDuration | int | | Backoff duration. |
|
||||
| cloudProviderBackoffJitter | int | | Backoff jitter. |
|
||||
| cloudProviderRateLimit | bool | | Enable rate limiting. |
|
||||
| cloudProviderRateLimitQPS | int | | Rate limit QPS. |
|
||||
| cloudProviderRateLimitBucket | int | | Rate limit bucket Size. |
|
||||
| useInstanceMetadata | bool | | Use instance metadata service where possible. |
|
||||
| useManagedIdentityExtension | bool | | Use managed service identity for the virtual machine to access Azure Resource Manager APIs. This is used for [managed identity authentication](https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/overview). For user-assigned managed identity, `UserAssignedIdentityID` needs to be set. |
|
||||
| UserAssignedIdentityID | string | | The client ID of the user assigned Managed Service Identity (MSI) which is assigned to the underlying VMs. This is used for [managed identity authentication](https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/overview). |
|
||||
| maximumLoadBalancerRuleCount | int | | The limit enforced by Azure Load balancer. The default is `0` and maximum is `148`. |
|
||||
| LoadBalancerSku | string | | SKU of the load balancer and public IP. Valid values are `basic` or `standard`. Default(blank) to `basic`. |
|
||||
| ExcludeMasterFromStandardLB | bool | | Excludes master nodes (labeled with `node-role.kubernetes.io/master`) from the backend pool of Azure standard loadbalancer. Defaults to `nil`. |
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
---
|
||||
title: Tutorials
|
||||
weight: 10000
|
||||
---
|
||||
@@ -41,8 +41,8 @@
|
||||
</div>
|
||||
{{end}}
|
||||
{{ if in .Dir "os/v1.x" }}
|
||||
<div class="alert row">
|
||||
<strong>RancherOS 1.x is currently in a maintain-only-as-essential mode.</strong> It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see <a href="https://rancher.zendesk.com/hc/en-us/articles/360041771072-Could-you-help-us-understan[…]opment-and-support-status-of-RancherOS-for-2020-and-beyond-">this page.</a>
|
||||
<div class="alert alert-notice">
|
||||
<strong>RancherOS 1.x is currently in a maintain-only-as-essential mode.</strong> It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see <a href="https://rancher.com/docs/os/v1.x/en/support/"> this page.</a>
|
||||
</div>
|
||||
{{end}}
|
||||
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 19.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
viewBox="0 0 242.2 107.4" style="enable-background:new 0 0 242.2 107.4;" xml:space="preserve">
|
||||
<style type="text/css">
|
||||
.st0{fill:#2453FF;}
|
||||
</style>
|
||||
<g>
|
||||
<g>
|
||||
<path class="st0" d="M229,23.6l-2.5-14.9c-0.8-4.8-2.7-8.7-4.1-8.7c-1.5,0-2.7,4-2.7,8.8v3.9c0,4.8-4,8.8-8.8,8.8H207
|
||||
c-0.3,0-0.6,0-0.8,0v10.7c0.3,0,0.6,0,0.8,0h14.7C226.5,32.2,229.8,28.3,229,23.6"/>
|
||||
<path class="st0" d="M193.9,11h-23.7c-0.2,0-0.4,0-0.6,0h-24.4c-0.3,0-0.6,0-0.8,0.1V8.8c0-4.8-1.2-8.8-2.7-8.8s-3.3,3.9-4.1,8.7
|
||||
l-2.5,14.9c-0.8,4.8,2.5,8.7,7.4,8.7h14.6c1.5,0,2.9-0.2,4.2-0.6c-0.5,2.5-2.6,4.4-5.3,4.4h-20.5c-3.3,0-5.8-3-5.3-6.3l2.1-12.5
|
||||
c0.5-3.3-2-6.3-5.3-6.3H24.8c-2.2,0-4,1.3-4.9,3.2L0.7,43.5c-0.3,0.5-0.3,1.1,0.1,1.6l3.7,4.4c0.5,0.6,1.3,0.6,1.9,0.2l13.1-10.3
|
||||
V102c0,3,2.4,5.4,5.4,5.4h29c3,0,5.4-2.4,5.4-5.4V80.2c0-3,2.4-5.4,5.4-5.4h72.4c3,0,5.4,2.4,5.4,5.4V102c0,3,2.4,5.4,5.4,5.4h29
|
||||
c3,0,5.4-2.4,5.4-5.4V78.6h-15.4c-4.8,0-8.8-4-8.8-8.8V54.7c0-2.9,1.4-5.4,3.5-7v18c0,4.8,4,8.8,8.8,8.8h23.7c4.8,0,8.8-4,8.8-8.8
|
||||
V19.9C202.7,14.9,198.8,11,193.9,11"/>
|
||||
</g>
|
||||
<g>
|
||||
<path class="st0" d="M230.6,5.6c0-3.9,2.9-5.6,5.6-5.6s5.6,1.7,5.6,5.6c0,3.8-2.9,5.5-5.6,5.5S230.6,9.4,230.6,5.6z M240.5,5.6
|
||||
c0-3.1-2-4.4-4.2-4.4S232,2.5,232,5.6c0,3,2.1,4.4,4.3,4.4C238.5,9.9,240.5,8.6,240.5,5.6z M234.4,2.8h2c1,0,2,0.3,2,1.7
|
||||
c0,0.8-0.6,1.3-1.3,1.5l1.3,2.3h-1.2L236,6.1h-0.5v2.2h-1.1L234.4,2.8L234.4,2.8z M236.4,5.3c0.5,0,0.9-0.3,0.9-0.8
|
||||
c0-0.6-0.5-0.7-0.9-0.7h-1v1.5H236.4z"/>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 1.7 KiB |
@@ -0,0 +1,51 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 19.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
viewBox="0 0 637.2 93.8" style="enable-background:new 0 0 637.2 93.8;" xml:space="preserve">
|
||||
<style type="text/css">
|
||||
.st0{fill:#2453FF;}
|
||||
.st1{fill:#000000;}
|
||||
.st2{fill:#CCCCCC;}
|
||||
.st3{fill:#B3B3B3;}
|
||||
.st4{fill:#FFFFFF;}
|
||||
</style>
|
||||
<g>
|
||||
<g>
|
||||
<path class="st0" d="M200.7,20.6l-2.2-13c-0.7-4.2-2.3-7.6-3.6-7.6c-1.3,0-2.4,3.5-2.4,7.7v3.4c0,4.2-3.5,7.7-7.7,7.7h-3.4
|
||||
c-0.2,0-0.5,0-0.7,0v9.4c0.2,0,0.5,0,0.7,0h12.8C198.5,28.2,201.4,24.8,200.7,20.6"/>
|
||||
<path class="st0" d="M170,9.6h-20.8c-0.2,0-0.3,0-0.5,0h-21.3c-0.3,0-0.5,0-0.7,0.1v-2c0-4.2-1.1-7.7-2.4-7.7
|
||||
c-1.3,0-2.9,3.4-3.6,7.6l-2.2,13c-0.7,4.2,2.2,7.6,6.4,7.6h12.8c1.3,0,2.6-0.2,3.6-0.6c-0.4,2.2-2.3,3.8-4.6,3.8h-18
|
||||
c-2.9,0-5.1-2.6-4.6-5.5l1.8-10.9c0.5-2.9-1.7-5.5-4.6-5.5H22.1c-1.9,0-3.5,1.1-4.3,2.8L1,38c-0.3,0.4-0.3,1,0.1,1.4l3.3,3.9
|
||||
c0.4,0.5,1.1,0.6,1.6,0.2l11.4-9v54.8c0,2.6,2.1,4.7,4.7,4.7h25.4c2.6,0,4.7-2.1,4.7-4.7v-19c0-2.6,2.1-4.7,4.7-4.7h63.3
|
||||
c2.6,0,4.7,2.1,4.7,4.7v19c0,2.6,2.1,4.7,4.7,4.7h25.4c2.6,0,4.7-2.1,4.7-4.7V68.6h-13.5c-4.2,0-7.7-3.5-7.7-7.7V47.8
|
||||
c0-2.5,1.2-4.7,3.1-6.1v15.7c0,4.2,3.5,7.7,7.7,7.7H170c4.2,0,7.7-3.5,7.7-7.7v-40C177.7,13.1,174.2,9.6,170,9.6"/>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<path class="st1" d="M217.7,12.2h28.6c13.6,0,22.7,6.6,22.7,19.3c0,10.4-7.1,16.6-14,18.8c2.1,1.7,3.6,4.1,4.8,6.6
|
||||
c2.9,5.9,4.8,12.3,10.9,12.3c1.5,0,2.8-0.5,2.8-0.5L272.1,81c0,0-3.7,0.9-6.9,0.9c-8.2,0-12.9-3.2-17.8-14.2
|
||||
c-2.1-4.9-4.9-13.6-8.7-13.6h-3.9v27.4h-17.2V12.2z M234.9,24.7v17h6.2c4.9,0,10.7-1.5,10.7-8.9c0-6.1-3.9-8.1-8.6-8.1H234.9z"/>
|
||||
<path class="st1" d="M292.2,12.2h17.4l23.4,69.3h-17.4l-4.3-13.1h-23.2l-4.2,13.1h-15L292.2,12.2z M292.2,55.7h14.9l-4.7-14.6
|
||||
c-1.6-4.9-2.4-11.9-2.4-11.9h-0.4c0,0-1,7.1-2.6,11.8L292.2,55.7z"/>
|
||||
<path class="st1" d="M333.6,12.2H352l18.2,34.4c1.5,3,3.6,8.2,5.2,12.3h0.4c-0.2-3.9-0.7-9.4-0.7-13.5V12.2h14.1v69.3h-18
|
||||
l-18.9-34.3c-1.7-3.1-3.6-7.6-5-11.3h-0.4c0.3,3.9,0.8,8.5,0.8,12.3v33.3h-14.1V12.2z"/>
|
||||
<path class="st1" d="M392.9,46.5c0-25.1,12.4-35.4,31.6-35.4c20.2,0,28.3,11.1,26.1,26.1l-16,1.4c1.7-11-2.6-15.4-10.4-15.4
|
||||
c-7.5,0-13.6,5.5-13.6,23.4c0,18.9,6.6,23.7,14.1,23.7c7.1,0,12.8-4.4,11.6-13.5l15,1.5c1.1,14.1-9,24.4-27.5,24.4
|
||||
C405,82.8,392.9,71.7,392.9,46.5"/>
|
||||
<polygon class="st1" points="454.8,12.2 472,12.2 472,38.4 493,38.4 493,12.2 510.2,12.2 510.2,81.6 493,81.6 493,52.2 472,52.2
|
||||
472,81.6 454.8,81.6 "/>
|
||||
<polygon class="st1" points="517.1,12.2 563,12.2 563,25 534.2,25 534.2,39.9 558.3,39.9 558.3,52.6 534.2,52.6 534.2,68.8
|
||||
564,68.8 564,81.6 517.1,81.6 "/>
|
||||
<path class="st1" d="M567.3,12.2h28.6c13.6,0,22.7,6.6,22.7,19.3c0,10.4-7.1,16.6-14,18.8c2.1,1.7,3.6,4.1,4.8,6.6
|
||||
c2.9,5.9,4.8,12.3,10.9,12.3c1.5,0,2.8-0.5,2.8-0.5L621.7,81c0,0-3.7,0.9-6.9,0.9c-8.2,0-12.9-3.2-17.8-14.2
|
||||
c-2.1-4.9-4.9-13.6-8.7-13.6h-3.9v27.4h-17.2V12.2z M584.4,24.7v17h6.2c4.9,0,10.7-1.5,10.7-8.9c0-6.1-3.9-8.1-8.6-8.1H584.4z"/>
|
||||
</g>
|
||||
<g>
|
||||
<path class="st1" d="M625.2,16.6c0-3.9,2.9-5.6,5.6-5.6c2.7,0,5.6,1.7,5.6,5.6c0,3.8-2.9,5.5-5.6,5.5
|
||||
C628.2,22.2,625.2,20.5,625.2,16.6z M635.1,16.6c0-3.1-2-4.4-4.2-4.4c-2.2,0-4.3,1.3-4.3,4.4c0,3,2.1,4.4,4.3,4.4
|
||||
C633.1,21,635.1,19.7,635.1,16.6z M629,13.8h2c1,0,2,0.3,2,1.7c0,0.8-0.6,1.3-1.3,1.5l1.3,2.3h-1.2l-1.2-2.2h-0.5v2.2H629V13.8z
|
||||
M631.1,16.3c0.5,0,0.9-0.3,0.9-0.8c0-0.6-0.5-0.7-0.9-0.7h-1v1.5H631.1z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 3.5 KiB |
Reference in New Issue
Block a user