From 057e022e32a44c5f0f28eed6a3280022f15eb0b1 Mon Sep 17 00:00:00 2001 From: Negash Date: Mon, 25 Nov 2019 23:55:03 +0300 Subject: [PATCH 01/82] Update _index.md Quick deploy roles for AWS IAM --- .../en/config-options/cloud-providers/aws/_index.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/content/rke/latest/en/config-options/cloud-providers/aws/_index.md b/content/rke/latest/en/config-options/cloud-providers/aws/_index.md index 9ab6c05524d..c14e2e68ae3 100644 --- a/content/rke/latest/en/config-options/cloud-providers/aws/_index.md +++ b/content/rke/latest/en/config-options/cloud-providers/aws/_index.md @@ -12,7 +12,7 @@ cloud_provider: ## IAM Requirements -The nodes used in RKE that will be running the AWS cloud provider must have at least the following IAM policy. +The nodes used in RKE that will be running the AWS cloud provider must have at least the following IAM policy (`rancher-role.json`). ```json { @@ -22,7 +22,7 @@ The nodes used in RKE that will be running the AWS cloud provider must have at l } ``` -In order to use Elastic Load Balancers (ELBs) and EBS with Kubernetes, the node(s) will need to have the an IAM role with appropriate access. +In order to use Elastic Load Balancers (ELBs) and EBS with Kubernetes, the node(s) will need to have the an IAM role with appropriate access (`rancher-policy.json`). ## Example Policy for IAM Role: @@ -54,6 +54,15 @@ In order to use Elastic Load Balancers (ELBs) and EBS with Kubernetes, the node( } ``` +Deploy files to AWS IAM: + +```bash +$ aws iam create-instance-profile --instance-profile-name rancher-node +$ aws iam create-role --role-name rancher-node --assume-role-policy-document file://rancher-role.json +$ aws iam put-role-policy --role-name rancher-node --policy-name rancher-policy --policy-document file://rancher-policy.json +$ aws iam add-role-to-instance-profile --instance-profile rancher-node --role-name rancher-node +``` + ## Tagging Amazon Resources Any resources used in a Kubernetes cluster with the Amazon cloud provider must be tagged with a cluster ID. From a2f4cbbd1e74809ae444b86cf761663359c727df Mon Sep 17 00:00:00 2001 From: Negash Date: Tue, 26 Nov 2019 00:00:16 +0300 Subject: [PATCH 02/82] set IAM Profile Name --- .../rke/latest/en/config-options/cloud-providers/aws/_index.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/rke/latest/en/config-options/cloud-providers/aws/_index.md b/content/rke/latest/en/config-options/cloud-providers/aws/_index.md index c14e2e68ae3..c580991232f 100644 --- a/content/rke/latest/en/config-options/cloud-providers/aws/_index.md +++ b/content/rke/latest/en/config-options/cloud-providers/aws/_index.md @@ -63,6 +63,9 @@ $ aws iam put-role-policy --role-name rancher-node --policy-name rancher-policy $ aws iam add-role-to-instance-profile --instance-profile rancher-node --role-name rancher-node ``` +Set `IAM Instance Profile Name` in node template to `rancher-node` + + ## Tagging Amazon Resources Any resources used in a Kubernetes cluster with the Amazon cloud provider must be tagged with a cluster ID. From 0ff7e4e32c9d2464d109831a4742d9d8da54b737 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Thu, 12 Dec 2019 10:58:01 -0700 Subject: [PATCH 03/82] Add list of ports required for combination etcd/controlplane/worker nodes --- .../en/installation/requirements/_index.md | 90 +++++++++++++++++-- 1 file changed, 82 insertions(+), 8 deletions(-) diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index 68210195cc2..990f002dae2 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -2,7 +2,6 @@ title: Installation Requirements weight: 1 aliases: - - /rancher/v2.x/en/hosts/amazon/#required-ports-for-rancher-to-work/ - /rancher/v2.x/en/installation/references --- @@ -92,15 +91,20 @@ Each node used should have a static IP configured, regardless of whether you are This section describes the port requirements for nodes running the `rancher/rancher` container. -The port requirements are different depending on whether you are installing Rancher on a single node or on a high-availability Kubernetes cluster. For a single node, you only need to open the [ports required to enable Rancher to communicate with user clusters.](#port-requirements-for-enabling-rancher-to-communicate-with-user-clusters) For a high-availability installation, the same ports need to be opened, as well as additional [ports required to set up the Kubernetes cluster](#additional-port-requirements-for-nodes-in-high-availability-rancher-installations) that Rancher is installed on. +The port requirements are different depending on whether you are installing Rancher on a single node or on a high-availability Kubernetes cluster. -### Port Requirements for Enabling Rancher to Communicate with User Clusters +- **For a single-node installation,** you only need to open the ports required to enable Rancher to communicate with downstream user clusters. +- **For a high-availability installation,** the same ports need to be opened, as well as additional ports required to set up the Kubernetes cluster that Rancher is installed on. -For a single-node installation, you only need to open the ports for the Rancher management plane. These ports are opened to allow the Rancher server to communicate with the Kubernetes clusters that will run your apps and services. +{{% tabs %}} +{{% tab "HA Install Port Requirements" %}} +### Ports for Communication with Downstream Clusters -For a high-availability installation, these rules apply as well as the [port requirements to set up the Kubernetes cluster](#additional-port-requirements-for-nodes-in-high-availability-rancher-installations) that Rancher is installed on. +To communicate with downstream clusters, Rancher requires different ports to be open depending on the infrastructure you are using. -The port requirements are different based the infrastructure you are using. For example, if you are deploying Rancher on nodes hosted by an infrastructure provider, port `22` must be open for SSH. The following diagram depicts the ports that are opened for each [cluster type]({{}}/rancher/v2.x/en/cluster-provisioning). +For example, if you are deploying Rancher on nodes hosted by an infrastructure provider, port `22` must be open for SSH. + +The following diagram depicts the ports that are opened for each [cluster type]({{}}/rancher/v2.x/en/cluster-provisioning).
Port Requirements for the Rancher Management Plane
@@ -126,8 +130,78 @@ The following tables break down the port requirements for inbound and outbound t **Note** Rancher nodes may also require additional outbound access for any external [authentication provider]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) which is configured (LDAP for example). -### Additional Port Requirements for Nodes in High-Availability Rancher Installations +### Additional Port Requirements for Nodes in an HA/Kubernetes Cluster You will need to open additional ports to launch the Kubernetes cluster that are required for a high-availability installation of Rancher. -The ports that need to be opened for each node depend on the node's Kubernetes role: etcd, controlplane, or worker. For a breakdown of the port requirements for each role, refer to the [port requirements for the Rancher Kubernetes Engine.]({{}}/rke/latest/en/os/#ports) +If you follow the Rancher installation documentation for setting up a Kubernetes cluster using RKE, you will set up a cluster in which all three nodes have all three roles: etcd, controlplane, and worker. In that case, you can refer to this list of requirements for each node with all three roles: + +
Inbound Rules for Nodes with All Three Roles: etcd, Controlplane, and Worker
+ +Protocol | Port | Source | Description +-----------|------|----------|-------------- +TCP | 22 | Linux worker nodes only, and any network that you want to be able to remotely access this node from. | Remote access over SSH +TCP | 80 | Any source that consumes Ingress services | Ingress controller (HTTP) +TCP | 443 | Any source that consumes Ingress services | Ingress controller (HTTPS) +TCP | 2376 | Rancher nodes | Docker daemon TLS port used by Docker Machine (only needed when using Node Driver/Templates) +TCP | 2379 | etcd nodes and controlplane nodes | etcd client requests +TCP | 2380 | etcd nodes and controlplane nodes | etcd peer communication +TCP | 3389 | Windows worker nodes only, and any network that you want to be able to remotely access this node from. | Remote access over RDP +TCP | 6443 | etcd nodes, controlplane nodes, and worker nodes | Kubernetes apiserver +UDP | 8472 | etcd nodes, controlplane nodes, and worker nodes | Canal/Flannel VXLAN overlay networking +TCP | 9099 | the node itself (local traffic, not across nodes) | Canal/Flannel livenessProbe/readinessProbe +TCP | 10250 | controlplane nodes | kubelet +TCP | 10254 | the node itself (local traffic, not across nodes) | Ingress controller livenessProbe/readinessProbe +TCP/UDP | 30000-32767 | Any source that consumes NodePort services | NodePort port range + +
Outbound Rules for Nodes with All Three Roles: etcd, Controlplane, and Worker
+ +Protocol | Port | Source | Destination | Description +-----------|------|----------|---------------|-------------- +TCP | 22 | RKE node | Any node configured in Cluster Configuration File | SSH provisioning of node by RKE +TCP | 443 | Rancher nodes | Rancher agent | +TCP | 2379 | etcd nodes | etcd client requests | +TCP | 2380 | etcd nodes | etcd peer communication | +TCP | 6443 | RKE node | controlplane nodes | Kubernetes API server +TCP | 6443 | controlplane nodes | Kubernetes API server | +UDP | 8472 | etcd nodes, controlplane nodes, and worker nodes | Canal/Flannel VXLAN overlay networking | +TCP | 9099 | the node itself (local traffic, not across nodes) | Canal/Flannel livenessProbe/readinessProbe | +TCP | 10250 | etcd nodes, controlplane nodes, and worker nodes | kubelet | +TCP | 10254 | the node itself (local traffic, not across nodes) | Ingress controller livenessProbe/readinessProbe + +The ports that need to be opened for each node depend on the node's Kubernetes role: etcd, controlplane, or worker. If you installed Rancher on a Kubernetes cluster that doesn't have all three roles on each node, refer to the [port requirements for the Rancher Kubernetes Engine (RKE).]({{}}/rke/latest/en/os/#ports) The RKE docs show a breakdown of the port requirements for each role. +{{% /tab %}} +{{% tab "Single Node Port Requirements" %}} +### Ports for Communication with Downstream Clusters + +To communicate with downstream clusters, Rancher requires different ports to be open depending on the infrastructure you are using. + +For example, if you are deploying Rancher on nodes hosted by an infrastructure provider, port `22` must be open for SSH. + +The following diagram depicts the ports that are opened for each [cluster type]({{}}/rancher/v2.x/en/cluster-provisioning). + +
Port Requirements for the Rancher Management Plane
+ +![Basic Port Requirements]({{}}/img/rancher/port-communications.svg) + +The following tables break down the port requirements for inbound and outbound traffic: + +
Inbound Rules for Rancher Nodes
+ +| Protocol | Port | Source | Description | +| -------- | ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | +| TCP | 80 | Load balancer/proxy that does external SSL termination | Rancher UI/API when external SSL termination is used | +| TCP | 443 |
  • etcd nodes
  • controlplane nodes
  • worker nodes
  • hosted/imported Kubernetes
  • any source that needs to be able to use the Rancher UI or API
| Rancher agent, Rancher UI/API, kubectl | + +
Outbound Rules for Rancher Nodes
+ +| Protocol | Port | Source | Description | +| -------- | ---- | -------------------------------------------------------- | --------------------------------------------- | +| TCP | 22 | Any node IP from a node created using Node Driver | SSH provisioning of nodes using Node Driver | +| TCP | 443 | `35.160.43.145/32`, `35.167.242.46/32`, `52.33.59.17/32` | git.rancher.io (catalogs) | +| TCP | 2376 | Any node IP from a node created using Node driver | Docker daemon TLS port used by Docker Machine | +| TCP | 6443 | Hosted/Imported Kubernetes API | Kubernetes API server | + +**Note** Rancher nodes may also require additional outbound access for any external [authentication provider]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) which is configured (LDAP for example). +{{% /tab %}} +{{% /tabs %}} From 42958a555c7ffc86d84f9b7a8559304951265070 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Thu, 5 Dec 2019 17:19:09 -0700 Subject: [PATCH 04/82] Add Docker installation scripts to docs --- .../requirements/installing-docker/_index.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/rancher/v2.x/en/installation/requirements/installing-docker/_index.md diff --git a/content/rancher/v2.x/en/installation/requirements/installing-docker/_index.md b/content/rancher/v2.x/en/installation/requirements/installing-docker/_index.md new file mode 100644 index 00000000000..ac20da0afe8 --- /dev/null +++ b/content/rancher/v2.x/en/installation/requirements/installing-docker/_index.md @@ -0,0 +1,18 @@ +--- +title: Installing Docker +weight: 1 +--- + +Docker is required to be installed on any node that runs the Rancher server. + +There are a couple of options for installing Docker. One option is to refer to the [official Docker documentation](https://docs.docker.com/install/) about how to install Docker on Linux. The steps will vary based on the Linux distribution. + +Another option is to use one of Rancher's Docker installation scripts, which are available for most recent versions of Docker. + +For example, this command could be used to install Docker 18.09 on Ubuntu: + +``` +curl https://releases.rancher.com/install-docker/18.09.sh | sh +``` + +To find out whether a script is available for installing a certain Docker version, refer to this [GitHub repository,](https://github.com/rancher/install-docker) which contains all of Rancher's Docker installation scripts. \ No newline at end of file From acd25768562a6cc13f50126e1a626b23eeab333d Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 17 Dec 2019 17:29:49 -0700 Subject: [PATCH 05/82] Update install Docker section --- content/rancher/v2.x/en/installation/requirements/_index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index 990f002dae2..2d4c1010be3 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -35,7 +35,9 @@ All supported operating systems are 64-bit x86. If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/options/arm64-platform/) -For information on how to install Docker, refer to the offical [Docker documentation.](https://docs.docker.com/) +### Installing Docker + +Docker can be installed by following the steps in the offical [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{}}/rancher/v2.x/en/installation/requirements/installing-docker) to install Docker with one command. # Hardware Requirements From 91dc62b5ecaf4e69066f7c64d08b7f58e69ae5c0 Mon Sep 17 00:00:00 2001 From: Tejeev Date: Wed, 18 Dec 2019 10:43:37 +0000 Subject: [PATCH 06/82] added missing 'to' but the end of this paragraph feels very repetitive --- .../v2.x/en/cluster-admin/projects-and-namespaces/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md index 592ea784b6b..a4d867ead81 100644 --- a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md @@ -17,7 +17,7 @@ Projects provide an extra level of organization in your Kubernetes clusters beyo - Clusters contain projects. - Projects contain namespaces. -Within Rancher, projects allow you manage multiple namespaces as a single entity. In the base version of Kubernetes, which does not include projects, features like role-based access rights or cluster resources are assigned to individual namespaces. In clusters where multiple namespaces require the same set of access rights, assigning these rights to each individual namespace can become tedious. Even though all namespaces require the same rights, there's no way to apply those rights to all of your namespaces in a single action. You'd have to repetitively assign these rights to each namespace! +Within Rancher, projects allow you to manage multiple namespaces as a single entity. In the base version of Kubernetes, which does not include projects, features like role-based access rights or cluster resources are assigned to individual namespaces. In clusters where multiple namespaces require the same set of access rights, assigning these rights to each individual namespace can become tedious. Even though all namespaces require the same rights, there's no way to apply those rights to all of your namespaces in a single action. You'd have to repetitively assign these rights to each namespace! Rancher projects resolve this issue by allowing you to apply resources and access rights at the project level. Each namespace in the project then inherits these resources and policies, so you only have to assign them to the project once, rather than assigning them to each namespace. From f4cff2c5a3dc721f698cf139889da638c56ef194 Mon Sep 17 00:00:00 2001 From: Tejeev Date: Wed, 18 Dec 2019 10:48:34 +0000 Subject: [PATCH 07/82] Update _index.md --- .../v2.x/en/cluster-admin/projects-and-namespaces/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md index 592ea784b6b..54b89731666 100644 --- a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md @@ -129,7 +129,7 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h 1. **Optional:** Repeat these substeps to add more quotas. -1. **Optional:** Specify **Container Default Resource Limit**, which will be applied to every container started in the project. The parameter is recommended if you have CPU or Memory limits set by the Resource Quota. It can be overridden on per an individual namespace or a container level. For more information, see [Container Default Resource Limit]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#setting-container-default-resource-limit) +1. **Optional:** Specify **Container Default Resource Limit**, which will be applied to every container started in the project. The parameter is recommended if you have CPU or Memory limits set by the Resource Quota. It can be overridden on per an individual namespace or a container level. For more information, see [Container Default Resource Limit]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#setting-container-default-resource-limit) >**Note:** This option is available as of v2.2.0. From 7dc923e0fff602b5a4220d53817e3b5a3e02032b Mon Sep 17 00:00:00 2001 From: ZHAO Yao Date: Wed, 18 Dec 2019 18:54:54 +0800 Subject: [PATCH 08/82] fix typo --- content/rancher/v2.x/en/overview/architecture/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/overview/architecture/_index.md b/content/rancher/v2.x/en/overview/architecture/_index.md index d62f7514b80..2bb7112087e 100644 --- a/content/rancher/v2.x/en/overview/architecture/_index.md +++ b/content/rancher/v2.x/en/overview/architecture/_index.md @@ -7,7 +7,7 @@ This section focuses on the Rancher server, its components, and how Rancher comm For information on the different ways that Rancher can be installed, refer to the [section on choosing an installation method.]({{}}/rancher/v2.x/en/installation/choosing-installation) -For a list of main eatures of the Rancher API server, refer to the [overview section.]({{}}/rancher/v2.x/en/overview/#features-of-the-rancher-api-server) +For a list of main features of the Rancher API server, refer to the [overview section.]({{}}/rancher/v2.x/en/overview/#features-of-the-rancher-api-server) For guidance about setting up the underlying infrastructure for the Rancher server, refer to the [architecture recommendations.]({{}}/rancher/v2.x/en/overview/architecture-recommendations) @@ -172,4 +172,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.]({{}}/rancher/v2.x/en/contributing/#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. \ No newline at end of file +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.]({{}}/rancher/v2.x/en/contributing/#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. From fe8d31090680d8ff1214b42e008710f1c49e9589 Mon Sep 17 00:00:00 2001 From: David Zisky Date: Wed, 18 Dec 2019 15:35:19 +0100 Subject: [PATCH 09/82] Updated info about using kubeconfig K3S no longer puts "localhost" in kubeconfig but "127.0.0.1" instead. Therefore - updated instructions. --- content/k3s/latest/en/configuration/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/k3s/latest/en/configuration/_index.md b/content/k3s/latest/en/configuration/_index.md index 1f3cc7d7bf8..7ee0ae25a13 100644 --- a/content/k3s/latest/en/configuration/_index.md +++ b/content/k3s/latest/en/configuration/_index.md @@ -90,7 +90,7 @@ Accessing Cluster from Outside ----------------------------- Copy `/etc/rancher/k3s/k3s.yaml` on your machine located outside the cluster as `~/.kube/config`. Then replace -"localhost" with the IP or name of your K3s server. `kubectl` can now manage your K3s cluster. +"127.0.0.1" with the IP or name of your K3s server. `kubectl` can now manage your K3s cluster. Node Registration ----------------- From 09b6413d075f6c82761c85ad8161241c85224f84 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Wed, 18 Dec 2019 11:51:12 -0700 Subject: [PATCH 10/82] Describe projects more concisely --- .../projects-and-namespaces/_index.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md index a4d867ead81..1ff9388ef3e 100644 --- a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md @@ -10,16 +10,16 @@ aliases: ## Projects -_Projects_ are organizational objects introduced in Rancher that ease the administrative burden of your cluster. You can use projects to support multi-tenancy. +A project is a group of multiple [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) and access control policies within a cluster. A project is a concept introduced by Rancher, not Kubernetes, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.x/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.x/en/k8s-in-rancher/) -Projects provide an extra level of organization in your Kubernetes clusters beyond [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/). In terms of hierarchy: +In terms of hierarchy: -- Clusters contain projects. -- Projects contain namespaces. +- Clusters contain projects +- Projects contain namespaces -Within Rancher, projects allow you to manage multiple namespaces as a single entity. In the base version of Kubernetes, which does not include projects, features like role-based access rights or cluster resources are assigned to individual namespaces. In clusters where multiple namespaces require the same set of access rights, assigning these rights to each individual namespace can become tedious. Even though all namespaces require the same rights, there's no way to apply those rights to all of your namespaces in a single action. You'd have to repetitively assign these rights to each namespace! +You can use projects to support multi-tenancy, so that a team can access a project within a cluster without having access to other projects in the same cluster. -Rancher projects resolve this issue by allowing you to apply resources and access rights at the project level. Each namespace in the project then inherits these resources and policies, so you only have to assign them to the project once, rather than assigning them to each namespace. +In the base version of Kubernetes, features like role-based access rights or cluster resources are assigned to individual namespaces. A project allows you to save time by giving an individual or a team acess to multiple namespaces simultaneously. You can use projects to perform actions like: @@ -28,8 +28,7 @@ You can use projects to perform actions like: - Assign resources to the project. - Assign Pod Security Policies. - -When you create a cluster, two project are automatically created within it: +When you create a cluster, two projects are automatically created within it: - [Default Project](#default-project) - [System Project](#system-project) From f6ed4f96ade62912ca5dd786d25ff96804381839 Mon Sep 17 00:00:00 2001 From: catherineluse Date: Mon, 16 Dec 2019 04:37:53 -0700 Subject: [PATCH 11/82] Update .gitignore --- .gitignore | 1 + .vscode/settings.json | 3 +++ 2 files changed, 4 insertions(+) diff --git a/.gitignore b/.gitignore index d325d3bd49d..130a0023abe 100644 --- a/.gitignore +++ b/.gitignore @@ -5,3 +5,4 @@ package-lock.json *.tern-port */**/.tern-port .DS_Store +.vscode/settings.json \ No newline at end of file diff --git a/.vscode/settings.json b/.vscode/settings.json index 7a73a41bfdf..def1f0b6e95 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,2 +1,5 @@ { + "editor.fontFamily": "'Lato', sans-serif;", + "editor.fontSize": 18, + "workbench.colorTheme": "Dainty – Purple Haze" } \ No newline at end of file From cf59c4325956aa35a7f49a64cc79cdc406302eff Mon Sep 17 00:00:00 2001 From: catherineluse Date: Wed, 18 Dec 2019 16:51:46 -0700 Subject: [PATCH 12/82] Formatting and link fixes for installation/Helm 2 docs --- .vscode/settings.json | 3 --- .../v2.x/en/installation/options/helm2/_index.md | 12 ++++++------ .../options/helm2/create-nodes-lb/_index.md | 6 +++--- .../helm2/create-nodes-lb/nginx/_index.md | 2 +- .../options/helm2/helm-init/_index.md | 4 ++-- .../helm2/helm-init/troubleshooting/_index.md | 2 +- .../options/helm2/helm-rancher/_index.md | 16 ++++++++-------- .../helm2/helm-rancher/chart-options/_index.md | 2 +- .../helm2/helm-rancher/troubleshooting/_index.md | 4 ++-- .../options/helm2/kubernetes-rke/_index.md | 4 ++-- .../options/helm2/rke-add-on/_index.md | 10 +++++----- .../helm2/rke-add-on/api-auditing/_index.md | 2 +- .../helm2/rke-add-on/layer-4-lb/_index.md | 4 ++-- .../helm2/rke-add-on/layer-4-lb/nlb/_index.md | 2 +- .../helm2/rke-add-on/layer-7-lb/_index.md | 4 ++-- .../helm2/rke-add-on/layer-7-lb/alb/_index.md | 2 +- .../helm2/rke-add-on/layer-7-lb/nginx/_index.md | 4 ++-- .../options/helm2/rke-add-on/proxy/_index.md | 2 +- .../404-default-backend/_index.md | 2 +- .../helm2/rke-add-on/troubleshooting/_index.md | 2 +- .../generic-troubleshooting/_index.md | 2 +- .../job-complete-status/_index.md | 2 +- .../installation/options/server-tags/_index.md | 9 ++++----- 23 files changed, 49 insertions(+), 53 deletions(-) diff --git a/.vscode/settings.json b/.vscode/settings.json index def1f0b6e95..7a73a41bfdf 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,5 +1,2 @@ { - "editor.fontFamily": "'Lato', sans-serif;", - "editor.fontSize": 18, - "workbench.colorTheme": "Dainty – Purple Haze" } \ No newline at end of file diff --git a/content/rancher/v2.x/en/installation/options/helm2/_index.md b/content/rancher/v2.x/en/installation/options/helm2/_index.md index 45128338ac3..04953ce9450 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/_index.md @@ -38,10 +38,10 @@ The following CLI tools are required for this install. Please make sure these to ## Installation Outline -- [Create Nodes and Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/) -- [Install Kubernetes with RKE]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/) -- [Initialize Helm (tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/) -- [Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/) +- [Create Nodes and Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/) +- [Install Kubernetes with RKE]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/kubernetes-rke/) +- [Initialize Helm (tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-init/) +- [Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/) ## Additional Install Options @@ -49,10 +49,10 @@ The following CLI tools are required for this install. Please make sure these to ## Previous Methods -[RKE add-on install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/) +[RKE add-on install]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/rke-add-on/) > **Important: RKE add-on install is only supported up to Rancher v2.0.8** > -> Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +> Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > > If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/_index.md index ade47ce26fe..2fc60064b8c 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/_index.md @@ -24,7 +24,7 @@ Configure a load balancer as a basic Layer 4 TCP forwarder. The exact configurat #### Examples -* [Nginx]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/) -* [Amazon NLB]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/nlb/) +* [Nginx]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/) +* [Amazon NLB]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nlb/) -### [Next: Install Kubernetes with RKE]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/) +### [Next: Install Kubernetes with RKE]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/kubernetes-rke/) diff --git a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md index 469541db519..ad5b37792c3 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md @@ -21,7 +21,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx. 1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`. -2. From `nginx.conf`, replace both occurences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/). +2. From `nginx.conf`, replace both occurences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/). >**Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options. diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md index 4ebf1bb88c7..16b37158c37 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md @@ -60,6 +60,6 @@ Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b ### Issues or errors? -See the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/troubleshooting/) page. +See the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-init/troubleshooting/) page. -### [Next: Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/) +### [Next: Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/) diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-init/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-init/troubleshooting/_index.md index c73013b5cb8..3941bd1b9f8 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-init/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-init/troubleshooting/_index.md @@ -20,4 +20,4 @@ helm version --server Error: could not find tiller ``` -When you have confirmed that `tiller` has been removed, please follow the steps provided in [Initialize Helm (Install tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/) to install `tiller` with the correct `ServiceAccount`. +When you have confirmed that `tiller` has been removed, please follow the steps provided in [Initialize Helm (Install tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-init/) to install `tiller` with the correct `ServiceAccount`. diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/_index.md index 9fc3f85cc0d..7dfe8cc223a 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/_index.md @@ -27,7 +27,7 @@ Rancher Server is designed to be secure by default and requires SSL/TLS configur There are three recommended options for the source of the certificate. -> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#external-tls-termination). +> **Note:** If you want terminate SSL/TLS externally, see [TLS termination on an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/#external-tls-termination). | Configuration | Chart option | Description | Requires cert-manager | |-----|-----|-----|-----| @@ -37,7 +37,7 @@ There are three recommended options for the source of the certificate. ### Optional: Install cert-manager -**Note:** cert-manager is only required for certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) and Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`). You should skip this step if you are using your own certificate files (option `ingress.tls.source=secret`) or if you use [TLS termination on an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#external-tls-termination). +**Note:** cert-manager is only required for certificates issued by Rancher's generated CA (`ingress.tls.source=rancher`) and Let's Encrypt issued certificates (`ingress.tls.source=letsEncrypt`). You should skip this step if you are using your own certificate files (option `ingress.tls.source=secret`) or if you use [TLS termination on an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/#external-tls-termination). > **Important:** > Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher. @@ -164,7 +164,7 @@ helm install rancher-/rancher \ --set ingress.tls.source=secret ``` -Now that Rancher is deployed, see [Adding TLS Secrets]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them. +Now that Rancher is deployed, see [Adding TLS Secrets]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them. After adding the secrets, check if Rancher was rolled out successfully: @@ -188,11 +188,11 @@ It should show the same count for `DESIRED` and `AVAILABLE`. The Rancher chart configuration has many options for customizing the install to suit your specific environment. Here are some common advanced scenarios. -* [HTTP Proxy]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#http-proxy) -* [Private Docker Image Registry]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#private-registry-and-air-gap-installs) -* [TLS Termination on an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#external-tls-termination) +* [HTTP Proxy]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/#http-proxy) +* [Private Docker Image Registry]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/#private-registry-and-air-gap-installs) +* [TLS Termination on an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/#external-tls-termination) -See the [Chart Options]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/) for the full list of options. +See the [Chart Options]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/) for the full list of options. ### Save your options @@ -202,4 +202,4 @@ Make sure you save the `--set` options you used. You will need to use the same o That's it you should have a functional Rancher server. Point a browser at the hostname you picked and you should be greeted by the colorful login page. -Doesn't work? Take a look at the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/troubleshooting/) Page +Doesn't work? Take a look at the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/troubleshooting/) Page diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md index ae2bead7b0c..ae2c449dcb3 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md @@ -152,7 +152,7 @@ We recommend configuring your load balancer as a Layer 4 balancer, forwarding pl You may terminate the SSL/TLS on a L7 load balancer external to the Rancher cluster (ingress). Use the `--set tls=external` option and point your load balancer at port http 80 on all of the Rancher cluster nodes. This will expose the Rancher interface on http port 80. Be aware that clients that are allowed to connect directly to the Rancher cluster will not be encrypted. If you choose to do this we recommend that you restrict direct access at the network level to just your load balancer. -> **Note:** If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/#using-a-private-ca-signed-certificate) to add the CA cert for Rancher. +> **Note:** If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/#using-a-private-ca-signed-certificate) to add the CA cert for Rancher. Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly. diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/troubleshooting/_index.md index 46a3508e593..375d870ac1c 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/troubleshooting/_index.md @@ -124,10 +124,10 @@ W0705 23:04:58.240571 7 backend_ssl.go:49] error obtaining PEM from secret ### no matches for kind "Issuer" -The [SSL configuration]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/#choose-your-ssl-configuration) option you have chosen requires [cert-manager]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/#optional-install-cert-manager) to be installed before installing Rancher or else the following error is shown: +The [SSL configuration]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/#choose-your-ssl-configuration) option you have chosen requires [cert-manager]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/#optional-install-cert-manager) to be installed before installing Rancher or else the following error is shown: ``` Error: validation failed: unable to recognize "": no matches for kind "Issuer" in version "certmanager.k8s.io/v1alpha1" ``` -Install [cert-manager]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/#optional-install-cert-manager) and try installing Rancher again. +Install [cert-manager]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/#optional-install-cert-manager) and try installing Rancher again. diff --git a/content/rancher/v2.x/en/installation/options/helm2/kubernetes-rke/_index.md b/content/rancher/v2.x/en/installation/options/helm2/kubernetes-rke/_index.md index b57911e5fb2..80876ffa010 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/kubernetes-rke/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/kubernetes-rke/_index.md @@ -125,6 +125,6 @@ Save a copy of the following files in a secure location: ### Issues or errors? -See the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/troubleshooting/) page. +See the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/kubernetes-rke/troubleshooting/) page. -### [Next: Initialize Helm (Install tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/) +### [Next: Initialize Helm (Install tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-init/) diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/_index.md index 1c9845e9cdc..ffdcc425d07 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/_index.md @@ -5,12 +5,12 @@ weight: 276 > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. -* [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb) -* [High Availability Installation with External Load Balancer (HTTPS/Layer 7)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb) -* [HTTP Proxy Configuration for a High Availability Installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/proxy/) -* [Troubleshooting RKE Add-on Installs]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/) +* [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb) +* [High Availability Installation with External Load Balancer (HTTPS/Layer 7)]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb) +* [HTTP Proxy Configuration for a High Availability Installation]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/rke-add-on/proxy/) +* [Troubleshooting RKE Add-on Installs]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/) diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/api-auditing/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/api-auditing/_index.md index 36dc7198bf2..d4a07362b68 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/api-auditing/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/api-auditing/_index.md @@ -7,7 +7,7 @@ aliases: >**Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md index 70a5558a7d3..66c0f330213 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. @@ -169,7 +169,7 @@ RKE uses a `.yml` config file to install and configure your Kubernetes cluster. >**Advanced Config Options:** > - >- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/). + >- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/rke-add-on/api-auditing/). >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/). diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/nlb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/nlb/_index.md index 41ce4337fa8..ef02bbfabd1 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/nlb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/nlb/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md index 8460a64160e..dca03867288 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. @@ -117,7 +117,7 @@ RKE uses a YAML config file to install and configure your Kubernetes cluster. Th >**Advanced Config Options:** > - >- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/api-auditing/). + >- Want records of all transactions with the Rancher API? Enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by editing your RKE config file. For more information, see how to enable it in [your RKE config file]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/rke-add-on/api-auditing/). >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/latest/en/config-options/). diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/alb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/alb/_index.md index 229cfa632d0..4656a579c1f 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/alb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/alb/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/nginx/_index.md index 74ea304f3d7..f1bc32d119b 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/nginx/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/nginx/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. @@ -19,7 +19,7 @@ For help installing NGINX, refer to their [install documentation](https://www.ng ## Create NGINX Configuration -See [Example NGINX config]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#example-nginx-config). +See [Example NGINX config]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/#example-nginx-config). ## Run NGINX diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/proxy/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/proxy/_index.md index 9a0e7edb6e4..cebf1ffb11b 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/proxy/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/proxy/_index.md @@ -5,7 +5,7 @@ weight: 277 > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/404-default-backend/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/404-default-backend/_index.md index 086744c0d50..bfbebc60586 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/404-default-backend/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/404-default-backend/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md index 5aeeafc2224..142363121e6 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/generic-troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/generic-troubleshooting/_index.md index f077118c92a..afc44300ae2 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/generic-troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/generic-troubleshooting/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/job-complete-status/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/job-complete-status/_index.md index ca20cded639..06df2796dc5 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/job-complete-status/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/job-complete-status/_index.md @@ -7,7 +7,7 @@ aliases: > #### **Important: RKE add-on install is only supported up to Rancher v2.0.8** > ->Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/ha/#installation-outline). +>Please use the Rancher helm chart to install HA Rancher. For details, see the [HA Install - Installation Outline]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/#installation-outline). > >If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. diff --git a/content/rancher/v2.x/en/installation/options/server-tags/_index.md b/content/rancher/v2.x/en/installation/options/server-tags/_index.md index cb6c08c4b3f..e3abff97965 100644 --- a/content/rancher/v2.x/en/installation/options/server-tags/_index.md +++ b/content/rancher/v2.x/en/installation/options/server-tags/_index.md @@ -87,8 +87,7 @@ Rancher Server is distributed as a Docker image, which have tags attached to the > **Notes:** > > - The `master` tag or any tag with `-rc` or another suffix is meant for the Rancher testing team to validate. You should not use these tags, as these builds are not officially supported. -> - Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). -> -> _Caveat:_ Alpha releases cannot be upgraded to or from any other release. -> -> {{% /tab %}} > {{% /tabs %}} +> - Want to install an alpha review for preview? Install using one of the alpha tags listed on our [announcements page](https://forums.rancher.com/c/announcements) (e.g., `v2.2.0-alpha1`). Caveat: Alpha releases cannot be upgraded to or from any other release. + +{{% /tab %}} +{{% /tabs %}} From f612771241e81e49d792dde295936693bf7426d7 Mon Sep 17 00:00:00 2001 From: catherineluse Date: Mon, 16 Dec 2019 04:37:53 -0700 Subject: [PATCH 13/82] Update .gitignore --- .vscode/settings.json | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.vscode/settings.json b/.vscode/settings.json index 7a73a41bfdf..def1f0b6e95 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,2 +1,5 @@ { + "editor.fontFamily": "'Lato', sans-serif;", + "editor.fontSize": 18, + "workbench.colorTheme": "Dainty – Purple Haze" } \ No newline at end of file From 871e3159a12de9461332a877672cb743b8bf0d01 Mon Sep 17 00:00:00 2001 From: catherineluse Date: Wed, 18 Dec 2019 23:10:38 -0700 Subject: [PATCH 14/82] Fix outdated UI reference about registry credentials --- .vscode/settings.json | 6 +----- content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md | 4 +++- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/.vscode/settings.json b/.vscode/settings.json index def1f0b6e95..0967ef424bc 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,5 +1 @@ -{ - "editor.fontFamily": "'Lato', sans-serif;", - "editor.fontSize": 18, - "workbench.colorTheme": "Dainty – Purple Haze" -} \ No newline at end of file +{} diff --git a/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md index 895c6d79102..663c04b0e75 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md @@ -19,7 +19,9 @@ Currently, deployments pull the private registry credentials automatically only 1. From the **Global** view, select the project containing the namespace(s) where you want to add a registry. -1. From the main menu, select **Resources > Registries**. Click **Add Registry**. +1. From the main menu, click **Resources > Secrets > Registry Credentials.** (For Rancher prior to v2.3, click **Resources > Registries.)** + +1. Click **Add Registry.** 1. Enter a **Name** for the registry. From 320ace209012320e175360f30222414013709737 Mon Sep 17 00:00:00 2001 From: catherineluse Date: Thu, 19 Dec 2019 00:01:33 -0700 Subject: [PATCH 15/82] Move feature flag docs to installation section --- content/rancher/v2.x/en/admin-settings/_index.md | 2 +- .../options}/feature-flags/_index.md | 8 +++++--- .../enable-not-default-storage-drivers/_index.md | 4 +++- .../feature-flags/istio-virtual-service-ui/_index.md | 4 +++- 4 files changed, 12 insertions(+), 6 deletions(-) rename content/rancher/v2.x/en/{admin-settings => installation/options}/feature-flags/_index.md (90%) rename content/rancher/v2.x/en/{admin-settings => installation/options}/feature-flags/enable-not-default-storage-drivers/_index.md (89%) rename content/rancher/v2.x/en/{admin-settings => installation/options}/feature-flags/istio-virtual-service-ui/_index.md (94%) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index d23b5e3d99f..86fc30a3512 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -58,4 +58,4 @@ For more information on how metadata works and how to configure metadata config, _Available as of v2.3.0_ -Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.]({{}}/rancher/v2.x/en/admin-settings/feature-flags) +Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.]({{}}/rancher/v2.x/en/installation/options/feature-flags) diff --git a/content/rancher/v2.x/en/admin-settings/feature-flags/_index.md b/content/rancher/v2.x/en/installation/options/feature-flags/_index.md similarity index 90% rename from content/rancher/v2.x/en/admin-settings/feature-flags/_index.md rename to content/rancher/v2.x/en/installation/options/feature-flags/_index.md index 0415f3c1adc..e1fc1983c84 100644 --- a/content/rancher/v2.x/en/admin-settings/feature-flags/_index.md +++ b/content/rancher/v2.x/en/installation/options/feature-flags/_index.md @@ -1,11 +1,13 @@ --- title: Enabling Experimental Features weight: 8000 +aliases: + - /rancher/v2.x/en/admin-settings/feature-flags --- _Available as of v2.3.0_ -Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type]({{}}/rancher/v2.x/en/admin-settings/feature-flags/enable-not-default-storage-drivers) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default. +Rancher includes some features that are experimental and disabled by default. You might want to enable these features, for example, if you decide that the benefits of using an [unsupported storage type]({{}}/rancher/v2.x/en/installation/options/feature-flags/enable-not-default-storage-drivers) outweighs the risk of using an untested feature. Feature flags were introduced to allow you to try these features that are not enabled by default. The features can be enabled in three ways: @@ -26,8 +28,8 @@ For example, if you install Rancher, then set a feature flag to true with the Ra The following is a list of the feature flags available in Rancher: -- `unsupported-storage-drivers`: This feature [allows unsupported storage drivers.]({{}}/rancher/v2.x/en/admin-settings/feature-flags/enable-not-default-storage-drivers) In other words, it enables types for storage providers and provisioners that are not enabled by default. -- `istio-virtual-service-ui`: This feature enables a [UI to create, read, update, and delete Istio virtual services and destination rules]({{}}/rancher/v2.x/en/admin-settings/feature-flags/istio-virtual-service-ui), which are traffic management features of Istio. +- `unsupported-storage-drivers`: This feature [allows unsupported storage drivers.]({{}}/rancher/v2.x/en/installation/options/feature-flags/able-not-default-storage-drivers) In other words, it enables types for storage providers and provisioners that are not enabled by default. +- `istio-virtual-service-ui`: This feature enables a [UI to create, read, update, and delete Istio virtual services and destination rules]({{}}/rancher/v2.x/en/installation/options/feature-flags/istio-virtual-service-ui), which are traffic management features of Istio. The below table shows the availability and default value for feature flags in Rancher: diff --git a/content/rancher/v2.x/en/admin-settings/feature-flags/enable-not-default-storage-drivers/_index.md b/content/rancher/v2.x/en/installation/options/feature-flags/enable-not-default-storage-drivers/_index.md similarity index 89% rename from content/rancher/v2.x/en/admin-settings/feature-flags/enable-not-default-storage-drivers/_index.md rename to content/rancher/v2.x/en/installation/options/feature-flags/enable-not-default-storage-drivers/_index.md index 5f26d7c3891..a4e729e3d5b 100644 --- a/content/rancher/v2.x/en/admin-settings/feature-flags/enable-not-default-storage-drivers/_index.md +++ b/content/rancher/v2.x/en/installation/options/feature-flags/enable-not-default-storage-drivers/_index.md @@ -1,12 +1,14 @@ --- title: Allow Unsupported Storage Drivers weight: 1 +aliases: + - /rancher/v2.x/en/admin-settings/feature-flags/enable-not-default-storage-drivers --- _Available as of v2.3.0_ This feature allows you to use types for storage providers and provisioners that are not enabled by default. -To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.]({{}}/rancher/v2.x/en/admin-settings/feature-flags) +To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.]({{}}/rancher/v2.x/en/installation/options/feature-flags/) Environment Variable Key | Default Value | Description ---|---|--- diff --git a/content/rancher/v2.x/en/admin-settings/feature-flags/istio-virtual-service-ui/_index.md b/content/rancher/v2.x/en/installation/options/feature-flags/istio-virtual-service-ui/_index.md similarity index 94% rename from content/rancher/v2.x/en/admin-settings/feature-flags/istio-virtual-service-ui/_index.md rename to content/rancher/v2.x/en/installation/options/feature-flags/istio-virtual-service-ui/_index.md index 8fc6fbd2d6f..f631b54d2ee 100644 --- a/content/rancher/v2.x/en/admin-settings/feature-flags/istio-virtual-service-ui/_index.md +++ b/content/rancher/v2.x/en/installation/options/feature-flags/istio-virtual-service-ui/_index.md @@ -1,6 +1,8 @@ --- title: UI for Istio Virtual Services and Destination Rules weight: 2 +aliases: + - /rancher/v2.x/en/admin-settings/feature-flags/istio-virtual-service-ui --- _Available as of v2.3.0_ @@ -8,7 +10,7 @@ This feature enables a UI that lets you create, read, update and delete virtual > **Prerequisite:** Turning on this feature does not enable Istio. A cluster administrator needs to [enable Istio for the cluster]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/setup) in order to use the feature. -To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.]({{}}/rancher/v2.x/en/admin-settings/feature-flags) +To enable or disable this feature, refer to the instructions on [the main page about enabling experimental features.]({{}}/rancher/v2.x/en/installation/options/feature-flags/) Environment Variable Key | Default Value | Status | Available as of ---|---|---|--- From 0ff16f58a24c04803d3293b4b88c5da105e9341c Mon Sep 17 00:00:00 2001 From: Tejeev Date: Thu, 19 Dec 2019 17:45:00 +0000 Subject: [PATCH 16/82] Fixed Istio links --- .../v2.x/en/cluster-admin/tools/istio/resources/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/resources/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/resources/_index.md index bb988012272..9b0dea50923 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/resources/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/resources/_index.md @@ -50,7 +50,7 @@ To configure the resources allocated to an Istio component, ## Pilot -[Pilot](https://istio.io/docs/concepts/what-is-istio/#pilot) provides the following: +[Pilot](https://istio.io/docs/ops/deployment/architecture/#pilot) provides the following: - Authentication configuration - Service discovery for the Envoy sidecars @@ -70,7 +70,7 @@ Pilot Selector | Ability to select the nodes in which istio-pilot pod is deploye ## Mixer -[Mixer](https://istio.io/docs/concepts/what-is-istio/#mixer) enforces access control and usage policies across the service mesh. It also integrates with plugins for monitoring tools such as Prometheus. The Envoy sidecar proxy passes telemetry data and monitoring data to Mixer, and Mixer passes the monitoring data to Prometheus. +[Mixer](https://istio.io/docs/ops/deployment/architecture/#mixer) enforces access control and usage policies across the service mesh. It also integrates with plugins for monitoring tools such as Prometheus. The Envoy sidecar proxy passes telemetry data and monitoring data to Mixer, and Mixer passes the monitoring data to Prometheus. For more information on Mixer, policies and telemetry, refer to the [documentation](https://istio.io/docs/concepts/policies-and-telemetry/). @@ -149,4 +149,4 @@ Enable Persistent Storage for Grafana | Enable Persistent Storage for Grafana | Source | Use a Storage Class to provision a new persistent volume or Use an existing persistent volume claim | Yes, when Grafana enabled and enabled PV | Use SC Storage Class | Storage Class for provisioning PV for Grafana | Yes, when Grafana enabled, enabled PV and use storage class | Use the default class Persistent Volume Size | The size for the PV you would like to provision for Grafana | Yes, when Grafana enabled, enabled PV and use storage class | 5Gi -Existing Claim | Use existing PVC for Grafana | Yes, when Grafana enabled, enabled PV and use existing PVC | n/a \ No newline at end of file +Existing Claim | Use existing PVC for Grafana | Yes, when Grafana enabled, enabled PV and use existing PVC | n/a From 5a6eae78aa0239a590696a61d579960717e6ef11 Mon Sep 17 00:00:00 2001 From: Lars Hugentobler Date: Mon, 23 Dec 2019 16:14:35 +0100 Subject: [PATCH 17/82] added "Secrets" level to "SSL Certificates" menu --- content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md index be9c46a198e..8ac2d3f0c02 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md @@ -13,7 +13,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c 1. From the **Global** view, select the project where you want to deploy your ingress. -1. From the main menu, select **Resources > Certificates**. Click **Add Certificate**. +1. From the main menu, select **Resources > Secrets > Certificates**. Click **Add Certificate**. 1. Enter a **Name** for the certificate. @@ -37,7 +37,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c - If you added an SSL certificate to the project, the certificate is available for deployments created in any project namespace. - If you added an SSL certificate to a namespace, the certificate is available only for deployments in that namespace. -- Your certificate is added to the **Resources > Certificates** view. +- Your certificate is added to the **Resources > Secrets > Certificates** view. ## What's Next? From 5fbd3232057da4b51f582b4208ac79bdb279df33 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 23 Dec 2019 11:25:58 -0700 Subject: [PATCH 18/82] Fix link to installation docs --- content/rancher/v2.x/en/overview/architecture/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/overview/architecture/_index.md b/content/rancher/v2.x/en/overview/architecture/_index.md index 2bb7112087e..c3c49b99cbc 100644 --- a/content/rancher/v2.x/en/overview/architecture/_index.md +++ b/content/rancher/v2.x/en/overview/architecture/_index.md @@ -5,7 +5,7 @@ weight: 1 This section focuses on the Rancher server, its components, and how Rancher communicates with downstream Kubernetes clusters. -For information on the different ways that Rancher can be installed, refer to the [section on choosing an installation method.]({{}}/rancher/v2.x/en/installation/choosing-installation) +For information on the different ways that Rancher can be installed, refer to the [overview of installation options.]({{}}/rancher/v2.x/en/installation/#overview-of-installation-options) For a list of main features of the Rancher API server, refer to the [overview section.]({{}}/rancher/v2.x/en/overview/#features-of-the-rancher-api-server) From ce7b5c9ae89073d5bc874e2f7dd0c4d8eadbdc82 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 23 Dec 2019 18:28:34 -0700 Subject: [PATCH 19/82] Fix links on main installation page --- content/rancher/v2.x/en/installation/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/rancher/v2.x/en/installation/_index.md b/content/rancher/v2.x/en/installation/_index.md index 11bbf818e0f..d9260f8ba4e 100644 --- a/content/rancher/v2.x/en/installation/_index.md +++ b/content/rancher/v2.x/en/installation/_index.md @@ -15,10 +15,10 @@ For testing and demonstration purposes, Rancher can also be installed with Docke There are also separate instructions for installing Rancher in an air gap environment or behind an HTTP proxy: -| Level of Internet Access | Installing on a Kubernetes Cluster - Strongly Recommended | Installing in a Single Docker Container | -| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| With direct access to the Internet | [Docs]({{}}/rancher/v2.x/en/installation/ha/) | [Docs]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-node) | -| Behind an HTTP proxy | These [docs,]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-node) plus this [configuration]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-nodeproxy/) | These [docs,]({{}}/rancher/v2.x/en/installation/ha/) plus this [configuration]({{}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#http-proxy) | +| Level of Internet Access | Installing on a Kubernetes Cluster - Strongly Recommended | Installing in a Single Docker Container | +| ---------------------------------- | ------------------------------ | ---------- | +| With direct access to the Internet | [Docs]({{}}/rancher/v2.x/en/installation/ha/) | [Docs]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-node) | +| Behind an HTTP proxy | These [docs,]({{}}/rancher/v2.x/en/installation/ha/) plus this [configuration]({{}}/rancher/v2.x/en/installation/options/chart-options/#http-proxy) | These [docs,]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-node) plus this [configuration]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-node/proxy/) | | In an air gap environment | [Docs]({{}}/rancher/v2.x/en/installation/other-installation-methods/air-gap) | [Docs]({{}}/rancher/v2.x/en/installation/other-installation-methods/air-gap) | > For the best performance and greater security, we recommend a 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. From 4949df81f9a74f85d66897e45fba98c14bae1e96 Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Wed, 13 Nov 2019 15:03:46 -0800 Subject: [PATCH 20/82] broken links --- .../installation/configuration/running-commands/_index.md | 2 +- content/rancher/v2.x/en/admin-settings/_index.md | 7 ++++--- .../rancher/v2.x/en/best-practices/containers/_index.md | 4 ++-- .../tools/istio/setup/enable-istio-in-cluster/_index.md | 2 +- .../en/cluster-provisioning/rke-clusters/options/_index.md | 4 ++-- .../v2.x/en/installation/requirements/ports/_index.md | 2 +- .../rancher/v2.x/en/project-admin/tools/alerts/_index.md | 2 +- 7 files changed, 12 insertions(+), 11 deletions(-) diff --git a/content/os/v1.x/en/installation/configuration/running-commands/_index.md b/content/os/v1.x/en/installation/configuration/running-commands/_index.md index 01bc8047343..11b8d44d8be 100644 --- a/content/os/v1.x/en/installation/configuration/running-commands/_index.md +++ b/content/os/v1.x/en/installation/configuration/running-commands/_index.md @@ -12,7 +12,7 @@ runcmd: - echo "test" > /home/rancher/test2 ``` -Commands specified using `runcmd` will be executed within the context of the `console` container. More details on the ordering of commands run in the `console` container can be found [here]({{< baseurl >}}/os/v1.x/en/installation/boot-process/built-in-system-services/#console). +Commands specified using `runcmd` will be executed within the context of the `console` container. ### Running Docker commands diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 86fc30a3512..1ac03b08994 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -46,16 +46,17 @@ For more information, see [Provisioning Drivers]({{< baseurl >}}/rancher/v2.x/en _Available as of v2.3.0_ -With this feature, you can upgrade to the latest version of Kubernetes as soon as it is released, without upgrading Rancher. This feature allows you to easily upgrade Kubernetes patch versions (i.e. `v1.15.X`), but not intended to upgrade Kubernetes minor versions (i.e. `v1.X.0`) as Kubernetes tends to deprecate or add APIs between minor versions. +With this feature, you can upgrade to the latest version of Kubernetes as soon as it is released, without upgrading Rancher. This feature allows you to easily upgrade Kubernetes patch versions (i.e. `v1.15.X`), but not intended to upgrade Kubernetes minor versions (i.e. `v1.X.0`) as Kubernetes tends to deprecate or add APIs between minor versions. The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the Rancher Kubernetes Metadata. For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see [Rancher Kubernetes Metadata]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rke-metadata/). Rancher Kubernetes Metadata contains Kubernetes version information which Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). -For more information on how metadata works and how to configure metadata config, see [Rancher Kubernetes Metadata]({{}}/rancher/v2.x/en/admin-settings/k8s-metadata). + +For more information on how metadata works and how to configure metadata config, see [Rancher Kubernetes Metadata]({{}}/rancher/v2.x/en/admin-settings/k8s-metadata/). ## Enabling Experimental Features _Available as of v2.3.0_ -Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.]({{}}/rancher/v2.x/en/installation/options/feature-flags) +Rancher includes some features that are experimental and disabled by default. Feature flags were introduced to allow you to try these features. For more information, refer to the section about [feature flags.]({{}}/rancher/v2.x/en/admin-settings/feature-flags/) diff --git a/content/rancher/v2.x/en/best-practices/containers/_index.md b/content/rancher/v2.x/en/best-practices/containers/_index.md index ce67e87ef6d..410dfb2f437 100644 --- a/content/rancher/v2.x/en/best-practices/containers/_index.md +++ b/content/rancher/v2.x/en/best-practices/containers/_index.md @@ -32,11 +32,11 @@ When possible, use a non-privileged user when running processes within your cont ### Define Resource Limits Apply CPU and memory limits to your pods. This can help manage the resources on your worker nodes and avoid a malfunctioning microservice from impacting other microservices. -In standard Kubernetes, you can set resource limits on the namespace level. In Rancher, you can set resource limits on the project level and they will propagate to all the namespaces within the project. For details, refer to the [Rancher docs]({{}}/rancher/v2.x/en/project-admin/resource-quotas/). +In standard Kubernetes, you can set resource limits on the namespace level. In Rancher, you can set resource limits on the project level and they will propagate to all the namespaces within the project. For details, refer to the Rancher docs. When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project or namespace, all containers will require a respective CPU or Memory field set during creation. To avoid setting these limits on each and every container during workload creation, a default container resource limit can be specified on the namespace. -The Kubernetes docs have more information on how resource limits can be set at the [container level](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) and the [namespace level](https://kubernetes.io/docs/concepts/policy/resource-quotas/). +The Kubernetes docs have more information on how resource limits can be set at the [container level](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) and the namespace level. ### Define Resource Requirements You should apply CPU and memory requirements to your pods. This is crucial for informing the scheduler which type of compute node your pod needs to be placed on, and ensuring it does not over-provision that node. In Kubernetes, you can set a resource requirement by defining `resources.requests` in the resource requests field in a pod's container spec. For details, refer to the [Kubernetes docs](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container). diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster/_index.md index ac8843d1ecb..9df03283a12 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster/_index.md @@ -9,7 +9,7 @@ A Rancher [administrator]({{}}/rancher/v2.x/en/admin-settings/rbac/glob 1. From the **Global** view, navigate to the **cluster** where you want to enable Istio. 1. Click **Tools > Istio.** -1. Optional: Configure member access and [resource limits]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/resources) for the Istio components. Ensure you have enough resources on your worker nodes to enable Istio. +1. Optional: Configure member access and [resource limits]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/resources/) for the Istio components. Ensure you have enough resources on your worker nodes to enable Istio. 1. Click **Enable**. 1. Click **Save**. diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md index 1313a317b15..89629d989da 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md @@ -63,9 +63,9 @@ The registry configuration here is applied during the provisioning of the cluste - **System images** are components needed to maintain the Kubernetes cluster. - **Add-ons** are used to deploy several cluster components, including network plug-ins, the ingress controller, the DNS provider, or the metrics server. -To deploy workloads that pull images from a private registry, you will need to [set up your own Kubernetes registry]({{}}/rancher/v2.x/en/k8s-in-rancher/registries/) for your project. +To deploy workloads that pull images from a private registry, you will need to set up your own Kubernetes registry for your project. -See the [RKE documentation on private registries]({{< baseurl >}}/rke/latest/en/config-options/private-registries/) for more information on the private registry for components applied during the provisioning of the cluster. +See the RKE documentation on private registries for more information on the private registry for components applied during the provisioning of the cluster. ### Authorized Cluster Endpoint diff --git a/content/rancher/v2.x/en/installation/requirements/ports/_index.md b/content/rancher/v2.x/en/installation/requirements/ports/_index.md index 5c79484b9e1..a39ef0ca510 100644 --- a/content/rancher/v2.x/en/installation/requirements/ports/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/ports/_index.md @@ -11,7 +11,7 @@ The following table lists the ports that need to be open to and from nodes that {{< ports-rancher-nodes >}} -**Note** Rancher nodes may also require additional outbound access for any external [authentication provider]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) which is configured (LDAP for example). +**Note** Rancher nodes may also require additional outbound access for any external authentication provider which is configured (LDAP for example). ## Kubernetes Cluster Nodes diff --git a/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md b/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md index daaa5b1427b..f8f82c6aab1 100644 --- a/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md +++ b/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md @@ -40,7 +40,7 @@ For information on other default alerts, refer to the section on [cluster-level ## Adding Project Alerts ->**Prerequisite:** Before you can receive project alerts, you must [add a notifier]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers). +>**Prerequisite:** Before you can receive project alerts, you must add a notifier. 1. From the **Global** view, navigate to the project that you want to configure project alerts for. Select **Tools > Alerts**. In versions prior to v2.2.0, you can choose **Resources > Alerts**. From 3f4075ff8ff59ef9790d0deeb78d396bf5b5a98a Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Wed, 20 Nov 2019 16:38:44 -0800 Subject: [PATCH 21/82] replace removed links with updated links --- content/rancher/v2.x/en/admin-settings/_index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 1ac03b08994..87ae8b08a3a 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -52,7 +52,6 @@ The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/ra Rancher Kubernetes Metadata contains Kubernetes version information which Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). - For more information on how metadata works and how to configure metadata config, see [Rancher Kubernetes Metadata]({{}}/rancher/v2.x/en/admin-settings/k8s-metadata/). ## Enabling Experimental Features From d796fc5a4037e22bcd87bef88e21d9a54f0c637c Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Fri, 6 Dec 2019 16:07:52 -0800 Subject: [PATCH 22/82] Fix broken links --- .../en/installation/requirements/_index.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index 2d4c1010be3..82577dd86b0 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -161,14 +161,14 @@ TCP/UDP | 30000-32767 | Any source that consumes NodePort services | NodePort po Protocol | Port | Source | Destination | Description -----------|------|----------|---------------|-------------- TCP | 22 | RKE node | Any node configured in Cluster Configuration File | SSH provisioning of node by RKE -TCP | 443 | Rancher nodes | Rancher agent | -TCP | 2379 | etcd nodes | etcd client requests | -TCP | 2380 | etcd nodes | etcd peer communication | +TCP | 443 | Rancher nodes | Rancher agent | +TCP | 2379 | etcd nodes | etcd client requests | +TCP | 2380 | etcd nodes | etcd peer communication | TCP | 6443 | RKE node | controlplane nodes | Kubernetes API server -TCP | 6443 | controlplane nodes | Kubernetes API server | -UDP | 8472 | etcd nodes, controlplane nodes, and worker nodes | Canal/Flannel VXLAN overlay networking | -TCP | 9099 | the node itself (local traffic, not across nodes) | Canal/Flannel livenessProbe/readinessProbe | -TCP | 10250 | etcd nodes, controlplane nodes, and worker nodes | kubelet | +TCP | 6443 | controlplane nodes | Kubernetes API server | +UDP | 8472 | etcd nodes, controlplane nodes, and worker nodes | Canal/Flannel VXLAN overlay networking | +TCP | 9099 | the node itself (local traffic, not across nodes) | Canal/Flannel livenessProbe/readinessProbe | +TCP | 10250 | etcd nodes, controlplane nodes, and worker nodes | kubelet | TCP | 10254 | the node itself (local traffic, not across nodes) | Ingress controller livenessProbe/readinessProbe The ports that need to be opened for each node depend on the node's Kubernetes role: etcd, controlplane, or worker. If you installed Rancher on a Kubernetes cluster that doesn't have all three roles on each node, refer to the [port requirements for the Rancher Kubernetes Engine (RKE).]({{}}/rke/latest/en/os/#ports) The RKE docs show a breakdown of the port requirements for each role. @@ -188,6 +188,9 @@ The following diagram depicts the ports that are opened for each [cluster type]( The following tables break down the port requirements for inbound and outbound traffic: +**Note** Rancher nodes may also require additional outbound access for any external [authentication provider]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) which is configured (LDAP for example). + +
Inbound Rules for Rancher Nodes
| Protocol | Port | Source | Description | @@ -195,6 +198,7 @@ The following tables break down the port requirements for inbound and outbound t | TCP | 80 | Load balancer/proxy that does external SSL termination | Rancher UI/API when external SSL termination is used | | TCP | 443 |
  • etcd nodes
  • controlplane nodes
  • worker nodes
  • hosted/imported Kubernetes
  • any source that needs to be able to use the Rancher UI or API
| Rancher agent, Rancher UI/API, kubectl | +
Outbound Rules for Rancher Nodes
| Protocol | Port | Source | Description | From 86e57ae4a2383cede5a3b5c4189daebeec7682d4 Mon Sep 17 00:00:00 2001 From: rawmind0 Date: Mon, 16 Dec 2019 22:33:49 +0100 Subject: [PATCH 23/82] Updated cert-manager installation/upgrade docs --- .../en/installation/ha/helm-rancher/_index.md | 23 ++-- .../options/chart-options/_index.md | 2 + .../options/upgrading-cert-manager/_index.md | 109 +++++++++++++----- .../air-gap/install-rancher/_index.md | 20 ++-- .../v2.x/en/upgrades/upgrades/ha/_index.md | 2 + 5 files changed, 102 insertions(+), 54 deletions(-) diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md index cb1a30a5233..1ac1f8e34ad 100644 --- a/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md +++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md @@ -62,20 +62,20 @@ Rancher relies on [cert-manager](https://github.com/jetstack/cert-manager) to is > **Important:** > Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher. -> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.9.1, please see our [upgrade documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). +> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). -These instructions are adapted from the [official cert-manager documentation](https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html#installing-with-helm). +These instructions are adapted from the [official cert-manager documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm). ``` # Install the CustomResourceDefinition resources separately -kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml +kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml + +> **Important:** +> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. # Create the namespace for cert-manager kubectl create namespace cert-manager -# Label the cert-manager namespace to disable resource validation -kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true - # Add the Jetstack Helm repository helm repo add jetstack https://charts.jetstack.io @@ -86,7 +86,7 @@ helm repo update helm install \ cert-manager jetstack/cert-manager \ --namespace cert-manager \ - --version v0.9.1 + --version v0.12.0 ``` Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods: @@ -94,13 +94,12 @@ Once you’ve installed cert-manager, you can verify it is deployed correctly by ``` kubectl get pods --namespace cert-manager -NAME READY STATUS RESTARTS AGE -cert-manager-7cbdc48784-rpgnt 1/1 Running 0 3m -cert-manager-webhook-5b5dd6999-kst4x 1/1 Running 0 3m -cert-manager-cainjector-3ba5cd2bcd-de332x 1/1 Running 0 3m +NAME READY STATUS RESTARTS AGE +cert-manager-5c6866597-zw7kh 1/1 Running 0 2m +cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m +cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m ``` -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 the [troubleshooting](https://docs.cert-manager.io/en/latest/getting-started/troubleshooting.html) guide. {{% /accordion %}} ### Install Rancher with Helm and Your Chosen Certificate Option diff --git a/content/rancher/v2.x/en/installation/options/chart-options/_index.md b/content/rancher/v2.x/en/installation/options/chart-options/_index.md index db92df57800..de2cfcde766 100644 --- a/content/rancher/v2.x/en/installation/options/chart-options/_index.md +++ b/content/rancher/v2.x/en/installation/options/chart-options/_index.md @@ -32,6 +32,8 @@ aliases: | `auditLog.maxSize` | 100 | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`) | | `busyboxImage` | "busybox" | `string` - Image location for busybox image used to collect audit logs _Note: Available as of v2.2.0_ | | `debug` | false | `bool` - set debug flag on rancher server | +| `certmanager.version` | "" | `string` - set cert-manager compatibility + | | `extraEnv` | [] | `list` - set additional environment variables for Rancher _Note: Available as of v2.2.0_ | | `imagePullSecrets` | [] | `list` - list of names of Secret resource containing private registry credentials | | `ingress.extraAnnotations` | {} | `map` - additional annotations to customize the ingress | diff --git a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md index 69ad051a38e..a28d310cfda 100644 --- a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md +++ b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md @@ -6,7 +6,8 @@ weight: 2040 Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, two 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 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. +2. [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: @@ -20,24 +21,36 @@ To address these changes, this guide will do two things: In order to upgrade cert-manager, follow these instructions: {{% accordion id="normal" label="Upgrading cert-manager with Internet access" %}} -1. Back up existing resources as a precaution +1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution ```plain - kubectl get -o yaml --all-namespaces issuer,clusterissuer,certificates > cert-manager-backup.yaml + kubectl get -o yaml --all-namespaces \ + issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml ``` -1. Delete the existing deployment +> **Important:** +> If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. [Additional annotation changes](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes) + +1. [Uninstall existing deployment](https://cert-manager.io/docs/installation/uninstall/kubernetes/#uninstalling-with-helm) ```plain helm delete --purge cert-manager ``` -1. Install the CustomResourceDefinition resources separately + Delete the CustomResourceDefinition using the link to the version vX.Y you installed ```plain - kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml + kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml ``` -1. Label the kube-system namespace to disable resource validation +1. Install the CustomResourceDefinition resources separately ```plain - kubectl label namespace kube-system certmanager.k8s.io/disable-validation=true + kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml + ``` + +> **Important:** +> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. + +1. Create the namespace for cert-manager if needed + ```plain + kubectl create namespace cert-manager ``` 1. Add the Jetstack Helm repository @@ -52,8 +65,17 @@ In order to upgrade cert-manager, follow these instructions: 1. Install the new version of cert-manager ```plain - helm install --version 0.9.1 --name cert-manager --namespace kube-system jetstack/cert-manager + helm install \ + cert-manager jetstack/cert-manager \ + --namespace cert-manager \ + --version v0.12.0 ``` + +1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources) + ```plain + kubectl apply -f cert-manager-backup.yaml + ``` + {{% /accordion %}} {{% accordion id="airgap" label="Upgrading cert-manager in an airgapped environment" %}} @@ -73,23 +95,24 @@ Before you can perform the upgrade, you must prepare your air gapped environment 1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://hub.helm.sh/charts/jetstack/cert-manager). ```plain - helm fetch jetstack/cert-manager --version v0.9.1 + helm fetch jetstack/cert-manager --version v0.12.0 ``` 1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files. ```plain - helm template ./cert-manager-v0.9.1.tgz --output-dir . \ - --name cert-manager --namespace kube-system \ + helm template ./cert-manager-v0.12.0.tgz --output-dir . \ + --name cert-manager --namespace cert-manager \ --set image.repository=/quay.io/jetstack/cert-manager-controller --set webhook.image.repository=/quay.io/jetstack/cert-manager-webhook --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector ``` -1. Download the required CRD file for cert-manager +1. Download the required CRD file for cert-manager (old and new) ```plain - curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml + curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml + curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml ``` ### Install cert-manager @@ -97,13 +120,24 @@ Before you can perform the upgrade, you must prepare your air gapped environment 1. Back up existing resources as a precaution ```plain - kubectl get -o yaml --all-namespaces issuer,clusterissuer,certificates > cert-manager-backup.yaml + kubectl get -o yaml --all-namespaces \ + issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml ``` +> **Important:** +> If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. [Additional annotation changes](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes) + 1. Delete the existing cert-manager installation ```plain - kubectl -n kube-system delete deployment,sa,clusterrole,clusterrolebinding -l 'app=cert-manager' -l 'chart=cert-manager-v0.5.2' + kubectl -n cert-manager \ + delete deployment,sa,clusterrole,clusterrolebinding \ + -l 'app=cert-manager' -l 'chart=cert-manager-v0.5.2' + ``` + + Delete the CustomResourceDefinition using the link to the version vX.Y you installed + ```plain + kubectl delete -f cert-manager/cert-manager-crd-old.yaml ``` 1. Install the CustomResourceDefinition resources separately @@ -112,42 +146,53 @@ Before you can perform the upgrade, you must prepare your air gapped environment kubectl apply -f cert-manager/cert-manager-crd.yaml ``` -1. Label the kube-system namespace to disable resource validation +> **Important:** +> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. + +1. Create the namespace for cert-manager ```plain - kubectl label namespace kube-system certmanager.k8s.io/disable-validation=true + kubectl create namespace cert-manager ``` 1. Install cert-manager ```plain - kubectl -n kube-system apply -R -f ./cert-manager + kubectl -n cert-manager apply -R -f ./cert-manager ``` + +1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources) + ```plain + kubectl apply -f cert-manager-backup.yaml + ``` + {{% /accordion %}} Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods: ``` -kubectl get pods --namespace kube-system +kubectl get pods --namespace cert-manager -NAME READY STATUS RESTARTS AGE -cert-manager-7cbdc48784-rpgnt 1/1 Running 0 3m -cert-manager-webhook-5b5dd6999-kst4x 1/1 Running 0 3m -cert-manager-cainjector-3ba5cd2bcd-de332x 1/1 Running 0 3m +NAME READY STATUS RESTARTS AGE +cert-manager-5c6866597-zw7kh 1/1 Running 0 2m +cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m +cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m ``` -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. - -> **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) - ## Cert-Manager API change and data migration Cert-manager has deprecated the use of the `certificate.spec.acme.solvers` field and will drop support for it completely in an upcoming release. Per the cert-manager documentation, a new format for configuring ACME certificate resources was introduced in v0.8. Specifically, the challenge solver configuration field was moved. Both the old format and new are supported as of v0.9, but support for the old format will be dropped in an upcoming release of cert-manager. The cert-manager documentation strongly recommends that after upgrading you update your ACME Issuer and Certificate resources to the new format. -Details about the change and migration instructions can be found in the [cert-manager v0.7 to v0.8 upgrade instructions](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.7-0.8.html). +Details about the change and migration instructions can be found in the [cert-manager v0.7 to v0.8 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/). + +The v0.11 release marks the removal of the v1alpha1 API that was used in previous versions of cert-manager, as well as our API group changing to be cert-manager.io instead of certmanager.k8s.io. + +We have also removed support for the old configuration format that was deprecated in the v0.8 release. This means you must transition to using the new solvers style configuration format for your ACME issuers before upgrading to v0.11. For more information, see the [upgrading to v0.8 guide](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/). + +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/). + 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 c4cb3081474..ac08fb75fd5 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 @@ -71,6 +71,7 @@ When setting up the Rancher Helm template, there are several options in the Helm | Chart Option | Chart Value | Description | | ----------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `certmanager.version` | "" | Configure proper Rancher TLS issuer depending of running cert-manager version. | | `systemDefaultRegistry` | `` | 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_ | @@ -81,7 +82,7 @@ Based on the choice your made in [B. Choose your SSL Configuration](#b-optional- By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface. > **Note:** -> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.9.1, please see our [upgrade cert-manager documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). +> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade cert-manager documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). 1. From a system connected to the internet, add the cert-manager repo to Helm. @@ -93,13 +94,13 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat 1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://hub.helm.sh/charts/jetstack/cert-manager). ```plain - helm fetch jetstack/cert-manager --version v0.9.1 + helm fetch jetstack/cert-manager --version v0.12.0 ``` 1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files. ```plain - helm template ./cert-manager-v0.9.1.tgz --output-dir . \ + helm template ./cert-manager-v0.12.0.tgz --output-dir . \ --name cert-manager --namespace cert-manager \ --set image.repository=/quay.io/jetstack/cert-manager-controller --set webhook.image.repository=/quay.io/jetstack/cert-manager-webhook @@ -109,7 +110,7 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat 1. Download the required CRD file for cert-manager ```plain - curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml + curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml ``` 1. Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools. @@ -120,12 +121,14 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat `` | The version number of the output tarball. `` | The DNS name you pointed at your load balancer. `` | The DNS name for your private registry. + `` | Cert-manager version running on k8s cluster. ```plain helm template ./rancher-.tgz --output-dir . \ --name rancher \ --namespace cattle-system \ --set hostname= \ + --set certmanager.version= \ --set rancherImage=/rancher/rancher \ --set systemDefaultRegistry= \ # Available as of v2.2.0, set a default private registry to be used in Rancher --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts @@ -182,18 +185,15 @@ If you are using self-signed certificates, install cert-manager: kubectl create namespace cert-manager ``` -1. Label the cert-manager namespace to disable resource validation. - - ```plain - kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true - ``` - 1. Create the cert-manager CustomResourceDefinitions (CRDs). ```plain kubectl apply -f cert-manager/cert-manager-crd.yaml ``` +> **Important:** +> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. + 1. Launch cert-manager. ```plain kubectl apply -R -f ./cert-manager diff --git a/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md index fc26a3018f5..864a5b88eb7 100644 --- a/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md +++ b/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md @@ -109,6 +109,7 @@ This section describes how to upgrade normal (Internet-connected) or air gap ins `` | The version number of the output tarball. `` | The DNS name you pointed at your load balancer. `` | The DNS name for your private registry. + `` | Cert-manager version running on k8s cluster. {{% accordion id="self-signed" label="Option A-Default Self-Signed Certificate" %}} @@ -117,6 +118,7 @@ helm template ./rancher-.tgz --output-dir . \ --name rancher \ --namespace cattle-system \ --set hostname= \ + --set certmanager.version= \ --set rancherImage=/rancher/rancher \ --set systemDefaultRegistry= \ # Available as of v2.2.0, set a default private registry to be used in Rancher --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts From 1f0824553e8f79c64b82ca0bd1972a4d9a9f39be Mon Sep 17 00:00:00 2001 From: catherineluse Date: Mon, 16 Dec 2019 18:39:44 -0700 Subject: [PATCH 24/82] Explain how to assign global roles to groups --- .../rbac/default-custom-roles/_index.md | 162 ++++++++++++++---- .../rbac/global-permissions/_index.md | 74 +++++--- 2 files changed, 179 insertions(+), 57 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md index 68f4f3c9cab..bc2ac911606 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md @@ -2,70 +2,166 @@ title: Custom Roles weight: 1128 aliases: - - /rancher/v2.x/en/tasks/global-configuration/roles/ + - /rancher/v2.x/en/tasks/global-configuration/roles/ --- Within Rancher, _roles_ determine what actions a user can make within a cluster or project. Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access. ->**Prerequisites:** -> ->To complete the tasks on this page, the following permissions are required: -> ->- [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/). ->- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) role assigned. +This section covers the following topics: -## Adding A Custom Role +- [Prerequisites](#prerequisites) +- [Creating a custom role for a cluster or project](#creating-a-custom-role-for-a-cluster-or-project) +- [Creating a custom global role that inherits from an existing role](#creating-a-custom-global-role-that-inherits-from-an-existing-role) +- [Creating a custom global role that does not inherit from another role](#creating-a-custom-global-role-that-does-not-inherit-from-another-role) +- [Deleting a custom global role](#deleting-a-custom-global-role) +- [Assigning a custom global role to a group](#assigning-a-custom-global-role-to-a-group) + +## Prerequisites + +To complete the tasks on this page, one of the following permissions are required: + + - [Administrator Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/). + - [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/#global-permissions-reference) role assigned. + +## Creating A Custom Role for a Cluster or Project While Rancher comes out-of-the-box with a set of default user roles, you can also create default custom roles to provide users with very specific permissions within Rancher. -1. From the **Global** view, select **Security > Roles** from the main menu. +The steps to add custom roles differ depending on the version of Rancher. -1. **v2.0.7 and later only:** Select a tab to determine the scope of the roles you're adding. The tabs are: +{{% tabs %}} +{{% tab "Rancher v2.0.7+" %}} - - **Cluster** +1. From the **Global** view, select **Security > Roles** from the main menu. - The role is valid for assignment when adding/managing members to _only_ clusters. +1. Select a tab to determine the scope of the roles you're adding. The tabs are: - - **Project** + - **Cluster:** The role is valid for assignment when adding/managing members to _only_ clusters. + - **Project:** The role is valid for assignment when adding/managing members to _only_ projects. - The role is valid for assignment when adding/managing members to _only_ projects. +1. Click **Add Cluster/Project Role.** - >**Note:** You cannot edit the Global tab. +1. **Name** the role. -1. Click **Add Cluster/Project Role**. +1. Optional: Choose the **Cluster/Project Creator Default** option to assign this role to a user when they create a new cluster or project. Using this feature, you can expand or restrict the default roles for cluster/project creators. -1. **Name** the role. + > Out of the box, the Cluster Creator Default and the Project Creator Default roles are `Cluster Owner` and `Project Owner` respectively. -1. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/). +1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role. - Locked roles cannot be assigned to users. + > When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. -1. **v2.0.7 and later only:** Choose a **Cluster/Project Creator Default** option setting. Use this option to set if the role is assigned to a user when they create a new cluster or project. Using this feature, you can expand or restrict the default roles for cluster/project creators. + You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign. - >**Note:** Out of the box, the Cluster Creator Default and the Project Creator Default roles are `Cluster Owner` and `Project Owner` respectively. +1. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. -1. **v2.0.6 and earlier only:** Assign the role a **Context**. Context determines the scope of role assigned to the user. The contexts are: +1. Click **Create**. - - **All** +{{% /tab %}} +{{% tab "Rancher prior to v2.0.7" %}} - The user can use their assigned role regardless of context. This role is valid for assignment when adding/managing members to clusters or projects. +1. From the **Global** view, select **Security > Roles** from the main menu. - - **Cluster** +1. Click **Add Cluster/Project Role**. - This role is valid for assignment when adding/managing members to _only_ clusters. +1. **Name** the role. - - **Project** +1. Choose whether to set the role to a status of [locked]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/). - This role is valid for assignment when adding/managing members to _only_ projects. + > **Note:** Locked roles cannot be assigned to users. -6. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role. +1. Assign the role a **Context**. Context determines the scope of role assigned to the user. The contexts are: - >**Note:** When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. + - **All:** The user can use their assigned role regardless of context. This role is valid for assignment when adding/managing members to clusters or projects. - You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign. + - **Cluster:** This role is valid for assignment when adding/managing members to _only_ clusters. -7. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. + - **Project:** This role is valid for assignment when adding/managing members to _only_ projects. -8. Click **Create**. +1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role. + + > When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. + + You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign. + +1. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. + +1. Click **Create**. + +{{% /tab %}} +{{% /tabs %}} + +## Creating a Custom Global Role that Inherits from an Existing Role + +_Available as of v2.3.4_ + +If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role that inherits from another role, such as the administrator role, so that you only have to configure the variations between the new and existing roles. + +The custom global role can then be assigned to a user or group so that the custom global role takes effect the first time the user or users sign into Rancher. + +To create a custom global role based on an existing role, + +1. Go to the **Global** view and click **Security > Roles.** +1. On the **Global** tab, go to the role that the custom global role will be based on. Click **Ellipsis (…) > Clone.** +Enter a name for the role. +1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.** +1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role. +1. Click **Save.** + +## Creating a Custom Global Role that Does Not Inherit from Another Role + +_Available as of v2.3.4_ + +Custom global roles don't have to be based on existing roles. To create a custom global role by choosing the specific Kubernetes resource operations that should be allowed for the role, follow these steps: + +1. Go to the **Global** view and click **Security > Roles.** +1. On the **Global** tab, click **Add Global Role.** +1. Enter a name for the role. +1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.** +1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role. +1. Click **Save.** + +## Deleting a Custom Global Role + +_Available as of v2.3.4_ + +When deleting a custom global role, all global role bindings with this custom role are deleted. + +If a user is only assigned one custom global role, and the role is deleted, the user would lose access to Rancher. For the user to regain access, an administrator would need to edit the user and apply new global permissions. + +Custom global roles can be deleted, but built-in roles cannot be deleted. + +To delete a custom global role, + +1. Go to the **Global** view and click **Security > Roles.** +2. On the **Global** tab, go to the custom global role that should be deleted and click **Ellipsis (…) > Delete.** +3. Click **Delete.** + +## Assigning a Custom Global Role to a Group + +_Available as of v2.3.4_ + +If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher. + +When a user in the group logs in, they get the built-in Standard User global role by default. They will also get the permissions assigned to their groups. + +If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have their individual Standard User role. + +> **Prerequisites:** You can only assign a global role to a group if: +> +> * You have set up an [external authentication provider]({{}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication) +> * The external authentication provider suppports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) +> * You have already set up at least one user group with the authentication provider + +To assign a custom global role to a group, follow these steps: + +1. From the **Global** view, go to **Security > Groups.** +1. Click **Assign Global Role.** +1. In the **Select Group To Add** field, choose the existing group that will be assigned the custom global role. +1. In the **Custom** section, choose any custom global role that will be assigned to the group. +1. Optional: In the **Global Permissions** or **Built-in** sections, select any additional permissions that the group should have. +1. Click **Create.** + +**Result:** The custom global role will take effect when the users in the group log into Rancher. \ No newline at end of file diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index 829f579537e..82b22032a63 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -7,43 +7,43 @@ _Permissions_ are individual access rights that you can assign when selecting a Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are two default global permissions: `Administrator` and `Standard User`. -- **Administrator:** +- **Administrator:** These users have full control over the entire Rancher system and all clusters within it. - These users have full control over the entire Rancher system and all clusters within it. +- **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters. -- **Standard User:** +You cannot update or delete the built-in Global Permissions. - These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters. +This section covers the following topics: ->**Note:** You cannot create, update, or delete Global Permissions. +- [Global permission assignment](#global-permission-assignment) +- [Custom global permissions](#custom-global-permissions) + - [Custom global permissions reference](#custom-global-permissions-reference) + - [Configuring default global permissions for new users](#configuring-default-global-permissions) + - [Configuring global permissions for existing individual users](#configuring-global-permissions-for-existing-individual-users) + - [Configuring global permissions for groups](#configuring-global-permissions-for-groups) # Global Permission Assignment Assignment of global permissions to a user depends on their authentication source: external or local. -- **External Authentication** - - When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the `Standard User` global permission. - -- **Local Authentication** - - When you create a new local user, you assign them a global permission as you complete the **Add User** form. +- **External Authentication:** When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the `Standard User` global permission. +- **Local Authentication:** When you create a new local user, you assign them a global permission as you complete the **Add User** form. # Custom Global Permissions Using custom permissions is convenient for providing users with narrow or specialized access to Rancher. -When a user from an [external authentication source]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in from the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters. +When a user from an [external authentication source]({{}}/rancher/v2.x/en/admin-settings/authentication/) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in from the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters. However, in some organizations, these permissions may extend too much access. Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a more restrictive set of custom global permissions. The default roles, Administrator and Standard User, each come with multiple global permissions built into them. The Administrator role includes all global permissions, while the default user role includes three global permissions: Create Clusters, Use Catalog Templates, and User Base, which is equivalent to the minimum permission to log in to Rancher. In other words, the custom global permissions are modularized so that if you want to change the default user role permissions, you can choose which subset of global permissions are included in the new default user role. -Administrators can enforce custom global permissions in two ways: +Administrators can enforce custom global permissions in multiple ways: -- Changing the [default permissions for new users](#configuring-default-global-permissions) - -- Editing the [permissions of an existing user](#configuring-global-permissions-for-individual-users) +- [Changing the default permissions for new users](#configuring-default-global-permissions) +- [Editing the permissions of an existing user](#configuring-global-permissions-for-individual-users) +- [Assigning a custom global permission to a group](#assigning-a-custom-global-permission-to-a-group) ### Custom Global Permissions Reference @@ -62,25 +62,25 @@ The following table lists each custom global permission available and whether it | Manage Settings | ✓ | | | Manage Users | ✓ | | | Use Catalog Templates | ✓ | ✓ | -| User Base* (Basic log-in access) | ✓ | ✓ | +| User Base\* (Basic log-in access) | ✓ | ✓ | -> *This role has two names: +> \*This role has two names: > > - When you go to the Users tab and edit a user's global role, this role is called Login Access in the custom global permissions list. > - When you go to the Security tab and edit the roles from the roles page, this role is called User Base. For details on which Kubernetes resources correspond to each global permission, you can go to the **Global** view in the Rancher UI. Then click **Security > Roles** and go to the **Global** tab. If you click an individual role, you can refer to the **Grant Resources** table to see all of the operations and resources that are permitted by the role. -> **Notes:** +> **Notes:** > ->- Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`. ->- When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. +> - Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`. +> - When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. ### Configuring Default Global Permissions If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions. ->**Note:** Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user. +> **Note:** Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user. To change the default global permissions that are assigned to external users upon their first log in, follow these steps: @@ -94,7 +94,7 @@ To change the default global permissions that are assigned to external users upo **Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column. -### Configuring Global Permissions for Individual Users +### Configuring Global Permissions for Existing Individual Users To configure permission for a user, @@ -109,3 +109,29 @@ To configure permission for a user, 1. Click **Save.** > **Result:** The user's global permissions have been updated. + +### Configuring Global Permissions for Groups + +_Available as of v2.3.4_ + +If you have a group of individuals that need the same level of access in Rancher, in can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher. + +When a user in the group logs in, they will get the built-in Standard User global role by default. They will also get the permissions assigned to their groups. + +If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have their individual Standard User role. + +> **Prerequisites:** You can only assign a global role to a group if: +> +> * You have set up an [external authentication provider]({{}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication) +> * The external authentication provider suppports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) +> * You have already set up at least one user group with the authentication provider + +To assign a custom global role to a group, follow these steps: + +1. From the **Global** view, go to **Security > Groups.** +1. Click **Assign Global Role.** +1. In the **Select Group To Add** field, choose the existing group that will be assigned the custom global role. +1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have. +1. Click **Create.** + +**Result:** The custom global role will take effect when the users in the group log into Rancher. \ No newline at end of file From 63ba7b1fd5f75619e58aca8d4b55411bc9704613 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 17 Dec 2019 15:23:35 -0700 Subject: [PATCH 25/82] Remove reference to inheritance for cloned roles --- .../rbac/default-custom-roles/_index.md | 20 +++++++++---------- .../rbac/global-permissions/_index.md | 4 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md index bc2ac911606..ff2f0275228 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md @@ -13,8 +13,8 @@ This section covers the following topics: - [Prerequisites](#prerequisites) - [Creating a custom role for a cluster or project](#creating-a-custom-role-for-a-cluster-or-project) -- [Creating a custom global role that inherits from an existing role](#creating-a-custom-global-role-that-inherits-from-an-existing-role) -- [Creating a custom global role that does not inherit from another role](#creating-a-custom-global-role-that-does-not-inherit-from-another-role) +- [Creating a custom global role that copies rules from an existing role](#creating-a-custom-global-role-that-copies-rules-from-an-existing-role) +- [Creating a custom global role that does not copy rules from another role](#creating-a-custom-global-role-that-does-not-copy-rules-from-another-role) - [Deleting a custom global role](#deleting-a-custom-global-role) - [Assigning a custom global role to a group](#assigning-a-custom-global-role-to-a-group) @@ -51,11 +51,11 @@ The steps to add custom roles differ depending on the version of Rancher. 1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role. - > When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. + > When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign. -1. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. +1. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. Note: When a custom role inherits from a parent role, the parent role cannot be deleted until the child role is deleted. 1. Click **Create**. @@ -82,22 +82,22 @@ The steps to add custom roles differ depending on the version of Rancher. 1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role. - > When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. + > When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign. -1. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. +1. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. Note: When a custom role inherits from a parent role, the parent role cannot be deleted until the child role is deleted. 1. Click **Create**. {{% /tab %}} {{% /tabs %}} -## Creating a Custom Global Role that Inherits from an Existing Role +## Creating a Custom Global Role that Copies Rules from an Existing Role _Available as of v2.3.4_ -If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role that inherits from another role, such as the administrator role, so that you only have to configure the variations between the new and existing roles. +If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role in which all of the rules from another role, such as the administrator role, are copied into a new role. This allows you to only configure the variations between the existing role and the new role. The custom global role can then be assigned to a user or group so that the custom global role takes effect the first time the user or users sign into Rancher. @@ -105,12 +105,12 @@ To create a custom global role based on an existing role, 1. Go to the **Global** view and click **Security > Roles.** 1. On the **Global** tab, go to the role that the custom global role will be based on. Click **Ellipsis (…) > Clone.** -Enter a name for the role. +1. Enter a name for the role. 1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.** 1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role. 1. Click **Save.** -## Creating a Custom Global Role that Does Not Inherit from Another Role +## Creating a Custom Global Role that Does Not Copy Rules from Another Role _Available as of v2.3.4_ diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index 82b22032a63..d8d9058b5a6 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -33,7 +33,7 @@ Assignment of global permissions to a user depends on their authentication sourc Using custom permissions is convenient for providing users with narrow or specialized access to Rancher. -When a user from an [external authentication source]({{}}/rancher/v2.x/en/admin-settings/authentication/) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in from the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters. +When a user from an [external authentication source]({{}}/rancher/v2.x/en/admin-settings/authentication/) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in for the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters. However, in some organizations, these permissions may extend too much access. Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a more restrictive set of custom global permissions. @@ -74,7 +74,7 @@ For details on which Kubernetes resources correspond to each global permission, > **Notes:** > > - Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`. -> - When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. +> - When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. ### Configuring Default Global Permissions From 176c33a332a92ca41228992a803393d13d56152a Mon Sep 17 00:00:00 2001 From: catherineluse Date: Wed, 18 Dec 2019 16:34:07 -0700 Subject: [PATCH 26/82] Clarify group roles docs --- .../rbac/default-custom-roles/_index.md | 12 ++++----- .../rbac/global-permissions/_index.md | 25 ++++++++++++++++--- 2 files changed, 27 insertions(+), 10 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md index ff2f0275228..8bfc1edf915 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md @@ -64,7 +64,7 @@ The steps to add custom roles differ depending on the version of Rancher. 1. From the **Global** view, select **Security > Roles** from the main menu. -1. Click **Add Cluster/Project Role**. +1. Click **Add Role**. 1. **Name** the role. @@ -72,7 +72,7 @@ The steps to add custom roles differ depending on the version of Rancher. > **Note:** Locked roles cannot be assigned to users. -1. Assign the role a **Context**. Context determines the scope of role assigned to the user. The contexts are: +1. In the **Context** dropdown menu, choose the scope of the role assigned to the user. The contexts are: - **All:** The user can use their assigned role regardless of context. This role is valid for assignment when adding/managing members to clusters or projects. @@ -95,7 +95,7 @@ The steps to add custom roles differ depending on the version of Rancher. ## Creating a Custom Global Role that Copies Rules from an Existing Role -_Available as of v2.3.4_ +_Available as of v2.4_ If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role in which all of the rules from another role, such as the administrator role, are copied into a new role. This allows you to only configure the variations between the existing role and the new role. @@ -112,7 +112,7 @@ To create a custom global role based on an existing role, ## Creating a Custom Global Role that Does Not Copy Rules from Another Role -_Available as of v2.3.4_ +_Available as of v2.4_ Custom global roles don't have to be based on existing roles. To create a custom global role by choosing the specific Kubernetes resource operations that should be allowed for the role, follow these steps: @@ -125,7 +125,7 @@ Custom global roles don't have to be based on existing roles. To create a custom ## Deleting a Custom Global Role -_Available as of v2.3.4_ +_Available as of v2.4_ When deleting a custom global role, all global role bindings with this custom role are deleted. @@ -141,7 +141,7 @@ To delete a custom global role, ## Assigning a Custom Global Role to a Group -_Available as of v2.3.4_ +_Available as of v2.4_ If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher. diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index d8d9058b5a6..0a6a7abc260 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -16,6 +16,8 @@ You cannot update or delete the built-in Global Permissions. This section covers the following topics: - [Global permission assignment](#global-permission-assignment) + - [Global permissions for new local users](#global-permissions-for-new-local-users) + - [Global permissions for users with external authentication](#global-permissions-for-users-with-external-authentication) - [Custom global permissions](#custom-global-permissions) - [Custom global permissions reference](#custom-global-permissions-reference) - [Configuring default global permissions for new users](#configuring-default-global-permissions) @@ -24,10 +26,25 @@ This section covers the following topics: # Global Permission Assignment -Assignment of global permissions to a user depends on their authentication source: external or local. +Global permissions for local users are assigned differently than users who log in to Rancher using external authentication. -- **External Authentication:** When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the `Standard User` global permission. -- **Local Authentication:** When you create a new local user, you assign them a global permission as you complete the **Add User** form. +### Global Permissions for New Local Users + +When you create a new local user, you assign them a global permission as you complete the **Add User** form. + +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. You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions) + +### Global Permissions for Users with External Authentication + +When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the `Standard User` global permission by default. + +When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users. + +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) + +As of Rancher v2.4, 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. # Custom Global Permissions @@ -112,7 +129,7 @@ To configure permission for a user, ### Configuring Global Permissions for Groups -_Available as of v2.3.4_ +_Available as of v2.4_ If you have a group of individuals that need the same level of access in Rancher, in can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher. From 85cb52e87bea85759511a70e4ffcb88a95b7db0d Mon Sep 17 00:00:00 2001 From: catherineluse Date: Fri, 20 Dec 2019 12:11:37 -0700 Subject: [PATCH 27/82] Respond to feedback on RBAC doc --- .../en/admin-settings/rbac/global-permissions/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index 0a6a7abc260..c857bf4b73d 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -36,8 +36,6 @@ To see the default permissions for new users, go to the **Global** view and clic ### Global Permissions for Users with External Authentication -When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the `Standard User` global permission by default. - When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users. 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) @@ -133,9 +131,11 @@ _Available as of v2.4_ If you have a group of individuals that need the same level of access in Rancher, in can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher. -When a user in the group logs in, they will get the built-in Standard User global role by default. They will also get the permissions assigned to their groups. +After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher. The users will gain the permissions from the custom global role in addition to the **New User Default** global permissions. -If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have their individual Standard User role. +By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions) + +If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have the roles that were marked as **New User Default.** > **Prerequisites:** You can only assign a global role to a group if: > From 84fe7ddbaf62f91265bcdad76f4611925b5549e0 Mon Sep 17 00:00:00 2001 From: catherineluse Date: Fri, 20 Dec 2019 15:00:09 -0700 Subject: [PATCH 28/82] Respond to feedback on RBAC doc --- .../rbac/global-permissions/_index.md | 28 +++++++++++++++---- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index c857bf4b73d..f66580a89f4 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -23,6 +23,7 @@ This section covers the following topics: - [Configuring default global permissions for new users](#configuring-default-global-permissions) - [Configuring global permissions for existing individual users](#configuring-global-permissions-for-existing-individual-users) - [Configuring global permissions for groups](#configuring-global-permissions-for-groups) + - [Refreshing group memberships](#refreshing-group-memberships) # Global Permission Assignment @@ -129,13 +130,15 @@ To configure permission for a user, _Available as of v2.4_ -If you have a group of individuals that need the same level of access in Rancher, in can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher. +If you have a group of individuals that need the same level of access in Rancher, it can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher. -After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher. The users will gain the permissions from the custom global role in addition to the **New User Default** global permissions. +After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher. -By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions) +For existing users, the new permissions will take effect when the users log out of Rancher and back in again, or when an administrator [refreshes the group memberships.](#refreshing-group-memberships) -If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have the roles that were marked as **New User Default.** +For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions) + +If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default.** Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,]((#refreshing-group-memberships)) whichever comes first. > **Prerequisites:** You can only assign a global role to a group if: > @@ -151,4 +154,19 @@ To assign a custom global role to a group, follow these steps: 1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have. 1. Click **Create.** -**Result:** The custom global role will take effect when the users in the group log into Rancher. \ No newline at end of file +**Result:** The custom global role will take effect when the users in the group log into Rancher. + +### Refreshing Group Memberships + +When an administrator updates the global permissions for a group, the changes take effect for individual group members after they log out of Rancher and log in again. + +To make the changes take effect immediately, an administrator or cluster owner can refresh group memberships. + +An administrator might also want to refresh group memberships if a user is removed from a group in the external authentication service. In that case, the refresh makes Rancher aware that the user was removed from the group. + +To refresh group memberships, + +1. From the **Global** view, click **Security > Users.** +1. Click **Refresh Group Memberships.** + +**Result:** Any changes to the group members' permissions will take effect. \ No newline at end of file From 3ef9e40bd817f183d4e90a6c81fd8ba7a158b59c Mon Sep 17 00:00:00 2001 From: catherineluse Date: Wed, 18 Dec 2019 22:54:11 -0700 Subject: [PATCH 29/82] Update security docs for Rancher v2.4 --- content/rancher/v2.x/en/security/_index.md | 31 ++++++++- .../v2.x/en/security/security-scan/_index.md | 64 +++++++++++++++++++ 2 files changed, 93 insertions(+), 2 deletions(-) create mode 100644 content/rancher/v2.x/en/security/security-scan/_index.md diff --git a/content/rancher/v2.x/en/security/_index.md b/content/rancher/v2.x/en/security/_index.md index 913927b32ed..123a516aca2 100644 --- a/content/rancher/v2.x/en/security/_index.md +++ b/content/rancher/v2.x/en/security/_index.md @@ -20,6 +20,29 @@ weight: 7505 +Security is at the heart of all Rancher features. From integrating with all the popular authentication tools and services, to an enterprise grade [RBAC capability,]({{}}/rancher/v2.x/en/admin-settings/rbac) Rancher makes your Kubernetes clusters even more secure. + +On this page, we provide security-related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters: + +- [Running a CIS security scan on a Kubernetes cluster](#running-a-cis-security-scan-on-a-kubernetes-cluster) +- [Guide to hardening Rancher installations](#rancher-hardening-guide) +- [The CIS Benchmark and self-assessment](#the-cis-benchmark-and-self-assessment) +- [Third-party penetration test reports](#third-party-penetration-test-reports) +- [Rancher CVEs and resolutions](#rancher-cves-and-resolutions) +- [Security Tips and Best Practices](#security-tips-and-best-practices) + +### Running a CIS Security Scan on a Kubernetes Cluster + +_Available as of v2.4_ + +Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS (Center for Internet Security) Kubernetes Benchmark. + +The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. + +When Rancher scans a cluster, it generates a report showing the results of each test, including the number of passed, skipped, and failed tests. The report also includes guidance on how to configure the cluster so that the failing tests will pass. + +For details, refer to the section on [security scans.]({{}}/rancher/v2.x/en/security/security-scan) + ### Rancher Hardening Guide The Rancher Hardening Guide is based off of controls and best practices found in the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) 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. @@ -28,7 +51,7 @@ The Rancher Hardening Guide is based off of controls and best practices found in - [Hardening Guide for Rancher v2.2.x with Kubernetes 1.13]({{< baseurl >}}/rancher/v2.x/en/security/hardening-2.2/) - [Hardening Guide for Rancher v2.3.x with Kubernetes 1.15]({{< baseurl >}}/rancher/v2.x/en/security/hardening-2.3/) -### CIS Benchmark Rancher Self-Assessment +### The CIS Benchmark and Self-Assessment The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster. @@ -39,7 +62,7 @@ Because Rancher and RKE install Kubernetes services as Docker containers, many o - [CIS Kubernetes Benchmark 1.4.1 - Rancher 2.2.x with Kubernetes 1.13]({{< baseurl >}}/rancher/v2.x/en/security/benchmark-2.2/#cis-kubernetes-benchmark-1-4-1-rancher-2-2-x-with-kubernetes-1-13) - [CIS Kubernetes Benchmark 1.4.1 - Rancher 2.3.x with Kubernetes 1.15]({{< baseurl >}}/rancher/v2.x/en/security/benchmark-2.3/#cis-kubernetes-benchmark-1-4-1-rancher-2-3-x-with-kubernetes-1-15) -### Third Party Pen Test Reports +### Third-party Penetration Test Reports Rancher periodically hires third parties to perform security audits and penetration tests of the Rancher 2.x software stack. The environments under test follow the Rancher provided hardening guides at the time of the testing. Results are posted when the third party has also verified fixes classified MEDIUM or above. @@ -62,3 +85,7 @@ Rancher is committed to informing the community of security issues in our produc | [CVE-2019-13209](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13209) | The vulnerability is known as a [Cross-Site Websocket Hijacking attack](https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html). This attack allows an exploiter to gain access to clusters managed by Rancher with the roles/permissions of a victim. It requires that a victim to be logged into a Rancher server and then access a third-party site hosted by the exploiter. Once that is accomplished, the exploiter is able to execute commands against the Kubernetes API with the permissions and identity of the victim. Reported by Matt Belisle and Alex Stevenson from Workiva. | 15 Jul 2019 | [Rancher v2.2.5](https://github.com/rancher/rancher/releases/tag/v2.2.5), [Rancher v2.1.11](https://github.com/rancher/rancher/releases/tag/v2.1.11) and [Rancher v2.0.16](https://github.com/rancher/rancher/releases/tag/v2.0.16) | | [CVE-2019-14436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14436) | The vulnerability allows a member of a project that has access to edit role bindings to be able to assign themselves or others a cluster level role granting them administrator access to that cluster. The issue was found and reported by Michal Lipinski at Nokia. | 5 Aug 2019 | [Rancher v2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) and [Rancher v2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) | | [CVE-2019-14435](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14435) | This vulnerability allows authenticated users to potentially extract otherwise private data out of IPs reachable from system service containers used by Rancher. This can include but not only limited to services such as cloud provider metadata services. Although Rancher allow users to configure whitelisted domains for system service access, this flaw can still be exploited by a carefully crafted HTTP request. The issue was found and reported by Matt Belisle and Alex Stevenson at Workiva. | 5 Aug 2019 | [Rancher v2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) and [Rancher v2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) | + +### Security Tips and Best Practices + +Our [best practices guide]({{}}/rancher/v2.x/en/best-practices/management/#tips-for-security) includes basic tips for increasing security in Rancher. \ No newline at end of file diff --git a/content/rancher/v2.x/en/security/security-scan/_index.md b/content/rancher/v2.x/en/security/security-scan/_index.md new file mode 100644 index 00000000000..6848f75f25a --- /dev/null +++ b/content/rancher/v2.x/en/security/security-scan/_index.md @@ -0,0 +1,64 @@ +--- +title: Security Scans +weight: 1 +--- + +_Available as of v2.4_ + +Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS (Center for Internet Security) Kubernetes Benchmark. + +The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. + +When Rancher scans a cluster, it generates a report showing the results of each test, including the number of passed, skipped, and failed tests. The report also includes guidance on how to configure the cluster so that the failing tests will pass. + +To check clusters for CIS Kubernetes Benchmark compliance, the security scan leverages [kube-bench,](https://github.com/aquasecurity/kube-bench) an open-source tool from Aqua Security. + +When Rancher scans a cluster hosted in a managed Kubernetes provider such as GKE, EKS, or AKS, only worker nodes can be scanned. + +### About the Generated Report + +Each scan generates a report can be viewed in the Rancher UI and can be downloaded in CSV format. + +The version of the [benchmark](https://www.cisecurity.org/benchmark/kubernetes/) that is used depends on the cluster's Kubernetes version. + +Each test in the resport is identified by its corresponding section of the benchmark. For example, if a cluster fails test 1.3.6, you can look up the description and rationale for the benchmark section 1.3.6 in the benchmark itself, or in Rancher's [hardening guide for the Kubernetes version that the cluster is using.]({{}}/rancher/v2.x/en/security/#rancher-hardening-guide) + +Similarly, for information how to manually audit the test result, you could look up section 1.3.6 in Rancher's [self-assessment guide for the corresponding Kubernetes version.]({{}}/rancher/v2.x/en/security/#the-cis-benchmark-and-self-assessment) + +### Prerequisites + +To run security scans on a cluster and access the generated reports, you must be an [Administrator]({{}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) or [Cluster Owner.]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/) + +### Running a Scan + +1. From the cluster view in Rancher, click **Tools > CIS Scans.** +1. Click **Run Scan.** + +**Result:** A report is generated and displayed in the **CIS Scans** page. To see details of the report, click the report's name. + +### Skipping a Test + +1. From the cluster view in Rancher, click **Tools > CIS Scans.** +1. Click the name of the report that has tests you want to skip. +1. A **Skip** button is displayed next to each failed test. Click **Skip** for each test that should be skipped. + +**Result:** The tests will be skipped on the next scan. + +To re-run the security scan, go to the top of the page and click **Run Scan.** + +### Un-skipping a Test + +1. From the cluster view in Rancher, click **Tools > CIS Scans.** +1. Click the name of the report that has tests you want to un-skip. +1. An **Unskip** button is displayed next to each skipped test. Click **Unskip** for each test that should not be skipped. + +**Result:** The tests will not be skipped on the next scan. + +To re-run the security scan, go to the top of the page and click **Run Scan.** + +### Deleting a Report + +1. From the cluster view in Rancher, click **Tools > CIS Scans.** +1. Go to the report that should be deleted. +1. Click the **Ellipsis (...) > Delete.** +1. Click **Delete.** \ No newline at end of file From f7214c39f8bc0f381c767680f64e3cbbc1584a3b Mon Sep 17 00:00:00 2001 From: catherineluse Date: Fri, 20 Dec 2019 12:23:34 -0700 Subject: [PATCH 30/82] Respond to feedback on CIS scan doc --- content/rancher/v2.x/en/security/_index.md | 8 ++++---- .../rancher/v2.x/en/security/security-scan/_index.md | 10 +++++----- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/content/rancher/v2.x/en/security/_index.md b/content/rancher/v2.x/en/security/_index.md index 123a516aca2..2ee41833ca0 100644 --- a/content/rancher/v2.x/en/security/_index.md +++ b/content/rancher/v2.x/en/security/_index.md @@ -35,17 +35,17 @@ On this page, we provide security-related documentation along with resources to _Available as of v2.4_ -Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS (Center for Internet Security) Kubernetes Benchmark. +Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS (Center for Internet Security) Kubernetes Benchmark. -The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. +The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. The Benchmark provides recommendations of two types: Scored and Not Scored. We run tests related to only Scored recommendations. -When Rancher scans a cluster, it generates a report showing the results of each test, including the number of passed, skipped, and failed tests. The report also includes guidance on how to configure the cluster so that the failing tests will pass. +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.]({{}}/rancher/v2.x/en/security/security-scan) ### Rancher Hardening Guide -The Rancher Hardening Guide is based off of controls and best practices found in the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) 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. +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 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. - [Hardening Guide for Rancher v2.1.x with Kubernetes 1.11]({{< baseurl >}}/rancher/v2.x/en/security/hardening-2.1/) - [Hardening Guide for Rancher v2.2.x with Kubernetes 1.13]({{< baseurl >}}/rancher/v2.x/en/security/hardening-2.2/) diff --git a/content/rancher/v2.x/en/security/security-scan/_index.md b/content/rancher/v2.x/en/security/security-scan/_index.md index 6848f75f25a..5040a39651c 100644 --- a/content/rancher/v2.x/en/security/security-scan/_index.md +++ b/content/rancher/v2.x/en/security/security-scan/_index.md @@ -7,9 +7,9 @@ _Available as of v2.4_ Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS (Center for Internet Security) Kubernetes Benchmark. -The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. +The CIS Kubernetes Benchmark is a reference document that can be used to establish a secure configuration baseline for Kubernetes. The Benchmark provides recommendations of two types: Scored and Not Scored. We run tests related to only Scored recommendations. -When Rancher scans a cluster, it generates a report showing the results of each test, including the number of passed, skipped, and failed tests. The report also includes guidance on how to configure the cluster so that the failing tests will pass. +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. To check clusters for CIS Kubernetes Benchmark compliance, the security scan leverages [kube-bench,](https://github.com/aquasecurity/kube-bench) an open-source tool from Aqua Security. @@ -19,11 +19,11 @@ When Rancher scans a cluster hosted in a managed Kubernetes provider such as GKE Each scan generates a report can be viewed in the Rancher UI and can be downloaded in CSV format. -The version of the [benchmark](https://www.cisecurity.org/benchmark/kubernetes/) that is used depends on the cluster's Kubernetes version. +The version of the [Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) that is used depends on the cluster's Kubernetes version. -Each test in the resport is identified by its corresponding section of the benchmark. For example, if a cluster fails test 1.3.6, you can look up the description and rationale for the benchmark section 1.3.6 in the benchmark itself, or in Rancher's [hardening guide for the Kubernetes version that the cluster is using.]({{}}/rancher/v2.x/en/security/#rancher-hardening-guide) +Each test in the report is identified by its corresponding Scored test in the Benchmark. For example, if a cluster fails test 1.3.6, you can look up the description and rationale for the section 1.3.6 in the Benchmark itself, or in Rancher's [hardening guide for the Kubernetes version that the cluster is using.]({{}}/rancher/v2.x/en/security/#rancher-hardening-guide) Recommendations marked as Not Scored in the Benchmark are not included in the report. -Similarly, for information how to manually audit the test result, you could look up section 1.3.6 in Rancher's [self-assessment guide for the corresponding Kubernetes version.]({{}}/rancher/v2.x/en/security/#the-cis-benchmark-and-self-assessment) +Similarly, for information on how to manually audit the test result, you could look up section 1.3.6 in Rancher's [self-assessment guide for the corresponding Kubernetes version.]({{}}/rancher/v2.x/en/security/#the-cis-benchmark-and-self-assessment) ### Prerequisites From 4915d19354b320ca78f6f7b1c44c5186f4a634db Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 24 Dec 2019 11:52:29 -0700 Subject: [PATCH 31/82] Say that security scan is for RKE clusters --- content/rancher/v2.x/en/security/security-scan/_index.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/content/rancher/v2.x/en/security/security-scan/_index.md b/content/rancher/v2.x/en/security/security-scan/_index.md index 5040a39651c..6af630675d9 100644 --- a/content/rancher/v2.x/en/security/security-scan/_index.md +++ b/content/rancher/v2.x/en/security/security-scan/_index.md @@ -13,13 +13,11 @@ When Rancher runs a CIS Security Scan on a cluster, it generates a report showin To check clusters for CIS Kubernetes Benchmark compliance, the security scan leverages [kube-bench,](https://github.com/aquasecurity/kube-bench) an open-source tool from Aqua Security. -When Rancher scans a cluster hosted in a managed Kubernetes provider such as GKE, EKS, or AKS, only worker nodes can be scanned. - ### About the Generated Report Each scan generates a report can be viewed in the Rancher UI and can be downloaded in CSV format. -The version of the [Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) that is used depends on the cluster's Kubernetes version. +To determine which version of the [Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) to use in the scan, Rancher chooses a version that is appropriate for the cluster's Kubernetes version. The Benchmark version is included in the generated report. Each test in the report is identified by its corresponding Scored test in the Benchmark. For example, if a cluster fails test 1.3.6, you can look up the description and rationale for the section 1.3.6 in the Benchmark itself, or in Rancher's [hardening guide for the Kubernetes version that the cluster is using.]({{}}/rancher/v2.x/en/security/#rancher-hardening-guide) Recommendations marked as Not Scored in the Benchmark are not included in the report. @@ -29,6 +27,10 @@ Similarly, for information on how to manually audit the test result, you could l To run security scans on a cluster and access the generated reports, you must be an [Administrator]({{}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) or [Cluster Owner.]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/) +Rancher can only run security scans on clusters that were created with RKE, which includes custom clusters and clusters that Rancher created in an infrastructure provider such as Amazon EC2 or GCE. Imported clusters and clusters in hosted Kubernetes providers can't be scanned by Rancher. + +The security scan cannot run in a cluster that has Windows nodes. + ### Running a Scan 1. From the cluster view in Rancher, click **Tools > CIS Scans.** From f2e378ec3989672110f5afc7318c239815c25603 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 24 Dec 2019 13:26:13 -0700 Subject: [PATCH 32/82] Fix formatting of table --- .../air-gap/populate-private-registry/_index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md index c42728b24b1..4b6be02acd1 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md @@ -39,11 +39,11 @@ These steps expect you to use a Linux workstation that has internet access, acce 2. From the release's **Assets** section (pictured above), download the following files, which are required to install Rancher in an air gap environment: - | Release File | Description | - | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | - | `rancher-images.txt` | This file contains a list of images needed to install Rancher, provision clusters and user Rancher tools. | - | `rancher-save-images.sh` | This script pulls all the images in the `rancher-images.txt` from Docker Hub and saves all of the images as `rancher-images.tar.gz`. | - | `rancher-load-images.sh` | This script loads images from the `rancher-images.tar.gz` file and pushes them to your private registry. | +| Release File | Description | +| ---------------- | -------------- | +| `rancher-images.txt` | This file contains a list of images needed to install Rancher, provision clusters and user Rancher tools. | +| `rancher-save-images.sh` | This script pulls all the images in the `rancher-images.txt` from Docker Hub and saves all of the images as `rancher-images.tar.gz`. | +| `rancher-load-images.sh` | This script loads images from the `rancher-images.tar.gz` file and pushes them to your private registry. | ### B. Collect all the required images (For HA Installs using Rancher Generated Self-Signed Certificate) From 27c5b89cad7d45994a4e90c73b53497c488e219b Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 24 Dec 2019 13:42:36 -0700 Subject: [PATCH 33/82] Fix tabs and code blocks --- .../populate-private-registry/_index.md | 20 ++++++------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md index 4b6be02acd1..877ab93e0c0 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md @@ -69,43 +69,35 @@ In an HA install, if you elect to use the Rancher default self-signed TLS certif ### C. Save the images to your workstation 1. Make `rancher-save-images.sh` an executable: - ``` chmod +x rancher-save-images.sh ``` 1. Run `rancher-save-images.sh` with the `rancher-images.txt` image list to create a tarball of all the required images: - ```plain ./rancher-save-images.sh --image-list ./rancher-images.txt ``` - - **Step Result:** Docker begins pulling the images used for an air gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-images.tar.gz`. Check that the output is in the directory. + **Result:** Docker begins pulling the images used for an air gap install. Be patient. This process takes a few minutes. When the process completes, your current directory will output a tarball named `rancher-images.tar.gz`. Check that the output is in the directory. ### D. Populate the private registry Move the images in the `rancher-images.tar.gz` to your private registry using the scripts to load the images. The `rancher-images.txt` is expected to be on the workstation in the same directory that you are running the `rancher-load-images.sh` script. 1. Log into your private registry if required: - ```plain docker login ``` - 1. Make `rancher-load-images.sh` an executable: - ``` chmod +x rancher-load-images.sh ``` 1. Use `rancher-load-images.sh` to extract, tag and push `rancher-images.txt` and `rancher-images.tar.gz` to your private registry: - - ```plain - ./rancher-load-images.sh --image-list ./rancher-images.txt --registry - ``` - - {{% /tab %}} - {{% tab "Linux and Windows Clusters" %}} + ```plain + ./rancher-load-images.sh --image-list ./rancher-images.txt --registry + ``` +{{% /tab %}} +{{% tab "Linux and Windows Clusters" %}} _Available as of v2.3.0_ From b95ab3542730a8737360363a529aaa35e47269ed Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Thu, 26 Dec 2019 11:24:56 -0800 Subject: [PATCH 34/82] broken links --- content/rancher/v2.x/en/admin-settings/_index.md | 2 +- .../rancher/v2.x/en/cluster-provisioning/production/_index.md | 2 +- .../en/upgrades/upgrades/migrating-from-rke-add-on/_index.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 87ae8b08a3a..ababd74bc86 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -48,7 +48,7 @@ _Available as of v2.3.0_ With this feature, you can upgrade to the latest version of Kubernetes as soon as it is released, without upgrading Rancher. This feature allows you to easily upgrade Kubernetes patch versions (i.e. `v1.15.X`), but not intended to upgrade Kubernetes minor versions (i.e. `v1.X.0`) as Kubernetes tends to deprecate or add APIs between minor versions. -The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the Rancher Kubernetes Metadata. For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see [Rancher Kubernetes Metadata]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rke-metadata/). +The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the Rancher Kubernetes Metadata. For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see Rancher Kubernetes Metadata. Rancher Kubernetes Metadata contains Kubernetes version information which Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). diff --git a/content/rancher/v2.x/en/cluster-provisioning/production/_index.md b/content/rancher/v2.x/en/cluster-provisioning/production/_index.md index 78edd318a48..5a0571f4698 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/production/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/production/_index.md @@ -32,7 +32,7 @@ For a full list of all the best practices that we recommend, refer to the [best For more information on what each role is used for, refer to the [section on roles for nodes in Kubernetes.]({{}}/rancher/v2.x/en/cluster-provisioning/production/nodes-and-roles) -For more information about the recommended number of nodes for each Kubernetes role, refer to the [section on recommended architecture.]({{}}/rancher/v2.x/encluster-provisioning/recommended-architecture) +For more information about the recommended number of nodes for each Kubernetes role, refer to the section on recommended architecture. ### Logging and Monitoring diff --git a/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md index 50cb6dc948f..88115612650 100644 --- a/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md +++ b/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md @@ -105,5 +105,5 @@ addons: |- From here follow the standard install steps. -* [3 - Initialize Helm]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/) +* 3 - Initialize Helm * [4 - Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/) From 5becf73de0fc8b49d8714d8ef9d76a9e26e9630a Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Thu, 26 Dec 2019 12:31:59 -0800 Subject: [PATCH 35/82] broken links --- content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md | 2 +- content/rancher/v2.x/en/installation/ha/_index.md | 2 +- .../options/helm2/rke-add-on/troubleshooting/_index.md | 2 +- .../rancher/v2.x/en/installation/options/rke-add-on/_index.md | 2 +- .../installation/options/rke-add-on/troubleshooting/_index.md | 2 +- .../other-installation-methods/single-node/_index.md | 2 +- content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md index 13c3bb94fe3..cc2a27dde9c 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md @@ -40,7 +40,7 @@ CURRENT NAME CLUSTER AUTHINFO N * my-cluster my-cluster user-46tmn my-cluster-controlplane-1 my-cluster-controlplane-1 user-46tmn ``` -For more information on how the authorized cluster endpoint works, refer to the [architecture section.]({{}}/rancher/v2.x/en/overview/architecture/4-authorized-cluster-endpoint) +For more information on how the authorized cluster endpoint works, refer to the architecture section. We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/#architecture-for-an-authorized-cluster-endpoint) diff --git a/content/rancher/v2.x/en/installation/ha/_index.md b/content/rancher/v2.x/en/installation/ha/_index.md index d930bdd5edc..1402615a57b 100644 --- a/content/rancher/v2.x/en/installation/ha/_index.md +++ b/content/rancher/v2.x/en/installation/ha/_index.md @@ -45,7 +45,7 @@ The following CLI tools are required for this install. Please make sure these to ## Previous Methods -[RKE add-on install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/) +RKE add-on install > **Important: RKE add-on install is only supported up to Rancher v2.0.8** > diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md index 142363121e6..091b41057d2 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md @@ -19,7 +19,7 @@ Choose from the following options: In this section, you can find generic ways to debug your Kubernetes cluster. -- [Failed to set up SSH tunneling for host](ssh-tunneling/) +- Failed to set up SSH tunneling for host In this section, you can find errors related to SSH tunneling when you run the `rke` command to setup your nodes. diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md index 5488045c906..b30583bd21c 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md @@ -12,4 +12,4 @@ weight: 276 - [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb) - [High Availability Installation with External Load Balancer (HTTPS/Layer 7)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb) - [HTTP Proxy Configuration for a High Availability Installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/proxy/) -- [Troubleshooting RKE Add-on Installs]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/) +- Troubleshooting RKE Add-on Installs diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md index 5aeeafc2224..dd3dec6c88e 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md @@ -19,7 +19,7 @@ Choose from the following options: In this section, you can find generic ways to debug your Kubernetes cluster. -- [Failed to set up SSH tunneling for host](ssh-tunneling/) +- Failed to set up SSH tunneling for host In this section, you can find errors related to SSH tunneling when you run the `rke` command to setup your nodes. diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md index 224932b0cdc..b71075d7754 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md @@ -25,7 +25,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher > **Do you want to...** > -> - Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/other-installation-methods/single-nodeproxy/) +> - Use a proxy? See HTTP Proxy Configuration > - Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) > - Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/) > - Record all transactions with the Rancher API? See [API Auditing](#api-audit-log) diff --git a/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md index 6aecbe1841b..dc76eeb9fdb 100644 --- a/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md +++ b/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md @@ -113,7 +113,7 @@ Get the options set from your current Rancher install >**Did you...** > - >- Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/other-installation-methods/single-nodeproxy/) + >- Use a proxy? See HTTP Proxy Configuration >- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) >- Record all transactions with the Rancher API? See [API Auditing](#api-audit-log) > From 4bbdd0953ff0e62440d5ffbb503b9083cb0cc4c7 Mon Sep 17 00:00:00 2001 From: dkeightley Date: Fri, 27 Dec 2019 10:11:04 +1300 Subject: [PATCH 36/82] Update bullet point to new lines with consistent wording Bring the two bullet points to new lines to fix the list structure Slight update to wording for consistency --- .../single-node/advanced/_index.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/advanced/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/advanced/_index.md index 0a098494cbe..7b2707fab24 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/advanced/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/advanced/_index.md @@ -18,8 +18,10 @@ If you want to configure Rancher to use a CA root certificate to be used when va Use the command example to start a Rancher container with your private CA certificates mounted. -- The volume option (`-v`) should specify the host directory containing the CA root certificates. -- The `e` flag in combination with `SSL_CERT_DIR` declares an environment variable that specifies the mounted CA root certificates directory location inside the container. - Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. - Mounting a host directory inside the container can be done using `-v host-source-directory:container-destination-directory` or `--volume host-source-directory:container-destination-directory`. +- The volume flag (`-v`) should specify the host directory containing the CA root certificates. +- The environment variable flag (`-e`) in combination with `SSL_CERT_DIR` and directory declares an environment variable that specifies the mounted CA root certificates directory location inside the container. +- Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. +- Mounting a host directory inside the container can be done using `-v host-source-directory:container-destination-directory` or `--volume host-source-directory:container-destination-directory`. The example below is based on having the CA root certificates in the `/host/certs` directory on the host and mounting this directory on `/container/certs` inside the Rancher container. From 7a68c199681864f3a9f6e0e97e559b7ceb498b82 Mon Sep 17 00:00:00 2001 From: YANO Tetsuro Date: Mon, 30 Dec 2019 10:37:45 +0900 Subject: [PATCH 37/82] add markdown option syntax hightlight add markdown option syntax hightlight --- content/k3s/latest/en/configuration/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/k3s/latest/en/configuration/_index.md b/content/k3s/latest/en/configuration/_index.md index 1f3cc7d7bf8..6d8df6eef94 100644 --- a/content/k3s/latest/en/configuration/_index.md +++ b/content/k3s/latest/en/configuration/_index.md @@ -29,7 +29,7 @@ spec: Keep in mind that `namespace` in your HelmChart resource metadata section should always be `kube-system`, because the K3s deploy controller is configured to watch this namespace for new HelmChart resources. If you want to specify the namespace for the actual helm release, you can do that using `targetNamespace` key in the spec section: -``` +```yaml apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: From b5f89d75fda3b2f8bdefc6394b3c3adb6880abe5 Mon Sep 17 00:00:00 2001 From: ZHAO Yao Date: Mon, 30 Dec 2019 17:35:08 +0800 Subject: [PATCH 38/82] fix typo --- content/rke/latest/en/config-options/bastion-host/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rke/latest/en/config-options/bastion-host/_index.md b/content/rke/latest/en/config-options/bastion-host/_index.md index 4e0f04260d1..3b6848759c6 100644 --- a/content/rke/latest/en/config-options/bastion-host/_index.md +++ b/content/rke/latest/en/config-options/bastion-host/_index.md @@ -3,7 +3,7 @@ title: Bastion/Jump Host Configuration weight: 220 --- -Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/), you can configure the `cluster.yml` so RKE will use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/latest/en/os/#ports) for the RKE node move to the configured bastion host. our private SSH key(s) only needs to reside on the host running RKE. You do not need to copy your private SSH key(s) to the bastion host. +Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/latest/en/config-options/nodes/), you can configure the `cluster.yml` so RKE will use a bastion host. Keep in mind that the [port requirements]({{< baseurl >}}/rke/latest/en/os/#ports) for the RKE node move to the configured bastion host. Our private SSH key(s) only needs to reside on the host running RKE. You do not need to copy your private SSH key(s) to the bastion host. ```yaml bastion_host: From 2ccb08f6fc3a41b373297f7beecef05ca16bd33b Mon Sep 17 00:00:00 2001 From: niusmallnan Date: Mon, 30 Dec 2019 21:39:08 +0800 Subject: [PATCH 39/82] Update for ros v1.5.5 --- .../v1.x/en/installation/amazon-ecs/_index.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/os/v1.x/en/installation/amazon-ecs/_index.md b/content/os/v1.x/en/installation/amazon-ecs/_index.md index fa8bee8a8ef..a76c7675044 100644 --- a/content/os/v1.x/en/installation/amazon-ecs/_index.md +++ b/content/os/v1.x/en/installation/amazon-ecs/_index.md @@ -62,21 +62,21 @@ Latest Release: [v1.5.4](https://github.com/rancher/os/releases/tag/v1.5.4) Region | Type | AMI ---|--- | --- -eu-north-1 | HVM - ECS enabled | [ami-0d0ea423c99b99528](https://eu-north-1.console.aws.amazon.com/ec2/home?region=eu-north-1#launchInstanceWizard:ami=ami-0d0ea423c99b99528) -ap-south-1 | HVM - ECS enabled | [ami-026d573feb2b40494](https://ap-south-1.console.aws.amazon.com/ec2/home?region=ap-south-1#launchInstanceWizard:ami=ami-026d573feb2b40494) -eu-west-3 | HVM - ECS enabled | [ami-0b00515ac5791981a](https://eu-west-3.console.aws.amazon.com/ec2/home?region=eu-west-3#launchInstanceWizard:ami=ami-0b00515ac5791981a) -eu-west-2 | HVM - ECS enabled | [ami-017c58d5ed26b91f4](https://eu-west-2.console.aws.amazon.com/ec2/home?region=eu-west-2#launchInstanceWizard:ami=ami-017c58d5ed26b91f4) -eu-west-1 | HVM - ECS enabled | [ami-00863d13761ef3724](https://eu-west-1.console.aws.amazon.com/ec2/home?region=eu-west-1#launchInstanceWizard:ami=ami-00863d13761ef3724) -ap-northeast-2 | HVM - ECS enabled | [ami-04e09c2c9c4b59d54](https://ap-northeast-2.console.aws.amazon.com/ec2/home?region=ap-northeast-2#launchInstanceWizard:ami=ami-04e09c2c9c4b59d54) -ap-northeast-1 | HVM - ECS enabled | [ami-0e5d74499b8bd1119](https://ap-northeast-1.console.aws.amazon.com/ec2/home?region=ap-northeast-1#launchInstanceWizard:ami=ami-0e5d74499b8bd1119) -sa-east-1 | HVM - ECS enabled | [ami-033aa9f2a4ea1c2ab](https://sa-east-1.console.aws.amazon.com/ec2/home?region=sa-east-1#launchInstanceWizard:ami=ami-033aa9f2a4ea1c2ab) -ca-central-1 | HVM - ECS enabled | [ami-0002d992ae120cc94](https://ca-central-1.console.aws.amazon.com/ec2/home?region=ca-central-1#launchInstanceWizard:ami=ami-0002d992ae120cc94) -ap-southeast-1 | HVM - ECS enabled | [ami-0524bbc4fb51f2190](https://ap-southeast-1.console.aws.amazon.com/ec2/home?region=ap-southeast-1#launchInstanceWizard:ami=ami-0524bbc4fb51f2190) -ap-southeast-2 | HVM - ECS enabled | [ami-09be0a7f78760ed49](https://ap-southeast-2.console.aws.amazon.com/ec2/home?region=ap-southeast-2#launchInstanceWizard:ami=ami-09be0a7f78760ed49) -eu-central-1 | HVM - ECS enabled | [ami-08b437124d5650e75](https://eu-central-1.console.aws.amazon.com/ec2/home?region=eu-central-1#launchInstanceWizard:ami=ami-08b437124d5650e75) -us-east-1 | HVM - ECS enabled | [ami-047c2cc8ce83362d5](https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#launchInstanceWizard:ami=ami-047c2cc8ce83362d5) -us-east-2 | HVM - ECS enabled | [ami-022fc798437fb846a](https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#launchInstanceWizard:ami=ami-022fc798437fb846a) -us-west-1 | HVM - ECS enabled | [ami-00d236646389e14d0](https://us-west-1.console.aws.amazon.com/ec2/home?region=us-west-1#launchInstanceWizard:ami=ami-00d236646389e14d0) -us-west-2 | HVM - ECS enabled | [ami-0c12fa819f3adc03d](https://us-west-2.console.aws.amazon.com/ec2/home?region=us-west-2#launchInstanceWizard:ami=ami-0c12fa819f3adc03d) -cn-north-1 | HVM - ECS enabled | [ami-092d12a2396dc0822](https://cn-north-1.console.amazonaws.cn/ec2/home?region=cn-north-1#launchInstanceWizard:ami=ami-092d12a2396dc0822) -cn-northwest-1 | HVM - ECS enabled | [ami-0d63e8f32b5873368](https://cn-northwest-1.console.amazonaws.cn/ec2/home?region=cn-northwest-1#launchInstanceWizard:ami=ami-0d63e8f32b5873368) +eu-north-1 | HVM - ECS enabled | [ami-0c46c1da6468aa948](https://eu-north-1.console.aws.amazon.com/ec2/home?region=eu-north-1#launchInstanceWizard:ami=ami-0c46c1da6468aa948) +ap-south-1 | HVM - ECS enabled | [ami-097e5fa868c46e925](https://ap-south-1.console.aws.amazon.com/ec2/home?region=ap-south-1#launchInstanceWizard:ami=ami-097e5fa868c46e925) +eu-west-3 | HVM - ECS enabled | [ami-016e7d630d7f608e4](https://eu-west-3.console.aws.amazon.com/ec2/home?region=eu-west-3#launchInstanceWizard:ami=ami-016e7d630d7f608e4) +eu-west-2 | HVM - ECS enabled | [ami-00aacd261ab72302e](https://eu-west-2.console.aws.amazon.com/ec2/home?region=eu-west-2#launchInstanceWizard:ami=ami-00aacd261ab72302e) +eu-west-1 | HVM - ECS enabled | [ami-0812b3f8aec8d2d81](https://eu-west-1.console.aws.amazon.com/ec2/home?region=eu-west-1#launchInstanceWizard:ami=ami-0812b3f8aec8d2d81) +ap-northeast-2 | HVM - ECS enabled | [ami-0d9d77df6579e618a](https://ap-northeast-2.console.aws.amazon.com/ec2/home?region=ap-northeast-2#launchInstanceWizard:ami=ami-0d9d77df6579e618a) +ap-northeast-1 | HVM - ECS enabled | [ami-09e957ac11ef430a3](https://ap-northeast-1.console.aws.amazon.com/ec2/home?region=ap-northeast-1#launchInstanceWizard:ami=ami-09e957ac11ef430a3) +sa-east-1 | HVM - ECS enabled | [ami-09c22f3ce89280ed4](https://sa-east-1.console.aws.amazon.com/ec2/home?region=sa-east-1#launchInstanceWizard:ami=ami-09c22f3ce89280ed4) +ca-central-1 | HVM - ECS enabled | [ami-016ac80225e649cf9](https://ca-central-1.console.aws.amazon.com/ec2/home?region=ca-central-1#launchInstanceWizard:ami=ami-016ac80225e649cf9) +ap-southeast-1 | HVM - ECS enabled | [ami-06cdfc80bdbd6f419](https://ap-southeast-1.console.aws.amazon.com/ec2/home?region=ap-southeast-1#launchInstanceWizard:ami=ami-06cdfc80bdbd6f419) +ap-southeast-2 | HVM - ECS enabled | [ami-0335f7bb1c51c0a74](https://ap-southeast-2.console.aws.amazon.com/ec2/home?region=ap-southeast-2#launchInstanceWizard:ami=ami-0335f7bb1c51c0a74) +eu-central-1 | HVM - ECS enabled | [ami-0af71ec7ee8b729be](https://eu-central-1.console.aws.amazon.com/ec2/home?region=eu-central-1#launchInstanceWizard:ami=ami-0af71ec7ee8b729be) +us-east-1 | HVM - ECS enabled | [ami-07209d7ec9e7545b4](https://us-east-1.console.aws.amazon.com/ec2/home?region=us-east-1#launchInstanceWizard:ami=ami-07209d7ec9e7545b4) +us-east-2 | HVM - ECS enabled | [ami-046358fe356dd0e35](https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#launchInstanceWizard:ami=ami-046358fe356dd0e35) +us-west-1 | HVM - ECS enabled | [ami-031bcb65b47cb0a77](https://us-west-1.console.aws.amazon.com/ec2/home?region=us-west-1#launchInstanceWizard:ami=ami-031bcb65b47cb0a77) +us-west-2 | HVM - ECS enabled | [ami-0d92d296ecb13ea45](https://us-west-2.console.aws.amazon.com/ec2/home?region=us-west-2#launchInstanceWizard:ami=ami-0d92d296ecb13ea45) +cn-north-1 | HVM - ECS enabled | [ami-04f1668aaf990acf6](https://cn-north-1.console.amazonaws.cn/ec2/home?region=cn-north-1#launchInstanceWizard:ami=ami-04f1668aaf990acf6) +cn-northwest-1 | HVM - ECS enabled | [ami-0771f259ffce58280](https://cn-northwest-1.console.amazonaws.cn/ec2/home?region=cn-northwest-1#launchInstanceWizard:ami=ami-0771f259ffce58280) From 2491034be8cbf482e66a32c3acf46262c273aabc Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 09:55:44 -0700 Subject: [PATCH 40/82] Update _index.md --- content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md index 8ac2d3f0c02..c6d41986124 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md @@ -13,7 +13,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c 1. From the **Global** view, select the project where you want to deploy your ingress. -1. From the main menu, select **Resources > Secrets > Certificates**. Click **Add Certificate**. +1. From the main menu, select **Resources > Secrets > Certificates**. Click **Add Certificate**. (For Rancher prior to v2.3, click **Resources > Certificates.**) 1. Enter a **Name** for the certificate. @@ -37,7 +37,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c - If you added an SSL certificate to the project, the certificate is available for deployments created in any project namespace. - If you added an SSL certificate to a namespace, the certificate is available only for deployments in that namespace. -- Your certificate is added to the **Resources > Secrets > Certificates** view. +- Your certificate is added to the **Resources > Secrets > Certificates** view. (For Rancher prior to v2.3, it is added to **Resources > Certificates.**) ## What's Next? From a159812432cb1ba3f5c806969de6c33ca4572aa3 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Thu, 17 Oct 2019 17:00:34 -0700 Subject: [PATCH 41/82] Say to check ingress-nginx upgrade policy --- .../rancher/v2.x/en/cluster-admin/editing-clusters/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md index 4eb7e29a741..cbc805c76ea 100644 --- a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md @@ -79,7 +79,7 @@ As of Rancher v2.3.0, the Kubernetes metadata feature was added, which allows Ra **Result:** Kubernetes begins upgrading for the cluster. During the upgrade, your cluster is unavailable. -> **Note:** The `ingress-nginx` pods are set to only upgrade on delete. After upgrading your cluster, you need to delete these pods to get the correct version for your deployment. +> **Note:** Check the upgrade policy of the `ingress-nginx` pods. If the upgrade policy is set to **onDelete,** you will need to delete these pods to get the correct version for your deployment. ### Adding a Pod Security Policy From 3d58fdeb080d5b8eba5da5a00b3f9b8a058d2430 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Fri, 18 Oct 2019 16:24:00 -0700 Subject: [PATCH 42/82] Explain ingress-nginx update strategy --- .../v2.x/en/cluster-admin/cloning-clusters/_index.md | 2 ++ .../v2.x/en/cluster-admin/editing-clusters/_index.md | 6 +++++- .../hosted-kubernetes-clusters/cce/_index.md | 2 +- .../hosted-kubernetes-clusters/tke/_index.md | 2 +- content/rancher/v2.x/en/security/hardening-2.3/_index.md | 2 ++ 5 files changed, 11 insertions(+), 3 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md index b097e8b7b12..150503020a0 100644 --- a/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md @@ -51,6 +51,8 @@ Begin by using Rancher CLI to export the configuration for the cluster that you ## 2. Modify Cluster Config +> 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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) + 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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) diff --git a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md index cbc805c76ea..633ce78db15 100644 --- a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md @@ -79,7 +79,11 @@ As of Rancher v2.3.0, the Kubernetes metadata feature was added, which allows Ra **Result:** Kubernetes begins upgrading for the cluster. During the upgrade, your cluster is unavailable. -> **Note:** Check the upgrade policy of the `ingress-nginx` pods. If the upgrade policy is set to **onDelete,** you will need to delete these pods to get the correct version for your deployment. +### Upgrading ingress-nginx + +For RKE v0.1.8+, the `ingress-nginx` YAML does not contain an upgrade policy, which makes the update strategy `RollingUpdate` by default. This policy allows the daemonset to restart the pods. + +For RKE prior to v0.1.8, the `updateStrategy` directive in the `ingress-nginx` YAML is set to `OnDelete.` In that case, you will need to delete these pods to get the correct version for your deployment. ### Adding a Pod Security Policy diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/_index.md index 45c2dfa3e48..39bb5c1c44b 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/cce/_index.md @@ -50,7 +50,7 @@ Huawei CCE service doesn't support the ability to create clusters with public ac | 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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) 7. Fill the following node configuration of the cluster: diff --git a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/_index.md b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/_index.md index 9899c63be38..c3f8087e741 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/tke/_index.md @@ -48,7 +48,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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) 7. Click `Next: Select Instance Type` to choose the instance type that will use for your TKE cluster. diff --git a/content/rancher/v2.x/en/security/hardening-2.3/_index.md b/content/rancher/v2.x/en/security/hardening-2.3/_index.md index ab0ebdf9feb..20ed39326b0 100644 --- a/content/rancher/v2.x/en/security/hardening-2.3/_index.md +++ b/content/rancher/v2.x/en/security/hardening-2.3/_index.md @@ -1124,6 +1124,8 @@ If a disallowed node driver is active, visit the _Node Drivers_ page under _Glob ## Appendix A - Complete RKE `cluster.yml` Example +> **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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) + ``` yaml nodes: - address: 18.191.190.205 From 756b31312e81bfd30e8b57c149d5d164df0296b8 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Fri, 18 Oct 2019 16:33:54 -0700 Subject: [PATCH 43/82] Remove changes from other commit --- .../rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md | 2 -- content/rancher/v2.x/en/security/hardening-2.3/_index.md | 2 -- 2 files changed, 4 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md index 150503020a0..b097e8b7b12 100644 --- a/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cloning-clusters/_index.md @@ -51,8 +51,6 @@ Begin by using Rancher CLI to export the configuration for the cluster that you ## 2. Modify Cluster Config -> 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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) - 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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) diff --git a/content/rancher/v2.x/en/security/hardening-2.3/_index.md b/content/rancher/v2.x/en/security/hardening-2.3/_index.md index 20ed39326b0..ab0ebdf9feb 100644 --- a/content/rancher/v2.x/en/security/hardening-2.3/_index.md +++ b/content/rancher/v2.x/en/security/hardening-2.3/_index.md @@ -1124,8 +1124,6 @@ If a disallowed node driver is active, visit the _Node Drivers_ page under _Glob ## Appendix A - Complete RKE `cluster.yml` Example -> **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+.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) - ``` yaml nodes: - address: 18.191.190.205 From d5f5f3a9f93444fed42597b459e6c272c63ae195 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 2 Dec 2019 15:52:44 -0700 Subject: [PATCH 44/82] Add ingress config to cluster.yml example, add note to upgrade section --- .../v2.x/en/cluster-admin/editing-clusters/_index.md | 2 +- .../v2.x/en/installation/ha/kubernetes-rke/_index.md | 7 +++++++ content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md | 5 ++++- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md index 633ce78db15..92ccfc2b965 100644 --- a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md @@ -83,7 +83,7 @@ As of Rancher v2.3.0, the Kubernetes metadata feature was added, which allows Ra For RKE v0.1.8+, the `ingress-nginx` YAML does not contain an upgrade policy, which makes the update strategy `RollingUpdate` by default. This policy allows the daemonset to restart the pods. -For RKE prior to v0.1.8, the `updateStrategy` directive in the `ingress-nginx` YAML is set to `OnDelete.` In that case, you will need to delete these pods to get the correct version for your deployment. +For RKE prior to v0.1.8, the `updateStrategy` directive in the `ingress-nginx` YAML was set to `OnDelete` because RKE did not yet support updating ingress and addons. In that case, you will need to delete these pods to get the correct version for your deployment. ### Adding a Pod Security Policy diff --git a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md index e785a901ac9..9b5eb8a8ebb 100644 --- a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md +++ b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md @@ -33,6 +33,13 @@ services: snapshot: true creation: 6h retention: 24h + +# Required for external TLS termination with +# ingress-nginx v0.22+ +ingress: + provider: nginx + options: + use-forwarded-headers: "true" ``` #### Common RKE Nodes Options diff --git a/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md index 864a5b88eb7..b3e15eefaad 100644 --- a/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md +++ b/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md @@ -13,7 +13,10 @@ To upgrade the components in your Kubernetes cluster, or the definition of the [ If you installed Rancher using the RKE Add-on yaml, follow the directions to [migrate or upgrade]({{}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on). ->**Note:** [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.]({{}}/rancher/v2.x/en/installation/options/upgrading-cert-manager) +>**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.]({{}}/rancher/v2.x/en/installation/options/upgrading-cert-manager) +> - 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.]({{}}/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/#configuring-ingress-for-external-tls-when-using-nginx-v0-25) # Prerequisites From 30ee7c983dd642398c6c138702bf21b3c4ade685 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 13:36:45 -0700 Subject: [PATCH 45/82] Say that nginx-ingress updateStrategy depends on Kubernetes version --- .../rancher/v2.x/en/cluster-admin/editing-clusters/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md index 92ccfc2b965..9f194c51414 100644 --- a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md @@ -81,7 +81,7 @@ As of Rancher v2.3.0, the Kubernetes metadata feature was added, which allows Ra ### Upgrading ingress-nginx -For RKE v0.1.8+, the `ingress-nginx` YAML does not contain an upgrade policy, which makes the update strategy `RollingUpdate` by default. This policy allows the daemonset to restart the pods. +For RKE v0.1.8+, the `ingress-nginx` YAML does not contain an `updateStrategy`. Therefore, the `updateStrategy` is the default value that is set by the Kubernetes API version. For example, the default `updateStrategy` for Kubernetes v1.13 was `onDelete`. When RKE v0.3.2 began supporting Kubernetes v1.16, the `updateStrategy` for `ingress-nginx` became `RollingUpdate` by default for RKE clusters with Kubernetes 1.16. This policy allows the daemonset to restart the pods. For RKE prior to v0.1.8, the `updateStrategy` directive in the `ingress-nginx` YAML was set to `OnDelete` because RKE did not yet support updating ingress and addons. In that case, you will need to delete these pods to get the correct version for your deployment. From 56b2cd73a456ef1e5183e8bd7e747e93d4680f76 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 13:47:13 -0700 Subject: [PATCH 46/82] Fix metadata link --- content/rancher/v2.x/en/admin-settings/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index ababd74bc86..182116ed5a1 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -48,7 +48,7 @@ _Available as of v2.3.0_ With this feature, you can upgrade to the latest version of Kubernetes as soon as it is released, without upgrading Rancher. This feature allows you to easily upgrade Kubernetes patch versions (i.e. `v1.15.X`), but not intended to upgrade Kubernetes minor versions (i.e. `v1.X.0`) as Kubernetes tends to deprecate or add APIs between minor versions. -The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the Rancher Kubernetes Metadata. For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see Rancher Kubernetes Metadata. +The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the Rancher Kubernetes Metadata. For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see [Rancher Kubernetes Metadata.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). From b72f1be7f12316ac8de587d1ab070ee7f37c0e5a Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 13:50:32 -0700 Subject: [PATCH 47/82] Fix architecture link --- content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md index cc2a27dde9c..a8a8ec8f428 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md @@ -40,7 +40,7 @@ CURRENT NAME CLUSTER AUTHINFO N * my-cluster my-cluster user-46tmn my-cluster-controlplane-1 my-cluster-controlplane-1 user-46tmn ``` -For more information on how the authorized cluster endpoint works, refer to the architecture section. +For more information on how the authorized cluster endpoint works, refer to the [architecture section.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/#architecture-for-an-authorized-cluster-endpoint) From 0b2dd0a73c8104c9c6e262b6840cdc38f70eb3a8 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 13:51:26 -0700 Subject: [PATCH 48/82] Fix architecture link typo --- content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md index a8a8ec8f428..02f446ad078 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md @@ -40,7 +40,7 @@ CURRENT NAME CLUSTER AUTHINFO N * my-cluster my-cluster user-46tmn my-cluster-controlplane-1 my-cluster-controlplane-1 user-46tmn ``` -For more information on how the authorized cluster endpoint works, refer to the [architecture section.]({{}}/rancher/v2.x/en/overview/architecture/#4-authorized-cluster-endpoint) We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/#architecture-for-an-authorized-cluster-endpoint) From 8eb3398d112d03c749199b4e2c499219bd4abb6e Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 13:52:38 -0700 Subject: [PATCH 49/82] Fix recommended architecture link --- .../rancher/v2.x/en/cluster-provisioning/production/_index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-provisioning/production/_index.md b/content/rancher/v2.x/en/cluster-provisioning/production/_index.md index 5a0571f4698..d5ab40db6fd 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/production/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/production/_index.md @@ -32,7 +32,8 @@ For a full list of all the best practices that we recommend, refer to the [best For more information on what each role is used for, refer to the [section on roles for nodes in Kubernetes.]({{}}/rancher/v2.x/en/cluster-provisioning/production/nodes-and-roles) -For more information about the recommended number of nodes for each Kubernetes role, refer to the section on recommended architecture. +For more information about the +number of nodes for each Kubernetes role, refer to the section on [recommended architecture.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/) ### Logging and Monitoring From c2cc4b4ca92a9a363279a06f45e4db1dc243358c Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 13:54:17 -0700 Subject: [PATCH 50/82] Fix link to RKE add-on install --- content/rancher/v2.x/en/installation/ha/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/installation/ha/_index.md b/content/rancher/v2.x/en/installation/ha/_index.md index 1402615a57b..2e0be6690e9 100644 --- a/content/rancher/v2.x/en/installation/ha/_index.md +++ b/content/rancher/v2.x/en/installation/ha/_index.md @@ -45,7 +45,7 @@ The following CLI tools are required for this install. Please make sure these to ## Previous Methods -RKE add-on install +[RKE add-on install]({{}}/rancher/v2.x/en/installation/options/rke-add-on/) > **Important: RKE add-on install is only supported up to Rancher v2.0.8** > From 5963e1c4769dca0ae748f7fa6f561c7dffc79e75 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 14:03:24 -0700 Subject: [PATCH 51/82] Fix SSH tunneling link --- .../options/helm2/rke-add-on/troubleshooting/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md index 091b41057d2..91076370aa2 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/troubleshooting/_index.md @@ -19,7 +19,7 @@ Choose from the following options: In this section, you can find generic ways to debug your Kubernetes cluster. -- Failed to set up SSH tunneling for host +- [Failed to set up SSH tunneling for host]({{}}/rke/latest/en/troubleshooting/ssh-connectivity-errors/) In this section, you can find errors related to SSH tunneling when you run the `rke` command to setup your nodes. From 563f031ada985ed4ad06189daa6a3fba823ce24b Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 14:05:29 -0700 Subject: [PATCH 52/82] Fix RKE add-on install troubleshooting link --- .../v2.x/en/installation/options/rke-add-on/_index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md index b30583bd21c..d53a7798ba5 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/_index.md @@ -9,7 +9,7 @@ weight: 276 > > If you are currently using the RKE add-on install method, see [Migrating from an HA RKE Add-on Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/) for details on how to move to using the helm chart. -- [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb) -- [High Availability Installation with External Load Balancer (HTTPS/Layer 7)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb) -- [HTTP Proxy Configuration for a High Availability Installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/proxy/) -- Troubleshooting RKE Add-on Installs +- [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb) +- [High Availability Installation with External Load Balancer (HTTPS/Layer 7)]({{< baseurl >}}/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb) +- [HTTP Proxy Configuration for a High Availability Installation]({{< baseurl >}}/rancher/v2.x/en/installation/options/rke-add-on/proxy/) +- [Troubleshooting RKE Add-on Installs]({{< baseurl >}}/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/) From 6027f3529d7e89ca3b74297527f15b59c662aefc Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 14:06:28 -0700 Subject: [PATCH 53/82] Fix other SSH tunneling link --- .../installation/options/rke-add-on/troubleshooting/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md index dd3dec6c88e..cde054aacf5 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/troubleshooting/_index.md @@ -19,7 +19,7 @@ Choose from the following options: In this section, you can find generic ways to debug your Kubernetes cluster. -- Failed to set up SSH tunneling for host +- [Failed to set up SSH tunneling for host]({{}}/rke/latest/en/troubleshooting/ssh-connectivity-errors/) In this section, you can find errors related to SSH tunneling when you run the `rke` command to setup your nodes. From 8a6ceaa4a4d3265435d46de20aac49a0b5bbb4ec Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 14:10:26 -0700 Subject: [PATCH 54/82] Fix link for single node installation behind proxy --- .../other-installation-methods/single-node/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md index b71075d7754..3f9083a7d1d 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md @@ -25,7 +25,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher > **Do you want to...** > -> - Use a proxy? See HTTP Proxy Configuration +> - Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/other-installation-methods/single-node/proxy/) > - Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) > - Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/) > - Record all transactions with the Rancher API? See [API Auditing](#api-audit-log) From 66c93cd4fe45148b9086a1ecc179360ea650bf77 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 14:12:21 -0700 Subject: [PATCH 55/82] Fix other link for single node with proxy --- content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md index dc76eeb9fdb..56a089262f8 100644 --- a/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md +++ b/content/rancher/v2.x/en/upgrades/upgrades/single-node/_index.md @@ -113,7 +113,7 @@ Get the options set from your current Rancher install >**Did you...** > - >- Use a proxy? See HTTP Proxy Configuration + >- Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/other-installation-methods/single-node/proxy/) >- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) >- Record all transactions with the Rancher API? See [API Auditing](#api-audit-log) > From 1abbd2ccc48cea62fa2f239b8598b5f13fb4411a Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 14:15:38 -0700 Subject: [PATCH 56/82] Fix RKE add-on migration links --- .../en/upgrades/upgrades/migrating-from-rke-add-on/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md index 88115612650..ababd9e5ff9 100644 --- a/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md +++ b/content/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/_index.md @@ -105,5 +105,5 @@ addons: |- From here follow the standard install steps. -* 3 - Initialize Helm -* [4 - Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/) +* [3 - Initialize Helm]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-init/) +* [4 - Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/helm-rancher/) From dda697306aceaed1dd1ed31a324cd3c00888bdff Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 14:21:36 -0700 Subject: [PATCH 57/82] Fix typo in link --- content/rancher/v2.x/en/admin-settings/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index 182116ed5a1..b5c5c077223 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -48,7 +48,7 @@ _Available as of v2.3.0_ With this feature, you can upgrade to the latest version of Kubernetes as soon as it is released, without upgrading Rancher. This feature allows you to easily upgrade Kubernetes patch versions (i.e. `v1.15.X`), but not intended to upgrade Kubernetes minor versions (i.e. `v1.X.0`) as Kubernetes tends to deprecate or add APIs between minor versions. -The information that Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the Rancher Kubernetes Metadata. For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see [Rancher Kubernetes Metadata.]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) is now located in the Rancher Kubernetes Metadata. For details on metadata configuration and how to change the Kubernetes version used for provisioning RKE clusters, see [Rancher Kubernetes Metadata.]({{}}/rancher/v2.x/en/admin-settings/k8s-metadata/) Rancher Kubernetes Metadata contains Kubernetes version information which Rancher uses to provision [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). From 3a9cf5d0bbf99db107ae49f80c814dafb9d169bf Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Thu, 17 Oct 2019 15:41:12 -0700 Subject: [PATCH 58/82] meta updates --- content/rancher/v2.x/en/_index.md | 2 + .../authentication/keycloak/_index.md | 1 + content/rancher/v2.x/en/catalog/_index.md | 3 +- content/rancher/v2.x/en/cli/_index.md | 3 +- .../cleaning-cluster-nodes/_index.md | 3 +- .../en/cluster-admin/kubeconfig/_index.md | 3 +- .../v2.x/en/cluster-admin/kubectl/_index.md | 3 +- .../projects-and-namespaces/_index.md | 3 +- .../en/cluster-admin/tools/logging/_index.md | 3 +- .../cluster-admin/tools/monitoring/_index.md | 3 +- .../volumes-and-storage/_index.md | 3 +- .../v2.x/en/cluster-provisioning/_index.md | 1 + .../imported-clusters/_index.md | 3 +- .../rke-clusters/custom-nodes/_index.md | 1 + .../rke-clusters/node-pools/ec2/_index.md | 3 +- .../rke-clusters/node-pools/vsphere/_index.md | 1 + .../en/faq/networking/cni-providers/_index.md | 3 +- .../rancher/v2.x/en/installation/_index.md | 3 +- .../rancher/v2.x/en/installation/ha/_index.md | 1 + .../en/installation/ha/helm-rancher/_index.md | 3 +- .../installation/ha/kubernetes-rke/_index.md | 3 +- .../options/helm2/helm-init/_index.md | 3 +- .../helm2/helm-rancher/tls-secrets/_index.md | 3 +- .../en/installation/requirements/_index.md | 1 + .../installation/requirements/ports/_index.md | 1 + .../en/installation/single-node/_index.md | 221 ++++++++++++++++++ .../en/k8s-in-rancher/certificates/_index.md | 3 +- .../horitzontal-pod-autoscaler/_index.md | 5 +- .../load-balancers-and-ingress/_index.md | 3 +- .../ingress/_index.md | 3 +- .../load-balancers/_index.md | 3 +- .../en/k8s-in-rancher/registries/_index.md | 5 +- .../en/k8s-in-rancher/workloads/_index.md | 3 +- .../workloads/deploy-workloads/_index.md | 1 + .../project-admin/tools/pipelines/_index.md | 3 +- .../v2.x/en/quick-start-guide/_index.md | 4 +- .../deployment/amazon-aws-qs/_index.md | 3 +- content/rke/latest/en/_index.md | 1 + .../rke/latest/en/config-options/_index.md | 3 +- .../add-ons/ingress-controllers/_index.md | 3 +- .../en/config-options/services/_index.md | 3 +- content/rke/latest/en/installation/_index.md | 3 +- .../rke/latest/en/managing-clusters/_index.md | 1 + 43 files changed, 297 insertions(+), 34 deletions(-) create mode 100644 content/rancher/v2.x/en/installation/single-node/_index.md diff --git a/content/rancher/v2.x/en/_index.md b/content/rancher/v2.x/en/_index.md index fa26e62f19b..75828fee200 100644 --- a/content/rancher/v2.x/en/_index.md +++ b/content/rancher/v2.x/en/_index.md @@ -1,5 +1,7 @@ --- +title: Rancher 2.x shortTitle: Rancher 2.x +description: Rancher adds significant value on top of Kubernetes, managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more. insertOneSix: true weight: 1 ctaBanner: intro-k8s-rancher-online-training diff --git a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md index 550f1848066..9da68a94c75 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md @@ -1,5 +1,6 @@ --- title: Configuring Keycloak (SAML) +description: Create a Keycloack SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins weight: 1200 --- _Available as of v2.1.0_ diff --git a/content/rancher/v2.x/en/catalog/_index.md b/content/rancher/v2.x/en/catalog/_index.md index 0481cacca6f..b0874d88278 100644 --- a/content/rancher/v2.x/en/catalog/_index.md +++ b/content/rancher/v2.x/en/catalog/_index.md @@ -1,5 +1,6 @@ --- -title: Catalogs and Apps +title: Catalogs, Helm Charts and Apps +description: Rancher enables the use of catalogs to repeatedly deploy applications easily. Catalogs are GitHub or Helm Chart repositories filled with deployment-ready apps. weight: 4000 aliases: - /rancher/v2.x/en/concepts/global-configuration/catalog/ diff --git a/content/rancher/v2.x/en/cli/_index.md b/content/rancher/v2.x/en/cli/_index.md index de92ac71134..db7a09d6383 100644 --- a/content/rancher/v2.x/en/cli/_index.md +++ b/content/rancher/v2.x/en/cli/_index.md @@ -1,5 +1,6 @@ --- -title: CLI +title: Using the Rancher Command Line Interface +description: The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI weight: 6000 aliases: - /rancher/v2.x/en/concepts/cli-configuration/ diff --git a/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md index ba21aa77071..41f61a37aa1 100644 --- a/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md @@ -1,5 +1,6 @@ --- -title: Cleaning up Clusters +title: Removing Kubernetes Components from Nodes +description: Learn about cluster cleanup when removing nodes from your Rancher-launched Kubernetes cluster. What is removed, how to do it manually weight: 2055 aliases: - /rancher/v2.x/en/faq/cleaning-cluster-nodes/ diff --git a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md index 02f446ad078..ecda9446aca 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md @@ -1,5 +1,6 @@ --- -title: Kubeconfig File +title: Configuring Access to Kubernetes Using A Kubeconfig File +description: A kubeconfig file is used to configure access to Kubernetes. When you create a cluster with Rancher, it automatically creates a kubeconfig for your cluster weight: 2010 aliases: - /rancher/v2.x/en/concepts/clusters/kubeconfig-files/ diff --git a/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md b/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md index 2d332ac495a..62e221eade5 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md @@ -1,5 +1,6 @@ --- -title: Using kubectl to Access a Cluster +title: Access a Cluster with Kubectl Shell or Kubectl CLI +description: Learn how you can access and manage your Kubernetes clusters using kubectl in two ways, with the kubectl shell or with the kubectl CLI and a kubeconfig file weight: 2015 aliases: - /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/ diff --git a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md index b7c9b4bfb3b..a47f7349041 100644 --- a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md @@ -1,5 +1,6 @@ --- -title: Projects and Namespaces +title: Projects and Kubernetes Namespaces with Rancher +description: Rancher Projects ease the administrative burden of your cluster and support multi-tenancy. Learn to create projects and divide projects into Kubernetes namespaces weight: 2032 aliases: - /rancher/v2.x/en/concepts/projects/ diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md index 86ca4105843..ed2f30e4e91 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md @@ -1,5 +1,6 @@ --- -title: Logging +title: Rancher Integration with Logging Services +description: Rancher integrates with popular logging services. Learn the requirements and benefits of integrating with logging services, and enable logging on your cluster. weight: 3 aliases: - /rancher/v2.x/en/tasks/logging/ diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md index a1c48123f1d..887bcda96d1 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md @@ -1,5 +1,6 @@ --- -title: Monitoring +title: Integrating Rancher and Prometheus for Cluster Monitoring +description: Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Lern about the scope of monitoring and how to enable cluster monitoring weight: 4 --- diff --git a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md index e8dea8adda3..09bf98357cc 100644 --- a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md @@ -1,5 +1,6 @@ --- -title: Volumes and Storage +title: Kubernetes Persistent Storage, Volumes, and Storage Classes +description: Learn about creating persistent storage in Kubernetes with persistent volumes and storage classes weight: 2031 aliases: - /rancher/v2.x/en/concepts/volumes-and-storage/ diff --git a/content/rancher/v2.x/en/cluster-provisioning/_index.md b/content/rancher/v2.x/en/cluster-provisioning/_index.md index 79cf83e18be..983f06da9fd 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/_index.md @@ -1,5 +1,6 @@ --- title: Provisioning Kubernetes Clusters +description: Read about Kubernetes clusters, what they are, the different node types, and how to create clusters in Rancher weight: 2000 aliases: - /rancher/v2.x/en/concepts/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 3659965b958..9db34f74e1a 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 @@ -1,5 +1,6 @@ --- -title: Importing Kubernetes Clusters +title: Import an Existing Cluster to Create a Cluster in Rancher +description: Learn how you can create a cluster in Rancher by importing an existing Kubernetes cluster. Then, you can manage it using Rancher weight: 2300 aliases: - /rancher/v2.x/en/tasks/clusters/import-cluster/ diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md index 3c374653307..0f82b86f606 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md @@ -1,5 +1,6 @@ --- title: Creating a Cluster with Custom Nodes +description: To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements shortTitle: Custom Nodes weight: 2225 aliases: diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md index fa9f9b61084..1f32b1e6bd9 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md @@ -1,6 +1,7 @@ --- title: Creating an Amazon EC2 Cluster shortTitle: Amazon EC2 +description: Learn the prerequisites and steps required in order for you to create an Amazon EC2 cluster using Rancher weight: 2210 aliases: - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-amazon-ec2/ @@ -199,4 +200,4 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. } ] } -``` \ No newline at end of file +``` diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md index 23b0a9bc6e1..cd8548d2f1a 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md @@ -1,6 +1,7 @@ --- title: Creating a vSphere Cluster shortTitle: vSphere +description: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes. weight: 2225 aliases: - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/ diff --git a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md index 5a2d100e8d8..28b7f587576 100644 --- a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md +++ b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md @@ -1,5 +1,6 @@ --- -title: CNI Providers +title: Container Network Interface (CNI) Providers +description: Learn about Container Network Interface (CNI), the CNI providers Rancher provides, the features they offer, and how to choose a provider for you weight: 2300 --- diff --git a/content/rancher/v2.x/en/installation/_index.md b/content/rancher/v2.x/en/installation/_index.md index d9260f8ba4e..b8368a203c4 100644 --- a/content/rancher/v2.x/en/installation/_index.md +++ b/content/rancher/v2.x/en/installation/_index.md @@ -1,5 +1,6 @@ --- -title: Installation +title: Overview of Installation Options +description: Learn how to install Rancher in development and production environments. Read about single node and high availability installation weight: 50 --- diff --git a/content/rancher/v2.x/en/installation/ha/_index.md b/content/rancher/v2.x/en/installation/ha/_index.md index 2e0be6690e9..911727c33b1 100644 --- a/content/rancher/v2.x/en/installation/ha/_index.md +++ b/content/rancher/v2.x/en/installation/ha/_index.md @@ -1,6 +1,7 @@ --- title: How to Install Rancher on a High-availability Kubernetes Cluster weight: 3 +description: For production environments, install Rancher in a high-availability configuration. Read the guide for setting up a 3-node cluster and still install Rancher using a Helm chart. --- For production environments, we recommend installing Rancher in a high-availability configuration so that your user base can always access Rancher Server. When installed in a Kubernetes cluster, Rancher will integrate with the cluster's etcd database and take advantage of Kubernetes scheduling for high-availability. diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md index 1ac1f8e34ad..c4d34c8a990 100644 --- a/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md +++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md @@ -1,5 +1,6 @@ --- -title: '3. Install Rancher' +title: 3. Installing Rancher Using the Helm Kubernetes Package Manager +description: Rancher installation is managed using the Helm Kubernetes package manager. Use Helm to install the prerequisites and charts to install Rancher weight: 200 --- diff --git a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md index e785a901ac9..49311af0aba 100644 --- a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md +++ b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md @@ -1,5 +1,6 @@ --- -title: '2. Install Kubernetes with RKE' +title: 2. Install Kubernetes with RKE +description: Learn how to use Rancher Kubernetes Engine (RKE) to install Kubernetes with a high availability etcd configuration. weight: 190 --- diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md index 16b37158c37..ab14a6ef048 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md @@ -1,5 +1,6 @@ --- -title: "3. Initialize Helm (Install Tiller)" +title: Initialize Helm: Install the Tiller Service +description: With Helm, you can create configurable deployments instead of using static files. In order to use Helm, the Tiller service needs to be installed on your cluster. weight: 195 --- diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md index 2866ca911e5..18ba0341f67 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md @@ -1,5 +1,6 @@ --- -title: Adding TLS Secrets +title: Adding Kubernetes TLS Secrets +description: Read about how to populate the Kubernetes TLS secret for a Rancher installation weight: 276 --- diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index 82577dd86b0..867c969151b 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -1,5 +1,6 @@ --- title: Installation Requirements +description: Learn the node requirements for each node running Rancher server when you’re configuring Rancher to run either in a single-node or high-availability setup weight: 1 aliases: - /rancher/v2.x/en/installation/references diff --git a/content/rancher/v2.x/en/installation/requirements/ports/_index.md b/content/rancher/v2.x/en/installation/requirements/ports/_index.md index a39ef0ca510..6f42a6f2b56 100644 --- a/content/rancher/v2.x/en/installation/requirements/ports/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/ports/_index.md @@ -1,5 +1,6 @@ --- title: Port Requirements +description: Read about port requirements needed in order for Rancher to operate properly, both for Rancher nodes and Kubernetes cluster nodes weight: 300 --- diff --git a/content/rancher/v2.x/en/installation/single-node/_index.md b/content/rancher/v2.x/en/installation/single-node/_index.md new file mode 100644 index 00000000000..7de572c5911 --- /dev/null +++ b/content/rancher/v2.x/en/installation/single-node/_index.md @@ -0,0 +1,221 @@ +--- +title: Single Node Install +description: For development and testing environments, use a single node install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container. +weight: 250 +aliases: + - /rancher/v2.x/en/installation/single-node-install/ +--- +For development and testing environments, we recommend installing Rancher by running a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container. + +>**Want to use an external load balancer?** +> See [Single Node Install with an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/single-node-install-external-lb) instead. + +## 1. Provision Linux Host + +Provision a single Linux host according to our [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements) to launch your {{< product >}} Server. + +## 2. Choose an SSL Option and Install Rancher + +For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster. + +>**Do you want to...** +> +>- Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/proxy/) +>- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) +>- Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/) +>- Record all transactions with the Rancher API? See [API Auditing](#api-audit-log) +> + +Choose from the following options: + +{{% accordion id="option-a" label="Option A-Default Self-Signed Certificate" %}} + +If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself. + +Log into your Linux host, and then run the minimum installation command below. + + + docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + rancher/rancher:latest + + +{{% /accordion %}} +{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Self-Signed" %}} +In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher. + +>**Prerequisites:** +>Create a self-signed certificate using [OpenSSL](https://www.openssl.org/) or another method of your choice. +> +>- The certificate files must be in [PEM format](#pem). +>- 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 [SSL FAQ / Troubleshooting](#cert-order). + +After creating your certificate, run the Docker command below to install Rancher. Use the `-v` flag and provide the path to your certificates to mount them in your container. + +Placeholder | Description +------------|------------- +`` | The path to the directory containing your certificate files. +`` | The path to your full certificate chain. +`` | The path to the private key for your certificate. +`` | The path to the certificate authority's private key. + +``` +docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + -v //:/etc/rancher/ssl/cert.pem \ + -v //:/etc/rancher/ssl/key.pem \ + -v //:/etc/rancher/ssl/cacerts.pem \ + rancher/rancher:latest +``` +{{% /accordion %}} +{{% accordion id="option-c" label="Option C-Bring Your Own Certificate: Signed by Recognized CA" %}} + +In production environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings. + +>**Prerequisites:** +> +>- The certificate files must be in [PEM format](#pem). +>- In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [SSL FAQ / Troubleshooting](#cert-order). + +After obtaining your certificate, run the Docker command below. + +- Use the `-v` flag and provide the path to your certificates to mount them in your container. Because your certificate is signed by a recognized CA, mounting an additional CA certificate file is unnecessary. +- Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher. + +Placeholder | Description +------------|------------- +`` | The path to the directory containing your certificate files. +`` | The path to your full certificate chain. +`` | The path to the private key for your certificate. + +``` +docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + -v //:/etc/rancher/ssl/cert.pem \ + -v //:/etc/rancher/ssl/key.pem \ + rancher/rancher:latest \ + --no-cacerts +``` +{{% /accordion %}} +{{% accordion id="option-d" label="Option D-Let's Encrypt Certificate" %}} + +>**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/). + +For production environments, you also have the option of using [Let's Encrypt](https://letsencrypt.org/) certificates. Let's Encrypt uses an http-01 challenge to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS. + +>**Prerequisites:** +> +>- Let's Encrypt is an Internet service. Therefore, this option cannot be used in an internal/air gapped network. +>- Create a record in your DNS that binds your Linux host IP address to the hostname that you want to use for Rancher access (`rancher.mydomain.com` for example). +>- Open port `TCP/80` on your Linux host. The Let's Encrypt http-01 challenge can come from any source IP address, so port `TCP/80` must be open to all IP addresses. + + +After you fulfill the prerequisites, you can install Rancher using a Let's Encrypt certificate by running the following command. + +Placeholder | Description +------------|------------- +`` | Your domain address + +``` +docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + rancher/rancher:latest \ + --acme-domain +``` + +{{% /accordion %}} + +## What's Next? + +- **Recommended:** Review [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/). Although you don't have any data you need to back up right now, we recommend creating backups after regular Rancher use. +- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/). + +
+ +## Advanced Options + +When installing Rancher, there are several [advanced options]({{< baseurl >}}/rancher/v2.x/en/installation/options/) that can be enabled. + +### Custom CA Certificate + +If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate. + +Use the command example to start a Rancher container with your private CA certificates mounted. + +- The volume option (`-v`) should specify the host directory containing the CA root certificates. +- The `e` flag in combination with `SSL_CERT_DIR` declares an environment variable that specifies the mounted CA root certificates directory location inside the container. + - Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. + - Mounting a host directory inside the container can be done using `-v host-source-directory:container-destination-directory` or `--volume host-source-directory:container-destination-directory`. + +The example below is based on having the CA root certificates in the `/host/certs` directory on the host and mounting this directory on `/container/certs` inside the Rancher container. + +``` +docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + -v /host/certs:/container/certs \ + -e SSL_CERT_DIR="/container/certs" \ + rancher/rancher:latest +``` + +### API Audit Log + +The API Audit Log records all the user and system transactions made through Rancher server. + +The API Audit Log writes to `/var/log/auditlog` inside the rancher container by default. Share that directory as a volume and set your `AUDIT_LEVEL` to enable the log. + +See [API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) for more information and options. + +``` +docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + -v /var/log/rancher/auditlog:/var/log/auditlog \ + -e AUDIT_LEVEL=1 \ + rancher/rancher:latest +``` + +### TLS settings + +_Available as of v2.1.7_ + +To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version: + +``` +docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + -e CATTLE_TLS_MIN_VERSION="1.0" \ + rancher/rancher:latest +``` + +See [TLS settings]({{< baseurl >}}/rancher/v2.x/en/admin-settings/tls-settings) for more information and options. + +### Air Gap + +If you are visiting this page to complete an air gap installation, you must pre-pend your private registry URL to the server tag when running the installation command in the option that you choose. Add `` with your private registry URL in front of `rancher/rancher:latest`. + +**Example:** + + /rancher/rancher:latest + +### Persistent Data + +{{< persistentdata >}} + +### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node + +In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container. + +If a node is added to a cluster, it deploys the nginx ingress controller which will use port 80 and 443. This will conflict with the default ports we advise to expose for the `rancher/rancher` container. + +Please note that this setup is not recommended for production use, but can be convenient for development/demo purposes. + +To change the host ports mapping, replace the following part `-p 80:80 -p 443:443` with `-p 8080:80 -p 8443:443`: + +``` +docker run -d --restart=unless-stopped \ + -p 8080:80 -p 8443:443 \ + rancher/rancher:latest +``` + +## FAQ and Troubleshooting + +{{< ssl_faq_single >}} diff --git a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md index c6d41986124..b2d81be4bd7 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md @@ -1,5 +1,6 @@ --- -title: SSL Certificates +title: Secure Sockets Layer Certificate +description: Learn how to add a secure sockets layer (SSL) certificate to either a project, a namespace, or both, so that you can add it to deployments weight: 3060 aliases: - /rancher/v2.x/en/tasks/projects/add-ssl-certificates/ diff --git a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md index 55580b4bb16..2301619cd7a 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md @@ -1,5 +1,6 @@ --- -title: Horizontal Pod Autoscaler +title: The Horizontal Pod Autoscaler +description: Learn about the horizontal pod autoscaler (HPA). How to manage HPAs and how to test them with a service deployment weight: 3026 --- @@ -31,4 +32,4 @@ You might have additional HPA installation steps if you are using an older versi In Rancher v2.3.x+, you can see your HPA's current number of replicas by going to your project and clicking **Resources > HPA.** For more information, refer to [Get HPA Metrics and Status]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/). You can also use `kubectl` to get the status of HPAs that you test with your load testing tool. For more information, refer to [Testing HPAs with kubectl] -({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/). \ No newline at end of file +({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/). diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md index ef8e7c8d762..096c69a6c17 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/_index.md @@ -1,5 +1,6 @@ --- -title: Load Balancing and Ingresses +title: Set Up Load Balancer and Ingress Controller within Rancher +description: Learn how you can set up load balancers and ingress controllers to redirect service requests within Rancher, and learn about the limitations of load balancers weight: 3040 --- diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md index ce3ced278ed..409d2b64b60 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md @@ -1,5 +1,6 @@ --- -title: Ingress +title: Adding Ingresses to Your Project +description: Ingresses can be added for workloads to provide load balancing, SSL termination and host/path-based routing. Learn how to add Rancher ingress to your project weight: 3042 aliases: - /rancher/v2.x/en/tasks/workloads/add-ingress/ diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md index c00f76846db..0069bde6f75 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md @@ -1,5 +1,6 @@ --- -title: Load Balancers +title: Layer 4 and Layer 7 Load Balancing +description: Kubernetes supports load balancing with Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments weight: 3041 aliases: - /rancher/v2.x/en/concepts/load-balancing/ diff --git a/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md index 663c04b0e75..36bbd21c1e8 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md @@ -1,5 +1,6 @@ --- -title: Registries +title: Kubernetes Registry and Docker Registry +description: Learn about the Docker registry and Kubernetes registry, their use cases and how to use a private registry with the Rancher UI weight: 3063 aliases: - /rancher/v2.x/en/tasks/projects/add-registries/ @@ -112,4 +113,4 @@ The result should look like this: 10s Normal Pulled Pod Successfully pulled image "quay.io//" ``` -For more information, refer to the Kubernetes documentation on [creating a pod that uses your secret.](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret) \ No newline at end of file +For more information, refer to the Kubernetes documentation on [creating a pod that uses your secret.](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-pod-that-uses-your-secret) diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md index f5da74a4a81..e25b3b7c54d 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md @@ -1,5 +1,6 @@ --- -title: Workloads +title: Kubernetes Workloads and Pods +description: Learn about the two constructs with which you can build any complex containerized application in Kubernetes, Kubernetes workloads and pods weight: 3025 aliases: - /rancher/v2.x/en/concepts/workloads/ diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md index 0ae69d79bd4..123c2fd295f 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/_index.md @@ -1,5 +1,6 @@ --- title: Deploying Workloads +description: Read this step by step guide for deploying workloads. Deploy a workload to run an application in one or more containers. weight: 3026 aliases: - /rancher/v2.x/en/tasks/workloads/deploy-workloads/ diff --git a/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md b/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md index 4628689ee68..53c21a827f6 100644 --- a/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md +++ b/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md @@ -1,5 +1,6 @@ --- -title: Pipelines +title: Rancher's CI/CD Pipelines +description: Use Rancher’s CI/CD pipeline to automatically checkout code, run builds or scripts, publish Docker images, and deploy software to users weight: 2529 aliases: - /rancher/v2.x/en/concepts/ci-cd-pipelines/ diff --git a/content/rancher/v2.x/en/quick-start-guide/_index.md b/content/rancher/v2.x/en/quick-start-guide/_index.md index e9b6640327a..99f2fda4262 100644 --- a/content/rancher/v2.x/en/quick-start-guide/_index.md +++ b/content/rancher/v2.x/en/quick-start-guide/_index.md @@ -1,6 +1,6 @@ --- -title: Quick Start Guides -short title: Quick Start Index +title: Rancher Deployment Quick Start Guides +short title: Use this section to jump start your Rancher deployment and testing. It contains instructions for a simple Rancher setup and some common use cases. weight: 25 --- >**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation]({{< baseurl >}}/rancher/v2.x/en/installation/). diff --git a/content/rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/_index.md b/content/rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/_index.md index 7519a654cbf..65fee61875a 100644 --- a/content/rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/_index.md +++ b/content/rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/_index.md @@ -1,5 +1,6 @@ --- -title: Amazon AWS Quick Start +title: Rancher AWS Quick Start Guide +description: Read this step by step Rancher AWS guide to quickly deploy a Rancher Server with a single node cluster attached. weight: 100 --- The following steps will quickly deploy a Rancher Server with a single node cluster attached. diff --git a/content/rke/latest/en/_index.md b/content/rke/latest/en/_index.md index edd0d014bee..9ff72d7c3a2 100644 --- a/content/rke/latest/en/_index.md +++ b/content/rke/latest/en/_index.md @@ -1,6 +1,7 @@ --- title: Overview of RKE shortTitle: RKE +description: RKE solves Kubernetes installation complexity. With RKE, Kubernetes installation is simplified, regardless of what OSs and platforms you’re running. weight: 1 --- diff --git a/content/rke/latest/en/config-options/_index.md b/content/rke/latest/en/config-options/_index.md index 5ea4de749c8..64cb99d8932 100644 --- a/content/rke/latest/en/config-options/_index.md +++ b/content/rke/latest/en/config-options/_index.md @@ -1,5 +1,6 @@ --- -title: Config Options +title: Kubernetes Configuration Options +description: There are a lot of different Kubernetes Configuration options you can choose from when setting up your cluster.yml for RKE weight: 200 --- diff --git a/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md b/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md index 8044305eb63..a7da4af0cd6 100644 --- a/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md +++ b/content/rke/latest/en/config-options/add-ons/ingress-controllers/_index.md @@ -1,5 +1,6 @@ --- -title: Ingress Controllers +title: K8s Ingress Controllers +description: By default, RKE deploys the NGINX ingress controller. Learn how to schedule and disable default k8s ingress controllers, and how to configure NGINX controller weight: 262 --- diff --git a/content/rke/latest/en/config-options/services/_index.md b/content/rke/latest/en/config-options/services/_index.md index 17af63348bf..cfd88cc39a9 100644 --- a/content/rke/latest/en/config-options/services/_index.md +++ b/content/rke/latest/en/config-options/services/_index.md @@ -1,5 +1,6 @@ --- -title: Kubernetes Default Services +title: Default Kubernetes Services +description: To deploy Kubernetes, RKE deploys several default Kubernetes services. Read about etcd, kube-api server, kubelet, kube-proxy and more weight: 230 --- diff --git a/content/rke/latest/en/installation/_index.md b/content/rke/latest/en/installation/_index.md index dcfc313ef21..aa3745781c5 100644 --- a/content/rke/latest/en/installation/_index.md +++ b/content/rke/latest/en/installation/_index.md @@ -1,5 +1,6 @@ --- -title: Installation +title: RKE Kubernetes Installation +description: RKE is a fast, versatile Kubernetes installer you can use to install Kubernetes on your Linux hosts. Learn the simple steps for an RKE Kubernetes installation weight: 50 --- diff --git a/content/rke/latest/en/managing-clusters/_index.md b/content/rke/latest/en/managing-clusters/_index.md index bfed7a7d10e..24dcb07884b 100644 --- a/content/rke/latest/en/managing-clusters/_index.md +++ b/content/rke/latest/en/managing-clusters/_index.md @@ -1,5 +1,6 @@ --- title: Adding and Removing Nodes +description: RKE supports adding/removing nodes for worker and controlplane hosts. Learn about the changes you need to make to the cluster.yml in order to add/remove nodes weight: 175 aliases: - /rke/latest/en/installation/managing-clusters/ From 02c3c18f8cb5b2e14a512b60d71bb3365f968984 Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Tue, 5 Nov 2019 10:34:10 -0800 Subject: [PATCH 59/82] adding quotes to some problmatic meta --- content/rancher/v2.x/en/_index.md | 6 +++--- content/rancher/v2.x/en/cluster-admin/kubectl/_index.md | 4 ++-- .../v2.x/en/cluster-admin/volumes-and-storage/_index.md | 4 ++-- .../v2.x/en/installation/options/helm2/helm-init/_index.md | 4 ++-- .../load-balancers-and-ingress/load-balancers/_index.md | 4 ++-- content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md | 4 ++-- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/content/rancher/v2.x/en/_index.md b/content/rancher/v2.x/en/_index.md index 75828fee200..183a84d1e71 100644 --- a/content/rancher/v2.x/en/_index.md +++ b/content/rancher/v2.x/en/_index.md @@ -1,7 +1,7 @@ --- -title: Rancher 2.x -shortTitle: Rancher 2.x -description: Rancher adds significant value on top of Kubernetes, managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more. +title: "Rancher 2.x" +shortTitle: "Rancher 2.x" +description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more." insertOneSix: true weight: 1 ctaBanner: intro-k8s-rancher-online-training diff --git a/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md b/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md index 62e221eade5..190f080af7b 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md @@ -1,6 +1,6 @@ --- -title: Access a Cluster with Kubectl Shell or Kubectl CLI -description: Learn how you can access and manage your Kubernetes clusters using kubectl in two ways, with the kubectl shell or with the kubectl CLI and a kubeconfig file +title: "Access a Cluster with Kubectl Shell or Kubectl CLI" +description: "Lean how you can access and manage your Kubernetes clusters using kubectl in two ways: with kubectl Shell or with kubectl CLI and kuberconfig file" weight: 2015 aliases: - /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/ diff --git a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md index 09bf98357cc..f37822b1eb9 100644 --- a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md @@ -1,6 +1,6 @@ --- -title: Kubernetes Persistent Storage, Volumes, and Storage Classes -description: Learn about creating persistent storage in Kubernetes with persistent volumes and storage classes +title: "Kubernetes Persistent Storage: Volumes and Storage Classes" +description: "Learn about the two ways with which you can creat persistent storage in Kubernetes: persistent volumes and storage classes" weight: 2031 aliases: - /rancher/v2.x/en/concepts/volumes-and-storage/ diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md index ab14a6ef048..a88abd42de1 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-init/_index.md @@ -1,6 +1,6 @@ --- -title: Initialize Helm: Install the Tiller Service -description: With Helm, you can create configurable deployments instead of using static files. In order to use Helm, the Tiller service needs to be installed on your cluster. +title: "Initialize Helm: Install the Tiller Service" +description: "With Helm, you can create configurable deployments instead of using static files. In order to use Helm, the Tiller service needs to be installed on your cluster." weight: 195 --- diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md index 0069bde6f75..c8229313a7b 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/_index.md @@ -1,6 +1,6 @@ --- -title: Layer 4 and Layer 7 Load Balancing -description: Kubernetes supports load balancing with Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments +title: "Layer 4 and Layer 7 Load Balancing" +description: "Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer-7 Load Balancing. Learn about the support for each way in different deployments" weight: 3041 aliases: - /rancher/v2.x/en/concepts/load-balancing/ diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md index e25b3b7c54d..617929af284 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/_index.md @@ -1,6 +1,6 @@ --- -title: Kubernetes Workloads and Pods -description: Learn about the two constructs with which you can build any complex containerized application in Kubernetes, Kubernetes workloads and pods +title: "Kubernetes Workloads and Pods" +description: "Learn about the two constructs with which you can build any complex containerized application in Kubernetes: Kubernetes workloads and pods" weight: 3025 aliases: - /rancher/v2.x/en/concepts/workloads/ From 8d868f542c829b0ab88e8443ee254c7b932f52c1 Mon Sep 17 00:00:00 2001 From: Robert Parker Date: Wed, 4 Dec 2019 16:50:55 -0800 Subject: [PATCH 60/82] meta updates --- content/rancher/v2.x/en/_index.md | 2 ++ content/rancher/v2.x/en/cli/_index.md | 2 ++ content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md | 1 + content/rancher/v2.x/en/cluster-provisioning/_index.md | 2 +- .../v2.x/en/cluster-provisioning/imported-clusters/_index.md | 2 ++ .../en/cluster-provisioning/rke-clusters/custom-nodes/_index.md | 1 + .../rke-clusters/node-pools/vsphere/_index.md | 1 + .../options/helm2/helm-rancher/tls-secrets/_index.md | 2 +- content/rancher/v2.x/en/quick-start-guide/_index.md | 1 + 9 files changed, 12 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/_index.md b/content/rancher/v2.x/en/_index.md index 183a84d1e71..1cdb421ebd0 100644 --- a/content/rancher/v2.x/en/_index.md +++ b/content/rancher/v2.x/en/_index.md @@ -2,6 +2,8 @@ title: "Rancher 2.x" shortTitle: "Rancher 2.x" description: "Rancher adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more." +metaTitle: "Rancher 2.x Docs: What is New?" +metaDescription: "Rancher 2 adds significant value on top of Kubernetes: managing hundreds of clusters from one interface, centralizing RBAC, enabling monitoring and alerting. Read more." insertOneSix: true weight: 1 ctaBanner: intro-k8s-rancher-online-training diff --git a/content/rancher/v2.x/en/cli/_index.md b/content/rancher/v2.x/en/cli/_index.md index db7a09d6383..956fe637aeb 100644 --- a/content/rancher/v2.x/en/cli/_index.md +++ b/content/rancher/v2.x/en/cli/_index.md @@ -1,6 +1,8 @@ --- title: Using the Rancher Command Line Interface description: The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI +metaTitle: "Using the Rancher Command Line Interface " +metaDescription: "The Rancher CLI is a unified tool that you can use to interact with Rancher. With it, you can operate Rancher using a command line interface rather than the GUI" weight: 6000 aliases: - /rancher/v2.x/en/concepts/cli-configuration/ diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md index ed2f30e4e91..42fe6e49253 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md @@ -1,6 +1,7 @@ --- title: Rancher Integration with Logging Services description: Rancher integrates with popular logging services. Learn the requirements and benefits of integrating with logging services, and enable logging on your cluster. +metaDescription: "Rancher integrates with popular logging services. Learn the requirements and benefits of integrating with logging services, and enable logging on your cluster." weight: 3 aliases: - /rancher/v2.x/en/tasks/logging/ diff --git a/content/rancher/v2.x/en/cluster-provisioning/_index.md b/content/rancher/v2.x/en/cluster-provisioning/_index.md index 983f06da9fd..778123a3c45 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/_index.md @@ -1,6 +1,6 @@ --- title: Provisioning Kubernetes Clusters -description: Read about Kubernetes clusters, what they are, the different node types, and how to create clusters in Rancher +description: Provisioning Kubernetes Clusters weight: 2000 aliases: - /rancher/v2.x/en/concepts/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 9db34f74e1a..e5172a8af7e 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 @@ -1,6 +1,8 @@ --- title: Import an Existing Cluster to Create a Cluster in Rancher description: Learn how you can create a cluster in Rancher by importing an existing Kubernetes cluster. Then, you can manage it using Rancher +metaTitle: "Kubernetes Cluster Management" +metaDescription: "Learn how you can import an existing Kubernetes cluster and then manage it using Rancher" weight: 2300 aliases: - /rancher/v2.x/en/tasks/clusters/import-cluster/ diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md index 0f82b86f606..3ba53e83e2d 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/_index.md @@ -1,6 +1,7 @@ --- title: Creating a Cluster with Custom Nodes description: To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements +metaDescription: "To create a cluster with custom nodes, you’ll need to access servers in your cluster and provision them according to Rancher requirements" shortTitle: Custom Nodes weight: 2225 aliases: diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md index cd8548d2f1a..e512460253d 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/_index.md @@ -2,6 +2,7 @@ title: Creating a vSphere Cluster shortTitle: vSphere description: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes. +metaDescription: Use Rancher to create a vSphere cluster. It may consist of groups of VMs with distinct properties which allow for fine-grained control over the sizing of nodes. weight: 2225 aliases: - /rancher/v2.x/en/tasks/clusters/creating-a-cluster/create-cluster-vsphere/ diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md index 18ba0341f67..8920125b9f8 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/tls-secrets/_index.md @@ -1,6 +1,6 @@ --- title: Adding Kubernetes TLS Secrets -description: Read about how to populate the Kubernetes TLS secret for a Rancher installation +description: Read about how to populate the Kubernetes TLS secret for a Rancher installation weight: 276 --- diff --git a/content/rancher/v2.x/en/quick-start-guide/_index.md b/content/rancher/v2.x/en/quick-start-guide/_index.md index 99f2fda4262..630450f42d2 100644 --- a/content/rancher/v2.x/en/quick-start-guide/_index.md +++ b/content/rancher/v2.x/en/quick-start-guide/_index.md @@ -1,5 +1,6 @@ --- title: Rancher Deployment Quick Start Guides +metaDescription: Use this section to jump start your Rancher deployment and testing. It contains instructions for a simple Rancher setup and some common use cases. short title: Use this section to jump start your Rancher deployment and testing. It contains instructions for a simple Rancher setup and some common use cases. weight: 25 --- From 69af87ff51ef1e418ab204b7a152db327512a653 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 15:51:54 -0700 Subject: [PATCH 61/82] Fix sidebar navigation --- .../rancher/v2.x/en/installation/_index.md | 2 +- .../single-node/_index.md | 2 +- .../en/installation/single-node/_index.md | 221 ------------------ 3 files changed, 2 insertions(+), 223 deletions(-) delete mode 100644 content/rancher/v2.x/en/installation/single-node/_index.md diff --git a/content/rancher/v2.x/en/installation/_index.md b/content/rancher/v2.x/en/installation/_index.md index b8368a203c4..8511d1a4716 100644 --- a/content/rancher/v2.x/en/installation/_index.md +++ b/content/rancher/v2.x/en/installation/_index.md @@ -1,5 +1,5 @@ --- -title: Overview of Installation Options +title: Installing Rancher description: Learn how to install Rancher in development and production environments. Read about single node and high availability installation weight: 50 --- diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md index 3f9083a7d1d..60a1be75680 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md @@ -1,11 +1,11 @@ --- title: Installing Rancher on a Single Node Using Docker +description: For development and testing environments, use a single node install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container. weight: 1 aliases: - /rancher/v2.x/en/installation/single-node-install/ - /rancher/v2.x/en/installation/single-node --- - For development and testing environments, we recommend installing Rancher by running a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container. > **Want to use an external load balancer?** diff --git a/content/rancher/v2.x/en/installation/single-node/_index.md b/content/rancher/v2.x/en/installation/single-node/_index.md deleted file mode 100644 index 7de572c5911..00000000000 --- a/content/rancher/v2.x/en/installation/single-node/_index.md +++ /dev/null @@ -1,221 +0,0 @@ ---- -title: Single Node Install -description: For development and testing environments, use a single node install. Install Docker on a single Linux host, and deploy Rancher with a single Docker container. -weight: 250 -aliases: - - /rancher/v2.x/en/installation/single-node-install/ ---- -For development and testing environments, we recommend installing Rancher by running a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container. - ->**Want to use an external load balancer?** -> See [Single Node Install with an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/single-node-install-external-lb) instead. - -## 1. Provision Linux Host - -Provision a single Linux host according to our [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements) to launch your {{< product >}} Server. - -## 2. Choose an SSL Option and Install Rancher - -For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster. - ->**Do you want to...** -> ->- Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/proxy/) ->- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) ->- Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/) ->- Record all transactions with the Rancher API? See [API Auditing](#api-audit-log) -> - -Choose from the following options: - -{{% accordion id="option-a" label="Option A-Default Self-Signed Certificate" %}} - -If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself. - -Log into your Linux host, and then run the minimum installation command below. - - - docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - rancher/rancher:latest - - -{{% /accordion %}} -{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Self-Signed" %}} -In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher. - ->**Prerequisites:** ->Create a self-signed certificate using [OpenSSL](https://www.openssl.org/) or another method of your choice. -> ->- The certificate files must be in [PEM format](#pem). ->- 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 [SSL FAQ / Troubleshooting](#cert-order). - -After creating your certificate, run the Docker command below to install Rancher. Use the `-v` flag and provide the path to your certificates to mount them in your container. - -Placeholder | Description -------------|------------- -`` | The path to the directory containing your certificate files. -`` | The path to your full certificate chain. -`` | The path to the private key for your certificate. -`` | The path to the certificate authority's private key. - -``` -docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - -v //:/etc/rancher/ssl/cert.pem \ - -v //:/etc/rancher/ssl/key.pem \ - -v //:/etc/rancher/ssl/cacerts.pem \ - rancher/rancher:latest -``` -{{% /accordion %}} -{{% accordion id="option-c" label="Option C-Bring Your Own Certificate: Signed by Recognized CA" %}} - -In production environments where you're exposing an app publicly, use a certificate signed by a recognized CA so that your user base doesn't encounter security warnings. - ->**Prerequisites:** -> ->- The certificate files must be in [PEM format](#pem). ->- In your certificate file, include all intermediate certificates provided by the recognized CA. Order your certificates with your certificate first, followed by the intermediates. For an example, see [SSL FAQ / Troubleshooting](#cert-order). - -After obtaining your certificate, run the Docker command below. - -- Use the `-v` flag and provide the path to your certificates to mount them in your container. Because your certificate is signed by a recognized CA, mounting an additional CA certificate file is unnecessary. -- Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher. - -Placeholder | Description -------------|------------- -`` | The path to the directory containing your certificate files. -`` | The path to your full certificate chain. -`` | The path to the private key for your certificate. - -``` -docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - -v //:/etc/rancher/ssl/cert.pem \ - -v //:/etc/rancher/ssl/key.pem \ - rancher/rancher:latest \ - --no-cacerts -``` -{{% /accordion %}} -{{% accordion id="option-d" label="Option D-Let's Encrypt Certificate" %}} - ->**Remember:** Let's Encrypt provides rate limits for requesting new certificates. Therefore, limit how often you create or destroy the container. For more information, see [Let's Encrypt documentation on rate limits](https://letsencrypt.org/docs/rate-limits/). - -For production environments, you also have the option of using [Let's Encrypt](https://letsencrypt.org/) certificates. Let's Encrypt uses an http-01 challenge to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS. - ->**Prerequisites:** -> ->- Let's Encrypt is an Internet service. Therefore, this option cannot be used in an internal/air gapped network. ->- Create a record in your DNS that binds your Linux host IP address to the hostname that you want to use for Rancher access (`rancher.mydomain.com` for example). ->- Open port `TCP/80` on your Linux host. The Let's Encrypt http-01 challenge can come from any source IP address, so port `TCP/80` must be open to all IP addresses. - - -After you fulfill the prerequisites, you can install Rancher using a Let's Encrypt certificate by running the following command. - -Placeholder | Description -------------|------------- -`` | Your domain address - -``` -docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - rancher/rancher:latest \ - --acme-domain -``` - -{{% /accordion %}} - -## What's Next? - -- **Recommended:** Review [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/). Although you don't have any data you need to back up right now, we recommend creating backups after regular Rancher use. -- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/). - -
- -## Advanced Options - -When installing Rancher, there are several [advanced options]({{< baseurl >}}/rancher/v2.x/en/installation/options/) that can be enabled. - -### Custom CA Certificate - -If you want to configure Rancher to use a CA root certificate to be used when validating services, you would start the Rancher container sharing the directory that contains the CA root certificate. - -Use the command example to start a Rancher container with your private CA certificates mounted. - -- The volume option (`-v`) should specify the host directory containing the CA root certificates. -- The `e` flag in combination with `SSL_CERT_DIR` declares an environment variable that specifies the mounted CA root certificates directory location inside the container. - - Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. - - Mounting a host directory inside the container can be done using `-v host-source-directory:container-destination-directory` or `--volume host-source-directory:container-destination-directory`. - -The example below is based on having the CA root certificates in the `/host/certs` directory on the host and mounting this directory on `/container/certs` inside the Rancher container. - -``` -docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - -v /host/certs:/container/certs \ - -e SSL_CERT_DIR="/container/certs" \ - rancher/rancher:latest -``` - -### API Audit Log - -The API Audit Log records all the user and system transactions made through Rancher server. - -The API Audit Log writes to `/var/log/auditlog` inside the rancher container by default. Share that directory as a volume and set your `AUDIT_LEVEL` to enable the log. - -See [API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) for more information and options. - -``` -docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - -v /var/log/rancher/auditlog:/var/log/auditlog \ - -e AUDIT_LEVEL=1 \ - rancher/rancher:latest -``` - -### TLS settings - -_Available as of v2.1.7_ - -To set a different TLS configuration, you can use the `CATTLE_TLS_MIN_VERSION` and `CATTLE_TLS_CIPHERS` environment variables. For example, to configure TLS 1.0 as minimum accepted TLS version: - -``` -docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - -e CATTLE_TLS_MIN_VERSION="1.0" \ - rancher/rancher:latest -``` - -See [TLS settings]({{< baseurl >}}/rancher/v2.x/en/admin-settings/tls-settings) for more information and options. - -### Air Gap - -If you are visiting this page to complete an air gap installation, you must pre-pend your private registry URL to the server tag when running the installation command in the option that you choose. Add `` with your private registry URL in front of `rancher/rancher:latest`. - -**Example:** - - /rancher/rancher:latest - -### Persistent Data - -{{< persistentdata >}} - -### Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node - -In the situation where you want to use a single node to run Rancher and to be able to add the same node to a cluster, you have to adjust the host ports mapped for the `rancher/rancher` container. - -If a node is added to a cluster, it deploys the nginx ingress controller which will use port 80 and 443. This will conflict with the default ports we advise to expose for the `rancher/rancher` container. - -Please note that this setup is not recommended for production use, but can be convenient for development/demo purposes. - -To change the host ports mapping, replace the following part `-p 80:80 -p 443:443` with `-p 8080:80 -p 8443:443`: - -``` -docker run -d --restart=unless-stopped \ - -p 8080:80 -p 8443:443 \ - rancher/rancher:latest -``` - -## FAQ and Troubleshooting - -{{< ssl_faq_single >}} From cc2e744857fcaa649c94a579f6a17a96068e932a Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Mon, 30 Dec 2019 18:26:38 -0700 Subject: [PATCH 62/82] Reorganize cluster administration section --- .../rancher/v2.x/en/cluster-admin/_index.md | 67 ++---------- .../en/cluster-admin/cluster-access/_index.md | 34 ++++++ .../cluster-access/cluster-members/_index.md | 58 ++++++++++ .../{ => cluster-access}/kubeconfig/_index.md | 1 + .../{ => cluster-access}/kubectl/_index.md | 1 + .../cluster-admin/cluster-members/_index.md | 22 ---- .../cluster-admin/editing-clusters/_index.md | 103 +----------------- .../v2.x/en/cluster-admin/nodes/_index.md | 58 +++++++--- .../pod-security-policy/_index.md | 30 +++++ .../v2.x/en/cluster-admin/tools/_index.md | 2 +- .../upgrading-kubernetes/_index.md | 24 ++++ content/rancher/v2.x/en/overview/_index.md | 2 +- .../v2.x/en/overview/architecture/_index.md | 6 +- 13 files changed, 209 insertions(+), 199 deletions(-) create mode 100644 content/rancher/v2.x/en/cluster-admin/cluster-access/_index.md create mode 100644 content/rancher/v2.x/en/cluster-admin/cluster-access/cluster-members/_index.md rename content/rancher/v2.x/en/cluster-admin/{ => cluster-access}/kubeconfig/_index.md (99%) rename content/rancher/v2.x/en/cluster-admin/{ => cluster-access}/kubectl/_index.md (98%) delete mode 100644 content/rancher/v2.x/en/cluster-admin/cluster-members/_index.md create mode 100644 content/rancher/v2.x/en/cluster-admin/pod-security-policy/_index.md create mode 100644 content/rancher/v2.x/en/cluster-admin/upgrading-kubernetes/_index.md diff --git a/content/rancher/v2.x/en/cluster-admin/_index.md b/content/rancher/v2.x/en/cluster-admin/_index.md index f86a2bc5e84..193e40fa6c9 100644 --- a/content/rancher/v2.x/en/cluster-admin/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/_index.md @@ -3,66 +3,15 @@ title: Cluster Administration weight: 2005 --- -## What's a Kubernetes Cluster? - -A cluster is a group of computers that work together as a single system. - -A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestration system](https://kubernetes.io/) to deploy, maintain, and scale Docker containers, allowing your organization to automate application operations. - -### Kubernetes Cluster Node Components - -Each computing resource in a Kubernetes Cluster is called a _node_. Nodes can be either bare-metal servers or virtual machines. Kubernetes classifies nodes into three types: _etcd_ nodes, _control plane_ nodes, and _worker_ nodes. - -#### etcd Nodes - -[etcd](https://kubernetes.io/docs/concepts/overview/components/#etcd) nodes run the etcd database. The etcd database component is a key value store used as Kubernetes storage for all cluster data, such as cluster coordination and state management. - -etcd is a distributed key value store, meaning it runs on multiple nodes so that there's always a backup available for fail over. Even though you can run etcd on a single node, you should run it on multiple nodes. We recommend 3, 5, or 7 etcd nodes for redundancy. - -#### Control Plane Nodes - -[Control plane](https://kubernetes.io/docs/concepts/#kubernetes-control-plane) nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles. - -#### Worker Nodes - -[Worker nodes](https://kubernetes.io/docs/concepts/architecture/nodes/) run: - -- _Kubelets_: An agent that monitors the state of the node, ensuring your containers are healthy. -- _Workloads_: The containers and pods that hold your apps, as well as other types of deployments. - -Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your workloads. - After you provision a cluster in Rancher, you can begin using powerful Kubernetes features to deploy and scale your containerized applications in development, testing, or production environments. -## Interacting with Clusters +This page covers the following topics: -- **Rancher UI** +- [Switching between clusters](#switching-between-clusters) +- [Managing clusters in Rancher](#managing-clusters-in-rancher) +- [Configuring tools](#configuring-tools) - Rancher provides an intuitive user interface for interacting with your clusters. All options available in the UI use the Rancher API. Therefore any action possible in the UI is also possible in the Rancher CLI or Rancher API. - -- **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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell). - - - **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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-and-a-kubeconfig-file). - -- **Rancher CLI** - - You can control your clusters by downloading Rancher's own command-line interface, [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/). This CLI tool can interact directly with different clusters and projects or pass them `kubectl` commands. - -- **Rancher API** - - Finally, you can interact with your clusters over the Rancher API. Before you use the API, you must obtain an [API key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/). To view the different resource fields and actions for an API object, open the API UI, which can be accessed by clicking on **View in API** for any Rancher UI object. +> This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{}}/rancher/v2.x/en/overview/concepts) page. ## Switching between Clusters @@ -76,9 +25,9 @@ After clusters have been [provisioned into Rancher]({{< baseurl >}}/rancher/v2.x | Action | [Rancher launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) | [Hosted Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) | [Imported Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters) | | --- | --- | ---| ---| -| [Using kubeconfig file to access a Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/kubeconfig/) | * | * | * | -| [Using kubectl to Access a Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/kubectl/) | * | * | * | -| [Adding Cluster Members]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cluster-members/) | * | * | * | +| [Using kubeconfig file to access a Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cluster-access/kubeconfig/) | * | * | * | +| [Using kubectl to Access a Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/) | * | * | * | +| [Adding Cluster Members]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cluster-access/cluster-members/) | * | * | * | | [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) | * | * | * | | [Managing Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/nodes) | * | * | * | | [Managing Persistent Volumes and Storage Classes]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/) | * | * | * | diff --git a/content/rancher/v2.x/en/cluster-admin/cluster-access/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-access/_index.md new file mode 100644 index 00000000000..973ba43dcce --- /dev/null +++ b/content/rancher/v2.x/en/cluster-admin/cluster-access/_index.md @@ -0,0 +1,34 @@ +--- +title: Cluster Access +weight: 1 +--- + +There are many ways you can interact with Kubernetes clusters that are managed by Rancher: + +- **Rancher UI** + + Rancher provides an intuitive user interface for interacting with your clusters. All options available in the UI use the Rancher API. Therefore any action possible in the UI is also possible in the Rancher CLI or Rancher API. + +- **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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell). + + - **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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubectl/#accessing-clusters-with-kubectl-and-a-kubeconfig-file). + +- **Rancher CLI** + + You can control your clusters by downloading Rancher's own command-line interface, [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/). This CLI tool can interact directly with different clusters and projects or pass them `kubectl` commands. + +- **Rancher API** + + Finally, you can interact with your clusters over the Rancher API. Before you use the API, you must obtain an [API key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/). To view the different resource fields and actions for an API object, open the API UI, which can be accessed by clicking on **View in API** for any Rancher UI object. \ No newline at end of file diff --git a/content/rancher/v2.x/en/cluster-admin/cluster-access/cluster-members/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-access/cluster-members/_index.md new file mode 100644 index 00000000000..171df0822c1 --- /dev/null +++ b/content/rancher/v2.x/en/cluster-admin/cluster-access/cluster-members/_index.md @@ -0,0 +1,58 @@ +--- +title: Adding Users to Clusters +weight: 2020 +aliases: + - /rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/ + - /rancher/v2.x/en/cluster-provisioning/cluster-members/ + - /rancher/v2.x/en/k8s-in-rancher/cluster-members/ + - /rancher/v2.x/en/cluster-admin/cluster-members +--- + +If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. + +>**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/) instead. + +There are two contexts where you can add cluster members: + +- Adding Members to a New Cluster + + You can add members to a cluster as you create it (recommended if possible). + +- [Adding Members to an Existing Cluster](#editing-cluster-membership) + + You can always add members to a cluster after a cluster is provisioned. + +## Editing Cluster Membership + +Cluster administrators can edit the membership for a cluster, controlling which Rancher users can access the cluster and what features they can use. + +1. From the **Global** view, open the cluster that you want to add members to. + +2. From the main menu, select **Members**. Then click **Add Member**. + +3. Search for the user or group that you want to add to the cluster. + + If external authentication is configured: + + - Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) source as you type. + + >**Using AD but can't find your users?** + >There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ad/). + + - A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of. + + >**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). + +4. Assign the user or group **Cluster** roles. + + [What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/) + + >**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment. + > + > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/). + > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles). + +**Result:** The chosen users are added to the cluster. + +- To revoke cluster membership, select the user and click **Delete**. This action deletes membership, not the user. +- To modify a user's roles in the cluster, delete them from the cluster, and then re-add them with modified roles. diff --git a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubeconfig/_index.md similarity index 99% rename from content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md rename to content/rancher/v2.x/en/cluster-admin/cluster-access/kubeconfig/_index.md index ecda9446aca..270a5b45326 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubeconfig/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubeconfig/_index.md @@ -5,6 +5,7 @@ weight: 2010 aliases: - /rancher/v2.x/en/concepts/clusters/kubeconfig-files/ - /rancher/v2.x/en/k8s-in-rancher/kubeconfig/ + - /rancher/2.x/en/cluster-admin/kubeconfig --- A _kubeconfig file_ is a file used to configure access to Kubernetes when used in conjunction with the kubectl commandline tool (or other clients). diff --git a/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md similarity index 98% rename from content/rancher/v2.x/en/cluster-admin/kubectl/_index.md rename to content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md index 190f080af7b..b8deacf998d 100644 --- a/content/rancher/v2.x/en/cluster-admin/kubectl/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md @@ -5,6 +5,7 @@ weight: 2015 aliases: - /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/ - /rancher/v2.x/en/k8s-in-rancher/kubectl/ + - /rancher/v2.x/en/cluster-admin/kubectl --- You can access and manage your Kubernetes clusters using kubectl in two ways: diff --git a/content/rancher/v2.x/en/cluster-admin/cluster-members/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-members/_index.md deleted file mode 100644 index 8f8a197ad77..00000000000 --- a/content/rancher/v2.x/en/cluster-admin/cluster-members/_index.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Adding Users to Clusters -weight: 2020 -aliases: - - /rancher/v2.x/en/tasks/clusters/adding-managing-cluster-members/ - - /rancher/v2.x/en/cluster-provisioning/cluster-members/ - - /rancher/v2.x/en/k8s-in-rancher/cluster-members/ ---- - -If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership. - ->**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members/) instead. - -There are two contexts where you can add cluster members: - -- Adding Members to a New Cluster - - You can add members to a cluster as you create it (recommended if possible). - -- [Adding Members to an Existing Cluster]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) - - You can always add members to a cluster after a cluster is provisioned. diff --git a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md index 9f194c51414..3ff74c42103 100644 --- a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md @@ -1,5 +1,5 @@ --- -title: Editing Clusters +title: Cluster Configuration weight: 2025 aliases: - /rancher/v2.x/en/k8s-in-rancher/editing-clusters/ @@ -22,96 +22,20 @@ The following table lists the options and settings available for each cluster ty ## Editing Cluster Membership -Cluster administrators can edit the membership for a cluster, controlling which Rancher users can access the cluster and what features they can use. - -1. From the **Global** view, open the cluster that you want to add members to. - -2. From the main menu, select **Members**. Then click **Add Member**. - -3. Search for the user or group that you want to add to the cluster. - - If external authentication is configured: - - - Rancher returns users from your [external authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) source as you type. - - >**Using AD but can't find your users?** - >There may be an issue with your search attribute configuration. See [Configuring Active Directory Authentication: Step 5]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ad/). - - - A drop-down allows you to add groups instead of individual users. The drop-down only lists groups that you, the logged in user, are part of. - - >**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). - -4. Assign the user or group **Cluster** roles. - - [What are Cluster Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/) - - >**Tip:** For Custom Roles, you can modify the list of individual roles available for assignment. - > - > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/). - > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles). - -**Result:** The chosen users are added to the cluster. - -- To revoke cluster membership, select the user and click **Delete**. This action deletes membership, not the user. -- To modify a user's roles in the cluster, delete them from the cluster, and then re-add them with modified roles. +Cluster administrators can [edit the membership for a cluster,]({{}}/rancher/v2.x/en/cluster-admin/cluster-access/cluster-members) controlling which Rancher users can access the cluster and what features they can use. ## Cluster Options When editing clusters, clusters that are [launched using RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) feature more options than clusters that are imported or hosted by a Kubernetes provider. The headings that follow document options available only for RKE clusters. -### Upgrading Kubernetes - -Following an upgrade to the latest version of Rancher, you can update your existing clusters to use the latest supported version of Kubernetes. - -Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For example, Rancher v2.3.0 is was tested with Kubernetes v1.15.4, v1.14.7, and v1.13.11. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.3.0/) - -As of Rancher v2.3.0, the Kubernetes metadata feature was added, which allows Rancher to ship Kubernetes patch versions without upgrading Rancher. For details, refer to the [section on Kubernetes metadata.]({{}}/rancher/v2.x/en/admin-settings/k8s-metadata) - ->**Recommended:** Before upgrading Kubernetes, [backup your cluster]({{< baseurl >}}/rancher/v2.x/en/backups). - -1. From the **Global** view, find the cluster for which you want to upgrade Kubernetes. Select **Vertical Ellipsis (...) > Edit**. - -1. Expand **Cluster Options**. - -1. From the **Kubernetes Version** drop-down, choose the version of Kubernetes that you want to use for the cluster. - -1. Click **Save**. - -**Result:** Kubernetes begins upgrading for the cluster. During the upgrade, your cluster is unavailable. - ### Upgrading ingress-nginx For RKE v0.1.8+, the `ingress-nginx` YAML does not contain an `updateStrategy`. Therefore, the `updateStrategy` is the default value that is set by the Kubernetes API version. For example, the default `updateStrategy` for Kubernetes v1.13 was `onDelete`. When RKE v0.3.2 began supporting Kubernetes v1.16, the `updateStrategy` for `ingress-nginx` became `RollingUpdate` by default for RKE clusters with Kubernetes 1.16. This policy allows the daemonset to restart the pods. For RKE prior to v0.1.8, the `updateStrategy` directive in the `ingress-nginx` YAML was set to `OnDelete` because RKE did not yet support updating ingress and addons. In that case, you will need to delete these pods to get the correct version for your deployment. -### Adding a Pod Security Policy -When your cluster is running pods with security-sensitive configurations, assign it a [pod security policy]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/), which is a set of rules that monitors the conditions and settings in your pods. If a pod doesn't meet the rules specified in your policy, the policy stops it from running. - -You can assign a pod security policy when you provision a cluster. However, if you need to relax or restrict security for your pods later, you can update the policy while editing your cluster. - -1. From the **Global** view, find the cluster to which you want to apply a pod security policy. Select **Vertical Ellipsis (...) > Edit**. - -2. Expand **Cluster Options**. - -3. From **Pod Security Policy Support**, select **Enabled**. - - >**Note:** This option is only available for clusters [provisioned by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). - -4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster. - - Rancher ships with [policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) of `restricted` and `unrestricted`, although you can [create custom policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) as well. - -5. Click **Save**. - -**Result:** The pod security policy is applied to the cluster and any projects within the cluster. - ->**Note:** Workloads already running before assignment of a pod security policy are grandfathered in. Even if they don't meet your pod security policy, workloads running before assignment of the policy continue to run. -> ->To check if a running workload passes your pod security policy, clone or upgrade it. - -### Editing Other Cluster Options +# Editing Other Cluster Options In [clusters launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), you can edit any of the remaining options that follow. @@ -123,7 +47,7 @@ In [clusters launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioni Option | Description | ---------|----------| - Kubernetes Version | The version of Kubernetes installed on each cluster node. For more detail, see [Upgrading Kubernetes](#upgrading-kubernetes). | + Kubernetes Version | The version of Kubernetes installed on each cluster node. For more detail, see [Upgrading Kubernetes]({{}}/rancher/v2.x/en/cluster-admin/upgrading-kubernetes). | Network Provider | The [container networking interface]({{< baseurl >}}/rancher/v2.x/en/faq/networking/#cni-providers) that powers networking for your cluster.

**Note:** You can only choose this option while provisioning your cluster. It cannot be edited later. | Project Network Isolation | As of Rancher v2.0.7, if you're using the Canal network provider, you can choose whether to enable or disable inter-project communication. | Nginx Ingress | If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use Nginx ingress within the cluster. | @@ -134,7 +58,8 @@ Option | Description | Default Pod Security Policy | If you enable **Pod Security Policy Support**, use this drop-down to choose the pod security policy that's applied to the cluster. | Cloud Provider | If you're using a cloud provider to host cluster nodes launched by RKE, enable [this option]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) so that you can use the cloud provider's native features. If you want to store persistent data for your cloud-hosted cluster, this option is required. |
-#### Editing Cluster as YAML + +# Editing Cluster as YAML >**Note:** In Rancher v2.0.5 and v2.0.6, the names of services in the Config File (YAML) should contain underscores only: `kube_api` and `kube_controller`. @@ -146,19 +71,3 @@ Instead of using the Rancher UI to choose Kubernetes options for the cluster, ad ![image]({{< baseurl >}}/img/rancher/cluster-options-yaml.png) For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/latest/en/example-yamls/). - -## Managing Node Pools - -In clusters [launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), you can: - -- Add new [pools of nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to your cluster. The nodes added to the pool are provisioned according to the [node template]({{< baseurl >}}/rancher/v2.x/en/user-settings/node-templates/) that you use. - - - Click **+** and follow the directions on screen to create a new template. - - - You can also reuse existing templates by selecting one from the **Template** drop-down. - -- Redistribute Kubernetes roles amongst your node pools by making different checkbox selections - -- Scale the number of nodes in a pool up or down (although, if you simply want to maintain your node scale, we recommend using the cluster's [Nodes tab]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/nodes/#nodes-provisioned-by-node-pool) instead.) - ->**Note:** The Node Pools section is not available for imported clusters or clusters hosted by a Kubernetes provider. diff --git a/content/rancher/v2.x/en/cluster-admin/nodes/_index.md b/content/rancher/v2.x/en/cluster-admin/nodes/_index.md index 156b23aa917..31c3e595bae 100644 --- a/content/rancher/v2.x/en/cluster-admin/nodes/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/nodes/_index.md @@ -1,5 +1,5 @@ --- -title: Nodes +title: Nodes and Node Pools weight: 2030 aliases: - /rancher/v2.x/en/k8s-in-rancher/nodes/ @@ -7,11 +7,23 @@ aliases: After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab. Depending on the [option used]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher) to provision the cluster, there are different node options available. +This page covers the following topics: + +- [Node options for each type of cluster](#node-options-for-each-type-of-cluster) +- [Cordoning and draining nodes](#cordoning-and-draining-nodes) +- [Editing a node](#editing-a-node) +- [Viewing a node API](#viewing-a-node-api) +- [Deleting a node](#deleting-a-node) +- [Scaling nodes](#scaling-nodes) +- [SSH into a node hosted by an infrastructure provider](#ssh-into-a-node-hosted-by-an-infrastructure-provider) +- [Managing node pools](#managing-node-pools) To manage individual nodes, browse to the cluster that you want to manage and then select **Nodes** from the main menu. You can open the options menu for a node by clicking its **Ellipsis** icon (**...**). >**Note:** If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters). +# Node Options for Each Type of Cluster + The following table lists which node options are available for each [type of cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-options) in Rancher. Click the links in the **Option** column for more detailed information about each feature. | Option | [Nodes Hosted by an Infrastructure Provider][1] | [Custom Node][2] | [Hosted Cluster][3] | [Imported Nodes][4] | Description | @@ -29,14 +41,26 @@ The following table lists which node options are available for each [type of clu [3]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ [4]: {{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/ -## Cordoning a Node +### Notes for Node Pool Nodes + +Clusters provisioned using [one of the node pool options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) automatically maintain the node scale that's set during the initial cluster provisioning. This scale determines the number of active nodes that Rancher maintains for the cluster. + +### Notes for Nodes Provisioned by Hosted Kubernetes Providers + +Options for managing nodes [hosted by a Kubernetes provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) are somewhat limited in Rancher. Rather than using the Rancher UI to make edits such as scaling the number of nodes up or down, edit the cluster directly. + +### Notes for Imported Nodes + +Although you can deploy workloads to an [imported cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher. + +# Cordoning and Draining Nodes _Cordoning_ a node marks it as unschedulable. This feature is useful for performing short tasks on the node during small maintenance windows, like reboots, upgrades, or decommissions. When you're done, power back on and make the node schedulable again by uncordoning it. -## Draining a Node - _Draining_ is the process of first cordoning the node, and then evicting all its pods. This feature is useful for performing node maintenance (like kernel upgrades or hardware maintenance). It prevents new pods from deploying to the node while redistributing existing pods so that users don't experience service interruption. +When nodes are drained, pods are handled with the following rules: + - For pods with a replica set, the pod is replaced by a new pod that will be scheduled to a new node. Additionally, if the pod is part of a service, then clients will automatically be redirected to the new pod. - For pods with no replica set, you need to bring up a new copy of the pod, and assuming it is not part of a service, redirect clients to it. @@ -99,7 +123,7 @@ Once drain successfully completes, the node will be in a state of `drained`. You >**Want to know more about cordon and drain?** See the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node). -## Editing a Node +# Editing a Node Editing a node lets you: @@ -109,23 +133,23 @@ Editing a node lets you: * Add/Remove [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) -## Viewing a Node API +# Viewing a Node API Select this option to view the node's [API endpoints]({{< baseurl >}}/rancher/v2.x/en/api/). -## Deleting a Node +# Deleting a Node Use **Delete** to remove defective nodes from the cloud provider. When you the delete a defective node, Rancher automatically replaces it with an identically provisioned node. >**Tip:** If your cluster is hosted by an infrastructure provider, and you want to scale your cluster down instead of deleting a defective node, [scale down](#scaling-nodes) rather than delete. -## Scaling Nodes +# Scaling Nodes For nodes hosted by an infrastructure provider, you can scale the number of nodes in each node pool by using the scale controls. This option isn't available for other cluster types. -## SSH into a Node Hosted by an Infrastructure Provider +# SSH into a Node Hosted by an Infrastructure Provider For [nodes hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/), you have the option of downloading its SSH key so that you can connect to it remotely from your desktop. @@ -145,17 +169,19 @@ For [nodes hosted by an infrastructure provider]({{< baseurl >}}/rancher/v2.x/en ``` ssh -i id_rsa root@ ``` + +# Managing Node Pools -## Notes for Node Pool Nodes +> **Prerequisite:** The options below are available only for clusters that are [launched using RKE.]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) The node pool features are not available for imported clusters or clusters hosted by a Kubernetes provider. -Clusters provisioned using [one of the node pool options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) automatically maintain the node scale that's set during the initial cluster provisioning. This scale determines the number of active nodes that Rancher maintains for the cluster. +In clusters [launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), you can: +- Add new [pools of nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to your cluster. The nodes added to the pool are provisioned according to the [node template]({{< baseurl >}}/rancher/v2.x/en/user-settings/node-templates/) that you use. -## Notes for Nodes Provisioned by Hosted Kubernetes Providers + - Click **+** and follow the directions on screen to create a new template. -Options for managing nodes [hosted by a Kubernetes provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) are somewhat limited in Rancher. Rather than using the Rancher UI to make edits such as scaling the number of nodes up or down, edit the cluster directly. + - You can also reuse existing templates by selecting one from the **Template** drop-down. +- Redistribute Kubernetes roles amongst your node pools by making different checkbox selections -## Notes for Imported Nodes - -Although you can deploy workloads to an [imported cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher. +- Scale the number of nodes in a pool up or down (although, if you simply want to maintain your node scale, we recommend using the cluster's [Nodes tab]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/nodes/#nodes-provisioned-by-node-pool) instead.) diff --git a/content/rancher/v2.x/en/cluster-admin/pod-security-policy/_index.md b/content/rancher/v2.x/en/cluster-admin/pod-security-policy/_index.md new file mode 100644 index 00000000000..11e415f5b3a --- /dev/null +++ b/content/rancher/v2.x/en/cluster-admin/pod-security-policy/_index.md @@ -0,0 +1,30 @@ +--- +title: Adding a Pod Security Policy +weight: 80 +--- + +> **Prerequisite:** The options below are available only for clusters that are [launched using RKE.]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) + +When your cluster is running pods with security-sensitive configurations, assign it a [pod security policy]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/), which is a set of rules that monitors the conditions and settings in your pods. If a pod doesn't meet the rules specified in your policy, the policy stops it from running. + +You can assign a pod security policy when you provision a cluster. However, if you need to relax or restrict security for your pods later, you can update the policy while editing your cluster. + +1. From the **Global** view, find the cluster to which you want to apply a pod security policy. Select **Vertical Ellipsis (...) > Edit**. + +2. Expand **Cluster Options**. + +3. From **Pod Security Policy Support**, select **Enabled**. + + >**Note:** This option is only available for clusters [provisioned by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). + +4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster. + + Rancher ships with [policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) of `restricted` and `unrestricted`, although you can [create custom policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/#default-pod-security-policies) as well. + +5. Click **Save**. + +**Result:** The pod security policy is applied to the cluster and any projects within the cluster. + +>**Note:** Workloads already running before assignment of a pod security policy are grandfathered in. Even if they don't meet your pod security policy, workloads running before assignment of the policy continue to run. +> +>To check if a running workload passes your pod security policy, clone or upgrade it. \ No newline at end of file diff --git a/content/rancher/v2.x/en/cluster-admin/tools/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/_index.md index a03c09c0c1a..04f0c854429 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/_index.md @@ -1,5 +1,5 @@ --- -title: Configuring Tools +title: Tools for Logging, Monitoring, and Visibility weight: 2033 aliases: - /rancher/v2.x/en/tools/ diff --git a/content/rancher/v2.x/en/cluster-admin/upgrading-kubernetes/_index.md b/content/rancher/v2.x/en/cluster-admin/upgrading-kubernetes/_index.md new file mode 100644 index 00000000000..2d7f62ea392 --- /dev/null +++ b/content/rancher/v2.x/en/cluster-admin/upgrading-kubernetes/_index.md @@ -0,0 +1,24 @@ +--- +title: Upgrading Kubernetes +weight: 70 +--- + +> **Prerequisite:** The options below are available only for clusters that are [launched using RKE.]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) + +Following an upgrade to the latest version of Rancher, you can update your existing clusters to use the latest supported version of Kubernetes. + +Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For example, Rancher v2.3.0 is was tested with Kubernetes v1.15.4, v1.14.7, and v1.13.11. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.3.0/) + +As of Rancher v2.3.0, the Kubernetes metadata feature was added, which allows Rancher to ship Kubernetes patch versions without upgrading Rancher. For details, refer to the [section on Kubernetes metadata.]({{}}/rancher/v2.x/en/admin-settings/k8s-metadata) + +>**Recommended:** Before upgrading Kubernetes, [backup your cluster]({{< baseurl >}}/rancher/v2.x/en/backups). + +1. From the **Global** view, find the cluster for which you want to upgrade Kubernetes. Select **Vertical Ellipsis (...) > Edit**. + +1. Expand **Cluster Options**. + +1. From the **Kubernetes Version** drop-down, choose the version of Kubernetes that you want to use for the cluster. + +1. Click **Save**. + +**Result:** Kubernetes begins upgrading for the cluster. During the upgrade, your cluster is unavailable. \ No newline at end of file diff --git a/content/rancher/v2.x/en/overview/_index.md b/content/rancher/v2.x/en/overview/_index.md index f8709e5483e..0656ec3e7e2 100644 --- a/content/rancher/v2.x/en/overview/_index.md +++ b/content/rancher/v2.x/en/overview/_index.md @@ -35,7 +35,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and ### Working with Kubernetes -- **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{}}/rancher/v2.x/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{}}/rancher/v2.x/en/cluster-admin/editing-clusters/#upgrading-kubernetes) +- **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{}}/rancher/v2.x/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{}}/rancher/v2.x/en/cluster-admin/upgrading-kubernetes) - **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{}}/rancher/v2.x/en/catalog/) that make it easy to repeatedly deploy applications. - **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.x/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.x/en/k8s-in-rancher/) - **Pipelines:** Setting up a [pipeline]({{}}/rancher/v2.x/en/project-admin/tools/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects. diff --git a/content/rancher/v2.x/en/overview/architecture/_index.md b/content/rancher/v2.x/en/overview/architecture/_index.md index c3c49b99cbc..f87cc1e1f63 100644 --- a/content/rancher/v2.x/en/overview/architecture/_index.md +++ b/content/rancher/v2.x/en/overview/architecture/_index.md @@ -71,7 +71,7 @@ The authentication proxy forwards all Kubernetes API calls to downstream cluster Rancher communicates with Kubernetes clusters using a [service account,](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) which provides an identity for processes that run in a pod. -By default, Rancher generates a [kubeconfig file]({{}}/rancher/v2.x/en/cluster-admin/kubeconfig/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster. +By default, Rancher generates a [kubeconfig file]({{}}/rancher/v2.x/en/cluster-admin/cluster-access/kubeconfig/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster. ### 2. Cluster Controllers and Cluster Agents @@ -118,7 +118,7 @@ Like the authorized cluster endpoint, the `kube-api-auth` authentication service 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 [kubeconfig file]({{}}/rancher/v2.x/en/cluster-admin/kubeconfig) documentation. +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 [kubeconfig file]({{}}/rancher/v2.x/en/cluster-admin/cluster-access/kubeconfig) documentation. # Important Files @@ -128,7 +128,7 @@ The files mentioned below are needed to maintain, troubleshoot and upgrade your - `kube_config_rancher-cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down. - `rancher-cluster.rkestate`: The Kubernetes cluster state file. This file contains credentials for full access to the cluster. Note: This state file is only created when using RKE v0.2.0 or higher. -For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file]({{}}/rancher/v2.x/en/cluster-admin/kubeconfig/) documentation. +For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file]({{}}/rancher/v2.x/en/cluster-admin/cluster-access/kubeconfig/) documentation. # Tools for Provisioning Kubernetes Clusters From 8a187d082bce7b678d3876ffa0584ea8ea6ab3ad Mon Sep 17 00:00:00 2001 From: catherineluse Date: Mon, 30 Dec 2019 22:30:19 -0700 Subject: [PATCH 63/82] Update section on updating ingress-nginx --- .../v2.x/en/cluster-admin/editing-clusters/_index.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md index 3ff74c42103..d7eb5fa7dd5 100644 --- a/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/editing-clusters/_index.md @@ -28,12 +28,11 @@ Cluster administrators can [edit the membership for a cluster,]({{}}/ra When editing clusters, clusters that are [launched using RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) feature more options than clusters that are imported or hosted by a Kubernetes provider. The headings that follow document options available only for RKE clusters. -### Upgrading ingress-nginx +### Updating ingress-nginx -For RKE v0.1.8+, the `ingress-nginx` YAML does not contain an `updateStrategy`. Therefore, the `updateStrategy` is the default value that is set by the Kubernetes API version. For example, the default `updateStrategy` for Kubernetes v1.13 was `onDelete`. When RKE v0.3.2 began supporting Kubernetes v1.16, the `updateStrategy` for `ingress-nginx` became `RollingUpdate` by default for RKE clusters with Kubernetes 1.16. This policy allows the daemonset to restart the pods. - -For RKE prior to v0.1.8, the `updateStrategy` directive in the `ingress-nginx` YAML was set to `OnDelete` because RKE did not yet support updating ingress and addons. In that case, you will need to delete these pods to get the correct version for your deployment. +Clusters that were created before Kubernetes 1.16 will have an `ingress-nginx` `updateStrategy` of `OnDelete`. Clusters that were created with Kubernetes 1.16 or newer will have `RollingUpdate`. +If the `updateStrategy` of `ingress-nginx` is `OnDelete`, you will need to delete these pods to get the correct version for your deployment. # Editing Other Cluster Options From 176da138f38d295b009d289495dc7362ab23f876 Mon Sep 17 00:00:00 2001 From: Denise Date: Tue, 31 Dec 2019 09:01:09 -0800 Subject: [PATCH 64/82] Revert "Updated cert-manager installation/upgrade docs" This reverts commit 271a04de85eba9f8d6e8eedf6a1b0ba258f2ca07. --- .../en/installation/ha/helm-rancher/_index.md | 23 ++-- .../options/chart-options/_index.md | 2 - .../options/upgrading-cert-manager/_index.md | 107 +++++------------- .../air-gap/install-rancher/_index.md | 20 ++-- .../v2.x/en/upgrades/upgrades/ha/_index.md | 2 - 5 files changed, 53 insertions(+), 101 deletions(-) diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md index c4d34c8a990..d6f3c3ede5b 100644 --- a/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md +++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md @@ -63,20 +63,20 @@ Rancher relies on [cert-manager](https://github.com/jetstack/cert-manager) to is > **Important:** > Due to an issue with Helm v2.12.0 and cert-manager, please use Helm v2.12.1 or higher. -> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). +> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.9.1, please see our [upgrade documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). -These instructions are adapted from the [official cert-manager documentation](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm). +These instructions are adapted from the [official cert-manager documentation](https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html#installing-with-helm). ``` # Install the CustomResourceDefinition resources separately -kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml - -> **Important:** -> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. +kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml # Create the namespace for cert-manager kubectl create namespace cert-manager +# Label the cert-manager namespace to disable resource validation +kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true + # Add the Jetstack Helm repository helm repo add jetstack https://charts.jetstack.io @@ -87,7 +87,7 @@ helm repo update helm install \ cert-manager jetstack/cert-manager \ --namespace cert-manager \ - --version v0.12.0 + --version v0.9.1 ``` Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods: @@ -95,12 +95,13 @@ Once you’ve installed cert-manager, you can verify it is deployed correctly by ``` kubectl get pods --namespace cert-manager -NAME READY STATUS RESTARTS AGE -cert-manager-5c6866597-zw7kh 1/1 Running 0 2m -cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m -cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +cert-manager-7cbdc48784-rpgnt 1/1 Running 0 3m +cert-manager-webhook-5b5dd6999-kst4x 1/1 Running 0 3m +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 the [troubleshooting](https://docs.cert-manager.io/en/latest/getting-started/troubleshooting.html) guide. {{% /accordion %}} ### Install Rancher with Helm and Your Chosen Certificate Option diff --git a/content/rancher/v2.x/en/installation/options/chart-options/_index.md b/content/rancher/v2.x/en/installation/options/chart-options/_index.md index de2cfcde766..db92df57800 100644 --- a/content/rancher/v2.x/en/installation/options/chart-options/_index.md +++ b/content/rancher/v2.x/en/installation/options/chart-options/_index.md @@ -32,8 +32,6 @@ aliases: | `auditLog.maxSize` | 100 | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`) | | `busyboxImage` | "busybox" | `string` - Image location for busybox image used to collect audit logs _Note: Available as of v2.2.0_ | | `debug` | false | `bool` - set debug flag on rancher server | -| `certmanager.version` | "" | `string` - set cert-manager compatibility - | | `extraEnv` | [] | `list` - set additional environment variables for Rancher _Note: Available as of v2.2.0_ | | `imagePullSecrets` | [] | `list` - list of names of Secret resource containing private registry credentials | | `ingress.extraAnnotations` | {} | `map` - additional annotations to customize the ingress | diff --git a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md index a28d310cfda..69ad051a38e 100644 --- a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md +++ b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md @@ -6,8 +6,7 @@ weight: 2040 Rancher uses cert-manager to automatically generate and renew TLS certificates for HA deployments of Rancher. As of Fall 2019, two 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://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/). This change has no exact deadline. -2. [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://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. To address these changes, this guide will do two things: @@ -21,36 +20,24 @@ To address these changes, this guide will do two things: In order to upgrade cert-manager, follow these instructions: {{% accordion id="normal" label="Upgrading cert-manager with Internet access" %}} -1. [Back up existing resources](https://cert-manager.io/docs/tutorials/backup/) as a precaution +1. Back up existing resources as a precaution ```plain - kubectl get -o yaml --all-namespaces \ - issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml + kubectl get -o yaml --all-namespaces issuer,clusterissuer,certificates > cert-manager-backup.yaml ``` -> **Important:** -> If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. [Additional annotation changes](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes) - -1. [Uninstall existing deployment](https://cert-manager.io/docs/installation/uninstall/kubernetes/#uninstalling-with-helm) +1. Delete the existing deployment ```plain helm delete --purge cert-manager ``` - Delete the CustomResourceDefinition using the link to the version vX.Y you installed - ```plain - kubectl delete -f https://raw.githubusercontent.com/jetstack/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml - ``` - 1. Install the CustomResourceDefinition resources separately ```plain - kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml + kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml ``` -> **Important:** -> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. - -1. Create the namespace for cert-manager if needed +1. Label the kube-system namespace to disable resource validation ```plain - kubectl create namespace cert-manager + kubectl label namespace kube-system certmanager.k8s.io/disable-validation=true ``` 1. Add the Jetstack Helm repository @@ -65,17 +52,8 @@ In order to upgrade cert-manager, follow these instructions: 1. Install the new version of cert-manager ```plain - helm install \ - cert-manager jetstack/cert-manager \ - --namespace cert-manager \ - --version v0.12.0 + helm install --version 0.9.1 --name cert-manager --namespace kube-system jetstack/cert-manager ``` - -1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources) - ```plain - kubectl apply -f cert-manager-backup.yaml - ``` - {{% /accordion %}} {{% accordion id="airgap" label="Upgrading cert-manager in an airgapped environment" %}} @@ -95,24 +73,23 @@ Before you can perform the upgrade, you must prepare your air gapped environment 1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://hub.helm.sh/charts/jetstack/cert-manager). ```plain - helm fetch jetstack/cert-manager --version v0.12.0 + helm fetch jetstack/cert-manager --version v0.9.1 ``` 1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files. ```plain - helm template ./cert-manager-v0.12.0.tgz --output-dir . \ - --name cert-manager --namespace cert-manager \ + helm template ./cert-manager-v0.9.1.tgz --output-dir . \ + --name cert-manager --namespace kube-system \ --set image.repository=/quay.io/jetstack/cert-manager-controller --set webhook.image.repository=/quay.io/jetstack/cert-manager-webhook --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector ``` -1. Download the required CRD file for cert-manager (old and new) +1. Download the required CRD file for cert-manager ```plain - curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml - curl -L -o cert-manager/cert-manager-crd-old.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-X.Y/deploy/manifests/00-crds.yaml + curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml ``` ### Install cert-manager @@ -120,24 +97,13 @@ Before you can perform the upgrade, you must prepare your air gapped environment 1. Back up existing resources as a precaution ```plain - kubectl get -o yaml --all-namespaces \ - issuer,clusterissuer,certificates,certificaterequests > cert-manager-backup.yaml + kubectl get -o yaml --all-namespaces issuer,clusterissuer,certificates > cert-manager-backup.yaml ``` -> **Important:** -> If you are upgrading from a version older than 0.11.0, Update the apiVersion on all your backed up resources from `certmanager.k8s.io/v1alpha1` to `cert-manager.io/v1alpha2`. [Additional annotation changes](https://cert-manager.io/docs/installation/upgrading/upgrading-0.10-0.11/#additional-annotation-changes) - 1. Delete the existing cert-manager installation ```plain - kubectl -n cert-manager \ - delete deployment,sa,clusterrole,clusterrolebinding \ - -l 'app=cert-manager' -l 'chart=cert-manager-v0.5.2' - ``` - - Delete the CustomResourceDefinition using the link to the version vX.Y you installed - ```plain - kubectl delete -f cert-manager/cert-manager-crd-old.yaml + kubectl -n kube-system delete deployment,sa,clusterrole,clusterrolebinding -l 'app=cert-manager' -l 'chart=cert-manager-v0.5.2' ``` 1. Install the CustomResourceDefinition resources separately @@ -146,53 +112,42 @@ Before you can perform the upgrade, you must prepare your air gapped environment kubectl apply -f cert-manager/cert-manager-crd.yaml ``` -> **Important:** -> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. - -1. Create the namespace for cert-manager +1. Label the kube-system namespace to disable resource validation ```plain - kubectl create namespace cert-manager + kubectl label namespace kube-system certmanager.k8s.io/disable-validation=true ``` 1. Install cert-manager ```plain - kubectl -n cert-manager apply -R -f ./cert-manager + kubectl -n kube-system apply -R -f ./cert-manager ``` - -1. [Restore back up resources](https://cert-manager.io/docs/tutorials/backup/#restoring-resources) - ```plain - kubectl apply -f cert-manager-backup.yaml - ``` - {{% /accordion %}} Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the kube-system namespace for running pods: ``` -kubectl get pods --namespace cert-manager +kubectl get pods --namespace kube-system -NAME READY STATUS RESTARTS AGE -cert-manager-5c6866597-zw7kh 1/1 Running 0 2m -cert-manager-cainjector-577f6d9fd7-tr77l 1/1 Running 0 2m -cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +cert-manager-7cbdc48784-rpgnt 1/1 Running 0 3m +cert-manager-webhook-5b5dd6999-kst4x 1/1 Running 0 3m +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. + +> **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) + ## Cert-Manager API change and data migration Cert-manager has deprecated the use of the `certificate.spec.acme.solvers` field and will drop support for it completely in an upcoming release. Per the cert-manager documentation, a new format for configuring ACME certificate resources was introduced in v0.8. Specifically, the challenge solver configuration field was moved. Both the old format and new are supported as of v0.9, but support for the old format will be dropped in an upcoming release of cert-manager. The cert-manager documentation strongly recommends that after upgrading you update your ACME Issuer and Certificate resources to the new format. -Details about the change and migration instructions can be found in the [cert-manager v0.7 to v0.8 upgrade instructions](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/). - -The v0.11 release marks the removal of the v1alpha1 API that was used in previous versions of cert-manager, as well as our API group changing to be cert-manager.io instead of certmanager.k8s.io. - -We have also removed support for the old configuration format that was deprecated in the v0.8 release. This means you must transition to using the new solvers style configuration format for your ACME issuers before upgrading to v0.11. For more information, see the [upgrading to v0.8 guide](https://cert-manager.io/docs/installation/upgrading/upgrading-0.7-0.8/). - -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/). - +Details about the change and migration instructions can be found in the [cert-manager v0.7 to v0.8 upgrade instructions](https://docs.cert-manager.io/en/latest/tasks/upgrading/upgrading-0.7-0.8.html). 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 ac08fb75fd5..c4cb3081474 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 @@ -71,7 +71,6 @@ When setting up the Rancher Helm template, there are several options in the Helm | Chart Option | Chart Value | Description | | ----------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `certmanager.version` | "" | Configure proper Rancher TLS issuer depending of running cert-manager version. | | `systemDefaultRegistry` | `` | 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_ | @@ -82,7 +81,7 @@ Based on the choice your made in [B. Choose your SSL Configuration](#b-optional- By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface. > **Note:** -> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.11.0, please see our [upgrade cert-manager documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). +> Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.9.1, please see our [upgrade cert-manager documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). 1. From a system connected to the internet, add the cert-manager repo to Helm. @@ -94,13 +93,13 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat 1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://hub.helm.sh/charts/jetstack/cert-manager). ```plain - helm fetch jetstack/cert-manager --version v0.12.0 + helm fetch jetstack/cert-manager --version v0.9.1 ``` 1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files. ```plain - helm template ./cert-manager-v0.12.0.tgz --output-dir . \ + helm template ./cert-manager-v0.9.1.tgz --output-dir . \ --name cert-manager --namespace cert-manager \ --set image.repository=/quay.io/jetstack/cert-manager-controller --set webhook.image.repository=/quay.io/jetstack/cert-manager-webhook @@ -110,7 +109,7 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat 1. Download the required CRD file for cert-manager ```plain - curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.12/deploy/manifests/00-crds.yaml + curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml ``` 1. Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools. @@ -121,14 +120,12 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat `` | The version number of the output tarball. `` | The DNS name you pointed at your load balancer. `` | The DNS name for your private registry. - `` | Cert-manager version running on k8s cluster. ```plain helm template ./rancher-.tgz --output-dir . \ --name rancher \ --namespace cattle-system \ --set hostname= \ - --set certmanager.version= \ --set rancherImage=/rancher/rancher \ --set systemDefaultRegistry= \ # Available as of v2.2.0, set a default private registry to be used in Rancher --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts @@ -185,15 +182,18 @@ If you are using self-signed certificates, install cert-manager: kubectl create namespace cert-manager ``` +1. Label the cert-manager namespace to disable resource validation. + + ```plain + kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true + ``` + 1. Create the cert-manager CustomResourceDefinitions (CRDs). ```plain kubectl apply -f cert-manager/cert-manager-crd.yaml ``` -> **Important:** -> If you are running Kubernetes v1.15 or below, you will need to add the `--validate=false flag to your kubectl apply command above else you will receive a validation error relating to the x-kubernetes-preserve-unknown-fields field in cert-manager’s CustomResourceDefinition resources. This is a benign error and occurs due to the way kubectl performs resource validation. - 1. Launch cert-manager. ```plain kubectl apply -R -f ./cert-manager diff --git a/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md b/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md index b3e15eefaad..793140b6b8d 100644 --- a/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md +++ b/content/rancher/v2.x/en/upgrades/upgrades/ha/_index.md @@ -112,7 +112,6 @@ This section describes how to upgrade normal (Internet-connected) or air gap ins `` | The version number of the output tarball. `` | The DNS name you pointed at your load balancer. `` | The DNS name for your private registry. - `` | Cert-manager version running on k8s cluster. {{% accordion id="self-signed" label="Option A-Default Self-Signed Certificate" %}} @@ -121,7 +120,6 @@ helm template ./rancher-.tgz --output-dir . \ --name rancher \ --namespace cattle-system \ --set hostname= \ - --set certmanager.version= \ --set rancherImage=/rancher/rancher \ --set systemDefaultRegistry= \ # Available as of v2.2.0, set a default private registry to be used in Rancher --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts From c2e0e9195289580f223d7ffd76d6208912fb1db8 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 31 Dec 2019 13:48:57 -0700 Subject: [PATCH 65/82] Make registry page more discoverable from secrets page --- .../v2.x/en/k8s-in-rancher/registries/_index.md | 4 +++- .../v2.x/en/k8s-in-rancher/secrets/_index.md | 16 +++++++++++----- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md index 36bbd21c1e8..b24f7e97cff 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/registries/_index.md @@ -16,6 +16,8 @@ Deployments use the Kubernetes registry secret to authenticate with a private Do Currently, deployments pull the private registry credentials automatically only if the workload is created in the Rancher UI and not when it is created via kubectl. +# Creating a Registry + >**Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use. 1. From the **Global** view, select the project containing the namespace(s) where you want to add a registry. @@ -40,7 +42,7 @@ Currently, deployments pull the private registry credentials automatically only - You can view the secret in the Rancher UI from the **Resources > Registries** view. - Any workload that you create in the Rancher UI will have the credentials to access the registry if the workload is within the registry's scope. -## Using a Private Registry +# Using a Private Registry You can deploy a workload with an image from a private registry through the Rancher UI, or with `kubectl`. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/secrets/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/secrets/_index.md index 3c648e07f92..b6f31611d9e 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/secrets/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/secrets/_index.md @@ -7,9 +7,13 @@ aliases: [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets) store sensitive data like passwords, tokens, or keys. They may contain one or more key value pairs. +> This page is about secrets in general. For details on setting up a private registry, refer to the section on [registries.]({{}}/rancher/v2.x/en/k8s-in-rancher/registries) + When configuring a workload, you'll be able to choose which secrets to include. Like config maps, secrets can be referenced by workloads as either an environment variable or a volume mount. ->**Note:** Any update to an active secrets won't automatically update the pods that are using it. Restart those pods to have them use the new secret. +Any update to an active secrets won't automatically update the pods that are using it. Restart those pods to have them use the new secret. + +# Creating Secrets When creating a secret, you can make it available for any deployment within a project, or you can limit it to a single namespace. @@ -25,15 +29,17 @@ When creating a secret, you can make it available for any deployment within a pr 5. From **Secret Values**, click **Add Secret Value** to add a key value pair. Add as many values as you need. - >**Tip:** You can add multiple key value pairs to the secret by copying and pasting. - > - > {{< img "/img/rancher/bulk-key-values.gif" "Bulk Key Value Pair Copy/Paste">}} + >**Tip:** You can add multiple key value pairs to the secret by copying and pasting. + > + > {{< img "/img/rancher/bulk-key-values.gif" "Bulk Key Value Pair Copy/Paste">}} 1. Click **Save**. **Result:** Your secret is added to the project or namespace, depending on the scope you chose. You can view the secret in the Rancher UI from the **Resources > Secrets** view. -## What's Next? +Any update to an active secrets won't automatically update the pods that are using it. Restart those pods to have them use the new secret. + +# What's Next? Now that you have a secret added to the project or namespace, you can add it to a workload that you deploy. From 791ca73dfbebefdb67a41db4e64f4e24e1f13abe Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 31 Dec 2019 14:04:53 -0700 Subject: [PATCH 66/82] Say that ntp is an important package to install --- content/rancher/v2.x/en/installation/requirements/_index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index 867c969151b..64c9043fca7 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -32,6 +32,8 @@ For details on which OS and Docker versions were tested with each Rancher versio All supported operating systems are 64-bit x86. +The `ntp` (Network Time Protocol) package should be installed. This prevents errors with certificate validation that can occur when the time is not synchronized between the client and server. + > **Note:** Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. This [how-to guide]({{}}/rancher/v2.x/en/installation/options/firewall) shows how to check the default firewall rules and how to open the ports with `firewalld` if necessary. If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/options/arm64-platform/) From 5aeed997060f8069f6d8ffc5c69c5f4992272dc4 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 31 Dec 2019 15:07:33 -0700 Subject: [PATCH 67/82] Rearrange/consolidate duplicated info in tools section --- .../v2.x/en/cluster-admin/tools/_index.md | 77 ++++--------------- .../en/cluster-admin/tools/alerts/_index.md | 35 +++++++-- .../en/cluster-admin/tools/logging/_index.md | 40 ++++++---- .../cluster-admin/tools/monitoring/_index.md | 37 ++++++--- 4 files changed, 100 insertions(+), 89 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/tools/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/_index.md index 04f0c854429..444f5f47a18 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/_index.md @@ -10,86 +10,41 @@ Rancher contains a variety of tools that aren't included in Kubernetes to assist -- [Notifiers](#notifiers) -- [Alerts](#alerts) +- [Notifiers and Alerts](#notifiers-and-alerts) - [Logging](#logging) - [Monitoring](#monitoring) +- [Istio](#istio) ## Notifiers and Alerts -Notifiers and alerts are two features that work together to inform you of events in the Rancher system. Notifiers are objects that you configure to leverage popular IT services, which send you notification of Rancher events. Alerts are rule sets that trigger when those notifications are sent. +Notifiers and alerts are two features that work together to inform you of events in the Rancher system. -Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address. - -When you create a cluster, some alert rules are predefined. For details, refer to the [documentation on default alerts.]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/default-alerts) - -### Notifiers - -Before you can receive alerts, you must configure one or more notifier in Rancher. - -_Notifiers_ are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Rancher integrates with a variety of popular IT services, including: - -- Slack: Send alert notifications to your Slack channels. -- 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. - -For more information, see [Notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/). - -### Alerts - -To keep your clusters and applications healthy and driving your organizational productivity forward, you need stay informed of events occurring in your clusters, both planned and unplanned. To help you stay informed of these events, Rancher allows you to configure alerts. - -_Alerts_ are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level. - -Some examples of alert events are: - -- A Kubernetes [master component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) entering an unhealthy state. -- A node or [workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/) error occurring. -- A scheduled deployment taking place as planned. -- A node's hardware resources becoming overstressed. - -When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions. - -Additionally, you can set an urgency level for each alert. This urgency appears in the notification you receive, helping you to prioritize your response actions. For example, if you have an alert configured to inform you of a routine deployment, no action is required. These alerts can be assigned a low priority level. However, if a deployment fails, it can critically impact your organization, and you need to react quickly. Assign these alerts a high priority level. - -You can configure alerts at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/). +[Notifiers]({{}}/rancher/v2.x/en/cluster-admin/tools/notifiers) are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Notifications can be sent with Slack, email, PagerDuty, WeChat, and webhooks. +[Alerts]({{}}/rancher/v2.x/en/cluster-admin/tools/alerts) are rules that trigger those notifications. Before you can receive alerts, you must configure one or more notifier in Rancher. The scope for alerts can be set at either the cluster or project level. ## Logging -Rancher can integrate with popular external services used for event streams, telemetry, or search. Rancher can integrate with the following services: +Logging is helpful because it allows you to: -- Elasticsearch -- splunk -- kafka -- syslog -- fluentd +- Capture and analyze the state of your cluster +- Look for trends in your environment +- Save your logs to a safe location outside of your cluster +- Stay informed of events like a container crashing, a pod eviction, or a node dying +- More easily debugg and troubleshoot problems -These services collect container log events, which are saved to the `/var/log/containers` directory on each of your nodes. The service collects both standard and error events. You can then log into your services to review the events collected, leveraging each service's unique features. +Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd. -When configuring Rancher to integrate with these services, you'll have to point Rancher toward the service's endpoint and provide authentication information. Additionally, you'll have the opportunity to enter key value pairs to filter the log events collected. The service will only collect events for containers marked with your configured key value pairs. - -### Logging Advantages - -Setting up a logging service to collect logs from your cluster or project is helpful several ways: - -- Logs errors and warnings in your Kubernetes infrastructure to a stream. The stream informs you of events like a container crashing, a pod eviction, or a node dying. -- Allows you to capture and analyze the state of your cluster and look for trends in your environment using the log stream. -- Helps you when troubleshooting or debugging. -- Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues. - -You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/logging/). +For details, refer to the [logging section.]({{}}/rancher/v2.x/en/cluster-admin/tools/logging) ## Monitoring _Available as of v2.2.0_ -Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is a stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster. +Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. For details, refer to the [monitoring section.]({{}}/rancher/v2.x/en/cluster-admin/tools/monitoring) -In other words, Prometheus let's you view metrics from your different Rancher and Kubernetes objects. Using timestamps, you can query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported. +## Istio -You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/). + [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. For details on how to enable Istio in Rancher, refer to the [Istio section.]({{}}/rancher/v2.x/en/cluster-admin/tools/istio) \ No newline at end of file diff --git a/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md index 85a15aff2ca..a5f83df2b65 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md @@ -3,15 +3,38 @@ title: Alerts weight: 2 --- -To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. To help you stay informed of these events, you can configure alerts. +To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions. -Alerts are sets of rules, chosen by you, to monitor for specific events. +Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address. + +Before you can receive alerts, you must configure one or more notifier in Rancher. When you create a cluster, some alert rules are predefined. You can receive these alerts if you configure a [notifier]({{}}/rancher/v2.x/en/cluster-admin/tools/notifiers) for them. For details about what triggers the predefined alerts, refer to the [documentation on default alerts.]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/default-alerts) -## Alerts Scope +This section covers the following topics: + +- [Alert event examples](#alert-event-examples) +- [Urgency levels](#urgency-levels) +- [Scope of alerts](#scope-of-alerts) +- [Adding cluster alerts](#adding-cluster-alerts) +- [Managing cluster alerts](#managing-cluster-alerts) + +# Alert Event Examples + +Some examples of alert events are: + +- A Kubernetes [master component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) entering an unhealthy state. +- A node or [workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/) error occurring. +- A scheduled deployment taking place as planned. +- A node's hardware resources becoming overstressed. + +# Urgency Levels + +You can set an urgency level for each alert. This urgency appears in the notification you receive, helping you to prioritize your response actions. For example, if you have an alert configured to inform you of a routine deployment, no action is required. These alerts can be assigned a low priority level. However, if a deployment fails, it can critically impact your organization, and you need to react quickly. Assign these alerts a high priority level. + +# Scope of Alerts The scope for alerts can be set at either the cluster level or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/). @@ -22,7 +45,7 @@ At the cluster level, Rancher monitors components in your Kubernetes cluster, an - The resource events from specific system services. - The Prometheus expression cross the thresholds -## Adding Cluster Alerts +# Adding Cluster Alerts As a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to send you alerts for cluster events. @@ -202,7 +225,7 @@ This alert type monitors for the overload from Prometheus expression querying, i **Result:** Your alert is configured. A notification is sent when the alert is triggered. -## Managing Cluster Alerts +# Managing Cluster Alerts After you set up cluster alerts, you can manage each alert object. To manage alerts, browse to the cluster containing the alerts, and then select **Tools > Alerts** that you want to manage. You can: @@ -210,4 +233,4 @@ After you set up cluster alerts, you can manage each alert object. To manage ale - Edit alert settings - Delete unnecessary alerts - Mute firing alerts -- Unmute muted alerts +- Unmute muted alerts \ No newline at end of file diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md index 42fe6e49253..e2c8b9f5054 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md @@ -8,7 +8,13 @@ aliases: - /rancher/v2.x/en/tools/logging/ --- -Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters. +Logging is helpful because it allows you to: + +- Capture and analyze the state of your cluster +- Look for trends in your environment +- Save your logs to a safe location outside of your cluster +- Stay informed of events like a container crashing, a pod eviction, or a node dying +- More easily debugg and troubleshoot problems Rancher supports integration with the following services: @@ -18,9 +24,26 @@ Rancher supports integration with the following services: - Syslog - Fluentd +This section covers the following topics: + +- [How logging integrations work](#how-logging-integrations-work) +- [Requirements](#requirements) +- [Logging scope](#logging-scope) +- [Enabling cluster logging](#enabling-cluster-logging) + +# How Logging Integrations Work + +Rancher can integrate with popular external services used for event streams, telemetry, or search. These services can log errors and warnings in your Kubernetes infrastructure to a stream. + +These services collect container log events, which are saved to the `/var/log/containers` directory on each of your nodes. The service collects both standard and error events. You can then log into your services to review the events collected, leveraging each service's unique features. + +When configuring Rancher to integrate with these services, you'll have to point Rancher toward the service's endpoint and provide authentication information. + +Additionally, you'll have the opportunity to enter key-value pairs to filter the log events collected. The service will only collect events for containers marked with your configured key-value pairs. + >**Note:** You can only configure one logging service per cluster or per project. -## Requirements +# Requirements The Docker daemon on each node in the cluster should be [configured](https://docs.docker.com/config/containers/logging/configure/) with the (default) log-driver: `json-file`. You can check the log-driver by running the following command: @@ -29,16 +52,7 @@ $ docker info | grep 'Logging Driver' Logging Driver: json-file ``` -## Advantages - -Setting up a logging service to collect logs from your cluster/project has several advantages: - -- Logs errors and warnings in your Kubernetes infrastructure to a stream. The stream informs you of events like a container crashing, a pod eviction, or a node dying. -- Allows you to capture and analyze the state of your cluster and look for trends in your environment using the log stream. -- Helps you when troubleshooting or debugging. -- Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues. - -## Logging Scope +# Logging Scope You can configure logging at either cluster level or project level. @@ -50,7 +64,7 @@ Logs that are sent to your logging service are from the following locations: - Pod logs stored at `/var/log/containers`. - Kubernetes system components logs stored at `/var/lib/rancher/rke/log/`. -## Enabling Cluster Logging +# Enabling Cluster Logging As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to send Kubernetes logs to a logging service. diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md index 887bcda96d1..4eb7a29e020 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md @@ -6,13 +6,32 @@ weight: 4 _Available as of v2.2.0_ -Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/): +Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. + +This section covers the following topics: + +- [About Prometheus](#about-prometheus) +- [Monitoring scope](#monitoring-scope) +- [Enabling cluster monitoring](#enabling-cluster-monitoring) +- [Resource consumption](#resource-consumption) + - [Resource consumption of Prometheus pods](#resource-consumption-of-prometheus-pods) + - [Resource consumption of other pods](#resources-consumption-of-other-pods) + +# About Prometheus + +Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/): + +You can configure these services to collect logs at either the cluster level or the project level. This page describes how to enable monitoring for a cluster. For details on enabling monitoring for a project, refer to the [project administration section]({{}}/rancher/v2.x/en/project-admin/tools/monitoring/). >A stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster. -In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported. +In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. -## Monitoring Scope +By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. + +Multi-tenancy support in terms of cluster-only and project-only Prometheus instances are also supported. + +# Monitoring Scope Using Prometheus, you can monitor Rancher at both the cluster level and [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/). For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server. @@ -24,7 +43,7 @@ Using Prometheus, you can monitor Rancher at both the cluster level and [project - [Project monitoring]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/) allows you to view the state of pods running in a given project. Prometheus collects metrics from the project's deployed HTTP and TCP/UDP workloads. -## Enabling Cluster Monitoring +# Enabling Cluster Monitoring As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster. @@ -36,13 +55,13 @@ As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global 1. Click **Save**. -**Result:** The Prometheus server will be deployed as well as two monitoring applications. The two monitoring applications, `cluster-monitoring` and `monitoring-operator`, are added as an [application]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) to the cluster's `system` project. After the applications are `active`, you can start viewing [cluster metrics]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/) through the [Rancher dashboard]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/viewing-metrics/#rancher-dashboard) or directly from [Grafana]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#grafana). +**Result:** The Prometheus server will be deployed as well as two monitoring applications. The two monitoring applications, `cluster-monitoring` and `monitoring-operator`, are added as an [application]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) to the cluster's `system` project. After the applications are `active`, you can start viewing [cluster metrics]({{}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/) through the [Rancher dashboard]({{}}/rancher/v2.x/en/cluster-admin/tools/monitoring/viewing-metrics/#rancher-dashboard) or directly from [Grafana]({{}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#grafana). -### Resource Consumption +# Resource Consumption When enabling cluster monitoring, you need to ensure your worker nodes and Prometheus pod have enough resources. The tables below provides a guide of how much resource consumption will be used. In larger deployments, it is strongly advised that the monitoring infrastructure be placed on dedicated nodes in the cluster. -#### Prometheus Pod Resource Consumption +### Resource Consumption of Prometheus Pods This table is the resource consumption of the Prometheus pod, which is based on the number of all the nodes in the cluster. The count of nodes includes the worker, control plane and etcd nodes. Total disk space allocation should be approximated by the `rate * retention` period set at the cluster level. When enabling cluster level monitoring, you should adjust the CPU and Memory limits and reservation. @@ -70,7 +89,7 @@ Additional pod resource requirements for cluster level monitoring. | Operator | prometheus-operator | 100m | 50Mi | 200m | 100Mi | Y | -#### Other Pods Resource Consumption +### Resource Consumption of Other Pods Besides the Prometheus pod, there are components that are deployed that require additional resources on the worker nodes. @@ -79,4 +98,4 @@ Pod | CPU (milli CPU) | Memory (MB) Node Exporter (Per Node) | 100 | 30 Kube State Cluster Monitor | 100 | 130 Grafana | 100 | 150 -Prometheus Cluster Monitoring Nginx | 50 | 50 +Prometheus Cluster Monitoring Nginx | 50 | 50 \ No newline at end of file From f59d08eb78f66105c407151e6c75d7f430494930 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 31 Dec 2019 15:34:06 -0700 Subject: [PATCH 68/82] Fix formatting in installation docs --- .../air-gap/install-rancher/_index.md | 127 ++++++++---------- .../single-node/_index.md | 9 +- 2 files changed, 60 insertions(+), 76 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 c4cb3081474..e0becd6511d 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 @@ -31,24 +31,20 @@ This section describes installing Rancher in five parts: 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. 1. If you haven't already, initialize `helm` locally on a workstation that has internet access. Note: Refer to the [Helm version requirements]({{}}/rancher/v2.x/en/installation/options/helm-version) to choose a version of Helm to install Rancher. - - ```plain - helm init -c - ``` + ```plain + helm init -c + ``` 2. Use `helm repo add` command to add the Helm chart repository that contains charts to install Rancher. For more information about the repository choices and which is best for your use case, see [Choosing a Version of Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/options/server-tags/#helm-chart-repositories). - - {{< release-channel >}} - - ``` - helm repo add rancher- https://releases.rancher.com/server-charts/ - ``` + {{< release-channel >}} + ``` + helm repo add rancher- https://releases.rancher.com/server-charts/ + ``` 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 +``` > Want additional options? Need help troubleshooting? See [High Availability Install: Advanced Options]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/#advanced-configurations). @@ -69,12 +65,12 @@ For HA air gap configurations, there are two recommended options for the source When setting up the Rancher Helm template, there are several options in the Helm chart that are designed specifically for air gap installations. -| Chart Option | Chart Value | Description | -| ----------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `systemDefaultRegistry` | `` | Configure Rancher server to always pull from your private registry when provisioning clusters. | +| Chart Option | Chart Value | Description | +| ----------------------- | -------------------------------- | ------- | +| `systemDefaultRegistry` | `` | 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-optional-install-cert-manager), complete one of the procedures below. +Based on the choice your made in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), complete one of the procedures below. {{% accordion id="self-signed" label="Option A-Default Self-Signed Certificate" %}} @@ -84,20 +80,17 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat > Recent changes to cert-manager require an upgrade. If you are upgrading Rancher and using a version of cert-manager older than v0.9.1, please see our [upgrade cert-manager documentation]({{< baseurl >}}/rancher/v2.x/en/installation/options/upgrading-cert-manager/). 1. From a system connected to the internet, add the cert-manager repo to Helm. - - ```plain - helm repo add jetstack https://charts.jetstack.io - helm repo update - ``` + ```plain + helm repo add jetstack https://charts.jetstack.io + helm repo update + ``` 1. Fetch the latest cert-manager chart available from the [Helm chart repository](https://hub.helm.sh/charts/jetstack/cert-manager). - - ```plain - helm fetch jetstack/cert-manager --version v0.9.1 - ``` + ```plain + helm fetch jetstack/cert-manager --version v0.9.1 + ``` 1. Render the cert manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files. - ```plain helm template ./cert-manager-v0.9.1.tgz --output-dir . \ --name cert-manager --namespace cert-manager \ @@ -107,21 +100,17 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat ``` 1. Download the required CRD file for cert-manager - ```plain curl -L -o cert-manager/cert-manager-crd.yaml https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml ``` - 1. Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools. - - Placeholder | Description - ------------|------------- - `` | The version number of the output tarball. - `` | The DNS name you pointed at your load balancer. - `` | The DNS name for your private registry. - - ```plain +Placeholder | Description + ------------|------------- +`` | The version number of the output tarball. +`` | The DNS name you pointed at your load balancer. +`` | The DNS name for your private registry. + ```plain helm template ./rancher-.tgz --output-dir . \ --name rancher \ --namespace cattle-system \ @@ -129,27 +118,24 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat --set rancherImage=/rancher/rancher \ --set systemDefaultRegistry= \ # Available as of v2.2.0, set a default private registry to be used in Rancher --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts - ``` +``` {{% /accordion %}} {{% accordion id="secret" label="Option B: Certificates From Files using Kubernetes Secrets" %}} -1. Create Kubernetes secrets from your own certificates for Rancher to use. +Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher. - > **Note:** The common name for the cert will need to match the `hostname` option or the ingress controller will fail to provision the site for Rancher. +Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools. -1. Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools. +If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`. - > **Note:** If you are using a Private CA signed cert, add `--set privateCA=true` following `--set ingress.tls.source=secret`. - - | Placeholder | Description | - | -------------------------------- | ----------------------------------------------- | - | `` | The version number of the output tarball. | - | `` | The DNS name you pointed at your load balancer. | - | `` | The DNS name for your private registry. | - - ```plain +| Placeholder | Description | +| -------------------------------- | ----------------------------------------------- | +| `` | The version number of the output tarball. | +| `` | The DNS name you pointed at your load balancer. | +| `` | The DNS name for your private registry. | +```plain helm template ./rancher-.tgz --output-dir . \ --name rancher \ --namespace cattle-system \ @@ -158,9 +144,9 @@ By default, Rancher generates a CA and uses cert-manager to issue the certificat --set ingress.tls.source=secret \ --set systemDefaultRegistry= \ # Available as of v2.2.0, set a default private registry to be used in Rancher --set useBundledSystemChart=true # Available as of v2.3.0, use the packaged Rancher system charts - ``` +``` -1. See [Adding TLS Secrets]({{}}/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them. +Then refer to [Adding TLS Secrets]({{}}/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/) to publish the certificate files so Rancher and the ingress controller can use them. {{% /accordion %}} @@ -170,34 +156,31 @@ 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 chose to use self-signed certificates in [B. Choose your SSL Configuration](#b-optional-install-cert-manager), install cert-manager. +If you chose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager. {{% accordion id="install-cert-manager" label="Self-Signed Certificate Installs - Install Cert-manager" %}} If you are using self-signed certificates, install cert-manager: 1. Create the namespace for cert-manager. - - ```plain - kubectl create namespace cert-manager - ``` +```plain +kubectl create namespace cert-manager +``` 1. Label the cert-manager namespace to disable resource validation. - - ```plain - kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true - ``` +```plain +kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true +``` 1. Create the cert-manager CustomResourceDefinitions (CRDs). - - ```plain - kubectl apply -f cert-manager/cert-manager-crd.yaml - ``` +```plain +kubectl apply -f cert-manager/cert-manager-crd.yaml +``` 1. Launch cert-manager. - ```plain - kubectl apply -R -f ./cert-manager - ``` +```plain +kubectl apply -R -f ./cert-manager +``` {{% /accordion %}} @@ -229,9 +212,9 @@ The single node installation is for Rancher users that are wanting to **test** o For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster. -| Environment Variable Key | Environment Variable Value | Description | -| -------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `CATTLE_SYSTEM_DEFAULT_REGISTRY` | `` | Configure Rancher server to always pull from your private registry when provisioning clusters. | +| Environment Variable Key | Environment Variable Value | Description | +| -------------------------------- | -------------------------------- | ---- | +| `CATTLE_SYSTEM_DEFAULT_REGISTRY` | `` | Configure Rancher server to always pull from your private registry when provisioning clusters. | | `CATTLE_SYSTEM_CATALOG` | `bundled` | 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_ | > **Do you want to...** diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md index 60a1be75680..38b8d067fb8 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md @@ -38,10 +38,11 @@ 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. - docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - rancher/rancher:latest - +``` +docker run -d --restart=unless-stopped \ +-p 80:80 -p 443:443 \ +rancher/rancher:latest +``` {{% /accordion %}} {{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Self-Signed" %}} In development or testing environments where your team will access your Rancher server, create a self-signed certificate for use with your install so that your team can verify they're connecting to your instance of Rancher. From 2b59cf2bd767b800e6c5eb262f8da3e02e02835c Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 31 Dec 2019 16:04:31 -0700 Subject: [PATCH 69/82] Fix accordions --- .../single-node/_index.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md index 38b8d067fb8..1eba31f9b01 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/_index.md @@ -6,10 +6,11 @@ aliases: - /rancher/v2.x/en/installation/single-node-install/ - /rancher/v2.x/en/installation/single-node --- + For development and testing environments, we recommend installing Rancher by running a single Docker container. In this installation scenario, you'll install Docker on a single Linux host, and then deploy Rancher on your host using a single Docker container. > **Want to use an external load balancer?** -> See [Single Node Install with an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb) instead. +> See [Single Node Install with an External Load Balancer]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb) instead. ## Requirements for OS, Docker, Hardware, and Networking @@ -17,7 +18,7 @@ Make sure that your node fulfills the general [installation requirements.]({{}}/rancher/v2.x/en/installation/requirements) to launch your {{< product >}} Server. +Provision a single Linux host according to our [Requirements]({{}}/rancher/v2.x/en/installation/requirements) to launch your Rancher server. ## 2. Choose an SSL Option and Install Rancher @@ -25,9 +26,9 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher > **Do you want to...** > -> - Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/other-installation-methods/single-node/proxy/) -> - Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) -> - Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/) +> - Use a proxy? See [HTTP Proxy Configuration]({{}}/rancher/v2.x/en/installation/other-installation-methods/single-node/proxy/) +> - Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/) +> - Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{}}/rancher/v2.x/en/installation/air-gap-single-node/) > - Record all transactions with the Rancher API? See [API Auditing](#api-audit-log) Choose from the following options: @@ -40,8 +41,8 @@ Log into your Linux host, and then run the minimum installation command below. ``` docker run -d --restart=unless-stopped \ --p 80:80 -p 443:443 \ -rancher/rancher:latest + -p 80:80 -p 443:443 \ + rancher/rancher:latest ``` {{% /accordion %}} {{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Self-Signed" %}} @@ -90,7 +91,7 @@ After obtaining your certificate, run the Docker command below. | ------------------- | ------------------------------------------------------------ | | `` | The path to the directory containing your certificate files. | | `` | The path to your full certificate chain. | -| `` | The path to the private key for your certificate. | +| `` | The path to the private key for your certificate. | ``` docker run -d --restart=unless-stopped \ @@ -98,7 +99,7 @@ docker run -d --restart=unless-stopped \ -v //:/etc/rancher/ssl/cert.pem \ -v //:/etc/rancher/ssl/key.pem \ rancher/rancher:latest \ - --no-cacerts + --no-cacerts ``` {{% /accordion %}} @@ -122,11 +123,10 @@ After you fulfill the prerequisites, you can install Rancher using a Let's Encry ``` docker run -d --restart=unless-stopped \ - -p 80:80 -p 443:443 \ - rancher/rancher:latest \ - --acme-domain + -p 80:80 -p 443:443 \ + rancher/rancher:latest \ + --acme-domain ``` - {{% /accordion %}} ## Advanced Options From 6ce580875a5b4b66fb3c7e08cea9bbd6026a73c0 Mon Sep 17 00:00:00 2001 From: Vicken Simonian Date: Wed, 1 Jan 2020 23:36:06 -0800 Subject: [PATCH 70/82] Various typo fixes --- .../k3s/latest/en/installation/ha/_index.md | 2 +- .../en/installation/network-options/_index.md | 3 +- content/os/v1.x/en/about/security/_index.md | 2 +- .../adding-kernel-parameters/_index.md | 4 +- .../configuration/docker/_index.md | 24 ++++---- .../networking/interfaces/_index.md | 10 ++-- .../running-rancheros/cloud/do/_index.md | 2 +- .../authentication/ad/_index.md | 10 ++-- .../authentication/google/_index.md | 44 +++++++------- .../authentication/keycloak/_index.md | 15 +++-- .../authentication/ping-federate/_index.md | 6 +- .../authentication/user-groups/_index.md | 2 +- .../rbac/cluster-project-roles/_index.md | 9 ++- .../rbac/default-custom-roles/_index.md | 4 +- .../rbac/global-permissions/_index.md | 4 +- .../en/admin-settings/rke-templates/_index.md | 4 +- .../rke-templates/example-scenarios/_index.md | 10 ++-- .../en/best-practices/management/_index.md | 16 ++--- .../v2.x/en/catalog/globaldns/_index.md | 4 +- .../en/catalog/multi-cluster-apps/_index.md | 14 ++--- .../cluster-admin/backing-up-etcd/_index.md | 4 +- .../cluster-access/kubectl/_index.md | 2 +- .../projects-and-namespaces/_index.md | 2 +- .../en/cluster-admin/tools/istio/_index.md | 4 +- .../cluster-admin/tools/istio/rbac/_index.md | 4 +- .../en/cluster-admin/tools/logging/_index.md | 4 +- .../cluster-admin/tools/monitoring/_index.md | 4 +- .../tools/monitoring/expression/_index.md | 4 +- .../volumes-and-storage/_index.md | 2 +- .../examples/vsphere/_index.md | 4 +- .../node-requirements/_index.md | 8 +-- .../rke-clusters/node-pools/ec2/_index.md | 4 +- .../rke-clusters/options/_index.md | 58 +++++++++---------- .../rancher/v2.x/en/contributing/_index.md | 2 +- .../en/faq/networking/cni-providers/_index.md | 2 +- .../ha/create-nodes-lb/nginx/_index.md | 2 +- .../en/installation/how-ha-works/_index.md | 2 +- .../options/chart-options/_index.md | 2 +- .../en/installation/options/etcd/_index.md | 2 +- .../helm2/create-nodes-lb/nginx/_index.md | 2 +- .../helm-rancher/chart-options/_index.md | 2 +- .../helm2/rke-add-on/layer-4-lb/_index.md | 4 +- .../helm2/rke-add-on/layer-7-lb/_index.md | 6 +- .../options/rke-add-on/layer-4-lb/_index.md | 4 +- .../options/rke-add-on/layer-7-lb/_index.md | 6 +- .../options/upgrading-cert-manager/_index.md | 2 +- .../single-node-install-external-lb/_index.md | 2 +- .../en/installation/requirements/_index.md | 2 +- .../en/k8s-in-rancher/certificates/_index.md | 2 +- .../manage-hpa-with-rancher-ui/_index.md | 2 +- .../testing-hpa/_index.md | 18 +++--- .../ingress/_index.md | 2 +- .../en/k8s-in-rancher/pipelines/_index.md | 26 ++++----- .../workloads/rollback-workloads/_index.md | 2 +- .../workloads/upgrade-workloads/_index.md | 2 +- .../v2.x/en/security/benchmark-2.1/_index.md | 2 +- .../controlplane/_index.md | 2 +- .../worker-and-generic/_index.md | 2 +- .../rollbacks/single-node-rollbacks/_index.md | 4 +- .../v1.6-migration/load-balancing/_index.md | 2 +- .../en/v1.6-migration/monitor-apps/_index.md | 2 +- .../secrets-encryption/_index.md | 2 +- .../ssh-connectivity-errors/_index.md | 4 +- 63 files changed, 203 insertions(+), 206 deletions(-) diff --git a/content/k3s/latest/en/installation/ha/_index.md b/content/k3s/latest/en/installation/ha/_index.md index 81adf97d1a7..ca6897ae48a 100644 --- a/content/k3s/latest/en/installation/ha/_index.md +++ b/content/k3s/latest/en/installation/ha/_index.md @@ -16,7 +16,7 @@ The following diagram illustrates the above configuration: In this architecture a server node is defined as a machine (bare-metal or virtual) running the `k3s server` command. A worker node is defined as a machine running the `k3s agent` command. -Workers register through the fixed registration address, but after registration they establish a connection directly to one of the sever nodes. This is a websocket connection initiated by the `k3s agent` process and it is maintained by a client-side load balancer running as part of the agent process. +Workers register through the fixed registration address, but after registration they establish a connection directly to one of the server nodes. This is a websocket connection initiated by the `k3s agent` process and it is maintained by a client-side load balancer running as part of the agent process. Installation Outline -------------------- diff --git a/content/k3s/latest/en/installation/network-options/_index.md b/content/k3s/latest/en/installation/network-options/_index.md index 2894215706c..b981d8775cf 100644 --- a/content/k3s/latest/en/installation/network-options/_index.md +++ b/content/k3s/latest/en/installation/network-options/_index.md @@ -34,7 +34,7 @@ Visit the [Project Calico Docs](https://docs.projectcalico.org/) website. Follow } ``` -Applyl the Canal YAML. +Apply the Canal YAML. Ensure the settings were applied by running the following command on the host: @@ -68,4 +68,3 @@ You should see that IP forwarding is set to true. {{% /tab %}} {{% /tabs %}} - diff --git a/content/os/v1.x/en/about/security/_index.md b/content/os/v1.x/en/about/security/_index.md index a7cc30096dc..00286cf1a53 100644 --- a/content/os/v1.x/en/about/security/_index.md +++ b/content/os/v1.x/en/about/security/_index.md @@ -14,7 +14,7 @@ weight: 303

Please submit possible security issues by emailing security@rancher.com

-

Announcments

+

Announcements

Subscribe to the Rancher announcements forum for release updates.

diff --git a/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md b/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md index 49d4242bb19..cafa5232098 100644 --- a/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md +++ b/content/os/v1.x/en/installation/configuration/adding-kernel-parameters/_index.md @@ -49,7 +49,7 @@ On desktop systems the Syslinux boot menu can be switched to graphical mode by a #### Recovery console -`rancher.recovery=true` will start a single user `root` bash session as easily in the boot process, with no network, or persitent filesystem mounted. This can be used to fix disk problems, or to debug your system. +`rancher.recovery=true` will start a single user `root` bash session as easily in the boot process, with no network, or persistent filesystem mounted. This can be used to fix disk problems, or to debug your system. #### Enable/Disable sshd @@ -61,7 +61,7 @@ On desktop systems the Syslinux boot menu can be switched to graphical mode by a #### Autologin console -`rancher.autologin=` will automatically log in the sepcified console - common values are `tty1`, `ttyS0` and `ttyAMA0` - depending on your platform. +`rancher.autologin=` will automatically log in the specified console - common values are `tty1`, `ttyS0` and `ttyAMA0` - depending on your platform. #### Enable/Disable hypervisor service auto-enable diff --git a/content/os/v1.x/en/installation/configuration/docker/_index.md b/content/os/v1.x/en/installation/configuration/docker/_index.md index ef670d9ef93..0620f6ecd6d 100644 --- a/content/os/v1.x/en/installation/configuration/docker/_index.md +++ b/content/os/v1.x/en/installation/configuration/docker/_index.md @@ -119,7 +119,7 @@ $ ros config set rancher.system_docker.bip 172.19.0.0/16 _Available as of v1.4.x_ -The default path of system-docker logs is `/var/log/system-docker.log`. If you want to write the system-docker logs to a separate partition, +The default path of system-docker logs is `/var/log/system-docker.log`. If you want to write the system-docker logs to a separate partition, e.g. [RANCHER_OEM partition]({{< baseurl >}}/os/v1.x/en/about/custom-partition-layout/#use-rancher-oem-partition), you can try `rancher.defaults.system_docker_logs`: ``` @@ -170,11 +170,11 @@ Status: Downloaded newer image for alpine:latest _Available as of v1.5.0_ -When RancherOS is booted, you start with a User Docker service that is running in System Docker. With v1.5.0, RancherOS has the ability to create additional User Docker services that can run at the same time. +When RancherOS is booted, you start with a User Docker service that is running in System Docker. With v1.5.0, RancherOS has the ability to create additional User Docker services that can run at the same time. #### Terminology -Throughout the rest of this documentation, we may simplify to use these terms when describing Docker. +Throughout the rest of this documentation, we may simplify to use these terms when describing Docker. | Terminology | Definition | |-----------------------|--------------------------------------------------| @@ -184,13 +184,13 @@ Throughout the rest of this documentation, we may simplify to use these terms wh #### Pre-Requisites -User Docker must be set as Docker 17.12.1 or earlier. If it's a later Docker version, it will produce errors when creating a user defined network in System Docker. +User Docker must be set as Docker 17.12.1 or earlier. If it's a later Docker version, it will produce errors when creating a user defined network in System Docker. ``` $ ros engine switch docker-17.12.1-ce ``` -You will need to create a user-defined network, which will be used when creating the Other User Docker. +You will need to create a user-defined network, which will be used when creating the Other User Docker. ``` $ system-docker network create --subnet=172.20.0.0/16 dind @@ -204,7 +204,7 @@ In order to create another User Docker, you will use `ros engine create`. Curren $ ros engine create otheruserdockername --network=dind --fixed-ip=172.20.0.2 ``` -After the Other User Docker service is created, users can query this service like other services. +After the Other User Docker service is created, users can query this service like other services. ``` $ ros service list @@ -215,13 +215,13 @@ disabled volume-nfs enabled otheruserdockername ``` -You can use `ros service up` to start the Other User Docker service. +You can use `ros service up` to start the Other User Docker service. ``` $ ros service up otheruserdockername ``` -After the Other User Docker service is running, you can interact with it just like you can use the built-in User Docker. You would need to append `-` to `docker`. +After the Other User Docker service is running, you can interact with it just like you can use the built-in User Docker. You would need to append `-` to `docker`. ``` $ docker-otheruserdockername ps -a @@ -229,7 +229,7 @@ $ docker-otheruserdockername ps -a #### SSH into the Other User Docker container -When creating the Other User Docker, you can set an external SSH port so you can SSH into the Other User Docker container in System Docker. By using `--ssh-port` and adding ssh keys with `--authorized-keys`, you can set up this optional SSH port. +When creating the Other User Docker, you can set an external SSH port so you can SSH into the Other User Docker container in System Docker. By using `--ssh-port` and adding ssh keys with `--authorized-keys`, you can set up this optional SSH port. ``` $ ros engine create --help @@ -248,7 +248,7 @@ When using `--authorized-keys`, you will need to put the key file in one of the /home/ ``` -RancherOS will generate a random password for each Other User Docker container, which can be viewed in the container logs. If you do not set any SSH keys, the password can be used. +RancherOS will generate a random password for each Other User Docker container, which can be viewed in the container logs. If you do not set any SSH keys, the password can be used. ``` $ system-docker logs otheruserdockername @@ -259,7 +259,7 @@ password: xCrw6fEG ====================================== ``` -In System Docker, you can SSH into any Other Uesr Docker Container using `ssh`. +In System Docker, you can SSH into any Other User Docker Container using `ssh`. ``` $ system-docker ps @@ -274,7 +274,7 @@ $ ssh root@ #### Removing any Other User Docker Service -We recommend using `ros engine rm` to remove any Other User Docker service. +We recommend using `ros engine rm` to remove any Other User Docker service. ``` $ ros engine rm otheruserdockername diff --git a/content/os/v1.x/en/installation/networking/interfaces/_index.md b/content/os/v1.x/en/installation/networking/interfaces/_index.md index f33ac9f7de9..f93384e4e53 100644 --- a/content/os/v1.x/en/installation/networking/interfaces/_index.md +++ b/content/os/v1.x/en/installation/networking/interfaces/_index.md @@ -232,7 +232,7 @@ rancher: scan_ssid: 1 ``` -When adding in WiFi access, you do not need a system reboot, you only need to restart the `network` service in System Docker. +When adding in WiFi access, you do not need a system reboot, you only need to restart the `network` service in System Docker. ``` $ sudo system-docker restart network @@ -244,13 +244,13 @@ $ sudo system-docker restart network _Available as of v1.5_ -In order to support 4G-LTE, 4G-LTE module will need to be connected to the motherboard and to get a good signal, an external atenna will need to be added. You can assemble such a device, which supports USB interface and SIM cards slot: +In order to support 4G-LTE, 4G-LTE module will need to be connected to the motherboard and to get a good signal, an external antenna will need to be added. You can assemble such a device, which supports USB interface and SIM cards slot: ![](https://ws1.sinaimg.cn/bmiddle/006tNc79ly1fzcuvhu6zpj30k80qwag1.jpg) -In order to use RancherOS, you will need to use the ISO built for 4G-LTE support. This ISO has a built-in `modem-manager` service and is available with each release. +In order to use RancherOS, you will need to use the ISO built for 4G-LTE support. This ISO has a built-in `modem-manager` service and is available with each release. -After booting the ISO, there will be a 4G NIC, such as `wwan0`. Use the following `cloud-config` to set the APN parameter. +After booting the ISO, there will be a 4G NIC, such as `wwan0`. Use the following `cloud-config` to set the APN parameter. ```yaml rancher: @@ -266,4 +266,4 @@ After any configuration changes, restart the `modem-manager` service to apply th $ sudo system-docker restart modem-manager ``` -> **Note:** Currently, RancherOS has some built-in rules in `udev` rules to allow RancherOS to recognize specific 4G devices, but there are additional vendors that may be missing. If you need to add these in, please file an issue. +> **Note:** Currently, RancherOS has some built-in rules in `udev` rules to allow RancherOS to recognize specific 4G devices, but there are additional vendors that may be missing. If you need to add these in, please file an issue. diff --git a/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md b/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md index 9390b0092f4..d644822ded6 100644 --- a/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md +++ b/content/os/v1.x/en/installation/running-rancheros/cloud/do/_index.md @@ -3,7 +3,7 @@ title: Digital Ocean weight: 107 --- -RancherOS is avaliable in the Digital Ocean portal. RancherOS is a member of container distributions and you can find it easily. +RancherOS is available in the Digital Ocean portal. RancherOS is a member of container distributions and you can find it easily. >**Note** >Deploying to Digital Ocean will incur charges. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md index fbe444f333c..f74e1e8b0ce 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md @@ -5,19 +5,19 @@ aliases: - /rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/ --- -If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI. +If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI. Rancher uses LDAP to communicate with the Active Directory server. The authentication flow for Active Directory is therefore the same as for the [OpenLDAP authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/openldap) integration. > **Note:** -> +> > Before you start, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). ## Prerequisites You'll need to create or obtain from your AD administrator a new AD user to use as service account for Rancher. This user must have sufficient permissions to perform LDAP searches and read attributes of users and groups under your AD domain. -Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has read-only privileges for most objects in the domain partition. +Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has read-only privileges for most objects in the domain partition. Note however, that in some locked-down Active Directory configurations this default behaviour may not apply. In such case you will need to ensure that the service account user has at least **Read** and **List Content** permissions granted either on the Base OU (enclosing users and groups) or globally for the domain. @@ -126,7 +126,7 @@ Once you have completed the configuration, proceed by testing the connection to ## Annex: Identify Search Base and Schema using ldapsearch -In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hirarchy and schema of your AD server. +In order to successfully configure AD authentication it is crucial that you provide the correct configuration pertaining to the hierarchy and schema of your AD server. The [`ldapsearch`](http://manpages.ubuntu.com/manpages/artful/man1/ldapsearch.1.html) tool allows you to query your AD server to learn about the schema used for user and group objects. @@ -165,7 +165,7 @@ The output of the above `ldapsearch` query also allows to determine the correct > **Note:** > -> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead. +> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead. We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md index f29f6520b21..5266e219d7e 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/google/_index.md @@ -15,7 +15,7 @@ Within Rancher, only administrators or users with the **Manage Authentication** - You must have the Admin SDK API enabled for your G Suite domain. You can enable it using the steps on [this page.](https://support.google.com/a/answer/60757?hl=en) After the Admin SDK API is enabled, your G Suite domain's API screen should look like this: -![Enable Admin APIs]({{}}/img/rancher/Google-Enable-APIs-Screen.png) +![Enable Admin APIs]({{}}/img/rancher/Google-Enable-APIs-Screen.png) # Setting up G Suite for OAuth with Rancher Before you can set up Google OAuth in Rancher, you need to log in to your G Suite account and do the following: @@ -27,8 +27,8 @@ Before you can set up Google OAuth in Rancher, you need to log in to your G Suit ### 1. Adding Rancher as an Authorized Domain 1. Click [here](https://console.developers.google.com/apis/credentials) to go to credentials page of your Google domain. -1. Select your project and click **OAuth consent screen.** -![OAuth Consent Screen]({{}}/img/rancher/Google-OAuth-consent-screen-tab.png) +1. Select your project and click **OAuth consent screen.** +![OAuth Consent Screen]({{}}/img/rancher/Google-OAuth-consent-screen-tab.png) 1. Go to **Authorized Domains** and enter the top private domain of your Rancher server URL in the list. The top private domain is the rightmost superdomain. So for example, www.foo.co.uk a top private domain of foo.co.uk. For more information on top-level domains, refer to [this article.](https://github.com/google/guava/wiki/InternetDomainNameExplained#public-suffixes-and-private-domains) 1. Go to **Scopes for Google APIs** and make sure **email,** **profile** and **openid** are enabled. @@ -36,14 +36,14 @@ Before you can set up Google OAuth in Rancher, you need to log in to your G Suit ### 2. Creating OAuth2 Credentials for the Rancher Server 1. Go to the Google API console, select your project, and go to the [credentials page.](https://console.developers.google.com/apis/credentials) -![Credentials]({{}}/img/rancher/Google-Credentials-tab.png) -1. On the **Create Credentials** dropdown, select **OAuth client ID.** +![Credentials]({{}}/img/rancher/Google-Credentials-tab.png) +1. On the **Create Credentials** dropdown, select **OAuth client ID.** 1. Click **Web application.** -1. Provide a name. -1. Fill out the **Authorized JavaScript origins** and **Authorized redirect URIs.** Note: The Rancher UI page for setting up Google OAuth (available from the Global view under **Security > Authentication > Google**) provides you the exact links to enter for this step. - - Under **Authorized JavaScript origins,** enter your Rancher server URL. - - Under **Authorized redirect URIs,** enter your Rancher server URL appended with the path `verify-auth`. For example, if your URI is `https://rancherServer`, you will enter `https://rancherServer/verify-auth`. -1. Click on **Create.** +1. Provide a name. +1. Fill out the **Authorized JavaScript origins** and **Authorized redirect URIs.** Note: The Rancher UI page for setting up Google OAuth (available from the Global view under **Security > Authentication > Google**) provides you the exact links to enter for this step. + - Under **Authorized JavaScript origins,** enter your Rancher server URL. + - Under **Authorized redirect URIs,** enter your Rancher server URL appended with the path `verify-auth`. For example, if your URI is `https://rancherServer`, you will enter `https://rancherServer/verify-auth`. +1. Click on **Create.** 1. After the credential is created, you will see a screen with a list of your credentials. Choose the credential you just created, and in that row on rightmost side, click **Download JSON.** Save the file so that you can provide these credentials to Rancher. **Result:** Your OAuth credentials have been successfully created. @@ -58,16 +58,16 @@ As a workaround to get this capability, G Suite recommends creating a service ac This section describes how to: - Create a service account -- Create a key for the service account and download the credenials as JSON +- Create a key for the service account and download the credentials as JSON 1. Click [here](https://console.developers.google.com/iam-admin/serviceaccounts) and select your project for which you generated OAuth credentials. -1. Click on **Create Service Account.** -1. Enter a name and click **Create.** -![Service account creation Step 1]({{}}/img/rancher/Google-svc-acc-step1.png) -1. Don't provide any roles on the **Service account permissions** page and click **Continue** -![Service account creation Step 2]({{}}/img/rancher/Google-svc-acc-step2.png) +1. Click on **Create Service Account.** +1. Enter a name and click **Create.** +![Service account creation Step 1]({{}}/img/rancher/Google-svc-acc-step1.png) +1. Don't provide any roles on the **Service account permissions** page and click **Continue** +![Service account creation Step 2]({{}}/img/rancher/Google-svc-acc-step2.png) 1. Click on **Create Key** and select the JSON option. Download the JSON file and save it so that you can provide it as the service account credentials to Rancher. -![Service account creation Step 3]({{}}/img/rancher/Google-svc-acc-step3-key-creation.png) +![Service account creation Step 3]({{}}/img/rancher/Google-svc-acc-step3-key-creation.png) **Result:** Your service account is created. @@ -79,13 +79,13 @@ Using the Unique ID of the service account key, register it as an Oauth Client u 1. Get the Unique ID of the key you just created. If it's not displayed in the list of keys right next to the one you created, you will have to enable it. To enable it, click **Unique ID** and click **OK.** This will add a **Unique ID** column to the list of service account keys. Save the one listed for the service account you created. NOTE: This is a numeric key, not to be confused with the alphanumeric field **Key ID.** - ![Service account Unique ID]({{}}/img/rancher/Google-Select-UniqueID-column.png) -1. Go to the [**Manage OAuth Client Access** page.](https://admin.google.com/AdminHome?chromeless=1#OGX:ManageOauthClients) + ![Service account Unique ID]({{}}/img/rancher/Google-Select-UniqueID-column.png) +1. Go to the [**Manage OAuth Client Access** page.](https://admin.google.com/AdminHome?chromeless=1#OGX:ManageOauthClients) 1. Add the Unique ID obtained in the previous step in the **Client Name** field. -1. In the **One or More API Scopes** field, add the following scopes: +1. In the **One or More API Scopes** field, add the following scopes: ``` openid,profile,email,https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly - ``` + ``` 1. Click **Authorize.** **Result:** The service account is registered as an OAuth client in your G Suite account. @@ -101,6 +101,6 @@ Using the Unique ID of the service account key, register it as an Oauth Client u - For **Step Two,** provide the OAuth credentials JSON that you downloaded after completing [this section.](#2-creating-oauth2-credentials-for-the-rancher-server) You can upload the file or paste the contents into the **OAuth Credentials** field. - For **Step Three,** provide the service account credentials JSON that downloaded at the end of [this section.](#3-creating-service-account-credentials) The credentials will only work if you successfully [registered the service account key](#4-register-the-service-account-key-as-an-oauth-client) as an OAuth client in your G Suite account. 1. Click **Authenticate with Google**. -1. Click **Save**. +1. Click **Save**. **Result:** Google authentication is successfully configured. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md index 9da68a94c75..e7350e6c96d 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/keycloak/_index.md @@ -1,6 +1,6 @@ --- title: Configuring Keycloak (SAML) -description: Create a Keycloack SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins +description: Create a Keycloak SAML client and configure Rancher to work with Keycloak. By the end your users will be able to sign into Rancher using their Keycloak logins weight: 1200 --- _Available as of v2.1.0_ @@ -12,7 +12,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati - You must have a [Keycloak IdP Server](https://www.keycloak.org/docs/latest/server_installation/) configured. - In Keycloak, create a [new SAML client](https://www.keycloak.org/docs/latest/server_admin/#saml-clients), with the settings below. See the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#saml-clients) for help. - Setting | Value + Setting | Value ------------|------------ `Sign Documents` | `ON` 1 `Sign Assertions` | `ON` 1 @@ -23,7 +23,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati `Valid Redirect URI` | `https://yourRancherHostURL/v1-saml/keycloak/saml/acs` >1: Optionally, you can enable either one or both of these settings. -- Export a `metadata.xml` file from your Keycloak client: +- Export a `metadata.xml` file from your Keycloak client: From the `Installation` tab, choose the `SAML Metadata IDPSSODescriptor` format option and download your file. @@ -48,7 +48,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati | IDP-metadata | The `metadata.xml` file that you exported from your IdP server. | >**Tip:** You can generate a key/certificate pair using an openssl command. For example: - > + > > openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.key -out myservice.cert @@ -64,7 +64,7 @@ If your organization uses Keycloak Identity Provider (IdP) for user authenticati ## Annex: Troubleshooting -If you are experiencing issues while testing the connection to the Keycloak server, first double-check the confiuration option of your SAML client. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation. +If you are experiencing issues while testing the connection to the Keycloak server, first double-check the configuration option of your SAML client. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation. ### You are not redirected to Keycloak @@ -90,10 +90,10 @@ You are correctly redirected to your IdP login page and you are able to enter yo * Check your Keycloak log. * If the log displays `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`, set `Client Signature Required` to `OFF` in your Keycloak client. - + ### Keycloak 6.0.0+: IDPSSODescriptor missing from options -Keycloak versions 6.0.0 and up no longer provide the IDP metadata under the `Installation` tab. +Keycloak versions 6.0.0 and up no longer provide the IDP metadata under the `Installation` tab. You can still get the XML from the following url: `https://{KEYCLOAK-URL}/auth/realms/{REALM-NAME}/protocol/saml/descriptor` @@ -112,4 +112,3 @@ You are left with something similar as the example below: ``` - diff --git a/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md index cc6a3b75791..8cb2508c681 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/ping-federate/_index.md @@ -9,9 +9,9 @@ If your organization uses Ping Identity Provider (IdP) for user authentication, >**Prerequisites:** > >- You must have a [Ping IdP Server](https://www.pingidentity.com/) configured. ->- Following are the Rancher Service Provider URLs needed for configuration: -Metadata URL: `https:///v1-saml/ping/saml/metadata` -Assertion Consure Service (ACS) URL: `https:///v1-saml/ping/saml/acs` +>- Following are the Rancher Service Provider URLs needed for configuration: +Metadata URL: `https:///v1-saml/ping/saml/metadata` +Assertion Consumer Service (ACS) URL: `https:///v1-saml/ping/saml/acs` >- Export a `metadata.xml` file from your IdP Server. For more information, see the [PingIdentity documentation](https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#concept_exportingMetadata.html). 1. From the **Global** view, select **Security > Authentication** from the main menu. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md index b4261c097cf..722452e5f63 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/user-groups/_index.md @@ -29,7 +29,7 @@ Rancher will periodically refresh the user information even before a user logs i - **`auth-user-info-max-age-seconds`** - This setting controls how old a user's information can be before Rancher refreshes it. If a user makes an API call (either directly or by using the Rancher CLI or kubectl) and the time since the user's last refresh is greater than this setting, then Rancher will trigger a refresh. This settting defaults to `3600` seconds, i.e. 1 hour. + This setting controls how old a user's information can be before Rancher refreshes it. If a user makes an API call (either directly or by using the Rancher CLI or kubectl) and the time since the user's last refresh is greater than this setting, then Rancher will trigger a refresh. This setting defaults to `3600` seconds, i.e. 1 hour. - **`auth-user-info-resync-cron`** diff --git a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md index 92292af2ab0..bd7867b8f55 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md @@ -89,7 +89,7 @@ _Project roles_ are roles that can be used to grant users access to a project. T These users can view everything in the project but cannot create, update, or delete anything. >**Caveat:** - > + > >Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned. @@ -126,7 +126,7 @@ The following table lists each built-in custom project role available in Rancher > **Notes:** > >- Each project role listed above, including `Owner`, `Member`, and `Read Only`, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page. ->- When viewing the resources associated with default roles created by Rancher, if there are multiple Kuberenetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. +>- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource. >- The `Manage Project Members` role allows the project owner to manage any members of the project **and** grant them any project scoped role regardless of their access to the project resources. Be cautious when assigning this role out individually. ### Defining Custom Roles @@ -161,12 +161,12 @@ You can change the cluster or project role(s) that are automatically assigned to 1. Enable the role as default. {{% accordion id="cluster" label="For Clusters" %}} -1. From **Clustor Creator Default**, choose **Yes: Default role for new cluster creation**. +1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**. 1. Click **Save**. {{% /accordion %}} {{% accordion id="project" label="For Projects" %}} 1. From **Project Creator Default**, choose **Yes: Default role for new project creation**. -1. Click **Save**. +1. Click **Save**. {{% /accordion %}} 1. If you want to remove a default role, edit the permission and select **No** from the default roles option. @@ -181,4 +181,3 @@ When you revoke the cluster membership for a standard user that's explicitly ass - Exercise any [individual project roles](#project-role-reference) they are assigned. If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships. - diff --git a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md index 8bfc1edf915..f17db7645a7 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/_index.md @@ -150,9 +150,9 @@ When a user in the group logs in, they get the built-in Standard User global rol If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have their individual Standard User role. > **Prerequisites:** You can only assign a global role to a group if: -> +> > * You have set up an [external authentication provider]({{}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication) -> * The external authentication provider suppports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) +> * The external authentication provider supports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) > * You have already set up at least one user group with the authentication provider To assign a custom global role to a group, follow these steps: diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index f66580a89f4..c181c5dee43 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -141,9 +141,9 @@ For new users, the new permissions take effect when the users log in to Rancher If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default.** Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,]((#refreshing-group-memberships)) whichever comes first. > **Prerequisites:** You can only assign a global role to a group if: -> +> > * You have set up an [external authentication provider]({{}}/rancher/v2.x/en/admin-settings/authentication/#external-vs-local-authentication) -> * The external authentication provider suppports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) +> * The external authentication provider supports [user groups]({{}}/rancher/v2.x/en/admin-settings/authentication/user-groups/) > * You have already set up at least one user group with the authentication provider To assign a custom global role to a group, follow these steps: diff --git a/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md b/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md index 34ac570d8e1..3c0d8cbcdc5 100644 --- a/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rke-templates/_index.md @@ -47,7 +47,7 @@ The [add-on section](#add-ons) of an RKE template is especially powerful because # Scope of RKE Templates RKE templates are supported for Rancher-provisioned clusters. The templates can be used to provision custom clusters or clusters that are launched by an infrastructure provider. - + RKE templates are for defining Kubernetes and Rancher settings. Node templates are responsible for configuring nodes. For tips on how to use RKE templates in conjunction with hardware, refer to [RKE Templates and Hardware]({{}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware). RKE templates can be created from scratch to pre-define cluster configuration. They can be applied to launch new clusters, or templates can also be exported from existing running clusters. @@ -102,7 +102,7 @@ As of Rancher v2.3.3, you can [save the configuration of an existing cluster as # Standardizing Hardware -RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjuction with other tools]({{}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware). +RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjunction with other tools]({{}}/rancher/v2.x/en/admin-settings/rke-templates/rke-templates-and-hardware). # YAML Customization diff --git a/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md b/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md index cbc398d7424..4e93e102c62 100644 --- a/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rke-templates/example-scenarios/_index.md @@ -15,11 +15,11 @@ These example scenarios describe how an organization could use templates to stan Let's say there is an organization in which the administrators decide that all new clusters should be created with Kubernetes version 1.14. -1. First, an administrator creates a template which specifies the Kubernetes version as 1.14 and marks all other settings as **Allow User Override**. +1. First, an administrator creates a template which specifies the Kubernetes version as 1.14 and marks all other settings as **Allow User Override**. 1. The administrator makes the template public. 1. The administrator turns on template enforcement. -**Results:** +**Results:** - All Rancher users in the organization have access to the template. - All new clusters created by [standard users]({{}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) with this template will use Kubernetes 1.14 and they are unable to use a different Kubernetes version. By default, standard users don't have permission to create templates, so this template will be the only template they can use unless more templates are shared with them. @@ -29,10 +29,10 @@ In this way, the administrators enforce the Kubernetes version across the organi # Templates for Basic and Advanced Users -Let's say an organization has both basic and advanced users. Adminstrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want. +Let's say an organization has both basic and advanced users. Administrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want. 1. First, an administrator turns on [RKE template enforcement.]({{}}/rancher/v2.x/en/admin-settings/rke-templates/enforcement/#requiring-new-clusters-to-use-a-cluster-template) This means that every [standard user]({{}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) in Rancher will need to use an RKE template when they create a cluster. -1. The administrator then creates two templates: +1. The administrator then creates two templates: - One template for basic users, with almost every option specified except for access keys - One template for advanced users, which has most or all options has **Allow User Override** turned on @@ -44,7 +44,7 @@ Let's say an organization has both basic and advanced users. Adminstrators want # Updating Templates and Clusters Created with Them -Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the adminstrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes. +Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the administrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes. In this organization, many clusters were created with a template that requires Kubernetes v1.14. Because the template does not allow that setting to be overridden, the users who created the cluster cannot directly edit that setting. diff --git a/content/rancher/v2.x/en/best-practices/management/_index.md b/content/rancher/v2.x/en/best-practices/management/_index.md index 70168c3e2ad..fe7f5f75bf4 100644 --- a/content/rancher/v2.x/en/best-practices/management/_index.md +++ b/content/rancher/v2.x/en/best-practices/management/_index.md @@ -15,7 +15,7 @@ Rancher is container-based and can potentially run on any Linux-based operating ### Upgrade Your Kubernetes Version Keep your Kubernetes cluster up to date with a recent and supported version. Typically the Kubernetes community will support the current version and previous three minor releases (for example, 1.14.x, 1.13.x, 1.12.x, and 1.11.x). After a new version is released, the third-oldest supported version reaches EOL (End of Life) status. Running on an EOL release can be a risk if a security issues are found and patches are not available. The community typically makes minor releases every quarter (every three months). -Rancher’s SLA’s are not community dependent, but as Kubernetes is a community-driven software, the quality of experience will degrade as you get farther away from the community's supported target. +Rancher’s SLAs are not community dependent, but as Kubernetes is a community-driven software, the quality of experience will degrade as you get farther away from the community's supported target. ### Kill Pods Randomly During Testing Run chaoskube or a similar mechanism to randomly kill pods in your test environment. This will test the resiliency of your infrastructure and the ability of Kubernetes to self-heal. It's not recommended to run this in your production environment. @@ -26,7 +26,7 @@ Rancher's "Add Cluster" UI is preferable for getting started with Kubernetes clu Rancher [maintains a Terraform provider](https://rancher.com/blog/2019/rancher-2-terraform-provider/) for working with Rancher 2.0 Kubernetes. It is called the [Rancher2 Provider.](https://www.terraform.io/docs/providers/rancher2/index.html) ### Upgrade Rancher in a Staging Environment -All upgrades, both patch and feature upgrades, should be first tested on a staging environment before production is upgraded. The more closely the staging environment mirrors production, the higher chance your production upgrade will be successful. +All upgrades, both patch and feature upgrades, should be first tested on a staging environment before production is upgraded. The more closely the staging environment mirrors production, the higher chance your production upgrade will be successful. ### Renew Certificates Before they Expire Multiple people in your organization should set up calendar reminders for certificate renewal. Consider renewing the certificate two weeks to one month in advance. If you have multiple certificates to track, consider using [monitoring and alerting mechanisms]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/) to track certificate expiration. @@ -48,7 +48,7 @@ When installing or upgrading a non-production environment to an early release, a Make sure the feature version you are upgrading to is considered "stable" as determined by Rancher. Use the beta, release candidate, and "latest" versions in a testing, development, or demo environment to try out new features. Feature version upgrades, for example 2.1.x to 2.2.x, should be considered as and when they are released. Some bug fixes and most features are not back ported into older versions. -Keep in mind that Rancher does End of Life support for old versions, so you will eventually want to upgrade if you want to continue to receive patches. +Keep in mind that Rancher does End of Life support for old versions, so you will eventually want to upgrade if you want to continue to receive patches. For more detail on what happens during the Rancher product lifecycle, refer to the [Support Maintenance Terms](https://rancher.com/support-maintenance-terms/). @@ -99,7 +99,7 @@ In addition to Rancher software updates, closely monitor security fixes for rela # Tips for Multi-Tenant Clusters ### Namespaces -Each tenant should have their own unique namespaces within the cluster. This avoids naming conflicts and allows resources to be only visible to their owner through use of RBAC policy +Each tenant should have their own unique namespaces within the cluster. This avoids naming conflicts and allows resources to be only visible to their owner through use of RBAC policy ### Project Isolation Use Rancher's Project Isolation to automatically generate Network Policy between Projects (sets of Namespaces). This further protects workloads from interference @@ -108,18 +108,18 @@ Use Rancher's Project Isolation to automatically generate Network Policy between Enforce use of sane resource limit definitions for every deployment in your cluster. This not only protects the owners of the deployment, but the neighboring resources from other tenants as well. Remember, namespaces do not isolate at the node level, so over-consumption of resources on a node affects other namespace deployments. Admission controllers can be written to require resource limit definitions ### Resource Requirements -Enforce use of resource requirement definitions for each deployment in your cluster. This enables the scheduler to appropriately schedule workloads. Otherwise you will eventually end up with over-provisioned nodes. +Enforce use of resource requirement definitions for each deployment in your cluster. This enables the scheduler to appropriately schedule workloads. Otherwise you will eventually end up with over-provisioned nodes. # Class of Service and Kubernetes Clusters A class of service describes the expectations around cluster uptime, durability, and duration of maintenance windows. Typically organizations group these characteristics into labels such as "dev" or "prod" ### Consider fault domains -Kubernetes clusters can span multiple classes of service, however it is important to consider the ability for one workload to affect another. Without proper deployment practices such as resource limits, requirements, etc, a deployment that is not behaving well has the potential to impact the health of the cluster. In a "dev" environment it is common for end-users to exercise less caution with deployments, thus increasing the chance of such behavior. Sharing this behavior with your production workload increases risk. +Kubernetes clusters can span multiple classes of service, however it is important to consider the ability for one workload to affect another. Without proper deployment practices such as resource limits, requirements, etc, a deployment that is not behaving well has the potential to impact the health of the cluster. In a "dev" environment it is common for end-users to exercise less caution with deployments, thus increasing the chance of such behavior. Sharing this behavior with your production workload increases risk. ### Upgrade risks -Upgrades of Kuberentes are not without risk, the best way to predict the outcome of an upgrade is try it on a cluster of similar load and use case as your production cluster. This is where having non-prod class of service clusters can be advantageous. +Upgrades of Kubernetes are not without risk, the best way to predict the outcome of an upgrade is try it on a cluster of similar load and use case as your production cluster. This is where having non-prod class of service clusters can be advantageous. -### Resource Efficiency +### Resource Efficiency Clusters can be built with varying degrees of redundancy. In a class of service with low expectations for uptime, resources and cost can be conserved by building clusters without redundant Kubernetes control components. This approach may also free up more budget/resources to increase the redundancy at the production level # Network Security diff --git a/content/rancher/v2.x/en/catalog/globaldns/_index.md b/content/rancher/v2.x/en/catalog/globaldns/_index.md index 21a7b84a57d..783a1dcf843 100644 --- a/content/rancher/v2.x/en/catalog/globaldns/_index.md +++ b/content/rancher/v2.x/en/catalog/globaldns/_index.md @@ -35,7 +35,7 @@ By default, only [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-s 1. From the **Global View**, select **Tools > Global DNS Providers**. 1. To add a provider, choose from the available provider options and configure the Global DNS Provider with necessary credentials and an optional domain. -1. (Optional) Add additional users so they could use the provider when creating Globel DNS entries as well as manage the Global DNS provider. +1. (Optional) Add additional users so they could use the provider when creating Global DNS entries as well as manage the Global DNS provider. {{% accordion id="route53" label="Route53" %}} 1. Enter a **Name** for the provider. @@ -81,7 +81,7 @@ By default, only [global administrators]({{< baseurl >}}/rancher/v2.x/en/admin-s In order for Global DNS entries to be programmed, you will need to add a specific annotation on an ingress in your application or target project and this ingress needs to use a specific `hostname` and an annotation that should match the FQDN of the Global DNS entry. -1. For any application that you want targetted for your Global DNS entry, find an ingress associated with the application. +1. For any application that you want targeted for your Global DNS entry, find an ingress associated with the application. 1. In order for the DNS to be programmed, the following requirements must be met: * The ingress routing rule must be set to use a `hostname` that matches the FQDN of the Global DNS entry. * The ingress must have an annotation (`rancher.io/globalDNS.hostname`) and the value of this annotation should match the FQDN of the Global DNS entry. diff --git a/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md b/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md index 62936ccb55a..f40b0e593c7 100644 --- a/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md +++ b/content/rancher/v2.x/en/catalog/multi-cluster-apps/_index.md @@ -18,7 +18,7 @@ After creating a multi-cluster application, you can program a [Global DNS entry] 3. (Optional) Review the detailed descriptions, which are derived from the Helm chart's `README`. -4. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `-`. +4. Under **Configuration Options** enter a **Name** for the multi-cluster application. By default, this name is also used to create a Kubernetes namespace in each [target project](#targets) for the multi-cluster application. The namespace is named as `-`. 5. Select a **Template Version**. @@ -50,13 +50,13 @@ In the **Upgrades** section, select the upgrade strategy to use, when you decide #### Roles -In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#launching-catalog-applications), that specific users's permissions are used for creation of all workloads/resources that is required by the app. +In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/#launching-catalog-applications), that specific user's permissions are used for creation of all workloads/resources that is required by the app. For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects. Rancher will let you select from two options for Roles, **Project** and **Cluster**. Rancher will allow creation using any of these roles based on the user's permissions. -- **Project** - This is the equivalent of a [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or a [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles), then the user is considered to have the appropriate level of permissions. +- **Project** - This is the equivalent of a [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [project member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _project member_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or a [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles), then the user is considered to have the appropriate level of permissions. - **Cluster** - This is the equivalent of a [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles). If you select this role, Rancher will check that in all the target projects, the user has minimally the [cluster owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) role. While the user might not be explicitly granted the _cluster owner_ role, if the user is an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), then the user is considered to have the appropriate level of permissions. @@ -68,7 +68,7 @@ When launching the application, Rancher will confirm if you have these permissio For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://github.com/helm/helm/blob/master/docs/using_helm.md#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm. -> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is reuired to wrap the values with double quotes (i.e., ``"abc, bcd"``). +> For example, when entering an answer that includes two values separated by a comma (i.e. `abc, bcd`), it is required to wrap the values with double quotes (i.e., ``"abc, bcd"``). #### Using a `questions.yml` file @@ -84,7 +84,7 @@ By default, multi-cluster applications can only be managed by the user who creat 1. Find the user that you want to add by typing in the member's name in the **Member** search box. -2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean. +2. Select the **Access Type** for that member. There are three access types for a multi-cluster project, but due to how the permissions of a multi-cluster application are launched, please read carefully to understand what these access types mean. - **Owner**: This access type can manage any configuration part of the multi-cluster application including the template version, the [multi-cluster applications specific configuration options](#configuration-options-to-make-a-multi-cluster-app), the [application specific configuration options](#application-configuration-options), the [members who can interact with the multi-cluster application](#members) and the [custom application configuration answers](#overriding-application-configuration-options-for-specific-projects). Since a multi-cluster application is created with a different set of permissions from the user, any _owner_ of the multi-cluster application can manage/remove applications in [target projects](#targets) without explicitly having access to these project(s). Only trusted users should be provided with this access type. @@ -108,7 +108,7 @@ The ability to use the same configuration to deploy the same application across - **Answer**: Enter the answer that you want to be used instead. -## Upgrading Multi-Cluster App Roles and Projects +## Upgrading Multi-Cluster App Roles and Projects - **Changing Roles on an existing Multi-Cluster app** The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`. @@ -120,7 +120,7 @@ The creator and any users added with the access-type "owner" to a multi-cluster ## Multi-Cluster Application Management -One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of manangement.Multi-cluster applications can be cloned, upgraded or rolled back. +One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back. 1. From the **Global** view, choose **Apps** in the navigation bar. diff --git a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md index 02f7324204d..e4aa716ccbb 100644 --- a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md @@ -7,7 +7,7 @@ _Available as of v2.2.0_ In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster. -Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additonally, one-time snapshots can easily be taken as well. +Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additionally, one-time snapshots can easily be taken as well. >**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/). @@ -55,7 +55,7 @@ By default, the `local` backup target is selected. The benefits of this option i _Available as of v2.3.0_ -As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatiable file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced. +As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatible file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced. >>**Note:** This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface. diff --git a/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md index b8deacf998d..249ec5baa6f 100644 --- a/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cluster-access/kubectl/_index.md @@ -1,6 +1,6 @@ --- title: "Access a Cluster with Kubectl Shell or Kubectl CLI" -description: "Lean how you can access and manage your Kubernetes clusters using kubectl in two ways: with kubectl Shell or with kubectl CLI and kuberconfig file" +description: "Lean how you can access and manage your Kubernetes clusters using kubectl in two ways: with kubectl Shell or with kubectl CLI and kubeconfig file" weight: 2015 aliases: - /rancher/v2.x/en/tasks/clusters/using-kubectl-to-access-a-cluster/ diff --git a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md index a47f7349041..371303c96c9 100644 --- a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md @@ -20,7 +20,7 @@ In terms of hierarchy: You can use projects to support multi-tenancy, so that a team can access a project within a cluster without having access to other projects in the same cluster. -In the base version of Kubernetes, features like role-based access rights or cluster resources are assigned to individual namespaces. A project allows you to save time by giving an individual or a team acess to multiple namespaces simultaneously. +In the base version of Kubernetes, features like role-based access rights or cluster resources are assigned to individual namespaces. A project allows you to save time by giving an individual or a team access to multiple namespaces simultaneously. You can use projects to perform actions like: diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md index 78a59a98735..71313bc816f 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/_index.md @@ -30,7 +30,7 @@ Rancher's Istio integration comes with comprehensive visualization aids: - **Trace the root cause of errors with Jaeger.** [Jaeger](https://www.jaegertracing.io/) is an open-source tool that provides a UI for a distributed tracing system, which is useful for root cause analysis and for determining what causes poor performance. Distributed tracing allows you to view an entire chain of calls, which might originate with a user request and traverse dozens of microservices. - **Get the full picture of your microservice architecture with Kiali.** [Kiali](https://www.kiali.io/) provides a diagram that shows the services within a service mesh and how they are connected, including the traffic rates and latencies between them. You can check the health of the service mesh, or drill down to see the incoming and outgoing requests to a single component. - **Gain insights from time series analytics with Grafana dashboards.** [Grafana](https://grafana.com/) is an analytics platform that allows you to query, visualize, alert on and understand the data gathered by Prometheus. -- **Write custom queries for time series data with the Promethus UI.** [Prometheus](https://prometheus.io/) is a systems monitoring and alerting toolkit. Prometheus scrapes data from your cluster, which is then used by Grafana. A Prometheus UI is also integrated into Rancher, and lets you write custom queries for time series data and see the results in the UI. +- **Write custom queries for time series data with the Prometheus UI.** [Prometheus](https://prometheus.io/) is a systems monitoring and alerting toolkit. Prometheus scrapes data from your cluster, which is then used by Grafana. A Prometheus UI is also integrated into Rancher, and lets you write custom queries for time series data and see the results in the UI. # Prerequisites @@ -42,7 +42,7 @@ Refer to the [setup guide]({{}}/rancher/v2.x/en/cluster-admin/tools/ist # Disabling Istio -To remove Istio components from a cluster, namepace, or workload, refer to the section on [disabling Istio.]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/disabling-istio) +To remove Istio components from a cluster, namespace, or workload, refer to the section on [disabling Istio.]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/disabling-istio) # Accessing Visualizations diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md index 69d8aabeb78..eb6f3c20fa7 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md @@ -7,7 +7,7 @@ This section describes the permissions required to access Istio features and how # Cluster-level Access -By default, only cluster adminstrators can: +By default, only cluster administrators can: - Enable Istio for the cluster - Configure resource allocations for Istio @@ -33,7 +33,7 @@ By default, the Kiali and Jaeger visualizations are restricted to the cluster o Rancher supports giving groups permission to access Kiali and Jaeger, but not individuals. -To configure who has permission to access the Kiali and Jaeger UI, +To configure who has permission to access the Kiali and Jaeger UI, 1. Go to the cluster view and click **Tools > Istio.** 1. Then go to the **Member Access** section. If you want to restrict access to certain groups, choose **Allow cluster owner and specified members to access Kiali and Jaeger UI.** Search for the groups that you want to have access to Kiali and Jaeger. If you want all members to have access to the tools, click **Allow all members to access Kiali and Jaeger UI.** diff --git a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md index e2c8b9f5054..b3d85b3b438 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/logging/_index.md @@ -14,7 +14,7 @@ Logging is helpful because it allows you to: - Look for trends in your environment - Save your logs to a safe location outside of your cluster - Stay informed of events like a container crashing, a pod eviction, or a node dying -- More easily debugg and troubleshoot problems +- More easily debug and troubleshoot problems Rancher supports integration with the following services: @@ -100,7 +100,7 @@ As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global ``` openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com" ``` - 2. If you are using a self-signed certificate, provide the **CA Certificate PEM**. + 2. If you are using a self-signed certificate, provide the **CA Certificate PEM**. 1. (Optional) Complete the **Additional Logging Configuration** form. diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md index 4eb7a29e020..ede960e2578 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/_index.md @@ -1,6 +1,6 @@ --- title: Integrating Rancher and Prometheus for Cluster Monitoring -description: Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Lern about the scope of monitoring and how to enable cluster monitoring +description: Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Learn about the scope of monitoring and how to enable cluster monitoring weight: 4 --- @@ -27,7 +27,7 @@ You can configure these services to collect logs at either the cluster level or In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. -By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. +By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster-only and project-only Prometheus instances are also supported. diff --git a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md index 4b52c207fae..a667264c69c 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/monitoring/expression/_index.md @@ -238,8 +238,8 @@ weight: 4 | Catalog | Expression | | --- | --- | - | Detail |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`
accpeted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`
| - | Summary |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`
accpeted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`
| + | Detail |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"}) by (instance)`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"}) by (instance)`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"}) by (instance)`
accepted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m]))) by (instance)`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m]))) by (instance)`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m]))) by (instance)`
| + | Summary |
reading`sum(nginx_ingress_controller_nginx_process_connections{state="reading"})`
waiting`sum(nginx_ingress_controller_nginx_process_connections{state="waiting"})`
writing`sum(nginx_ingress_controller_nginx_process_connections{state="writing"})`
accepted`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="accepted"}[5m])))`
active`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="active"}[5m])))`
handled`sum(ceil(increase(nginx_ingress_controller_nginx_process_connections_total{state="handled"}[5m])))`
| - **Ingress Controller Request Process Time** diff --git a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md index f37822b1eb9..59de651d0e6 100644 --- a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/_index.md @@ -1,6 +1,6 @@ --- title: "Kubernetes Persistent Storage: Volumes and Storage Classes" -description: "Learn about the two ways with which you can creat persistent storage in Kubernetes: persistent volumes and storage classes" +description: "Learn about the two ways with which you can create persistent storage in Kubernetes: persistent volumes and storage classes" weight: 2031 aliases: - /rancher/v2.x/en/concepts/volumes-and-storage/ diff --git a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md index 4f811564629..54a0fdf1d8b 100644 --- a/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/volumes-and-storage/examples/vsphere/_index.md @@ -42,7 +42,7 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub 7. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`. 8. Click **Launch** to create the workload. -### Verifing Persistence of the Volume +### Verifying Persistence of the Volume 1. From the context menu of the workload you just created, click **Execute Shell**. 2. Note the directory at root where the volume has been mounted to (in this case `/persistent`). @@ -50,7 +50,7 @@ In order to provision vSphere volumes in a cluster created with the [Rancher Kub 4. **Close** the shell window. 5. Click on the name of the workload to reveal detail information. 6. Open the context menu next to the Pod in the *Running* state. -7. Delete the Pod by selecting **Delete**. +7. Delete the Pod by selecting **Delete**. 8. Observe that the pod is deleted. Then a new pod is scheduled to replace it so that the workload maintains its configured scale of a single stateful pod. 9. Once the replacement pod is running, click **Execute Shell**. 10. Inspect the contents of the directory where the volume is mounted by entering `ls -l /`. Note that the file you created earlier is still present. diff --git a/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md b/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md index 05099d44c3d..4b9ddbd3c50 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/node-requirements/_index.md @@ -23,9 +23,9 @@ Rancher works has been tested and is supported with downstream clusters running All supported operating systems are 64-bit x86. -If you plan to use ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/options/arm64-platform/) +If you plan to use ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/options/arm64-platform/) -For information on how to install Docker, refer to the offical [Docker documentation.](https://docs.docker.com/) +For information on how to install Docker, refer to the official [Docker documentation.](https://docs.docker.com/) > **Note:** Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. This [how-to guide]({{}}/rancher/v2.x/en/installation/options/firewall) shows how to check the default firewall rules and how to open the ports with `firewalld` if necessary. @@ -41,7 +41,7 @@ Windows nodes can be used for worker nodes only. See [Configuring Custom Cluster The hardware requirements for nodes with the `worker` role mostly depend on your workloads. The minimum to run the Kubernetes node components is 1 CPU (core) and 1GB of memory. -Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controplane, and workers) should be hosted on different nodes so that they can scale separately from each other. +Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controlplane, and workers) should be hosted on different nodes so that they can scale separately from each other. For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters.](https://kubernetes.io/docs/setup/best-practices/cluster-large/) @@ -106,7 +106,7 @@ The following table depicts the port requirements for [Rancher Launched Kubernet ### Port Requirements for Clusters Hosted by an Infrastructure Provider -If you are launching a Kubernetes cluster on nodes that are in an infastructure provider such as Amazon EC2, Google Container Engine, DigitalOcean, Azure, or vSphere, these port requirements apply. +If you are launching a Kubernetes cluster on nodes that are in an infrastructure provider such as Amazon EC2, Google Container Engine, DigitalOcean, Azure, or vSphere, these port requirements apply. These required ports are automatically opened by Rancher during creation of clusters using cloud providers. diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md index 1f32b1e6bd9..c702095a959 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ec2/_index.md @@ -14,7 +14,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. - IAM Policy created to add to the user of the Access Key And Secret Key. See [Amazon Documentation: Creating IAM Policies (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-start) how to create an IAM policy. See our three example JSON policies below: - [Example IAM Policy](#example-iam-policy) - [Example IAM Policy with PassRole](#example-iam-policy-with-passrole) (needed if you want to use [Kubernetes Cloud Provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) or want to pass an IAM Profile to an instance) - - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes) + - [Example IAM Policy to allow encrypted EBS volumes](#example-iam-policy-to-allow-encrypted-ebs-volumes) - IAM Policy added as Permission to the user. See [Amazon Documentation: Adding Permissions to a User (Console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) how to attach it to an user. @@ -36,7 +36,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2. 1. Complete each of the following forms using information available from the [EC2 Management Console](https://aws.amazon.com/ec2). - - **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisistes](#prerequisites) how to create the Access Key and Secret Key and the needed permissions. + - **Account Access** is where you configure the region of the nodes, and the credentials (Access Key and Secret Key) used to create the machine. See [Prerequisites](#prerequisites) how to create the Access Key and Secret Key and the needed permissions. {{< step_create-cloud-credential >}} diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md index 89629d989da..cbe4677d4d3 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md @@ -1,7 +1,7 @@ --- title: Cluster Options weight: 2250 ---- +--- As you configure a new cluster that's provisioned using [RKE]({{< baseurl >}}/rke/latest/en/), you can choose custom Kubernetes options. @@ -60,7 +60,7 @@ _Available as of v2.2.0_ The registry configuration here is applied during the provisioning of the cluster. This option tells Rancher where to pull the [system images]({{}}/rke/latest/en/config-options/system-images/) or [addon images.]({{}}/rke/latest/en/config-options/add-ons/) -- **System images** are components needed to maintain the Kubernetes cluster. +- **System images** are components needed to maintain the Kubernetes cluster. - **Add-ons** are used to deploy several cluster components, including network plug-ins, the ingress controller, the DNS provider, or the metrics server. To deploy workloads that pull images from a private registry, you will need to set up your own Kubernetes registry for your project. @@ -109,7 +109,7 @@ If the nodes you are adding to the cluster have Docker configured with a non-def #### Recurring etcd Snapshots -Option to enable or disable [recurring etcd snaphots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots). +Option to enable or disable [recurring etcd snapshots]({{< baseurl >}}/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots). ## Config File @@ -131,63 +131,63 @@ RKE (Rancher Kubernetes Engine) is the tool that Rancher uses to provision Kuber {{% accordion id="v2.3.0-cluster-config-file" label="Example Cluster Config File for Rancher v2.3.0+" %}} ```yaml -# +# # Cluster Config -# +# docker_root_dir: /var/lib/docker enable_cluster_alerting: false enable_cluster_monitoring: false enable_network_policy: false local_cluster_auth_endpoint: enabled: true -# +# # Rancher Config -# +# rancher_kubernetes_engine_config: # Your RKE template config goes here. addon_job_timeout: 30 authentication: strategy: x509 ignore_docker_version: true -# +# # # Currently only nginx ingress provider is supported. # # To disable ingress controller, set `provider: none` # # To enable ingress on specific nodes, use the node_selector, eg: # provider: nginx # node_selector: # app: ingress -# +# ingress: provider: nginx kubernetes_version: v1.15.3-rancher3-1 monitoring: provider: metrics-server -# +# # If you are using calico on AWS -# +# # network: # plugin: calico # calico_network_provider: # cloud_provider: aws -# +# # # To specify flannel interface -# +# # network: # plugin: flannel # flannel_network_provider: # iface: eth1 -# +# # # To specify flannel interface for canal plugin -# +# # network: # plugin: canal # canal_network_provider: # iface: eth1 -# +# network: options: flannel_backend_type: vxlan plugin: canal -# +# # services: # kube-api: # service_cluster_ip_range: 10.43.0.0/16 @@ -197,7 +197,7 @@ rancher_kubernetes_engine_config: # Your RKE template config goes here. # kubelet: # cluster_domain: cluster.local # cluster_dns_server: 10.43.0.10 -# +# services: etcd: backup_config: @@ -232,46 +232,46 @@ addon_job_timeout: 30 authentication: strategy: x509 ignore_docker_version: true -# +# # # Currently only nginx ingress provider is supported. # # To disable ingress controller, set `provider: none` # # To enable ingress on specific nodes, use the node_selector, eg: # provider: nginx # node_selector: # app: ingress -# +# ingress: provider: nginx kubernetes_version: v1.15.3-rancher3-1 monitoring: provider: metrics-server -# +# # If you are using calico on AWS -# +# # network: # plugin: calico # calico_network_provider: # cloud_provider: aws -# +# # # To specify flannel interface -# +# # network: # plugin: flannel # flannel_network_provider: # iface: eth1 -# +# # # To specify flannel interface for canal plugin -# +# # network: # plugin: canal # canal_network_provider: # iface: eth1 -# +# network: options: flannel_backend_type: vxlan plugin: canal -# +# # services: # kube-api: # service_cluster_ip_range: 10.43.0.0/16 @@ -281,7 +281,7 @@ network: # kubelet: # cluster_domain: cluster.local # cluster_dns_server: 10.43.0.10 -# +# services: etcd: backup_config: diff --git a/content/rancher/v2.x/en/contributing/_index.md b/content/rancher/v2.x/en/contributing/_index.md index 857f81ef92c..ea8273a830b 100644 --- a/content/rancher/v2.x/en/contributing/_index.md +++ b/content/rancher/v2.x/en/contributing/_index.md @@ -5,7 +5,7 @@ aliases: - /rancher/v2.x/en/faq/contributing/ --- -This section explains the respositories used for Rancher, how to build the repositories, and what information to include when you file an issue. +This section explains the repositories used for Rancher, how to build the repositories, and what information to include when you file an issue. For more detailed information on how to contribute to the development of Rancher projects, refer to the [Rancher Developer Wiki](https://github.com/rancher/rancher/wiki). The wiki has resources on many topics, including the following: diff --git a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md index 28b7f587576..76b489cb64f 100644 --- a/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md +++ b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md @@ -127,7 +127,7 @@ The following table summarizes the different features available for each CNI net - External Datastore: CNI network providers with this feature need an external datastore for its data. -- Encyption: This feature allows cyphered and secure network control and data planes. +- Encryption: This feature allows cyphered and secure network control and data planes. - Ingress/Egress Policies: This feature allows you to manage routing control for both Kubernetes and non-Kubernetes communications. diff --git a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md index 928b4a8fc57..8fbca33a814 100644 --- a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md +++ b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nginx/_index.md @@ -22,7 +22,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx. 1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`. -2. From `nginx.conf`, replace both occurences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/). +2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/). > **Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options. diff --git a/content/rancher/v2.x/en/installation/how-ha-works/_index.md b/content/rancher/v2.x/en/installation/how-ha-works/_index.md index 739506c6404..f88defc3682 100644 --- a/content/rancher/v2.x/en/installation/how-ha-works/_index.md +++ b/content/rancher/v2.x/en/installation/how-ha-works/_index.md @@ -3,7 +3,7 @@ title: About High-availability Installations weight: 2 --- -We recommend using [Helm,]({{}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased avaialability is achieved by running Rancher on multiple nodes. +We recommend using [Helm,]({{}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased availability is achieved by running Rancher on multiple nodes. In a typical HA Rancher installation, Kubernetes is first installed on three nodes that are hosted in an infrastructure provider such as Amazon's EC2 or Google Compute Engine. diff --git a/content/rancher/v2.x/en/installation/options/chart-options/_index.md b/content/rancher/v2.x/en/installation/options/chart-options/_index.md index db92df57800..3e3e477a56e 100644 --- a/content/rancher/v2.x/en/installation/options/chart-options/_index.md +++ b/content/rancher/v2.x/en/installation/options/chart-options/_index.md @@ -192,7 +192,7 @@ This NGINX configuration is tested on NGINX 1.14. > **Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). - Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster. -- Replace both occurences of `FQDN` to the DNS name for Rancher. +- Replace both occurrences of `FQDN` to the DNS name for Rancher. - Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively. ``` diff --git a/content/rancher/v2.x/en/installation/options/etcd/_index.md b/content/rancher/v2.x/en/installation/options/etcd/_index.md index 3746064e844..dfe02cabb98 100644 --- a/content/rancher/v2.x/en/installation/options/etcd/_index.md +++ b/content/rancher/v2.x/en/installation/options/etcd/_index.md @@ -25,7 +25,7 @@ You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3. Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS. -To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etc/wal` directories will need to have disks mounted and formmated on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions. +To implement this solution in an RKE cluster, the `/var/lib/etcd/data` and `/var/lib/etc/wal` directories will need to have disks mounted and formatted on the underlying host. In the `extra_args` directive of the `etcd` service, you must include the `wal_dir` directory. Without specifying the `wal_dir`, etcd process will try to manipulate the underlying `wal` mount with insufficient permissions. ```yaml # RKE cluster.yml diff --git a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md index ad5b37792c3..631dc196339 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/nginx/_index.md @@ -21,7 +21,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx. 1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`. -2. From `nginx.conf`, replace both occurences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/). +2. From `nginx.conf`, replace both occurrences (port 80 and port 443) of ``, ``, and `` with the IPs of your [nodes]({{< baseurl >}}/rancher/v2.x/en/installation/options/helm2/create-nodes-lb/). >**Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options. diff --git a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md index ae2c449dcb3..b7aed0238dc 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/helm-rancher/chart-options/_index.md @@ -192,7 +192,7 @@ This NGINX configuration is tested on NGINX 1.14. >**Note:** This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). * Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster. -* Replace both occurences of `FQDN` to the DNS name for Rancher. +* Replace both occurrences of `FQDN` to the DNS name for Rancher. * Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively. ``` diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md index 66c0f330213..9eeb325d616 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-4-lb/_index.md @@ -210,7 +210,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -392,7 +392,7 @@ During installation, RKE automatically generates a config file named `kube_confi You have a couple of options: -- Create a backup of your Rancher Server in case of a disaster scenario: [High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). +- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). - Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
diff --git a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md index dca03867288..1ada737e358 100644 --- a/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/helm2/rke-add-on/layer-7-lb/_index.md @@ -134,7 +134,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`. >**Note:** - > + > >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements. nodes: @@ -159,7 +159,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -278,7 +278,7 @@ During installation, RKE automatically generates a config file named `kube_confi ## What's Next? -- **Recommended:** Review [Creating Backups—High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. +- **Recommended:** Review [Creating Backups—High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. - Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md index 290be87b9e9..222ee65542e 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-4-lb/_index.md @@ -211,7 +211,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -393,7 +393,7 @@ During installation, RKE automatically generates a config file named `kube_confi You have a couple of options: -- Create a backup of your Rancher Server in case of a disaster scenario: [High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). +- Create a backup of your Rancher Server in case of a disaster scenario: [High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration). - Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
diff --git a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md index 7502a60584f..1d53224c6df 100644 --- a/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md +++ b/content/rancher/v2.x/en/installation/options/rke-add-on/layer-7-lb/_index.md @@ -135,7 +135,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`. The specified user should be able to access the Docket socket, you can test this by logging in with the specified user and run `docker ps`. >**Note:** - > + > >When using RHEL/CentOS, the SSH user can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565. See [Operating System Requirements]({{< baseurl >}}/rke/latest/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements. nodes: @@ -160,7 +160,7 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec services: etcd: - backup: false + backup: false ## 7. Configure Certificates @@ -279,7 +279,7 @@ During installation, RKE automatically generates a config file named `kube_confi ## What's Next? -- **Recommended:** Review [Creating Backups—High Availablility Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. +- **Recommended:** Review [Creating Backups—High Availability Back Up and Restoration]({{< baseurl >}}/rancher/v2.x/en/backups/backups/ha-backups/) to learn how to backup your Rancher Server in case of a disaster scenario. - Create a Kubernetes cluster: [Creating a Cluster]({{< baseurl >}}/rancher/v2.x/en/tasks/clusters/creating-a-cluster/).
diff --git a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md index 69ad051a38e..622eea8c319 100644 --- a/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md +++ b/content/rancher/v2.x/en/installation/options/upgrading-cert-manager/_index.md @@ -11,7 +11,7 @@ Rancher uses cert-manager to automatically generate and renew TLS certificates f To address these changes, this guide will do two things: 1. Document the procedure for upgrading cert-manager -1. Explain the cert-manager API changes and link to cert-manager's offficial documentation for migrating your data +1. Explain the cert-manager API changes and link to cert-manager's official documentation for migrating your data ## Performing the upgrade diff --git a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md index 76fca429f83..bc79b50ad59 100644 --- a/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md +++ b/content/rancher/v2.x/en/installation/other-installation-methods/single-node/single-node-install-external-lb/_index.md @@ -106,7 +106,7 @@ This NGINX configuration is tested on NGINX 1.14. > **Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/). - Replace `rancher-server` with the IP address or hostname of the node running the Rancher container. -- Replace both occurences of `FQDN` to the DNS name for Rancher. +- Replace both occurrences of `FQDN` to the DNS name for Rancher. - Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively. ``` diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index 64c9043fca7..9cc63f86b67 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -40,7 +40,7 @@ If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).]({{}}/rancher/v2.x/en/installation/requirements/installing-docker) to install Docker with one command. +Docker can be installed by following the steps in the official [Docker documentation.](https://docs.docker.com/) Rancher also provides [scripts]({{}}/rancher/v2.x/en/installation/requirements/installing-docker) to install Docker with one command. # Hardware Requirements diff --git a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md index b2d81be4bd7..8e3670d145f 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/certificates/_index.md @@ -32,7 +32,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c 1. From **Certificate**, either copy and paste your certificate into the text box (include the header and footer), or click **Read from a file** to browse to the certificate on your file system. If possible, we recommend using **Read from a file** to reduce likelihood of error. - Certifcate files end with an extension of `.crt`. + Certificate files end with an extension of `.crt`. **Result:** Your certificate is added to the project or namespace. You can now add it to deployments. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md index d0c7e6cdb9e..5a3af016138 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/manage-hpa-with-rancher-ui/_index.md @@ -50,6 +50,6 @@ If you want to create HPAs that scale based on other metrics than CPU and memory 1. Click **Ellipsis (...) > Delete**. -1. Click **Delete** to confim. +1. Click **Delete** to confirm. > **Result:** The HPA is deleted from the current cluster. \ No newline at end of file diff --git a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md index 70e11daac47..cb49344658d 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/_index.md @@ -60,7 +60,7 @@ spec: selector: app: hello-world ``` -{{% /accordion %}} +{{% /accordion %}} 1. Deploy it to your cluster. @@ -222,14 +222,14 @@ Use your load testing tool to scale up to two pods based on CPU Usage. # kubectl get pods ``` You should receive output similar to what follows: - ``` + ``` NAME READY STATUS RESTARTS AGE hello-world-54764dfbf8-k8ph2 1/1 Running 0 1m hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h ``` {{% /accordion %}} {{% accordion id="observe-upscale-3-pods-cpu-cooldown" label="Upscale to 3 pods: CPU Usage Up to Target" %}} -Use your load testing tool to upspace to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes. +Use your load testing tool to upscale to 3 pods based on CPU usage with `horizontal-pod-autoscaler-upscale-delay` set to 3 minutes. 1. Enter the following command. ``` @@ -312,7 +312,7 @@ Use your load testing to scale down to 1 pod when all metrics are below target f Use your load testing tool to upscale two pods based on CPU usage. 1. Enter the following command. - ``` + ``` # kubectl describe hpa ``` You should receive output similar to what follows. @@ -345,7 +345,7 @@ Use your load testing tool to upscale two pods based on CPU usage. # kubectl get pods ``` You should receive output similar to what follows. - ``` + ``` NAME READY STATUS RESTARTS AGE hello-world-54764dfbf8-5pfdr 1/1 Running 0 3s hello-world-54764dfbf8-q6l82 1/1 Running 0 6h @@ -387,7 +387,7 @@ Use your load testing tool to scale up to three pods when the cpu_system usage l 1. Enter the following command to confirm three pods are running. ``` # kubectl get pods - ``` + ``` You should receive output similar to what follows: ``` # kubectl get pods @@ -443,7 +443,7 @@ Use your load testing tool to upscale to four pods based on CPU usage. `horizont hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s hello-world-54764dfbf8-q6l82 1/1 Running 0 6h ``` -{{% /accordion %}} +{{% /accordion %}} {{% accordion id="custom-metrics-observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}} Use your load testing tool to scale down to one pod when all metrics below target for `horizontal-pod-autoscaler-downscale-delay`. @@ -484,8 +484,8 @@ Use your load testing tool to scale down to one pod when all metrics below targe # kubectl get pods ``` You should receive output similar to what follows. - ``` + ``` NAME READY STATUS RESTARTS AGE hello-world-54764dfbf8-q6l82 1/1 Running 0 6h - ``` + ``` {{% /accordion %}} \ No newline at end of file diff --git a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md index 409d2b64b60..d90fc336f02 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md @@ -73,7 +73,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an 1. Enter the **Host** using encrypted communication. - 1. To add additional hosts that use the certitificate, click **Add Hosts**. + 1. To add additional hosts that use the certificate, click **Add Hosts**. 1. **Optional:** Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your ingress. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md index 0efcd6c9095..7c6071500ed 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md @@ -11,7 +11,7 @@ aliases: >- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1. >- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x). -Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments. +Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments. If you can access a project, you can enable repositories to start building pipelines. Only an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can authorize version control providers. @@ -99,7 +99,7 @@ If you haven't added any stages, click **Configure pipeline for this branch** to {{% /tab %}} {{% tab "By YAML" %}}
-For each stage, you can add multiple steps. Read more about each [step type](#step-types) and the [advanced options](#advanced-options) to get all thhe details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage. +For each stage, you can add multiple steps. Read more about each [step type](#step-types) and the [advanced options](#advanced-options) to get all the details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage. ```yaml # example @@ -145,7 +145,7 @@ _Available as of v2.2.0_ 1. Select the conditions for the notification. You can select to get a notification for the following statuses: `Failed`, `Success`, `Changed`. For example, if you want to receive notifications when an execution fails, select **Failed**. -1. If you don't have any existing [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers), Rancher will provide a warning that no notifers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button. +1. If you don't have any existing [notifiers]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers), Rancher will provide a warning that no notifiers are set up and provide a link to be able to go to the notifiers page. Follow the [instructions]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers) to add a notifier. If you already have notifiers, you can add them to the notification by clicking the **Add Recipient** button. > **Note:** Notifiers are configured at a cluster level and require a different level of permissions. @@ -163,7 +163,7 @@ In the `notification` section, you will provide the following information: * **Notifier:** The ID of the notifier. This can be found by finding the notifier and selecting **View in API** to get the ID. * **Recipient:** Depending on the type of the notifier, the "default recipient" can be used or you can override this with a different recipient. For example, when configuring a slack notifier, you select a channel as your default recipient, but if you wanted to send notifications to a different channel, you can select a different recipient. * **Condition:** Select which conditions of when you want the notification to be sent. -* **Message (Optional):** If you want to change the default notification message, you can edit this in the yaml. Note: This option is not available in the UI. +* **Message (Optional):** If you want to change the default notification message, you can edit this in the yaml. Note: This option is not available in the UI. ```yaml # Example @@ -181,7 +181,7 @@ notification: notifier: "c-wdcsr:n-c9pg7" - recipient: "test@example.com" notifier: "c-wdcsr:n-lkrhd" - # Select which statuses you want the notification to be sent + # Select which statuses you want the notification to be sent condition: ["Failed", "Success", "Changed"] # Ability to override the default message (Optional) message: "my-message" @@ -309,7 +309,7 @@ stages:
{{% /tab %}} -{{% /tabs %}} +{{% /tabs %}} ### Build and Publish Images @@ -413,7 +413,7 @@ Under the `steps` section, add a step with `publishCatalogConfig`. You will prov * GitBranch: The git branch of the chart repository that the template will be published to. * GitAuthor: The author name used in the commit message. * GitEmail: The author email used in the commit message. -* Credentials: You should provide Git credentials by referencing secrets in dedicated pipeline namespace. If you publish via SSH protocol, inject your deploy key to the `DEPLOY_KEY` environment variable. If you publish via HTTP(S) protolcol, inject your username and password to `USERNAME` and `PASSWORD` environment variables. +* Credentials: You should provide Git credentials by referencing secrets in dedicated pipeline namespace. If you publish via SSH protocol, inject your deploy key to the `DEPLOY_KEY` environment variable. If you publish via HTTP(S) protocol, inject your username and password to `USERNAME` and `PASSWORD` environment variables. ```yaml # example @@ -467,7 +467,7 @@ stages:
{{% /tab %}} -{{% /tabs %}} +{{% /tabs %}} ### Deploy Catalog App @@ -563,7 +563,7 @@ Wildcard character (`*`) expansion is supported in `branch` conditions. 1. Click **Add Rule**. In the **Value** field, enter the name of the branch that triggers the pipeline. - 1. **Optional:** Add more branches that trigger a build. + 1. **Optional:** Add more branches that trigger a build. 1. Click **Done.** @@ -581,7 +581,7 @@ Wildcard character (`*`) expansion is supported in `branch` conditions. 1. In the **Trigger Rules** section, configure rules to run or skip the stage. - 1. Click **Add Rule**. + 1. Click **Add Rule**. 1. Choose the **Type** that triggers the stage and enter a value. @@ -606,7 +606,7 @@ Wildcard character (`*`) expansion is supported in `branch` conditions. 1. In the **Trigger Rules** section, configure rules to run or skip the step. - 1. Click **Add Rule**. + 1. Click **Add Rule**. 1. Choose the **Type** that triggers the step and enter a value. @@ -660,7 +660,7 @@ When configuring a pipeline, certain [step types](#step-types) allow you to use 1. Within one of the stages, find the **step** that you want to add an environment variable for, click the **Edit** icon. -1. Click **Show advanced options**. +1. Click **Show advanced options**. 1. Click **Add Variable**, and then enter a key and value in the fields that appear. Add more variables if needed. @@ -709,7 +709,7 @@ Create a secret in the same project as your pipeline, or explicitly in the names 1. Within one of the stages, find the **step** that you want to use a secret for, click the **Edit** icon. -1. Click **Show advanced options**. +1. Click **Show advanced options**. 1. Click **Add From Secret**. Select the secret file that you want to use. Then choose a key. Optionally, you can enter an alias for the key. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md index a10bcea6ebd..4be9cd00eaf 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/rollback-workloads/_index.md @@ -9,7 +9,7 @@ Sometimes there is a need to rollback to the previous version of the application 1. From the **Global** view, open the project running the workload you want to rollback. -1. Find the workload that you want to rollback and select **Vertical Elipsis (... ) > Rollback**. +1. Find the workload that you want to rollback and select **Vertical Ellipsis (... ) > Rollback**. 1. Choose the revision that you want to roll back to. Click **Rollback**. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md index c00c15e0a97..5d47c733ed4 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/workloads/upgrade-workloads/_index.md @@ -8,7 +8,7 @@ When a new version of an application image is released on Docker Hub, you can up 1. From the **Global** view, open the project running the workload you want to upgrade. -1. Find the workload that you want to upgrade and select **Vertical Elipsis (... ) > Edit**. +1. Find the workload that you want to upgrade and select **Vertical Ellipsis (... ) > Edit**. 1. Update the **Docker Image** to the updated version of the application image on Docker Hub. diff --git a/content/rancher/v2.x/en/security/benchmark-2.1/_index.md b/content/rancher/v2.x/en/security/benchmark-2.1/_index.md index caa0cb60459..d5e2c74968f 100644 --- a/content/rancher/v2.x/en/security/benchmark-2.1/_index.md +++ b/content/rancher/v2.x/en/security/benchmark-2.1/_index.md @@ -1190,7 +1190,7 @@ docker inspect etcd | jq -e '.[0].Args[] | match("--peer-auto-tls(?:(?!=false).* **Notes** -RKE does not currently implement a seperate CA for etcd certificates. +RKE does not currently implement a separate CA for etcd certificates. `--trusted-ca-file` is set and different from the `--client-ca-file` used by `kube-apiserver`. diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md index e3451e421ef..a94b1a04ee7 100644 --- a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md +++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/controlplane/_index.md @@ -7,7 +7,7 @@ This section applies to nodes with the `controlplane` role. # Check if the Controlplane Containers are Running -There are three specific containers launched on nodes with the `controlpane` role: +There are three specific containers launched on nodes with the `controlplane` role: * `kube-apiserver` * `kube-controller-manager` diff --git a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md index 2f92ed8b9b2..d102694fe45 100644 --- a/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md +++ b/content/rancher/v2.x/en/troubleshooting/kubernetes-components/worker-and-generic/_index.md @@ -7,7 +7,7 @@ This section applies to every node as it includes components that run on nodes w # Check if the Containers are Running -There are three specific containers launched on nodes with the `controlpane` role: +There are three specific containers launched on nodes with the `controlplane` role: * kubelet * kube-proxy diff --git a/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md b/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md index f0304c2eb44..bc7d2301915 100644 --- a/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md +++ b/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md @@ -38,7 +38,7 @@ You can obtain `` and `` by loggi ## Rolling Back Rancher -If you have issues upgrading Rancher, roll it back to its lastest known healthy state by pulling the last version you used and then restoring the backup you made before upgrade. +If you have issues upgrading Rancher, roll it back to its latest known healthy state by pulling the last version you used and then restoring the backup you made before upgrade. >**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur. @@ -51,7 +51,7 @@ If you have issues upgrading Rancher, roll it back to its lastest known healthy ``` docker pull rancher/rancher: ``` - + 1. Stop the container currently running Rancher Server. Replace `` with the name of your Rancher container. ``` diff --git a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md index aa76e842de3..6885d6794a1 100644 --- a/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md +++ b/content/rancher/v2.x/en/v1.6-migration/load-balancing/_index.md @@ -157,6 +157,6 @@ Cattle provided feature-rich load balancer support that is [well documented]({{< - Only ports 80 and 443 can be configured for HTTP/HTTPS routing via Ingress. Also Ingress Controller is deployed globally as a DaemonSet and not launched as a scalable service. Also, users cannot assign random external ports to be used for balancing. Therefore, users need to ensure that they configure unique hostname/path combinations to avoid routing conflicts using the same two ports. - There is no way to specify port rule priority and ordering. - Rancher v1.6 added support for draining backend connections and specifying a drain timeout. This is not supported in Rancher v2.x. -- There is no support for specifying a custom stickiness policy and a custom load balancer config to be appended to the default config as of now in Rancher v2.x. There is some support, however, available in native Kubernetes for customizing the NGINX configuration as noted in the [NGINX Ingress Controller Custom Conguration Documentation](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-configuration/). +- There is no support for specifying a custom stickiness policy and a custom load balancer config to be appended to the default config as of now in Rancher v2.x. There is some support, however, available in native Kubernetes for customizing the NGINX configuration as noted in the [NGINX Ingress Controller Custom Configuration Documentation](https://kubernetes.github.io/ingress-nginx/examples/customization/custom-configuration/). ### Finished! diff --git a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md index d018c49e4e4..c9ea17668c4 100644 --- a/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md +++ b/content/rancher/v2.x/en/v1.6-migration/monitor-apps/_index.md @@ -45,7 +45,7 @@ The following diagram displays the health check microservice evaluating a contai ## Rancher v2.x Health Checks -In Rancher v2.x, the health check microservice is replaced with Kubernete's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP. +In Rancher v2.x, the health check microservice is replaced with Kubernetes's native health check mechanisms, called _probes_. These probes, similar to the Rancher v1.6 health check microservice, monitor the health of pods over TCP and HTTP. However, probes in Rancher v2.x have some important differences, which are described below. For full details about probes, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes). diff --git a/content/rke/latest/en/config-options/secrets-encryption/_index.md b/content/rke/latest/en/config-options/secrets-encryption/_index.md index 9d447592c0a..c4dc378a249 100644 --- a/content/rke/latest/en/config-options/secrets-encryption/_index.md +++ b/content/rke/latest/en/config-options/secrets-encryption/_index.md @@ -18,7 +18,7 @@ RKE provides users with two paths of configuration to enable at-rest data encryp - Managed at-rest data encryption - Custom configuration for at-rest data encryption -Both configuration options can be added during initial cluster provisioning or by updating an exsiting cluster. +Both configuration options can be added during initial cluster provisioning or by updating an existing cluster. To utilize this feature, a new field `secrets_encryption_config` is added to the [Kubernetes API service configuration]({{}}//rke/latest/en/config-options/services/#kubernetes-api-server). A full custom configuration looks like this: diff --git a/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md b/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md index f8cee4cc5e4..81240247b68 100644 --- a/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md +++ b/content/rke/latest/en/troubleshooting/ssh-connectivity-errors/_index.md @@ -20,7 +20,7 @@ CONTAINER ID IMAGE COMMAND CREATED See [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user) how to set this up properly. -* When using RedHat/CentOS as operating system, you cannot use the user `root` to connect to the nodes because of [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). You will need to add a separate user and configure it to access the Docker socket. See [RKE OS Requirements](https://rancher.com/docs/rke/latest/en/os/#red-hat-enterprise-linux-rhel-oracle-enterprise-linux-oel-centos) for more on how to set this up. +* When using RedHat/CentOS as operating system, you cannot use the user `root` to connect to the nodes because of [Bugzilla #1527565](https://bugzilla.redhat.com/show_bug.cgi?id=1527565). You will need to add a separate user and configure it to access the Docker socket. See [RKE OS Requirements](https://rancher.com/docs/rke/latest/en/os/#red-hat-enterprise-linux-rhel-oracle-enterprise-linux-oel-centos) for more on how to set this up. * SSH server version is not version 6.7 or higher. This is needed for socket forwarding to work, which is used to connect to the Docker socket over SSH. This can be checked using `sshd -V` on the host you are connecting to, or using netcat: ``` @@ -35,7 +35,7 @@ SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10 #### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain -* The key file specified as `ssh_key_path` is not correct for accesing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with. +* The key file specified as `ssh_key_path` is not correct for accessing the node. Double-check if you specified the correct `ssh_key_path` for the node and if you specified the correct user to connect with. #### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: cannot decode encrypted private keys From 4d26fb987a0bfe6ab0ea4b84e2bac0b851da5a74 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Thu, 2 Jan 2020 14:37:37 -0700 Subject: [PATCH 71/82] Fix typo in architecture diagram --- static/img/rancher/rancher-architecture-cluster-controller.svg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/static/img/rancher/rancher-architecture-cluster-controller.svg b/static/img/rancher/rancher-architecture-cluster-controller.svg index 922cc572ef9..ce9fb2958f6 100644 --- a/static/img/rancher/rancher-architecture-cluster-controller.svg +++ b/static/img/rancher/rancher-architecture-cluster-controller.svg @@ -1,3 +1,3 @@ -
User Cluster 1
<font style="font-size: 20px">User Cluster 1</font>
kubectl get pods
[Not supported by viewer]
kube-api-auth
[Not supported by viewer]
Bob
[Not supported by viewer]
Alice
Alice
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
etcd Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
etcd Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
etcd Node
[Not supported by viewer]
4
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Controlplane
Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Controlplane
Node
[Not supported by viewer]
Kubernetes API Server
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
kubectl get pods
[Not supported by viewer]
Cluster Agent
[Not supported by viewer]
1
[Not supported by viewer]
Rancher Server
<font style="font-size: 20px">Rancher Server<br></font>
Cluster Controller 1
[Not supported by viewer]
Cluster Controller 2
[Not supported by viewer]
Cluster Controller 3
[Not supported by viewer]
2
[Not supported by viewer]
3
[Not supported by viewer]
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
User Cluster 2
[Not supported by viewer]
User Cluster 2
[Not supported by viewer]
Authentication Proxy
[Not supported by viewer]
Kubernetes provisioned
by Rancher Kubernetes
Engine
[Not supported by viewer] \ No newline at end of file +
User Cluster 1
<font style="font-size: 20px">User Cluster 1</font>
kubectl get pods
[Not supported by viewer]
kube-api-auth
[Not supported by viewer]
Bob
[Not supported by viewer]
Alice
Alice
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
etcd Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
etcd Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
etcd Node
[Not supported by viewer]
4
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Controlplane
Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Controlplane
Node
[Not supported by viewer]
Kubernetes API Server
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
Kubelet
[Not supported by viewer]
Node Agent
[Not supported by viewer]
Worker Node
[Not supported by viewer]
kubectl get pods
[Not supported by viewer]
Cluster Agent
[Not supported by viewer]
1
[Not supported by viewer]
Rancher Server
<font style="font-size: 20px">Rancher Server<br></font>
Cluster Controller 1
[Not supported by viewer]
Cluster Controller 2
[Not supported by viewer]
Cluster Controller 3
[Not supported by viewer]
2
[Not supported by viewer]
3
[Not supported by viewer]
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
Tunnel
User Cluster 2
[Not supported by viewer]
User Cluster 3
[Not supported by viewer]
Authentication Proxy
[Not supported by viewer]
Kubernetes provisioned
by Rancher Kubernetes
Engine
[Not supported by viewer] \ No newline at end of file From 626df8ebba9c2f01e131fb992479aea7de80c207 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 26 Nov 2019 17:28:50 -0700 Subject: [PATCH 72/82] Edit K3s docs --- .gitignore | 2 +- content/k3s/latest/en/_index.md | 5 +- content/k3s/latest/en/advanced/_index.md | 203 ++++++++++++++++-- content/k3s/latest/en/architecture/_index.md | 52 +++++ content/k3s/latest/en/configuration/_index.md | 8 +- content/k3s/latest/en/installation/_index.md | 8 +- .../latest/en/installation/airgap/_index.md | 10 +- .../en/installation/datastore/_index.md | 2 +- .../k3s/latest/en/installation/ha/_index.md | 39 ++-- .../en/installation/install-options/_index.md | 39 +++- .../installation/node-requirements/_index.md | 2 + content/k3s/latest/en/known-issues/_index.md | 4 + content/k3s/latest/en/networking/_index.md | 17 +- content/k3s/latest/en/quick-start/_index.md | 6 +- content/k3s/latest/en/storage/_index.md | 48 ++++- content/k3s/latest/en/upgrades/_index.md | 10 +- static/img/rancher/k3s-ha-architecture.svg | 3 + .../k3s-single-node-server-architecture.svg | 3 + 18 files changed, 374 insertions(+), 87 deletions(-) create mode 100644 content/k3s/latest/en/architecture/_index.md create mode 100644 static/img/rancher/k3s-ha-architecture.svg create mode 100644 static/img/rancher/k3s-single-node-server-architecture.svg diff --git a/.gitignore b/.gitignore index 130a0023abe..3db5f73ddd2 100644 --- a/.gitignore +++ b/.gitignore @@ -5,4 +5,4 @@ package-lock.json *.tern-port */**/.tern-port .DS_Store -.vscode/settings.json \ No newline at end of file +.vscode/settings.json diff --git a/content/k3s/latest/en/_index.md b/content/k3s/latest/en/_index.md index ede2b86a14d..58cb7baa2e8 100644 --- a/content/k3s/latest/en/_index.md +++ b/content/k3s/latest/en/_index.md @@ -14,13 +14,12 @@ Great for: * ARM * Situations where a PhD in k8s clusterology is infeasible -What is this? ---- +# What is K3s? K3s is a fully compliant Kubernetes distribution with the following enhancements: * An embedded SQLite database has replaced etcd as the default datastore. External datastores such as PostgreSQL, MySQL, and etcd are also supported. -* Simple but powerful "batteries-included" features have been added, such as: a local storage provider, a service load balancer, a helm controller, and the Traefik ingress controller. +* Simple but powerful "batteries-included" features have been added, such as: a local storage provider, a service load balancer, a Helm controller, and the Traefik ingress controller. * Operation of all Kubernetes control plane components is encapsulated in a single binary and process. This allows K3s to automate and manage complex cluster operations like distributing certificates. * In-tree cloud providers and storage plugins have been removed. * External dependencies have been minimized (just a modern kernel and cgroup mounts needed). K3s packages required dependencies, including: diff --git a/content/k3s/latest/en/advanced/_index.md b/content/k3s/latest/en/advanced/_index.md index 426a40d4afd..ca549701510 100644 --- a/content/k3s/latest/en/advanced/_index.md +++ b/content/k3s/latest/en/advanced/_index.md @@ -1,23 +1,174 @@ --- -title: "Advanced Options" +title: "Advanced Options and Configuration" weight: 40 aliases: - /k3s/latest/en/running/ + - /k3s/latest/en/configuration/ --- -This section contains advanced information describing the different ways you can run and manage K3s. +This section contains advanced information describing the different ways you can run and manage K3s: -Starting the Server ------------------- +- [Auto-deploying manifests](#auto-deploying-manifests) +- [Using the Helm CRD](#using-the-helm-crd) +- [Accessing the cluster from outside with kubectl](#accessing-the-cluster-from-outside-with-kubectl) +- [Using Docker as the container runtime](#using-docker-as-the-container-runtime) +- [Running K3s with RootlessKit (Experimental)](#running-k3s-with-rootlesskit-experimental) +- [Node labels and taints](#node-labels-and-taints) +- [Starting the server with the installation script](#starting-the-server-with-the-installation-script) +- [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) + +# Auto-Deploying Manifests + +Any file found in `/var/lib/rancher/k3s/server/manifests` will automatically be deployed to +Kubernetes in a manner similar to `kubectl apply`. + +It is also possible to deploy Helm charts. K3s supports a CRD controller for installing charts. A YAML file specification can look as following (example taken from `/var/lib/rancher/k3s/server/manifests/traefik.yaml`): + +```yaml +apiVersion: helm.cattle.io/v1 +kind: HelmChart +metadata: + name: traefik + namespace: kube-system +spec: + chart: stable/traefik + set: + rbac.enabled: "true" + ssl.enabled: "true" +``` + +Keep in mind that `namespace` in your HelmChart resource metadata section should always be `kube-system`, because the K3s deploy controller is configured to watch this namespace for new HelmChart resources. If you want to specify the namespace for the actual Helm release, you can do that using `targetNamespace` key under the `spec` directive, as shown in the configuration example below. + +Also note that besides `set`, you can use `valuesContent` under the `spec` directive. And it's okay to use both of them: + +```yaml +apiVersion: helm.cattle.io/v1 +kind: HelmChart +metadata: + name: grafana + namespace: kube-system +spec: + chart: stable/grafana + targetNamespace: monitoring + set: + adminPassword: "NotVerySafePassword" + valuesContent: |- + image: + tag: master + env: + GF_EXPLORE_ENABLED: true + adminUser: admin + sidecar: + datasources: + enabled: true +``` + +K3s versions `<= v0.5.0` used `k3s.cattle.io` for the API group of HelmCharts. This has been changed to `helm.cattle.io` for later versions. + +# Using the Helm CRD + +You can deploy a 3rd party Helm chart using an example like this: + +```yaml +apiVersion: helm.cattle.io/v1 +kind: HelmChart +metadata: + name: nginx + namespace: kube-system +spec: + chart: nginx + repo: https://charts.bitnami.com/bitnami + targetNamespace: default +``` + +You can install a specific version of a Helm chart using an example like this: + +```yaml +apiVersion: helm.cattle.io/v1 +kind: HelmChart +metadata: + name: stable/nginx-ingress + namespace: kube-system +spec: + chart: nginx-ingress + version: 1.24.4 + targetNamespace: default +``` + +# Accessing the Cluster from Outside with kubectl + +Copy `/etc/rancher/k3s/k3s.yaml` on your machine located outside the cluster as `~/.kube/config`. Then replace "localhost" with the IP or name of your K3s server. `kubectl` can now manage your K3s cluster. + +# Using Docker as the Container Runtime + +K3s includes and defaults to [containerd,](https://containerd.io/) an industry-standard container runtime. If you want to use Docker instead of containerd then you simply need to run the agent with the `--docker` flag. + +K3s will generate config.toml for containerd in `/var/lib/rancher/k3s/agent/etc/containerd/config.toml`. For advanced customization for this file you can create another file called `config.toml.tmpl` in the same directory and it will be used instead. + +The `config.toml.tmpl` will be treated as a Golang template file, and the `config.Node` structure is being passed to the template, the following is an example on how to use the structure to customize the configuration file https://github.com/rancher/k3s/blob/master/pkg/agent/templates/templates.go#L16-L32 + +# Running K3s with RootlessKit (Experimental) + +> **Warning:** This feature is experimental. + +RootlessKit is a kind of Linux-native "fake root" utility, made for mainly [running Docker and Kubernetes as an unprivileged user,](https://github.com/rootless-containers/usernetes) so as to protect the real root on the host from potential container-breakout attacks. + +Initial rootless support has been added but there are a series of significant usability issues surrounding it. + +We are releasing the initial support for those interested in rootless and hopefully some people can help to improve the usability. First, ensure you have a proper setup and support for user namespaces. Refer to the [requirements section](https://github.com/rootless-containers/rootlesskit#setup) in RootlessKit for instructions. +In short, latest Ubuntu is your best bet for this to work. + +### Known Issues with RootlessKit + +* **Ports** + + When running rootless a new network namespace is created. This means that K3s instance is running with networking fairly detached from the host. The only way to access services run in K3s from the host is to set up port forwards to the K3s network namespace. We have a controller that will automatically bind 6443 and service port below 1024 to the host with an offset of 10000. + + That means service port 80 will become 10080 on the host, but 8080 will become 8080 without any offset. + + Currently, only `LoadBalancer` services are automatically bound. + +* **Daemon lifecycle** + + Once you kill K3s and then start a new instance of K3s it will create a new network namespace, but it doesn't kill the old pods. So you are left + with a fairly broken setup. This is the main issue at the moment, how to deal with the network namespace. + + The issue is tracked in https://github.com/rootless-containers/rootlesskit/issues/65 + +* **Cgroups** + + Cgroups are not supported. + +### Running Servers and Agents with Rootless + +Just add `--rootless` flag to either server or agent. So run `k3s server --rootless` and then look for the message +`Wrote kubeconfig [SOME PATH]` for where your kubeconfig to access you cluster is. + +> Be careful, if you use `-o` to write +the kubeconfig to a different directory it will probably not work. This is because the K3s instance in running in a different +mount namespace. + +# Node Labels and Taints + +K3s agents can be configured with the options `--node-label` and `--node-taint` which adds a label and taint to the kubelet. The two options only add labels and/or taints [at registration time,]({{}}/k3s/latest/en/installation/install-options/#node-labels-and-taints-for-agents) so they can only be added once and not changed after that again by running K3s commands. + +If you want to change node labels and taints after node registration you should use `kubectl`. Refer to the official Kubernetes documentation for details on how to add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) and [node labels.](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) + +# Starting the Server with the Installation Script The installation script will auto-detect if your OS is using systemd or openrc and start the service. -When running with openrc logs will be created at `/var/log/k3s.log`, or with systemd in `/var/log/syslog` and viewed using `journalctl -u k3s`. An example of installing and auto-starting with the install script: +When running with openrc, logs will be created at `/var/log/k3s.log`. + +When running with systemd, logs will be created in `/var/log/syslog` and viewed using `journalctl -u k3s`. + +An example of installing and auto-starting with the install script: ```bash curl -sfL https://get.k3s.io | sh - ``` -When running the server manually you should get an output similar to: +When running the server manually you should get an output similar to the following: ``` $ k3s server @@ -38,10 +189,9 @@ INFO[2019-01-22T15:16:20.541049100-07:00] Run: k3s kubectl The output will likely be much longer as the agent will create a lot of logs. By default the server will register itself as a node (run the agent). -Alpine Linux ------------- +# Additional Preparation for Alpine Linux Setup -In order to pre-setup Alpine Linux you have to go through the following steps: +In order to set up Alpine Linux, you have to go through the following preparation: ```bash echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab @@ -75,19 +225,26 @@ reboot After rebooting: -- download **k3s** to **/usr/local/bin/k3s** -- create an openrc file in **/etc/init.d** +- Download **k3s** to **/usr/local/bin/k3s** +- Create an openrc file in **/etc/init.d** -Running in Docker (and docker-compose) ------------------ +# Running K3d (K3s in Docker) and docker-compose -[k3d](https://github.com/rancher/k3d) is a utility designed to easily run K3s in Docker. It can be installed via the [brew](https://brew.sh/) utility for MacOS. +[k3d](https://github.com/rancher/k3d) is a utility designed to easily run K3s in Docker. -`rancher/k3s` images are also available to run K3s server and agent from Docker. A `docker-compose.yml` is in the root of the K3s repo that -serves as an example of how to run K3s from Docker. To run from `docker-compose` from this repo run: +It can be installed via the the [brew](https://brew.sh/) utility on MacOS: + +``` +brew install k3d +``` + +`rancher/k3s` images are also available to run the K3s server and agent from Docker. + +A `docker-compose.yml` is in the root of the K3s repo that serves as an example of how to run K3s from Docker. To run from `docker-compose` from this repo, run: docker-compose up --scale node=3 # kubeconfig is written to current dir + kubectl --kubeconfig kubeconfig.yaml get node NAME STATUS ROLES AGE VERSION @@ -95,12 +252,14 @@ serves as an example of how to run K3s from Docker. To run from `docker-compose d54c8b17c055 Ready 11s v1.13.2-k3s2 db7a5a5a5bdd Ready 12s v1.13.2-k3s2 -To run the agent only in Docker, use `docker-compose up node`. Alternatively the Docker run command can also be used; +To run the agent only in Docker, use `docker-compose up node`. + +Alternatively the `docker run` command can also be used: sudo docker run \ - -d --tmpfs /run \ - --tmpfs /var/run \ - -e K3S_URL=${SERVER_URL} \ - -e K3S_TOKEN=${NODE_TOKEN} \ - --privileged rancher/k3s:vX.Y.Z + -d --tmpfs /run \ + --tmpfs /var/run \ + -e K3S_URL=${SERVER_URL} \ + -e K3S_TOKEN=${NODE_TOKEN} \ + --privileged rancher/k3s:vX.Y.Z diff --git a/content/k3s/latest/en/architecture/_index.md b/content/k3s/latest/en/architecture/_index.md new file mode 100644 index 00000000000..4f551fb99bf --- /dev/null +++ b/content/k3s/latest/en/architecture/_index.md @@ -0,0 +1,52 @@ +--- +title: Architecture +weight: 1 +--- + +This page describes the architecture of a high-availability K3s server cluster and how it differs from a single-node server cluster. + +It also describes how agent nodes are registered with K3s servers. + +A server node is defined as a machine (bare-metal or virtual) running the `k3s server` command. A worker node is defined as a machine running the `k3s agent` command. + +This page covers the following topics: + +- [Single-server setup with an embedded database](#single-server-setup-with-an-embedded-db) +- [High-availability K3s server with an external database](#high-availability-k3s-server-with-an-external-db) + - [Fixed registration address for agent nodes](#fixed-registration-address-for-agent-nodes) +- [How agent node registration works](#how-agent-node-registration-works) + +# Single-server Setup with an Embedded DB + +The following diagram shows an example of a cluster that has a single-node K3s server with an embedded SQLite database. + +In this configuration, each agent node is registered to the same server node. A K3s user can manipulate Kubernetes resources by calling the K3s API on the server node. + +![Architecture]({{}}/img/rancher/k3s-single-node-server-architecture.svg) + +# High-Availability K3s Server with an External DB + +Single server clusters can meet a variety of use cases, but for environments where uptime of the Kubernetes control plane is critical, you can run K3s in an HA configuration. An HA K3s cluster is comprised of: + +* Two or more **server nodes** that will serve the Kubernetes API and run other control plane services +* An **external datastore** (as opposed to the embedded SQLite datastore used in single-server setups) + +![Architecture]({{< baseurl >}}/img/rancher/k3s-ha-architecture.svg) + +### Fixed Registration Address for Agent Nodes + +In the high-availability server configuration, each node must also register with the Kubernetes API by using a fixed registration address, as shown in the diagram below. + +After registration, the agent nodes establish a connection directly to one of the server nodes. + +![k3s HA]({{< baseurl >}}/img/k3s/k3s-production-setup.svg) + +# How Agent Node Registration Works + +Agent nodes are registered with a websocket connection initiated by the `k3s agent` process, and the connection is maintained by a client-side load balancer running as part of the agent process. + +Agents will register with the server using the node cluster secret along with a randomly generated password for the node, stored at `/etc/rancher/node/password`. The server will store the passwords for individual nodes at `/var/lib/rancher/k3s/server/cred/node-passwd`, and any subsequent attempts must use the same password. + +If the `/etc/rancher/node` directory of an agent is removed, the password file should be recreated for the agent, or the entry removed from the server. + +A unique node ID can be appended to the hostname by launching K3s servers or agents using the `--with-node-id` flag. \ No newline at end of file diff --git a/content/k3s/latest/en/configuration/_index.md b/content/k3s/latest/en/configuration/_index.md index 65387bb5bc1..4173c2092c8 100644 --- a/content/k3s/latest/en/configuration/_index.md +++ b/content/k3s/latest/en/configuration/_index.md @@ -27,7 +27,11 @@ spec: ssl.enabled: "true" ``` -Keep in mind that `namespace` in your HelmChart resource metadata section should always be `kube-system`, because the K3s deploy controller is configured to watch this namespace for new HelmChart resources. If you want to specify the namespace for the actual helm release, you can do that using `targetNamespace` key in the spec section: +Keep in mind that `namespace` in your HelmChart resource metadata section should always be `kube-system`, because the K3s deploy controller is configured to watch this namespace for new HelmChart resources. + +If you want to specify the namespace for the actual Helm release, you can do that using `targetNamespace` key under the `spec` directive, as shown in the configuration example below. + +Also note that besides `set`, you can also use `valuesContent` under the `spec` directive. And it's okay to use both of them: ```yaml apiVersion: helm.cattle.io/v1 @@ -51,8 +55,6 @@ spec: enabled: true ``` -Also note that besides `set` you can use `valuesContent` in the spec section. And it's okay to use both of them. - K3s versions `<= v0.5.0` used `k3s.cattle.io` for the api group of helmcharts, this has been changed to `helm.cattle.io` for later versions. Using the helm CRD diff --git a/content/k3s/latest/en/installation/_index.md b/content/k3s/latest/en/installation/_index.md index f631fe9c543..3a6fb03fa7f 100644 --- a/content/k3s/latest/en/installation/_index.md +++ b/content/k3s/latest/en/installation/_index.md @@ -8,12 +8,12 @@ This section contains instructions for installing K3s in various environments. P [Installation and Configuration Options]({{< baseurl >}}/k3s/latest/en/installation/install-options/) provides guidance on the options available to you when installing K3s. -[High Availability with an External DB]({{< baseurl >}}/k3s/latest/en/installation/ha/) details how to setup an HA K3s cluster backed by an external datastore such as MySQL, PostgreSQL, or etcd. +[High Availability with an External DB]({{< baseurl >}}/k3s/latest/en/installation/ha/) details how to set up an HA K3s cluster backed by an external datastore such as MySQL, PostgreSQL, or etcd. -[High Availability with Embedded DB (Experimental)]({{< baseurl >}}/k3s/latest/en/installation/ha-embedded/) details how to setup an HA K3s cluster that leverages a built-in distributed database. +[High Availability with Embedded DB (Experimental)]({{< baseurl >}}/k3s/latest/en/installation/ha-embedded/) details how to set up an HA K3s cluster that leverages a built-in distributed database. -[Air-Gap Installation]({{< baseurl >}}/k3s/latest/en/installation/airgap/) details how to setup K3s in environments that do not have direct access to the Internet. +[Air-Gap Installation]({{< baseurl >}}/k3s/latest/en/installation/airgap/) details how to set up K3s in environments that do not have direct access to the Internet. ### Uninstalling -If you installed K3s with the help of the `install.sh` script, an uninstall script is generated during installation, which will be created on your node at `/usr/local/bin/k3s-uninstall.sh` (or as `k3s-agent-uninstall.sh`). +If you installed K3s with the help of the `install.sh` script, an uninstall script is generated during installation. The script is created on your node at `/usr/local/bin/k3s-uninstall.sh` (or as `k3s-agent-uninstall.sh`). diff --git a/content/k3s/latest/en/installation/airgap/_index.md b/content/k3s/latest/en/installation/airgap/_index.md index e96967163c1..66564948a5d 100644 --- a/content/k3s/latest/en/installation/airgap/_index.md +++ b/content/k3s/latest/en/installation/airgap/_index.md @@ -5,11 +5,11 @@ weight: 60 In this guide, we are assuming you have created your nodes in your air-gap environment and have a secure Docker private registry on your bastion server. -Installation Outline --------------------- -1. Prepare Images Directory -2. Create Registry YAML -3. Install K3s +# Installation Outline + +1. [Prepare Images Directory](#prepare-images-directory) +2. [Create Registry YAML](#create-registry-YAML) +3. [Install K3s](#install-k3s) ### Prepare Images Directory Obtain the images tar file for your architecture from the [releases](https://github.com/rancher/k3s/releases) page for the version of K3s you will be running. diff --git a/content/k3s/latest/en/installation/datastore/_index.md b/content/k3s/latest/en/installation/datastore/_index.md index 7d5c2775871..63ef6baa32b 100644 --- a/content/k3s/latest/en/installation/datastore/_index.md +++ b/content/k3s/latest/en/installation/datastore/_index.md @@ -94,4 +94,4 @@ k3s server ``` ### Embedded DQLite for HA (Experimental) -K3s's use of DQLite is similar to its use of SQLite. It is simple to setup and manage. As such, there is no external configuration or additional steps to take in order to use this option. Please see [High Availability with Embedded DB (Experimental)]({{< baseurl >}}/k3s/latest/en/installation/ha-embedded/) for instructions on how to run with this option. +K3s's use of DQLite is similar to its use of SQLite. It is simple to set up and manage. As such, there is no external configuration or additional steps to take in order to use this option. Please see [High Availability with Embedded DB (Experimental)]({{< baseurl >}}/k3s/latest/en/installation/ha-embedded/) for instructions on how to run with this option. diff --git a/content/k3s/latest/en/installation/ha/_index.md b/content/k3s/latest/en/installation/ha/_index.md index ca6897ae48a..024e7a1714f 100644 --- a/content/k3s/latest/en/installation/ha/_index.md +++ b/content/k3s/latest/en/installation/ha/_index.md @@ -1,36 +1,35 @@ --- -title: "High Availability with an External DB" +title: High Availability with an External DB weight: 30 --- >**Note:** Official support for High-Availability (HA) was introduced in our v1.0.0 release. +This section describes how to install a high-availability K3s cluster with an external database. + Single server clusters can meet a variety of use cases, but for environments where uptime of the Kubernetes control plane is critical, you can run K3s in an HA configuration. An HA K3s cluster is comprised of: * Two or more **server nodes** that will serve the Kubernetes API and run other control plane services -* An **external datastore** (as opposed to the embedded SQLite datastore used in single server setups) -* A **fixed registration address** placed in front of the server nodes to allow worker nodes to register with the cluster +* An **external datastore** (as opposed to the embedded SQLite datastore used in single-server setups) +* A **fixed registration address** that is placed in front of the server nodes to allow worker nodes to register with the cluster -The following diagram illustrates the above configuration: -![k3s HA]({{< baseurl >}}/img/k3s/k3s-production-setup.svg) - -In this architecture a server node is defined as a machine (bare-metal or virtual) running the `k3s server` command. A worker node is defined as a machine running the `k3s agent` command. +For more details on how these components work together, refer to the [architecture section.]({{}}/k3s/latest/en/architecture/#high-availability-with-an-external-db) Workers register through the fixed registration address, but after registration they establish a connection directly to one of the server nodes. This is a websocket connection initiated by the `k3s agent` process and it is maintained by a client-side load balancer running as part of the agent process. -Installation Outline --------------------- +# Installation Outline + Setting up an HA cluster requires the following steps: -1. Create an external datastore -2. Launch server nodes -3. Configure fixed registration address -4. Join worker nodes +1. [Create an external datastore](#1-create-an-external-datastore) +2. [Launch server nodes](#2-launch-server-nodes) +3. [Configure the fixed registration address](#3-configure-the-fixed-registration-address) +4. [Join worker nodes](#4-join-worker-nodes) -### Create an External Datastore +### 1. Create an External Datastore You will first need to create an external datastore for the cluster. See the [Cluster Datastore Options]({{< baseurl >}}/k3s/latest/en/installation/datastore/) documentation for more details. -### Launch Server Nodes +### 2. Launch Server Nodes K3s requires two or more server nodes for this HA configuration. See the [Node Requirements]({{< baseurl >}}/k3s/latest/en/installation/node-requirements/) guide for minimum machine requirements. When running the `k3s server` command on these nodes, you must set the `datastore-endpoint` parameter so that K3s knows how to connect to the external datastore. Please see the [datastore configuration guide]({{< baseurl >}}/k3s/latest/en/installation/datastore/#external-datastore-configuration-parameters) for information on configuring this parameter. @@ -41,16 +40,16 @@ By default, server nodes will be schedulable and thus your workloads can get lau Once you've launched the `k3s server` process on all server nodes, you can ensure that the cluster has come up properly by checking that the nodes are in the Ready state with `k3s kubectl get nodes`. -### Configure the Fixed Registration Address -Worker nodes need a URL to register against. This can be the IP or hostname of any of the server nodes, but in many cases those may change over time. For example, if you are running your cluster in a cloud that supports scaling groups, you may scale the server node group up and down over time, causing nodes to be created and destroyed and thus having different IPs from the initial set of server nodes. Therefore, you should have a stable endpoint in front of the server nodes that will not change over time. This endpoint can be setup using any number approaches, such as: +### 3. Configure the Fixed Registration Address +Worker nodes need a URL to register against. This can be the IP or hostname of any of the server nodes, but in many cases those may change over time. For example, if you are running your cluster in a cloud that supports scaling groups, you may scale the server node group up and down over time, causing nodes to be created and destroyed and thus having different IPs from the initial set of server nodes. Therefore, you should have a stable endpoint in front of the server nodes that will not change over time. This endpoint can be set up using any number approaches, such as: * A layer-4 (TCP) load balancer * Round-robin DNS -* A virtual or elastic IP addresses +* Virtual or elastic IP addresses -This endpoint can also be used for accessing the Kubernetes API. So you can, for example, modify your kubeconfig file to point to it instead of a specific node. +This endpoint can also be used for accessing the Kubernetes API. So you can, for example, modify your [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file to point to it instead of a specific node. -### Join Worker Nodes +### 4. Join Worker Nodes Joining worker nodes in an HA cluster is the same as joining worker nodes in a single server cluster. You just need to specify the URL the agent should register to and the token it should use. ``` K3S_TOKEN=SECRET k3s agent --server https://fixed-registration-address:6443 diff --git a/content/k3s/latest/en/installation/install-options/_index.md b/content/k3s/latest/en/installation/install-options/_index.md index b9c3aa859e2..424cbd9ae73 100644 --- a/content/k3s/latest/en/installation/install-options/_index.md +++ b/content/k3s/latest/en/installation/install-options/_index.md @@ -1,9 +1,18 @@ --- -title: "Installation and Configuration Options" +title: "Installation Options" weight: 20 --- -### Installation script options +This page focuses on the options that can be used when you set up K3s for the first time: + +- [Installation script options](#installation-script-options) +- [Installing K3s from the binary](#installing-k3s-from-the-binary) +- [Registration options for the K3s server](#registration-options-for-the-k3s-server) +- [Registration options for the K3s agent](#registration-options-for-the-k3s-agent) + +For more advanced options, refer to [this page.]({{}}/k3s/latest/en/advanced) + +# Installation Script Options As mentioned in the [Quick-Start Guide]({{< baseurl >}}/k3s/latest/en/quick-start/), you can use the installation script available at https://get.k3s.io to install K3s as a service on systemd and openrc based systems. @@ -36,7 +45,7 @@ When using this method to install K3s, the following environment variables can b - `INSTALL_K3S_BIN_DIR_READ_ONLY` - If set to true will not write files to `INSTALL_K3S_BIN_DIR`, forces setting INSTALL_K3S_SKIP_DOWNLOAD=true. + If set to true will not write files to `INSTALL_K3S_BIN_DIR`, forces setting `INSTALL_K3S_SKIP_DOWNLOAD=true`. - `INSTALL_K3S_SYSTEMD_DIR` @@ -44,7 +53,9 @@ When using this method to install K3s, the following environment variables can b - `INSTALL_K3S_EXEC` - Command with flags to use for launching K3s in the service. If the command is not specified, it will default to "agent" if `K3S_URL` is set or "server" if it is not set. The final systemd command resolves to a combination of this environment variable and script args. To illustrate this, the following commands result in the same behavior: + Command with flags to use for launching K3s in the service. If the command is not specified, it will default to "agent" if `K3S_URL` is set or "server" if it is not set. + + The final systemd command resolves to a combination of this environment variable and script args. To illustrate this, the following commands result in the same behavior of registering a server without flannel: ```sh curl ... | INSTALL_K3S_EXEC="--no-flannel" sh -s - curl ... | INSTALL_K3S_EXEC="server --no-flannel" sh -s - @@ -65,7 +76,8 @@ When using this method to install K3s, the following environment variables can b Environment variables which begin with `K3S_` will be preserved for the systemd and openrc services to use. Setting `K3S_URL` without explicitly setting an exec command will default the command to "agent". When running the agent `K3S_TOKEN` must also be set. -### Beyond the Installation Script +# Installing K3s from the Binary + As stated, the installation script is primarily concerned with configuring K3s to run as a service. If you choose to not use the script, you can run K3s simply by downloading the binary from our [release page](https://github.com/rancher/k3s/releases/latest), placing it on your path, and executing it. The K3s binary supports the following commands: Command | Description @@ -79,7 +91,7 @@ Command | Description The `k3s server` and `k3s agent` commands have additional configuration options that can be viewed with `k3s server --help` or `k3s agent --help`. For convenience, that help text is presented here: -### `k3s server` +# Registration Options for the K3s Server ``` NAME: k3s server - Run management server @@ -145,7 +157,7 @@ OPTIONS: --cluster-secret value (deprecated) use --token [$K3S_CLUSTER_SECRET] ``` -### `k3s agent` +# Registration Options for the K3s Agent ``` NAME: k3s agent - Run node agent @@ -181,3 +193,16 @@ OPTIONS: --no-flannel (deprecated) use --flannel-backend=none --cluster-secret value (deprecated) use --token [$K3S_CLUSTER_SECRET] ``` + +### Node Labels and Taints for Agents + +K3s agents can be configured with the options `--node-label` and `--node-taint` which adds a label and taint to the kubelet. The two options only add labels and/or taints at registration time, so they can only be added once and not changed after that again by running K3s commands. + +Below is an example showing how to add labels and a taint: +``` + --node-label foo=bar \ + --node-label hello=world \ + --node-taint key1=value1:NoExecute +``` + +If you want to change node labels and taints after node registration you should use `kubectl`. Refer to the official Kubernetes documentation for details on how to add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) and [node labels.](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) \ No newline at end of file diff --git a/content/k3s/latest/en/installation/node-requirements/_index.md b/content/k3s/latest/en/installation/node-requirements/_index.md index 25e2a8b3119..0d3a0aaeee5 100644 --- a/content/k3s/latest/en/installation/node-requirements/_index.md +++ b/content/k3s/latest/en/installation/node-requirements/_index.md @@ -18,6 +18,8 @@ K3s should run on just about any flavor of Linux. However, K3s is tested on the * Ubuntu 18.04 (amd64) * Raspbian Buster (armhf) +> If you are using Alpine Linux, follow [these steps]({{}}/k3s/latest/en/advanced/#additional-preparation-for-alpine-linux-setup) for additional setup. + ## Hardware Hardware requirements scale based on the size of your deployments. Minimum recommendations are outlined here. diff --git a/content/k3s/latest/en/known-issues/_index.md b/content/k3s/latest/en/known-issues/_index.md index c79f84bc653..8107e8a7451 100644 --- a/content/k3s/latest/en/known-issues/_index.md +++ b/content/k3s/latest/en/known-issues/_index.md @@ -11,3 +11,7 @@ If you plan to use K3s with docker, Docker installed via a snap package is not r **Iptables** If you are running iptables in nftables mode instead of legacy you might encounter issues. We recommend utilizing newer iptables (such as 1.6.1+) to avoid issues. + +**RootlessKit** + +Running K3s with RootlessKit is experimental and has several [known issues.]({{}}/k3s/latest/en/advanced/#known-issues-with-rootlesskit) diff --git a/content/k3s/latest/en/networking/_index.md b/content/k3s/latest/en/networking/_index.md index f7a37ed7354..d4f780d8dc5 100644 --- a/content/k3s/latest/en/networking/_index.md +++ b/content/k3s/latest/en/networking/_index.md @@ -12,27 +12,26 @@ Please reference the [Node Requirements]({{< baseurl >}}/k3s/latest/en/installat CoreDNS ------- -CoreDNS is deployed on start of the agent, to disable run each server with the `--no-deploy coredns` option. +CoreDNS is deployed on start of the agent. To disable, run each server with the `--no-deploy coredns` option. -If you don't install CoreDNS you will need to install a cluster DNS provider yourself. +If you don't install CoreDNS, you will need to install a cluster DNS provider yourself. Traefik Ingress Controller -------------------------- -Traefik is deployed by default when starting the server. For more information see [Auto Deploying Manifests]({{< baseurl >}}/k3s/latest/en/configuration/#auto-deploying-manifests). The default config file is found in `/var/lib/rancher/k3s/server/manifests/traefik.yaml` and any changes made to this file will automatically be deployed to Kubernetes in a manner similar to `kubectl apply`. +[Traefik](https://traefik.io/) is a modern HTTP reverse proxy and load balancer made to deploy microservices with ease. It simplifies networking complexity while designing, deploying, and running applications. + +Traefik is deployed by default when starting the server. For more information see [Auto Deploying Manifests]({{< baseurl >}}/k3s/latest/en/advanced/#auto-deploying-manifests). The default config file is found in `/var/lib/rancher/k3s/server/manifests/traefik.yaml` and any changes made to this file will automatically be deployed to Kubernetes in a manner similar to `kubectl apply`. The Traefik ingress controller will use ports 80, 443, and 8080 on the host (i.e. these will not be usable for HostPort or NodePort). -You can tweak traefik to meet your needs by setting options in the traefik.yaml file. -Reference the official [Traefik for Helm Configuration Parameters](https://github.com/helm/charts/tree/master/stable/traefik#configuration) readme for more information. +You can tweak traefik to meet your needs by setting options in the traefik.yaml file. Refer to the official [Traefik for Helm Configuration Parameters](https://github.com/helm/charts/tree/master/stable/traefik#configuration) readme for more information. To disable it, start each server with the `--no-deploy traefik` option. Service Load Balancer --------------------- -K3s includes a basic service load balancer that uses available host ports. If you try to create -a load balancer that listens on port 80, for example, it will try to find a free host in the cluster -for port 80. If no port is available the load balancer will stay in Pending. +K3s includes a basic service load balancer that uses available host ports. If you try to create a load balancer that listens on port 80, for example, it will try to find a free host in the cluster for port 80. If no port is available, the load balancer will stay in Pending. -To disable the embedded load balancer run the server with the `--no-deploy servicelb` option. This is necessary if you wish to run a different load balancer, such as MetalLB. +To disable the embedded load balancer, run the server with the `--no-deploy servicelb` option. This is necessary if you wish to run a different load balancer, such as MetalLB. \ No newline at end of file diff --git a/content/k3s/latest/en/quick-start/_index.md b/content/k3s/latest/en/quick-start/_index.md index e4e8156bf34..8ec057e36a0 100644 --- a/content/k3s/latest/en/quick-start/_index.md +++ b/content/k3s/latest/en/quick-start/_index.md @@ -3,7 +3,9 @@ title: "Quick-Start Guide" weight: 10 --- ->**Note:** This guide will help you quickly launch a cluster with default options. The [installation section](../installation) covers in greater detail how K3s can be set up. +This guide will help you quickly launch a cluster with default options. The [installation section](../installation) covers in greater detail how K3s can be set up. + +For information on how K3s components work together, refer to the [architecture section.]({{}}/k3s/latest/en/architecture/#high-availability-with-an-external-db) > New to Kubernetes? The official Kubernetes docs already have some great tutorials outlining the basics [here](https://kubernetes.io/docs/tutorials/kubernetes-basics/). @@ -18,7 +20,7 @@ After running this installation: * The K3s service will be configured to automatically restart after node reboots or if the process crashes or is killed * Additional utilities will be installed, including `kubectl`, `crictl`, `ctr`, `k3s-killall.sh`, and `k3s-uninstall.sh` -* A kubeconfig file will be written to `/etc/rancher/k3s/k3s.yaml` and the kubectl installed by K3s will automatically use it +* A [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file will be written to `/etc/rancher/k3s/k3s.yaml` and the kubectl installed by K3s will automatically use it To install on worker nodes and add them to the cluster, run the installation script with the `K3S_URL` and `K3S_TOKEN` environment variables. Here is an example showing how to join a worker node: diff --git a/content/k3s/latest/en/storage/_index.md b/content/k3s/latest/en/storage/_index.md index a567420905b..790cbd04e38 100644 --- a/content/k3s/latest/en/storage/_index.md +++ b/content/k3s/latest/en/storage/_index.md @@ -5,7 +5,11 @@ weight: 30 When deploying an application that needs to retain data, you’ll need to create persistent storage. Persistent storage allows you to store application data external from the pod running your application. This storage practice allows you to maintain application data, even if the application’s pod fails. -# Local Storage Provider +A persistent volume (PV) is a piece of storage in the Kubernetes cluster, while a persistent volume claim (PVC) is a request for storage. For details on how PVs and PVCs work, refer to the official Kubernetes documentation on [storage.](https://kubernetes.io/docs/concepts/storage/volumes/) + +This page describes how to set up persistent storage with a local storage provider, or with [Longhorn.](#setting-up-longhorn) + +# Setting up the Local Storage Provider K3s comes with Rancher's Local Path Provisioner and this enables the ability to create persistent volume claims out of the box using local storage on the respective node. Below we cover a simple example. For more information please reference the official documentation [here](https://github.com/rancher/local-path-provisioner/blob/master/README.md#usage). Create a hostPath backed persistent volume claim and a pod to utilize it: @@ -51,19 +55,33 @@ spec: claimName: local-path-pvc ``` -Apply the yaml `kubectl create -f pvc.yaml` and `kubectl create -f pod.yaml` +Apply the yaml: -Confirm the PV and PVC are created. `kubectl get pv` and `kubectl get pvc` The status should be Bound for each. +``` +kubectl create -f pvc.yaml +kubectl create -f pod.yaml +``` -# Longhorn +Confirm the PV and PVC are created: + +``` +kubectl get pv +kubectl get pvc +``` + +The status should be Bound for each. + +# Setting up Longhorn [comment]: <> (pending change - longhorn may support arm64 and armhf in the future.) > **Note:** At this time Longhorn only supports amd64. -K3s supports [Longhorn](https://github.com/longhorn/longhorn). Below we cover a simple example. For more information please reference the official documentation [here](https://github.com/longhorn/longhorn/blob/master/README.md). +K3s supports [Longhorn](https://github.com/longhorn/longhorn). Longhorn is an open-source distributed block storage system for Kubernetes. -Apply the longhorn.yaml to install Longhorn. +Below we cover a simple example. For more information, refer to the official documentation [here](https://github.com/longhorn/longhorn/blob/master/README.md). + +Apply the longhorn.yaml to install Longhorn: ``` kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml @@ -71,13 +89,18 @@ kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/depl Longhorn will be installed in the namespace `longhorn-system`. -Before we create a PVC, we will create a storage class for longhorn with this yaml. +Before we create a PVC, we will create a storage class for Longhorn with this yaml: ``` kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/master/examples/storageclass.yaml ``` -Now, apply the following yaml to create the PVC and pod with `kubectl create -f pvc.yaml` and `kubectl create -f pod.yaml` +Apply the yaml to create the PVC and pod: + +``` +kubectl create -f pvc.yaml +kubectl create -f pod.yaml +``` ### pvc.yaml @@ -119,4 +142,11 @@ spec: claimName: longhorn-volv-pvc ``` -Confirm the PV and PVC are created. `kubectl get pv` and `kubectl get pvc` The status should be Bound for each. +Confirm the PV and PVC are created: + +``` +kubectl get pv +kubectl get pvc +``` + +The status should be Bound for each. diff --git a/content/k3s/latest/en/upgrades/_index.md b/content/k3s/latest/en/upgrades/_index.md index 62d3dd47cd8..3ce3a0591a3 100644 --- a/content/k3s/latest/en/upgrades/_index.md +++ b/content/k3s/latest/en/upgrades/_index.md @@ -3,7 +3,11 @@ title: "Upgrades" weight: 25 --- ->**Note:** When upgrading, upgrade server nodes first one at a time then any worker nodes. +You can upgrade K3s by using the installation script, or by manually installing the binary of the desired version. + +>**Note:** When upgrading, upgrade server nodes first one at a time, then any worker nodes. + +### Upgrade K3s Using the Installation Script To upgrade K3s from an older version you can re-run the installation script using the same flags, for example: @@ -17,6 +21,8 @@ If you want to upgrade to specific version you can run the following command: curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=vX.Y.Z-rc1 sh - ``` +### Manually Upgrade K3s Using the Binary + Or to manually upgrade K3s: 1. Download the desired version of K3s from [releases](https://github.com/rancher/k3s/releases/latest) @@ -24,6 +30,8 @@ Or to manually upgrade K3s: 3. Stop the old version 4. Start the new version +### Restarting K3s + Restarting K3s is supported by the installation script for systemd and openrc. To restart manually for systemd use: ```sh diff --git a/static/img/rancher/k3s-ha-architecture.svg b/static/img/rancher/k3s-ha-architecture.svg new file mode 100644 index 00000000000..70493a11a0c --- /dev/null +++ b/static/img/rancher/k3s-ha-architecture.svg @@ -0,0 +1,3 @@ + + +
External Traffic
External Traffic
kubectl get pods
[Not supported by viewer]
K3s User
K3s User
Load
Balancer
[Not supported by viewer]
K3s
Server
[Not supported by viewer]

Server
Node
[Not supported by viewer]

Server
Node
[Not supported by viewer]

Server
Node
[Not supported by viewer]
External
Database
[Not supported by viewer]
K3s
Agents
[Not supported by viewer]
Agent
Node
[Not supported by viewer]
Agent
Node
[Not supported by viewer]
Agent
Node
[Not supported by viewer]
Load
Balancer
[Not supported by viewer]
also called worker nodes
also called worker nodes
Example configuration
for nodes running your apps and services
[Not supported by viewer] \ No newline at end of file diff --git a/static/img/rancher/k3s-single-node-server-architecture.svg b/static/img/rancher/k3s-single-node-server-architecture.svg new file mode 100644 index 00000000000..00bf13979ec --- /dev/null +++ b/static/img/rancher/k3s-single-node-server-architecture.svg @@ -0,0 +1,3 @@ + + +
External Traffic
External Traffic
K3s
Server
[Not supported by viewer]

Server
Node
[Not supported by viewer]
Embedded
SQLite
Database
[Not supported by viewer]
K3s
Agents
[Not supported by viewer]
Agent
Node
[Not supported by viewer]
Agent
Node
[Not supported by viewer]
Agent
Node
[Not supported by viewer]
Load
Balancer
[Not supported by viewer]
also called worker nodes
also called worker nodes
Example configuration
for nodes running your apps and services
[Not supported by viewer]
kubectl get pods
[Not supported by viewer]
K3s User
K3s User \ No newline at end of file From d2ecf84a98e93ffb417b3f8934af7a1cdb288c43 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Fri, 3 Jan 2020 09:46:53 -0700 Subject: [PATCH 73/82] Remove page that was combined with advanced options --- content/k3s/latest/en/configuration/_index.md | 167 ------------------ 1 file changed, 167 deletions(-) delete mode 100644 content/k3s/latest/en/configuration/_index.md diff --git a/content/k3s/latest/en/configuration/_index.md b/content/k3s/latest/en/configuration/_index.md deleted file mode 100644 index 4173c2092c8..00000000000 --- a/content/k3s/latest/en/configuration/_index.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: "Configuration Info" -weight: 50 ---- - -This section contains information on using K3s with various configurations. - - -Auto-Deploying Manifests ------------------------- - -Any file found in `/var/lib/rancher/k3s/server/manifests` will automatically be deployed to -Kubernetes in a manner similar to `kubectl apply`. - -It is also possible to deploy Helm charts. K3s supports a CRD controller for installing charts. A YAML file specification can look as following (example taken from `/var/lib/rancher/k3s/server/manifests/traefik.yaml`): - -```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: traefik - namespace: kube-system -spec: - chart: stable/traefik - set: - rbac.enabled: "true" - ssl.enabled: "true" -``` - -Keep in mind that `namespace` in your HelmChart resource metadata section should always be `kube-system`, because the K3s deploy controller is configured to watch this namespace for new HelmChart resources. - -If you want to specify the namespace for the actual Helm release, you can do that using `targetNamespace` key under the `spec` directive, as shown in the configuration example below. - -Also note that besides `set`, you can also use `valuesContent` under the `spec` directive. And it's okay to use both of them: - -```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: grafana - namespace: kube-system -spec: - chart: stable/grafana - targetNamespace: monitoring - set: - adminPassword: "NotVerySafePassword" - valuesContent: |- - image: - tag: master - env: - GF_EXPLORE_ENABLED: true - adminUser: admin - sidecar: - datasources: - enabled: true -``` - -K3s versions `<= v0.5.0` used `k3s.cattle.io` for the api group of helmcharts, this has been changed to `helm.cattle.io` for later versions. - -Using the helm CRD ---------------------- - -You can deploy a 3rd party helm chart using an example like this: - -```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: nginx - namespace: kube-system -spec: - chart: nginx - repo: https://charts.bitnami.com/bitnami - targetNamespace: default -``` - -You can install a specific version of a helm chart using an example like this: - -```yaml -apiVersion: helm.cattle.io/v1 -kind: HelmChart -metadata: - name: stable/nginx-ingress - namespace: kube-system -spec: - chart: nginx-ingress - version: 1.24.4 - targetNamespace: default -``` - -Accessing Cluster from Outside ------------------------------ - -Copy `/etc/rancher/k3s/k3s.yaml` on your machine located outside the cluster as `~/.kube/config`. Then replace -"127.0.0.1" with the IP or name of your K3s server. `kubectl` can now manage your K3s cluster. - -Node Registration ------------------ - -Agents will register with the server using the node cluster secret along with a randomly generated -password for the node, stored at `/etc/rancher/node/password`. The server will -store the passwords for individual nodes at `/var/lib/rancher/k3s/server/cred/node-passwd`, and any -subsequent attempts must use the same password. If the `/etc/rancher/node` directory of an agent is removed the -password file should be recreated for the agent, or the entry removed from the server. A unique node -id can be appended to the hostname by launching k3s servers or agents using the `--with-node-id` flag. - -Containerd and Docker ----------- - -K3s includes and defaults to containerd. If you want to use Docker instead of containerd then you simply need to run the agent with the `--docker` flag. - -K3s will generate config.toml for containerd in `/var/lib/rancher/k3s/agent/etc/containerd/config.toml`, for advanced customization for this file you can create another file called `config.toml.tmpl` in the same directory and it will be used instead. - -The `config.toml.tmpl` will be treated as a Golang template file, and the `config.Node` structure is being passed to the template, the following is an example on how to use the structure to customize the configuration file https://github.com/rancher/k3s/blob/master/pkg/agent/templates/templates.go#L16-L32 - -Rootless (Experimental) --------- - -_**WARNING**:_ Experimental feature - -Initial rootless support has been added but there are a series of significant usability issues surrounding it. -We are releasing the initial support for those interested in rootless and hopefully some people can help to -improve the usability. First ensure you have proper setup and support for user namespaces. Refer to the -[requirements section](https://github.com/rootless-containers/rootlesskit#setup) in RootlessKit for instructions. -In short, latest Ubuntu is your best bet for this to work. - - -**Issues w/ Rootless**: - -* **Ports** - - When running rootless a new network namespace is created. This means that K3s instance is running with networking - fairly detached from the host. The only way to access services run in K3s from the host is to setup port forwards - to the K3s network namespace. We have a controller that will automatically bind 6443 and service port below 1024 to the host with an offset of 10000. - - That means service port 80 will become 10080 on the host, but 8080 will become 8080 without any offset. - - Currently, only `LoadBalancer` services are automatically bound. - -* **Daemon lifecycle** - - Once you kill K3s and then start a new instance of K3s it will create a new network namespace, but it doesn't kill the old pods. So you are left - with a fairly broken setup. This is the main issue at the moment, how to deal with the network namespace. - - The issue is tracked in https://github.com/rootless-containers/rootlesskit/issues/65 - -* **Cgroups** - - Cgroups are not supported - -**Running w/ Rootless**: - -Just add `--rootless` flag to either server or agent. So run `k3s server --rootless` and then look for the message -`Wrote kubeconfig [SOME PATH]` for where your kubeconfig to access you cluster is. Be careful, if you use `-o` to write -the kubeconfig to a different directory it will probably not work. This is because the K3s instance in running in a different -mount namespace. - -Node Labels and Taints ----------------------- - -K3s agents can be configured with the options `--node-label` and `--node-taint` which adds a label and taint to the kubelet. The two options only add labels and/or taints at registration time, so they can only be added once and not changed after that again by running K3s. If you want to change node labels and taints after node registration you should use `kubectl`. Below is an example showing how to add labels and a taint: -``` - --node-label foo=bar \ - --node-label hello=world \ - --node-taint key1=value1:NoExecute -``` - From 0f5aa51cecb75790261d340560653fdc60c9fd95 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Fri, 3 Jan 2020 11:53:29 -0700 Subject: [PATCH 74/82] Say that read-only system project access is needed for configuring Isito viz access --- .vscode/settings.json | 1 - .../rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) delete mode 100644 .vscode/settings.json diff --git a/.vscode/settings.json b/.vscode/settings.json deleted file mode 100644 index 0967ef424bc..00000000000 --- a/.vscode/settings.json +++ /dev/null @@ -1 +0,0 @@ -{} diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md index eb6f3c20fa7..cf828fa7fed 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md @@ -33,6 +33,8 @@ By default, the Kiali and Jaeger visualizations are restricted to the cluster o Rancher supports giving groups permission to access Kiali and Jaeger, but not individuals. +> To configure permissions for Jaeger and Kiali, you must have at least read-only [access]({{}}/rancher/v2.x/en/project-admin/project-members/) to the `System` project. + To configure who has permission to access the Kiali and Jaeger UI, 1. Go to the cluster view and click **Tools > Istio.** From cb3146d527f5047a03d6fa0f5f0bf6a9aa76b300 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Fri, 3 Jan 2020 13:46:51 -0700 Subject: [PATCH 75/82] Delete note --- .../rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md index cf828fa7fed..eb6f3c20fa7 100644 --- a/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/tools/istio/rbac/_index.md @@ -33,8 +33,6 @@ By default, the Kiali and Jaeger visualizations are restricted to the cluster o Rancher supports giving groups permission to access Kiali and Jaeger, but not individuals. -> To configure permissions for Jaeger and Kiali, you must have at least read-only [access]({{}}/rancher/v2.x/en/project-admin/project-members/) to the `System` project. - To configure who has permission to access the Kiali and Jaeger UI, 1. Go to the cluster view and click **Tools > Istio.** From eb288454234f077931f0f2cbf1ff1f9b7e71b498 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Fri, 3 Jan 2020 19:19:00 -0700 Subject: [PATCH 76/82] Reorganize project administration section --- .../projects-and-namespaces/_index.md | 33 +++-- .../rancher/v2.x/en/k8s-in-rancher/_index.md | 2 +- .../en/k8s-in-rancher/pipelines/_index.md | 4 +- .../pipelines/example-repos/_index.md | 4 +- content/rancher/v2.x/en/overview/_index.md | 2 +- .../rancher/v2.x/en/project-admin/_index.md | 6 +- .../project-admin/editing-projects/_index.md | 125 ------------------ .../en/project-admin/namespaces/_index.md | 19 +-- .../{tools => }/pipelines/_index.md | 18 ++- .../pipelines/docs-for-v2.0.x/_index.md | 1 + .../pod-security-policies/_index.md | 31 +++++ .../project-admin/project-members/_index.md | 42 +++++- .../project-admin/resource-quotas/_index.md | 111 +++------------- .../override-container-default/_index.md | 43 ++++++ .../override-namespace-default/_index.md | 34 +++++ .../quota-type-reference/_index.md | 24 ++++ .../quotas-for-projects/_index.md | 39 ++++++ .../v2.x/en/project-admin/tools/_index.md | 65 +++------ .../en/project-admin/tools/alerts/_index.md | 12 +- .../en/project-admin/tools/logging/_index.md | 2 + .../project-admin/tools/monitoring/_index.md | 31 +++-- 21 files changed, 325 insertions(+), 323 deletions(-) delete mode 100644 content/rancher/v2.x/en/project-admin/editing-projects/_index.md rename content/rancher/v2.x/en/project-admin/{tools => }/pipelines/_index.md (96%) rename content/rancher/v2.x/en/project-admin/{tools => }/pipelines/docs-for-v2.0.x/_index.md (98%) create mode 100644 content/rancher/v2.x/en/project-admin/pod-security-policies/_index.md create mode 100644 content/rancher/v2.x/en/project-admin/resource-quotas/override-container-default/_index.md create mode 100644 content/rancher/v2.x/en/project-admin/resource-quotas/override-namespace-default/_index.md create mode 100644 content/rancher/v2.x/en/project-admin/resource-quotas/quota-type-reference/_index.md create mode 100644 content/rancher/v2.x/en/project-admin/resource-quotas/quotas-for-projects/_index.md diff --git a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md index 371303c96c9..262489ebdf3 100644 --- a/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/projects-and-namespaces/_index.md @@ -7,9 +7,21 @@ aliases: - /rancher/v2.x/en/tasks/projects/ - /rancher/v2.x/en/tasks/projects/create-project/ - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/ + - /rancher/v2.x/en/tasks/projects/create-project/ --- -## Projects +This section describes how projects and namespaces work with Rancher. It covers the following topics: + +- [About projects](#about-projects) + - [The cluster's default project](#the-cluster-s-default-project) + - [The system project](#the-system-project) +- [Project authorization](#project-authorization) +- [Pod security policies](#pod-security-policies) +- [Creating projects](#creating-projects) +- [Switching between clusters and projects](#switching-between-clusters-and-projects) +- [Namespaces](#namespaces) + +# About Projects A project is a group of multiple [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) and access control policies within a cluster. A project is a concept introduced by Rancher, not Kubernetes, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.x/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.x/en/k8s-in-rancher/) @@ -34,12 +46,11 @@ When you create a cluster, two projects are automatically created within it: - [Default Project](#default-project) - [System Project](#system-project) +### The Cluster's Default Project -### Default Project +When you provision a cluster with Rancher, it automatically creates a `default` project for the cluster. This is a project you can use to get started with your cluster, but you can always delete it and replace it with projects that have more descriptive names. -When you provision a cluster, it automatically creates a `default` project for the cluster. This is a project you can use to get started with your cluster, but you can always delete it and replace it with projects that have more descriptive names. - -### System Project +### The System Project _Available as of v2.0.7_ @@ -61,18 +72,18 @@ The `system` project: > >The `system` project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health. -### Authorization +# Project Authorization Non-administrative users are only authorized for project access after an administrator, cluster owner or cluster member explicitly adds them to the project's **Members** tab. >**Exception:** > Non-administrative users can access projects that they create themselves. -### Pod Security Policies +# Pod Security Policies -Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the project level in addition to the cluster level. 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]({{}}/rancher/v2.x/en/project-admin/pod-security-policies) in addition to the [cluster level.](../pod-security-policy) However, as a best practice, we recommend applying Pod Security Policies at the cluster level. -### Creating Projects +# Creating Projects 1. From the **Global** view, choose **Clusters** from the main menu. From the **Clusters** page, open the cluster from which you want to create a project. @@ -137,7 +148,7 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h **Result:** Your project is created. You can view it from the cluster's **Projects/Namespaces** view. -## Switching between Clusters/Projects +# Switching between Clusters and Projects To switch between clusters and projects, use the **Global** drop-down available in the main menu. @@ -148,7 +159,7 @@ Alternatively, you can switch between projects and clusters using the main menu. - To switch between clusters, open the **Global** view and select **Clusters** from the main menu. Then open a cluster. - To switch between projects, open a cluster, and then select **Projects/Namespaces** from the main menu. Select the link for the project that you want to open. -## Namespaces +# Namespaces Within Rancher, you can further divide projects into different [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which are virtual clusters within a project backed by a physical cluster. Should you require another level of organization beyond projects and the `default` namespace, you can use multiple namespaces to isolate applications and resources. diff --git a/content/rancher/v2.x/en/k8s-in-rancher/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/_index.md index 1d79b6056fe..08fd6927811 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/_index.md @@ -56,7 +56,7 @@ For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/k8 ## Pipelines -After your project has been [configured to a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), you can add the repositories and start configuring a pipeline for each repository. +After your project has been [configured to a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/#version-control-providers), you can add the repositories and start configuring a pipeline for each repository. For more information, see [Pipelines]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/). diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md index 7c6071500ed..e39437f23a7 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md @@ -11,7 +11,7 @@ aliases: >- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1. >- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x). -Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments. +Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments. If you can access a project, you can enable repositories to start building pipelines. Only an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can authorize version control providers. @@ -233,7 +233,7 @@ timeout: 30 Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** (In versions prior to v2.3.0, go to the **Pipelines** tab.) Find your pipeline and select the vertical **Ellipsis (...) > Run**. -During this initial run, your pipeline is tested, and the following [pipeline components]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#how-pipelines-work) are deployed to your project as workloads in a new namespace dedicated to the pipeline: +During this initial run, your pipeline is tested, and the following [pipeline components]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/#how-pipelines-work) are deployed to your project as workloads in a new namespace dedicated to the pipeline: - `docker-registry` - `jenkins` diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example-repos/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example-repos/_index.md index be9733f856a..00ddc2f207f 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example-repos/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/example-repos/_index.md @@ -11,7 +11,7 @@ Rancher ships with several example repositories that you can use to familiarize - Maven - php -> **Note:** The example repositories are only available if you have not [configured a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines). +> **Note:** The example repositories are only available if you have not [configured a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines). ## Configure Repositories @@ -67,4 +67,4 @@ After enabling an example repository, run the pipeline to see how it works. ## What's Next? -For detailed information about setting up your own pipeline for your repository, [configure a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines), [enable a repository](#configure-repositories) and finally [configure your pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#pipeline-configuration). +For detailed information about setting up your own pipeline for your repository, [configure a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines), [enable a repository](#configure-repositories) and finally [configure your pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#pipeline-configuration). diff --git a/content/rancher/v2.x/en/overview/_index.md b/content/rancher/v2.x/en/overview/_index.md index 0656ec3e7e2..7a913064129 100644 --- a/content/rancher/v2.x/en/overview/_index.md +++ b/content/rancher/v2.x/en/overview/_index.md @@ -38,7 +38,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and - **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{}}/rancher/v2.x/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{}}/rancher/v2.x/en/cluster-admin/upgrading-kubernetes) - **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{}}/rancher/v2.x/en/catalog/) that make it easy to repeatedly deploy applications. - **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{}}/rancher/v2.x/en/project-admin/) and for [managing applications within projects.]({{}}/rancher/v2.x/en/k8s-in-rancher/) -- **Pipelines:** Setting up a [pipeline]({{}}/rancher/v2.x/en/project-admin/tools/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects. +- **Pipelines:** Setting up a [pipeline]({{}}/rancher/v2.x/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects. - **Istio:** Our [integration with Istio]({{}}/rancher/v2.x/en/cluster-admin/tools/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing. ### Working with Cloud Infrastructure diff --git a/content/rancher/v2.x/en/project-admin/_index.md b/content/rancher/v2.x/en/project-admin/_index.md index 9d024be480f..8a37b2a1383 100644 --- a/content/rancher/v2.x/en/project-admin/_index.md +++ b/content/rancher/v2.x/en/project-admin/_index.md @@ -1,6 +1,9 @@ --- title: Project Administration weight: 2500 +aliases: + - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/ + - /rancher/v2.x/en/project-admin/editing-projects/ --- _Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications. @@ -18,10 +21,11 @@ You can use projects to perform actions like: - [Assign users access to a group of namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/project-members) - Assign users [specific roles in a project]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/) -- [Edit project settings]({{< baseurl >}}/rancher/v2.x/en/project-admin/editing-projects/) - [Set resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/) - [Manage namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/) - [Configure tools]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/) +- [Set up pipelines for continuous integration and deployment]({{}}/rancher/v2.x/en/project-admin/pipelines) +- [Configure pod security policies]({{}}/rancher/v2.x/en/project-admin/pod-security-policies) ### Authorization diff --git a/content/rancher/v2.x/en/project-admin/editing-projects/_index.md b/content/rancher/v2.x/en/project-admin/editing-projects/_index.md deleted file mode 100644 index 86129458b8f..00000000000 --- a/content/rancher/v2.x/en/project-admin/editing-projects/_index.md +++ /dev/null @@ -1,125 +0,0 @@ ---- -title: Editing Projects -weight: 2510 -aliases: - - /rancher/v2.x/en/tasks/projects/create-project/ - - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/ ---- - -After projects are created, there are certain aspects that can be changed later. - -## Adding Members - -Following project creation, you can add users as project members so that they can access its resources. - -1. From the **Global** view, open the project that you want to add members to. - -2. From the main menu, select **Members**. Then click **Add Member**. - -3. Search for the user or group that you want to add to the project. - - If external authentication is configured: - - - Rancher returns users from your external authentication source as you type. - - - A drop-down allows you to add groups instead of individual users. The dropdown only lists groups that you, the logged in user, are included in. - - >**Note:** If you are logged in as a local user, external users do not display in your search results. - -1. Assign the user or group **Project** roles. - - [What are Project Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/) - - >**Notes:** - > - >- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned. - > - >- For `Custom` roles, you can modify the list of individual roles available for assignment. - > - > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles). - > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/). - -**Result:** The chosen users are added to the project. - -- To revoke project membership, select the user and click **Delete**. This action deletes membership, not the user. -- To modify a user's roles in the project, delete them from the project, and then re-add them with modified roles. - -## Editing the Pod Security Policy - ->**Note:** These cluster options are only available for [clusters that Rancher has launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). - -You can always assign a PSP to an existing project if you didn't assign one during creation. - ->**Prerequisites:** -> -> - Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). -> - Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/#adding-changing-a-pod-security-policy). - -1. From the **Global** view, find the cluster containing the project you want to apply a PSP to. - -1. From the main menu, select **Projects/Namespaces**. - -3. Find the project that you want to add a PSP to. From that project, select **Vertical Ellipsis (...) > Edit**. - -4. From the **Pod Security Policy** drop-down, select the PSP you want to apply to the project. - Assigning a PSP to a project will: - - - Override the cluster's default PSP. - - Apply the PSP to the project. - - Apply the PSP to any namespaces you add to the project later. - -5. Click **Save**. - -**Result:** The PSP is applied to the project and any namespaces added to the project. - ->**Note:** Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP. - -## Editing Resource Quotas - -_Available as of v2.0.1_ - -Edit [resource quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) when: - -- You want to limit the resources that a project and its namespaces can use. -- You want to scale the resources available to a project up or down when a research quota is already in effect. - -1. From the **Global** view, open the cluster containing the project to which you want to apply a resource quota. - -1. From the main menu, select **Projects/Namespaces**. - -1. Find the project that you want to add a resource quota to. From that project, select **Ellipsis (...) > Edit**. - -1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas. - -1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#resource-quota-types). - -1. Enter values for the **Project Limit** and the **Namespace Default Limit**. - - | Field | Description | - | ----------------------- | -------------------------------------------------------------------------------------------------------- | - | Project Limit | The overall resource limit for the project. | - | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project. The combined limit of all project namespaces shouldn't exceed the project limit. | - -1. **Optional:** Add more quotas. - -1. Click **Create**. - -**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, Rancher won't let you save your changes. - - -## Editing Container Default Resource Limit - -_Available as of v2.2.0_ - -Edit [container default resource limit]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#setting-container-default-resource-limit) when: - -- You have a CPU or Memory resource quota set on a project, and want to supply the corresponding default values for a container. -- You want to edit the default container resource limit. - -1. From the **Global** view, open the cluster containing the project to which you want to edit the container default resource limit. - -1. From the main menu, select **Projects/Namespaces**. - -1. Find the project that you want to edit the container default resource limit. From that project, select **Ellipsis (...) > Edit**. - -1. Expand **Container Default Resource Limit** and edit the values. diff --git a/content/rancher/v2.x/en/project-admin/namespaces/_index.md b/content/rancher/v2.x/en/project-admin/namespaces/_index.md index 96c03538fae..ef84e757bbe 100644 --- a/content/rancher/v2.x/en/project-admin/namespaces/_index.md +++ b/content/rancher/v2.x/en/project-admin/namespaces/_index.md @@ -60,21 +60,6 @@ Cluster admins and members may occasionally need to move a namespace to another ### Editing Namespace Resource Quotas -If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) configured for a project, you can override the namespace default limit to provide a specific namespace with access to more (or less) project resources. +You can always override the namespace default limit to provide a specific namespace with access to more (or less) project resources. -1. From the **Global** view, open the cluster that contains the namespace for which you want to edit the resource quota. - -1. From the main menu, select **Projects/Namespaces**. - -1. Find the namespace for which you want to edit the resource quota. Select **Ellipsis (...) > Edit**. - -1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured project limits. - - For more information about each **Resource Type**, see [Resource Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types). - - >**Note:** - > - >- If a resource quota is not configured for the project, these options will not be available. - >- If you enter limits that exceed the configured project limits, Rancher will not let you save your edits. - -**Result:** The namespace's default resource quota is overwritten with your override. +For more information, see how to [edit namespace resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin//resource-quotas/override-namespace-default/#editing-namespace-resource-quotas). \ No newline at end of file diff --git a/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md b/content/rancher/v2.x/en/project-admin/pipelines/_index.md similarity index 96% rename from content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md rename to content/rancher/v2.x/en/project-admin/pipelines/_index.md index 53c21a827f6..f29403e4053 100644 --- a/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md +++ b/content/rancher/v2.x/en/project-admin/pipelines/_index.md @@ -1,13 +1,29 @@ --- title: Rancher's CI/CD Pipelines description: Use Rancher’s CI/CD pipeline to automatically checkout code, run builds or scripts, publish Docker images, and deploy software to users -weight: 2529 +weight: 4000 aliases: - /rancher/v2.x/en/concepts/ci-cd-pipelines/ - /rancher/v2.x/en/tasks/pipelines/ - /rancher/v2.x/en/tools/pipelines/ - /rancher/v2.x/en/tools/pipelines/configurations/ + - /rancher/v2.x/en/project-admin/tools/pipelines --- +Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline. + +To set up a pipeline, you'll first need to authorize Rancher using your GitHub settings. Directions are provided in the Rancher UI. After authorizing Rancher in GitHub, provide Rancher with a client ID and secret to authenticate. + +After configuring Rancher and GitHub, you can deploy containers running Jenkins to automate a pipeline execution: + +- Build your application from code to image. +- Validate your builds. +- Deploy your build images to your cluster. +- Run unit tests. +- Run regression tests. + + + + A _pipeline_ is a software delivery process that is broken into different stages and steps. Setting up a pipeline can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects. diff --git a/content/rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x/_index.md b/content/rancher/v2.x/en/project-admin/pipelines/docs-for-v2.0.x/_index.md similarity index 98% rename from content/rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x/_index.md rename to content/rancher/v2.x/en/project-admin/pipelines/docs-for-v2.0.x/_index.md index 0414cfa3e90..9daa8dad7c4 100644 --- a/content/rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x/_index.md +++ b/content/rancher/v2.x/en/project-admin/pipelines/docs-for-v2.0.x/_index.md @@ -3,6 +3,7 @@ title: v2.0.x Pipeline Documentation weight: 9000 aliases: - /rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x + - /rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x --- >**Note:** This section describes the pipeline feature as implemented in Rancher v2.0.x. If you are using Rancher v2.1 or later, where pipelines have been significantly improved, please refer to the new documentation for [v2.1 or later]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines). diff --git a/content/rancher/v2.x/en/project-admin/pod-security-policies/_index.md b/content/rancher/v2.x/en/project-admin/pod-security-policies/_index.md new file mode 100644 index 00000000000..e92356c11c6 --- /dev/null +++ b/content/rancher/v2.x/en/project-admin/pod-security-policies/_index.md @@ -0,0 +1,31 @@ +--- +title: Pod Security Policies +weight: 5600 +--- + +> These cluster options are only available for [clusters in which Rancher has launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/). + +You can always assign a pod security policy (PSP) to an existing project if you didn't assign one during creation. + +### Prerequisites + +- Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). +- Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [Existing Cluster: Adding a Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/#adding-changing-a-pod-security-policy). + +### Applying a Pod Security Policy + +1. From the **Global** view, find the cluster containing the project you want to apply a PSP to. +1. From the main menu, select **Projects/Namespaces**. +1. Find the project that you want to add a PSP to. From that project, select **Vertical Ellipsis (...) > Edit**. +1. From the **Pod Security Policy** drop-down, select the PSP you want to apply to the project. + Assigning a PSP to a project will: + + - Override the cluster's default PSP. + - Apply the PSP to the project. + - Apply the PSP to any namespaces you add to the project later. + +1. Click **Save**. + +**Result:** The PSP is applied to the project and any namespaces added to the project. + +>**Note:** Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked to determine if they comply with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP. \ No newline at end of file diff --git a/content/rancher/v2.x/en/project-admin/project-members/_index.md b/content/rancher/v2.x/en/project-admin/project-members/_index.md index 386d5b80025..00c97f2098a 100644 --- a/content/rancher/v2.x/en/project-admin/project-members/_index.md +++ b/content/rancher/v2.x/en/project-admin/project-members/_index.md @@ -8,14 +8,46 @@ aliases: If you want to provide a user with access and permissions to _specific_ projects and resources within a cluster, assign the user a project membership. +You can add members to a project as it is created, or add them to an existing project. + >**Tip:** Want to provide a user with access to _all_ projects within a cluster? See [Adding Cluster Members]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/cluster-members/) instead. -There are two contexts where you can add project members: +### Adding Members to a New Project -- [Adding Members when Creating New Projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/) +You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/) - You can add members to a project as you create it (recommended if possible). +### Adding Members to an Existing Project -- [Adding Members to an Existing Project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/) +Following project creation, you can add users as project members so that they can access its resources. - You can always add members to a project later. +1. From the **Global** view, open the project that you want to add members to. + +2. From the main menu, select **Members**. Then click **Add Member**. + +3. Search for the user or group that you want to add to the project. + + If external authentication is configured: + + - Rancher returns users from your external authentication source as you type. + + - A drop-down allows you to add groups instead of individual users. The dropdown only lists groups that you, the logged in user, are included in. + + >**Note:** If you are logged in as a local user, external users do not display in your search results. + +1. Assign the user or group **Project** roles. + + [What are Project Roles?]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/) + + >**Notes:** + > + >- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned. + > + >- For `Custom` roles, you can modify the list of individual roles available for assignment. + > + > - To add roles to the list, [Add a Custom Role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles). + > - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/locked-roles/). + +**Result:** The chosen users are added to the project. + +- To revoke project membership, select the user and click **Delete**. This action deletes membership, not the user. +- To modify a user's roles in the project, delete them from the project, and then re-add them with modified roles. \ No newline at end of file diff --git a/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md index b253dfb0fd4..155907e9876 100644 --- a/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md +++ b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md @@ -1,5 +1,5 @@ --- -title: Resource Quotas +title: Project Resource Quotas weight: 2515 aliases: - /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/ @@ -9,107 +9,40 @@ _Available as of v2.1.0_ In situations where several teams share a cluster, one team may overconsume the resources available: CPU, memory, storage, services, Kubernetes objects like pods or secrets, and so on. To prevent this overconsumption, you can apply a _resource quota_, which is a Rancher feature that limits the resources available to a project or namespace. -## Resource Quotas in Rancher +This page is a how-to guide for creating resource quotas in existing projects. -Resource quotas in Rancher include the same functionality as the [native version of Kubernetes](https://kubernetes.io/docs/concepts/policy/resource-quotas/). However, in Rancher, resource quotas have been extended so that you can apply them to [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects). +Resource quotas can also be set when a new project is created. For details, refer to the section on [creating new projects.]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/projects-and-namespaces/#creating-projects) -In a standard Kubernetes deployment, resource quotas are applied to individual namespaces. However, you cannot apply the quota to your namespaces simultaneously with a single action. Instead, the resource quota must be applied multiple times. +> Resource quotas in Rancher include the same functionality as the [native version of Kubernetes](https://kubernetes.io/docs/concepts/policy/resource-quotas/). However, in Rancher, resource quotas have been extended so that you can apply them to [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects). For details on how resource quotas work with projects in Rancher, refer to [this page.](./quotas-for-projects) -In the following diagram, a Kubernetes administrator is trying to enforce a resource quota without Rancher. The administrator wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The administrator has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually. +### Applying Resource Quotas to Existing Projects -Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace -![Native Kubernetes Resource Quota Implementation]({{< baseurl >}}/img/rancher/kubernetes-resource-quota.svg) +_Available as of v2.0.1_ -Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#overriding-the-default-limit-for-a-namespace). +Edit [resource quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) when: -The resource quota includes two limits, which you set while creating or editing a project: - +- You want to limit the resources that a project and its namespaces can use. +- You want to scale the resources available to a project up or down when a research quota is already in effect. -- **Project Limits:** +1. From the **Global** view, open the cluster containing the project to which you want to apply a resource quota. - This set of values configures an overall resource limit for the project. If you try to add a new namespace to the project, Rancher uses the limits you've set to validate that the project has enough resources to accommodate the namespace. In other words, if you try to move a namespace into a project near its resource quota, Rancher blocks you from moving the namespace. +1. From the main menu, select **Projects/Namespaces**. -- **Namespace Default Limits:** +1. Find the project that you want to add a resource quota to. From that project, select **Ellipsis (...) > Edit**. - This value is the default resource limit available for each namespace. When the resource quota is set on the project level, this limit is automatically propagated to each namespace in the project. Each namespace is bound to this default limit unless you [override it](#namespace-default-limit-overrides). +1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas. -In the following diagram, a Rancher administrator wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the administrator can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`). +1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#resource-quota-types). -Rancher: Resource Quotas Propagating to Each Namespace -![Rancher Resource Quota Implementation]({{< baseurl >}}/img/rancher/rancher-resource-quota.svg) +1. Enter values for the **Project Limit** and the **Namespace Default Limit**. -The following table explains the key differences between the two quota types. + | Field | Description | + | ----------------------- | -------------------------------------------------------------------------------------------------------- | + | Project Limit | The overall resource limit for the project. | + | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project. The combined limit of all project namespaces shouldn't exceed the project limit. | -| Rancher Resource Quotas | Kubernetes Resource Quotas | -| ---------------------------------------------------------- | -------------------------------------------------------- | -| Applies to projects and namespace. | Applies to namespaces only. | -| Creates resource pool for all namespaces in project. | Applies static resource limits to individual namespaces. | -| Applies resource quotas to namespaces through propagation. | Applies only to the assigned namespace. +1. **Optional:** Add more quotas. +1. Click **Create**. -## Creating Resource Quotas - -You can create resource quotas in the following contexts: - -- [While creating projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-projects) -- [While editing projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/#editing-resource-quotas) - -## Resource Quota Types - -When you create a resource quota, you are configuring the pool of resources available to the project. You can set the following resource limits for the following resource types. - -| Resource Type | Description | -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| CPU Limit* | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the project/namespace.1 | -| CPU Reservation* | The minimum amount of CPU (in millicores) guaranteed to the project/namespace.1 | -| Memory Limit* | The maximum amount of memory (in bytes) allocated to the project/namespace.1 | -| Memory Reservation* | The minimum amount of memory (in bytes) guaranteed to the project/namespace.1 | -| Storage Reservation | The minimum amount of storage (in gigabytes) guaranteed to the project/namespace. | -| Services Load Balancers | The maximum number of load balancers services that can exist in the project/namespace. | -| Services Node Ports | The maximum number of node port services that can exist in the project/namespace. | -| Pods | The maximum number of pods that can exist in the project/namespace in a non-terminal state (i.e., pods with a state of `.status.phase in (Failed, Succeeded)` equal to true). | -| Services | The maximum number of services that can exist in the project/namespace. | -| ConfigMaps | The maximum number of ConfigMaps that can exist in the project/namespace. | -| Persistent Volume Claims | The maximum number of persistent volume claims that can exist in the project/namespace. | -| Replications Controllers | The maximum number of replication controllers that can exist in the project/namespace. | -| Secrets | The maximum number of secrets that can exist in the project/namespace. | - ->***** When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. As of v2.2.0, a [container default resource limit](#setting-container-default-resource-limit) can be set at the same time to avoid the need to explicitly set these limits for every workload. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required. - -## Overriding the Default Limit for a Namespace - -Although the **Namespace Default Limit** propagates from the project to each namespace, in some cases, you may need to increase (or decrease) the performance for a specific namespace. In this situation, you can override the default limits by editing the namespace. - -In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it performs better. Therefore, the administrator [raises the namespace limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) for `Namespace 3` so that the namespace can access more resources. - -Namespace Default Limit Override -![Namespace Default Limit Override]({{< baseurl >}}/img/rancher/rancher-resource-quota-override.svg) - -How to: [Editing Namespace Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) - -### Editing Namespace Resource Quotas - -You can always override the namespace default limit to provide a specific namespace with access to more (or less) project resources. - -For more information, see how to [edit namespace resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/#editing-namespace-resource-quota/). - -## Setting Container Default Resource Limit - -_Available as of v2.2.0_ - -When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required. - -To avoid setting these limits on each and every container during workload creation, a default container resource limit can be specified on the namespace. - -When the default container resource limit is set at a project level, the parameter will be propagated to any namespace created in the project after the limit has been set. For any existing namespace in a project, this limit will not be automatically propagated. You will need to manually set the default container resource limit for any existing namespaces in the project in order for it to be used when creating any containers. - -> **Note:** Prior to v2.2.0, you could not launch catalog applications that did not have any limits set. With v2.2.0, you will be able to set a default container resource limit on a project and launch any catalog applications. - -Once a container default resource limit is configured on a namespace, the default will be pre-populated for any containers created in that namespace. These limits/reservations can always be overridden during workload creation. - -| Resource Type | Description | -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| CPU Limit | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the container.| -| CPU Reservation | The minimum amount of CPU (in millicores) guaranteed to the container. | -| Memory Limit | The maximum amount of memory (in bytes) allocated to the container. | -| Memory Reservation | The minimum amount of memory (in bytes) guaranteed to the container. +**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, Rancher won't let you save your changes. diff --git a/content/rancher/v2.x/en/project-admin/resource-quotas/override-container-default/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/override-container-default/_index.md new file mode 100644 index 00000000000..bd9d1517459 --- /dev/null +++ b/content/rancher/v2.x/en/project-admin/resource-quotas/override-container-default/_index.md @@ -0,0 +1,43 @@ +--- +title: Setting Container Default Resource Limits +weight: 3 +--- + +_Available as of v2.2.0_ + +When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required. + +To avoid setting these limits on each and every container during workload creation, a default container resource limit can be specified on the namespace. + +### Editing the Container Default Resource Limit + +_Available as of v2.2.0_ + +Edit [container default resource limit]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#setting-container-default-resource-limit) when: + +- You have a CPU or Memory resource quota set on a project, and want to supply the corresponding default values for a container. +- You want to edit the default container resource limit. + +1. From the **Global** view, open the cluster containing the project to which you want to edit the container default resource limit. +1. From the main menu, select **Projects/Namespaces**. +1. Find the project that you want to edit the container default resource limit. From that project, select **Ellipsis (...) > Edit**. +1. Expand **Container Default Resource Limit** and edit the values. + +### Resource Limit Propagation + +When the default container resource limit is set at a project level, the parameter will be propagated to any namespace created in the project after the limit has been set. For any existing namespace in a project, this limit will not be automatically propagated. You will need to manually set the default container resource limit for any existing namespaces in the project in order for it to be used when creating any containers. + +> **Note:** Prior to v2.2.0, you could not launch catalog applications that did not have any limits set. With v2.2.0, you can set a default container resource limit on a project and launch any catalog applications. + +Once a container default resource limit is configured on a namespace, the default will be pre-populated for any containers created in that namespace. These limits/reservations can always be overridden during workload creation. + +### Container Resource Quota Types + +The following resource limits can be configured: + +| Resource Type | Description | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| CPU Limit | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the container.| +| CPU Reservation | The minimum amount of CPU (in millicores) guaranteed to the container. | +| Memory Limit | The maximum amount of memory (in bytes) allocated to the container. | +| Memory Reservation | The minimum amount of memory (in bytes) guaranteed to the container. \ No newline at end of file diff --git a/content/rancher/v2.x/en/project-admin/resource-quotas/override-namespace-default/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/override-namespace-default/_index.md new file mode 100644 index 00000000000..0501008f985 --- /dev/null +++ b/content/rancher/v2.x/en/project-admin/resource-quotas/override-namespace-default/_index.md @@ -0,0 +1,34 @@ +--- +title: Overriding the Default Limit for a Namespace +weight: 2 +--- + +Although the **Namespace Default Limit** propagates from the project to each namespace, in some cases, you may need to increase (or decrease) the performance for a specific namespace. In this situation, you can override the default limits by editing the namespace. + +In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it performs better. Therefore, the administrator [raises the namespace limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) for `Namespace 3` so that the namespace can access more resources. + +Namespace Default Limit Override +![Namespace Default Limit Override]({{< baseurl >}}/img/rancher/rancher-resource-quota-override.svg) + +How to: [Editing Namespace Resource Quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) + +### Editing Namespace Resource Quotas + +If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) configured for a project, you can override the namespace default limit to provide a specific namespace with access to more (or less) project resources. + +1. From the **Global** view, open the cluster that contains the namespace for which you want to edit the resource quota. + +1. From the main menu, select **Projects/Namespaces**. + +1. Find the namespace for which you want to edit the resource quota. Select **Ellipsis (...) > Edit**. + +1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured project limits. + + For more information about each **Resource Type**, see [Resource Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types). + + >**Note:** + > + >- If a resource quota is not configured for the project, these options will not be available. + >- If you enter limits that exceed the configured project limits, Rancher will not let you save your edits. + +**Result:** The namespace's default resource quota is overwritten with your override. \ No newline at end of file diff --git a/content/rancher/v2.x/en/project-admin/resource-quotas/quota-type-reference/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/quota-type-reference/_index.md new file mode 100644 index 00000000000..e671a9afdb1 --- /dev/null +++ b/content/rancher/v2.x/en/project-admin/resource-quotas/quota-type-reference/_index.md @@ -0,0 +1,24 @@ +--- +title: Resource Quota Type Reference +weight: 4 +--- + +When you create a resource quota, you are configuring the pool of resources available to the project. You can set the following resource limits for the following resource types. + +| Resource Type | Description | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| CPU Limit* | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the project/namespace.1 | +| CPU Reservation* | The minimum amount of CPU (in millicores) guaranteed to the project/namespace.1 | +| Memory Limit* | The maximum amount of memory (in bytes) allocated to the project/namespace.1 | +| Memory Reservation* | The minimum amount of memory (in bytes) guaranteed to the project/namespace.1 | +| Storage Reservation | The minimum amount of storage (in gigabytes) guaranteed to the project/namespace. | +| Services Load Balancers | The maximum number of load balancers services that can exist in the project/namespace. | +| Services Node Ports | The maximum number of node port services that can exist in the project/namespace. | +| Pods | The maximum number of pods that can exist in the project/namespace in a non-terminal state (i.e., pods with a state of `.status.phase in (Failed, Succeeded)` equal to true). | +| Services | The maximum number of services that can exist in the project/namespace. | +| ConfigMaps | The maximum number of ConfigMaps that can exist in the project/namespace. | +| Persistent Volume Claims | The maximum number of persistent volume claims that can exist in the project/namespace. | +| Replications Controllers | The maximum number of replication controllers that can exist in the project/namespace. | +| Secrets | The maximum number of secrets that can exist in the project/namespace. | + +>***** When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. As of v2.2.0, a [container default resource limit](#setting-container-default-resource-limit) can be set at the same time to avoid the need to explicitly set these limits for every workload. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required. \ No newline at end of file diff --git a/content/rancher/v2.x/en/project-admin/resource-quotas/quotas-for-projects/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/quotas-for-projects/_index.md new file mode 100644 index 00000000000..73d7c180f80 --- /dev/null +++ b/content/rancher/v2.x/en/project-admin/resource-quotas/quotas-for-projects/_index.md @@ -0,0 +1,39 @@ +--- +title: How Resource Quotas Work in Rancher Projects +weight: 1 +--- + +Resource quotas in Rancher include the same functionality as the [native version of Kubernetes](https://kubernetes.io/docs/concepts/policy/resource-quotas/). However, in Rancher, resource quotas have been extended so that you can apply them to [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects). + +In a standard Kubernetes deployment, resource quotas are applied to individual namespaces. However, you cannot apply the quota to your namespaces simultaneously with a single action. Instead, the resource quota must be applied multiple times. + +In the following diagram, a Kubernetes administrator is trying to enforce a resource quota without Rancher. The administrator wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The administrator has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually. + +Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace +![Native Kubernetes Resource Quota Implementation]({{< baseurl >}}/img/rancher/kubernetes-resource-quota.svg) + +Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#overriding-the-default-limit-for-a-namespace). + +The resource quota includes two limits, which you set while creating or editing a project: + + +- **Project Limits:** + + This set of values configures an overall resource limit for the project. If you try to add a new namespace to the project, Rancher uses the limits you've set to validate that the project has enough resources to accommodate the namespace. In other words, if you try to move a namespace into a project near its resource quota, Rancher blocks you from moving the namespace. + +- **Namespace Default Limits:** + + This value is the default resource limit available for each namespace. When the resource quota is set on the project level, this limit is automatically propagated to each namespace in the project. Each namespace is bound to this default limit unless you [override it](#namespace-default-limit-overrides). + +In the following diagram, a Rancher administrator wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the administrator can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`). + +Rancher: Resource Quotas Propagating to Each Namespace +![Rancher Resource Quota Implementation]({{< baseurl >}}/img/rancher/rancher-resource-quota.svg) + +The following table explains the key differences between the two quota types. + +| Rancher Resource Quotas | Kubernetes Resource Quotas | +| ---------------------------------------------------------- | -------------------------------------------------------- | +| Applies to projects and namespace. | Applies to namespaces only. | +| Creates resource pool for all namespaces in project. | Applies static resource limits to individual namespaces. | +| Applies resource quotas to namespaces through propagation. | Applies only to the assigned namespace. \ No newline at end of file diff --git a/content/rancher/v2.x/en/project-admin/tools/_index.md b/content/rancher/v2.x/en/project-admin/tools/_index.md index 94e0c446564..0921bdc4cf6 100644 --- a/content/rancher/v2.x/en/project-admin/tools/_index.md +++ b/content/rancher/v2.x/en/project-admin/tools/_index.md @@ -1,76 +1,41 @@ --- -title: Configuring Tools +title: Tools for Logging, Monitoring, and Visibility weight: 2525 --- Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories: - -- [Alerts](#alerts) +- [Notifiers and Alerts](#notifiers-and-alerts) - [Logging](#logging) -- [Pipelines](#pipelines) - [Monitoring](#monitoring) -## Alerts +## Notifiers and Alerts -To keep your clusters and applications healthy and driving your organizational productivity forward, you need stay informed of events occurring in your clusters, both planned and unplanned. To help you stay informed of these events, Rancher allows you to configure alerts. +Notifiers and alerts are two features that work together to inform you of events in the Rancher system. -_Alerts_ are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level. +[Notifiers]({{}}/rancher/v2.x/en/cluster-admin/tools/notifiers) are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Notifications can be sent with Slack, email, PagerDuty, WeChat, and webhooks. -Some examples of alert events are: - -- A Kubernetes [master component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) entering an unhealthy state. -- A node or [workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/) error occurring. -- A scheduled deployment taking place as planned. -- A node's hardware resources becoming overstressed. - -When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions. - -Additionally, you can set an urgency level for each alert. This urgency appears in the notification you receive, helping you to prioritize your response actions. For example, if you have an alert configured to inform you of a routine deployment, no action is required. These alerts can be assigned a low priority level. However, if a deployment fails, it can critically impact your organization, and you need to react quickly. Assign these alerts a high priority level. - -You can configure alerts at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/). +[Alerts]({{}}/rancher/v2.x/en/cluster-admin/tools/alerts) are rules that trigger those notifications. Before you can receive alerts, you must configure one or more notifier in Rancher. The scope for alerts can be set at either the cluster or project level. ## Logging -Rancher can integrate with popular external services used for event streams, telemetry, or search. Rancher can integrate with the following services: +Logging is helpful because it allows you to: -- Elasticsearch -- splunk -- kafka -- syslog -- fluentd +- Capture and analyze the state of your cluster +- Look for trends in your environment +- Save your logs to a safe location outside of your cluster +- Stay informed of events like a container crashing, a pod eviction, or a node dying +- More easily debugg and troubleshoot problems -These services collect container log events, which are saved to the `/var/log/containers` directory on each of your nodes. The service collects both standard and error events. You can then log into your services to review the events collected, leveraging each service's unique features. +Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd. -When configuring Rancher to integrate with these services, you'll have to point Rancher toward the service's endpoint and provide authentication information. Additionally, you'll have the opportunity to enter key value pairs to filter the log events collected. The service will only collect events for containers marked with your configured key value pairs. - -You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/logging/). - -## Pipelines - -Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline. - -To set up a pipeline, you'll first need to authorize Rancher using your GitHub settings. Directions are provided in the Rancher UI. After authorizing Rancher in GitHub, provide Rancher with a client ID and secret to authenticate. - -After configuring Rancher and GitHub, you can deploy containers running Jenkins to automate a pipeline execution: - -- Build your application from code to image. -- Validate your builds. -- Deploy your build images to your cluster. -- Run unit tests. -- Run regression tests. - -For more information, see [Pipelines]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/). +For details, refer to the [logging section.]({{}}/rancher/v2.x/en/cluster-admin/tools/logging) ## Monitoring _Available as of v2.2.0_ -Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is a stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster. - -In other words, Prometheus let's you view metrics from your different Rancher and Kubernetes objects. Using timestamps, you can query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported. - -You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/). +Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. For details, refer to the [monitoring section.]({{}}/rancher/v2.x/en/cluster-admin/tools/monitoring) diff --git a/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md b/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md index f8f82c6aab1..fa9c7b0bdaa 100644 --- a/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md +++ b/content/rancher/v2.x/en/project-admin/tools/alerts/_index.md @@ -3,11 +3,13 @@ title: Alerts weight: 2526 --- -To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. To help you stay informed of these events, you can configure alerts. +To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions. -Alerts are sets of rules, chosen by you, to monitor for specific events. +Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address. -Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can manage project alerts. +Before you can receive alerts, one or more [notifier]({{}}/rancher/v2.x/en/cluster-admin/tools/notifiers) must be configured at the cluster level. + +Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can manage project alerts. This section covers the following topics: @@ -18,7 +20,7 @@ This section covers the following topics: ## Alerts Scope - The scope for alerts can be set at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or project level. +The scope for alerts can be set at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or project level. At the project level, Rancher monitors specific deployments and sends alerts for: @@ -29,7 +31,7 @@ At the project level, Rancher monitors specific deployments and sends alerts for ## Default Project-level Alerts -When you enable monitoring for the project, some project-level alerts are provided. +When you enable monitoring for the project, some project-level alerts are provided. You can receive these alerts if a [notifier]({{}}/rancher/v2.x/en/cluster-admin/tools/notifiers) for them is configured at the cluster level. | Alert | Explanation | |-------|-------------| diff --git a/content/rancher/v2.x/en/project-admin/tools/logging/_index.md b/content/rancher/v2.x/en/project-admin/tools/logging/_index.md index 680f9aa2e86..5e842ce96c7 100644 --- a/content/rancher/v2.x/en/project-admin/tools/logging/_index.md +++ b/content/rancher/v2.x/en/project-admin/tools/logging/_index.md @@ -5,6 +5,8 @@ weight: 2527 Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters. +For background information about how logging integrations work, refer to the [cluster administration section.]({{}}/rancher/v2.x/en/cluster-admin/tools/logging/#how-logging-integrations-work) + Rancher supports the following services: - Elasticsearch diff --git a/content/rancher/v2.x/en/project-admin/tools/monitoring/_index.md b/content/rancher/v2.x/en/project-admin/tools/monitoring/_index.md index c82f4fcbe08..76afbdf2cb6 100644 --- a/content/rancher/v2.x/en/project-admin/tools/monitoring/_index.md +++ b/content/rancher/v2.x/en/project-admin/tools/monitoring/_index.md @@ -5,15 +5,19 @@ weight: 2528 _Available as of v2.2.4_ -Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/): +Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. ->A stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster. +> For more information about how Prometheus works, refer to the [cluster administration section.]({{}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#about-prometheus) -In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported. +This section covers the following topics: -Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can configure project level monitoring. Project members can only view monitoring metrics. +- [Monitoring scope](#monitoring-scope) +- [Permissions to configure project monitoring](#permissions-to-configure-project-monitoring) +- [Configuring project monitoring](#configuring-project-monitoring) +- [Project-level monitoring resource requirements](#project-level-monitoring-resource-requirements) +- [Project metrics](#project-metrics) -## Monitoring Scope +### Monitoring Scope Using Prometheus, you can monitor Rancher at both the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) and project level. For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server. @@ -25,7 +29,11 @@ Using Prometheus, you can monitor Rancher at both the [cluster level]({{< baseur - Project monitoring allows you to view the state of pods running in a given project. Prometheus collects metrics from the project's deployed HTTP and TCP/UDP workloads. -## Configuring Project Monitoring +### Permissions to Configure Project Monitoring + +Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can configure project level monitoring. Project members can only view monitoring metrics. + +### Configuring Project Monitoring 1. From the **Global** view, navigate to the project that you want to configure project monitoring. @@ -35,7 +43,7 @@ Using Prometheus, you can monitor Rancher at both the [cluster level]({{< baseur 1. Click **Save**. -### Project Level Monitoring Resource Requirements +### Project-Level Monitoring Resource Requirements Container| CPU - Request | Mem - Request | CPU - Limit | Mem - Limit | Configurable ---------|---------------|---------------|-------------|-------------|------------- @@ -45,14 +53,11 @@ Grafana | 100m | 100Mi | 200m | 200Mi | No **Result:** A single application,`project-monitoring`, is added as an [application]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) to the project. After the application is `active`, you can start viewing [project metrics](#project-metrics) through the [Rancher dashboard]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#rancher-dashboard) or directly from [Grafana]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#grafana). -## Project Metrics +### Project Metrics If [cluster monitoring]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) is also enabled for the project, [workload metrics]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#workload-metrics) are available for the project. You can monitor custom metrics from any [exporters](https://prometheus.io/docs/instrumenting/exporters/) as long as project monitoring is enabled. You can also expose some custom endpoints on deployments without needing to configure Prometheus for your project. -### Example - -A [Redis](https://redis.io/) application is deployed in the namespace `redis-app` in the project `Datacenter`. It is monitored via [Redis exporter](https://github.com/oliver006/redis_exporter). - -After enabling project monitoring, you can edit the application to configure the **Advanced Options -> Custom Metrics** section. Enter the `Container Port` and `Path` and select the `Protocol`. +> **Example:** +> A [Redis](https://redis.io/) application is deployed in the namespace `redis-app` in the project `Datacenter`. It is monitored via [Redis exporter](https://github.com/oliver006/redis_exporter). After enabling project monitoring, you can edit the application to configure the Advanced Options -> Custom Metrics section. Enter the `Container Port` and `Path` and select the `Protocol`. From 2eee521664b47f16edbecd6e3615ba40719a6d9e Mon Sep 17 00:00:00 2001 From: David Nuzik Date: Sun, 5 Jan 2020 13:04:36 -0700 Subject: [PATCH 77/82] Add info about helm3 and migrating from helm2 - Provides information explaining that K3s supports helm v2 and v3 as of our v1.17.0 release. - Links to official documentation which has good instructions on how to leverage helm v2 / v3 and migrate. --- content/k3s/latest/en/advanced/_index.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/content/k3s/latest/en/advanced/_index.md b/content/k3s/latest/en/advanced/_index.md index ca549701510..8151f7ce8ec 100644 --- a/content/k3s/latest/en/advanced/_index.md +++ b/content/k3s/latest/en/advanced/_index.md @@ -8,6 +8,7 @@ aliases: This section contains advanced information describing the different ways you can run and manage K3s: +- [Using Helm 3](#using-helm-3) - [Auto-deploying manifests](#auto-deploying-manifests) - [Using the Helm CRD](#using-the-helm-crd) - [Accessing the cluster from outside with kubectl](#accessing-the-cluster-from-outside-with-kubectl) @@ -18,6 +19,17 @@ 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) +# Using Helm 3 + +K3s release _v1.17.0+k3s.1_ added support for Helm 3. You can access the Helm 3 documentation [here](https://helm.sh/docs/intro/quickstart/). +Note that Helm 3 no longer requires tiller and the helm init command. Refer to the official documentation for details. + +K3s does not require any special configuration to start using Helm 3. Just be sure you have properly set your KUBECONFIG for Helm to work properly. + +### Upgrading + +If you were using Helm v2 in previous versions of K3s, you may upgrade to v1.17.0+k3s.1 or newer and Helm 2 will still function. If you wish to migrate to Helm 3, [this](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) blog post by Helm explains how to use a plugin to successfully migrate. Refer to the official Helm 3 documentation [here](https://helm.sh/docs/) for more information. K3s will handle either Helm v2 or Helm v3 as of v1.17.0+k3s.1. Just be sure you have properly set your KUBECONFIG for Helm to work properly. + # Auto-Deploying Manifests Any file found in `/var/lib/rancher/k3s/server/manifests` will automatically be deployed to From cde633d3a697bb3dabd1585e80c5647891e84eb9 Mon Sep 17 00:00:00 2001 From: OmarSastec <49637392+OmarSastec@users.noreply.github.com> Date: Mon, 6 Jan 2020 12:20:50 +0100 Subject: [PATCH 78/82] Update _index.md --- content/rancher/v2.x/en/installation/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/installation/_index.md b/content/rancher/v2.x/en/installation/_index.md index 8511d1a4716..b7524c97730 100644 --- a/content/rancher/v2.x/en/installation/_index.md +++ b/content/rancher/v2.x/en/installation/_index.md @@ -10,7 +10,7 @@ Before installing Rancher, make sure that your nodes fulfill all of the [install ### Overview of Installation Options -We recommend using [Helm,]({{}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased avaialability is achieved by running Rancher on multiple nodes. +We recommend using [Helm,]({{}}/rancher/v2.x/en/overview/architecture/concepts/#about-helm) a Kubernetes package manager, to install Rancher on a dedicated Kubernetes cluster. This is called a high-availability (HA) installation because increased availability is achieved by running Rancher on multiple nodes. For testing and demonstration purposes, Rancher can also be installed with Docker on a single node. However, there is no migration path from a single-node Docker installation to an HA installation on a Kubernetes cluster. Therefore, you may want to use an HA installation from the start. From ee4dced1a8ed9de95de58134e2a7a63b560288a3 Mon Sep 17 00:00:00 2001 From: David Nuzik Date: Mon, 6 Jan 2020 12:18:03 -0700 Subject: [PATCH 79/82] Provide KUBECONFIG examples and mention note to add helmVersion to YAML for manifests --- content/k3s/latest/en/advanced/_index.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/content/k3s/latest/en/advanced/_index.md b/content/k3s/latest/en/advanced/_index.md index 8151f7ce8ec..330bdad09d5 100644 --- a/content/k3s/latest/en/advanced/_index.md +++ b/content/k3s/latest/en/advanced/_index.md @@ -24,11 +24,24 @@ This section contains advanced information describing the different ways you can K3s release _v1.17.0+k3s.1_ added support for Helm 3. You can access the Helm 3 documentation [here](https://helm.sh/docs/intro/quickstart/). Note that Helm 3 no longer requires tiller and the helm init command. Refer to the official documentation for details. -K3s does not require any special configuration to start using Helm 3. Just be sure you have properly set your KUBECONFIG for Helm to work properly. +K3s does not require any special configuration to start using Helm 3. Just be sure you have properly set your KUBECONFIG environment variable or specify the location of the kubeconf file with the `--kubeconfig` flag for Helm to work properly. For example: + +Leverage the KUBECONFIG environment variable: + +``` +export KUBECONFIG=/etc/rancher/k3s/k3s.yaml +helm ls --all-namespaces +``` + +Or specify the location of the kubeconfig file per command: + +``` +helm --kubeconfig /etc/rancher/k3s/k3s.yaml ls --all-namespaces +``` ### Upgrading -If you were using Helm v2 in previous versions of K3s, you may upgrade to v1.17.0+k3s.1 or newer and Helm 2 will still function. If you wish to migrate to Helm 3, [this](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) blog post by Helm explains how to use a plugin to successfully migrate. Refer to the official Helm 3 documentation [here](https://helm.sh/docs/) for more information. K3s will handle either Helm v2 or Helm v3 as of v1.17.0+k3s.1. Just be sure you have properly set your KUBECONFIG for Helm to work properly. +If you were using Helm v2 in previous versions of K3s, you may upgrade to v1.17.0+k3s.1 or newer and Helm 2 will still function. If you wish to migrate to Helm 3, [this](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) blog post by Helm explains how to use a plugin to successfully migrate. Refer to the official Helm 3 documentation [here](https://helm.sh/docs/) for more information. K3s will handle either Helm v2 or Helm v3 as of v1.17.0+k3s.1. Just be sure you have properly set your kubeconfig as per the examples above in the [Using Helm 3](#using-helm-3) section. # Auto-Deploying Manifests @@ -52,6 +65,8 @@ spec: Keep in mind that `namespace` in your HelmChart resource metadata section should always be `kube-system`, because the K3s deploy controller is configured to watch this namespace for new HelmChart resources. If you want to specify the namespace for the actual Helm release, you can do that using `targetNamespace` key under the `spec` directive, as shown in the configuration example below. +> **Note:** In order for the Helm Controller to know which version of Helm to use to Auto-Deploy a helm app, please specify the `helmVersion` in the spec of your YAML file. + Also note that besides `set`, you can use `valuesContent` under the `spec` directive. And it's okay to use both of them: ```yaml From aac584b761ad0155b15d39dcfe8c1d1a5df42c1a Mon Sep 17 00:00:00 2001 From: David Nuzik Date: Mon, 6 Jan 2020 14:13:01 -0700 Subject: [PATCH 80/82] Make setting up kubeconfig its own section --- content/k3s/latest/en/advanced/_index.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/content/k3s/latest/en/advanced/_index.md b/content/k3s/latest/en/advanced/_index.md index 330bdad09d5..8b2c5f76e68 100644 --- a/content/k3s/latest/en/advanced/_index.md +++ b/content/k3s/latest/en/advanced/_index.md @@ -8,6 +8,7 @@ aliases: This section contains advanced information describing the different ways you can run and manage K3s: +- [Setting Up the kubeconfig File](#setting-up-the-kubeconfig-file) - [Using Helm 3](#using-helm-3) - [Auto-deploying manifests](#auto-deploying-manifests) - [Using the Helm CRD](#using-the-helm-crd) @@ -19,29 +20,36 @@ 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) -# Using Helm 3 +# Setting Up the kubeconfig File -K3s release _v1.17.0+k3s.1_ added support for Helm 3. You can access the Helm 3 documentation [here](https://helm.sh/docs/intro/quickstart/). -Note that Helm 3 no longer requires tiller and the helm init command. Refer to the official documentation for details. - -K3s does not require any special configuration to start using Helm 3. Just be sure you have properly set your KUBECONFIG environment variable or specify the location of the kubeconf file with the `--kubeconfig` flag for Helm to work properly. For example: +The kubeconfig file is used to configure access to the Kubernetes cluster. It is required to be set up properly in order to access the Kubernetes API such as with kubectl or for installing applications with Helm. You may set the kubeconfig by either exporting the KUBECONFIG environment variable or by specifying a flag for kubectl and helm. Refer to the examples below for details. Leverage the KUBECONFIG environment variable: ``` export KUBECONFIG=/etc/rancher/k3s/k3s.yaml +kubectl get pods --all-namespaces helm ls --all-namespaces ``` Or specify the location of the kubeconfig file per command: ``` +kubectl --kubeconfig /etc/rancher/k3s/k3s.yaml get pods --all-namespaces helm --kubeconfig /etc/rancher/k3s/k3s.yaml ls --all-namespaces ``` +# Using Helm 3 + +K3s release _v1.17.0+k3s.1_ added support for Helm 3. You can access the Helm 3 documentation [here](https://helm.sh/docs/intro/quickstart/). +Note that Helm 3 no longer requires tiller and the helm init command. Refer to the official documentation for details. + +K3s does not require any special configuration to start using Helm 3. Just be sure you have properly set up your kubeconfig as per the [Setting Up the kubeconfig File](#setting-up-the-kubeconfig-file) section above. + + ### Upgrading -If you were using Helm v2 in previous versions of K3s, you may upgrade to v1.17.0+k3s.1 or newer and Helm 2 will still function. If you wish to migrate to Helm 3, [this](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) blog post by Helm explains how to use a plugin to successfully migrate. Refer to the official Helm 3 documentation [here](https://helm.sh/docs/) for more information. K3s will handle either Helm v2 or Helm v3 as of v1.17.0+k3s.1. Just be sure you have properly set your kubeconfig as per the examples above in the [Using Helm 3](#using-helm-3) section. +If you were using Helm v2 in previous versions of K3s, you may upgrade to v1.17.0+k3s.1 or newer and Helm 2 will still function. If you wish to migrate to Helm 3, [this](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) blog post by Helm explains how to use a plugin to successfully migrate. Refer to the official Helm 3 documentation [here](https://helm.sh/docs/) for more information. K3s will handle either Helm v2 or Helm v3 as of v1.17.0+k3s.1. Just be sure you have properly set your kubeconfig as per the examples above in the [Setting Up the kubeconfig File](#setting-up-the-kubeconfig-file) section. # Auto-Deploying Manifests From af122556b8634d05f784b212fac09004b1e4d79c Mon Sep 17 00:00:00 2001 From: David-VTUK Date: Thu, 9 Jan 2020 18:14:37 +0000 Subject: [PATCH 81/82] Update _index.md Fix broken link for [architecture section] in the link "For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.]" --- .../v2.x/en/cluster-provisioning/rke-clusters/options/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md index cbe4677d4d3..5ca68abc076 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/_index.md @@ -77,7 +77,7 @@ Authorized Cluster Endpoint can be used to directly access the Kubernetes API se This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates. -For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.]({{}}/rancher/v2.x/en/overview/architecture/4-authorized-cluster-endpoint) +For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.]({{}}/rancher/v2.x/en/overview/architecture/#4-authorized-cluster-endpoint) We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/#architecture-for-an-authorized-cluster-endpoint) From 3f4a5d536b0470dbdfd0671dac8f4df684b993c6 Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Tue, 24 Dec 2019 14:42:20 -0700 Subject: [PATCH 82/82] Change title for section on cleaning nodes --- .../v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md index 41f61a37aa1..410a774314c 100644 --- a/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/_index.md @@ -6,9 +6,12 @@ aliases: - /rancher/v2.x/en/faq/cleaning-cluster-nodes/ - /rancher/v2.x/en/admin-settings/removing-rancher/user-cluster-nodes/ --- + +This section describes how to disconnect a node from a Rancher-launched Kubernetes cluster and remove all of the Kubernetes components from the node. This process allows you to use the node for other purposes. + When you use Rancher to [launch nodes for a cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#cluster-creation-in-rancher), resources (containers/virtual network interfaces) and configuration items (certificates/configuration files) are created. -When removing nodes from your Rancher launched Kubernetes cluster (provided that they are in `Active` state), those resources automatically cleaned, and the only action needed is to restart the node. When a node has become unreachable and the automatic cleanup process cannot be used, we describe the steps that need to be executed before the node can be added to a cluster again. +When removing nodes from your Rancher launched Kubernetes cluster (provided that they are in `Active` state), those resources are automatically cleaned, and the only action needed is to restart the node. When a node has become unreachable and the automatic cleanup process cannot be used, we describe the steps that need to be executed before the node can be added to a cluster again. ## What Gets Removed?