mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
Updating notes
This commit is contained in:
+10
-2
@@ -5,7 +5,11 @@ weight: 300
|
||||
|
||||
Now that you have a running RKE cluster, you can install Rancher in it. For security reasons all traffic to Rancher must be encrypted with TLS. For this tutorial you are going to automatically issue a self-signed certificate through [cert-manager](https://cert-manager.io/). In a real-world use-case you will likely use Let's Encrypt or provide your own certificate.
|
||||
|
||||
> **Note:** These installation instructions assume you are using Helm 3.
|
||||
:::note
|
||||
|
||||
These installation instructions assume you are using Helm 3.
|
||||
|
||||
:::
|
||||
|
||||
### Install cert-manager
|
||||
|
||||
@@ -78,7 +82,11 @@ kubectl rollout status deployment -n cattle-system rancher
|
||||
|
||||
You can now navigate to `https://rancher.example.com` and start using Rancher.
|
||||
|
||||
> **Note:** If you don't intend to send telemetry data, opt out [telemetry]({{<baseurl>}}/rancher/v2.6/en/faq/telemetry/) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
|
||||
:::caution
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry]({{<baseurl>}}/rancher/v2.6/en/faq/telemetry/) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
|
||||
|
||||
:::
|
||||
|
||||
### Additional Resources
|
||||
|
||||
|
||||
+10
-3
@@ -151,8 +151,11 @@ default backend - 404
|
||||
|
||||
### Save Your Files
|
||||
|
||||
> **Important**
|
||||
> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
|
||||
:::note Important:
|
||||
|
||||
The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
|
||||
|
||||
:::
|
||||
|
||||
Save a copy of the following files in a secure location:
|
||||
|
||||
@@ -160,7 +163,11 @@ Save a copy of the following files in a secure location:
|
||||
- `kube_config_cluster.yml`: The [Kubeconfig file]({{<baseurl>}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
|
||||
- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{<baseurl>}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.
|
||||
|
||||
> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
:::note
|
||||
|
||||
The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
|
||||
:::
|
||||
|
||||
### Issues or errors?
|
||||
|
||||
|
||||
+5
-2
@@ -44,8 +44,11 @@ For an example showing how to set up an NGINX load balancer, refer to [this page
|
||||
|
||||
For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/nlb/)
|
||||
|
||||
> **Important:**
|
||||
> Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
:::note Important:
|
||||
|
||||
Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
|
||||
:::
|
||||
|
||||
### 3. Set up the DNS Record
|
||||
|
||||
|
||||
@@ -13,7 +13,11 @@ Make sure `NO_PROXY` contains the network addresses, network address ranges and
|
||||
| HTTPS_PROXY | Proxy address to use when initiating HTTPS connection(s) |
|
||||
| NO_PROXY | Network address(es), network address range(s) and domains to exclude from using the proxy when initiating connection(s) |
|
||||
|
||||
> **Note** NO_PROXY must be in uppercase to use network range (CIDR) notation.
|
||||
:::note Important:
|
||||
|
||||
NO_PROXY must be in uppercase to use network range (CIDR) notation.
|
||||
|
||||
:::
|
||||
|
||||
## Docker Installation
|
||||
|
||||
|
||||
+39
-23
@@ -8,8 +8,11 @@ Rancher can be installed by running a single Docker container.
|
||||
|
||||
In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container.
|
||||
|
||||
> **Want to use an external load balancer?**
|
||||
> See [Docker Install with an External Load Balancer]({{<baseurl>}}/rancher/v2.6/en/installation/resources/advanced/single-node-install-external-lb) instead.
|
||||
:::note Want to use an external load balancer?
|
||||
|
||||
See [Docker Install with an External Load Balancer]({{<baseurl>}}/rancher/v2.6/en/installation/resources/advanced/single-node-install-external-lb) instead.
|
||||
|
||||
:::
|
||||
|
||||
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:
|
||||
|
||||
@@ -31,12 +34,14 @@ Provision a single Linux host according to our [Requirements]({{<baseurl>}}/ranc
|
||||
|
||||
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.
|
||||
|
||||
> **Do you want to..**.
|
||||
>
|
||||
> - Use a proxy? See [HTTP Proxy Configuration]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/proxy/)
|
||||
> - Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/advanced/#custom-ca-certificate/)
|
||||
> - Complete an Air Gap Installation? See [Air Gap: Docker Install]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap/)
|
||||
> - Record all transactions with the Rancher API? See [API Auditing](./advanced/#api-audit-log)
|
||||
:::tip Do you want to..
|
||||
|
||||
- Use a proxy? See [HTTP Proxy Configuration]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/proxy/)
|
||||
- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/advanced/#custom-ca-certificate/)
|
||||
- Complete an Air Gap Installation? See [Air Gap: Docker Install]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap/)
|
||||
- Record all transactions with the Rancher API? See [API Auditing](./advanced/#api-audit-log)
|
||||
|
||||
:::
|
||||
|
||||
Choose from the following options:
|
||||
|
||||
@@ -62,11 +67,14 @@ docker run -d --restart=unless-stopped \
|
||||
### Option B: Bring Your Own Certificate, Self-signed
|
||||
In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher.
|
||||
|
||||
> **Prerequisites:**
|
||||
> Create a self-signed certificate using [OpenSSL](https://www.openssl.org/) or another method of your choice.
|
||||
>
|
||||
> - The certificate files must be in PEM format.
|
||||
> - In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
:::note Prerequisites:
|
||||
|
||||
Create a self-signed certificate using [OpenSSL](https://www.openssl.org/) or another method of your choice.
|
||||
|
||||
- The certificate files must be in PEM format.
|
||||
- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
|
||||
:::
|
||||
|
||||
After creating your certificate, run the Docker command below to install Rancher. Use the `-v` flag and provide the path to your certificates to mount them in your container.
|
||||
|
||||
@@ -95,10 +103,12 @@ In production environments where you're exposing an app publicly, you would use
|
||||
|
||||
The Docker install is not recommended for production. These instructions are provided for testing and development purposes only.
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The certificate files must be in PEM format.
|
||||
> - In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
:::note Prerequisites:
|
||||
|
||||
- The certificate files must be in PEM format.
|
||||
- In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
|
||||
:::
|
||||
|
||||
After obtaining your certificate, run the Docker command below.
|
||||
|
||||
@@ -125,17 +135,23 @@ docker run -d --restart=unless-stopped \
|
||||
|
||||
### Option D: Let's Encrypt Certificate
|
||||
|
||||
> **Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
|
||||
:::caution
|
||||
|
||||
Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
|
||||
|
||||
:::
|
||||
|
||||
For production environments, you also have the option of using [Let's Encrypt](https://letsencrypt.org/) certificates. Let's Encrypt uses an http-01 challenge to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS.
|
||||
|
||||
The Docker install is not recommended for production. These instructions are provided for testing and development purposes only.
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - Let's Encrypt is an Internet service. Therefore, this option cannot be used in an internal/air gapped network.
|
||||
> - Create a record in your DNS that binds your Linux host IP address to the hostname that you want to use for Rancher access (`rancher.mydomain.com` for example).
|
||||
> - Open port `TCP/80` on your Linux host. The Let's Encrypt http-01 challenge can come from any source IP address, so port `TCP/80` must be open to all IP addresses.
|
||||
:::note Prerequisites:
|
||||
|
||||
- Let's Encrypt is an Internet service. Therefore, this option cannot be used in an internal/air gapped network.
|
||||
- Create a record in your DNS that binds your Linux host IP address to the hostname that you want to use for Rancher access (`rancher.mydomain.com` for example).
|
||||
- Open port `TCP/80` on your Linux host. The Let's Encrypt http-01 challenge can come from any source IP address, so port `TCP/80` must be open to all IP addresses.
|
||||
|
||||
:::
|
||||
|
||||
After you fulfill the prerequisites, you can install Rancher using a Let's Encrypt certificate by running the following command.
|
||||
|
||||
|
||||
+10
-2
@@ -37,7 +37,11 @@ You can obtain `<PRIOR_RANCHER_VERSION>` and `<RANCHER_CONTAINER_NAME>` by loggi
|
||||
|
||||
If you have issues upgrading Rancher, roll it back to its latest known healthy state by pulling the last version you used and then restoring the backup you made before upgrade.
|
||||
|
||||
>**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
|
||||
:::danger
|
||||
|
||||
Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
|
||||
|
||||
:::
|
||||
|
||||
1. Using a remote Terminal connection, log into the node running your Rancher Server.
|
||||
|
||||
@@ -78,7 +82,11 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
|
||||
```
|
||||
Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/#privileged-access-for-rancher)
|
||||
|
||||
>**Note:** _Do not_ stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
|
||||
:::note Important:
|
||||
|
||||
**_Do not_** stop the rollback after initiating it, even if the rollback process seems longer than expected. Stopping the rollback may result in database issues during future upgrades.
|
||||
|
||||
:::
|
||||
|
||||
1. Wait a few moments and then open Rancher in a web browser. Confirm that the rollback succeeded and that your data is restored.
|
||||
|
||||
|
||||
+50
-15
@@ -5,7 +5,11 @@ weight: 1010
|
||||
|
||||
The following instructions will guide you through upgrading a Rancher server that was installed with Docker.
|
||||
|
||||
> **Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher/) before upgrading.
|
||||
:::note Important:
|
||||
|
||||
**Docker installs are not supported in production environments.** These instructions are provided for testing and development purposes only. If you have already deployed a Docker install in production and need to upgrade to a new Rancher version, we recommend [migrating to the Helm chart install]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher/) before upgrading.
|
||||
|
||||
:::
|
||||
|
||||
# Prerequisites
|
||||
|
||||
@@ -112,7 +116,11 @@ docker pull rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
|
||||
Start a new Rancher server container using the data from the `rancher-data` container. Remember to pass in all the environment variables that you had used when you started the original container.
|
||||
|
||||
>**Important:** _Do not_ stop the upgrade after initiating it, even if the upgrade process seems longer than expected. Stopping the upgrade may result in database migration errors during future upgrades.
|
||||
:::note Important:
|
||||
|
||||
**_Do not_** stop the upgrade after initiating it, even if the upgrade process seems longer than expected. Stopping the upgrade may result in database migration errors during future upgrades.
|
||||
|
||||
:::
|
||||
|
||||
If you used a proxy, see [HTTP Proxy Configuration.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/proxy/)
|
||||
|
||||
@@ -158,7 +166,11 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
|
||||
|
||||
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
|
||||
|
||||
>**Reminder of the Cert Prerequisite:** The certificate files must be in PEM format. In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates.
|
||||
:::note Reminder of the Cert Prerequisite:
|
||||
|
||||
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates.
|
||||
|
||||
:::
|
||||
|
||||
Placeholder | Description
|
||||
------------|-------------
|
||||
@@ -189,7 +201,11 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
|
||||
|
||||
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with. Remember to include `--no-cacerts` as an argument to the container to disable the default CA certificate generated by Rancher.
|
||||
|
||||
>**Reminder of the Cert Prerequisite:** The certificate files must be in PEM format. In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
:::note Reminder of the Cert Prerequisite:
|
||||
|
||||
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
|
||||
:::
|
||||
|
||||
Placeholder | Description
|
||||
------------|-------------
|
||||
@@ -216,14 +232,20 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
|
||||
|
||||
{{% accordion id="option-d" label="Click to expand" %}}
|
||||
|
||||
>**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
|
||||
:::caution
|
||||
|
||||
Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/).
|
||||
|
||||
:::
|
||||
|
||||
If you have selected to use [Let's Encrypt](https://letsencrypt.org/) certificates, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to provide the domain that you had used when you originally installed Rancher.
|
||||
|
||||
>**Reminder of the Cert Prerequisites:**
|
||||
>
|
||||
>- Create a record in your DNS that binds your Linux host IP address to the hostname that you want to use for Rancher access (`rancher.mydomain.com` for example).
|
||||
>- Open port `TCP/80` on your Linux host. The Let's Encrypt http-01 challenge can come from any source IP address, so port `TCP/80` must be open to all IP addresses.
|
||||
:::note Reminder of the Cert Prerequisites:
|
||||
|
||||
- Create a record in your DNS that binds your Linux host IP address to the hostname that you want to use for Rancher access (`rancher.mydomain.com` for example).
|
||||
- Open port `TCP/80` on your Linux host. The Let's Encrypt http-01 challenge can come from any source IP address, so port `TCP/80` must be open to all IP addresses.
|
||||
|
||||
:::
|
||||
|
||||
Placeholder | Description
|
||||
------------|-------------
|
||||
@@ -280,7 +302,11 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
|
||||
|
||||
If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with.
|
||||
|
||||
>**Reminder of the Prerequisite:** The certificate files must be in PEM format. In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
:::note Reminder of the Cert Prerequisite:
|
||||
|
||||
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
|
||||
:::
|
||||
|
||||
Placeholder | Description
|
||||
------------|-------------
|
||||
@@ -311,7 +337,11 @@ Privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
|
||||
|
||||
If you have selected to use a certificate signed by a recognized CA, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificates that you had originally installed with.
|
||||
|
||||
>**Reminder of the Prerequisite:** The certificate files must be in PEM format. In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
:::note Reminder of the Cert Prerequisite:
|
||||
|
||||
The certificate files must be in PEM format. In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Certificate Troubleshooting.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/troubleshooting)
|
||||
|
||||
:::
|
||||
|
||||
Placeholder | Description
|
||||
------------|-------------
|
||||
@@ -321,7 +351,11 @@ Placeholder | Description
|
||||
`<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port.
|
||||
`<RANCHER_VERSION_TAG>` | The release tag of the [Rancher version]({{<baseurl>}}/rancher/v2.6/en/installation/resources/chart-options/) that you want to upgrade to.
|
||||
|
||||
> **Note:** Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
|
||||
:::note
|
||||
|
||||
Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
docker run -d --volumes-from rancher-data \
|
||||
@@ -346,10 +380,11 @@ privileged access is [required.]({{<baseurl>}}/rancher/v2.6/en/installation/othe
|
||||
|
||||
Log into Rancher. Confirm that the upgrade succeeded by checking the version displayed in the bottom-left corner of the browser window.
|
||||
|
||||
>**Having network issues in your user clusters following upgrade?**
|
||||
>
|
||||
> See [Restoring Cluster Networking]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration).
|
||||
:::note Having network issues in your user clusters following upgrade?
|
||||
|
||||
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,12 +30,14 @@ The port requirements differ based on the Rancher server architecture.
|
||||
|
||||
Rancher can be installed on any Kubernetes cluster. For Rancher installs on a K3s, RKE, or RKE2 Kubernetes cluster, refer to the tabs below. For other Kubernetes distributions, refer to the distribution's documentation for the port requirements for cluster nodes.
|
||||
|
||||
> **Notes:**
|
||||
>
|
||||
> - Rancher nodes may also require additional outbound access for any external authentication provider which is configured (LDAP for example).
|
||||
> - Kubernetes recommends TCP 30000-32767 for node port services.
|
||||
> - For firewalls, traffic may need to be enabled within the cluster and pod CIDR.
|
||||
> - Rancher nodes may also need outbound access to an external S3 location which is used for storing cluster backups (Minio for example).
|
||||
:::note Notes:
|
||||
|
||||
- Rancher nodes may also require additional outbound access for any external authentication provider which is configured (LDAP for example).
|
||||
- Kubernetes recommends TCP 30000-32767 for node port services.
|
||||
- For firewalls, traffic may need to be enabled within the cluster and pod CIDR.
|
||||
- Rancher nodes may also need outbound access to an external S3 location which is used for storing cluster backups (Minio for example).
|
||||
|
||||
:::
|
||||
|
||||
### Ports for Rancher Server Nodes on K3s
|
||||
|
||||
@@ -47,7 +49,11 @@ The nodes need to be able to reach other nodes over UDP port 8472 when Flannel V
|
||||
|
||||
If you wish to utilize the metrics server, you will need to open port 10250 on each node.
|
||||
|
||||
> **Important:** The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
|
||||
:::note Important:
|
||||
|
||||
The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
|
||||
|
||||
:::
|
||||
|
||||
The following tables break down the port requirements for inbound and outbound traffic:
|
||||
|
||||
@@ -127,7 +133,11 @@ All nodes need to be able to reach other nodes over UDP port 8472 when Flannel V
|
||||
|
||||
If you wish to utilize the metrics server, you will need to open port 10250 on each node.
|
||||
|
||||
**Important:** The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
|
||||
:::note Important:
|
||||
|
||||
The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
|
||||
|
||||
:::
|
||||
|
||||
<figcaption>Inbound Rules for RKE2 Server Nodes</figcaption>
|
||||
|
||||
@@ -183,9 +193,11 @@ The following diagram depicts the ports that are opened for each [cluster type](
|
||||
|
||||

|
||||
|
||||
>**Tip:**
|
||||
>
|
||||
>If security isn't a large concern and you're okay with opening a few additional ports, you can use the table in [Commonly Used Ports](#commonly-used-ports) as your port reference instead of the comprehensive tables below.
|
||||
:::tip
|
||||
|
||||
If security isn't a large concern and you're okay with opening a few additional ports, you can use the table in [Commonly Used Ports](#commonly-used-ports) as your port reference instead of the comprehensive tables below.
|
||||
|
||||
:::
|
||||
|
||||
### Ports for Rancher Launched Kubernetes Clusters using Node Pools
|
||||
|
||||
@@ -193,8 +205,11 @@ The following diagram depicts the ports that are opened for each [cluster type](
|
||||
|
||||
The following table depicts the port requirements for [Rancher Launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) with nodes created in an [Infrastructure Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/).
|
||||
|
||||
>**Note:**
|
||||
>The required ports are automatically opened by Rancher during creation of clusters in cloud providers like Amazon EC2 or DigitalOcean.
|
||||
:::note
|
||||
|
||||
The required ports are automatically opened by Rancher during creation of clusters in cloud providers like Amazon EC2 or DigitalOcean.
|
||||
|
||||
:::
|
||||
|
||||
{{< ports-iaas-nodes >}}
|
||||
|
||||
|
||||
@@ -6,7 +6,11 @@ weight: 1
|
||||
|
||||
This page describes the software, hardware, and networking requirements for the nodes where the Rancher server will be installed. The Rancher server can be installed on a single node or a high-availability Kubernetes cluster.
|
||||
|
||||
> It is important to note that if you install Rancher on a Kubernetes cluster, requirements are different from the [node requirements for downstream user clusters,]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/) which will run your apps and services.
|
||||
:::note Important:
|
||||
|
||||
If you install Rancher on a Kubernetes cluster, requirements are different from the [node requirements for downstream user clusters,]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/) which will run your apps and services.
|
||||
|
||||
:::
|
||||
|
||||
Make sure the node(s) for the Rancher server fulfill the following requirements:
|
||||
|
||||
@@ -164,7 +168,11 @@ Rancher performance depends on etcd in the cluster performance. To ensure optima
|
||||
|
||||
This section describes the networking requirements for the node(s) where the Rancher server is installed.
|
||||
|
||||
> If a server containing Rancher has the `X-Frame-Options=DENY` header, some pages in the new Rancher UI will not be able to render after upgrading from the legacy UI. This is because some legacy pages are embedded as iFrames in the new UI.
|
||||
:::caution
|
||||
|
||||
If a server containing Rancher has the `X-Frame-Options=DENY` header, some pages in the new Rancher UI will not be able to render after upgrading from the legacy UI. This is because some legacy pages are embedded as iFrames in the new UI.
|
||||
|
||||
:::
|
||||
|
||||
### Node IP Addresses
|
||||
|
||||
|
||||
@@ -3,9 +3,11 @@ title: "Running on ARM64 (Experimental)"
|
||||
weight: 3
|
||||
---
|
||||
|
||||
> **Important:**
|
||||
>
|
||||
> Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment.
|
||||
:::caution:
|
||||
|
||||
Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment.
|
||||
|
||||
:::
|
||||
|
||||
The following options are available when using an ARM64 platform:
|
||||
|
||||
@@ -19,12 +21,15 @@ The following options are available when using an ARM64 platform:
|
||||
--privileged \
|
||||
rancher/rancher:vX.Y.Z
|
||||
```
|
||||
> **Note:** To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your
|
||||
> version's release notes in the following two ways:
|
||||
>
|
||||
> - Manually find your version using https://github.com/rancher/rancher/releases.
|
||||
> - Go directly to your version using the tag and the specific version number. If you plan to use v2.5.8, for example, you may
|
||||
> navigate to https://github.com/rancher/rancher/releases/tag/v2.5.8.
|
||||
:::note
|
||||
|
||||
To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your
|
||||
version's release notes in the following two ways:
|
||||
|
||||
- Manually find your version using https://github.com/rancher/rancher/releases.
|
||||
- Go directly to your version using the tag and the specific version number. If you plan to use v2.5.8, for example, you may navigate to https://github.com/rancher/rancher/releases/tag/v2.5.8.
|
||||
|
||||
:::
|
||||
|
||||
- Create custom cluster and adding ARM64 based node(s)
|
||||
- Kubernetes cluster version must be 1.12 or higher
|
||||
|
||||
+30
-15
@@ -31,22 +31,27 @@ Provision a single Linux host according to our [Requirements]({{<baseurl>}}/ranc
|
||||
|
||||
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.
|
||||
|
||||
> **Do you want to..**.
|
||||
>
|
||||
> - Complete an Air Gap Installation?
|
||||
> - Record all transactions with the Rancher API?
|
||||
>
|
||||
> See [Advanced Options](#advanced-options) below before continuing.
|
||||
:::note Do you want to..
|
||||
|
||||
- Complete an Air Gap Installation?
|
||||
- Record all transactions with the Rancher API?
|
||||
|
||||
See [Advanced Options](#advanced-options) below before continuing.
|
||||
|
||||
:::
|
||||
|
||||
Choose from the following options:
|
||||
|
||||
{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
|
||||
If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
|
||||
|
||||
> **Prerequisites:**
|
||||
> Create a self-signed certificate.
|
||||
>
|
||||
> - The certificate files must be in PEM format.
|
||||
:::note Prerequisites:
|
||||
|
||||
Create a self-signed certificate.
|
||||
|
||||
- The certificate files must be in PEM format.
|
||||
|
||||
:::
|
||||
|
||||
**To Install Rancher Using a Self-Signed Cert:**
|
||||
|
||||
@@ -63,9 +68,11 @@ If you elect to use a self-signed certificate to encrypt communication, you must
|
||||
{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
|
||||
If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The certificate files must be in PEM format.
|
||||
:::note Prerequisites:
|
||||
|
||||
- The certificate files must be in PEM format.
|
||||
|
||||
:::
|
||||
|
||||
**To Install Rancher Using a Cert Signed by a Recognized CA:**
|
||||
|
||||
@@ -101,7 +108,11 @@ The load balancer or proxy has to be configured to support the following:
|
||||
|
||||
This NGINX configuration is tested on NGINX 1.14.
|
||||
|
||||
> **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
||||
:::note
|
||||
|
||||
This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
||||
|
||||
:::
|
||||
|
||||
- Replace `rancher-server` with the IP address or hostname of the node running the Rancher container.
|
||||
- Replace both occurrences of `FQDN` to the DNS name for Rancher.
|
||||
@@ -205,7 +216,11 @@ As of Rancher v2.5, privileged access is [required.]({{<baseurl>}}/rancher/v2.6/
|
||||
|
||||
This layer 7 NGINX configuration is tested on NGINX version 1.13 (mainline) and 1.14 (stable).
|
||||
|
||||
> **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
|
||||
:::note
|
||||
|
||||
This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
|
||||
|
||||
:::
|
||||
|
||||
```
|
||||
upstream rancher {
|
||||
|
||||
@@ -29,7 +29,11 @@ Rancher provides several different Helm chart repositories to choose from. We al
|
||||
<br/>
|
||||
Instructions on when to select these repos are available below in [Switching to a Different Helm Chart Repository](#switching-to-a-different-helm-chart-repository).
|
||||
|
||||
> **Note:** All charts in the `rancher-stable` repository will correspond with any Rancher version tagged as `stable`.
|
||||
:::note
|
||||
|
||||
All charts in the `rancher-stable` repository will correspond with any Rancher version tagged as `stable`.
|
||||
|
||||
:::
|
||||
|
||||
### Helm Chart Versions
|
||||
|
||||
@@ -46,7 +50,11 @@ To fetch a specific version of your chosen repo, define the `--version` paramete
|
||||
|
||||
After installing Rancher, if you want to change which Helm chart repository to install Rancher from, you will need to follow these steps.
|
||||
|
||||
> **Note:** Because the rancher-alpha repository contains only alpha charts, switching between the rancher-alpha repository and the rancher-stable or rancher-latest repository for upgrades is not supported.
|
||||
:::note
|
||||
|
||||
Because the rancher-alpha repository contains only alpha charts, switching between the rancher-alpha repository and the rancher-stable or rancher-latest repository for upgrades is not supported.
|
||||
|
||||
:::
|
||||
|
||||
{{< release-channel >}}
|
||||
|
||||
@@ -87,10 +95,12 @@ Rancher Server is distributed as a Docker image, which have tags attached to the
|
||||
| `rancher/rancher:stable` | Our newest stable release. This tag is recommended for production. |
|
||||
| `rancher/rancher:<v2.X.X>` | You can install specific versions of Rancher by using the tag from a previous release. See what's available at DockerHub. |
|
||||
|
||||
> **Notes:**
|
||||
>
|
||||
> - The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
|
||||
> - Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). Caveat: Alpha releases cannot be upgraded to or from any other release.
|
||||
:::note
|
||||
|
||||
- The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported.
|
||||
- Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). Caveat: Alpha releases cannot be upgraded to or from any other release.
|
||||
|
||||
:::
|
||||
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
@@ -21,7 +21,11 @@ Because the API sets the actual value and the command line sets the default valu
|
||||
|
||||
For example, if you install Rancher, then set a feature flag to true with the Rancher API, then upgrade Rancher with a command that sets the feature flag to false, the default value will still be false, but the feature will still be enabled because it was set with the Rancher API. If you then deleted the set value (true) with the Rancher API, setting it to NULL, the default value (false) would take effect.
|
||||
|
||||
> **Note:** There are some feature flags that may require a restart of the Rancher server container. These features that require a restart are marked in the table of these docs and in the UI.
|
||||
:::note
|
||||
|
||||
There are some feature flags that may require a restart of the Rancher server container. These features that require a restart are marked in the table of these docs and in the UI.
|
||||
|
||||
:::
|
||||
|
||||
The following is a list of the feature flags available in Rancher:
|
||||
|
||||
@@ -59,7 +63,11 @@ When you install Rancher, enable the feature you want with a feature flag. The c
|
||||
|
||||
### Enabling Features for Kubernetes Installs
|
||||
|
||||
> **Note:** Values set from the Rancher API will override the value passed in through the command line.
|
||||
:::note
|
||||
|
||||
Values set from the Rancher API will override the value passed in through the command line.
|
||||
|
||||
:::
|
||||
|
||||
When installing Rancher with a Helm chart, use the `--set` option. In the below example, two features are enabled by passing the feature flag names in a comma separated list:
|
||||
|
||||
|
||||
@@ -7,16 +7,23 @@ weight: 3
|
||||
|
||||
This section describes how to install a Kubernetes cluster. This cluster should be dedicated to run only the Rancher server.
|
||||
|
||||
> Rancher can run on any Kubernetes cluster, included hosted Kubernetes solutions such as Amazon EKS. The below instructions represent only one possible way to install Kubernetes.
|
||||
:::note
|
||||
|
||||
Rancher can run on any Kubernetes cluster, included hosted Kubernetes solutions such as Amazon EKS. The below instructions represent only one possible way to install Kubernetes.
|
||||
|
||||
:::
|
||||
|
||||
For systems without direct internet access, refer to [Air Gap: Kubernetes install.]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap/)
|
||||
|
||||
> **Single-node Installation Tip:**
|
||||
> In a single-node Kubernetes cluster, the Rancher server does not have high availability, which is important for running Rancher in production. However, installing Rancher on a single-node cluster can be useful if you want to save resources by using a single node in the short term, while preserving a high-availability migration path.
|
||||
>
|
||||
> To set up a single-node RKE cluster, configure only one node in the `cluster.yml` . The single node should have all three roles: `etcd`, `controlplane`, and `worker`.
|
||||
>
|
||||
> In both single-node setups, Rancher can be installed with Helm on the Kubernetes cluster in the same way that it would be installed on any other cluster.
|
||||
:::tip Single-node Installation Tip:
|
||||
|
||||
In a single-node Kubernetes cluster, the Rancher server does not have high availability, which is important for running Rancher in production. However, installing Rancher on a single-node cluster can be useful if you want to save resources by using a single node in the short term, while preserving a high-availability migration path.
|
||||
|
||||
To set up a single-node RKE cluster, configure only one node in the `cluster.yml` . The single node should have all three roles: `etcd`, `controlplane`, and `worker`.
|
||||
|
||||
In both single-node setups, Rancher can be installed with Helm on the Kubernetes cluster in the same way that it would be installed on any other cluster.
|
||||
|
||||
:::
|
||||
|
||||
# Installing Kubernetes
|
||||
|
||||
@@ -75,13 +82,17 @@ ingress:
|
||||
| `internal_address` | no | The private DNS or IP address for internal cluster traffic |
|
||||
| `ssh_key_path` | no | Path to SSH private key used to authenticate to the node (defaults to `~/.ssh/id_rsa`) |
|
||||
|
||||
> **Advanced Configurations:** RKE has many configuration options for customizing the install to suit your specific environment.
|
||||
>
|
||||
> Please see the [RKE Documentation]({{<baseurl>}}/rke/latest/en/config-options/) for the full list of options and capabilities.
|
||||
>
|
||||
> For tuning your etcd cluster for larger Rancher installations, see the [etcd settings guide]({{<baseurl>}}/rancher/v2.6/en/installation/resources/advanced/etcd/).
|
||||
>
|
||||
> For more information regarding Dockershim support, refer to [this page]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/dockershim/)
|
||||
:::note Advanced Configurations:
|
||||
|
||||
RKE has many configuration options for customizing the install to suit your specific environment.
|
||||
|
||||
Please see the [RKE Documentation]({{<baseurl>}}/rke/latest/en/config-options/) for the full list of options and capabilities.
|
||||
|
||||
For tuning your etcd cluster for larger Rancher installations, see the [etcd settings guide]({{<baseurl>}}/rancher/v2.6/en/installation/resources/advanced/etcd/).
|
||||
|
||||
For more information regarding Dockershim support, refer to [this page]({{<baseurl>}}/rancher/v2.6/en/installation/requirements/dockershim/)
|
||||
|
||||
:::
|
||||
|
||||
### 2. Run RKE
|
||||
|
||||
@@ -99,7 +110,11 @@ Assuming you have installed `kubectl`, you need to place the `kubeconfig` file i
|
||||
|
||||
When you ran `rke up`, RKE should have created a `kubeconfig` file named `kube_config_cluster.yml`. This file has the credentials for `kubectl` and `helm`.
|
||||
|
||||
> **Note:** If you have used a different file name from `rancher-cluster.yml`, then the kube config file will be named `kube_config_<FILE_NAME>.yml`.
|
||||
:::note
|
||||
|
||||
If you have used a different file name from `rancher-cluster.yml`, then the kube config file will be named `kube_config_<FILE_NAME>.yml`.
|
||||
|
||||
:::
|
||||
|
||||
Move this file to `$HOME/.kube/config`, or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`:
|
||||
|
||||
@@ -149,8 +164,11 @@ This confirms that you have successfully installed a Kubernetes cluster that the
|
||||
|
||||
### 5. Save Your Files
|
||||
|
||||
> **Important**
|
||||
> The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
|
||||
:::note Important:
|
||||
|
||||
The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster.
|
||||
|
||||
:::
|
||||
|
||||
Save a copy of the following files in a secure location:
|
||||
|
||||
@@ -158,7 +176,11 @@ Save a copy of the following files in a secure location:
|
||||
- `kube_config_cluster.yml`: The [Kubeconfig file]({{<baseurl>}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster.
|
||||
- `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{<baseurl>}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.<br/><br/>_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._
|
||||
|
||||
> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
:::note
|
||||
|
||||
The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
|
||||
:::
|
||||
|
||||
### Issues or errors?
|
||||
|
||||
|
||||
+9
-6
@@ -8,12 +8,15 @@ This section describes how to install a Kubernetes cluster according to the [bes
|
||||
|
||||
For systems without direct internet access, refer to the air gap installation instructions.
|
||||
|
||||
> **Single-node Installation Tip:**
|
||||
> In a single-node Kubernetes cluster, the Rancher server does not have high availability, which is important for running Rancher in production. However, installing Rancher on a single-node cluster can be useful if you want to save resources by using a single node in the short term, while preserving a high-availability migration path.
|
||||
>
|
||||
> To set up a single-node K3s cluster, run the Rancher server installation command on just one node instead of two nodes.
|
||||
>
|
||||
> In both single-node setups, Rancher can be installed with Helm on the Kubernetes cluster in the same way that it would be installed on any other cluster.
|
||||
:::tip Single-node Installation Tip:
|
||||
|
||||
In a single-node Kubernetes cluster, the Rancher server does not have high availability, which is important for running Rancher in production. However, installing Rancher on a single-node cluster can be useful if you want to save resources by using a single node in the short term, while preserving a high-availability migration path.
|
||||
|
||||
To set up a single-node K3s cluster, run the Rancher server installation command on just one node instead of two nodes.
|
||||
|
||||
In both single-node setups, Rancher can be installed with Helm on the Kubernetes cluster in the same way that it would be installed on any other cluster.
|
||||
|
||||
:::
|
||||
|
||||
# Prerequisites
|
||||
|
||||
|
||||
+5
-1
@@ -56,7 +56,11 @@ sudo usermod -aG docker ubuntu
|
||||
```
|
||||
1. Repeat these steps so that Docker is installed on each node that will eventually run the Rancher management server.
|
||||
|
||||
> To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher’s Docker installation scripts.
|
||||
:::tip
|
||||
|
||||
To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher’s Docker installation scripts.
|
||||
|
||||
:::
|
||||
|
||||
**Result:** You have set up Rancher server nodes that fulfill all the node requirements for OS, Docker, hardware and networking.
|
||||
|
||||
|
||||
+10
-3
@@ -9,7 +9,11 @@ The recommended infrastructure for the Rancher-only Kubernetes cluster differs d
|
||||
|
||||
For more information about each installation option, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation)
|
||||
|
||||
> **Note:** These nodes must be in the same region. You may place these servers in separate availability zones (datacenter).
|
||||
:::note Important:
|
||||
|
||||
These nodes must be in the same region. You may place these servers in separate availability zones (datacenter).
|
||||
|
||||
:::
|
||||
|
||||
To install the Rancher management server on a high-availability K3s cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
@@ -53,8 +57,11 @@ For an example showing how to set up an NGINX load balancer, refer to [this page
|
||||
|
||||
For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/nlb/)
|
||||
|
||||
> **Important:**
|
||||
> Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
:::caution
|
||||
|
||||
Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
|
||||
:::
|
||||
|
||||
### 4. Set up the DNS Record
|
||||
|
||||
|
||||
+10
-3
@@ -5,7 +5,11 @@ weight: 2
|
||||
|
||||
This tutorial is intended to help you create a high-availability RKE cluster that can be used to install a Rancher server.
|
||||
|
||||
> **Note:** These nodes must be in the same region. You may place these servers in separate availability zones (datacenter).
|
||||
:::note Important:
|
||||
|
||||
These nodes must be in the same region. You may place these servers in separate availability zones (datacenter).
|
||||
|
||||
:::
|
||||
|
||||
To install the Rancher management server on a high-availability RKE cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
@@ -44,8 +48,11 @@ For an example showing how to set up an NGINX load balancer, refer to [this page
|
||||
|
||||
For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/nlb/)
|
||||
|
||||
> **Important:**
|
||||
> Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
:::caution
|
||||
|
||||
Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
|
||||
:::
|
||||
|
||||
### 3. Set up the DNS Record
|
||||
|
||||
|
||||
+10
-3
@@ -7,7 +7,11 @@ This tutorial is intended to help you provision the underlying infrastructure fo
|
||||
|
||||
The recommended infrastructure for the Rancher-only Kubernetes cluster differs depending on whether Rancher will be installed on a RKE2 Kubernetes cluster, an RKE Kubernetes cluster, or a single Docker container.
|
||||
|
||||
> **Note:** These nodes must be in the same region. You may place these servers in separate availability zones (datacenter).
|
||||
:::note Important:
|
||||
|
||||
These nodes must be in the same region. You may place these servers in separate availability zones (datacenter).
|
||||
|
||||
::
|
||||
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
@@ -38,8 +42,11 @@ For an example showing how to set up an NGINX load balancer, refer to [this page
|
||||
|
||||
For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{<baseurl>}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/nlb/)
|
||||
|
||||
> **Important:**
|
||||
> Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
:::caution
|
||||
|
||||
Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications.
|
||||
|
||||
:::
|
||||
|
||||
### 4. Set up the DNS Record
|
||||
|
||||
|
||||
+10
-2
@@ -7,7 +7,11 @@ NGINX will be configured as Layer 4 load balancer (TCP) that forwards connection
|
||||
|
||||
In this configuration, the load balancer is positioned in front of your nodes. The load balancer can be any host capable of running NGINX.
|
||||
|
||||
One caveat: do not use one of your Rancher nodes as the load balancer.
|
||||
:::note
|
||||
|
||||
Do not use one of your Rancher nodes as the load balancer.
|
||||
|
||||
:::
|
||||
|
||||
> These examples show the load balancer being configured to direct traffic to three Rancher server nodes. If Rancher is installed on an RKE Kubernetes cluster, three nodes are required. If Rancher is installed on a K3s Kubernetes cluster, only two nodes are required.
|
||||
|
||||
@@ -25,7 +29,11 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx.
|
||||
|
||||
2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of `<IP_NODE_1>`, `<IP_NODE_2>`, and `<IP_NODE_3>` with the IPs of your nodes.
|
||||
|
||||
> **Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
||||
:::note
|
||||
|
||||
See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
||||
|
||||
:::
|
||||
|
||||
<figcaption>Example NGINX config</figcaption>
|
||||
```
|
||||
|
||||
@@ -36,7 +36,11 @@ Regardless of whether an NGINX Ingress or Traefik Ingress controller is used, th
|
||||
1. Select **Services** and choose **EC2**, find the section **Load Balancing** and open **Target Groups**.
|
||||
1. Click **Create target group** to create the first target group, regarding TCP port 443.
|
||||
|
||||
> **Note:** Health checks are handled differently based on the Ingress. For details, refer to [this section.](#health-check-paths-for-nginx-ingress-and-traefik-ingresses)
|
||||
:::note
|
||||
|
||||
Health checks are handled differently based on the Ingress. For details, refer to [this section.](#health-check-paths-for-nginx-ingress-and-traefik-ingresses)
|
||||
|
||||
:::
|
||||
|
||||
### Target Group (TCP port 443)
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ The [single-node Docker installation]({{<baseurl>}}/rancher/v2.6/en/installation
|
||||
|
||||
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.
|
||||
|
||||
### Air Gapped Installations
|
||||
### Air-Gapped Installations
|
||||
|
||||
Follow [these steps]({{<baseurl>}}/rancher/v2.6/en/installation/other-installation-methods/air-gap) to install the Rancher server in an air gapped environment.
|
||||
|
||||
|
||||
@@ -18,7 +18,11 @@ kubectl -n cattle-system create secret tls tls-rancher-ingress \
|
||||
--key=tls.key
|
||||
```
|
||||
|
||||
> **Note:** If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. If you are using a private CA signed certificate, replacing the certificate is only possible if the new certificate is signed by the same CA as the certificate currently in use.
|
||||
:::note
|
||||
|
||||
If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. If you are using a private CA signed certificate, replacing the certificate is only possible if the new certificate is signed by the same CA as the certificate currently in use.
|
||||
|
||||
:::
|
||||
|
||||
# Using a Private CA Signed Certificate
|
||||
|
||||
@@ -31,7 +35,11 @@ kubectl -n cattle-system create secret generic tls-ca \
|
||||
--from-file=cacerts.pem=./cacerts.pem
|
||||
```
|
||||
|
||||
> **Note:** The configured `tls-ca` secret is retrieved when Rancher starts. On a running Rancher installation the updated CA will take effect after new Rancher pods are started.
|
||||
:::note
|
||||
|
||||
The configured `tls-ca` secret is retrieved when Rancher starts. On a running Rancher installation the updated CA will take effect after new Rancher pods are started.
|
||||
|
||||
:::
|
||||
|
||||
# Updating a Private CA Certificate
|
||||
|
||||
|
||||
@@ -71,7 +71,11 @@ kubectl -n cattle-system logs -f rancher-784d94f59b-vgqzh
|
||||
|
||||
Use your browser to check the certificate details. If it says the Common Name is "Kubernetes Ingress Controller Fake Certificate", something may have gone wrong with reading or issuing your SSL cert.
|
||||
|
||||
> **Note:** if you are using LetsEncrypt to issue certs it can sometimes take a few minutes to issue the cert.
|
||||
:::note
|
||||
|
||||
If you are using LetsEncrypt to issue certs, it can sometimes take a few minutes to issue the cert.
|
||||
|
||||
:::
|
||||
|
||||
### Checking for issues with cert-manager issued certs (Rancher Generated or LetsEncrypt)
|
||||
|
||||
|
||||
@@ -59,7 +59,11 @@ $ kubectl -n cattle-system create secret generic tls-ca \
|
||||
|
||||
## 3. Reconfigure the Rancher deployment
|
||||
|
||||
> Before proceeding, generate an API token in the Rancher UI (<b>User > API & Keys</b>) and save the Bearer Token which you might need in step 4.
|
||||
:::note
|
||||
|
||||
Before proceeding, generate an API token in the Rancher UI (<b>User > API & Keys</b>) and save the Bearer Token which you might need in step 4.
|
||||
|
||||
:::
|
||||
|
||||
This step is required if Rancher was initially installed with self-signed certificates (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`).
|
||||
|
||||
@@ -157,7 +161,11 @@ Fleet agents in Rancher managed clusters store kubeconfig that is used to connec
|
||||
|
||||
# Updating from a Private CA Certificate to a Common Certificate
|
||||
|
||||
>It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are outlined below.
|
||||
:::note
|
||||
|
||||
It is possible to perform the opposite procedure as shown above: you may change from a private certificate to a common, or non-private, certificate. The steps involved are outlined below.
|
||||
|
||||
:::
|
||||
|
||||
## 1. Create/update the certificate secret resource
|
||||
|
||||
@@ -198,7 +206,11 @@ kubectl -n cattle-system delete secret tls-ca
|
||||
|
||||
## 3. Reconfigure the Rancher deployment
|
||||
|
||||
> Before proceeding, [generate an API token in the Rancher UI]({{<baseurl>}}/rancher/v2.6/en/user-settings/api-keys/#creating-an-api-key) (<b>User > API & Keys</b>).
|
||||
:::note Important:
|
||||
|
||||
Before proceeding, [generate an API token in the Rancher UI]({{<baseurl>}}/rancher/v2.6/en/user-settings/api-keys/#creating-an-api-key) (<b>User > API & Keys</b>).
|
||||
|
||||
:::
|
||||
|
||||
This step is required if Rancher was initially installed with self-signed certificates (`ingress.tls.source=rancher`) or with a Let's Encrypt issued certificate (`ingress.tls.source=letsEncrypt`).
|
||||
|
||||
|
||||
@@ -39,8 +39,11 @@ In order to upgrade cert-manager, follow these instructions:
|
||||
issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml
|
||||
```
|
||||
|
||||
> **Important:**
|
||||
> If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. If you use any cert-manager annotations on any of your other resources, you will need to update them to reflect the new API group. For details, refer to the documentation on [additional annotation changes.](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)
|
||||
:::note Important:
|
||||
|
||||
If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. If you use any cert-manager annotations on any of your other resources, you will need to update them to reflect the new API group. For details, refer to the documentation on [additional annotation changes.](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes)
|
||||
|
||||
:::
|
||||
|
||||
1. [Uninstall existing deployment](https://cert-manager.io/docs/installation/uninstall/kubernetes/#uninstalling-with-helm)
|
||||
|
||||
@@ -182,8 +185,11 @@ Before you can perform the upgrade, you must prepare your air gapped environment
|
||||
kubectl apply -f cert-manager/cert-manager-crd.yaml
|
||||
```
|
||||
|
||||
> **Note:**
|
||||
> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false` flag to your `kubectl apply` command above. Otherwise, you will receive a validation error relating to the `x-kubernetes-preserve-unknown-fields` field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation.
|
||||
:::note Important:
|
||||
|
||||
If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false` flag to your `kubectl apply` command above. Otherwise, you will receive a validation error relating to the `x-kubernetes-preserve-unknown-fields` field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation.
|
||||
|
||||
:::
|
||||
|
||||
1. Create the namespace for cert-manager
|
||||
|
||||
|
||||
+8
-6
@@ -7,12 +7,14 @@ If you have restrictive Pod Security Policies enabled, then Istio may not be abl
|
||||
|
||||
The Istio CNI plugin removes the need for each application pod to have a privileged `NET_ADMIN` container. For further information, see the [Istio CNI Plugin docs](https://istio.io/docs/setup/additional-setup/cni). Please note that the [Istio CNI Plugin is in alpha](https://istio.io/about/feature-stages/).
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The cluster must be an RKE Kubernetes cluster.
|
||||
> - The cluster must have been created with a default PodSecurityPolicy.
|
||||
>
|
||||
> To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.
|
||||
:::note Prerequisites:
|
||||
|
||||
- The cluster must be an RKE Kubernetes cluster.
|
||||
- The cluster must have been created with a default PodSecurityPolicy.
|
||||
|
||||
To enable pod security policy support when creating a Kubernetes cluster in the Rancher UI, go to <b>Advanced Options.</b> In the <b>Pod Security Policy Support</b> section, click <b>Enabled.</b> Then select a default pod security policy.
|
||||
|
||||
:::
|
||||
|
||||
1. [Set the PodSecurityPolicy to unrestricted](#1-set-the-podsecuritypolicy-to-unrestricted)
|
||||
2. [Enable the CNI](#2-enable-the-cni)
|
||||
|
||||
@@ -36,7 +36,11 @@ This option allows you to define which specific services or pods you would like
|
||||
|
||||
The usability tradeoff is that you have to create the service monitor or pod monitor per namespace since you cannot monitor across namespaces.
|
||||
|
||||
> **Prerequisite:** Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example ServiceMonitor is provided below.
|
||||
:::note Prerequisite:
|
||||
|
||||
Define a ServiceMonitor or PodMonitor for `<your namespace>`. An example ServiceMonitor is provided below.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
|
||||
@@ -9,7 +9,11 @@ The CPU and memory allocations for each component are [configurable.](#configuri
|
||||
|
||||
Before enabling Istio, we recommend that you confirm that your Rancher worker nodes have enough CPU and memory to run all of the components of Istio.
|
||||
|
||||
> **Tip:** In larger deployments, it is strongly advised that the infrastructure be placed on dedicated nodes in the cluster by adding a node selector for each Istio component.
|
||||
:::tip
|
||||
|
||||
In larger deployments, it is strongly advised that the infrastructure be placed on dedicated nodes in the cluster by adding a node selector for each Istio component.
|
||||
|
||||
:::
|
||||
|
||||
The table below shows a summary of the minimum recommended resource requests and limits for the CPU and memory of each core Istio component.
|
||||
|
||||
|
||||
@@ -3,7 +3,11 @@ title: 3. Add Deployments and Services with the Istio Sidecar
|
||||
weight: 4
|
||||
---
|
||||
|
||||
> **Prerequisite:** To enable Istio for a workload, the cluster and namespace must have the Istio app installed.
|
||||
:::note Prerequisite:
|
||||
|
||||
To enable Istio for a workload, the cluster and namespace must have the Istio app installed.
|
||||
|
||||
:::
|
||||
|
||||
Enabling Istio in a namespace only enables automatic sidecar injection for new workloads. To enable the Envoy sidecar for existing workloads, you need to enable it manually for each workload.
|
||||
|
||||
|
||||
@@ -3,12 +3,14 @@ title: 1. Enable Istio in the Cluster
|
||||
weight: 1
|
||||
---
|
||||
|
||||
>**Prerequisites:**
|
||||
>
|
||||
>- Only a user with the `cluster-admin` [Kubernetes default role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) assigned can configure and install Istio in a Kubernetes cluster.
|
||||
>- If you have pod security policies, you will need to install Istio with the CNI enabled. For details, see [this section.]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/enable-istio-with-psp)
|
||||
>- To install Istio on an RKE2 cluster, additional steps are required. For details, see [this section.]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/rke2/)
|
||||
>- To install Istio in a cluster where project network isolation is enabled, additional steps are required. For details, see [this section.]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/canal-and-project-network)
|
||||
:::note Prerequisites:
|
||||
|
||||
- Only a user with the `cluster-admin` [Kubernetes default role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) assigned can configure and install Istio in a Kubernetes cluster.
|
||||
- If you have pod security policies, you will need to install Istio with the CNI enabled. For details, see [this section.]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/enable-istio-with-psp)
|
||||
- To install Istio on an RKE2 cluster, additional steps are required. For details, see [this section.]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/rke2/)
|
||||
- To install Istio in a cluster where project network isolation is enabled, additional steps are required. For details, see [this section.]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/canal-and-project-network)
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the where you want to enable Istio and click **Explore**.
|
||||
|
||||
@@ -7,7 +7,11 @@ You will need to manually enable Istio in each namespace that you want to be tra
|
||||
|
||||
This namespace setting will only affect new workloads in the namespace. Any preexisting workloads will need to be re-deployed to leverage the sidecar auto injection.
|
||||
|
||||
> **Prerequisite:** To enable Istio in a namespace, the cluster must have Istio installed.
|
||||
:::note Prerequisite:
|
||||
|
||||
To enable Istio in a namespace, the cluster must have Istio installed.
|
||||
|
||||
:::
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster that you created and click **Explore**.
|
||||
@@ -39,7 +43,11 @@ To add the annotation to a workload,
|
||||
|
||||
**Result:** The Istio sidecar will not be injected into the workload.
|
||||
|
||||
> **NOTE:** If you are having issues with a Job you deployed not completing, you will need to add this annotation to your pod using the provided steps. Since Istio Sidecars run indefinitely, a Job cannot be considered complete even after its task has completed.
|
||||
:::note
|
||||
|
||||
If you are having issues with a Job you deployed not completing, you will need to add this annotation to your pod using the provided steps. Since Istio Sidecars run indefinitely, a Job cannot be considered complete even after its task has completed.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
### [Next: Add Deployments with the Istio Sidecar ]({{<baseurl>}}/rancher/v2.6/en/istio/setup/deploy-workloads)
|
||||
@@ -18,7 +18,9 @@ The workloads and services that you want to be controlled by Istio must meet [Is
|
||||
|
||||
# Install
|
||||
|
||||
> **Quick Setup** If you don't need external traffic to reach Istio, and you just want to set up Istio for monitoring and tracing traffic within the cluster, skip the steps for [setting up the Istio gateway]({{<baseurl>}}/rancher/v2.6/en/istio/setup/gateway) and [setting up Istio's components for traffic management.]({{<baseurl>}}/rancher/v2.6/en/istio/setup/set-up-traffic-management)
|
||||
:::tip Quick Setup Tip: If you don't need external traffic to reach Istio, and you just want to set up Istio for monitoring and tracing traffic within the cluster, skip the steps for [setting up the Istio gateway]({{<baseurl>}}/rancher/v2.6/en/istio/setup/gateway) and [setting up Istio's components for traffic management.]({{<baseurl>}}/rancher/v2.6/en/istio/setup/set-up-traffic-management)
|
||||
|
||||
:::
|
||||
|
||||
1. [Enable Istio in the cluster.]({{<baseurl>}}/rancher/v2.6/en/istio/setup/enable-istio-in-cluster)
|
||||
1. [Enable Istio in all the namespaces where you want to use it.]({{<baseurl>}}/rancher/v2.6/en/istio/setup/enable-istio-in-namespace)
|
||||
|
||||
@@ -9,7 +9,11 @@ This section describes how to view the traffic that is being managed by Istio.
|
||||
|
||||
The Istio overview page provides a link to the Kiali dashboard. From the Kiali dashboard, you are able to view graphs for each namespace. The Kiali graph provides a powerful way to visualize the topology of your Istio service mesh. It shows you which services communicate with each other.
|
||||
|
||||
>**Prerequisite:** To enable traffic to show up in the graph, ensure you have prometheus installed in the cluster. Rancher-istio installs Kiali configured by default to work with the rancher-monitoring chart. You can use rancher-monitoring or install your own monitoring solution. Optional: you can change configuration on how data scraping occurs by setting the [Selectors & Scrape Configs]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/selectors-and-scrape) options.
|
||||
:::note Prerequisites:
|
||||
|
||||
To enable traffic to show up in the graph, ensure you have prometheus installed in the cluster. Rancher-istio installs Kiali configured by default to work with the rancher-monitoring chart. You can use rancher-monitoring or install your own monitoring solution. Optional: you can change configuration on how data scraping occurs by setting the [Selectors & Scrape Configs]({{<baseurl>}}/rancher/v2.6/en/istio/configuration-reference/selectors-and-scrape) options.
|
||||
|
||||
:::
|
||||
|
||||
To see the traffic graph,
|
||||
|
||||
|
||||
@@ -6,7 +6,11 @@ weight: 3060
|
||||
|
||||
When you create an ingress within Rancher/Kubernetes, you must provide it with a secret that includes a TLS private key and certificate, which are used to encrypt and decrypt communications that come through the ingress. You can make certificates available for ingress use by adding the certificate to the ingress deployment.
|
||||
|
||||
>**Prerequisites:** You must have a TLS private key and certificate available to upload.
|
||||
:::note Prerequisite:
|
||||
|
||||
You must have a TLS private key and certificate available to upload.
|
||||
|
||||
:::
|
||||
|
||||
### 1. Create a Secret
|
||||
|
||||
|
||||
@@ -13,8 +13,12 @@ ConfigMaps accept key value pairs in common string formats, like config files or
|
||||
1. Click **Create**.
|
||||
1. Enter a **Name** for the Config Map.
|
||||
|
||||
>**Note:** Kubernetes classifies ConfigMaps as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your ConfigMaps must have a unique name among the other certificates, registries, and secrets within your workspace.
|
||||
:::note
|
||||
|
||||
Kubernetes classifies ConfigMaps as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your ConfigMaps must have a unique name among the other certificates, registries, and secrets within your workspace.
|
||||
|
||||
:::
|
||||
|
||||
1. Select the **Namespace** you want to add Config Map to.
|
||||
|
||||
1. On the **Data** tab, add a key-value pair to your ConfigMap. Add as many values as you need. You can add multiple key value pairs to the ConfigMap by copying and pasting. Alternatively, use **Read from File** to add the data. Note: If you need to store sensitive data, [use a secret]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/secrets/), not a ConfigMap.
|
||||
|
||||
+10
-2
@@ -21,7 +21,11 @@ If you want to create HPAs that scale based on other metrics than CPU and memory
|
||||
|
||||
1. Click **Create** to create the HPA.
|
||||
|
||||
> **Result:** The HPA is deployed to the chosen namespace. You can view the HPA's status from the project's Resources > HPA view.
|
||||
:::note Result:
|
||||
|
||||
The HPA is deployed to the chosen namespace. You can view the HPA's status from the project's Resources > HPA view.
|
||||
|
||||
:::
|
||||
|
||||
## Get HPA Metrics and Status
|
||||
|
||||
@@ -41,4 +45,8 @@ For more detailed metrics and status of a specific HPA, click the name of the HP
|
||||
1. Find the HPA which you would like to delete and click **⋮ > Delete**.
|
||||
1. Click **Delete** to confirm.
|
||||
|
||||
> **Result:** The HPA is deleted from the current cluster.
|
||||
:::note Result:
|
||||
|
||||
The HPA is deleted from the current cluster.
|
||||
|
||||
:::
|
||||
@@ -31,7 +31,12 @@ If you use this option, ingress routes requests for a hostname to the service or
|
||||
1. **Optional:** If you want specify a workload or service when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field. Typically, the first rule that you create does not include a path.
|
||||
1. Enter the **Port** number that each target operates on.
|
||||
### Certificates
|
||||
>**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/certificates/).
|
||||
|
||||
:::note
|
||||
|
||||
You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/certificates/).
|
||||
|
||||
:::
|
||||
|
||||
1. When creating an ingress, click the **Certificates** tab.
|
||||
1. Click **Add Certificate**.
|
||||
|
||||
@@ -52,9 +52,11 @@ Your ingress, which creates a port of entry to your cluster similar to a load ba
|
||||
|
||||
Ingress can provide other functionality as well, such as SSL termination, name-based virtual hosting, and more.
|
||||
|
||||
>**Using Rancher in a High Availability Configuration?**
|
||||
>
|
||||
>Refrain from adding an Ingress to the `local` cluster. The Nginx Ingress Controller that Rancher uses acts as a global entry point for _all_ clusters managed by Rancher, including the `local` cluster. Therefore, when users try to access an application, your Rancher connection may drop due to the Nginx configuration being reloaded. We recommend working around this issue by deploying applications only in clusters that you launch using Rancher.
|
||||
:::note Using Rancher in a High Availability Configuration?
|
||||
|
||||
Refrain from adding an Ingress to the `local` cluster. The Nginx Ingress Controller that Rancher uses acts as a global entry point for _all_ clusters managed by Rancher, including the `local` cluster. Therefore, when users try to access an application, your Rancher connection may drop due to the Nginx configuration being reloaded. We recommend working around this issue by deploying applications only in clusters that you launch using Rancher.
|
||||
|
||||
:::
|
||||
|
||||
- For more information on how to set up ingress in Rancher, see [Ingress]({{<baseurl>}}/rancher/v2.6/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/)
|
||||
|
||||
@@ -11,7 +11,11 @@ Layer-4 load balancer (or the external load balancer) forwards traffic to Nodepo
|
||||
|
||||
Often, the Layer-4 load balancer is supported by the underlying cloud provider, so when you deploy RKE clusters on bare-metal servers and vSphere clusters, Layer-4 load balancer is not supported. However, a single [globally managed config-map](https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/) can be used to expose services on NGINX or third-party ingress.
|
||||
|
||||
> **Note:** It is possible to deploy a cluster with a non-cloud load balancer, such as [MetalLB.](https://metallb.universe.tf/) However, that use case is more advanced than the Layer-4 load balancer supported by a cloud provider, and it is not configurable in Rancher or RKE.
|
||||
:::note
|
||||
|
||||
It is possible to deploy a cluster with a non-cloud load balancer, such as [MetalLB.](https://metallb.universe.tf/) However, that use case is more advanced than the Layer-4 load balancer supported by a cloud provider, and it is not configurable in Rancher or RKE.
|
||||
|
||||
:::
|
||||
|
||||
### Support for Layer-4 Load Balancing
|
||||
|
||||
|
||||
@@ -16,7 +16,11 @@ Currently, deployments pull the private registry credentials automatically only
|
||||
|
||||
# Creating a Registry in Namespaces
|
||||
|
||||
>**Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.
|
||||
:::note Prerequisite:
|
||||
|
||||
You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to add a registry and click **Explore**.
|
||||
@@ -25,7 +29,11 @@ Currently, deployments pull the private registry credentials automatically only
|
||||
1. Click **Registry**.
|
||||
1. Enter a **Name** for the registry.
|
||||
|
||||
>**Note:** Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace.
|
||||
:::note
|
||||
|
||||
Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace.
|
||||
|
||||
:::
|
||||
|
||||
1. Select a namespace for the registry.
|
||||
1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password.
|
||||
@@ -39,7 +47,11 @@ Currently, deployments pull the private registry credentials automatically only
|
||||
|
||||
# Creating a Registry in Projects
|
||||
|
||||
>**Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.
|
||||
:::note Prerequisites:
|
||||
|
||||
You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.
|
||||
|
||||
:::
|
||||
|
||||
Before v2.6, secrets were required to be in a project scope. Projects are no longer required, and you may use the namespace scope instead. As a result, the Rancher UI was updated to reflect this new functionality. However, you may still create a project-scoped registry if desired. Use the following steps to do so:
|
||||
|
||||
@@ -54,7 +66,11 @@ Before v2.6, secrets were required to be in a project scope. Projects are no lon
|
||||
1. In the top navigation bar, filter to see only one project.
|
||||
1. Enter a **Name** for the registry.
|
||||
|
||||
>**Note:** Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace.
|
||||
:::note
|
||||
|
||||
Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace.
|
||||
|
||||
:::
|
||||
|
||||
1. Select a namespace for the registry.
|
||||
1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password.
|
||||
@@ -66,7 +82,11 @@ Before v2.6, secrets were required to be in a project scope. Projects are no lon
|
||||
- You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
|
||||
- Any workload that you create in the Rancher UI will have the credentials to access the registry if the workload is within the registry's scope.
|
||||
|
||||
>**Note:** Project-scoped registries on the local cluster are only visible when a single project is selected.
|
||||
:::note
|
||||
|
||||
Project-scoped registries on the local cluster are only visible when a single project is selected.
|
||||
|
||||
:::
|
||||
|
||||
# Using a Private Registry
|
||||
|
||||
|
||||
@@ -5,7 +5,11 @@ weight: 3062
|
||||
|
||||
[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs.
|
||||
|
||||
> This page is about secrets in general. For details on setting up a private registry, refer to the section on [registries.]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/registries)
|
||||
:::note
|
||||
|
||||
This page is about secrets in general. For details on setting up a private registry, refer to the section on [registries.]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/registries)
|
||||
|
||||
:::
|
||||
|
||||
When configuring a workload, you'll be able to choose which secrets to include. Like config maps, secrets can be referenced by workloads as either an environment variable or a volume mount.
|
||||
|
||||
@@ -21,13 +25,21 @@ Mounted secrets will be updated automatically unless they are mounted as subpath
|
||||
1. Select a **Namespace** for the secret.
|
||||
1. Enter a **Name** for the secret.
|
||||
|
||||
>**Note:** Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a namespace can have duplicate names. Therefore, to prevent conflicts, your secret must have a unique name among all secrets within your workspace.
|
||||
:::note
|
||||
|
||||
Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a namespace can have duplicate names. Therefore, to prevent conflicts, your secret must have a unique name among all secrets within your workspace.
|
||||
|
||||
:::
|
||||
|
||||
1. From **Data**, click **Add** to add a key-value pair. Add as many values as you need.
|
||||
|
||||
>**Tip:** You can add multiple key value pairs to the secret by copying and pasting.
|
||||
>
|
||||
> {{< img "/img/rancher/bulk-key-values.gif" "Bulk Key Value Pair Copy/Paste">}}
|
||||
:::tip
|
||||
|
||||
You can add multiple key value pairs to the secret by copying and pasting.
|
||||
|
||||
:::
|
||||
|
||||
{{< img "/img/rancher/bulk-key-values.gif" "Bulk Key Value Pair Copy/Paste">}}
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
@@ -52,7 +64,11 @@ Before v2.6, secrets were required to be in a project scope. Projects are no lon
|
||||
|
||||
**Result:** Your secret is added to the individual project you chose. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**.
|
||||
|
||||
>**Note:** Project-scoped secrets on the local cluster are only visible when a single project is selected.
|
||||
:::note
|
||||
|
||||
Project-scoped secrets on the local cluster are only visible when a single project is selected.
|
||||
|
||||
:::
|
||||
|
||||
# What's Next?
|
||||
|
||||
|
||||
@@ -36,15 +36,16 @@ Deploy a workload to run an application in one or more containers.
|
||||
|
||||
- **Scaling/Upgrade Policy**
|
||||
|
||||
>**Amazon Note for Volumes:**
|
||||
>
|
||||
> To mount an Amazon EBS volume:
|
||||
>
|
||||
>- In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes.
|
||||
>
|
||||
>- The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/) or [Creating a Custom Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes).
|
||||
|
||||
:::note Amazon Note for Volumes:
|
||||
|
||||
To mount an Amazon EBS volume:
|
||||
|
||||
- In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes.
|
||||
|
||||
- The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ec2/) or [Creating a Custom Cluster]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes).
|
||||
|
||||
:::
|
||||
|
||||
1. Click **Show Advanced Options** and configure:
|
||||
|
||||
- **Command**
|
||||
|
||||
Reference in New Issue
Block a user