mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-30 08:35:32 +00:00
Catherine Luse
GitHub
@@ -59,4 +59,45 @@ These options can be passed in with the command line, or in the [configuration f
|
||||
| `--etcd-snapshot-retention` value | Number of snapshots to retain (default: 5) |
|
||||
| `--etcd-snapshot-dir` value | Directory to save db snapshots. (Default location: `${data-dir}/db/snapshots`) |
|
||||
| `--cluster-reset` | Forget all peers and become sole member of a new cluster. This can also be set with the environment variable `[$K3S_CLUSTER_RESET]`.
|
||||
| `--cluster-reset-restore-path` value | Path to snapshot file to be restored
|
||||
| `--cluster-reset-restore-path` value | Path to snapshot file to be restored
|
||||
|
||||
### S3 Compatible API Support
|
||||
|
||||
K3s supports writing etcd snapshots to and restoring etcd snapshots from systems with S3-compatible APIs. S3 support is available for both on-demand and scheduled snapshots.
|
||||
|
||||
The arguments below have been added to the `server` subcommand. These flags exist for the `etcd-snapshot` subcommand as well however the `--etcd-s3` portion is removed to avoid redundancy.
|
||||
|
||||
| Options | Description |
|
||||
| ----------- | --------------- |
|
||||
| `--etcd-s3` | Enable backup to S3 |
|
||||
| `--etcd-s3-endpoint` | S3 endpoint url |
|
||||
| `--etcd-s3-endpoint-ca` | S3 custom CA cert to connect to S3 endpoint |
|
||||
| `--etcd-s3-skip-ssl-verify` | Disables S3 SSL certificate validation |
|
||||
| `--etcd-s3-access-key` | S3 access key |
|
||||
| `--etcd-s3-secret-key` | S3 secret key" |
|
||||
| `--etcd-s3-bucket` | S3 bucket name |
|
||||
| `--etcd-s3-region` | S3 region / bucket location (optional). defaults to us-east-1 |
|
||||
| `--etcd-s3-folder` | S3 folder |
|
||||
|
||||
To perform an on-demand etcd snapshot and save it to S3:
|
||||
|
||||
```
|
||||
k3s etcd-snapshot \
|
||||
--s3 \
|
||||
--s3-bucket=<S3-BUCKET-NAME> \
|
||||
--s3-access-key=<S3-ACCESS-KEY> \
|
||||
--s3-secret-key=<S3-SECRET-KEY>
|
||||
```
|
||||
|
||||
To perform an on-demand etcd snapshot restore from S3, first make sure that K3s isn't running. Then run the following commands:
|
||||
|
||||
```
|
||||
k3s server \
|
||||
--cluster-init \
|
||||
--cluster-reset \
|
||||
--etcd-s3 \
|
||||
--cluster-reset-restore-path=<SNAPSHOT-NAME> \
|
||||
--etcd-s3-bucket=<S3-BUCKET-NAME> \
|
||||
--etcd-s3-access-key=<S3-ACCESS-KEY> \
|
||||
--etcd-s3-secret-key=<S3-SECRET-KEY>
|
||||
```
|
||||
|
||||
@@ -2040,7 +2040,7 @@ Where access to the Kubernetes API from a pod is required, a specific service ac
|
||||
The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
</details>
|
||||
|
||||
**Result:** Fail. Currently requires operator intervention See the [Harending Guide](../hardening_guide/_) for details.
|
||||
**Result:** Fail. Currently requires operator intervention See the [Hardening Guide]({{<baseurl>}}/rancher/k3s/latest/en/security/hardening_guide) for details.
|
||||
|
||||
**Audit:**
|
||||
For each namespace in the cluster, review the rights assigned to the default service account and ensure that it has no roles or cluster roles bound to it apart from the defaults. Additionally ensure that the automountServiceAccountToken: false setting is in place for each default service account.
|
||||
|
||||
@@ -5,6 +5,8 @@ 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://support.rancher.com/hc/en-us/articles/360041771072#development-status-0-0)
|
||||
|
||||
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.
|
||||
|
||||
Another way in which RancherOS is designed specifically for running Docker is that it always runs the latest version of Docker. This allows users to take advantage of the latest Docker capabilities and bug fixes.
|
||||
|
||||
@@ -8,6 +8,7 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/backups/backups/single-node-backups/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backup/single-node-backups/
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/docker-backups
|
||||
- /rancher/v2.0-v2.4/en/installation/backups-and-restoration/single-node-backup-and-restoration/
|
||||
---
|
||||
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ The binary can be downloaded directly from the UI. The link can be found in the
|
||||
|
||||
After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires:
|
||||
|
||||
- Your [Rancher Server URL]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/server-url), which is used to connect to Rancher Server.
|
||||
- Your Rancher Server URL, which is used to connect to Rancher Server.
|
||||
- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key]({{<baseurl>}}/rancher/v2.0-v2.4/en/user-settings/api-keys/).
|
||||
|
||||
### CLI Authentication
|
||||
|
||||
@@ -5,7 +5,7 @@ weight: 2030
|
||||
|
||||
After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. Depending on the [option used]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/) to provision the cluster, there are different node options available.
|
||||
|
||||
> If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.0-v2.4/en/k8s-in-rancher/editing-clusters).
|
||||
> If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.0-v2.4/en/cluster-admin/editing-clusters/#editing-clusters-with-yaml).
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
|
||||
@@ -53,7 +53,16 @@ Using Prometheus, you can monitor Rancher at both the cluster level and [project
|
||||
|
||||
As an [administrator]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster.
|
||||
|
||||
> **Prerequisite:** Make sure that you are allowing traffic on port 9796 for each of your nodes because Prometheus will scrape metrics from here.
|
||||
> **Prerequisite:** The following TCP ports need to be opened for metrics scraping:
|
||||
>
|
||||
> | Port | Node type | Component |
|
||||
> | --- | --- | --- |
|
||||
> | 9796 | Worker | Node exporter |
|
||||
> | 10254 | Worker | Nginx Ingress Controller |
|
||||
> | 10250 | Worker/Controlplane | Kubelet |
|
||||
> | 10251 | Controlplane | Kube scheduler |
|
||||
> | 10252 | Controlplane | Kube controller manager |
|
||||
> | 2379 | Etcd | Etcd server |
|
||||
|
||||
1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring.
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ The cluster cannot be downgraded to a previous Kubernetes version.
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The options below are available only for [Rancher-launched RKE Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) and [imported K3s Kubernetes clusters.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters)
|
||||
> - The options below are available only for [Rancher-launched RKE Kubernetes clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/) and imported/registered K3s Kubernetes clusters.
|
||||
> - Before upgrading Kubernetes, [back up your cluster.]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups)
|
||||
|
||||
1. From the **Global** view, find the cluster for which you want to upgrade Kubernetes. Select **⋮ > Edit**.
|
||||
|
||||
@@ -5,6 +5,7 @@ weight: 2031
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/tasks/clusters/adding-storage/
|
||||
- /rancher/v2.0-v2.4/en/cluster-admin/volumes-and-storage/persistent-volume-claims/
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/
|
||||
---
|
||||
When deploying an application that needs to retain data, you'll need to create persistent storage. Persistent storage allows you to store application data external from the pod running your application. This storage practice allows you to maintain application data, even if the application's pod fails.
|
||||
|
||||
|
||||
+1
-1
@@ -25,7 +25,7 @@ Creating a persistent volume in Rancher will not create a storage volume. It onl
|
||||
|
||||
The steps to set up a persistent storage device will differ based on your infrastructure. We provide examples of how to set up storage using [vSphere,](../examples/vsphere) [NFS,](../examples/nfs) or Amazon's [EBS.](../examples/ebs)
|
||||
|
||||
If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/longhorn)
|
||||
If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster.
|
||||
|
||||
### 2. Add a persistent volume that refers to the persistent storage
|
||||
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ This section assumes that you understand the Kubernetes concepts of storage clas
|
||||
|
||||
New storage is often provisioned by a cloud provider such as Amazon EBS. However, new storage doesn't have to be in the cloud.
|
||||
|
||||
If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster. For more information, see [this page.]({{<baseurl>}}/rancher/v2.0-v2.4/en/longhorn)
|
||||
If you have a pool of block storage, and you don't want to use a cloud provider, Longhorn could help you provide persistent storage to your Kubernetes cluster.
|
||||
|
||||
To provision new storage for your workloads, follow these steps:
|
||||
|
||||
|
||||
+1
-1
@@ -19,4 +19,4 @@ headless: true
|
||||
| [Configuring Pod Security Policies]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/pod-security-policy/) | ✓ | | |
|
||||
| [Running Security Scans]({{<baseurl>}}/rancher/v2.0-v2.4/en/security/security-scan/) | ✓ | | |
|
||||
|
||||
\* Cluster configuration options can't be edited for imported clusters, except for [K3s clusters.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters)
|
||||
\* Cluster configuration options can't be edited for imported clusters, except for K3s clusters.
|
||||
|
||||
@@ -108,7 +108,7 @@ The ports required to be open are different depending on how the user cluster is
|
||||
|
||||
For a breakdown of the port requirements for etcd nodes, controlplane nodes, and worker nodes in a Kubernetes cluster, refer to the [port requirements for the Rancher Kubernetes Engine.]({{<baseurl>}}/rke/latest/en/os/#ports)
|
||||
|
||||
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/ports#downstream-kubernetes-cluster-nodes)).
|
||||
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/ports#downstream-kubernetes-cluster-nodes).
|
||||
|
||||
# Optional: Security Considerations
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ Typically, most applications are deployed on a single Kubernetes cluster, but th
|
||||
|
||||
Any Helm charts from a global catalog can be used to deploy and manage multi-cluster applications.
|
||||
|
||||
After creating a multi-cluster application, you can program a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/globaldns/) to make it easier to access the application.
|
||||
After creating a multi-cluster application, you can program a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/) to make it easier to access the application.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Launching a multi-cluster app](#launching-a-multi-cluster-app)
|
||||
|
||||
@@ -102,4 +102,4 @@ _Available as v2.2.0_
|
||||
|
||||
When creating applications that span multiple Kubernetes clusters, a Global DNS entry can be created to route traffic to the endpoints in all of the different clusters. An external DNS server will need be programmed to assign a fully qualified domain name (a.k.a FQDN) to your application. Rancher will use the FQDN you provide and the IP addresses where your application is running to program the DNS. Rancher will gather endpoints from all the Kubernetes clusters running your application and program the DNS.
|
||||
|
||||
For more information on how to use this feature, see [Global DNS]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/globaldns/).
|
||||
For more information on how to use this feature, see [Global DNS]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/).
|
||||
|
||||
@@ -8,7 +8,7 @@ aliases:
|
||||
|
||||
Within a project, when you want to deploy applications from catalogs, the applications available in your project will be based on the [scope of the catalogs]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/legacy-catalogs/#catalog-scopes).
|
||||
|
||||
If your application is using ingresses, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/globaldns/).
|
||||
If your application is using ingresses, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/).
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Launching a catalog app](#launching-a-catalog-app)
|
||||
|
||||
+1
@@ -6,6 +6,7 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap-single-node/install-rancher
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap/install-rancher
|
||||
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/install-rancher/
|
||||
---
|
||||
|
||||
This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
|
||||
|
||||
+2
-2
@@ -164,7 +164,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
|
||||
--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
|
||||
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
@@ -218,7 +218,7 @@ If you are installing Rancher versions before v2.3.0, you will not be able to us
|
||||
These resources could be helpful when installing Rancher:
|
||||
|
||||
- [Rancher Helm chart options]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/chart-options/)
|
||||
- [Adding TLS secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/tls-secrets/)
|
||||
- [Adding TLS secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/)
|
||||
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/options/troubleshooting/)
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
+1
@@ -4,6 +4,7 @@ weight: 30
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/troubleshooting-ha/404-default-backend/
|
||||
- /rancher/v2.0-v2.4/en/installation/options/helm2/rke-add-on/troubleshooting/404-default-backend
|
||||
- /404-default-backend/
|
||||
---
|
||||
|
||||
> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
|
||||
|
||||
+1
@@ -4,6 +4,7 @@ weight: 370
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/troubleshooting-ha/
|
||||
- /rancher/v2.0-v2.4/en/installation/options/helm2/rke-add-on/troubleshooting
|
||||
- /rancher/v2.0-v2.4/en/installation/resources/advanced/helm2/rke-add-on/troubleshooting/404-default-backend/
|
||||
---
|
||||
|
||||
> #### **Important: RKE add-on install is only supported up to Rancher v2.0.8**
|
||||
|
||||
@@ -76,7 +76,7 @@ $ helm ls -A
|
||||
|
||||
Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade.
|
||||
|
||||
If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using [custom certificates]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-Kubernetes/#6-install-rancher-with-helm-and-your-chosen-certificate-option).
|
||||
If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using custom certificates.
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
|
||||
@@ -44,7 +44,7 @@ For more information, see [Ingress]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-ra
|
||||
|
||||
When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
For more information, see [Global DNS]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/globaldns/).
|
||||
For more information, see [Global DNS]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/).
|
||||
|
||||
## Service Discovery
|
||||
|
||||
|
||||
@@ -60,4 +60,4 @@ Ingress can provide other functionality as well, such as SSL termination, name-b
|
||||
|
||||
- For more information on how to set up ingress in Rancher, see [Ingress]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/load-balancers-and-ingress/ingress).
|
||||
- For complete information about ingress and ingress controllers, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/)
|
||||
- When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry, see [Global DNS]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/globaldns/).
|
||||
- When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry, see [Global DNS]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/).
|
||||
|
||||
+1
-1
@@ -7,7 +7,7 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/load-balancers-and-ingress/ingress
|
||||
---
|
||||
|
||||
Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/globaldns/).
|
||||
Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.0-v2.4/en/helm-charts/globaldns/).
|
||||
|
||||
1. From the **Global** view, open the project that you want to add ingress to.
|
||||
1. Click **Resources** in the main navigation bar. Click the **Load Balancing** tab. (In versions before v2.3.0, just click the **Load Balancing** tab.) Then click **Add Ingress**.
|
||||
|
||||
@@ -3,6 +3,7 @@ title: Project Administration
|
||||
weight: 9
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/project-admin/editing-projects/
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/editing-projects/
|
||||
---
|
||||
|
||||
_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Project Resource Quotas
|
||||
weight: 2515
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/resource-quotas
|
||||
---
|
||||
|
||||
_Available as of v2.1.0_
|
||||
|
||||
@@ -196,7 +196,7 @@ services:
|
||||
|
||||
> **Note:** As the `kubelet` is running inside a container, the path for files located in `/etc` and `/usr` are in `/host/etc` and `/host/usr` inside the `kubelet` container.
|
||||
|
||||
See [Editing Cluster as YAML]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/editing-clusters/#editing-cluster-as-yaml) how to apply this change. When the provisioning of the cluster has finished, you have to remove the kube-dns pod to activate the new setting in the pod:
|
||||
See [Editing Cluster as YAML]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/editing-clusters/#editing-clusters-with-yaml) how to apply this change. When the provisioning of the cluster has finished, you have to remove the kube-dns pod to activate the new setting in the pod:
|
||||
|
||||
```
|
||||
kubectl delete pods -n kube-system -l k8s-app=kube-dns
|
||||
|
||||
@@ -104,7 +104,7 @@ A restore is performed by creating a Restore custom resource. For a tutorial, re
|
||||
|
||||
# Migrating Rancher to a New Cluster
|
||||
|
||||
A migration is performed by following [these steps.](./migrating-rancher)
|
||||
A migration is performed by following [these steps.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
|
||||
|
||||
# Default Storage Location Configuration
|
||||
|
||||
|
||||
@@ -7,6 +7,8 @@ aliases:
|
||||
|
||||
In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer the instructions for [single node backups]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/docker-installs/docker-backups)
|
||||
|
||||
The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Rancher version must be v2.5.0 and up
|
||||
@@ -17,7 +19,7 @@ The backup storage location is an operator-level setting, so it needs to be conf
|
||||
|
||||
Backups are created as .tar.gz files. These files can be pushed to S3 or Minio, or they can be stored in a persistent volume.
|
||||
|
||||
1. In the Rancher UI, go to the **Cluster Explorer.**
|
||||
1. In the Rancher UI, go to the **Cluster Explorer** view for the local cluster.
|
||||
1. Click **Apps.**
|
||||
1. Click **Rancher Backups.**
|
||||
1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config)
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
title: Migrating Rancher to a New Cluster
|
||||
weight: 3
|
||||
aliases:
|
||||
- /rancher/v2.5/en/backups/v2.5/migrating-rancher
|
||||
---
|
||||
|
||||
If you are migrating Rancher to a new Kubernetes cluster, you don't need to install Rancher on the new cluster first. If Rancher is restored to a new cluster with Rancher already installed, it can cause problems.
|
||||
|
||||
@@ -10,14 +10,14 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.](../migrating-rancher)
|
||||
> * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
|
||||
> * While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore.
|
||||
|
||||
### Create the Restore Custom Resource
|
||||
|
||||
1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.**
|
||||
1. Click **Restore.**
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.5/en/backups/configuration/restore-config) and to the [examples.]({{<baseurl>}}/rancher/v2.5/en/backups/examples)
|
||||
1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Restore YAML.
|
||||
|
||||
```yaml
|
||||
@@ -38,7 +38,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
|
||||
For help configuring the Restore, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
For help configuring the Restore, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.5/en/backups/configuration/restore-config) and to the [examples.]({{<baseurl>}}/rancher/v2.5/en/backups/examples)
|
||||
|
||||
1. Click **Create.**
|
||||
|
||||
@@ -50,12 +50,11 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
### Logs
|
||||
|
||||
To check how the restore is progressing, you can check the logs of the operator. Follow these steps to get the logs:
|
||||
To check how the restore is progressing, you can check the logs of the operator. Run this command to follow the logs:
|
||||
|
||||
```yaml
|
||||
kubectl get pods -n cattle-resources-system
|
||||
kubectl logs <pod name from above command> -n cattle-resources-system -f
|
||||
```
|
||||
kubectl logs -n cattle-resources-system -l app.kubernetes.io/name=rancher-backup -f
|
||||
|
||||
|
||||
### Cleanup
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ aliases:
|
||||
|
||||
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. This is not different when using Kubernetes and Rancher. Fortunately the integrated monitoring and alerting functionality makes this whole process a lot easier.
|
||||
|
||||
The [Rancher Documentation]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/v2.5/) describes in detail, how you can set up a complete Prometheus and Grafana stack. Out of the box this will scrape monitoring data from all system and Kubernetes components in your cluster and provide sensible dashboards and alerts for them to get started. But for a reliable setup, you also need to monitor your own workloads and adapt Prometheus and Grafana to your own specific use cases and cluster sizes. This document aims to give you best practices for this.
|
||||
The [Rancher monitoring documentation]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/) describes how you can set up a complete Prometheus and Grafana stack. Out of the box this will scrape monitoring data from all system and Kubernetes components in your cluster and provide sensible dashboards and alerts for them to get started. But for a reliable setup, you also need to monitor your own workloads and adapt Prometheus and Grafana to your own specific use cases and cluster sizes. This document aims to give you best practices for this.
|
||||
|
||||
- [What to Monitor](#what-to-monitor)
|
||||
- [Configuring Prometheus Resource Usage](#configuring-prometheus-resource-usage)
|
||||
|
||||
@@ -18,7 +18,7 @@ The binary can be downloaded directly from the UI. The link can be found in the
|
||||
|
||||
After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires:
|
||||
|
||||
- Your [Rancher Server URL]({{<baseurl>}}/rancher/v2.5/en/admin-settings/server-url), which is used to connect to Rancher Server.
|
||||
- Your Rancher Server URL, which is used to connect to Rancher Server.
|
||||
- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key]({{<baseurl>}}/rancher/v2.5/en/user-settings/api-keys/).
|
||||
|
||||
### CLI Authentication
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
title: Removing Kubernetes Components from Nodes
|
||||
description: Learn about cluster cleanup when removing nodes from your Rancher-launched Kubernetes cluster. What is removed, how to do it manually
|
||||
weight: 2055
|
||||
aliases:
|
||||
- /rancher/v2.5/en/faq/cleaning-cluster-nodes/
|
||||
---
|
||||
|
||||
This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes.
|
||||
|
||||
@@ -5,6 +5,7 @@ aliases:
|
||||
- /rancher/v2.5/en/tasks/clusters/adding-managing-cluster-members/
|
||||
- /rancher/v2.5/en/k8s-in-rancher/cluster-members/
|
||||
- /rancher/v2.5/en/cluster-admin/cluster-members
|
||||
- /rancher/v2.5/en/cluster-provisioning/cluster-members/
|
||||
---
|
||||
|
||||
If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Cluster Configuration
|
||||
weight: 2025
|
||||
aliases:
|
||||
- /rancher/v2.5/en/k8s-in-rancher/editing-clusters
|
||||
---
|
||||
|
||||
After you provision a Kubernetes cluster using Rancher, you can still edit options and settings for the cluster.
|
||||
@@ -36,7 +38,7 @@ Option | Description |
|
||||
Nginx Ingress | If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use Nginx ingress within the cluster. |
|
||||
Metrics Server Monitoring | Each cloud provider capable of launching a cluster using RKE can collect metrics and monitor for your cluster nodes. Enable this option to view your node metrics from your cloud provider's portal. |
|
||||
Pod Security Policy Support | Enables [pod security policies]({{<baseurl>}}/rancher/v2.5/en/admin-settings/pod-security-policies/) for the cluster. After enabling this option, choose a policy using the **Default Pod Security Policy** drop-down. |
|
||||
Docker version on nodes | Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support. If you choose to require a [supported Docker version]({{<baseurl>}}/rancher/v2.5/en/installation/options/rke-add-on/layer-7-lb/), Rancher will stop pods from running on nodes that don't have a supported Docker version installed. |
|
||||
Docker version on nodes | Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support. If you choose to require a supported Docker version, Rancher will stop pods from running on nodes that don't have a supported Docker version installed. |
|
||||
Docker Root Directory | The directory on your cluster nodes where you've installed Docker. If you install Docker on your nodes to a non-default directory, update this path. |
|
||||
Default Pod Security Policy | If you enable **Pod Security Policy Support**, use this drop-down to choose the pod security policy that's applied to the cluster. |
|
||||
Cloud Provider | If you're using a cloud provider to host cluster nodes launched by RKE, enable [this option]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/cloud-providers/) so that you can use the cloud provider's native features. If you want to store persistent data for your cloud-hosted cluster, this option is required. |
|
||||
|
||||
@@ -12,7 +12,7 @@ This section covers the following topics:
|
||||
- [Node options available for each cluster creation option](#node-options-available-for-each-cluster-creation-option)
|
||||
- [Nodes hosted by an infrastructure provider](#nodes-hosted-by-an-infrastructure-provider)
|
||||
- [Nodes provisioned by hosted Kubernetes providers](#nodes-provisioned-by-hosted-kubernetes-providers)
|
||||
- [Imported nodes](#imported-nodes)
|
||||
- [Registered nodes](#registered-nodes)
|
||||
- [Managing and editing individual nodes](#managing-and-editing-individual-nodes)
|
||||
- [Viewing a node in the Rancher API](#viewing-a-node-in-the-rancher-api)
|
||||
- [Deleting a node](#deleting-a-node)
|
||||
@@ -29,21 +29,24 @@ This section covers the following topics:
|
||||
# Node Options Available for Each Cluster Creation Option
|
||||
|
||||
The following table lists which node options are available for each type of cluster in Rancher. Click the links in the **Option** column for more detailed information about each feature.
|
||||
| Option | [Nodes Hosted by an Infrastructure Provider][1] | [Custom Node][2] | [Hosted Cluster][3] | [Registered EKS Nodes][4] | [All Other Registered Nodes][5] | Description |
|
||||
| ------------------------------------------------ | ------------------------------------------------ | ---------------- | ------------------- | ------------------- | -------------------| ------------------------------------------------------------------ |
|
||||
| [Cordon](#cordoning-a-node) | ✓ | ✓ | ✓ | ✓ | ✓ | Marks the node as unschedulable. |
|
||||
| [Drain](#draining-a-node) | ✓ | ✓ | ✓ | ✓ | ✓ | Marks the node as unschedulable _and_ evicts all pods. |
|
||||
| [Edit](#managing-and-editing-individual-nodes) | ✓ | ✓ | ✓ | ✓ | ✓ | Enter a custom name, description, label, or taints for a node. |
|
||||
| [View API](#viewing-a-node-in-the-rancher-api) | ✓ | ✓ | ✓ | ✓ | ✓ | View API data. |
|
||||
| [Delete](#deleting-a-node) | ✓ | ✓ | | * | * | Deletes defective nodes from the cluster. |
|
||||
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | | Download SSH key in order to SSH into the node. |
|
||||
| [Node Scaling](#scaling-nodes) | ✓ | | | ✓ | | Scale the number of nodes in the node pool up or down. |
|
||||
|
||||
| Option | [Nodes Hosted by an Infrastructure Provider][1] | [Custom Node][2] | [Hosted Cluster][3] | [Registered Nodes][4] | Description |
|
||||
| ------------------------------------------------ | ------------------------------------------------ | ---------------- | ------------------- | ------------------- | ------------------------------------------------------------------ |
|
||||
| [Cordon](#cordoning-a-node) | ✓ | ✓ | ✓ | | Marks the node as unschedulable. |
|
||||
| [Drain](#draining-a-node) | ✓ | ✓ | ✓ | | Marks the node as unschedulable _and_ evicts all pods. |
|
||||
| [Edit](#managing-and-editing-individual-nodes) | ✓ | ✓ | ✓ | | Enter a custom name, description, label, or taints for a node. |
|
||||
| [View API](#viewing-a-node-in-the-rancher-api) | ✓ | ✓ | ✓ | | View API data. |
|
||||
| [Delete](#deleting-a-node) | ✓ | ✓ | | | Deletes defective nodes from the cluster. |
|
||||
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | Download SSH key for in order to SSH into the node. |
|
||||
| [Node Scaling](#scaling-nodes) | ✓ | | | | Scale the number of nodes in the node pool up or down. |
|
||||
[1]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
|
||||
[2]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/
|
||||
[3]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
|
||||
[4]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
|
||||
[5]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
|
||||
|
||||
\* Delete option accessible via View API
|
||||
|
||||
[1]: {{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/
|
||||
[2]: {{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/custom-nodes/
|
||||
[3]: {{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/
|
||||
[4]: {{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/
|
||||
|
||||
### Nodes Hosted by an Infrastructure Provider
|
||||
|
||||
@@ -59,9 +62,9 @@ Rancher uses [node templates]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning
|
||||
|
||||
Options for managing nodes [hosted by a Kubernetes provider]({{<baseurl >}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/) are somewhat limited in Rancher. Rather than using the Rancher UI to make edits such as scaling the number of nodes up or down, edit the cluster directly.
|
||||
|
||||
### Imported Nodes
|
||||
### Registered Nodes
|
||||
|
||||
Although you can deploy workloads to an [imported cluster]({{< baseurl >}}/rancher/v2.5/en/cluster-provisioning/imported-clusters/) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher.
|
||||
Although you can deploy workloads to a [registered cluster]({{< baseurl >}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher.
|
||||
|
||||
# Managing and Editing Individual Nodes
|
||||
|
||||
|
||||
+2
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Setting up Existing Storage
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.5/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/
|
||||
---
|
||||
|
||||
This section describes how to set up existing persistent storage for workloads in Rancher.
|
||||
|
||||
@@ -19,4 +19,4 @@ headless: true
|
||||
| [Configuring Pod Security Policies]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/pod-security-policy/) | ✓ | | |
|
||||
| [Running Security Scans]({{<baseurl>}}/rancher/v2.5/en/security/security-scan/) | ✓ | | |
|
||||
|
||||
\* Cluster configuration options can't be edited for imported clusters, except for [K3s clusters.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters)
|
||||
\* Cluster configuration options can't be edited for imported clusters, except for [K3s clusters.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/imported-clusters/)
|
||||
|
||||
@@ -106,7 +106,7 @@ The ports required to be open are different depending on how the user cluster is
|
||||
|
||||
For a breakdown of the port requirements for etcd nodes, controlplane nodes, and worker nodes in a Kubernetes cluster, refer to the [port requirements for the Rancher Kubernetes Engine.]({{<baseurl>}}/rke/latest/en/os/#ports)
|
||||
|
||||
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](({{<baseurl>}}/rancher/v2.5/en/installation/requirements/ports#downstream-kubernetes-cluster-nodes)).
|
||||
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements]({{<baseurl>}}/rancher/v2.5/en/installation/requirements/ports#downstream-kubernetes-cluster-nodes).
|
||||
|
||||
# Optional: Security Considerations
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Registering Existing Clusters
|
||||
weight: 6
|
||||
aliases:
|
||||
- /rancher/v2.5/en/cluster-provisioning/imported-clusters
|
||||
---
|
||||
|
||||
_Available as of v2.5_
|
||||
@@ -45,7 +47,7 @@ If you are registering a K3s cluster, make sure the `cluster.yml` is readable. I
|
||||
2. Choose **Register**.
|
||||
3. Enter a **Cluster Name**.
|
||||
4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
5. For Rancher v2.5.6+, use **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent]({{<baseurl>}}rancher/v2.5/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
5. For Rancher v2.5.6+, use **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
6. Click **Create**.
|
||||
7. The prerequisite for `cluster-admin` privileges is shown (see **Prerequisites** above), including an example command to fulfil the prerequisite.
|
||||
8. Copy the `kubectl` command to your clipboard and run it on a node where kubeconfig is configured to point to the cluster you want to import. If you are unsure it is configured correctly, run `kubectl get nodes` to verify before running the command shown in Rancher.
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ When using the `Amazon` cloud provider, you can leverage the following capabilit
|
||||
- **Load Balancers:** Launches an AWS Elastic Load Balancer (ELB) when choosing `Layer-4 Load Balancer` in **Port Mapping** or when launching a `Service` with `type: LoadBalancer`.
|
||||
- **Persistent Volumes**: Allows you to use AWS Elastic Block Stores (EBS) for persistent volumes.
|
||||
|
||||
See [cloud-provider-aws README](https://github.com/kubernetes/cloud-provider-aws/blob/master/README.md) for all information regarding the Amazon cloud provider.
|
||||
See [cloud-provider-aws README](https://kubernetes.github.io/cloud-provider-aws/) for all information regarding the Amazon cloud provider.
|
||||
|
||||
To set up the Amazon cloud provider,
|
||||
|
||||
|
||||
@@ -142,7 +142,7 @@ Option to enable or disable [recurring etcd snapshots]({{<baseurl>}}/rke/latest/
|
||||
|
||||
_Available as of v2.5.6_
|
||||
|
||||
Option to set environment variables for [rancher agents]({{<baseurl>}}rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
Option to set environment variables for [rancher agents]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
|
||||
|
||||
# Cluster Config File
|
||||
|
||||
@@ -9,7 +9,7 @@ Typically, most applications are deployed on a single Kubernetes cluster, but th
|
||||
|
||||
Any Helm charts from a global catalog can be used to deploy and manage multi-cluster applications.
|
||||
|
||||
After creating a multi-cluster application, you can program a [Global DNS entry]({{<baseurl>}}/rancher/v2.5/en/catalog/globaldns/) to make it easier to access the application.
|
||||
After creating a multi-cluster application, you can program a global DNS entry to make it easier to access the application.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Launching a multi-cluster app](#launching-a-multi-cluster-app)
|
||||
@@ -99,7 +99,7 @@ If the Helm chart that you are deploying contains a `questions.yml` file, Ranche
|
||||
|
||||
### Key Value Pairs for Native Helm Charts
|
||||
|
||||
For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a [custom Helm chart repository]({{<baseurl>}}/rancher/v2.5/en/catalog/custom/), answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
|
||||
For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a custom Helm chart repository, answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
|
||||
|
||||
### Members
|
||||
|
||||
|
||||
@@ -2,7 +2,10 @@
|
||||
title: Helm Charts in Rancher
|
||||
weight: 11
|
||||
aliases:
|
||||
- rancher/v2.x/en/helm-charts/apps-marketplace
|
||||
- /rancher/v2.x/en/helm-charts/apps-marketplace
|
||||
- /rancher/v2.5/en/catalog/
|
||||
- /rancher/v2.5/en/catalog/apps
|
||||
- /rancher/v2.5/en/catalog/launching-apps
|
||||
---
|
||||
|
||||
In this section, you'll learn how to manage Helm chart repositories and applications in Rancher.
|
||||
|
||||
@@ -56,7 +56,7 @@ However, this option is useful if you want to save resources by using a single n
|
||||
|
||||
For test and demonstration purposes, Rancher can be installed with Docker on a single node.
|
||||
|
||||
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.5/en/backups/v2.5/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.5/en/backups/migrating-rancher)
|
||||
|
||||
### Other Options
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ For the tutorial to install an RKE Kubernetes cluster, refer to [this page.]({{<
|
||||
|
||||
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)
|
||||
|
||||
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)
|
||||
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)
|
||||
|
||||
# Install the Rancher Helm Chart
|
||||
|
||||
|
||||
@@ -77,13 +77,13 @@ For information on enabling experimental features, refer to [this page.]({{<base
|
||||
|
||||
Enabling the [API Audit Log]({{<baseurl>}}/rancher/v2.5/en/installation/api-auditing/).
|
||||
|
||||
You can collect this log as you would any container log. Enable the [Logging service under Rancher Tools]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/tools/logging/) for the `System` Project on the Rancher server cluster.
|
||||
You can collect this log as you would any container log. Enable [logging]({{<baseurl>}}/rancher/v2.5/en/logging) for the `System` Project on the Rancher server cluster.
|
||||
|
||||
```plain
|
||||
--set auditLog.level=1
|
||||
```
|
||||
|
||||
By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable the [Logging service under Rancher Tools]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/tools/logging/) for the Rancher server cluster or System Project.
|
||||
By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable [logging]({{<baseurl>}}/rancher/v2.5/en/logging) for the Rancher server cluster or System Project.
|
||||
|
||||
Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.
|
||||
|
||||
|
||||
@@ -24,14 +24,14 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.](../migrating-rancher)
|
||||
> * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
|
||||
> * While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore.
|
||||
|
||||
### Create the Restore Custom Resource
|
||||
|
||||
1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.**
|
||||
1. Click **Restore.**
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.5/en/backups/configuration/restore-config) and to the [examples.]({{<baseurl>}}/rancher/v2.5/en/backups/examples)
|
||||
1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Restore YAML.
|
||||
|
||||
```yaml
|
||||
@@ -52,7 +52,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
|
||||
For help configuring the Restore, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
For help configuring the Restore, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/configuration/restore-config/) and to the [examples.]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/examples/)
|
||||
|
||||
1. Click **Create.**
|
||||
|
||||
|
||||
@@ -24,8 +24,6 @@ For the instructions to upgrade Rancher installed with Docker, refer to [ths pag
|
||||
|
||||
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services]({{<baseurl>}}/rke/latest/en/config-options/services/) or [add-ons]({{<baseurl>}}/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE]({{<baseurl>}}/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
|
||||
|
||||
If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade]({{<baseurl>}}/rancher/v2.5/en/upgrades/upgrades/migrating-from-rke-add-on).
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Upgrade Outline](#upgrade-outline)
|
||||
- [Known Upgrade Issues](#known-upgrade-issues)
|
||||
@@ -51,7 +49,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository]({{
|
||||
|
||||
The upgrade instructions assume you are using Helm 3.
|
||||
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here]({{<baseurl>}}/rancher/v2.5/en/installation/upgrades-rollbacks/upgrades/ha/helm2)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/helm2)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
### For air gap installs: Populate private registry
|
||||
|
||||
@@ -258,7 +256,7 @@ Log into Rancher to confirm that the upgrade succeeded.
|
||||
|
||||
>**Having network issues following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/namespace-migration/#restoring-cluster-networking).
|
||||
> See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration).
|
||||
|
||||
# Known Upgrade Issues
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ To upgrade Rancher without upgrading the underlying Kubernetes cluster, follow t
|
||||
|
||||
**Result:** Rancher is upgraded to the new version.
|
||||
|
||||
If necessary, restore Rancher from backup by following [these steps.]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/restoring-rancher/)
|
||||
If necessary, restore Rancher from backup by following [these steps.]({{<baseurl>}}/rancher/v2.5/en/backups/restoring-rancher/)
|
||||
|
||||
### Upgrading Both Rancher and the Underlying Cluster
|
||||
|
||||
|
||||
@@ -17,4 +17,4 @@ The Docker installation is for development and testing environments only.
|
||||
|
||||
Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
|
||||
|
||||
For Rancher v2.5+, 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.5/en/backups/v2.5/migrating-rancher/)
|
||||
For Rancher v2.5+, 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.5/en/backups/migrating-rancher)
|
||||
+3
-1
@@ -6,6 +6,8 @@ aliases:
|
||||
- /rancher/v2.5/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
|
||||
- /rancher/v2.5/en/installation/air-gap-single-node/install-rancher
|
||||
- /rancher/v2.5/en/installation/air-gap/install-rancher
|
||||
- /rancher/v2.5/en/installation/air-gap-installation/install-rancher/
|
||||
- /rancher/v2.5/en/installation/air-gap-high-availability/install-rancher/
|
||||
---
|
||||
|
||||
This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
|
||||
@@ -234,7 +236,7 @@ The Docker installation is for Rancher users who want to test out Rancher.
|
||||
|
||||
Instead of running on a Kubernetes cluster, you install the Rancher server component on a single node using a `docker run` command. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server.
|
||||
|
||||
For Rancher v2.5+, the backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/migrating-rancher/)
|
||||
For Rancher v2.5+, the backup application can be used to migrate the Rancher server from a Docker install to a Kubernetes install using [these steps.]({{<baseurl>}}/rancher/v2.5/en/backups/migrating-rancher)
|
||||
|
||||
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
|
||||
|
||||
|
||||
+1
-1
@@ -151,7 +151,7 @@ From a system that can access ports 22/TCP and 6443/TCP on the Linux host node(s
|
||||
|
||||
This file is an RKE configuration file, which is a configuration for the cluster you're deploying Rancher to.
|
||||
|
||||
Replace values in the code sample below with help of the _RKE Options_ table. Use the IP address or DNS names of the [3 nodes]({{<baseurl>}}/rancher/v2.5/en/installation/air-gap-high-availability/provision-hosts) you created.
|
||||
Replace values in the code sample below with help of the _RKE Options_ table. Use the IP address or DNS names of the three nodes you created.
|
||||
|
||||
> **Tip:** For more details on the options available, see the RKE [Config Options]({{<baseurl>}}/rke/latest/en/config-options/).
|
||||
|
||||
|
||||
+1
@@ -6,6 +6,7 @@ aliases:
|
||||
- /rancher/v2.5/en/installation/air-gap-single-node/prepare-private-registry/
|
||||
- /rancher/v2.5/en/installation/air-gap-single-node/config-rancher-for-private-reg/
|
||||
- /rancher/v2.5/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
|
||||
- /rancher/v2.5/en/installation/air-gap-installation/prepare-private-reg/
|
||||
---
|
||||
|
||||
This section describes how to set up your private registry so that when you install Rancher, Rancher will pull all the required images from this registry.
|
||||
|
||||
+1
-1
@@ -152,7 +152,7 @@ If you need help with creating a private registry, please refer to the [official
|
||||
{{% tab "Docker" %}}
|
||||
> The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server.
|
||||
>
|
||||
> As of Rancher v2.5, 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.5/en/backups/v2.5/migrating-rancher/)
|
||||
> As of Rancher v2.5, 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.5/en/backups/migrating-rancher)
|
||||
|
||||
### 1. Set up a Linux Node
|
||||
|
||||
|
||||
+1
-1
@@ -17,7 +17,7 @@ In this installation scenario, you'll install Docker on a single Linux host, and
|
||||
|
||||
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.5/en/backups/v2.5/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.5/en/backups/migrating-rancher)
|
||||
|
||||
### Privileged Access for Rancher v2.5+
|
||||
|
||||
|
||||
+1
-1
@@ -352,7 +352,7 @@ Log into Rancher. Confirm that the upgrade succeeded by checking the version dis
|
||||
|
||||
>**Having network issues in your user clusters following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/upgrades/namespace-migration/#restoring-cluster-networking).
|
||||
> See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration).
|
||||
|
||||
|
||||
# 6. Clean up Your Old Rancher Server Container
|
||||
|
||||
@@ -30,7 +30,7 @@ The Rancher UI works best in Firefox or Chrome.
|
||||
|
||||
Rancher should work with any modern Linux distribution.
|
||||
|
||||
Docker is required for nodes that will run K3s or RKE Kubernetes clusters. It is not required for RancherD installs.
|
||||
Docker is required for nodes that will run RKE Kubernetes clusters. It is not required for RancherD installs.
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
|
||||
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
title: Setting up a High-availability RKE2 Kubernetes Cluster for Rancher
|
||||
shortTitle: Set up RKE2 for Rancher
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.x/en/installation/resources/k8s-tutorials/ha-RKE2
|
||||
---
|
||||
_Tested on v2.5.6_
|
||||
|
||||
@@ -9,7 +11,7 @@ This section describes how to install a Kubernetes cluster according to the [bes
|
||||
|
||||
# Prerequisites
|
||||
|
||||
These instructions assume you have set up three nodes, a load balancer, a DNS record, [this section.](({{<baseurl>}}/rancher/v2.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
These instructions assume you have set up three nodes, a load balancer, and a DNS record as described [this section.]({{<baseurl>}}/rancher/v2.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
|
||||
Note that in order for RKE2 to work correctly with the load balancer, you need to set up two listeners: one for the supervisor on port 9345, and one for the Kubernetes API on port 6443.
|
||||
|
||||
@@ -176,4 +178,4 @@ spec:
|
||||
image:
|
||||
repository: us.gcr.io/k8s-artifacts-prod/ingress-nginx/controller
|
||||
tag: "v0.34.1"
|
||||
```
|
||||
```
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Adding TLS Secrets
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.5/en/installation/resources/encryption/tls-secrets/
|
||||
---
|
||||
|
||||
Kubernetes will create all the objects and services for Rancher, but it will not become available until we populate the `tls-rancher-ingress` secret in the `cattle-system` namespace with the certificate and key.
|
||||
|
||||
@@ -76,7 +76,7 @@ $ helm ls -A
|
||||
|
||||
Upgrade the Helm application instance using the original configuration values and making sure to specify `ingress.tls.source=secret` as well as the current chart version to prevent an application upgrade.
|
||||
|
||||
If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using [custom certificates]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-Kubernetes/#6-install-rancher-with-helm-and-your-chosen-certificate-option).
|
||||
If the certificate was signed by a private CA, add the `set privateCA=true` argument as well. Also make sure to read the documentation describing the initial installation using custom certificates.
|
||||
|
||||
```
|
||||
helm upgrade rancher rancher-stable/rancher \
|
||||
|
||||
@@ -3,6 +3,7 @@ title: Selectors and Scrape Configs
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.5/en/istio/v2.5/configuration-reference/selectors-and-scrape
|
||||
- /rancher/v2.5/en/cluster-admin/tools/istio/setup/node-selectors
|
||||
---
|
||||
|
||||
The Monitoring app sets `prometheus.prometheusSpec.ignoreNamespaceSelectors=false`, which enables monitoring across all namespaces by default.
|
||||
|
||||
@@ -46,8 +46,6 @@ For more information, see [Ingress]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher
|
||||
|
||||
When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
For more information, see [Global DNS]({{<baseurl>}}/rancher/v2.5/en/catalog/globaldns/).
|
||||
|
||||
## Service Discovery
|
||||
|
||||
After you expose your cluster to external requests using a load balancer and/or ingress, it's only available by IP address. To create a resolveable hostname, you must create a service record, which is a record that maps an IP address, external hostname, DNS record alias, workload(s), or labelled pods to a specific hostname.
|
||||
|
||||
@@ -60,4 +60,4 @@ Ingress can provide other functionality as well, such as SSL termination, name-b
|
||||
|
||||
- For more information on how to set up ingress in Rancher, see [Ingress]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/load-balancers-and-ingress/ingress).
|
||||
- For complete information about ingress and ingress controllers, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/)
|
||||
- When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry, see [Global DNS]({{<baseurl>}}/rancher/v2.5/en/catalog/globaldns/).
|
||||
- When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
@@ -7,7 +7,7 @@ aliases:
|
||||
- /rancher/v2.5/en/k8s-in-rancher/load-balancers-and-ingress/ingress
|
||||
---
|
||||
|
||||
Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.5/en/catalog/globaldns/).
|
||||
Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing. When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.
|
||||
|
||||
1. From the **Global** view, open the project that you want to add ingress to.
|
||||
1. Click **Resources** in the main navigation bar. Click the **Load Balancing** tab. Then click **Add Ingress**.
|
||||
|
||||
@@ -7,6 +7,7 @@ weight: 15
|
||||
aliases:
|
||||
- /rancher/v2.5/en/dashboard/logging
|
||||
- /rancher/v2.5/en/logging/v2.5
|
||||
- /rancher/v2.5/en/cluster-admin/tools/logging
|
||||
---
|
||||
|
||||
- [Changes in Rancher v2.5](#changes-in-rancher-v2-5)
|
||||
|
||||
@@ -3,6 +3,9 @@ title: Alertmanager
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.5/en/monitoring-alerting/v2.5/configuration/alertmanager
|
||||
- rancher/v2.5/en/monitoring-alerting/legacy/notifiers/
|
||||
- /rancher/v2.5/en/cluster-admin/tools/notifiers
|
||||
- /rancher/v2.5/en/cluster-admin/tools/alerts
|
||||
---
|
||||
|
||||
The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.
|
||||
@@ -21,7 +24,7 @@ The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configurati
|
||||
- [Receiver](#receiver)
|
||||
- [Grouping](#grouping)
|
||||
- [Matching](#matching)
|
||||
- [Example Alertmanager YAML](#example-alertmanager-yaml)
|
||||
- [Example Alertmanager Config](#example-alertmanager-config)
|
||||
- [Example Route Config for CIS Scan Alerts](#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
# Overview
|
||||
|
||||
@@ -45,7 +45,7 @@ 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:
|
||||
|
||||
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.5/en/backups/v2.5/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.5/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.
|
||||
|
||||
|
||||
@@ -154,7 +154,7 @@ stages:
|
||||
|
||||
# Step Type: Publish Catalog Template
|
||||
|
||||
The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a [git hosted chart repository]({{<baseurl>}}/rancher/v2.5/en/catalog/custom/). It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. Any variables in the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) is supported for any file in the chart folder.
|
||||
The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a git hosted chart repository. It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. Any variables in the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) is supported for any file in the chart folder.
|
||||
|
||||
### Configuring Publishing a Catalog Template by UI
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Project Resource Quotas
|
||||
weight: 2515
|
||||
aliases:
|
||||
- /rancher/v2.5/en/k8s-in-rancher/projects-and-namespaces/resource-quotas
|
||||
---
|
||||
|
||||
In situations where several teams share a cluster, one team may overconsume the resources available: CPU, memory, storage, services, Kubernetes objects like pods or secrets, and so on. To prevent this overconsumption, you can apply a _resource quota_, which is a Rancher feature that limits the resources available to a project or namespace.
|
||||
|
||||
@@ -15,3 +15,4 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
| [CVE-2019-13209](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13209) | The vulnerability is known as a [Cross-Site Websocket Hijacking attack](https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html). This attack allows an exploiter to gain access to clusters managed by Rancher with the roles/permissions of a victim. It requires that a victim to be logged into a Rancher server and then access a third-party site hosted by the exploiter. Once that is accomplished, the exploiter is able to execute commands against the Kubernetes API with the permissions and identity of the victim. Reported by Matt Belisle and Alex Stevenson from Workiva. | 15 Jul 2019 | [Rancher v2.2.5](https://github.com/rancher/rancher/releases/tag/v2.2.5), [Rancher v2.1.11](https://github.com/rancher/rancher/releases/tag/v2.1.11) and [Rancher v2.0.16](https://github.com/rancher/rancher/releases/tag/v2.0.16) |
|
||||
| [CVE-2019-14436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14436) | The vulnerability allows a member of a project that has access to edit role bindings to be able to assign themselves or others a cluster level role granting them administrator access to that cluster. The issue was found and reported by Michal Lipinski at Nokia. | 5 Aug 2019 | [Rancher v2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) and [Rancher v2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2019-14435](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14435) | This vulnerability allows authenticated users to potentially extract otherwise private data out of IPs reachable from system service containers used by Rancher. This can include but not only limited to services such as cloud provider metadata services. Although Rancher allow users to configure whitelisted domains for system service access, this flaw can still be exploited by a carefully crafted HTTP request. The issue was found and reported by Matt Belisle and Alex Stevenson at Workiva. | 5 Aug 2019 | [Rancher v2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) and [Rancher v2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2021-25313](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25313) | A security vulnerability was discovered on all Rancher 2 versions. When accessing the Rancher API with a browser, the URL was not properly escaped, making it vulnerable to an XSS attack. Specially crafted URLs to these API endpoints could include JavaScript which would be embedded in the page and execute in a browser. There is no direct mitigation. Avoid clicking on untrusted links to your Rancher server. | 2 Mar 2021 | [Rancher v2.5.6](https://github.com/rancher/rancher/releases/tag/v2.5.6), [Rancher v2.4.14](https://github.com/rancher/rancher/releases/tag/v2.4.14), and [Rancher v2.3.11](https://github.com/rancher/rancher/releases/tag/v2.3.11) |
|
||||
@@ -26,6 +26,8 @@ For more detail about evaluating a hardened cluster against the official CIS ben
|
||||
- Rancher **exec shell** and **view logs** for pods are **not** functional in a CIS 1.6 hardened setup when only public IP is provided when registering custom nodes. This functionality requires a private IP to be provided when registering the custom nodes.
|
||||
- When setting the `default_pod_security_policy_template_id:` to `restricted` Rancher creates **RoleBindings** and **ClusterRoleBindings** on the default service accounts. The CIS 1.6 5.1.5 check requires the default service accounts have no roles or cluster roles bound to it apart from the defaults. In addition the default service accounts should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
Migration Rancher from 2.4 to 2.5. Addons were removed in HG 2.5, and therefore namespaces on migration may be not created on the downstream clusters. Pod may fail to run because of missing namesapce like ingress-nginx, cattlae-system.
|
||||
|
||||
### Configure Kernel Runtime Parameters
|
||||
|
||||
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
|
||||
|
||||
@@ -32,10 +32,6 @@ This section contains information to help you troubleshoot issues when using Ran
|
||||
|
||||
If you experience issues with your [Rancher server installed on Kubernetes]({{<baseurl>}}/rancher/v2.5/en/installation/install-rancher-on-k8s/)
|
||||
|
||||
- [Registered clusters]({{<baseurl>}}/rancher/v2.5/en/troubleshooting/registered-clusters/)
|
||||
|
||||
If you experience issues when [Registering Kubernetes Clusters]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/)
|
||||
|
||||
- [Logging]({{<baseurl>}}/rancher/v2.5/en/troubleshooting/logging/)
|
||||
|
||||
Read more about what log levels can be configured and how to configure a log level.
|
||||
|
||||
@@ -196,7 +196,7 @@ services:
|
||||
|
||||
> **Note:** As the `kubelet` is running inside a container, the path for files located in `/etc` and `/usr` are in `/host/etc` and `/host/usr` inside the `kubelet` container.
|
||||
|
||||
See [Editing Cluster as YAML]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/editing-clusters/#editing-cluster-as-yaml) how to apply this change. When the provisioning of the cluster has finished, you have to remove the kube-dns pod to activate the new setting in the pod:
|
||||
See [Editing Cluster as YAML]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/editing-clusters/#editing-clusters-with-yaml) how to apply this change. When the provisioning of the cluster has finished, you have to remove the kube-dns pod to activate the new setting in the pod:
|
||||
|
||||
```
|
||||
kubectl delete pods -n kube-system -l k8s-app=kube-dns
|
||||
|
||||
@@ -7,6 +7,8 @@ aliases:
|
||||
|
||||
In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer the instructions for [single node backups]({{<baseurl>}}/rancher/v2.x/en/backups/v2.5/docker-installs/docker-backups)
|
||||
|
||||
The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Rancher version must be v2.5.0 and up
|
||||
@@ -17,7 +19,7 @@ The backup storage location is an operator-level setting, so it needs to be conf
|
||||
|
||||
Backups are created as .tar.gz files. These files can be pushed to S3 or Minio, or they can be stored in a persistent volume.
|
||||
|
||||
1. In the Rancher UI, go to the **Cluster Explorer.**
|
||||
1. In the Rancher UI, go to the **Cluster Explorer** view for the local cluster.
|
||||
1. Click **Apps.**
|
||||
1. Click **Rancher Backups.**
|
||||
1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config)
|
||||
|
||||
@@ -17,7 +17,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.**
|
||||
1. Click **Restore.**
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [ [configuration reference]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/configuration/restore-config/) and to the [examples.]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/examples/)
|
||||
1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Restore YAML.
|
||||
|
||||
```yaml
|
||||
@@ -38,7 +38,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
|
||||
For help configuring the Restore, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
For help configuring the Restore, refer to the [configuration reference]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/configuration/restore-config/) and to the [examples.]({{<baseurl>}}/rancher/v2.5/en/backups/v2.5/examples/)
|
||||
|
||||
1. Click **Create.**
|
||||
|
||||
@@ -50,11 +50,10 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
### Logs
|
||||
|
||||
To check how the restore is progressing, you can check the logs of the operator. Follow these steps to get the logs:
|
||||
To check how the restore is progressing, you can check the logs of the operator. Run this command to follow the logs:
|
||||
|
||||
```yaml
|
||||
kubectl get pods -n cattle-resources-system
|
||||
kubectl logs <pod name from above command> -n cattle-resources-system -f
|
||||
```
|
||||
kubectl logs -n cattle-resources-system -l app.kubernetes.io/name=rancher-backup -f
|
||||
```
|
||||
|
||||
### Cleanup
|
||||
|
||||
@@ -18,7 +18,7 @@ The binary can be downloaded directly from the UI. The link can be found in the
|
||||
|
||||
After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires:
|
||||
|
||||
- Your [Rancher Server URL]({{<baseurl>}}/rancher/v2.x/en/admin-settings/server-url), which is used to connect to Rancher Server.
|
||||
- Your Your Rancher Server URL, which is used to connect to Rancher Server.
|
||||
- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key]({{<baseurl>}}/rancher/v2.x/en/user-settings/api-keys/).
|
||||
|
||||
### CLI Authentication
|
||||
|
||||
@@ -12,7 +12,7 @@ This section covers the following topics:
|
||||
- [Node options available for each cluster creation option](#node-options-available-for-each-cluster-creation-option)
|
||||
- [Nodes hosted by an infrastructure provider](#nodes-hosted-by-an-infrastructure-provider)
|
||||
- [Nodes provisioned by hosted Kubernetes providers](#nodes-provisioned-by-hosted-kubernetes-providers)
|
||||
- [Imported nodes](#imported-nodes)
|
||||
- [Registered/Imported nodes](#registered-imported-nodes)
|
||||
- [Managing and editing individual nodes](#managing-and-editing-individual-nodes)
|
||||
- [Viewing a node in the Rancher API](#viewing-a-node-in-the-rancher-api)
|
||||
- [Deleting a node](#deleting-a-node)
|
||||
@@ -30,20 +30,44 @@ This section covers the following topics:
|
||||
|
||||
The following table lists which node options are available for each type of cluster in Rancher. Click the links in the **Option** column for more detailed information about each feature.
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5" %}}
|
||||
| Option | [Nodes Hosted by an Infrastructure Provider][1] | [Custom Node][2] | [Hosted Cluster][3] | [Registered EKS Nodes][4] | [All Other Registered Nodes][5] | Description |
|
||||
| ------------------------------------------------ | ------------------------------------------------ | ---------------- | ------------------- | ------------------- | -------------------| ------------------------------------------------------------------ |
|
||||
| [Cordon](#cordoning-a-node) | ✓ | ✓ | ✓ | ✓ | ✓ | Marks the node as unschedulable. |
|
||||
| [Drain](#draining-a-node) | ✓ | ✓ | ✓ | ✓ | ✓ | Marks the node as unschedulable _and_ evicts all pods. |
|
||||
| [Edit](#managing-and-editing-individual-nodes) | ✓ | ✓ | ✓ | ✓ | ✓ | Enter a custom name, description, label, or taints for a node. |
|
||||
| [View API](#viewing-a-node-in-the-rancher-api) | ✓ | ✓ | ✓ | ✓ | ✓ | View API data. |
|
||||
| [Delete](#deleting-a-node) | ✓ | ✓ | | * | * | Deletes defective nodes from the cluster. |
|
||||
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | | Download SSH key in order to SSH into the node. |
|
||||
| [Node Scaling](#scaling-nodes) | ✓ | | | ✓ | | Scale the number of nodes in the node pool up or down. |
|
||||
|
||||
[1]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
|
||||
[2]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/
|
||||
[3]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
|
||||
[4]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
|
||||
[5]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/
|
||||
|
||||
\* Delete option accessible via View API
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.0-v2.4" %}}
|
||||
| Option | [Nodes Hosted by an Infrastructure Provider][1] | [Custom Node][2] | [Hosted Cluster][3] | [Imported Nodes][4] | Description |
|
||||
| ------------------------------------------------ | ------------------------------------------------ | ---------------- | ------------------- | ------------------- | ------------------------------------------------------------------ |
|
||||
| [Cordon](#cordoning-a-node) | ✓ | ✓ | ✓ | | Marks the node as unschedulable. |
|
||||
| [Drain](#draining-a-node) | ✓ | ✓ | ✓ | | Marks the node as unschedulable _and_ evicts all pods. |
|
||||
| [Edit](#managing-and-editing-individual-nodes) | ✓ | ✓ | ✓ | | Enter a custom name, description, label, or taints for a node. |
|
||||
| [View API](#viewing-a-node-in-the-rancher-api) | ✓ | ✓ | ✓ | | View API data. |
|
||||
| [Cordon](#cordoning-a-node) | ✓ | ✓ | ✓ | ✓ | Marks the node as unschedulable. |
|
||||
| [Drain](#draining-a-node) | ✓ | ✓ | ✓ | ✓ | Marks the node as unschedulable _and_ evicts all pods. |
|
||||
| [Edit](#managing-and-editing-individual-nodes) | ✓ | ✓ | ✓ | ✓ | Enter a custom name, description, label, or taints for a node. |
|
||||
| [View API](#viewing-a-node-in-the-rancher-api) | ✓ | ✓ | ✓ | ✓ | View API data. |
|
||||
| [Delete](#deleting-a-node) | ✓ | ✓ | | | Deletes defective nodes from the cluster. |
|
||||
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | Download SSH key for in order to SSH into the node. |
|
||||
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | Download SSH key in order to SSH into the node. |
|
||||
| [Node Scaling](#scaling-nodes) | ✓ | | | | Scale the number of nodes in the node pool up or down. |
|
||||
|
||||
[1]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/
|
||||
[2]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/
|
||||
[3]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/
|
||||
[4]: {{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
### Nodes Hosted by an Infrastructure Provider
|
||||
|
||||
@@ -59,9 +83,17 @@ Rancher uses [node templates]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning
|
||||
|
||||
Options for managing nodes [hosted by a Kubernetes provider]({{<baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) are somewhat limited in Rancher. Rather than using the Rancher UI to make edits such as scaling the number of nodes up or down, edit the cluster directly.
|
||||
|
||||
### Imported Nodes
|
||||
### Registered/Imported Nodes
|
||||
|
||||
Although you can deploy workloads to an [imported cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher.
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5" %}}
|
||||
Although you can deploy workloads to a [registered cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/) using Rancher, management of individual cluster nodes is limited to the supported options indicated in the [node options table]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/nodes/#cordoning-a-node). All other options to manage registered cluster nodes must take place outside of Rancher.
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher v2.0-v2.4" %}}
|
||||
Although you can deploy workloads to an [imported cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/) using Rancher, management of individual cluster nodes is limited to the supported options indicated in the [node options table]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/nodes/#cordoning-a-node). All other options
|
||||
to manage imported cluster nodes must take place outside of Rancher.
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
# Managing and Editing Individual Nodes
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ The cluster cannot be downgraded to a previous Kubernetes version.
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The options below are available only for [Rancher-launched RKE Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) and [imported K3s Kubernetes clusters.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters)
|
||||
> - The options below are available only for [Rancher-launched RKE Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) and imported K3s Kubernetes clusters.
|
||||
> - Before upgrading Kubernetes, [back up your cluster.]({{<baseurl>}}/rancher/v2.x/en/backups)
|
||||
|
||||
1. From the **Global** view, find the cluster for which you want to upgrade Kubernetes. Select **⋮ > Edit**.
|
||||
|
||||
@@ -66,6 +66,13 @@ In [Rancher Launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-
|
||||
### hostPath Volumes
|
||||
Before you create a hostPath volume, you need to set up an [extra_bind]({{<baseurl>}}/rke/latest/en/config-options/services/services-extras/#extra-binds/) in your cluster configuration. This will mount the path as a volume in your kubelets, which can then be used for hostPath volumes in your workloads.
|
||||
|
||||
### Migrating vSphere Cloud Provider from In-tree to Out-of-tree
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
For instructions on how to migrate from the in-tree vSphere cloud provider to out-of-tree, and manage the existing VMs post migration, refer to [this page.]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/cloud-providers/vsphere/out-of-tree)
|
||||
|
||||
|
||||
### Related Links
|
||||
|
||||
- [Kubernetes Documentation: Storage](https://kubernetes.io/docs/concepts/storage/)
|
||||
|
||||
@@ -19,4 +19,4 @@ headless: true
|
||||
| [Configuring Pod Security Policies]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/pod-security-policy/) | ✓ | | |
|
||||
| [Running Security Scans]({{<baseurl>}}/rancher/v2.x/en/security/security-scan/) | ✓ | | |
|
||||
|
||||
\* Cluster configuration options can't be edited for imported clusters, except for [K3s clusters.]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters)
|
||||
\* Cluster configuration options can't be edited for imported clusters, except for K3s clusters.
|
||||
@@ -108,7 +108,7 @@ The ports required to be open are different depending on how the user cluster is
|
||||
|
||||
For a breakdown of the port requirements for etcd nodes, controlplane nodes, and worker nodes in a Kubernetes cluster, refer to the [port requirements for the Rancher Kubernetes Engine.]({{<baseurl>}}/rke/latest/en/os/#ports)
|
||||
|
||||
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](({{<baseurl>}}/rancher/v2.x/en/installation/requirements/ports#downstream-kubernetes-cluster-nodes)).
|
||||
Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements]({{<baseurl>}}/rancher/v2.x/en/installation/requirements/ports#downstream-kubernetes-cluster-nodes).
|
||||
|
||||
# Optional: Security Considerations
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ If you are registering a K3s cluster, make sure the `cluster.yml` is readable. I
|
||||
2. Choose **Register**.
|
||||
3. Enter a **Cluster Name**.
|
||||
4. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users that can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
5. Use **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent]({{<baseurl>}}rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
5. Use **Agent Environment Variables** under **Cluster Options** to set environment variables for [rancher cluster agent]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
6. Click **Create**.
|
||||
7. The prerequisite for `cluster-admin` privileges is shown (see **Prerequisites** above), including an example command to fulfil the prerequisite.
|
||||
8. Copy the `kubectl` command to your clipboard and run it on a node where kubeconfig is configured to point to the cluster you want to import. If you are unsure it is configured correctly, run `kubectl get nodes` to verify before running the command shown in Rancher.
|
||||
|
||||
+2
-2
@@ -8,7 +8,7 @@ When using the `Amazon` cloud provider, you can leverage the following capabilit
|
||||
- **Load Balancers:** Launches an AWS Elastic Load Balancer (ELB) when choosing `Layer-4 Load Balancer` in **Port Mapping** or when launching a `Service` with `type: LoadBalancer`.
|
||||
- **Persistent Volumes**: Allows you to use AWS Elastic Block Stores (EBS) for persistent volumes.
|
||||
|
||||
See [cloud-provider-aws README](https://github.com/kubernetes/cloud-provider-aws/blob/master/README.md) for all information regarding the Amazon cloud provider.
|
||||
See [cloud-provider-aws README](https://kubernetes.github.io/cloud-provider-aws/) for all information regarding the Amazon cloud provider.
|
||||
|
||||
To set up the Amazon cloud provider,
|
||||
|
||||
@@ -147,4 +147,4 @@ Setting the value of the tag to `owned` tells the cluster that all resources wit
|
||||
|
||||
### Using Amazon Elastic Container Registry (ECR)
|
||||
|
||||
The kubelet component has the ability to automatically obtain ECR credentials, when the IAM profile mentioned in [Create an IAM Role and attach to the instances](#1-create-an-iam-role-and-attach-to-the-instances) is attached to the instance(s). When using a Kubernetes version older than v1.15.0, the Amazon cloud provider needs be configured in the cluster. Starting with Kubernetes version v1.15.0, the kubelet can obtain ECR credentials without having the Amazon cloud provider configured in the cluster.
|
||||
The kubelet component has the ability to automatically obtain ECR credentials, when the IAM profile mentioned in [Create an IAM Role and attach to the instances](#1-create-an-iam-role-and-attach-to-the-instances) is attached to the instance(s). When using a Kubernetes version older than v1.15.0, the Amazon cloud provider needs be configured in the cluster. Starting with Kubernetes version v1.15.0, the kubelet can obtain ECR credentials without having the Amazon cloud provider configured in the cluster.
|
||||
|
||||
+6
-16
@@ -2,24 +2,14 @@
|
||||
title: Setting up the vSphere Cloud Provider
|
||||
weight: 4
|
||||
---
|
||||
In this section, you'll learn how to set up a vSphere cloud provider for a Rancher managed RKE Kubernetes cluster in vSphere.
|
||||
|
||||
In this section, you'll learn how to set up the vSphere cloud provider for a Rancher managed RKE Kubernetes cluster in vSphere.
|
||||
# In-tree Cloud Provider
|
||||
|
||||
Follow these steps while creating the vSphere cluster in Rancher:
|
||||
To use the in-tree vSphere cloud provider, you will need to use an RKE configuration option. For details, refer to [this page.](./in-tree)
|
||||
|
||||
1. Set **Cloud Provider** option to `Custom`.
|
||||
# Out-of-tree Cloud Provider
|
||||
|
||||
{{< img "/img/rancher/vsphere-node-driver-cloudprovider.png" "vsphere-node-driver-cloudprovider">}}
|
||||
_Available as of v2.5+_
|
||||
|
||||
1. Click on **Edit as YAML**
|
||||
1. Insert the following structure to the pre-populated cluster YAML. As of Rancher v2.3+, this structure must be placed under `rancher_kubernetes_engine_config`. In versions before v2.3, it has to be defined as a top-level field. Note that the `name` *must* be set to `vsphere`.
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config: # Required as of Rancher v2.3+
|
||||
cloud_provider:
|
||||
name: vsphere
|
||||
vsphereCloudProvider:
|
||||
[Insert provider configuration]
|
||||
```
|
||||
|
||||
Rancher uses RKE (the Rancher Kubernetes Engine) to provision Kubernetes clusters. Refer to the [vSphere configuration reference in the RKE documentation]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/vsphere/config-reference/) for details about the properties of the `vsphereCloudProvider` directive.
|
||||
To set up the out-of-tree vSphere cloud provider, you will need to install Helm charts from the Rancher marketplace. For details, refer to [this page.](./out-of-tree)
|
||||
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: How to Configure In-tree vSphere Cloud Provider
|
||||
shortTitle: In-tree Cloud Provider
|
||||
weight: 10
|
||||
---
|
||||
|
||||
To set up the in-tree vSphere cloud provider, follow these steps while creating the vSphere cluster in Rancher:
|
||||
|
||||
1. Set **Cloud Provider** option to `Custom` or `Custom (In-Tree)`.
|
||||
|
||||
{{< img "/img/rancher/vsphere-node-driver-cloudprovider.png" "vsphere-node-driver-cloudprovider">}}
|
||||
|
||||
1. Click on **Edit as YAML**
|
||||
1. Insert the following structure to the pre-populated cluster YAML. This structure must be placed under `rancher_kubernetes_engine_config`. Note that the `name` *must* be set to `vsphere`.
|
||||
|
||||
```yaml
|
||||
rancher_kubernetes_engine_config:
|
||||
cloud_provider:
|
||||
name: vsphere
|
||||
vsphereCloudProvider:
|
||||
[Insert provider configuration]
|
||||
```
|
||||
|
||||
Rancher uses RKE (the Rancher Kubernetes Engine) to provision Kubernetes clusters. Refer to the [vSphere configuration reference in the RKE documentation]({{<baseurl>}}/rke/latest/en/config-options/cloud-providers/vsphere/config-reference/) for details about the properties of the `vsphereCloudProvider` directive.
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: How to Configure Out-of-tree vSphere Cloud Provider
|
||||
shortTitle: Out-of-tree Cloud Provider
|
||||
weight: 10
|
||||
---
|
||||
_Available as of v2.5+_
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
This page covers how to install the Cloud Provider Interface (CPI) and Cloud Storage Interface (CSI) plugins after bringing up a cluster.
|
||||
|
||||
# Prerequisites
|
||||
|
||||
The vSphere version must be 7.0u1 or higher.
|
||||
|
||||
The Kubernetes version must be 1.19 or higher.
|
||||
|
||||
Using the vSphere out-of-tree cloud provider requires Linux nodes and is not supported on Windows.
|
||||
|
||||
# Installation
|
||||
|
||||
The Cloud Provider Interface (CPI) should be installed first before installing the Cloud Storage Interface (CSI).
|
||||
|
||||
### 1. Create a vSphere cluster
|
||||
|
||||
1. On the Clusters page, click on **Add Cluster** and select the **vSphere** option or **Existing Nodes** option.
|
||||
1. Under **Cluster Options > Cloud Provider** select **External (Out-of-tree)**. This sets the cloud provider option on the Kubernetes cluster to `external` which sets your Kubernetes cluster up to be configured with an out-of-tree cloud provider.
|
||||
1. Finish creating your cluster.
|
||||
|
||||
### 2. Install the CPI plugin
|
||||
|
||||
1. From the **Cluster Explorer** view, go to the top left dropdown menu and click **Apps & Marketplace.**
|
||||
1. Select the **vSphere CPI** chart. Fill out the required vCenter details.
|
||||
1. vSphere CPI initializes all nodes with ProviderID which is needed by the vSphere CSI driver. Check if all nodes are initialized with the ProviderID before installing CSI driver with the following command:
|
||||
|
||||
```
|
||||
kubectl describe nodes | grep "ProviderID"
|
||||
```
|
||||
### 3. Installing the CSI plugin
|
||||
|
||||
1. From the **Cluster Explorer** view, go to the top left dropdown menu and click **Apps & Marketplace.**
|
||||
1. Select the **vSphere CSI** chart. Fill out the required vCenter details.
|
||||
2. Set **Enable CSI Migration** to **false**.
|
||||
3. This chart creates a StorageClass with the `csi.vsphere.vmware.com` as the provisioner. Fill out the details for the StorageClass and launch the chart.
|
||||
|
||||
# Using the CSI driver for provisioning volumes
|
||||
The CSI chart by default creates a storageClass.
|
||||
|
||||
If that option was not selected while launching the chart, create a storageClass with the `csi.vsphere.vmware.com` as the provisioner.
|
||||
|
||||
All volumes provisioned using this StorageClass will get provisioned by the CSI driver.
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Migrating vSphere In-tree Volumes to CSI
|
||||
weight: 5
|
||||
---
|
||||
_Available as of v2.5+_
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
This page covers how to migrate from the in-tree vSphere cloud provider to out-of-tree, and manage the existing VMs post migration.
|
||||
It follows the steps provided in the official [vSphere migration documentation](https://vsphere-csi-driver.sigs.k8s.io/features/vsphere_csi_migration.html) and provides the steps to be performed in Rancher.
|
||||
### Cloud-config Format Limitation
|
||||
Existing volumes that were provisioned using the following cloud-config format will NOT get migrated due to an existing bug in vsphere CSI.
|
||||
If the cloud-config has this format for datastore and resource pool path, vsphere CSI driver cannot recognize it:
|
||||
```yaml
|
||||
default-datastore: </datacenter>/datastore/<default-datastore-name>
|
||||
resourcepool-path: "</datacenter>/host/<cluster-name>/Resources/<resource-pool-name>"
|
||||
```
|
||||
Volumes provisioned with the in-tree provider using the following format will get migrated correctly:
|
||||
```yaml
|
||||
default-datastore: <default-datastore-name>
|
||||
resourcepool-path: "<cluster-name>/Resources/<resource-pool-name>"
|
||||
```
|
||||
Upstream bug: https://github.com/kubernetes-sigs/vsphere-csi-driver/issues/628
|
||||
Rancher issue tracking this bug: https://github.com/rancher/rancher/issues/31105
|
||||
# Prerequisites
|
||||
- vSphere CSI Migration requires vSphere 7.0u1. In order to be able to manage existing in-tree vSphere volumes, upgrade vSphere to 7.0u1.
|
||||
- The Kubernetes version must be 1.19 or higher.
|
||||
# Migration
|
||||
### 1. Install the CPI plugin
|
||||
Before installing CPI, we need to taint all nodes with `node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule`.
|
||||
This can be done by running the following commands:
|
||||
```
|
||||
curl -O https://raw.githubusercontent.com/rancher/helm3-charts/56b622f519728378abeddfe95074f1b87ab73b1e/charts/vsphere-cpi/taints.sh
|
||||
```
|
||||
Or:
|
||||
```
|
||||
wget https://raw.githubusercontent.com/rancher/helm3-charts/56b622f519728378abeddfe95074f1b87ab73b1e/charts/vsphere-cpi/taints.sh
|
||||
chmod +x taints.sh
|
||||
./taints.sh <path to kubeconfig if running the command outside the cluster>
|
||||
```
|
||||
|
||||
Once all nodes are tainted by the running the script, launch the Helm vSphere CPI chart.
|
||||
|
||||
1. From the **Cluster Explorer** view, go to the top left dropdown menu and click **Apps & Marketplace.**
|
||||
2. Select the **vSphere CPI** chart.
|
||||
3. Fill out the required vCenter details and click **Launch**.
|
||||
|
||||
vSphere CPI initializes all nodes with ProviderID, which is needed by the vSphere CSI driver.
|
||||
Check if all nodes are initialized with the ProviderID with the following command:
|
||||
```
|
||||
kubectl describe nodes | grep "ProviderID"
|
||||
```
|
||||
|
||||
### 2. Install the CSI driver
|
||||
|
||||
1. From the **Cluster Explorer** view, go to the top left dropdown menu and click **Apps & Marketplace.**
|
||||
1. Select the **vSphere CSI** chart.
|
||||
1. Fill out the required vCenter details and click **Launch**.
|
||||
1. Set **Enable CSI Migration** to **true**.
|
||||
1. This chart creates a StorageClass with the `csi.vsphere.vmware.com` as the provisioner. You can provide the URL of the datastore to be used for CSI volume provisioning while creating this StorageClass. The datastore URL can be found in the vSphere client by selecting the datastore and going to the Summary tab. Fill out the details for the StorageClass and click **Launch**.
|
||||
### 3. Edit the cluster to enable CSI migration feature flags
|
||||
1. While editing the cluster, if the Kubernetes version is less than 1.19, select Kubernetes version 1.19 or higher from the **Kubernetes Version** dropdown.
|
||||
2. For enabling feature flags, click on "Edit as YAML", and add the following under kube-controller and kubelet:
|
||||
```yaml
|
||||
extra_args:
|
||||
feature-gates: "CSIMigration=true,CSIMigrationvSphere=true"
|
||||
```
|
||||
### 4. Drain worker nodes
|
||||
Worker nodes must be drained during the upgrade before changing the kubelet and kube-controller-manager args.
|
||||
1. Click **Edit as Form** and then click on "Advanced Options."
|
||||
1. Set the field **Maximum Worker Nodes Unavailable** to count of 1.
|
||||
1. To drain the nodes during upgrade, select **Drain Nodes > Yes**.
|
||||
1. Set **Force** and **Delete Local Data** to **true**.
|
||||
1. Click **Save** to upgrade the cluster.
|
||||
-9
@@ -1,9 +0,0 @@
|
||||
---
|
||||
title: Migrating vSphere In-tree Volumes to CSI
|
||||
weight: 5
|
||||
---
|
||||
_Available as of v2.5.6_
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
For instructions on how to migrate from the in-tree vSphere cloud provider to out-of-tree, and manage the existing VMs post migration, refer to [this page.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/vsphere-volume-migration)
|
||||
-9
@@ -1,9 +0,0 @@
|
||||
---
|
||||
title: vSphere Out-of-tree Cloud Provider
|
||||
weight: 4
|
||||
---
|
||||
_Available as of v2.5.6_
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
For instructions on how to install the CPI and CSI plugins after bringing up a cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/out-of-tree-vsphere)
|
||||
@@ -157,7 +157,7 @@ Option to enable or disable [recurring etcd snapshots]({{<baseurl>}}/rke/latest/
|
||||
|
||||
_Available as of v2.5.6_
|
||||
|
||||
Option to set environment variables for [rancher agents]({{<baseurl>}}rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
Option to set environment variables for [rancher agents]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables.
|
||||
|
||||
# Cluster Config File
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Typically, most applications are deployed on a single Kubernetes cluster, but th
|
||||
|
||||
Any Helm charts from a global catalog can be used to deploy and manage multi-cluster applications.
|
||||
|
||||
After creating a multi-cluster application, you can program a [Global DNS entry]({{<baseurl>}}/rancher/v2.x/en/catalog/globaldns/) to make it easier to access the application.
|
||||
After creating a multi-cluster application, you can program a [Global DNS entry]({{<baseurl>}}/rancher/v2.x/en/helm-charts/legacy-catalogs/globaldns/) to make it easier to access the application.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Launching a multi-cluster app](#launching-a-multi-cluster-app)
|
||||
|
||||
@@ -105,4 +105,4 @@ _Available as v2.2.0_
|
||||
|
||||
When creating applications that span multiple Kubernetes clusters, a Global DNS entry can be created to route traffic to the endpoints in all of the different clusters. An external DNS server will need be programmed to assign a fully qualified domain name (a.k.a FQDN) to your application. Rancher will use the FQDN you provide and the IP addresses where your application is running to program the DNS. Rancher will gather endpoints from all the Kubernetes clusters running your application and program the DNS.
|
||||
|
||||
For more information on how to use this feature, see [Global DNS]({{<baseurl>}}/rancher/v2.x/en/catalog/globaldns/).
|
||||
For more information on how to use this feature, see [Global DNS]({{<baseurl>}}/rancher/v2.x/en/helm-charts/legacy-catalogs/globaldns/).
|
||||
|
||||
@@ -7,7 +7,7 @@ aliases:
|
||||
|
||||
Within a project, when you want to deploy applications from catalogs, the applications available in your project will be based on the [scope of the catalogs]({{<baseurl>}}/rancher/v2.x/en/helm-charts/legacy-catalogs/#catalog-scopes).
|
||||
|
||||
If your application is using ingresses, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.x/en/catalog/globaldns/).
|
||||
If your application is using ingresses, you can program the ingress hostname to an external DNS by setting up a [Global DNS entry]({{<baseurl>}}/rancher/v2.x/en/helm-charts/legacy-catalogs/globaldns/).
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Launching a catalog app](#launching-a-catalog-app)
|
||||
|
||||
@@ -24,7 +24,7 @@ For the tutorial to install an RKE Kubernetes cluster, refer to [this page.]({{<
|
||||
|
||||
For the tutorial to install a K3s Kubernetes cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.x/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.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-ha-with-external-db)
|
||||
|
||||
For the tutorial to install an RKE2 Kubernetes cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.x/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.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
For the tutorial to install an RKE2 Kubernetes cluster, refer to [this page.]({{<baseurl>}}/rancher/v2.x/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.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha)
|
||||
|
||||
# Install the Rancher Helm Chart
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
|
||||
1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.**
|
||||
1. Click **Restore.**
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference](../../../backups/v2.5/configuration/restore-config/) and to the [examples.](../../../backups/v2.5/examples)
|
||||
1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Restore YAML.
|
||||
|
||||
```yaml
|
||||
@@ -52,7 +52,7 @@ A restore is performed by creating a Restore custom resource.
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
```
|
||||
|
||||
For help configuring the Restore, refer to the [configuration reference](../configuration/restore-config) and to the [examples.](../examples/#restore)
|
||||
For help configuring the Restore, refer to the [configuration reference](../../../backups/v2.5/configuration/restore-config/) and to the [examples.](../../../backups/v2.5/examples)
|
||||
|
||||
1. Click **Create.**
|
||||
|
||||
@@ -88,4 +88,4 @@ For information on how to roll back Rancher installed with Docker, refer to [thi
|
||||
|
||||
# Rolling Back to Rancher v2.0-v2.1
|
||||
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here]({{<baseurl>}}/rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/v2.0-v2.1) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here]({{<baseurl>}}/rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/v2.0-v2.1) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
@@ -30,7 +30,7 @@ The Rancher UI works best in Firefox or Chrome.
|
||||
|
||||
Rancher should work with any modern Linux distribution.
|
||||
|
||||
Docker is required for nodes that will run K3s or RKE Kubernetes clusters. It is not required for RancherD installs.
|
||||
Docker is required for nodes that will run RKE Kubernetes clusters. It is not required for RancherD installs.
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
|
||||
|
||||
@@ -170,4 +170,4 @@ Before installing Rancher on SELinux Enforcing CentOS 8 nodes or RHEL 8 nodes, y
|
||||
```
|
||||
sudo yum install iptables
|
||||
sudo yum install container-selinux
|
||||
```
|
||||
```
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
title: Port Requirements
|
||||
description: Read about port requirements needed in order for Rancher to operate properly, both for Rancher nodes and downstream Kubernetes cluster nodes
|
||||
weight: 300
|
||||
aliases:
|
||||
- /rancher/v2.5/en/installation/references
|
||||
---
|
||||
|
||||
To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes.
|
||||
|
||||
+2
-2
@@ -164,7 +164,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
|
||||
--set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.x/en/installation/options/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
|
||||
Then refer to [Adding TLS Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them.
|
||||
|
||||
{{% /accordion %}}
|
||||
|
||||
@@ -218,7 +218,7 @@ If you are installing Rancher versions before v2.3.0, you will not be able to us
|
||||
These resources could be helpful when installing Rancher:
|
||||
|
||||
- [Rancher Helm chart options]({{<baseurl>}}/rancher/v2.x/en/installation/options/chart-options/)
|
||||
- [Adding TLS secrets]({{<baseurl>}}/rancher/v2.x/en/installation/options/tls-secrets/)
|
||||
- [Adding TLS secrets]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/)
|
||||
- [Troubleshooting Rancher Kubernetes Installations]({{<baseurl>}}/rancher/v2.x/en/installation/options/troubleshooting/)
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user