mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Merge pull request #815 from btat/broken-links-2023-08
Fix broken links across versions
This commit is contained in:
+1
-1
@@ -10,7 +10,7 @@ Several of the alerts use Prometheus expressions as the metric that triggers the
|
||||
|
||||
Etcd is the key-value store that contains the state of the Kubernetes cluster. Rancher provides default alerts if the built-in monitoring detects a potential problem with etcd. You don't have to enable monitoring to receive these alerts.
|
||||
|
||||
A leader is the node that handles all client requests that need cluster consensus. For more information, you can refer to this [explanation of how etcd works.](https://rancher.com/blog/2019/2019-01-29-what-is-etcd/#how-does-etcd-work)
|
||||
A leader is the node that handles all client requests that need cluster consensus. For more information, you can refer to this [explanation of how etcd works.](https://www.rancher.cn/blog/2019/2019-01-29-what-is-etcd/#how-does-etcd-work)
|
||||
|
||||
The leader of the cluster can change in response to certain events. It is normal for the leader to change, but too many changes can indicate a problem with the network or a high CPU load. With longer latencies, the default etcd configuration may cause frequent heartbeat timeouts, which trigger a new leader election.
|
||||
|
||||
|
||||
+1
-1
@@ -69,4 +69,4 @@ To access a project-level Grafana instance,
|
||||
|
||||
1. You will be signed in to the Grafana instance automatically. The default username is `admin` and the default password is `admin`. For security, we recommend that you log out of Grafana, log back in with the `admin` password, and change your password.
|
||||
|
||||
**Results:** You will be logged into Grafana from the Grafana instance. After logging in, you can view the preset Grafana dashboards, which are imported via the [Grafana provisioning mechanism](http://docs.grafana.org/administration/provisioning/#dashboards), so you cannot modify them directly. For now, if you want to configure your own dashboards, clone the original and modify the new copy.
|
||||
**Results:** You will be logged into Grafana from the Grafana instance. After logging in, you can view the preset Grafana dashboards, which are imported via the [Grafana provisioning mechanism](https://grafana.com/docs/grafana/latest/administration/provisioning/#dashboards), so you cannot modify them directly. For now, if you want to configure your own dashboards, clone the original and modify the new copy.
|
||||
|
||||
+1
-1
@@ -56,4 +56,4 @@ When you go to the Grafana instance, you will be logged in with the username `ad
|
||||
|
||||
1. You will be signed in to the Grafana instance automatically. The default username is `admin` and the default password is `admin`. For security, we recommend that you log out of Grafana, log back in with the `admin` password, and change your password.
|
||||
|
||||
**Results:** You are logged into Grafana from the Grafana instance. After logging in, you can view the preset Grafana dashboards, which are imported via the [Grafana provisioning mechanism](http://docs.grafana.org/administration/provisioning/#dashboards), so you cannot modify them directly. For now, if you want to configure your own dashboards, clone the original and modify the new copy.
|
||||
**Results:** You are logged into Grafana from the Grafana instance. After logging in, you can view the preset Grafana dashboards, which are imported via the [Grafana provisioning mechanism](https://grafana.com/docs/grafana/latest/administration/provisioning/#dashboards), so you cannot modify them directly. For now, if you want to configure your own dashboards, clone the original and modify the new copy.
|
||||
|
||||
+2
-10
@@ -9,14 +9,6 @@ This section is about how to deploy Rancher for your air gapped environment. An
|
||||
|
||||
Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes Installation is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
This section describes installing Rancher in five parts:
|
||||
|
||||
- [A. Add the Helm Chart Repository](#a-add-the-helm-chart-repository)
|
||||
- [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration)
|
||||
- [C. Render the Rancher Helm Template](#c-render-the-rancher-helm-template)
|
||||
- [D. Install Rancher](#d-install-rancher)
|
||||
- [E. For Rancher versions before v2.3.0, Configure System Charts](#e-for-rancher-versions-before-v2-3-0-configure-system-charts)
|
||||
|
||||
### A. Add the Helm Chart Repository
|
||||
|
||||
From a system that has access to the internet, fetch the latest Helm chart and copy the resulting manifests to a system that has access to the Rancher server cluster.
|
||||
@@ -54,7 +46,7 @@ Rancher Server is designed to be secure by default and requires SSL/TLS configur
|
||||
|
||||
When Rancher is installed on an air gapped Kubernetes cluster, there are two recommended options for the source of the certificate.
|
||||
|
||||
> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../../../../../reference-guides/installation-references/helm-chart-options#external-tls-termination).
|
||||
> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer](../../../../../reference-guides/installation-references/helm-chart-options.md#external-tls-termination).
|
||||
|
||||
| Configuration | Chart option | Description | Requires cert-manager |
|
||||
| ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
|
||||
@@ -239,7 +231,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
|
||||
|
||||
> **Do you want to...**
|
||||
>
|
||||
> - Configure custom CA root certificate to access your services? See [Custom CA root certificate](../../../../../reference-guides/installation-references/helm-chart-options#additional-trusted-cas).
|
||||
> - Configure custom CA root certificate to access your services? See [Custom CA root certificate](../../../../../reference-guides/installation-references/helm-chart-options.md#additional-trusted-cas).
|
||||
> - Record all transactions with the Rancher API? See [API Auditing](../../../../../reference-guides/single-node-rancher-in-docker/advanced-options.md#api-audit-log).
|
||||
|
||||
- For Rancher before v2.3.0, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach. Then, after Rancher is installed, you will need to configure Rancher to use that repository. For details, refer to the documentation on [setting up the system charts for Rancher before v2.3.0.](../../../resources/local-system-charts.md)
|
||||
|
||||
+1
-1
@@ -157,7 +157,7 @@ Your load balancer must support long lived websocket connections and will need t
|
||||
|
||||
#### Configuring Ingress for External TLS when Using NGINX v0.25
|
||||
|
||||
In NGINX v0.25, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0220) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.25, you must edit the `cluster.yml` to enable the `use-forwarded-headers` option for ingress:
|
||||
In NGINX v0.25, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0220) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.25, you must edit the `cluster.yml` to enable the `use-forwarded-headers` option for ingress:
|
||||
|
||||
```yaml
|
||||
ingress:
|
||||
|
||||
+1
-1
@@ -205,7 +205,7 @@ Choose from the following options:
|
||||
>Create a self-signed certificate.
|
||||
>
|
||||
>- The certificate files must be in PEM format.
|
||||
>- The certificate files must be encoded in [base64](#base64).
|
||||
>- The certificate files must be encoded in base64.
|
||||
>- 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.](../../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
|
||||
|
||||
1. In `kind: Secret` with `name: cattle-keys-ingress`:
|
||||
|
||||
+1
-1
@@ -152,7 +152,7 @@ Choose from the following options:
|
||||
>Create a self-signed certificate.
|
||||
>
|
||||
>- The certificate files must be in PEM format.
|
||||
>- The certificate files must be encoded in [base64](#base64).
|
||||
>- The certificate files must be encoded in base64.
|
||||
>- 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.](../../../other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
|
||||
|
||||
In `kind: Secret` with `name: cattle-keys-ingress`, replace `<BASE64_CA>` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`)
|
||||
|
||||
+2
-2
@@ -21,7 +21,7 @@ If you installed Rancher using the RKE Add-on yaml, follow the directions to [mi
|
||||
>**Notes:**
|
||||
>
|
||||
> - [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../../resources/upgrade-cert-manager.md)
|
||||
> - If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.](../../../../reference-guides/installation-references/helm-chart-options.md#configuring-ingress-for-external-tls-when-using-nginx-v0-25)
|
||||
> - If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.](../../../../reference-guides/installation-references/helm-chart-options.md#configuring-ingress-for-external-tls-when-using-nginx-v025)
|
||||
> - 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/) This [section](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
|
||||
|
||||
## Prerequisites
|
||||
@@ -53,7 +53,7 @@ of your Kubernetes cluster running Rancher server. You'll use the snapshot as a
|
||||
|
||||
1. Get the repository name that you used to install Rancher.
|
||||
|
||||
For information about the repos and their differences, see [Helm Chart Repositories](../../../../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories).
|
||||
For information about the repos and their differences, see [Helm Chart Repositories](../../resources/choose-a-rancher-version.md#helm-chart-repositories).
|
||||
|
||||
- Latest: Recommended for trying out the newest features
|
||||
```
|
||||
|
||||
+3
-11
@@ -3,7 +3,7 @@ title: 4. Install Rancher
|
||||
---
|
||||
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha"/>
|
||||
</head>
|
||||
|
||||
@@ -14,14 +14,6 @@ This section is about how to deploy Rancher for your air gapped environment. An
|
||||
|
||||
Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes install is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
This section describes installing Rancher in five parts:
|
||||
|
||||
- [1. Add the Helm Chart Repository](#1-add-the-helm-chart-repository)
|
||||
- [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration)
|
||||
- [3. Render the Rancher Helm Template](#3-render-the-rancher-helm-template)
|
||||
- [4. Install Rancher](#4-install-rancher)
|
||||
- [5. For Rancher versions before v2.3.0, Configure System Charts](#5-for-rancher-versions-before-v2-3-0-configure-system-charts)
|
||||
|
||||
## 1. Add the Helm Chart Repository
|
||||
|
||||
From a system that has access to the internet, fetch the latest Helm chart and copy the resulting manifests to a system that has access to the Rancher server cluster.
|
||||
@@ -76,7 +68,7 @@ When setting up the Rancher Helm template, there are several options in the Helm
|
||||
| `systemDefaultRegistry` | `<REGISTRY.YOURDOMAIN.COM:PORT>` | Configure Rancher server to always pull from your private registry when provisioning clusters. |
|
||||
| `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. _Available as of v2.3.0_ |
|
||||
|
||||
Based on the choice your made in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), complete one of the procedures below.
|
||||
Based on the choice your made in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), complete one of the procedures below.
|
||||
|
||||
### Option A: Default Self-Signed Certificate
|
||||
|
||||
@@ -188,7 +180,7 @@ Copy the rendered manifest directories to a system that has access to the Ranche
|
||||
|
||||
Use `kubectl` to create namespaces and apply the rendered manifests.
|
||||
|
||||
If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
|
||||
If you choose to use self-signed certificates in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), install cert-manager.
|
||||
|
||||
### For Self-Signed Certificate Installs, Install Cert-manager
|
||||
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ The following instructions will guide you through upgrading a Rancher server tha
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Review the [known upgrade issues](../../../../pages-for-subheaders/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) Note that upgrades to or from any chart in the [rancher-alpha repository](../../../../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories/) aren’t supported.
|
||||
- **Review the [known upgrade issues](../../../../pages-for-subheaders/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) Note that upgrades to or from any chart in the [rancher-alpha repository](../../resources/choose-a-rancher-version.md#helm-chart-repositories) aren’t supported.
|
||||
- **For [air gap installs only,](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version.** Follow the guide to [populate your private registry](../air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
|
||||
|
||||
## Placeholder Review
|
||||
|
||||
+6
-6
@@ -9,8 +9,8 @@ title: Upgrading Cert-Manager with Helm 2
|
||||
Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
|
||||
|
||||
1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
1. [Cert-manager is deprecating and replacing the certificate.spec.acme.solvers field](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.7-0.8.html#upgrading-from-v0-7-to-v0-8). This change has no exact deadline.
|
||||
1. [Cert-manager is deprecating `v1alpha1` API and replacing its API group](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)
|
||||
1. [Cert-manager is deprecating and replacing the certificate.spec.acme.solvers field](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8). This change has no exact deadline.
|
||||
1. [Cert-manager is deprecating `v1alpha1` API and replacing its API group](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11)
|
||||
|
||||
To address these changes, this guide will do two things:
|
||||
|
||||
@@ -156,12 +156,12 @@ cert-manager-webhook-5b5dd6999-kst4x 1/1 Running 0 3
|
||||
cert-manager-cainjector-3ba5cd2bcd-de332x 1/1 Running 0 3m
|
||||
```
|
||||
|
||||
If the ‘webhook’ pod (2nd line) is in a ContainerCreating state, it may still be waiting for the Secret to be mounted into the pod. Wait a couple of minutes for this to happen but if you experience problems, please check cert-manager's [troubleshooting](https://docs.cert-manager.io/en/latest/getting-started/troubleshooting.html) guide.
|
||||
If the ‘webhook’ pod (2nd line) is in a ContainerCreating state, it may still be waiting for the Secret to be mounted into the pod. Wait a couple of minutes for this to happen but if you experience problems, please check cert-manager's [troubleshooting](https://cert-manager.io/docs/troubleshooting/) guide.
|
||||
|
||||
> **Note:** The above instructions ask you to add the disable-validation label to the kube-system namespace. Here are additional resources that explain why this is necessary:
|
||||
>
|
||||
> - [Information on the disable-validation label](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.4-0.5.html?highlight=certmanager.k8s.io%2Fdisable-validation#disabling-resource-validation-on-the-cert-manager-namespace)
|
||||
> - [Information on webhook validation for certificates](https://docs.cert-manager.io/en/latest/getting-started/webhook.html)
|
||||
> - [Information on the disable-validation label](https://cert-manager.io/docs/installation/upgrading/upgrading-0.4-0.5#disabling-resource-validation-on-the-cert-manager-namespace)
|
||||
> - [Information on webhook validation for certificates](https://cert-manager.io/docs/concepts/webhook/)
|
||||
|
||||
## Cert-Manager API change and data migration
|
||||
|
||||
@@ -177,4 +177,4 @@ We have also removed support for the old configuration format that was deprecate
|
||||
|
||||
Details about the change and migration instructions can be found in the [cert-manager v0.10 to v0.11 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/).
|
||||
|
||||
For information on upgrading from all other versions of cert-manager, refer to the [official documentation](https://cert-manager.io/docs/installation/upgrading/).
|
||||
For information on upgrading from all other versions of cert-manager, refer to the [official documentation](https://cert-manager.io/docs/installation/upgrade/).
|
||||
|
||||
+1
-1
@@ -241,5 +241,5 @@ We have also removed support for the old configuration format that was deprecate
|
||||
|
||||
Details about the change and migration instructions can be found in the [cert-manager v0.10 to v0.11 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/).
|
||||
|
||||
More info about [cert-manager upgrade information](https://cert-manager.io/docs/installation/upgrading/).
|
||||
More info about [cert-manager upgrade information](https://cert-manager.io/docs/installation/upgrade/).
|
||||
|
||||
|
||||
@@ -36,12 +36,12 @@ This feature enables kubectl to authenticate with the Rancher server and get a n
|
||||
4. SAML providers - Ping, Okta, ADFS, Keycloak, Shibboleth
|
||||
|
||||
When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server.
|
||||
The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid till [it expires](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens)
|
||||
The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid till [it expires](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), or [gets deleted from the Rancher server](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens)
|
||||
Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
|
||||
|
||||
_Note_
|
||||
|
||||
As of CLI [v2.4.10](https://github.com/ranchquick-start-guide/cli/releases/tag/v2.4.10), the kubeconfig token can be cached at a chosen path with `cache-dir` flag or env var `RANCHER_CACHE_DIR`.
|
||||
As of CLI [v2.4.10](https://github.com/rancher/cli/releases/tag/v2.4.10), the kubeconfig token can be cached at a chosen path with `cache-dir` flag or env var `RANCHER_CACHE_DIR`.
|
||||
|
||||
_**Current Known Issues**_
|
||||
|
||||
|
||||
+1
-1
@@ -35,7 +35,7 @@ The following steps will quickly deploy a Rancher Server on AWS with a single no
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
|
||||
1. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/aws) for more information.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws#readme) for more information.
|
||||
Suggestions include:
|
||||
- `aws_region` - Amazon AWS region, choose the closest instead of the default
|
||||
- `prefix` - Prefix for all created resources
|
||||
|
||||
+1
-1
@@ -39,7 +39,7 @@ The following steps will quickly deploy a Rancher server on Azure in a single-no
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
|
||||
2. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/azure) for more information.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure#readme) for more information.
|
||||
Suggestions include:
|
||||
- `azure_location` - Microsoft Azure region, choose the closest instead of the default
|
||||
- `prefix` - Prefix for all created resources
|
||||
|
||||
+1
-1
@@ -34,7 +34,7 @@ The following steps will quickly deploy a Rancher Server on DigitalOcean with a
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
|
||||
1. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/do) for more information.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do#readme) for more information.
|
||||
Suggestions include:
|
||||
- `do_region` - DigitalOcean region, choose the closest instead of the default
|
||||
- `prefix` - Prefix for all created resources
|
||||
|
||||
+1
-1
@@ -35,7 +35,7 @@ The following steps will quickly deploy a Rancher server on GCP in a single-node
|
||||
- `rancher_server_admin_password` - Admin password for created Rancher server
|
||||
|
||||
1. **Optional:** Modify optional variables within `terraform.tfvars`.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/gcp) for more information.
|
||||
See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp#readme) for more information.
|
||||
Suggestions include:
|
||||
- `gcp_region` - Google GCP region, choose the closest instead of the default
|
||||
- `prefix` - Prefix for all created resources
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
title: Pod Security Policies
|
||||
---
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies"/>
|
||||
</head>
|
||||
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
title: Global Permissions
|
||||
---
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
@@ -34,7 +34,7 @@ When a user logs into Rancher using an external authentication provider for the
|
||||
|
||||
To see the default permissions for new users, go to the **Global** view and click **Security > Roles.** On the **Global** tab, there is a column named **New User Default.** When adding a new local user, the user receives all default global permissions that are marked as checked in this column, and you can [change them to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-existing-individual-users)
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-individual-users)
|
||||
|
||||
As of Rancher v2.4.0, you can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
|
||||
|
||||
|
||||
+1
-1
@@ -16,7 +16,7 @@ To schedule scans for an existing cluster:
|
||||
1. Click **Tools > CIS Scans.**
|
||||
1. Click **Add Schedule.** This takes you to the section of the cluster editing page that is applicable to configuring a schedule for CIS scans. (This section can also be reached by going to the cluster view, clicking **⋮ > Edit,** and going to the **Advanced Options.**)
|
||||
1. In the **CIS Scan Enabled** field, click **Yes.**
|
||||
[defined in a separate ConfigMap](#skip-tests)
|
||||
[defined in a separate ConfigMap](./skip-tests.md)
|
||||
1. In the **CIS Scan Interval (cron)** job, enter a [cron expression](https://en.wikipedia.org/wiki/Cron#CRON_expression) to define how often the cluster will be scanned.
|
||||
1. In the **CIS Scan Report Retention** field, enter the number of past reports that should be kept.
|
||||
|
||||
|
||||
+1
-1
@@ -34,7 +34,7 @@ This second method, the capability to connect directly to the cluster's Kubernet
|
||||
|
||||
To use the authorized cluster endpoint, you will need to configure kubectl to use the extra kubectl context in the kubeconfig file that Rancher generates for you when the RKE cluster is created. This file can be downloaded from the cluster view in the Rancher UI, and the instructions for configuring kubectl are on [this page.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)
|
||||
|
||||
These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../pages-for-subheaders/rancher-manager-architecture.md#communicating-with-downstream-user-clusters) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
|
||||
These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
|
||||
|
||||
### About the kube-api-auth Authentication Webhook
|
||||
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ You can assign a pod security policy when you provision a cluster. However, if y
|
||||
|
||||
4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
|
||||
|
||||
Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-pod-security-policies) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-pod-security-policies) as well.
|
||||
Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-psps) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#creating-psps) as well.
|
||||
|
||||
5. Click **Save**.
|
||||
|
||||
|
||||
+1
-1
@@ -48,7 +48,7 @@ Begin by using Rancher CLI to export the configuration for the cluster that you
|
||||
|
||||
Use your favorite text editor to modify the cluster configuration in `cluster-template.yml` for your cloned cluster.
|
||||
|
||||
> **Note:** As of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v2-3-0)
|
||||
> **Note:** As of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v230)
|
||||
|
||||
1. Open `cluster-template.yml` (or whatever you named your config) in your favorite text editor.
|
||||
|
||||
|
||||
+1
-1
@@ -114,7 +114,7 @@ Standard users are only authorized for project access in two situations:
|
||||
|
||||
## Pod Security Policies
|
||||
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policluster-admin/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/security/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
|
||||
## Creating Projects
|
||||
|
||||
|
||||
+1
-1
@@ -85,6 +85,6 @@ If you are upgrading from Rancher v2.0.13 or earlier, or v2.1.8 or earlier, and
|
||||
cp -r /etc/kubernetes/ssl /etc/kubernetes/.tmp
|
||||
```
|
||||
|
||||
1. Rotate the certificates. For Rancher v2.0.x and v2.1.x, use the [Rancher API.](#certificate-rotation-in-rancher-v2-1-x-and-v2-0-x) For Rancher 2.2.x, [use the UI.](#certificate-rotation-in-rancher-v2-2-x)
|
||||
1. Rotate the certificates. For Rancher v2.0.x and v2.1.x, use the [Rancher API.](#certificate-rotation-in-rancher-v21x-and-v20x) For Rancher 2.2.x, [use the UI.](#certificate-rotation-in-rancher-v22x)
|
||||
|
||||
1. After the command is finished, check if the `worker` nodes are Active. If not, log in to each `worker` node and restart the kubelet and proxy.
|
||||
+1
-1
@@ -22,4 +22,4 @@ For details on taking database snapshots and restoring your database from them,
|
||||
|
||||
- [Official MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html)
|
||||
- [Official PostgreSQL documentation](https://www.postgresql.org/docs/8.3/backup-dump.html)
|
||||
- [Official etcd documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md)
|
||||
- [Official etcd documentation](https://etcd.io/docs/v3.4/op-guide/recovery/)
|
||||
+1
-1
@@ -18,4 +18,4 @@ For details on taking database snapshots and restoring your database from them,
|
||||
|
||||
- [Official MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html)
|
||||
- [Official PostgreSQL documentation](https://www.postgresql.org/docs/8.3/backup-dump.html)
|
||||
- [Official etcd documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md)
|
||||
- [Official etcd documentation](https://etcd.io/docs/v3.4/op-guide/recovery/)
|
||||
-15
@@ -14,21 +14,6 @@ Any Helm charts from a global catalog can be used to deploy and manage multi-clu
|
||||
|
||||
After creating a multi-cluster application, you can program a [Global DNS entry](helm-charts-in-rancher/globaldns.md) to make it easier to access the application.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Launching a multi-cluster app](#launching-a-multi-cluster-app)
|
||||
- [Multi-cluster app configuration options](#multi-cluster-app-configuration-options)
|
||||
- [Targets](#targets)
|
||||
- [Upgrades](#upgrades)
|
||||
- [Roles](#roles)
|
||||
- [Application configuration options](#application-configuration-options)
|
||||
- [Using a questions.yml file](#using-a-questions-yml-file)
|
||||
- [Key value pairs for native Helm charts](#key-value-pairs-for-native-helm-charts)
|
||||
- [Members](#members)
|
||||
- [Overriding application configuration options for specific projects](#overriding-application-configuration-options-for-specific-projects)
|
||||
- [Upgrading multi-cluster app roles and projects](#upgrading-multi-cluster-app-roles-and-projects)
|
||||
- [Multi-cluster application management](#multi-cluster-application-management)
|
||||
- [Deleting a multi-cluster application](#deleting-a-multi-cluster-application)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To create a multi-cluster app in Rancher, you must have at least one of the following permissions:
|
||||
|
||||
-9
@@ -4,15 +4,6 @@ title: Creating Custom Catalogs
|
||||
|
||||
Custom catalogs can be added into Rancher at a global scope, cluster scope, or project scope.
|
||||
|
||||
- [Adding catalog repositories](#adding-catalog-repositories)
|
||||
- [Add custom Git repositories](#add-custom-git-repositories)
|
||||
- [Add custom Helm chart repositories](#add-custom-helm-chart-repositories)
|
||||
- [Add private Git/Helm chart repositories](#add-private-git-helm-chart-repositories)
|
||||
- [Adding global catalogs](#adding-global-catalogs)
|
||||
- [Adding cluster level catalogs](#adding-cluster-level-catalogs)
|
||||
- [Adding project level catalogs](#adding-project-level-catalogs)
|
||||
- [Custom catalog configuration reference](#custom-catalog-configuration-reference)
|
||||
|
||||
## Adding Catalog Repositories
|
||||
|
||||
Adding a catalog is as simple as adding a catalog name, a URL and a branch name.
|
||||
|
||||
+1
-1
@@ -11,7 +11,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://github.com/kubernetes/cloud-provider-aws/tree/master#readme) for all information regarding the Amazon cloud provider.
|
||||
|
||||
To set up the Amazon cloud provider,
|
||||
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Setting up the Google Compute Engine Cloud Provider
|
||||
|
||||
In this section, you'll learn how to enable the Google Compute Engine (GCE) cloud provider for custom clusters in Rancher. A custom cluster is one in which Rancher installs Kubernetes on existing nodes.
|
||||
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#gce)
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md#gce)
|
||||
|
||||
> **Prerequisites:** The service account of `Identity and API` access on GCE needs the `Computer Admin` permission.
|
||||
|
||||
|
||||
+1
-1
@@ -109,7 +109,7 @@ You can access your cluster after its state is updated to **Active.**
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in vSphere.
|
||||
|
||||
For Rancher versions before v2.0.4, when you create the cluster, you will also need to follow the steps in [this section](http://localhost:9001/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vpshere-node-template-config/prior-to-2.0.4/#disk-uuids) to enable disk UUIDs.
|
||||
For Rancher versions before v2.0.4, when you create the cluster, you will also need to follow the steps in [this section](../../../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/prior-to-v2.0.4.md#disk-uuids) to enable disk UUIDs.
|
||||
|
||||
1. From the **Clusters** page, click **Add Cluster**.
|
||||
1. Choose **vSphere**.
|
||||
|
||||
+1
-1
@@ -61,7 +61,7 @@ You can access your cluster after its state is updated to **Active.**
|
||||
| Cluster Label | The labels for the cluster. |
|
||||
| Highway Subnet | This option is only supported in `BareMetal` type. It requires you to select a VPC with high network speed for the bare metal machines. |
|
||||
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that as of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v2-3-0)
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that as of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v230)
|
||||
|
||||
## Node Configuration
|
||||
|
||||
|
||||
+1
-1
@@ -50,7 +50,7 @@ You can use Rancher to create a cluster hosted in Tencent Kubernetes Engine (TKE
|
||||
| VPC | Select the VPC name that you have created in the Tencent Cloud Console. |
|
||||
| Container Network CIDR | Enter the CIDR range of your Kubernetes cluster, you may check the available range of the CIDR in the VPC service of the Tencent Cloud Console. Default to 172.16.0.0/16. |
|
||||
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that as of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v2-3-0)
|
||||
**Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that as of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v230)
|
||||
|
||||
7. Click `Next: Select Instance Type` to choose the instance type that will use for your TKE cluster.
|
||||
|
||||
|
||||
+1
-1
@@ -21,7 +21,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an
|
||||
|
||||
## Ingress Rule Configuration
|
||||
|
||||
- [Automatically generate a sslip.io hostname](#automatically-generate-a-sslip-io-hostname)
|
||||
- [Automatically generate a sslip.io hostname](#automatically-generate-a-sslipio-hostname)
|
||||
- [Specify a hostname to use](#specify-a-hostname-to-use)
|
||||
- [Use as the default backend](#use-as-the-default-backend)
|
||||
- [Certificates](#certificates)
|
||||
|
||||
+1
-1
@@ -45,7 +45,7 @@ Deploy a workload to run an application in one or more containers.
|
||||
>
|
||||
>- 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](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).
|
||||
>- The cluster must be using the [AWS cloud provider](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).
|
||||
|
||||
|
||||
1. Click **Show Advanced Options** and configure:
|
||||
|
||||
+2
-2
@@ -21,12 +21,12 @@ The following table displays each service discovery feature available in the two
|
||||
|
||||
Service Discovery Feature | Rancher v1.6 | Rancher v2.x | Description
|
||||
--------------------------|--------------|--------------|-------------
|
||||
[service discovery within and across stack][1] (i.e., clusters) | ✓ | ✓ | All services in the stack are resolvable by `<service_name>` and by `<service_name>.<stack_name>` across stacks.
|
||||
[service discovery within and across namespaces][1] (i.e., clusters) | ✓ | ✓ | All services in the stack are resolvable by `<service_name>` and by `<service_name>.<stack_name>` across stacks.
|
||||
[container discovery][2] | ✓ | ✓ | All containers are resolvable globally by their name.
|
||||
[service alias name creation][3] | ✓ | ✓ | Adding an alias name to services and linking to other services using aliases.
|
||||
[discovery of external services][4] | ✓ | ✓ | Pointing to services deployed outside of Rancher using the external IP(s) or a domain name.
|
||||
|
||||
[1]: #service-discovery-within-and-across-stacks
|
||||
[1]: #service-discovery-within-and-across-namespaces
|
||||
[2]: #container-discovery
|
||||
[3]: #service-name-alias-creation
|
||||
[4]: #service-name-alias-creation
|
||||
|
||||
+3
-3
@@ -254,7 +254,7 @@ Following importation, you can view your v1.6 services in the v2.x UI as Kuberne
|
||||
|
||||
## What Now?
|
||||
|
||||
Although the migration-tool CLI parses your Rancher v1.6 Compose files to Kubernetes manifests, there are discrepancies between v1.6 and v2.x that you must address by manually editing your parsed [Kubernetes manifests](#output). In other words, you need to edit each workload and service imported into Rancher v2.x, as displayed below.
|
||||
Although the migration-tool CLI parses your Rancher v1.6 Compose files to Kubernetes manifests, there are discrepancies between v1.6 and v2.x that you must address by manually editing your parsed [Kubernetes manifests](#migration-tools-cli-output). In other words, you need to edit each workload and service imported into Rancher v2.x, as displayed below.
|
||||
|
||||
<figcaption>Edit Migrated Services</figcaption>
|
||||
|
||||
@@ -279,7 +279,7 @@ Directive | Instructions
|
||||
[scale][5] | In v1.6, scale refers to the number of container replicas running on a single node. In v2.x, this feature is replaced by replica sets.
|
||||
start_on_create | No Kubernetes equivalent. No action is required from you.
|
||||
|
||||
[1]:./monitor-apps.md#configuring-probes-in-rancher-v2-x
|
||||
[1]:./monitor-apps.md#configuring-probes-in-rancher-v2x
|
||||
[2]:./schedule-services.md#scheduling-using-labels
|
||||
[3]:./discover-services.md
|
||||
[4]:./expose-services.md
|
||||
@@ -289,6 +289,6 @@ start_on_create | No Kubernetes equivalent. No action is required from you.
|
||||
|
||||
[7]:./schedule-services.md#scheduling-using-labels
|
||||
[8]:./schedule-services.md#scheduling-global-services
|
||||
[9]:./schedule-services.md#label-affinity-antiaffinity
|
||||
[9]:./schedule-services.md#label-affinityantiaffinity
|
||||
|
||||
### [Next: Expose Your Services](expose-services.md)
|
||||
|
||||
+1
-1
@@ -122,7 +122,7 @@ When you configure a readiness check using Rancher v2.x, the `readinessProbe` di
|
||||
|
||||
HTTP checks monitor your deployment's health by sending an HTTP GET request to a specific URL path that you define. If the pod responds with a message range of `200`-`400`, the health check is considered successful. If the pod replies with any other value, the check is considered unsuccessful, so Kubernetes kills and replaces the pod according to its [restart policy](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). (this applies to Liveness probes, for Readiness probes, it will mark the pod as Unready).
|
||||
|
||||
You can configure the probe along with values for specifying its behavior by selecting the **HTTP returns successful status** or **HTTPS returns successful status**. For more information, see [Deploying Workloads](../kubernetes-resources-setup/workloads-and-pods/deploy-workloads.md). For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#healthcheck-parameter-mappings).
|
||||
You can configure the probe along with values for specifying its behavior by selecting the **HTTP returns successful status** or **HTTPS returns successful status**. For more information, see [Deploying Workloads](../kubernetes-resources-setup/workloads-and-pods/deploy-workloads.md). For help setting probe timeout and threshold values, see [Health Check Parameter Mappings](#health-check-parameter-mappings).
|
||||
|
||||

|
||||
|
||||
|
||||
+1
-1
@@ -40,7 +40,7 @@ Option | v1.6 Feature | v2.x Feature
|
||||
[Schedule a certain number of pods?](#schedule-a-certain-number-of-pods) | ✓ | ✓
|
||||
[Schedule pods to specific node?](#scheduling-pods-to-a-specific-node) | ✓ | ✓
|
||||
[Schedule to nodes using labels?](#applying-labels-to-nodes-and-pods) | ✓ | ✓
|
||||
[Schedule to nodes using label affinity/anti-affinity rules?](#label-affinity-antiaffinity) | ✓ | ✓
|
||||
[Schedule to nodes using label affinity/anti-affinity rules?](#label-affinityantiaffinity) | ✓ | ✓
|
||||
[Schedule based on resource constraints?](#scheduling-pods-using-resource-constraints) | ✓ | ✓
|
||||
[Preventing scheduling specific services to specific hosts?](#preventing-scheduling-specific-services-to-specific-nodes) | ✓ | ✓
|
||||
[Schedule services globally?](#scheduling-global-services) | ✓ | ✓
|
||||
|
||||
@@ -21,7 +21,7 @@ Rancher provides an intuitive user interface for interacting with your clusters.
|
||||
|
||||
### kubectl
|
||||
|
||||
You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/referenccluster-admin/cluster-access/kubectloverview/), to manage your clusters. You have two options for using kubectl:
|
||||
You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to manage your clusters. You have two options for using kubectl:
|
||||
|
||||
- **Rancher kubectl shell:** Interact with your clusters by launching a kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. For more information, see [Accessing Clusters with kubectl Shell](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md).
|
||||
- **Terminal remote connection:** You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local desktop and then copying the cluster's kubeconfig file to your local `~/.kube/config` directory. For more information, see [Accessing Clusters with kubectl and a kubeconfig File](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md).
|
||||
|
||||
@@ -15,9 +15,7 @@ Use the navigation bar on the left to find the current best practices for managi
|
||||
For more guidance on best practices, you can consult these resources:
|
||||
|
||||
- [Security](rancher-security.md)
|
||||
- [Rancher Blog](https://rancher.com/blog/)
|
||||
- [Articles about best practices on the Rancher blog](https://rancher.com/tags/best-practices/)
|
||||
- [101 More Security Best Practices for Kubernetes](https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/)
|
||||
- [Rancher Blog](https://www.suse.com/c/rancherblog/)
|
||||
- [Rancher Forum](https://forums.rancher.com/)
|
||||
- [Rancher Users Slack](https://slack.rancher.io/)
|
||||
- [Rancher Labs YouTube Channel - Online Meetups, Demos, Training, and Webinars](https://www.youtube.com/channel/UCh5Xtp82q8wjijP8npkVTBA/featured)
|
||||
|
||||
@@ -289,7 +289,7 @@ Input or select an **Expression**, the dropdown shows the original metrics from
|
||||
- [**Kubernetes Components**](https://github.com/kubernetes/metrics)
|
||||
- [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
|
||||
- [**Fluentd**](https://docs.fluentd.org/v1.0/articles/monitoring-prometheus) (supported by [Logging](./cluster-logging.md))
|
||||
- [**Cluster Level Grafana**](http://docs.grafana.org/administration/metrics/)
|
||||
- [**Cluster Level Grafana**](https://grafana.com/docs/grafana/latest/setup-grafana/set-up-grafana-monitoring/)
|
||||
- **Cluster Level Prometheus**
|
||||
|
||||
### Is
|
||||
|
||||
@@ -142,8 +142,8 @@ RKE uses a `.yml` config file to install and configure your Kubernetes cluster.
|
||||
|
||||
1. Download one of following templates, depending on the SSL certificate you're using.
|
||||
|
||||
- [Template for self-signed certificate<br/> `3-node-certificate.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-certificate.yml)
|
||||
- [Template for certificate signed by recognized CA<br/> `3-node-certificate-recognizedca.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-certificate-recognizedca.yml)
|
||||
- [Template for self-signed certificate<br/> `3-node-certificate.yml`](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/cluster-yml-templates/node-certificate.md)
|
||||
- [Template for certificate signed by recognized CA<br/> `3-node-certificate-recognizedca.yml`](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/cluster-yml-templates/node-certificate-recognizedca.md)
|
||||
|
||||
>**Advanced Config Options:**
|
||||
>
|
||||
|
||||
@@ -90,8 +90,8 @@ RKE uses a YAML config file to install and configure your Kubernetes cluster. Th
|
||||
|
||||
1. Download one of following templates, depending on the SSL certificate you're using.
|
||||
|
||||
- [Template for self-signed certificate<br/> `3-node-externalssl-certificate.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-externalssl-certificate.yml)
|
||||
- [Template for certificate signed by recognized CA<br/> `3-node-externalssl-recognizedca.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-externalssl-recognizedca.yml)
|
||||
- [Template for self-signed certificate<br/> `3-node-externalssl-certificate.yml`](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/cluster-yml-templates/node-externalssl-certificate.md)
|
||||
- [Template for certificate signed by recognized CA<br/> `3-node-externalssl-recognizedca.yml`](../getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/cluster-yml-templates/node-externalssl-recognizedca.md)
|
||||
|
||||
>**Advanced Config Options:**
|
||||
>
|
||||
@@ -152,7 +152,7 @@ Choose from the following options:
|
||||
>Create a self-signed certificate.
|
||||
>
|
||||
>- The certificate files must be in PEM format.
|
||||
>- The certificate files must be encoded in [base64](#base64).
|
||||
>- The certificate files must be encoded in base64.
|
||||
>- 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.](../getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/certificate-troubleshooting.md)
|
||||
|
||||
In `kind: Secret` with `name: cattle-keys-ingress`, replace `<BASE64_CA>` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`)
|
||||
|
||||
@@ -16,7 +16,7 @@ Make sure the node(s) for the Rancher server fulfill the following requirements:
|
||||
- [Operating Systems and Container Runtime Requirements](#operating-systems-and-container-runtime-requirements)
|
||||
- [Hardware Requirements](#hardware-requirements)
|
||||
- [CPU and Memory](#cpu-and-memory)
|
||||
- [CPU and Memory for Rancher before v2.4.0](#cpu-and-memory-for-rancher-before-v2-4-0)
|
||||
- [CPU and Memory for Rancher before v2.4.0](#cpu-and-memory-for-rancher-before-v240)
|
||||
- [Disks](#disks)
|
||||
- [Networking Requirements](#networking-requirements)
|
||||
- [Node IP Addresses](#node-ip-addresses)
|
||||
@@ -71,7 +71,7 @@ Hardware requirements scale based on the size of your Rancher deployment. Provis
|
||||
|
||||
These requirements apply to each host in an [RKE Kubernetes cluster where the Rancher server is installed.](install-upgrade-on-a-kubernetes-cluster.md)
|
||||
|
||||
Performance increased in Rancher v2.4.0. For the requirements of Rancher before v2.4.0, refer to [this section.](#cpu-and-memory-for-rancher-before-v2-4-0)
|
||||
Performance increased in Rancher v2.4.0. For the requirements of Rancher before v2.4.0, refer to [this section.](#cpu-and-memory-for-rancher-before-v240)
|
||||
|
||||
| Deployment Size | Clusters | Nodes | vCPUs | RAM |
|
||||
| --------------- | ---------- | ------------ | -------| ------- |
|
||||
|
||||
@@ -20,5 +20,5 @@ If you use Istio for traffic management, you will need to allow external traffic
|
||||
1. [Add deployments and services that have the Istio sidecar injected.](../how-to-guides/advanced-user-guides/istio-setup-guide/use-istio-sidecar.md)
|
||||
1. [Set up the Istio gateway. ](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-istio-gateway.md)
|
||||
1. [Set up Istio's components for traffic management.](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-traffic-management.md)
|
||||
1. [Generate traffic and see Istio in action.](istio-setup-guide.md#view-traffic)
|
||||
1. [Generate traffic and see Istio in action.](../how-to-guides/advanced-user-guides/istio-setup-guide/generate-and-view-traffic.md)
|
||||
|
||||
|
||||
@@ -113,7 +113,7 @@ _Available as of v2.1.0_
|
||||
1. Click **Authenticate**.
|
||||
|
||||
>**Note:**
|
||||
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
|
||||
> 1. Pipeline uses Gitlab [v4 API](https://github.com/gitlabhq/gitlabhq/blob/9-0-stable/doc/api/v3_to_v4.md) and the supported Gitlab version is 9.0+.
|
||||
> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
|
||||
|
||||
</TabItem>
|
||||
|
||||
@@ -49,7 +49,7 @@ The Benchmark provides recommendations of two types: Scored and Not Scored. We r
|
||||
|
||||
When Rancher runs a CIS security scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests.
|
||||
|
||||
For details, refer to the section on [security scans.](cis-scans)
|
||||
For details, refer to the section on [security scans.](cis-scan-guides.md)
|
||||
|
||||
### Rancher Hardening Guide
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ title: Setting up Cloud Providers
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/pages-for-subheaders/set-up-cloud-providers"/>
|
||||
</head>
|
||||
|
||||
A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes. For more information, refer to the [official Kubernetes documentation on cloud providers.](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
|
||||
A _cloud provider_ is a module in Kubernetes that provides an interface for managing nodes, load balancers, and networking routes. For more information, refer to the [official Kubernetes documentation on cloud providers.](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md)
|
||||
|
||||
When a cloud provider is set up in Rancher, the Rancher server can automatically provision new nodes, load balancers or persistent storage devices when launching Kubernetes definitions, if the cloud provider you're using supports such automation.
|
||||
|
||||
@@ -39,7 +39,7 @@ For details on enabling the vSphere cloud provider, refer to [this page.](../how
|
||||
|
||||
### Setting up a Custom Cloud Provider
|
||||
|
||||
The `Custom` cloud provider is available if you want to configure any [Kubernetes cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/).
|
||||
The `Custom` cloud provider is available if you want to configure any [Kubernetes cloud provider](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md).
|
||||
|
||||
For the custom cloud provider option, you can refer to the [RKE docs](https://rancher.com/docs/rke/latest/en/config-options/cloud-providers/) on how to edit the yaml file for your specific cloud provider. There are specific cloud providers that have more detailed configuration :
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ Review the [known upgrade issues](#known-upgrade-issues) in the Rancher document
|
||||
|
||||
A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
|
||||
|
||||
Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories/) aren't supported.
|
||||
Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
|
||||
|
||||
### Helm Version
|
||||
|
||||
@@ -49,7 +49,7 @@ For migration of installs started with Helm 2, refer to the official [Helm 2 to
|
||||
|
||||
### For upgrades from v2.0-v2.2 with external TLS termination
|
||||
|
||||
If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.](../reference-guides/installation-references/helm-chart-options.md#configuring-ingress-for-external-tls-when-using-nginx-v0-25)
|
||||
If you are upgrading Rancher from v2.x to v2.3+, and you are using external TLS termination, you will need to edit the cluster.yml to [enable using forwarded host headers.](../reference-guides/installation-references/helm-chart-options.md#configuring-ingress-for-external-tls-when-using-nginx-v025)
|
||||
|
||||
### For upgrades with cert-manager older than 0.8.0
|
||||
|
||||
@@ -82,7 +82,7 @@ You'll use the backup as a restoration point if something goes wrong during upgr
|
||||
|
||||
1. Get the repository name that you used to install Rancher.
|
||||
|
||||
For information about the repos and their differences, see [Helm Chart Repositories](../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories).
|
||||
For information about the repos and their differences, see [Helm Chart Repositories](../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md#helm-chart-repositories).
|
||||
|
||||
- Latest: Recommended for trying out the newest features
|
||||
```
|
||||
|
||||
@@ -57,7 +57,7 @@ Provision the host according to the [installation requirements](../how-to-guides
|
||||
>- Using Windows nodes as Kubernetes workers? See [this section](use-windows-clusters.md).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options](admin-settings/agent-options/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options](../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
|
||||
9. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
@@ -85,7 +85,7 @@ If you have configured your cluster to use Amazon as **Cloud Provider**, tag you
|
||||
|
||||
[Amazon Documentation: Tagging Your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
|
||||
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md)
|
||||
|
||||
|
||||
The following resources need to tagged with a `ClusterID`:
|
||||
|
||||
@@ -15,7 +15,7 @@ When the Rancher server is installed on a Kubernetes cluster, it should not be r
|
||||
It is strongly recommended to use hosted infrastructure such as Amazon's EC2 or Google's GCE instead. When you create a cluster using RKE on an infrastructure provider, you can configure the cluster to create etcd snapshots as a backup. You can then [use RKE](https://rancher.com/docs/rke/latest/en/etcd-snapshots/) or [Rancher](../../pages-for-subheaders/backup-restore-and-disaster-recovery.md) to restore your cluster from one of these snapshots. In a hosted Kubernetes environment, this backup and restore functionality is not supported.
|
||||
|
||||
### Make sure nodes are configured correctly for Kubernetes
|
||||
It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/performance.md)
|
||||
It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.4/op-guide/performance/)
|
||||
|
||||
### When using RKE: Backup the Statefile
|
||||
RKE keeps record of the cluster state in a file called `cluster.rkestate`. This file is important for the recovery of a cluster and/or the continued maintenance of the cluster through RKE. Because this file contains certificate material, we strongly recommend encrypting this file before backing up. After each run of `rke up` you should backup the state file.
|
||||
|
||||
@@ -33,4 +33,4 @@ This feature enables kubectl to authenticate with the Rancher server and get a n
|
||||
4. OpenLDAP
|
||||
5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth
|
||||
|
||||
When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
|
||||
When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), or [gets deleted from the Rancher server](../about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
|
||||
+1
-1
@@ -45,7 +45,7 @@ Please refer to [Amazon EC2 security group when using Node Driver](../../../../g
|
||||
|
||||
Configure the instances that will be created. Make sure you configure the correct **SSH User** for the configured AMI.
|
||||
|
||||
If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider](../../../../pages-for-subheaders/set-up-cloud-providers.md), you will need an additional permission in your policy. See [Example IAM policy with PassRole](#example-iam-policy-with-passrole) for an example policy.
|
||||
If you need to pass an **IAM Instance Profile Name** (not ARN), for example, when you want to use a [Kubernetes Cloud Provider](../../../../pages-for-subheaders/set-up-cloud-providers.md), you will need an additional permission in your policy. See [Example IAM policy with PassRole](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md#example-iam-policy-with-passrole) for an example policy.
|
||||
|
||||
### Engine Options
|
||||
|
||||
|
||||
+1
-7
@@ -2,7 +2,7 @@
|
||||
title: OpenLDAP Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/configure-openldap/openldap-config-reference"/>
|
||||
</head>
|
||||
|
||||
@@ -10,12 +10,6 @@ For further details on configuring OpenLDAP authentication, refer to the [offici
|
||||
|
||||
> Before you proceed with the configuration, please familiarize yourself with the concepts of [External Authentication Configuration and Principal Users](../../pages-for-subheaders/about-authentication.md#external-authentication-configuration-and-principal-users).
|
||||
|
||||
- [Background: OpenLDAP Authentication Flow](#background-openldap-authentication-flow)
|
||||
- [OpenLDAP server configuration](#openldap-server-configuration)
|
||||
- [User/group schema configuration](#user-group-schema-configuration)
|
||||
- [User schema configuration](#user-schema-configuration)
|
||||
- [Group schema configuration](#group-schema-configuration)
|
||||
|
||||
## Background: OpenLDAP Authentication Flow
|
||||
|
||||
1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes.
|
||||
|
||||
+1
-5
@@ -130,7 +130,7 @@ If you choose to assign a public IP address to your cluster's worker nodes, you
|
||||
|
||||
If you're using **Custom: Choose from your existing VPC and Subnets**:
|
||||
|
||||
(If you're using **Standard**, skip to the [instance options.)](#select-instance-options-2-4)
|
||||
(If you're using **Standard**, skip to the [instance options.)](#instance-options)
|
||||
|
||||
1. Make sure **Custom: Choose from your existing VPC and Subnets** is selected.
|
||||
|
||||
@@ -169,8 +169,6 @@ Amazon Documentation:
|
||||
|
||||
### Instance Options
|
||||
|
||||
<a id="select-instance-options-2-4"></a>
|
||||
|
||||
Instance type and size of your worker nodes affects how many IP addresses each worker node will have available. See this [documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI) for more information.
|
||||
|
||||
Option | Description
|
||||
@@ -182,8 +180,6 @@ User Data | Custom commands can to be passed to perform automated configuration
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If your changes were overwritten, it could be due to the way the cluster data is synced with EKS. Changes shouldn't be made to the cluster from another source, such as in the EKS console, and in Rancher within a five-minute span. For information on how this works and how to configure the refresh interval, refer to [Syncing.](#syncing)
|
||||
|
||||
If an unauthorized error is returned while attempting to modify or import the cluster and the cluster was not created with the role or user that your credentials belong to, refer to [Security and Compliance.](#security-and-compliance)
|
||||
|
||||
For any issues or troubleshooting details for your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html).
|
||||
|
||||
@@ -43,7 +43,7 @@ For details, refer to [Notifiers.](../explanations/integrations-in-rancher/notif
|
||||
|
||||
_Available as of v2.3_
|
||||
|
||||
[Istio](https:cluster-admin/tools/istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, control, troubleshoot, and secure the traffic within a complex network of microservices.
|
||||
[Istio](https://istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, control, troubleshoot, and secure the traffic within a complex network of microservices.
|
||||
|
||||
Refer to the Istio documentation [here.](../pages-for-subheaders/istio.md)
|
||||
|
||||
|
||||
+2
-2
@@ -75,7 +75,7 @@ Like the authorized cluster endpoint, the `kube-api-auth` authentication service
|
||||
|
||||
> **Example scenario:** Let's say that the Rancher server is located in the United States, and User Cluster 1 is located in Australia. A user, Alice, also lives in Australia. Alice can manipulate resources in User Cluster 1 by using the Rancher UI, but her requests will have to be sent from Australia to the Rancher server in the United States, then be proxied back to Australia, where the downstream user cluster is. The geographical distance may cause significant latency, which Alice can reduce by using the authorized cluster endpoint.
|
||||
|
||||
With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.
|
||||
With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.
|
||||
|
||||
You will need to use a context defined in this kubeconfig file to access the cluster if Rancher goes down. Therefore, we recommend exporting the kubeconfig file so that if Rancher goes down, you can still use the credentials in the file to access your cluster. For more information, refer to the section on accessing your cluster with [kubectl and the kubeconfig file.](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)
|
||||
|
||||
@@ -133,4 +133,4 @@ The GitHub repositories for Rancher can be found at the following links:
|
||||
- [Rancher CLI](https://github.com/rancher/cli)
|
||||
- [Catalog applications](https://github.com/rancher/helm)
|
||||
|
||||
This is a partial list of the most important Rancher repositories. For more details about Rancher source code, refer to the section on [contributing to Rancher.](../../contribute-to-rancher.md#repositories) To see all libraries and projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
|
||||
This is a partial list of the most important Rancher repositories. For more details about Rancher source code, refer to the section on [contributing to Rancher.](../../contribute-to-rancher.md#rancher-repositories) To see all libraries and projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
|
||||
+1
-1
@@ -195,7 +195,7 @@ Input or select an **Expression**. The dropdown shows the original metrics from
|
||||
- [**Container**](https://github.com/google/cadvisor)
|
||||
- [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
|
||||
- **Customize**
|
||||
- [**Project Level Grafana**](http://docs.grafana.org/administration/metrics/)
|
||||
- [**Project Level Grafana**](https://grafana.com/docs/grafana/latest/setup-grafana/set-up-grafana-monitoring/)
|
||||
- **Project Level Prometheus**
|
||||
|
||||
### Is
|
||||
|
||||
+1
-1
@@ -411,7 +411,7 @@ Verify that the permissions are `700` or more restrictive.
|
||||
|
||||
**Remediation**
|
||||
|
||||
Follow the steps as documented in [1.4.12](#1-4-12-ensure-that-the-etcd-data-directory-ownership-is-set-to-etcd-etcd) remediation.
|
||||
Follow the steps as documented in [1.4.12](#1412---ensure-that-the-etcd-data-directory-ownership-is-set-to-etcdetcd) remediation.
|
||||
|
||||
### 1.4.12 - Ensure that the etcd data directory ownership is set to `etcd:etcd`
|
||||
|
||||
|
||||
+1
-1
@@ -148,7 +148,7 @@ Verify that the permissions are `700` or more restrictive.
|
||||
|
||||
**Remediation**
|
||||
|
||||
Follow the steps as documented in [1.4.12](#1-4-12-ensure-that-the-etcd-data-directory-ownership-is-set-to-etcd-etcd) remediation.
|
||||
Follow the steps as documented in [1.4.12](#1412---ensure-that-the-etcd-data-directory-ownership-is-set-to-etcdetcd) remediation.
|
||||
|
||||
### 1.4.12 - Ensure that the etcd data directory ownership is set to `etcd:etcd`
|
||||
|
||||
|
||||
+1
-8
@@ -2,14 +2,7 @@
|
||||
title: Advanced Options for Docker Installs
|
||||
---
|
||||
|
||||
When installing Rancher, there are several [advanced options](../../pages-for-subheaders/resources.md) that can be enabled:
|
||||
|
||||
- [Custom CA Certificate](#custom-ca-certificate)
|
||||
- [API Audit Log](#api-audit-log)
|
||||
- [TLS Settings](#tls-settings)
|
||||
- [Air Gap](#air-gap)
|
||||
- [Persistent Data](#persistent-data)
|
||||
- [Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node](#running-rancher-rancher-and-rancher-rancher-agent-on-the-same-node)
|
||||
When installing Rancher, there are several [advanced options](../../pages-for-subheaders/resources.md) that can be enabled.
|
||||
|
||||
### Custom CA Certificate
|
||||
|
||||
|
||||
@@ -199,7 +199,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](../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#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:
|
||||
See [Editing Cluster as YAML](../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#cluster-config-file) 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
|
||||
|
||||
+57
-73
@@ -6,40 +6,38 @@ See the [Logging operator documentation](https://kube-logging.github.io/docs/con
|
||||
|
||||
See [Rancher Integration with Logging Services: Troubleshooting](../../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
|
||||
|
||||
- [Configuration](#configuration)
|
||||
- [YAML Example](#yaml-example)
|
||||
|
||||
## Configuration
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
- [Flows](#flows-2-5-8)
|
||||
- [Matches](#matches-2-5-8)
|
||||
- [Filters](#filters-2-5-8)
|
||||
- [Outputs](#outputs-2-5-8)
|
||||
- [ClusterFlows](#clusterflows-2-5-8)
|
||||
|
||||
## Changes in v2.5.8
|
||||
|
||||
The `Flows` and `ClusterFlows` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
|
||||
<a id="flows-2-5-8"></a>
|
||||
|
||||
## Flows
|
||||
|
||||
A `Flow` defines which logs to collect and filter and which output to send the logs to.
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
<a id="matches-2-5-8"></a>
|
||||
A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
`Flows` need to be defined in YAML.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Matches
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
Match statements are used to select which containers to pull logs from.
|
||||
|
||||
You can specify match statements to select or exclude logs according to Kubernetes labels, container and host names. Match statements are evaluated in the order they are defined and processed only until the first matching select or exclude rule applies.
|
||||
@@ -48,84 +46,70 @@ Matches can be configured by filling out the `Flow` or `ClusterFlow` forms in th
|
||||
|
||||
For detailed examples on using the match statement, see the [official documentation on log routing.](https://kube-logging.github.io/docs/configuration/log-routing/)
|
||||
|
||||
<a id="filters-2-5-8"></a>
|
||||
|
||||
### Filters
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
|
||||
|
||||
Filters need to be configured in YAML.
|
||||
|
||||
<a id="outputs-2-5-8"></a>
|
||||
|
||||
### Outputs
|
||||
|
||||
This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
`Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
|
||||
|
||||
<a id="clusterflows-2-5-8"></a>
|
||||
|
||||
## ClusterFlows
|
||||
|
||||
Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
- [Flows](#flows-2-5-0)
|
||||
- [Matches](#matches-2-5-0)
|
||||
- [Filters](#filters-2-5-0)
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
- [ClusterFlows](#clusterflows-2-5-0)
|
||||
|
||||
|
||||
<a id="flows-2-5-0"></a>
|
||||
|
||||
## Flows
|
||||
|
||||
A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
|
||||
|
||||
`Flows` need to be defined in YAML.
|
||||
|
||||
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
|
||||
|
||||
|
||||
<a id="matches-2-5-0"></a>
|
||||
|
||||
### Matches
|
||||
|
||||
Match statements are used to select which containers to pull logs from.
|
||||
|
||||
You can specify match statements to select or exclude logs according to Kubernetes labels, container and host names. Match statements are evaluated in the order they are defined and processed only until the first matching select or exclude rule applies.
|
||||
|
||||
For detailed examples on using the match statement, see the [official documentation on log routing.](https://kube-logging.github.io/docs/configuration/log-routing/)
|
||||
|
||||
<a id="filters-2-5-0"></a>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Filters
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
|
||||
|
||||
Filters need to be configured in YAML.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
### Filters
|
||||
|
||||
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
|
||||
|
||||
For a list of filters supported by the Logging operator, see [this page.](https://kube-logging.github.io/docs/configuration/plugins/filters/)
|
||||
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
|
||||
|
||||
<a id="outputs-2-5-0"></a>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Outputs
|
||||
|
||||
This `Output` will receive logs from the `Flow`.
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
<a id="clusterflows-2-5-0"></a>
|
||||
`Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespaced resource, the `Output` must reside in same namespace as the `Flow`.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## ClusterFlows
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.
|
||||
|
||||
`ClusterFlow` selects logs from all namespaces in the cluster. Logs from the cluster will be collected and logged to the selected `ClusterOutput`.
|
||||
|
||||
+17
-39
@@ -6,23 +6,13 @@ See the [Logging operator documentation](https://kube-logging.github.io/docs/con
|
||||
|
||||
See [Rancher Integration with Logging Services: Troubleshooting](../../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
|
||||
|
||||
## Configuration
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v2.5.8+">
|
||||
|
||||
- [Outputs](#outputs-2-5-8)
|
||||
- [ClusterOutputs](#clusteroutputs-2-5-8)
|
||||
|
||||
## Changes in v2.5.8
|
||||
|
||||
The `Outputs` and `ClusterOutputs` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
|
||||
<a id="outputs-2-5-8"></a>
|
||||
|
||||
## Outputs
|
||||
|
||||
As of Rancher v2.5.8, the `Outputs` and `ClusterOutputs` can now be configured by filling out forms in the Rancher UI.
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
|
||||
|
||||
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
|
||||
@@ -55,25 +45,9 @@ The Rancher UI provides forms for configuring the `Output` type, target, and acc
|
||||
|
||||
For example configuration for each logging plugin supported by the logging operator, see the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/plugins/outputs/).
|
||||
|
||||
<a id="clusteroutputs-2-5-8"></a>
|
||||
|
||||
## ClusterOutputs
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
- [Outputs](#outputs-2-5-0)
|
||||
- [ClusterOutputs](#clusteroutputs-2-5-0)
|
||||
|
||||
|
||||
<a id="outputs-2-5-0"></a>
|
||||
|
||||
## Outputs
|
||||
|
||||
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
|
||||
|
||||
The `Output` is a namespaced resource, which means only a `Flow` within the same namespace can access it.
|
||||
@@ -84,10 +58,21 @@ You can use secrets in these definitions, but they must also be in the same name
|
||||
|
||||
For examples of configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://kube-logging.github.io/docs/configuration/plugins/outputs/)
|
||||
|
||||
<a id="clusteroutputs-2-5-0"></a>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## ClusterOutputs
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
|
||||
|
||||
The Rancher UI provides forms for configuring the `ClusterOutput` type, target, and access credentials if applicable.
|
||||
@@ -99,16 +84,10 @@ For example configuration for each logging plugin supported by the logging opera
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## YAML Examples
|
||||
|
||||
Once logging is installed, you can use these examples to help craft your own logging pipeline.
|
||||
|
||||
- [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch)
|
||||
- [Output to Splunk](#output-to-splunk)
|
||||
- [Output to Syslog](#output-to-syslog)
|
||||
- [Unsupported Outputs](#unsupported-outputs)
|
||||
|
||||
### Cluster Output to ElasticSearch
|
||||
|
||||
Let's say you wanted to send all logs in your cluster to an `elasticsearch` cluster. First, we create a cluster `Output`.
|
||||
@@ -143,7 +122,6 @@ spec:
|
||||
|
||||
We should now see our configured index with logs in it.
|
||||
|
||||
|
||||
### Output to Splunk
|
||||
|
||||
What if we have an application team who only wants logs from a specific namespaces sent to a `splunk` server? For this case, we can use namespaced `Outputs` and `Flows`.
|
||||
|
||||
@@ -35,11 +35,11 @@ These instructions assume you are using Rancher v2.5, but Longhorn can be instal
|
||||
|
||||
### Installing Longhorn with Rancher
|
||||
|
||||
1. Fulfill all [Installation Requirements.](https://longhorn.io/docs/1.1.0/deploy/install/#installation-requirements)
|
||||
1. Fulfill all [Installation Requirements.](https://github.com/longhorn/website/blob/master/content/docs/archives/1.1.0/deploy/install/_index.md#installation-requirements)
|
||||
1. Go to the **Cluster Explorer** in the Rancher UI.
|
||||
1. Click **Apps.**
|
||||
1. Click `longhorn`.
|
||||
1. Optional: To customize the initial settings, click **Longhorn Default Settings** and edit the configuration. For help customizing the settings, refer to the [Longhorn documentation.](https://longhorn.io/docs/1.0.2/references/settings/)
|
||||
1. Optional: To customize the initial settings, click **Longhorn Default Settings** and edit the configuration. For help customizing the settings, refer to the [Longhorn documentation.](https://github.com/longhorn/website/blob/master/content/docs/archives/1.0.2/references/settings.md)
|
||||
1. Click **Install.**
|
||||
|
||||
**Result:** Longhorn is deployed in the Kubernetes cluster.
|
||||
|
||||
-4
@@ -6,10 +6,6 @@ _Available as of v2.5.8_
|
||||
|
||||
Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).
|
||||
|
||||
- [Comparison to Monitoring V1](#comparison-to-monitoring-v1)
|
||||
- [Cluster Requirements](#cluster-requirements)
|
||||
- [Upgrading Existing Clusters to wins v0.1.0](#upgrading-existing-clusters-to-wins-v0-1-0)
|
||||
|
||||
## Comparison to Monitoring V1
|
||||
|
||||
Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`.
|
||||
|
||||
+1
-1
@@ -198,7 +198,7 @@ docker run -d --restart=unless-stopped \
|
||||
rancher/rancher:latest
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
This layer 7 NGINX configuration is tested on NGINX version 1.13 (mainline) and 1.14 (stable).
|
||||
|
||||
|
||||
-4
@@ -6,10 +6,6 @@ title: Rollbacks
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks"/>
|
||||
</head>
|
||||
|
||||
- [Rolling Back to Rancher v2.5.0+](#rolling-back-to-rancher-v2-5-0)
|
||||
- [Rolling Back to Rancher v2.2-v2.4+](#rolling-back-to-rancher-v2-2-v2-4)
|
||||
- [Rolling Back to Rancher v2.0-v2.1](#rolling-back-to-rancher-v2-0-v2-1)
|
||||
|
||||
## Rolling Back to Rancher v2.5.0+
|
||||
|
||||
To roll back to Rancher v2.5.0+, use the **Rancher Backups** application and restore Rancher from backup.
|
||||
|
||||
-5
@@ -14,11 +14,6 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa
|
||||
|
||||
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Upgrade Outline](#upgrade-outline)
|
||||
- [Known Upgrade Issues](#known-upgrade-issues)
|
||||
- [RKE Add-on Installs](#rke-add-on-installs)
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Access to kubeconfig
|
||||
|
||||
+3
-3
@@ -40,7 +40,7 @@ Log into your Linux host, and then run the installation command below. When ente
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port. |
|
||||
| `<RANCHER_VERSION_TAG>` | The release tag of the [Rancher version](../../../../reference-guides/installation-references/helm-chart-options.md) that you want to install. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -77,7 +77,7 @@ After creating your certificate, log into your Linux host, and then run the inst
|
||||
| `<REGISTRY.YOURDOMAIN.COM:PORT>` | Your private registry URL and port. |
|
||||
| `<RANCHER_VERSION_TAG>` | The release tag of the [Rancher version](../../../../reference-guides/installation-references/helm-chart-options.md) that you want to install. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -114,7 +114,7 @@ After obtaining your certificate, log into your Linux host, and then run the ins
|
||||
|
||||
> **Note:** Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
|
||||
+1
-1
@@ -269,7 +269,7 @@ Copy the rendered manifest directories to a system that has access to the Ranche
|
||||
|
||||
Use `kubectl` to create namespaces and apply the rendered manifests.
|
||||
|
||||
If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager.
|
||||
If you choose to use self-signed certificates in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), install cert-manager.
|
||||
|
||||
### For Self-Signed Certificate Installs, Install Cert-manager
|
||||
|
||||
|
||||
+1
-1
@@ -78,7 +78,7 @@ If you have issues upgrading Rancher, roll it back to its latest known healthy s
|
||||
--privileged \
|
||||
rancher/rancher:<PRIOR_RANCHER_VERSION>
|
||||
```
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
>**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.
|
||||
|
||||
|
||||
+8
-8
@@ -10,7 +10,7 @@ The following instructions will guide you through upgrading a Rancher server tha
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) Note that upgrades to or from any chart in the [rancher-alpha repository](../../../../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories/) aren’t supported.
|
||||
- **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues) in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) Note that upgrades to or from any chart in the [rancher-alpha repository](../../resources/choose-a-rancher-version.md#helm-chart-repositories) aren’t supported.
|
||||
- **For [air gap installs only,](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version.** Follow the guide to [populate your private registry](../air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
|
||||
|
||||
## Placeholder Review
|
||||
@@ -151,7 +151,7 @@ docker run -d --volumes-from rancher-data \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
</details>
|
||||
|
||||
@@ -183,7 +183,7 @@ docker run -d --volumes-from rancher-data \
|
||||
rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
</details>
|
||||
|
||||
@@ -214,7 +214,7 @@ docker run -d --volumes-from rancher-data \
|
||||
--no-cacerts
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
### Option D: Let's Encrypt Certificate
|
||||
@@ -245,7 +245,7 @@ docker run -d --volumes-from rancher-data \
|
||||
--acme-domain <YOUR.DNS.NAME>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
|
||||
</details>
|
||||
|
||||
@@ -278,7 +278,7 @@ Placeholder | Description
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
### Option B: Bring Your Own Certificate: Self-Signed
|
||||
@@ -310,7 +310,7 @@ docker run -d --restart=unless-stopped \
|
||||
--privileged \
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
### Option C: Bring Your Own Certificate: Signed by Recognized CA
|
||||
@@ -344,7 +344,7 @@ docker run -d --volumes-from rancher-data \
|
||||
--privileged
|
||||
<REGISTRY.YOURDOMAIN.COM:PORT>/rancher/rancher:<RANCHER_VERSION_TAG>
|
||||
```
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher-v25)
|
||||
</details>
|
||||
|
||||
</TabItem>
|
||||
|
||||
+6
-6
@@ -9,8 +9,8 @@ title: Upgrading Cert-Manager with Helm 2
|
||||
Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, three important changes to cert-manager are set to occur that you need to take action on if you have an HA deployment of Rancher:
|
||||
|
||||
1. [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753)
|
||||
1. [Cert-manager is deprecating and replacing the certificate.spec.acme.solvers field](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.7-0.8.html#upgrading-from-v0-7-to-v0-8). This change has no exact deadline.
|
||||
1. [Cert-manager is deprecating `v1alpha1` API and replacing its API group](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/)
|
||||
1. [Cert-manager is deprecating and replacing the certificate.spec.acme.solvers field](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8). This change has no exact deadline.
|
||||
1. [Cert-manager is deprecating `v1alpha1` API and replacing its API group](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11)
|
||||
|
||||
To address these changes, this guide will do two things:
|
||||
|
||||
@@ -157,12 +157,12 @@ cert-manager-webhook-5b5dd6999-kst4x 1/1 Running 0 3
|
||||
cert-manager-cainjector-3ba5cd2bcd-de332x 1/1 Running 0 3m
|
||||
```
|
||||
|
||||
If the ‘webhook’ pod (2nd line) is in a ContainerCreating state, it may still be waiting for the Secret to be mounted into the pod. Wait a couple of minutes for this to happen but if you experience problems, please check cert-manager's [troubleshooting](https://docs.cert-manager.io/en/latest/getting-started/troubleshooting.html) guide.
|
||||
If the ‘webhook’ pod (2nd line) is in a ContainerCreating state, it may still be waiting for the Secret to be mounted into the pod. Wait a couple of minutes for this to happen but if you experience problems, please check cert-manager's [troubleshooting](https://cert-manager.io/docs/troubleshooting/) guide.
|
||||
|
||||
> **Note:** The above instructions ask you to add the disable-validation label to the kube-system namespace. Here are additional resources that explain why this is necessary:
|
||||
>
|
||||
> - [Information on the disable-validation label](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.4-0.5.html?highlight=certmanager.k8s.io%2Fdisable-validation#disabling-resource-validation-on-the-cert-manager-namespace)
|
||||
> - [Information on webhook validation for certificates](https://docs.cert-manager.io/en/latest/getting-started/webhook.html)
|
||||
> - [Information on the disable-validation label](https://cert-manager.io/docs/installation/upgrading/upgrading-0.4-0.5#disabling-resource-validation-on-the-cert-manager-namespace)
|
||||
> - [Information on webhook validation for certificates](https://cert-manager.io/docs/concepts/webhook/)
|
||||
|
||||
## Cert-Manager API change and data migration
|
||||
|
||||
@@ -178,4 +178,4 @@ We have also removed support for the old configuration format that was deprecate
|
||||
|
||||
Details about the change and migration instructions can be found in the [cert-manager v0.10 to v0.11 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/).
|
||||
|
||||
For information on upgrading from all other versions of cert-manager, refer to the [official documentation](https://cert-manager.io/docs/installation/upgrading/).
|
||||
For information on upgrading from all other versions of cert-manager, refer to the [official documentation](https://cert-manager.io/docs/installation/upgrade/).
|
||||
|
||||
+1
-1
@@ -242,4 +242,4 @@ We have also removed support for the old configuration format that was deprecate
|
||||
|
||||
Details about the change and migration instructions can be found in the [cert-manager v0.10 to v0.11 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/).
|
||||
|
||||
More info about [cert-manager upgrade information](https://cert-manager.io/docs/installation/upgrading/).
|
||||
More info about [cert-manager upgrade information](https://cert-manager.io/docs/installation/upgrade/).
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
title: Global Permissions
|
||||
---
|
||||
|
||||
<head>
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions"/>
|
||||
</head>
|
||||
|
||||
@@ -93,7 +93,7 @@ When a user logs into Rancher using an external authentication provider for the
|
||||
|
||||
To see the default permissions for new users, go to the **Global** view and click **Security > Roles.** On the **Global** tab, there is a column named **New User Default.** When adding a new local user, the user receives all default global permissions that are marked as checked in this column, and you can [change them to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-existing-individual-users)
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-individual-users)
|
||||
|
||||
You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
|
||||
|
||||
|
||||
+1
-1
@@ -21,7 +21,7 @@ The CIS Benchmark application supports two types of alerts:
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../explanations/integrations-in-rancher/cis-scans/configuration-reference.md)
|
||||
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers/#example-route-config-for-cis-scan-alerts)
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+2
-2
@@ -8,10 +8,10 @@ title: Enable Alerting for Rancher CIS Benchmark
|
||||
|
||||
Alerts can be configured to be sent out for a scan that runs on a schedule.
|
||||
|
||||
:::note Prerequisite:
|
||||
:::note Prerequisite:
|
||||
|
||||
Before enabling alerts for `rancher-cis-benchmark`, make sure to install the `rancher-monitoring` application and configure the Receivers and Routes. For more information, see [this section.](../../../explanations/integrations-in-rancher/cis-scans/configuration-reference.md)
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers/#example-route-config-for-cis-scan-alerts)
|
||||
While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. An example route configuration is [here.](../../../reference-guides/monitoring-v2-configuration/receivers.md#example-route-config-for-cis-scan-alerts)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -32,7 +32,7 @@ This second method, the capability to connect directly to the cluster's Kubernet
|
||||
|
||||
To use the authorized cluster endpoint, you will need to configure kubectl to use the extra kubectl context in the kubeconfig file that Rancher generates for you when the RKE cluster is created. This file can be downloaded from the cluster view in the Rancher UI, and the instructions for configuring kubectl are on [this page.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)
|
||||
|
||||
These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../pages-for-subheaders/rancher-manager-architecture.md#communicating-with-downstream-user-clusters) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
|
||||
These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
|
||||
|
||||
### About the kube-api-auth Authentication Webhook
|
||||
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ You can assign a pod security policy when you provision a cluster. However, if y
|
||||
|
||||
4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
|
||||
|
||||
Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-pod-security-policies) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-pod-security-policies) as well.
|
||||
Rancher ships with [policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#default-psps) of `restricted` and `unrestricted`, although you can [create custom policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md#creating-psps) as well.
|
||||
|
||||
5. Click **Save**.
|
||||
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ This section describes how to set up existing persistent storage for workloads i
|
||||
To set up storage, follow these steps:
|
||||
|
||||
1. [Set up persistent storage.](#1-set-up-persistent-storage)
|
||||
2. [Add a persistent volume that refers to the persistent storage.](#2-add-a-persistent-volume-that-refers-to-the-persistent-storage)
|
||||
2. [Add a persistent volume that refers to the persistent storage.](#2-add-a-persistentvolume-that-refers-to-the-persistent-storage)
|
||||
3. [Add a persistent volume claim that refers to the persistent volume.](#3-add-a-persistent-volume-claim-that-refers-to-the-persistent-volume)
|
||||
4. [Mount the persistent volume claim as a volume in your workload.](#4-mount-the-persistent-volume-claim-as-a-volume-in-your-workload)
|
||||
|
||||
|
||||
+1
-1
@@ -106,7 +106,7 @@ Standard users are only authorized for project access in two situations:
|
||||
|
||||
## Pod Security Policies
|
||||
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policluster-admin/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
|
||||
## Creating Projects
|
||||
|
||||
|
||||
+3
-4
@@ -8,7 +8,7 @@ If you previously enabled Monitoring, Alerting, or Notifiers in Rancher before v
|
||||
|
||||
As of v2.2.0, Rancher's Cluster Manager allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster.
|
||||
|
||||
When Monitoring is enabled, Monitoring V1 deploys [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/docs/grafana/latest/getting-started/what-is-grafana/) onto a cluster to monitor the state of processes of your cluster nodes, Kubernetes components, and software deployments and create custom dashboards to make it easy to visualize collected metrics.
|
||||
When Monitoring is enabled, Monitoring V1 deploys [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/docs/grafana/latest/introduction/) onto a cluster to monitor the state of processes of your cluster nodes, Kubernetes components, and software deployments and create custom dashboards to make it easy to visualize collected metrics.
|
||||
|
||||
Monitoring V1 could be configured on both a cluster-level and on a project-level and would automatically scrape certain workloads deployed as Apps on the Rancher cluster.
|
||||
|
||||
@@ -116,12 +116,11 @@ or add the Prometheus Rule through the Cluster Explorer
|
||||
|
||||

|
||||
|
||||
For more details on how to configure PrometheusRules in Monitoring V2 see [Monitoring Configuration](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md#prometheusrules).
|
||||
For more details on how to configure PrometheusRules in Monitoring V2 see [Monitoring Configuration](../../advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md).
|
||||
|
||||
### Migrating Notifiers
|
||||
|
||||
There is no direct equivalent for how notifiers work in Monitoring V1. Instead you have to replicate the desired setup with [Routes and Receivers](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md#alertmanager-config) in Monitoring V2.
|
||||
|
||||
There is no direct equivalent for how notifiers work in Monitoring V1. Instead you have to replicate the desired setup with [Routes and Receivers](../../advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md) in Monitoring V2.
|
||||
|
||||
### Migrating for RKE Template Users
|
||||
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ It is usually not necessary to directly edit the Alertmanager custom resource. F
|
||||
|
||||
When Receivers and Routes are updated, the monitoring application will automatically update the Alertmanager custom resource to be consistent with those changes.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#how-alertmanager-works)
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#3-how-alertmanager-works)
|
||||
|
||||
## About the Alertmanager Custom Resource
|
||||
|
||||
|
||||
+1
-1
@@ -93,7 +93,7 @@ spec:
|
||||
|
||||
### 3. Install cert-manager
|
||||
|
||||
Follow the steps to [install cert-manager](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#5-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
|
||||
Follow the steps to [install cert-manager](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#4-install-cert-manager) in the documentation about installing cert-manager on Kubernetes.
|
||||
|
||||
### 4. Bring up Rancher with Helm
|
||||
|
||||
|
||||
+1
-1
@@ -4,7 +4,7 @@ title: Setting up the Google Compute Engine Cloud Provider
|
||||
|
||||
In this section, you'll learn how to enable the Google Compute Engine (GCE) cloud provider for custom clusters in Rancher. A custom cluster is one in which Rancher installs Kubernetes on existing nodes.
|
||||
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#gce)
|
||||
The official Kubernetes documentation for the GCE cloud provider is [here.](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md#gce)
|
||||
|
||||
> **Prerequisites:** The service account of `Identity and API` access on GCE needs the `Computer Admin` permission.
|
||||
|
||||
|
||||
+3
-36
@@ -151,19 +151,10 @@ resource "rancher2_cluster" "my-eks-to-import" {
|
||||
|
||||
The control that Rancher has to manage a registered cluster depends on the type of cluster.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
- [Changes in v2.5.8](#changes-in-v2-5-8)
|
||||
- [Features for All Registered Clusters](#2-5-8-features-for-all-registered-clusters)
|
||||
- [Additional Features for Registered K3s Clusters](#2-5-8-additional-features-for-registered-k3s-clusters)
|
||||
- [Additional Features for Registered EKS and GKE Clusters](#additional-features-for-registered-eks-and-gke-clusters)
|
||||
|
||||
### Changes in v2.5.8
|
||||
|
||||
Greater management capabilities are now available for [registered GKE clusters.](#additional-features-for-registered-eks-and-gke-clusters) The same configuration options are available for registered GKE clusters as for the GKE clusters created through the Rancher UI.
|
||||
|
||||
<a id="2-5-8-features-for-all-registered-clusters"></a>
|
||||
### Features for All Registered Clusters
|
||||
|
||||
After registering a cluster, the cluster owner can:
|
||||
@@ -174,7 +165,6 @@ After registering a cluster, the cluster owner can:
|
||||
- Enable [Istio](../../../pages-for-subheaders/istio.md)
|
||||
- Manage projects and workloads
|
||||
|
||||
<a id="2-5-8-additional-features-for-registered-k3s-clusters"></a>
|
||||
### Additional Features for Registered K3s Clusters
|
||||
|
||||
[K3s](https://rancher.com/docs/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution.
|
||||
@@ -185,6 +175,9 @@ When a K3s cluster is registered in Rancher, Rancher will recognize it as K3s. T
|
||||
- The ability to configure the maximum number of nodes that will be upgraded concurrently
|
||||
- The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster
|
||||
|
||||
<Tabs groupId="rancher-version">
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
### Additional Features for Registered EKS and GKE Clusters
|
||||
|
||||
Registering an Amazon EKS cluster or GKE cluster allows Rancher to treat it as though it were created in Rancher.
|
||||
@@ -198,32 +191,6 @@ The capabilities for registered clusters are listed in the table on [this page.]
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
- [Features for All Registered Clusters](#before-2-5-8-features-for-all-registered-clusters)
|
||||
- [Additional Features for Registered K3s Clusters](#before-2-5-8-additional-features-for-registered-k3s-clusters)
|
||||
- [Additional Features for Registered EKS Clusters](#additional-features-for-registered-eks-clusters)
|
||||
|
||||
<a id="before-2-5-8-features-for-all-registered-clusters"></a>
|
||||
### Features for All Registered Clusters
|
||||
|
||||
After registering a cluster, the cluster owner can:
|
||||
|
||||
- [Manage cluster access](../../advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md) through role-based access control
|
||||
- Enable [monitoring, alerts and notifiers](../../../pages-for-subheaders/monitoring-and-alerting.md)
|
||||
- Enable [logging](../../../pages-for-subheaders/logging.md)
|
||||
- Enable [Istio](../../../pages-for-subheaders/istio.md)
|
||||
- Manage projects and workloads
|
||||
|
||||
<a id="before-2-5-8-additional-features-for-registered-k3s-clusters"></a>
|
||||
### Additional Features for Registered K3s Clusters
|
||||
|
||||
[K3s](https://rancher.com/docs/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution.
|
||||
|
||||
When a K3s cluster is registered in Rancher, Rancher will recognize it as K3s. The Rancher UI will expose the features for [all registered clusters,](#features-for-all-registered-clusters) in addition to the following features for editing and upgrading the cluster:
|
||||
|
||||
- The ability to [upgrade the K3s version](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)
|
||||
- The ability to configure the maximum number of nodes that will be upgraded concurrently
|
||||
- The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster
|
||||
|
||||
### Additional Features for Registered EKS Clusters
|
||||
|
||||
Registering an Amazon EKS cluster allows Rancher to treat it as though it were created in Rancher.
|
||||
|
||||
+1
-1
@@ -136,7 +136,7 @@ Use Rancher to set up and configure your Kubernetes cluster.
|
||||
|
||||
>**Note:** After submitting your private key, you may have to enable the Google Kubernetes Engine API. If prompted, browse to the URL displayed in the Rancher UI to enable the API.
|
||||
|
||||
6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](#gke-before-v2-5-8)
|
||||
6. Select your cluster options, node options and security options. For help, refer to the [GKE Cluster Configuration Reference.](../../../../pages-for-subheaders/gke-cluster-configuration.md)
|
||||
9. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:** You have successfully deployed a GKE cluster.
|
||||
|
||||
+1
-1
@@ -21,7 +21,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an
|
||||
|
||||
## Ingress Rule Configuration
|
||||
|
||||
- [Automatically generate a sslip.io hostname](#automatically-generate-a-sslip-io-hostname)
|
||||
- [Automatically generate a sslip.io hostname](#automatically-generate-a-sslipio-hostname)
|
||||
- [Specify a hostname to use](#specify-a-hostname-to-use)
|
||||
- [Use as the default backend](#use-as-the-default-backend)
|
||||
- [Certificates](#certificates)
|
||||
|
||||
+1
-1
@@ -45,7 +45,7 @@ Deploy a workload to run an application in one or more containers.
|
||||
>
|
||||
>- 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](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).
|
||||
>- The cluster must be using the [AWS cloud provider](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md).
|
||||
|
||||
|
||||
1. Click **Show Advanced Options** and configure:
|
||||
|
||||
@@ -15,9 +15,7 @@ Use the navigation bar on the left to find the current best practices for managi
|
||||
For more guidance on best practices, you can consult these resources:
|
||||
|
||||
- [Security](rancher-security.md)
|
||||
- [Rancher Blog](https://rancher.com/blog/)
|
||||
- [Articles about best practices on the Rancher blog](https://rancher.com/tags/best-practices/)
|
||||
- [101 More Security Best Practices for Kubernetes](https://rancher.com/blog/2019/2019-01-17-101-more-kubernetes-security-best-practices/)
|
||||
- [Rancher Blog](https://www.suse.com/c/rancherblog/)
|
||||
- [Rancher Forum](https://forums.rancher.com/)
|
||||
- [Rancher Users Slack](https://slack.rancher.io/)
|
||||
- [Rancher Labs YouTube Channel - Online Meetups, Demos, Training, and Webinars](https://www.youtube.com/channel/UCh5Xtp82q8wjijP8npkVTBA/featured)
|
||||
|
||||
+2
-2
@@ -108,8 +108,8 @@ There are three recommended options for the source of the certificate used for T
|
||||
|
||||
| Configuration | Helm Chart Option | Requires cert-manager |
|
||||
| ------------------------------ | ----------------------- | ------------------------------------- |
|
||||
| Rancher Generated Certificates (Default) | `ingress.tls.source=rancher` | [yes](#5-install-cert-manager) |
|
||||
| Let’s Encrypt | `ingress.tls.source=letsEncrypt` | [yes](#5-install-cert-manager) |
|
||||
| Rancher Generated Certificates (Default) | `ingress.tls.source=rancher` | [yes](#4-install-cert-manager) |
|
||||
| Let’s Encrypt | `ingress.tls.source=letsEncrypt` | [yes](#4-install-cert-manager) |
|
||||
| Certificates from Files | `ingress.tls.source=secret` | no |
|
||||
|
||||
### 4. Install cert-manager
|
||||
|
||||
+4
-4
@@ -54,7 +54,7 @@ If you are installing Rancher in a development or testing environment where iden
|
||||
|
||||
Log into your Linux host, and then run the minimum installation command below.
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```bash
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -81,7 +81,7 @@ After creating your certificate, run the Docker command below to install Rancher
|
||||
| `<PRIVATE_KEY.pem>` | The path to the private key for your certificate. |
|
||||
| `<CA_CERTS.pem>` | The path to the certificate authority's certificate. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```bash
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -113,7 +113,7 @@ After obtaining your certificate, run the Docker command below.
|
||||
| `<FULL_CHAIN.pem>` | The path to your full certificate chain. |
|
||||
| `<PRIVATE_KEY.pem>` | The path to the private key for your certificate. |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```bash
|
||||
docker run -d --restart=unless-stopped \
|
||||
@@ -143,7 +143,7 @@ After you fulfill the prerequisites, you can install Rancher using a Let's Encry
|
||||
| ----------------- | ------------------- |
|
||||
| `<YOUR.DNS.NAME>` | Your domain address |
|
||||
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v2-5)
|
||||
As of Rancher v2.5, privileged access is [required.](#privileged-access-for-rancher-v25)
|
||||
|
||||
```
|
||||
docker run -d --restart=unless-stopped \
|
||||
|
||||
@@ -29,8 +29,8 @@ Kubernetes v1.18+ | CIS v1.6 | [Link](../reference-guides/rancher-security/ranch
|
||||
|
||||
Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides
|
||||
---|---|---|---
|
||||
Kubernetes v1.18 | CIS v1.5 | [Link](https://docs.rke2.io/security/cis_self_assessment15/) | [Link](https://docs.rke2.io/security/hardening_guide/)
|
||||
Kubernetes v1.20 | CIS v1.6 | [Link](https://docs.rke2.io/security/cis_self_assessment16/) | [Link](https://docs.rke2.io/security/hardening_guide/)
|
||||
Kubernetes v1.18 | CIS v1.5 | [Link](https://github.com/rancher/rke2-docs/blob/f36b47ae8de3d859ae2db8ddf26beeb26c3e80b1/docs/security/cis_self_assessment15.md) | [Link](https://docs.rke2.io/security/hardening_guide)
|
||||
Kubernetes v1.20 | CIS v1.6 | [Link](https://docs.rke2.io/security/cis_self_assessment16) | [Link](https://docs.rke2.io/security/hardening_guide)
|
||||
|
||||
### K3s Guides
|
||||
|
||||
|
||||
@@ -59,7 +59,7 @@ Clusters won't begin provisioning until all three node roles (worker, etcd and c
|
||||
>- Using Windows nodes as Kubernetes workers? See [this section](use-windows-clusters.md).
|
||||
>- Bare-Metal Server Reminder: If you plan on dedicating bare-metal servers to each role, you must provision a bare-metal server for each role (i.e. provision multiple bare-metal servers).
|
||||
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options](admin-settings/agent-options/)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
8. <a id="step-8"></a>**Optional**: Click **[Show advanced options](../reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options.md)** to specify IP address(es) to use when registering the node, override the hostname of the node, or to add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to the node.
|
||||
|
||||
9. Copy the command displayed on screen to your clipboard.
|
||||
|
||||
@@ -87,7 +87,7 @@ If you have configured your cluster to use Amazon as **Cloud Provider**, tag you
|
||||
|
||||
[Amazon Documentation: Tagging Your Amazon EC2 Resources](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
|
||||
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)
|
||||
>**Note:** You can use Amazon EC2 instances without configuring a cloud provider in Kubernetes. You only have to configure the cloud provider if you want to use specific Kubernetes cloud provider functionality. For more information, see [Kubernetes Cloud Providers](https://github.com/kubernetes/website/blob/release-1.18/content/en/docs/concepts/cluster-administration/cloud-providers.md)
|
||||
|
||||
|
||||
The following resources need to be tagged with a `ClusterID`:
|
||||
|
||||
@@ -15,7 +15,7 @@ Rancher can provision nodes in vSphere and install Kubernetes on them. When crea
|
||||
|
||||
A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role.
|
||||
|
||||
- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v2-3)
|
||||
- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v23)
|
||||
- [Creating a vSphere Cluster](#creating-a-vsphere-cluster)
|
||||
- [Provisioning Storage](#provisioning-storage)
|
||||
- [Enabling the vSphere Cloud Provider](#enabling-the-vsphere-cloud-provider)
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: Logging Best Practices
|
||||
|
||||
In this guide, we recommend best practices for cluster-level logging and application logging.
|
||||
|
||||
- [Changes in Logging in Rancher v2.5](#changes-in-logging-in-rancher-v2-5)
|
||||
- [Changes in Logging in Rancher v2.5](#changes-in-logging-in-rancher-v25)
|
||||
- [Cluster-level Logging](#cluster-level-logging)
|
||||
- [Application Logging](#application-logging)
|
||||
- [General Best Practices](#general-best-practices)
|
||||
|
||||
@@ -33,4 +33,4 @@ This feature enables kubectl to authenticate with the Rancher server and get a n
|
||||
4. OpenLDAP
|
||||
5. SAML providers: Ping, Okta, ADFS, Keycloak, Shibboleth
|
||||
|
||||
When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens-period), or [gets deleted from the Rancher server](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
|
||||
When you first run kubectl, for example, `kubectl get pods`, it will ask you to pick an auth provider and log in with the Rancher server. The kubeconfig token is cached in the path where you run kubectl under `./.cache/token`. This token is valid until [it expires](../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), or [gets deleted from the Rancher server](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens). Upon expiration, the next `kubectl get pods` will ask you to log in with the Rancher server again.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user