diff --git a/content/rancher/v2.x/en/backups/v2.5/back-up-rancher/_index.md b/content/rancher/v2.x/en/backups/v2.5/back-up-rancher/_index.md index 0b1f5b26cfe..061cbcdf8e2 100644 --- a/content/rancher/v2.x/en/backups/v2.5/back-up-rancher/_index.md +++ b/content/rancher/v2.x/en/backups/v2.5/back-up-rancher/_index.md @@ -28,7 +28,7 @@ To perform a backup, a custom resource of type Backup must be created. 1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.** 1. Click **Backup.** -1. Create the Backup with the form, or with YAML editor. +1. Create the Backup with the form, or with the YAML editor. 1. For configuring the Backup details using the form, click **Create** and refer to the [configuration reference](../configuration/backup-config) and to the [examples.](../examples/#backup) 1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Backup YAML. This example Backup custom resource would create encrypted recurring backups in S3: diff --git a/content/rancher/v2.x/en/best-practices/v2.0-v2.4/containers/_index.md b/content/rancher/v2.x/en/best-practices/v2.0-v2.4/containers/_index.md index 6a66698e266..f75f0492322 100644 --- a/content/rancher/v2.x/en/best-practices/v2.0-v2.4/containers/_index.md +++ b/content/rancher/v2.x/en/best-practices/v2.0-v2.4/containers/_index.md @@ -5,7 +5,7 @@ aliases: - /rancher/v2.x/en/best-practices/containers --- -Running well built containers can greatly impact the overall performance and security of your environment. +Running well-built containers can greatly impact the overall performance and security of your environment. Below are a few tips for setting up your containers. diff --git a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/_index.md b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/_index.md index cea49be14c0..9d3d86d1fc6 100644 --- a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/_index.md +++ b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/_index.md @@ -14,8 +14,8 @@ Configuring sensible monitoring and alerting rules is vital for running any prod ### Tips for Setting Up Containers -Running well built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](./containers) for tips. +Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](./containers) for tips. ### Best Practices for Rancher Managed vSphere Clusters -This [guide](./managed-vsphere) outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware. \ No newline at end of file +This [guide](./managed-vsphere) outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware. diff --git a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/containers/_index.md b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/containers/_index.md index 6a66698e266..f75f0492322 100644 --- a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/containers/_index.md +++ b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/containers/_index.md @@ -5,7 +5,7 @@ aliases: - /rancher/v2.x/en/best-practices/containers --- -Running well built containers can greatly impact the overall performance and security of your environment. +Running well-built containers can greatly impact the overall performance and security of your environment. Below are a few tips for setting up your containers. diff --git a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md index cdb24711323..72f74e3f477 100644 --- a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md +++ b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md @@ -25,7 +25,7 @@ When installing the integrated monitoring stack, Rancher allows to configure sev ### Storage and Data Retention -The amount of storage needed for Prometheus directly correlates to the amount of time series and labels that you store and the data retention you have configured. It is important to note that Prometheus is not meant to be used as a long-term metrics storage. Data retention time is usually only a couple of days and not weeks or months. The reason for this is, that Prometheus does not perform any aggregation on its stored metrics. This is great because aggregation can dilute data, but it also means that the needed storage grows linearly over time without retention. +The amount of storage needed for Prometheus directly correlates to the amount of time series and labels that you store and the data retention you have configured. It is important to note that Prometheus is not meant to be used as a long-term metrics storage. Data retention time is usually only a couple of days and not weeks or months. The reason for this is that Prometheus does not perform any aggregation on its stored metrics. This is great because aggregation can dilute data, but it also means that the needed storage grows linearly over time without retention. One way to calculate the necessary storage is to look at the average size of a storage chunk in Prometheus with this query @@ -67,7 +67,7 @@ In order to store some, or all metrics for a long time, you can leverage Prometh While the integrated Rancher Monitoring already scrapes system metrics from a cluster's nodes and system components, the custom workloads that you deploy on Kubernetes should also be scraped for data. For that you can configure Prometheus to do an HTTP request to an endpoint of your applications in a certain interval. These endpoints should then return their metrics in a Prometheus format. -In general, you want to scrape data from all the workloads running in your cluster so that you can use them for alerts or debugging issues. Oftentimes, you recognize, that you need some data only when you actually need the metrics during an incident. It is good, if it is already scraped and stored. Since Prometheus is only meant to be a short-term metrics storage, scraping and keeping lots of data is usually not that expensive. If you are using a long-term storage solution with Prometheus, you can then still decide which data you are actually persisting and keeping there. +In general, you want to scrape data from all the workloads running in your cluster so that you can use them for alerts or debugging issues. Often, you recognize that you need some data only when you actually need the metrics during an incident. It is good, if it is already scraped and stored. Since Prometheus is only meant to be a short-term metrics storage, scraping and keeping lots of data is usually not that expensive. If you are using a long-term storage solution with Prometheus, you can then still decide which data you are actually persisting and keeping there. ### About Prometheus Exporters @@ -75,7 +75,7 @@ A lot of 3rd party workloads like databases, queues or web-servers either alread ### Prometheus support in Programming Languages and Frameworks -To get your own custom application metrics into Prometheus, you have to collect and expose these metrics directly from your applications code. Fortunately, there are already libraries and integrations available to help with this for most popular programming languages and frameworks. One example for this is the Prometheus support in the [Spring Framework](https://docs.spring.io/spring-metrics/docs/current/public/prometheus). +To get your own custom application metrics into Prometheus, you have to collect and expose these metrics directly from your application's code. Fortunately, there are already libraries and integrations available to help with this for most popular programming languages and frameworks. One example for this is the Prometheus support in the [Spring Framework](https://docs.spring.io/spring-metrics/docs/current/public/prometheus). ### ServiceMonitors and PodMonitors diff --git a/content/rancher/v2.x/en/cis-scans/v2.5/_index.md b/content/rancher/v2.x/en/cis-scans/v2.5/_index.md index affe72c2015..cef5119a4df 100644 --- a/content/rancher/v2.x/en/cis-scans/v2.5/_index.md +++ b/content/rancher/v2.x/en/cis-scans/v2.5/_index.md @@ -90,7 +90,7 @@ The `rancher-cis-benchmark` supports the CIS 1.5 Benchmark version. # About the CIS Benchmark -The Center for Internet Security is a 501(c)(3) nonprofit organization, formed in October 2000, with a mission is to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace". The organization is headquartered in East Greenbush, New York, with members including large corporations, government agencies, and academic institutions. +The Center for Internet Security is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace". The organization is headquartered in East Greenbush, New York, with members including large corporations, government agencies, and academic institutions. CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team. diff --git a/content/rancher/v2.x/en/cluster-provisioning/_index.md b/content/rancher/v2.x/en/cluster-provisioning/_index.md index 9ec28ddf483..1fc0f8509d3 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/_index.md @@ -41,7 +41,7 @@ For more information, refer to the section on [hosted Kubernetes clusters.]({{}}/rke/latest/en/)as a library when provisioning Kubernetes on your own nodes. RKE is Rancher’s own lightweight Kubernetes installer. +Rancher uses the [Rancher Kubernetes Engine (RKE)]({{}}/rke/latest/en/) as a library when provisioning Kubernetes on your own nodes. RKE is Rancher’s own lightweight Kubernetes installer. In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform. @@ -89,7 +89,7 @@ For more information, refer to the section on [importing existing clusters.]({{< _Available as of Rancher v2.4.0_ -[K3s]({{}}/k3s/latest/en/) is lightweight, fully compliant Kubernetes distribution. K3s Kubernetes clusters can now be imported into Rancher. +[K3s]({{}}/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution. K3s Kubernetes clusters can now be imported into Rancher. When a K3s cluster is imported, Rancher will recognize it as K3s, and the Rancher UI will expose the following features in addition to the functionality for other imported clusters: @@ -100,12 +100,12 @@ For more information, refer to the section on [imported K3s clusters.]({{}}/rancher/v2.x/en/cluster-admin/pod-security-policy/) | ✓ | | | | [Running Security Scans]({{}}/rancher/v2.x/en/security/security-scan/) | ✓ | | | -/* Cluster configuration options can't be edited for imported clusters, except for [K3s clusters.]({{}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters) +\* Cluster configuration options can't be edited for imported clusters, except for [K3s clusters.]({{}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/#additional-features-for-imported-k3s-clusters) diff --git a/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md index 2c8f6e10e33..54a861f240c 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md @@ -90,7 +90,7 @@ By default, GKE users are not given this privilege, so you will need to run the # Imported K3s Clusters -You can now import a K3s Kubernetes cluster into Rancher. [K3s]({{}}/k3s/latest/en/) is lightweight, fully compliant Kubernetes distribution. You can also upgrade Kubernetes by editing the K3s cluster in the Rancher UI. +You can now import a K3s Kubernetes cluster into Rancher. [K3s]({{}}/k3s/latest/en/) is a lightweight, fully compliant Kubernetes distribution. You can also upgrade Kubernetes by editing the K3s cluster in the Rancher UI. ### Additional Features for Imported K3s Clusters diff --git a/content/rancher/v2.x/en/cluster-provisioning/registered-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/registered-clusters/_index.md index addf46510e2..6f24cf77651 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/registered-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/registered-clusters/_index.md @@ -94,7 +94,7 @@ After registering a cluster, the cluster owner can: ### Additional Features for Registered K3s Clusters -[K3s]({{}}/k3s/latest/en/) is lightweight, fully compliant Kubernetes distribution. +[K3s]({{}}/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: diff --git a/content/rancher/v2.x/en/istio/v2.5/setup/enable-istio-in-cluster/_index.md b/content/rancher/v2.x/en/istio/v2.5/setup/enable-istio-in-cluster/_index.md index 0270e0fb722..8a79876fed9 100644 --- a/content/rancher/v2.x/en/istio/v2.5/setup/enable-istio-in-cluster/_index.md +++ b/content/rancher/v2.x/en/istio/v2.5/setup/enable-istio-in-cluster/_index.md @@ -30,7 +30,7 @@ Automatic sidecar injection is disabled by default. To enable this, set the `sid - The Project Network Isolation option is enabled. - You install the Istio Ingress module -The Istio Ingress Gateway pod won't be able to redirect ingress traffic to the workloads by default. This is because all the namespaces will be innacessible from the namespace where Istio is installed. You have two options. +The Istio Ingress Gateway pod won't be able to redirect ingress traffic to the workloads by default. This is because all the namespaces will be inaccessible from the namespace where Istio is installed. You have two options. The first option is to add a new Network Policy in each of the namespaces where you intend to have ingress controlled by Istio. Your policy should include the following lines: @@ -42,7 +42,7 @@ The first option is to add a new Network Policy in each of the namespaces where ``` The second option is to move the `istio-system` namespace to the `system` project, which by default is excluded from the network isolation -## Additonal Config Options +## Additional Config Options ### Overlay File @@ -58,7 +58,7 @@ The Monitoring app sets `prometheus.prometheusSpec.ignoreNamespaceSelectors=fals If you would like to limit prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources. -**Set ingnoreNamspaceSelectors to True** +**Set ignoreNamespaceSelectors to True** This limits monitoring to specific namespaces. @@ -82,7 +82,7 @@ This option allows you to define which specific services or pods you would like >Usability tradeoff is that you have to create the service monitor / pod monitor per namespace since you cannot monitor across namespaces. - **Pre Requisite:** define a ServiceMonitor or PodMonitor for ``. Example ServiceMonitor is provided below. + **Prerequisite:** define a ServiceMonitor or PodMonitor for ``. An example ServiceMonitor is provided below. 1. From the **Cluster Explorer**, open the kubectl shell 1. Run `kubectl create -f .yaml` if the file is stored locally in your cluster. @@ -90,7 +90,7 @@ This option allows you to define which specific services or pods you would like 1. If starting a new install, **Click** the **rancher-monitoring** chart and scroll down to **Preview Yaml**. 1. Run `kubectl label namespace istio-injection=enabled` to enable the envoy sidecar injection -**Result:** `` can be scraped by prometheus. +**Result:** `` can be scraped by prometheus. **Example Service Monitor for Istio Proxies** @@ -129,11 +129,11 @@ spec: -**Option 3: Set ingnoreNamspaceSelectors to False** +**Option 3: Set ignoreNamespaceSelectors to False** -This enables monitoring accross namespaces by giving prometheus additional scrape configurations. +This enables monitoring across namespaces by giving prometheus additional scrape configurations. - >Usability tradeoff is that all of prometheus' `additionalScrapeConfigs` are maintained in a single Secret. This could make upgrading difficult if monitoring is already deployed with additionalScrapeConfigs prior to installing Istio. + >The usability tradeoff is that all of prometheus' `additionalScrapeConfigs` are maintained in a single Secret. This could make upgrading difficult if monitoring is already deployed with additionalScrapeConfigs prior to installing Istio. 1. If starting a new install, **Click** the **rancher-monitoring** chart, then in **Chart Options** click **Edit as Yaml**. 1. If updating an existing installation, click on **Upgrade**, then in **Chart Options** click **Edit as Yaml**. diff --git a/content/rancher/v2.x/en/security/_index.md b/content/rancher/v2.x/en/security/_index.md index e1f9655dc3e..2ce2d72bf8d 100644 --- a/content/rancher/v2.x/en/security/_index.md +++ b/content/rancher/v2.x/en/security/_index.md @@ -39,7 +39,7 @@ Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to ru The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. -The Center for Internet Security (CIS) is a 501(c)(3) nonprofit organization, formed in October 2000, with a mission is to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace." +The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace." CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team. @@ -51,7 +51,7 @@ For details, refer to the section on [security scans.]({{}}/rancher/v2. ### Rancher Hardening Guide -The Rancher Hardening Guide is based off of controls and best practices found in the CIS Kubernetes Benchmark from the Center for Internet Security. +The Rancher Hardening Guide is based on controls and best practices found in the CIS Kubernetes Benchmark from the Center for Internet Security. The hardening guide provides prescriptive guidance for hardening a production installation of Rancher v2.1.x, v2.2.x and v.2.3.x. See Rancher's [Self Assessment of the CIS Kubernetes Benchmark](#cis-benchmark-rancher-self-assessment) for the full list of security controls. @@ -74,7 +74,7 @@ The benchmark self-assessment is a companion to the Rancher security hardening g Because Rancher and RKE install Kubernetes services as Docker containers, many of the control verification checks in the CIS Kubernetes Benchmark don't apply. This guide will walk through the various controls and provide updated example commands to audit compliance in Rancher created clusters. The original benchmark documents can be downloaded from the [CIS website](https://www.cisecurity.org/benchmark/kubernetes/). -Each version of Rancher's self assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark: +Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark: Self Assessment Guide Version | Rancher Version | Hardening Guide Version | Kubernetes Version | CIS Benchmark Version ---------------------------|----------|---------|-------|----- diff --git a/content/rancher/v2.x/en/security/rancher-2.5/_index.md b/content/rancher/v2.x/en/security/rancher-2.5/_index.md index 4b12b4458b6..86484f96dea 100644 --- a/content/rancher/v2.x/en/security/rancher-2.5/_index.md +++ b/content/rancher/v2.x/en/security/rancher-2.5/_index.md @@ -15,7 +15,7 @@ To harden a Kubernetes cluster outside of Rancher's distributions, refer to your # Guides -These guides have been tested along with the Rancher v2.5 release. Each self assessment guide is accompanied with a hardening guide and tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can choose to use the existing guides until a newer version is added. +These guides have been tested along with the Rancher v2.5 release. Each self-assessment guide is accompanied with a hardening guide and tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can choose to use the existing guides until a newer version is added. ### RKE Guides