From 59b08d176c369b26f847d2a63cf20c336bb820ca Mon Sep 17 00:00:00 2001 From: Lars Kerick Date: Wed, 2 Dec 2020 09:25:15 +0100 Subject: [PATCH 01/12] Added cgroup documentation for raspbian --- content/k3s/latest/en/advanced/_index.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/content/k3s/latest/en/advanced/_index.md b/content/k3s/latest/en/advanced/_index.md index 7edd6c620dc..633399b6614 100644 --- a/content/k3s/latest/en/advanced/_index.md +++ b/content/k3s/latest/en/advanced/_index.md @@ -19,6 +19,7 @@ This section contains advanced information describing the different ways you can - [Additional preparation for Alpine Linux setup](#additional-preparation-for-alpine-linux-setup) - [Running K3d (K3s in Docker) and docker-compose](#running-k3d-k3s-in-docker-and-docker-compose) - [Enabling legacy iptables on Raspbian Buster](#enabling-legacy-iptables-on-raspbian-buster) +- [Enabling cgroups for Raspbian Buster](#enabling-cgroups-for-raspbian-buster) - [SELinux Support](#selinux-support) # Certificate Rotation @@ -304,6 +305,15 @@ sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy sudo reboot ``` +# Enabling cgroups for Raspbian Buster + +Standard Raspbian Buster installations do not start with `cgroups` enabled. **K3S** needs `cgroups` to start the systemd service. `cgroups`can be enabled by appending `cgroup_memory=1 cgroup_enable=memory` to `/boot/cmdline.txt`. + +## example of /boot/cmdline.txt +``` +console=serial0,115200 console=tty1 root=PARTUUID=58b06195-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait cgroup_memory=1 cgroup_enable=memory +``` + # SELinux Support _Supported as of v1.19.4+k3s1. Experimental as of v1.17.4+k3s1._ From a2792b726de0beedb64c983b4986c3b3f648307f Mon Sep 17 00:00:00 2001 From: Tejeev Date: Fri, 4 Dec 2020 11:11:45 +0000 Subject: [PATCH 02/12] Add note on how to fetch specific version --- .../air-gap/install-rancher/_index.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/install-rancher/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/install-rancher/_index.md index c27acbcca55..58a9e26b8de 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/install-rancher/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/install-rancher/_index.md @@ -40,9 +40,14 @@ From a system that has access to the internet, fetch the latest Helm chart and c ``` 3. Fetch the latest Rancher chart. This will pull down the chart and save it in the current directory as a `.tgz` file. -```plain -helm fetch rancher-/rancher -``` + ```plain + helm fetch rancher-/rancher + ``` + + If you require a specific version of Rancher, you can fetch this with the Helm `--version` parameter like in the following example: + ```plain + helm fetch rancher-stable/rancher --version=v2.4.8 + ``` ### B. Choose your SSL Configuration From d694d5c9b7e78d0d804facbc4f6360ed417281a0 Mon Sep 17 00:00:00 2001 From: Tejeev Date: Fri, 4 Dec 2020 12:24:02 +0000 Subject: [PATCH 03/12] actually explained how to choose a version this instruction was conspicuously missing from the doc of the same name --- .../installation/resources/choosing-version/_index.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/installation/resources/choosing-version/_index.md b/content/rancher/v2.x/en/installation/resources/choosing-version/_index.md index 2d6af682c01..328f9066724 100644 --- a/content/rancher/v2.x/en/installation/resources/choosing-version/_index.md +++ b/content/rancher/v2.x/en/installation/resources/choosing-version/_index.md @@ -35,9 +35,16 @@ Instructions on when to select these repos are available below in [Switching to ### Helm Chart Versions -Rancher Helm chart versions match the Rancher version (i.e `appVersion`). +Rancher Helm chart versions match the Rancher version (i.e `appVersion`). Once you've added the repo you can search it to show available versions with the following command:
+    `helm search repo --versions` -For the Rancher v2.1.x versions, there were some Helm charts, that were using a version that was a build number, i.e. `yyyy.mm.`. These charts have been replaced with the equivalent Rancher version and are no longer available. +If you have several repos you can specify the repo name, ie. `helm search repo rancher-stable/rancher --versions`
+For more information, see https://helm.sh/docs/helm/helm_search_repo/ + +To fetch a specific version of your chosen repo, define the `--version` parameter like in the following example:
+    `helm fetch rancher-stable/rancher --version=2.4.8` + +For the Rancher v2.1.x versions, there were some Helm charts where the version was a build number, i.e. `yyyy.mm.`. These charts have been replaced with the equivalent Rancher version and are no longer available. ### Switching to a Different Helm Chart Repository From 78a49b79e0f4d662e92ff67a600be7e1f21ab1e9 Mon Sep 17 00:00:00 2001 From: Nick Gerace Date: Fri, 4 Dec 2020 11:56:17 -0500 Subject: [PATCH 04/12] Update Windows and RBAC sections in Logging Update Windows section to remove fluentd configcheck warning. Refactor RBAC section to be more streamlined. Add syslog note. Perform general edits on grammar and style. --- .../rancher/v2.x/en/logging/v2.5/_index.md | 99 +++++++++---------- 1 file changed, 49 insertions(+), 50 deletions(-) diff --git a/content/rancher/v2.x/en/logging/v2.5/_index.md b/content/rancher/v2.x/en/logging/v2.5/_index.md index cc8b7a446c6..7e0be50fbc5 100644 --- a/content/rancher/v2.x/en/logging/v2.5/_index.md +++ b/content/rancher/v2.x/en/logging/v2.5/_index.md @@ -11,19 +11,17 @@ weight: 1 - [Configuring the Logging Application](#configuring-the-logging-application) - [Working with Taints and Tolerations](#working-with-taints-and-tolerations) - # Changes in Rancher v2.5 The following changes were introduced to logging in Rancher v2.5: -- The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging in place of the former, in-house logging solution. -- [Fluent Bit](https://fluentbit.io/) is now used to aggregate the logs. [Fluentd](https://www.fluentd.org/) is used for filtering the messages and routing them to the outputs. Previously, only Fluentd was used. -- Logging can be configured with a Kubernetes manifest, because now the logging uses a Kubernetes operator with Custom Resource Definitions. +- The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution. +- [Fluent Bit](https://fluentbit.io/) is now used to aggregate the logs, and [Fluentd](https://www.fluentd.org/) is used for filtering the messages and routing them to the outputs. Previously, only Fluentd was used. +- Logging can be configured with a Kubernetes manifest, because logging now uses a Kubernetes operator with Custom Resource Definitions. - We now support filtering logs. - We now support writing logs to multiple outputs. - We now always collect Control Plane and etcd logs. - The following figure from the [Banzai documentation](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture) shows the new logging architecture:
How the Banzai Cloud Logging Operator Works with Fluentd and Fluent Bit
@@ -34,20 +32,20 @@ The following figure from the [Banzai documentation](https://banzaicloud.com/doc You can enable the logging for a Rancher managed cluster by going to the Apps page and installing the logging app. -1. In the Rancher UI, go to the cluster where you want to install logging and click **Cluster Explorer.** -1. Click **Apps.** +1. In the Rancher UI, go to the cluster where you want to install logging and click **Cluster Explorer**. +1. Click **Apps**. 1. Click the `rancher-logging` app. -1. Scroll to the bottom of the Helm chart README and click **Install.** +1. Scroll to the bottom of the Helm chart README and click **Install**. **Result:** The logging app is deployed in the `cattle-logging-system` namespace. # Uninstall Logging -1. From the **Cluster Explorer,** click **Apps & Marketplace.** -1. Click **Installed Apps.** +1. From the **Cluster Explorer**, click **Apps & Marketplace**. +1. Click **Installed Apps**. 1. Go to the `cattle-logging-system` namespace and check the boxes for `rancher-logging` and `rancher-logging-crd`. -1. Click **Delete.** -1. Confirm **Delete.** +1. Click **Delete**. +1. Confirm **Delete**. **Result** `rancher-logging` is uninstalled. @@ -55,21 +53,23 @@ You can enable the logging for a Rancher managed cluster by going to the Apps pa Rancher logging has two roles, `logging-admin` and `logging-view`. -`logging-admin` allows users full access to namespaced flows and outputs. +- `logging-admin` gives users full access to namespaced flows and outputs +- `logging-view` allows users to *view* namespaced flows and outputs, and cluster flows and outputs -The `logging-view` role allows users to view namespaced flows and outputs, and cluster flows and outputs. +> **Why choose one role over the other?** Edit access to cluster flow and cluster output resources is powerful. Any user with it has edit access for all logs in the cluster. -Edit access to the cluster flow and cluster output resources is powerful as it allows any user with edit access control of all logs in the cluster. +In Rancher, the cluster administrator role is the only role with full access to all `rancher-logging` resources. Cluster members are not able to edit or read any logging resources. Project owners and members have the following privileges: -In Rancher, the cluster administrator role is the only role with full access to all rancher-logging resources. +Project Owners | Project Members +--- | --- +able to create namespaced flows and outputs in their projects' namespaces | only able to view the flows and outputs in projects' namespaces +can collect logs from anything in their projects' namespaces | cannot collect any logs in their projects' namespaces -Cluster members are not able to edit or read any logging resources. - -Project owners are able to create namespaced flows and outputs in the namespaces under their projects. This means that project owners can collect logs from anything in their project namespaces. Project members are able to view the flows and outputs in the namespaces under their projects. Project owners and project members require at least 1 namespace in their project to use logging. If they do not have at least one namespace in their project they may not see the logging button in the top nav dropdown. +Both project owners and project members require at least *one* namespace in their project to use logging. If they do not, then they may not see the logging button in the top nav dropdown. # Configuring the Logging Application -To configure the logging application, go to the **Cluster Explorer** in the Rancher UI. In the upper left corner, click **Cluster Explorer > Logging.** +To configure the logging application, go to the **Cluster Explorer** in the Rancher UI. In the upper left corner, click **Cluster Explorer > Logging**. ### Overview of Logging Custom Resources @@ -84,9 +84,8 @@ According to the [Banzai Cloud documentation,](https://banzaicloud.com/docs/one- ### Examples -Let's say you wanted to send all logs in your cluster to an elasticsearch cluster. +**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. -First lets create our cluster output: ```yaml apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterOutput @@ -100,9 +99,9 @@ spec: scheme: http ``` -We have created a cluster output, without elasticsearch configuration, in the same namespace as our operator `cattle-logging-system.`. Any time we create a cluster flow or cluster output we have to put it in the `cattle-logging-system` namespace. +We have created this cluster output, without elasticsearch configuration, in the same namespace as our operator: `cattle-logging-system.`. Any time we create a cluster flow or cluster output, we have to put it in the `cattle-logging-system` namespace. -Now we have configured where we want the logs to go, lets configure all logs to go to that output. +Now that we have configured where we want the logs to go, let's configure all logs to go to that output. ```yaml apiVersion: logging.banzaicloud.io/v1beta1 @@ -117,9 +116,9 @@ spec: We should now see our configured index with logs in it. -What if we have an application team who only wants logs from a specific namespaces sent to a splunk server? For this case can use namespaced outputs and flows. +**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. -Before we start lets set up a scenario. +Before we start, let's set up that team's application: `coolapp`. ```yaml apiVersion: v1 @@ -149,7 +148,7 @@ spec: image: paynejacob/loggenerator:latest ``` -like before we start with an output, unlike cluster outputs we create our output in our application's namespace: +With `coolapp` running, we will follow a similar path as when we created a cluster output. However, unlike cluster outputs, we create our output in our application's namespace. ```yaml apiVersion: logging.banzaicloud.io/v1beta1 @@ -164,7 +163,7 @@ spec: protocol: http ``` -Once again, lets give our output some logs: +Once again, let's feed our output some logs. ```yaml apiVersion: logging.banzaicloud.io/v1beta1 @@ -177,7 +176,7 @@ spec: - "devteam-splunk" ``` -For the final example we create an output to write logs to a destination that is not supported out of the box (e.g. syslog): +**Unsupported Ouput:** For the final example, we create an output to write logs to a destination that is not supported out of the box (e.g. syslog): ```yaml apiVersion: v1 @@ -265,29 +264,31 @@ spec: ignore_network_errors_at_startup: false ``` -if we break down what is happening, first we create a deployment of a container that has the additional syslog plugin and accepts logs forwarded from another fluentd. Next we create an output configured as a forwarder to our deployment. The deployment fluentd will then forward all logs to the configured syslog destination. +Let's break down what is happening here. First, we create a deployment of a container that has the additional `syslog` plugin and accepts logs forwarded from another `fluentd`. Next we create an output configured as a forwarder to our deployment. The deployment `fluentd` will then forward all logs to the configured `syslog` destination. + +> **Note on syslog** The example provides an overview on using unsupported plugins, but `syslog` support is coming in a future Rancher v2.x release. # Working with Taints and Tolerations "Tainting" a Kubernetes node causes pods to repel running on that node. -Unless the pods have a ```toleration``` for that node's taint, they will run on other nodes in the cluster. -[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the ```nodeSelector``` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the ```PodSpec```, which enables the *opposite* effect of a taint. -Using ```nodeSelector``` gives pods an affinity towards certain nodes. +Unless the pods have a `toleration` for that node's taint, they will run on other nodes in the cluster. +[Taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) can work in conjunction with the `nodeSelector` [field](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) within the `PodSpec`, which enables the *opposite* effect of a taint. +Using `nodeSelector` gives pods an affinity towards certain nodes. Both provide choice for the what node(s) the pod will run on. ### Default Implementation in Rancher's Logging Stack -By default, Rancher taints all Linux nodes with ```cattle.io/os=linux```, and does not taint Windows nodes. -The logging stack pods have ```tolerations``` for this taint, which enables them to run on Linux nodes. -Moreover, we can populate the ```nodeSelector``` to ensure that our pods *only* run on Linux nodes. +By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes. +The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes. +Moreover, we can populate the `nodeSelector` to ensure that our pods *only* run on Linux nodes. Let's look at an example pod YAML file with these settings... ```yaml apiVersion: v1 kind: Pod -# metadata: +# metadata... spec: - # containers: + # containers... tolerations: - key: cattle.io/os operator: "Equal" @@ -297,33 +298,31 @@ spec: kubernetes.io/os: linux ``` -In the above example, we ensure that our pod only runs on Linux nodes, and we add a ```toleration``` for the taint we have on all of our Linux nodes. +In the above example, we ensure that our pod only runs on Linux nodes, and we add a `toleration` for the taint we have on all of our Linux nodes. You can do the same with Rancher's existing taints, or with your own custom ones. ### Windows Support -Clusters with Windows worker support logging with some small caveats: - -1. Windows node logs are currently unable to be exported. -2. ```fluentd-configcheck``` pod(s) will fail due to an [upstream issue](https://github.com/banzaicloud/logging-operator/issues/592), where ```tolerations``` and ```nodeSelector``` settings are not inherited from the ```logging-operator```. +Clusters with Windows workers support exporting logs from Linux nodes, but Windows node logs are currently unable to be exported. +Only Linux node logs are able to be exported. ### Adding NodeSelector Settings and Tolerations for Custom Taints -If you would like to add your own ```nodeSelector``` settings, or if you would like to add ```tolerations``` for additional taints, you can pass the following to the chart's values. +If you would like to add your own `nodeSelector` settings, or if you would like to add `tolerations` for additional taints, you can pass the following to the chart's values. ```yaml tolerations: - # insert tolerations list + # insert tolerations... nodeSelector: - # insert nodeSelector settings + # insert nodeSelector... ``` -These values will add both settings to the ```fluentd```, ```fluentbit```, and ```logging-operator``` containers. +These values will add both settings to the `fluentd`, `fluentbit`, and `logging-operator` containers. Essentially, these are global settings for all pods in the logging stack. -However, if you would like to add tolerations for *only* the ```fluentbit``` container, you can add the following to the chart's values. +However, if you would like to add tolerations for *only* the `fluentbit` container, you can add the following to the chart's values. ```yaml fluentbit_tolerations: - # insert tolerations list for fluentbit containers only -``` \ No newline at end of file + # insert tolerations list for fluentbit containers only... +``` From bf59bf2b908d936b5ef300497a26b57f91a19a70 Mon Sep 17 00:00:00 2001 From: JenTing Hsiao Date: Tue, 8 Dec 2020 12:34:36 +0800 Subject: [PATCH 05/12] Add anchor for Nodes Without a Hostname Signed-off-by: JenTing Hsiao --- content/k3s/latest/en/networking/_index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/k3s/latest/en/networking/_index.md b/content/k3s/latest/en/networking/_index.md index a98c5c0af9e..549096266eb 100644 --- a/content/k3s/latest/en/networking/_index.md +++ b/content/k3s/latest/en/networking/_index.md @@ -16,6 +16,7 @@ For information on which ports need to be opened for K3s, refer to the [Installa - [Usage](#usage) - [Excluding the Service LB from Nodes](#excluding-the-service-lb-from-nodes) - [Disabling the Service LB](#disabling-the-service-lb) +- [Nodes Without a Hostname](#nodes-without-a-hostname) # CoreDNS From 7944005a52f93a0880a67e1f94558e1066fe335d Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 8 Dec 2020 18:29:05 -0700 Subject: [PATCH 06/12] Say that you can migrate from Docker install with backup operator --- .../rancher/v2.x/en/installation/_index.md | 32 ++++++++++++++----- .../other-installation-methods/_index.md | 6 +++- .../air-gap/launch-kubernetes/_index.md | 6 ++-- .../air-gap/prepare-nodes/_index.md | 6 ++-- .../single-node-docker/_index.md | 8 +++-- .../v2.x/en/overview/architecture/_index.md | 8 ++++- 6 files changed, 48 insertions(+), 18 deletions(-) diff --git a/content/rancher/v2.x/en/installation/_index.md b/content/rancher/v2.x/en/installation/_index.md index 62364ea83ec..92f72123065 100644 --- a/content/rancher/v2.x/en/installation/_index.md +++ b/content/rancher/v2.x/en/installation/_index.md @@ -8,7 +8,7 @@ aliases: This section provides an overview of the architecture options of installing Rancher, describing advantages of each option. -### Terminology +# Terminology In this section, @@ -16,7 +16,7 @@ In this section, - **RKE (Rancher Kubernetes Engine)** is a certified Kubernetes distribution and CLI/library which creates and manages a Kubernetes cluster. - **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB. As of Rancher v2.4, Rancher can be installed on a K3s cluster. -### Changes to Installation in Rancher v2.5 +# Changes to Installation in Rancher v2.5 In Rancher v2.5, the Rancher management server can be installed on any Kubernetes cluster, including hosted clusters, such as Amazon EKS clusters. @@ -24,13 +24,29 @@ For Docker installations, a local Kubernetes cluster is installed in the single The `restrictedAdmin` Helm chart option was added. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.]({{}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#restricted-admin) -### Overview of Installation Options +# Overview of Installation Options Rancher can be installed on these main architectures: -- **High-availability Kubernetes Install:** We recommend using Helm, a Kubernetes package manager, to install Rancher on multiple nodes on a dedicated Kubernetes cluster. For RKE clusters, three nodes are required to achieve a high-availability cluster. For K3s clusters, only two nodes are required. -- **Single-node Kubernetes Install:** Another option is to install Rancher with Helm on a Kubernetes cluster, but to only use a single node in the cluster. In this case, the Rancher server doesn't have high availability, which is important for running Rancher in production. However, this option is useful if you want to save resources by using a single node in the short term, while preserving a high-availability migration path. In the future, you can add nodes to the cluster to get a high-availability Rancher server. -- **Docker Install:** For test and demonstration purposes, Rancher can be installed with Docker on a single node. This installation works out-of-the-box, but there is no migration path from a Docker installation to a high-availability installation. Therefore, you may want to use a Kubernetes installation from the start. +### High-availability Kubernetes Install + +We recommend using Helm, a Kubernetes package manager, to install Rancher on multiple nodes on a dedicated Kubernetes cluster. For RKE clusters, three nodes are required to achieve a high-availability cluster. For K3s clusters, only two nodes are required. + +### Single-node Kubernetes Install + +Another option is to install Rancher with Helm on a Kubernetes cluster, but to only use a single node in the cluster. In this case, the Rancher server doesn't have high availability, which is important for running Rancher in production. + +However, this option is useful if you want to save resources by using a single node in the short term, while preserving a high-availability migration path. In the future, you can add nodes to the cluster to get a high-availability Rancher server. + +### Docker Install + +For test and demonstration purposes, Rancher can be installed with Docker on a single node. + +For Rancher v2.0-v2.4, there is no migration path from a Docker installation to a high-availability installation. Therefore, you may want to use a Kubernetes installation from the start. + +For Rancher v2.5+, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{}}/rancher/v2.x/en/backups/v2.5/migrating-rancher/) + +### Other Options There are also separate instructions for installing Rancher in an air gap environment or behind an HTTP proxy: @@ -58,10 +74,10 @@ When the nodes in your Kubernetes cluster are running and fulfill the [node requ For a longer discussion of Rancher architecture, refer to the [architecture overview,]({{}}/rancher/v2.x/en/overview/architecture) [recommendations for production-grade architecture,]({{}}/rancher/v2.x/en/overview/architecture-recommendations) or our [best practices guide.]({{}}/rancher/v2.x/en/best-practices/deployment-types) -### Prerequisites +# Prerequisites Before installing Rancher, make sure that your nodes fulfill all of the [installation requirements.]({{}}/rancher/v2.x/en/installation/requirements/) -### Architecture Tip +# Architecture Tip For the best performance and greater security, we recommend a separate, dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters]({{}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher) for running your workloads. diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/_index.md index b9e2266abf8..0eab7f2d18c 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/_index.md @@ -17,4 +17,8 @@ The Docker installation is for development and testing environments only. Since there is only one node and a single Docker container, if the node goes down, there is no copy of the etcd data available on other nodes and you will lose all the data of your Rancher server. -When the Rancher server is installed with Docker, it cannot be migrated to a Kubernetes cluster for a production environment. +The ability to migrate Rancher to a high-availability cluster depends on the Rancher version: + +- For Rancher v2.0-v2.4, there was no migration path from a Docker installation to a high-availability installation. Therefore, if you are using Rancher prior to v2.5, you may want to use a Kubernetes installation from the start. + +- For Rancher v2.5+, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{}}/rancher/v2.x/en/backups/v2.5/migrating-rancher/) \ No newline at end of file diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md index ad3e85da78d..0e0390de878 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md @@ -11,11 +11,11 @@ This section describes how to install a Kubernetes cluster according to our [bes For Rancher prior to v2.4, Rancher should be installed on an [RKE]({{}}/rke/latest/en/) (Rancher Kubernetes Engine) Kubernetes cluster. RKE is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers. -As of Rancher v2.4, the Rancher management server can be installed on either an RKE cluster or a K3s Kubernetes cluster. K3s is also a fully certified Kubernetes distribution released by Rancher, but is newer than RKE. We recommend installing Rancher on K3s because K3s is easier to use, and more lightweight, with a binary size of less than 100 MB. Note: After Rancher is installed on an RKE cluster, there is no migration path to a K3s setup at this time. +In Rancher v2.4, the Rancher management server can be installed on either an RKE cluster or a K3s Kubernetes cluster. K3s is also a fully certified Kubernetes distribution released by Rancher, but is newer than RKE. We recommend installing Rancher on K3s because K3s is easier to use, and more lightweight, with a binary size of less than 100 MB. The Rancher management server can only be run on a Kubernetes cluster in an infrastructure provider where Kubernetes is installed using RKE or K3s. Use of Rancher on hosted Kubernetes providers, such as EKS, is not supported. Note: After Rancher is installed on an RKE cluster, there is no migration path to a K3s setup at this time. -The Rancher management server can only be run on Kubernetes cluster in an infrastructure provider where Kubernetes is installed using RKE or K3s. Use of Rancher on hosted Kubernetes providers, such as EKS, is not supported. +As of Rancher v2.5, Rancher can be installed on any Kubernetes cluster, including hosted Kubernetes providers. -The steps to set up an air-gapped Kubernetes cluster depend on whether RKE or K3s is used to install Kubernetes. +The steps to set up an air-gapped Kubernetes cluster on RKE or K3s are shown below. {{% tabs %}} {{% tab "K3s" %}} diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md index 0c6d0980e56..7465fe5a2cd 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/prepare-nodes/_index.md @@ -150,9 +150,9 @@ If you need help with creating a private registry, please refer to the [official {{% tab "Docker" %}} > The Docker installation is for Rancher users that are wanting to test out Rancher. Since there is only one node and a single Docker container, if the node goes down, you will lose all the data of your Rancher server. > -> For running Rancher in production, we recommend installing Rancher on a high-availability Kubernetes cluster. There is no upgrade path to transition your Docker installation to a Kubernetes Installation. -> -> If you want to save resources by using a single node in the short term, while preserving a migration path to a high-availability installation, we recommend installing Rancher on a single-node Kubernetes cluster. +> For Rancher v2.0-v2.4, there is no migration path from a Docker installation to a high-availability installation. Therefore, you may want to use a Kubernetes installation from the start. + +> For Rancher v2.5+, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{}}/rancher/v2.x/en/backups/v2.5/migrating-rancher/) ### 1. Set up a Linux Node diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node-docker/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node-docker/_index.md index 723d7819ff4..80ea46df0ec 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node-docker/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node-docker/_index.md @@ -8,8 +8,6 @@ aliases: - /rancher/v2.x/en/installation/other-installation-methods/single-node --- -> The Docker installation is for development and testing environments only. When the Rancher server is installed with Docker, it cannot be migrated to a Kubernetes cluster for a production environment. - Rancher can be installed by running a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container. @@ -17,6 +15,12 @@ In this installation scenario, you'll install Docker on a single Linux host, and > **Want to use an external load balancer?** > See [Docker Install with an External Load Balancer]({{}}/rancher/v2.x/en/installation/options/single-node-install-external-lb) instead. +A Docker installation of Rancher is recommended only for development and testing purposes. The ability to migrate Rancher to a high-availability cluster depends on the Rancher version: + +- For Rancher v2.0-v2.4, there was no migration path from a Docker installation to a high-availability installation. Therefore, if you are using Rancher prior to v2.5, you may want to use a Kubernetes installation from the start. + +- For Rancher v2.5+, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{}}/rancher/v2.x/en/backups/v2.5/migrating-rancher/) + ### Privileged Access for Rancher v2.5+ When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option. diff --git a/content/rancher/v2.x/en/overview/architecture/_index.md b/content/rancher/v2.x/en/overview/architecture/_index.md index 8c05752602d..20c2547ddea 100644 --- a/content/rancher/v2.x/en/overview/architecture/_index.md +++ b/content/rancher/v2.x/en/overview/architecture/_index.md @@ -41,7 +41,13 @@ The diagram below shows how users can manipulate both [Rancher-launched Kubernet You can install Rancher on a single node, or on a high-availability Kubernetes cluster. -A high-availability Kubernetes installation is recommended for production. A Docker installation may be used for development and testing purposes, but there is no migration path from a single-node to a high-availability installation. Therefore, you may want to use a Kubernetes installation from the start. +A high-availability Kubernetes installation is recommended for production. + +A Docker installation of Rancher is recommended only for development and testing purposes. The ability to migrate Rancher to a high-availability cluster depends on the Rancher version: + +- For Rancher v2.0-v2.4, there was no migration path from a Docker installation to a high-availability installation. Therefore, if you are using Rancher prior to v2.5, you may want to use a Kubernetes installation from the start. + +- For Rancher v2.5+, the Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster.]({{}}/rancher/v2.x/en/backups/v2.5/migrating-rancher/) The Rancher server, regardless of the installation method, should always run on nodes that are separate from the downstream user clusters that it manages. If Rancher is installed on a high-availability Kubernetes cluster, it should run on a separate cluster from the cluster(s) it manages. From e3b44bf94ca0a6371900fafa928a3946b45288af Mon Sep 17 00:00:00 2001 From: Bastian Hofmann Date: Wed, 9 Dec 2020 15:28:16 +0100 Subject: [PATCH 07/12] Add link to S3 credentials example on backup storage configuration page Signed-off-by: Bastian Hofmann --- .../en/backups/v2.5/configuration/storage-config/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/backups/v2.5/configuration/storage-config/_index.md b/content/rancher/v2.x/en/backups/v2.5/configuration/storage-config/_index.md index 77a7516d946..3f08a943c93 100644 --- a/content/rancher/v2.x/en/backups/v2.5/configuration/storage-config/_index.md +++ b/content/rancher/v2.x/en/backups/v2.5/configuration/storage-config/_index.md @@ -28,7 +28,7 @@ You can choose to not have any operator-level storage location configured. If yo | Parameter | Description | | -------------- | -------------- | -| Credential Secret | Choose the credentials for S3 from your secrets in Rancher. | +| Credential Secret | Choose the credentials for S3 from your secrets in Rancher. [Example]({{}}/rancher/v2.x/en/backups/v2.5/examples/#example-credential-secret-for-storing-backups-in-s3). | | Bucket Name | Enter the name of the [S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html) where the backups will be stored. Default: `rancherbackups`. | | Region | The [AWS region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) where the S3 bucket is located. | | Folder | The [folder in the S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/using-folders.html) where the backups will be stored. | @@ -111,4 +111,4 @@ nodeSelector: {} tolerations: [] affinity: {} -``` \ No newline at end of file +``` From bd5d5c1a1aa70bdc9a7ce73d145a3e397ebea642 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Wed, 9 Dec 2020 13:12:18 -0700 Subject: [PATCH 08/12] Update notifier page for Rancher v2.0-2.4 --- .../v2.0.x-v2.4.x/notifiers/_index.md | 170 ++++++++++++------ 1 file changed, 119 insertions(+), 51 deletions(-) diff --git a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md index a4bb73060ce..b7d4e45e75a 100644 --- a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md +++ b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md @@ -17,76 +17,144 @@ Rancher integrates with a variety of popular IT services, including: - **Email**: Choose email recipients for alert notifications. - **PagerDuty**: Route notifications to staff by phone, SMS, or personal email. - **WebHooks**: Update a webpage with alert notifications. -- **WeChat**: Send alert notifications to your Enterprise WeChat contacts. +- **WeChat**: (Available as of v2.2.0) Send alert notifications to your Enterprise WeChat contacts. +- **DingTalk**: (Available as of v2.4.6) Send alert notifications to DingChat using a webhook. +- **Microsoft Teams**: (Available as of v2.4.6) Send alert notifications to Teams using a webhook. This section covers the following topics: - [Roles-based access control for notifiers](#roles-based-access-control-for-notifiers) - [Adding notifiers](#adding-notifiers) +- [Configuration](#configuration) - [Managing notifiers](#managing-notifiers) - [Example payload for a webhook alert notifier](#example-payload-for-a-webhook-alert-notifier) -### Roles-based Access Control for Notifiers +# Roles-based Access Control for Notifiers Notifiers are configured at the cluster level. This model ensures that only cluster owners need to configure notifiers, leaving project owners to simply configure alerts in the scope of their projects. You don't need to dispense privileges like SMTP server access or cloud account access. -### Adding Notifiers +# Adding Notifiers Set up a notifier so that you can begin configuring and sending alerts. 1. From the **Global View**, open the cluster that you want to add a notifier. - 1. From the main menu, select **Tools > Notifiers**. Then click **Add Notifier**. - -1. Select the service you want to use as your notifier, and then fill out the form. -{{% accordion id="slack" label="Slack" %}} -1. Enter a **Name** for the notifier. -1. From Slack, create a webhook. For instructions, see the [Slack Documentation](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack). -1. From Rancher, enter your Slack webhook **URL**. -1. Enter the name of the channel that you want to send alert notifications in the following format: `#`. - - Both public and private channels are supported. -1. Click **Test**. If the test is successful, the Slack channel you're configuring for the notifier outputs `Slack setting validated`. -{{% /accordion %}} -{{% accordion id="email" label="Email" %}} -1. Enter a **Name** for the notifier. -1. In the **Sender** field, enter an email address available on your mail server that you want to send the notification. -1. In the **Host** field, enter the IP address or hostname for your SMTP server. Example: `smtp.email.com` -1. In the **Port** field, enter the port used for email. Typically, TLS uses `587` and SSL uses `465`. If you're using TLS, make sure **Use TLS** is selected. -1. Enter a **Username** and **Password** that authenticate with the SMTP server. -1. In the **Default Recipient** field, enter the email address that you want to receive the notification. -1. Click **Test**. If the test is successful, Rancher prints `settings validated` and you receive a test notification email. -{{% /accordion %}} -{{% accordion id="pagerduty" label="PagerDuty" %}} -1. Enter a **Name** for the notifier. -1. From PagerDuty, create a Prometheus integration. For instructions, see the [PagerDuty Documentation](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/). -1. From PagerDuty, copy the integration's **Integration Key**. -1. From Rancher, enter the key in the **Service Key** field. -1. Click **Test**. If the test is successful, your PagerDuty endpoint outputs `PagerDuty setting validated`. -{{% /accordion %}} -{{% accordion id="webhook" label="WebHook" %}} -1. Enter a **Name** for the notifier. -1. Using the app of your choice, create a webhook URL. -1. Enter your webhook **URL**. -1. Click **Test**. If the test is successful, the URL you're configuring as a notifier outputs `Webhook setting validated`. -{{% /accordion %}} -{{% accordion id="WeChat" label="WeChat" %}} - -_Available as of v2.2.0_ - -1. Enter a **Name** for the notifier. -1. In the **Corporation ID** field, enter the "EnterpriseID" of your corporation, you could get it from [Profile page](https://work.weixin.qq.com/wework_admin/frame#profile). -1. From Enterprise WeChat, create an application in the [Application page](https://work.weixin.qq.com/wework_admin/frame#apps), and then enter the "AgentId" and "Secret" of this application to the **Application Agent ID** and **Application Secret** fields. -1. Select the **Recipient Type** and then enter a corresponding id to **Default Recipient** field, for example, the party id, tag id or user account that you want to receive the notification. You could get contact information from [Contacts page](https://work.weixin.qq.com/wework_admin/frame#contacts). -{{% /accordion %}} - -1. _Available as of v2.3.0_ - Select **Enable** for **Send Resolved Alerts** if you wish to notify about resolved alerts. +1. Select the service you want to use as your notifier, and then fill out the form. For help filling out the form, refer to the configuration section below. +1. Click **Test.** You should receive a notification confirming that the notifier is configured correctly. 1. Click **Add** to complete adding the notifier. **Result:** Your notifier is added to Rancher. +# Configuration -### Managing Notifiers +- [Slack](#slack) +- [Email](#email) +- [PagerDuty](#pagerduty) +- [Webhook](#webhook) +- [WeChat](#wechat) +- [DingTalk](#dingtalk) +- [MicrosoftTeams](#microsoftteams) + +### Slack + +| Field | Explanation | +|----------|----------------------| +| Name | Enter a **Name** for the notifier. | +| URL | From Slack, create a webhook. For instructions, see the [Slack Documentation](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack). Then enter the Slack webhook URL. | +| Default Channel | Enter the name of the channel that you want to send alert notifications in the following format: `#`. Both public and private channels are supported. | +| Proxy URL | Proxy for the Slack webhook. | +| Send Resolved Alerts | _Available as of v2.3.0_ When enabled, you will receive resolved alerts, such as an alert about high CPU usage after the CPU has returned to normal levels. | + +**Validation:** Click **Test**. If the test is successful, the Slack channel you're configuring for the notifier outputs **Slack setting validated.** + +### Email + +| Field | Explanation | +|----------|----------------------| +| Name | Enter a **Name** for the notifier. | +| Default Recipient Address | Enter the email address that you want to receive the notification. | +| Send Resolved Alerts | _Available as of v2.3.0_ When enabled, you will receive resolved alerts, such as an alert about high CPU usage after the CPU has returned to normal levels. | + +SMTP Server Configuration: + +| Field | Explanation | +|----------|----------------------| +| Sender | Enter an email address available on your mail server that you want to send the notification. | +| Host | Enter the IP address or hostname for your SMTP server. Example: `smtp.email.com` | +| Port | In the **Port** field, enter the port used for email. Typically, TLS uses `587` and SSL uses `465`. | +| Use TLS | If you're using TLS, make sure **Use TLS** is selected. | +| Username | Username to authenticate with the SMTP server. | +| Password | Password to authenticate with the SMTP server. | + +**Validation:** Click **Test**. If the test is successful, Rancher prints **settings validated** and you receive a test notification email. + +### PagerDuty + +| Field | Explanation | +|----------|----------------------| +| Name | Enter a **Name** for the notifier. | +| Default Integration Key | From PagerDuty, create a Prometheus integration. For instructions, see the [PagerDuty Documentation](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/). Then enter the integration key. +| Service Key | The same as the integration key. For instructions on creating a Prometheus integration, see the [PagerDuty Documentation](https://www.pagerduty.com/docs/guides/prometheus-integration-guide/). Then enter the integration key. | +| Send Resolved Alerts | _Available as of v2.3.0_ When enabled, you will receive resolved alerts, such as an alert about high CPU usage after the CPU has returned to normal levels. | + +**Validation:** Click **Test**. If the test is successful, your PagerDuty endpoint outputs **PagerDuty setting validated.** + +### Webhook + +| Field | Explanation | +|----------|----------------------| +| Name | Enter a **Name** for the notifier. | +| URL | Using the app of your choice, create a webhook URL. | +| Proxy URL | Proxy for the webhook. | +| Send Resolved Alerts | _Available as of v2.3.0_ When enabled, you will receive resolved alerts, such as an alert about high CPU usage after the CPU has returned to normal levels. | + +**Validation:** Click **Test**. If the test is successful, the URL you're configuring as a notifier outputs **Webhook setting validated.** + +### WeChat + +_Available as of v2.2.0_ + +| Field | Explanation | +|----------|----------------------| +| Name | Enter a **Name** for the notifier. | +| Corporation ID | Enter the "EnterpriseID" of your corporation. You can get it fro the [Profile page](https://work.weixin.qq.com/wework_admin/frame#profile). | +| Application Agent ID | From Enterprise WeChat, create an application in the [Application page](https://work.weixin.qq.com/wework_admin/frame#apps), and then enter the "AgentId" of this application. You will also need to enter the application secret. | +| Application Secret | The secret that corresponds to the Application Agent ID. | +| Recipient Type | Party, tag, or user. | +| Default Recipient | The default recipient ID should correspond to the recipient type. It should be the party ID, tag ID or user account that you want to receive the notification. You could get contact information from [Contacts page](https://work.weixin.qq.com/wework_admin/frame#contacts). | +| Proxy URL | If you are using a proxy, enter the proxy URL. | +| Send Resolved Alerts | _Available as of v2.3.0_ When enabled, you will receive resolved alerts, such as an alert about high CPU usage after the CPU has returned to normal levels. | + +**Validation:** Click **Test.** If the test is successful, you should receive an alert message. + +### DingTalk + +_Available as of v2.4.6_ + +| Field | Explanation | +|----------|----------------------| +| Name | Enter a **Name** for the notifier. | +| Webhook URL | Enter the DingTalk webhook URL. For help setting up the webhook, refer to the [DingTalk documentation.](https://www.alibabacloud.com/help/doc-detail/52872.htm) | +| Secret | Optional: Enter a secret for the DingTalk webhook. | +| Proxy URL | Optional: Enter a proxy for the DingTalk webhook. | +| Send Resolved Alerts | When enabled, you will receive resolved alerts, such as an alert about high CPU usage after the CPU has returned to normal levels. | + +**Validation:** Click **Test.** If the test is successful, the DingTalk notifier output is **DingTalk setting validated.** + +### Microsoft Teams + +_Available as of v2.4.6_ + +| Field | Explanation | +|----------|----------------------| +| Name | Enter a **Name** for the notifier. | +| Webhook URL | Enter the Microsoft Teams webhook URL. For help setting up the webhook, refer to the [Teams Documentation.](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) | +| Proxy URL | Optional: Enter a proxy for the Teams webhook. | +| Send Resolved Alerts | When enabled, you will receive resolved alerts, such as an alert about high CPU usage after the CPU has returned to normal levels. | + +**Validation:** Click **Test.** If the test is successful, the Teams notifier output is **MicrosoftTeams setting validated.** + +# Managing Notifiers After you set up notifiers, you can manage them. From the **Global** view, open the cluster that you want to manage your notifiers. Select **Tools > Notifiers**. You can: @@ -94,7 +162,7 @@ After you set up notifiers, you can manage them. From the **Global** view, open - **Clone** them, to quickly setup slightly different notifiers. - **Delete** them when they're no longer necessary. -### Example Payload for a Webhook Alert Notifier +# Example Payload for a Webhook Alert Notifier ```json { @@ -130,7 +198,7 @@ After you set up notifiers, you can manage them. From the **Global** view, open } } ``` -### What's Next? +# What's Next? After creating a notifier, set up alerts to receive notifications of Rancher system events. From 86358a91c543105349103719aacf5693450a5573 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Wed, 9 Dec 2020 13:14:39 -0700 Subject: [PATCH 09/12] Fix typo --- .../en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md index b7d4e45e75a..64598db73ff 100644 --- a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md +++ b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md @@ -18,7 +18,7 @@ Rancher integrates with a variety of popular IT services, including: - **PagerDuty**: Route notifications to staff by phone, SMS, or personal email. - **WebHooks**: Update a webpage with alert notifications. - **WeChat**: (Available as of v2.2.0) Send alert notifications to your Enterprise WeChat contacts. -- **DingTalk**: (Available as of v2.4.6) Send alert notifications to DingChat using a webhook. +- **DingTalk**: (Available as of v2.4.6) Send alert notifications to DingTalk using a webhook. - **Microsoft Teams**: (Available as of v2.4.6) Send alert notifications to Teams using a webhook. This section covers the following topics: From fe455ee06dcbc99d1ca715f062412fbf6001db74 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Wed, 9 Dec 2020 14:30:48 -0700 Subject: [PATCH 10/12] Fix internal link --- .../en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md index 64598db73ff..a9d4d80ad39 100644 --- a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md +++ b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/_index.md @@ -53,7 +53,7 @@ Set up a notifier so that you can begin configuring and sending alerts. - [Webhook](#webhook) - [WeChat](#wechat) - [DingTalk](#dingtalk) -- [MicrosoftTeams](#microsoftteams) +- [Microsoft Teams](#microsoft-teams) ### Slack From 48804c58c482016e1d0833bca37be6f8322401b8 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Wed, 9 Dec 2020 21:17:40 -0700 Subject: [PATCH 11/12] Document advanced config options for Rancher v2.5 monitoring --- .../cluster-monitoring/prometheus/_index.md | 53 +++++++++++++++++-- 1 file changed, 48 insertions(+), 5 deletions(-) diff --git a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/prometheus/_index.md b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/prometheus/_index.md index f817e8603ca..b265606bc01 100644 --- a/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/prometheus/_index.md +++ b/content/rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/prometheus/_index.md @@ -9,9 +9,16 @@ aliases: _Available as of v2.2.0_ - While configuring monitoring at either the [cluster level]({{}}/rancher/v2.x/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/#enabling-cluster-monitoring) or [project level]({{}}/rancher/v2.x/en/project-admin/tools/monitoring/#enabling-project-monitoring), there are multiple options that can be configured. +- [Basic Configuration](#basic-configuration) +- [Advanced Options](#advanced-options) +- [Node Exporter](#node-exporter) +- [Persistent Storage](#persistent-storage) +- [Remote Storage](#remote-storage) + +# Basic Configuration + Option | Description -------|------------- Data Retention | How long your Prometheus instance retains monitoring data scraped from Rancher objects before it's purged. @@ -24,9 +31,45 @@ Prometheus [CPU Reservation](https://kubernetes.io/docs/concepts/configuration/m Prometheus [Memory Limit](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory) | Memory resource limit for the Prometheus pod. Prometheus [Memory Reservation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory) | Memory resource requests for the Prometheus pod. Selector | Ability to select the nodes in which Prometheus and Grafana pods are deployed to. To use this option, the nodes must have labels. -Advanced Options | Since monitoring is an [application](https://github.com/rancher/system-charts/tree/dev/charts/rancher-monitoring) from the [Rancher catalog]({{}}/rancher/v2.x/en/catalog/), it can be [configured like any other catalog application]({{}}/rancher/v2.x/en/catalog/catalog-config/). _Warning: Any modification to the application without understanding the entire application can lead to catastrophic errors._ -## Node Exporter +# Advanced Options + +Since monitoring is an [application](https://github.com/rancher/system-charts/tree/dev/charts/rancher-monitoring) from the [Rancher catalog]({{}}/rancher/v2.x/en/catalog/), it can be configured like any other catalog application, by passing in values to Helm. + +> **Warning:** Any modification to the application without understanding the entire application can lead to catastrophic errors. + +### Prometheus RemoteRead and RemoteWrite + +_Available as of v2.4.0_ + +Prometheus RemoteRead and RemoteWrite can be configured as custom answers in the **Advanced Options** section. + +For more information on remote endpoints and storage, refer to the [Prometheus documentation.](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage) + +The Prometheus operator documentation contains the full [RemoteReadSpec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotereadspec) and [RemoteWriteSpec.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotewritespec) + +An example configuration would be: + +| Variable | Value | +|--------------|------------| +| `prometheus.remoteWrite[0].url` | `http://mytarget.com` | + +### LivenessProbe and ReadinessProbe + +_Available as of v2.4.0_ + +Prometheus LivenessProbe and ReadinessProbe can be configured as custom answers in the **Advanced Options** section. + +The Kubernetes probe spec is [here.](https://v1-17.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#probe-v1-core) + +Some example key-value pairs are: + +| Variable | Value | +|--------------|------------| +| `prometheus.livenessProbe.timeoutSeconds` | 60 | +| `prometheus.readinessProbe.timeoutSeconds` | 60 | + +# Node Exporter The [node exporter](https://github.com/prometheus/node_exporter/blob/master/README.md) is a popular open source exporter, which exposes the metrics for hardware and \*NIX kernels OS. It is designed to monitor the host system. However, there are still issues with namespaces when running it in a container, mostly around filesystem mount spaces. In order to monitor actual network metrics for the container network, the node exporter must be deployed with the `hostNetwork` mode. @@ -34,7 +77,7 @@ When configuring Prometheus and enabling the node exporter, enter a host port in >**Warning:** In order for Prometheus to collect the metrics of the node exporter, after enabling cluster monitoring, you must open the Node Exporter Host Port in the host firewall rules to allow intranet access. By default, `9796` is used as that host port. -## Persistent Storage +# Persistent Storage >**Prerequisite:** Configure one or more [storage class]({{}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/#adding-storage-classes) to use as [persistent storage]({{}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/) for your Prometheus or Grafana pod. @@ -42,7 +85,7 @@ By default, when you enable Prometheus for either a cluster or project, all moni When enabling persistent storage for Prometheus or Grafana, specify the size of the persistent volume and select the [storage class]({{}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/#storage-classes). -## Remote Storage +# Remote Storage >**Prerequisite:** Need a remote storage endpoint to be available. The possible list of integrations is available [here](https://prometheus.io/docs/operating/integrations/) From 8226554bcafda84d59535233e7645be1b7ec3a33 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Thu, 10 Dec 2020 12:45:33 -0700 Subject: [PATCH 12/12] Correction to RKE docs about vSphere cloud provider --- .../en/config-options/cloud-providers/vsphere/_index.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md b/content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md index d73d2169d74..dea75f8121c 100644 --- a/content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md +++ b/content/rke/latest/en/config-options/cloud-providers/vsphere/_index.md @@ -3,13 +3,11 @@ title: vSphere Cloud Provider weight: 254 --- -In order to provision Kubernetes clusters in vSphere with the RKE CLI, you must enable the vSphere cloud provider. - -The vSphere cloud provider must also be enabled in order to provision clusters with Rancher, which uses RKE as a library when provisioning [RKE clusters.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) +This section describes how to enable the vSphere cloud provider. You will need to use the `cloud_provider` directive in the cluster YAML file. The [vSphere Cloud Provider](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) interacts with VMware infrastructure (vCenter or standalone ESXi server) to provision and manage storage for persistent volumes in a Kubernetes cluster. -This section describes how to enable the vSphere cloud provider. You will need to use the `cloud_provider` directive in the cluster YAML file. +When provisioning Kubernetes using RKE CLI or using [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) in Rancher, the vSphere Cloud Provider can be enabled by configuring the `cloud_provider` directive in the cluster YAML file. ### Related Links