`. If all goes well, you will automatically login to the recovery console.
+
+### How to recover
+
+We need to mount the root disk in the recovery console and delete some data:
+
+```
+$ mkdir /mnt/root-disk
+$ mount /dev/sda1 /mnt/root-disk
+
+# delete data previously generated using dd
+$ ls -ahl /mnt/root-disk/opt
+-rw-r--r-- 1 root root 1.3G Jul 19 07:32 2GB.img
+$ rm -f /mnt/root-disk/opt/2GB.img
+```
+
+After rebooting, you can enter the OS normally.
+
diff --git a/content/os/v1.x/en/about/security/_index.md b/content/os/v1.x/en/about/security/_index.md
index 1311d84a9ec..96b8c79470d 100644
--- a/content/os/v1.x/en/about/security/_index.md
+++ b/content/os/v1.x/en/about/security/_index.md
@@ -11,7 +11,7 @@ weight: 303
Reporting process
-Please submit possible security issues by emailing security@rancher.com
+Please submit possible security issues by emailing security@rancher.com
|
Announcments
@@ -28,6 +28,8 @@ weight: 303
| [CVE-2017-7184](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7184) | Allows local users to obtain root privileges or cause a denial of service (heap-based out-of-bounds access) by leveraging the CAP_NET_ADMIN capability. | 3 April 2017 | [RancherOS v0.9.2-rc1](https://github.com/rancher/os/releases/tag/v0.9.2-rc1) using Linux 4.9.20 |
| [CVE-2017-1000364](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000364) | Linux Kernel is prone to a local memory-corruption vulnerability. Attackers may be able to exploit this issue to execute arbitrary code with elevated privileges | 19 June 2017 | [RancherOS v1.0.3](https://github.com/rancher/os/releases/tag/v1.0.3) |
| [CVE-2017-1000366](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000366) | glibc contains a vulnerability that allows manipulation of the heap/stack. Attackers may be able to exploit this issue to execute arbitrary code with elevated privileges | 19 June 2017 | [RancherOS v1.0.3](https://github.com/rancher/os/releases/tag/v1.0.3) |
-| [CVE-2017-1000405](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000405) | The Linux Kernel versions 2.6.38 through 4.14 have a problematic use of pmd_mkdirty() in the touch_pmd() function inside the THP implementation. touch_pmd() can be reached by get_user_pages(). In such case, the pmd will become dirty. | 10 Dec 2017 | [RancherOS v1.1.1](https://github.com/rancher/os/releases/tag/v1.1.1) |
-| [CVE-2017-5754](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754) | Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache. | 5 Jan 2018 | [RancherOS v1.1.3](https://github.com/rancher/os/releases/tag/v1.1.3) using Linux v4.9.75|
-| [CVE-2017-5715](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715) | Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis | 6 Feb 2018 | [RancherOS v1.1.4](https://github.com/rancher/os/releases/tag/v1.1.4) using Linux v4.9.78 with the Retpoline support |
+| [CVE-2017-1000405](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000405) | The Linux Kernel versions 2.6.38 through 4.14 have a problematic use of pmd_mkdirty() in the touch_pmd() function inside the THP implementation. touch_pmd() can be reached by get_user_pages(). In such case, the pmd will become dirty. | 10 Dec 2017 | [RancherOS v1.1.1](https://github.com/rancher/os/releases/tag/v1.1.1) |
+| [CVE-2017-5754](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754) | Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache. | 5 Jan 2018 | [RancherOS v1.1.3](https://github.com/rancher/os/releases/tag/v1.1.3) using Linux v4.9.75 |
+| [CVE-2017-5715](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715) | Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis | 6 Feb 2018 | [RancherOS v1.1.4](https://github.com/rancher/os/releases/tag/v1.1.4) using Linux v4.9.78 with the Retpoline support |
+| [CVE-2017-5753](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753) | Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. | 31 May 2018 | [RancherOS v1.4.0](https://github.com/rancher/os/releases/tag/v1.4.0) using Linux v4.14.32 |
+| [CVE-2018-8897](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8897) | A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. | 31 May 2018 | [RancherOS v1.4.0](https://github.com/rancher/os/releases/tag/v1.4.0) using Linux v4.14.32 |
diff --git a/content/os/v1.x/en/installation/custom-builds/custom-kernels/_index.md b/content/os/v1.x/en/installation/custom-builds/custom-kernels/_index.md
index cf6a71c13fd..8a7ff668a11 100644
--- a/content/os/v1.x/en/installation/custom-builds/custom-kernels/_index.md
+++ b/content/os/v1.x/en/installation/custom-builds/custom-kernels/_index.md
@@ -3,86 +3,78 @@ title: Custom Kernels
weight: 181
---
+### Kernel version in RancherOS
+
+RancherOS basically uses the standard Linux kernel, but we maintain a kernel config ourselves. Due to various feature support and security fixes, we are constantly updating the kernel version.
+
+RancherOS | Kernel
+--------- | ------
+<=v0.7.1 | 4.4.x
+<=v1.3.0 | 4.9.x
+>=v1.4.0 | 4.14.x
+
### Building and Packaging a Kernel to be used in RancherOS
We build the kernel for RancherOS at the [os-kernel repository](https://github.com/rancher/os-kernel). You can use this repository to help package your own custom kernel to be used in RancherOS.
+Create a clone of the [os-kernel](https://github.com/rancher/os-kernel) repository to your local machine using `git clone`.
-1. Create a clone of the [os-kernel](https://github.com/rancher/os-kernel) repository to your local machine using `git clone`.
- ```
- $ git clone https://github.com/rancher/os-kernel.git
- ```
-2. In the `./Dockerfile.dapper` file, update the `KERNEL_TAG`, `KERNEL_VERSION`, `KERNEL_URL` and `KERNEL_SHA1`. `KERNEL_URL` points to Linux kernel sources archive, packaged as `.tar.gz` or `.tar.xz`. `KERNEL_SHA1` is the `SHA1` sum of the kernel sources archive.
- `./Dockerfile.dapper` file
+```
+$ git clone https://github.com/rancher/os-kernel.git
+```
- ```bash
- ########## Kernel version Configuration #############################
- ENV KERNEL_TAG=v4.8.7
- ENV KERNEL_VERSION=4.8.7-rancher
- ENV KERNEL_SHA1=5c10724a0e7e97b72046be841df0c69c6e2a03c2
- ENV KERNEL_URL=https://github.com/rancher/linux/archive/${KERNEL_TAG}.tar.gz
- ```
-3. After you've replaced the `KERNEL_*` values, run `make` in the root `os-kernel` directory. After the build is completed, a `./dist/kernel` directory will be created with the freshly built kernel tarball and headers.
- ```
- $ make
- ...snip...
- --- 4.8.7-rancher Kernel prepared for RancherOS
- ./dist/kernel/extra-linux-4.8.7-rancher-x86.tar.gz
- ./dist/kernel/build-linux-4.8.7-rancher-x86.tar.gz
- ./dist/kernel/linux-4.8.7-rancher-x86.tar.gz
- ./dist/kernel/config
+If you want to build kernel v4.14.53, you can refer to the following command. After the build is completed, a `./dist/kernel` directory will be created with the freshly built kernel tarball and headers.
- Images ready to push:
- rancher/os-extras:4.8.7-rancher
- rancher/os-headers:4.8.7-rancher
- ```
+```
+$ git tag v4.14.53-rancher
+$ KERNEL_TAG=4.14.53 make release
+...snip...
+./dist/kernel/extra-linux-4.14.53-rancher-x86.tar.gz
+./dist/kernel/build-linux-4.14.53-rancher-x86.tar.gz
+./dist/kernel/linux-4.14.53-rancher-x86.tar.gz
+./dist/kernel/config
+...snip...
+Images ready to push:
+rancher/os-extras:4.14.53-rancher
+rancher/os-headers:4.14.53-rancher
+ ```
+For some users who need a custom kernel, the following information is very useful to you:
-Now you need to either upload the `./dist/kernel/linux-4.8.7-rancher-x86.tar.gz` file to somewhere, or copy that file into your clone of the `rancher/os` repo, as `assets/kernel.tar.gz`.
+1. The modules defined in `modules.list` will be packaged into the built-in modules.
+2. The modules defined in `modules-extra.list` will be packaged into the extra modules.
+3. You can modify `config/kernel-config` to build the kernel modules you need.
+4. You can add your patches in the `patches` directory, and `os-kernel` will update these patches after downloading the kernel source.
+
+Now you need to either upload the `./dist/kernel/linux-4.14.53-rancher-x86.tar.gz` file to somewhere, or copy that file into your clone of the `rancher/os` repo, as `assets/kernel.tar.gz`.
The `build-.tar.gz` and `extra-.tar.gz` files are used to build the `rancher/os-extras` and `rancher/os-headers` images for your RancherOS release - which you will need to tag them with a different organisation name, push them to a registry, and create custom service.yml files.
+Your kernel should be packaged and published as a set of files of the following format:
+
+1. `.tar.gz` is the one KERNEL_URL in `rancher/os` should point to. It contains the kernel binary, core modules and firmware.
+
+2. `build-.tar.gz` contains build headers to build additional modules: it is a subset of the kernel sources tarball. These files will be installed into `/usr/src/` using the `kernel-headers-system-docker` and `kernel-headers` services.
+
+3. `extra-.tar.gz` contains extra modules and firmware for your kernel and should be built into a `kernel-extras` service.
+
### Building a RancherOS release using the Packaged kernel files.
By default, RancherOS ships with the kernel provided by the [os-kernel repository](https://github.com/rancher/os-kernel). Swapping out the default kernel can by done by [building your own custom RancherOS ISO]({{< baseurl >}}/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/).
- 1. Create a clone of the main [RancherOS repository](https://github.com/rancher/os) to your local machine with a `git clone`.
- ```
- $ git clone https://github.com/rancher/os.git
- ```
- 2. In the root of the repository, the "General Configuration" section of `Dockerfile.dapper` will need to be updated. Using your favorite editor, replace the appropriate `KERNEL_URL` value with a URL of your compiled custom kernel tarball. Ideally, the URL will use `HTTPS`.
- `Dockerfile.dapper` file
- ```
- # Update the URL to your own custom kernel tarball
- ARG KERNEL_URL_amd64=https://github.com/rancher/os-kernel/releases/download/Ubuntu-4.4.0-23.41-rancher/linux-4.4.10-rancher-x86.tar.gz
- ARG KERNEL_URL_arm64=https://github.com/imikushin/os-kernel/releases/download/Estuary-4.1.18-arm64-3/linux-4.1.18-arm64.tar.gz
- ```
+
+Create a clone of the main [RancherOS repository](https://github.com/rancher/os) to your local machine with a `git clone`.
+
+```
+$ git clone https://github.com/rancher/os.git
+```
+
+In the root of the repository, the "General Configuration" section of `Dockerfile.dapper` will need to be updated. Using your favorite editor, replace the appropriate `KERNEL_URL` value with a URL of your compiled custom kernel tarball. Ideally, the URL will use `HTTPS`.
+
+```
+# Update the URL to your own custom kernel tarball
+ARG KERNEL_VERSION_amd64=4.14.63-rancher
+ARG KERNEL_URL_amd64=https://link/xxxx
+```
+
+After you've replaced the URL with your custom kernel, you can follow the steps in [building your own custom RancherOS ISO]({{< baseurl >}}/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/).
> **Note:** `KERNEL_URL` settings should point to a Linux kernel, compiled and packaged in a specific way. You can fork [os-kernel repository](https://github.com/rancher/os-kernel) to package your own kernel.
-
- Your kernel should be packaged and published as a set of files of the following format:
-
- `.tar.gz` is the one KERNEL_URL should point to. It contains the kernel binary, core modules and firmware:
-
- ```
- boot/
- vmlinuz-
- lib/
- modules/
- /
- ...
- firmware/
- ...
- ```
-
- `build.tar.gz` contains build headers to build additional modules: it is a subset of the kernel sources tarball. These files will be installed into `/usr/src/` using the `kernel-headers-system-docker` and `kernel-headers` services.
-
- `extra.tar.gz` contains extra modules and firmware for your kernel and should be built into a `kernel-extras` service:
-
- ```
- lib/
- modules/
- /
- ...
- firmware/
- ...
- ```
- 3. After you've replaced the URL with your custom kernel, you can follow the steps in [building your own custom RancherOS ISO]({{< baseurl >}}/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/).
diff --git a/content/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/_index.md b/content/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/_index.md
index f5fb5c07359..430631a20df 100644
--- a/content/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/_index.md
+++ b/content/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/_index.md
@@ -5,79 +5,70 @@ weight: 182
It's easy to build your own RancherOS ISO.
-1. Create a clone of the main [RancherOS repository](https://github.com/rancher/os) to your local machine with a `git clone`.
- ```
- $ git clone https://github.com/rancher/os.git
- ```
-2. In the root of the repository, the "General Configuration" section of `Dockerfile.dapper` can be updated to use [custom kernels]({{< baseurl >}}/os/v1.x/en/installation/custom-builds/custom-kernels).
-3. After you've saved your edits, run `make` in the root directory. After the build has completed, a `./dist/artifacts` directory will be created with the custom built RancherOS release files.
- Build Requirements: `bash`, `make`, `docker` (Docker version >= 1.10.3)
- ```
- $ make
- $ cd dist/artifacts
- $ ls
- initrd rancheros.iso
- iso-checksums.txt vmlinuz
- ```
+Create a clone of the main [RancherOS repository](https://github.com/rancher/os) to your local machine with a `git clone`.
+
+```
+$ git clone https://github.com/rancher/os.git
+```
+
+In the root of the repository, the "General Configuration" section of `Dockerfile.dapper` can be updated to use [custom kernels]({{< baseurl >}}/os/v1.x/en/installation/custom-builds/custom-kernels).
+After you've saved your edits, run `make` in the root directory. After the build has completed, a `./dist/artifacts` directory will be created with the custom built RancherOS release files.
+Build Requirements: `bash`, `make`, `docker` (Docker version >= 1.10.3)
+
+```
+$ make
+$ cd dist/artifacts
+$ ls
+initrd rancheros.iso
+iso-checksums.txt vmlinuz
+```
+
+If you need a compressed ISO, you can run this command:
+
+```
+$ INTEGRATION_TESTS=0 make release
+```
The `rancheros.iso` is ready to be used to [boot RancherOS from ISO]({{< baseurl >}}/os/v1.x/en/installation/running-rancheros/workstation/boot-from-iso/) or [launch RancherOS using Docker Machine]({{< baseurl >}}/os/v1.x/en/installation/running-rancheros/workstation/docker-machine).
-
### Creating a GCE Image Archive
-You can build the [GCE image archive](https://cloud.google.com/compute/docs/tutorials/building-images) using [Packer](https://www.packer.io/). You will need Packer, QEMU and GNU tar installed.
-
-First, create `gce-qemu.json`:
-
-```json
-{
- "builders":
- [
- {
- "type": "qemu",
- "name": "qemu-googlecompute",
- "iso_url": "https://github.com/rancherio/os/releases/download//rancheros.iso",
- "iso_checksum": "",
- "iso_checksum_type": "md5",
- "ssh_wait_timeout": "360s",
- "disk_size": 10000,
- "format": "raw",
- "headless": true,
- "accelerator": "none",
- "ssh_host_port_min": 2225,
- "ssh_host_port_max": 2229,
- "ssh_username": "rancher",
- "ssh_password": "rancher",
- "ssh_port": 22,
- "net_device": "virtio-net",
- "disk_interface": "scsi",
- "qemuargs": [
- ["-m", "1024M"], ["-nographic"], ["-display", "none"]
- ]
- }
- ],
- "provisioners": [
- {
- "type":"shell",
- "script": "../scripts/install2disk"
- }
- ]
-}
-```
-
-NOTE: For faster builds You can use `"kvm"` as the `accelerator` field value if you have KVM, but that's optional.
-
-Run:
+Create a clone of the main [RancherOS repository](https://github.com/rancher/os) to your local machine with a `git clone`.
```
-$ packer build gce-qemu.json
+$ git clone https://github.com/rancher/os-packer.git
```
-Packer places its output into `output-qemu-googlecompute/packer-qemu-googlecompute` - it's a raw VM disk image. Now you just need to name it `disk.raw` and package it as sparse .tar.gz:
+GCE supports KVM virtualization, and we use `packer` to build KVM images. Before building, you need to verify that the host can support KVM.
+If you want to build GCE image based on RancherOS v1.4.0, you can run this command:
```
-$ mv output-qemu-googlecompute/packer-qemu-googlecompute disk.raw
-$ tar -czSf rancheros-.tar.gz disk.raw
+RANCHEROS_VERSION=v1.4.0 make build-gce
```
-NOTE: the last command should be using GNU tar. It might be named `gtar` on your system.
+### Custom build cases
+
+#### Reduce memory requirements
+
+With the changes of the kernel and built docker, RancherOS booting requires more memory, please refer to [Memory Requirements]({{< baseurl >}}/os/v1.x/en/#hardware-requirements).
+
+By customizing the ISO, you can reduce the memory usage on boot. The easiest way is to downgrade the built-in docker version, because docker takes up a lot of space.
+This can effectively reduce the memory required to decompress the initrd on boot, using docker 17.03 is a good choice:
+
+```
+# update os-config.tpl.yml in rancher/os
+ hostname: {{.HOSTNAME_DEFAULT}}
+ {{if eq "amd64" .ARCH -}}
+ docker:
+- engine: docker-18.03.1-ce
++ engine: docker-17.03.2-ce
+ {{else -}}
+ docker:
+- engine: docker-18.03.1-ce
++ engine: docker-17.03.2-ce
+ {{end -}}
+...
+
+# run make
+$ INTEGRATION_TESTS=0 make release
+```
diff --git a/content/os/v1.x/en/installation/running-rancheros/workstation/docker-machine/_index.md b/content/os/v1.x/en/installation/running-rancheros/workstation/docker-machine/_index.md
index ffc765578d9..25dbad82d17 100644
--- a/content/os/v1.x/en/installation/running-rancheros/workstation/docker-machine/_index.md
+++ b/content/os/v1.x/en/installation/running-rancheros/workstation/docker-machine/_index.md
@@ -3,13 +3,20 @@ title: Using Docker Machine
weight: 101
---
-Before we get started, you'll need to make sure that you have docker machine installed. Download it directly from the docker machine [releases](https://github.com/docker/machine/releases).
+Before we get started, you'll need to make sure that you have docker machine installed. Download it directly from the docker machine [releases](https://github.com/docker/machine/releases).
+You also need to know the [memory requirements]({{< baseurl >}}/os/v1.x/en/#hardware-requirements).
> **Note:** If you create a RancherOS instance using Docker Machine, you will not be able to upgrade your version of RancherOS.
### Downloading RancherOS
-Get the latest `rancheros.iso` artifact from the RancherOS [releases](https://github.com/rancher/os/releases).
+Get the latest ISO artifact from the RancherOS [releases](https://github.com/rancher/os/releases).
+
+Machine Driver | ISO Name
+-------------- | --------------------
+VirtualBox | rancheros.iso
+VMWare VSphere | rancheros-vmware.iso
+VMWare Fusion | rancheros-vmware.iso
### Using Docker Machine
@@ -19,20 +26,17 @@ You can use Docker Machine to launch VMs for various providers. Currently Virtua
Before moving forward, you'll need to have VirtualBox installed. Download it directly from [VirtualBox](https://www.virtualbox.org/wiki/Downloads). Once you have VirtualBox and Docker Machine installed, it's just one command to get RancherOS running.
-```
-$ docker-machine create -d virtualbox --virtualbox-boot2docker-url
-```
+Here is an example about using the RancherOS latest link:
-
+```
+$ docker-machine create -d virtualbox \
+ --virtualbox-boot2docker-url https://releases.rancher.com/os/latest/rancheros.iso \
+ --virtualbox-memory \
+
+```
> **Note:** Instead of downloading the ISO, you can directly use the URL for the `rancheros.iso`.
-Example using the RancherOS latest link:
-
-```
-$ docker-machine create -d virtualbox --virtualbox-boot2docker-url https://releases.rancher.com/os/latest/rancheros.iso
-```
-
That's it! You should now have a RancherOS host running on VirtualBox. You can verify that you have a VirtualBox VM running on your host.
> **Note:** After the machine is created, Docker Machine may display some errors regarding creation, but if the VirtualBox VM is running, you should be able to [log in](#logging-into-rancheros).
@@ -49,16 +53,18 @@ _Available as of v1.4_
Before moving forward, you’ll need to have VMWare VSphere installed. Once you have VMWare VSphere and Docker Machine installed, it’s just one command to get RancherOS running.
-```
-$ docker-machine create --driver vmwarevsphere --vmwarevsphere-username= --vmwarevsphere-password= --vmwarevsphere-memory-size= --vmwarevsphere-boot2docker-url= --vmwarevsphere-vcenter= --vmwarevsphere-vcenter-port= --vmwarevsphere-disk-size=
-```
-
-> **Note:** Instead of downloading the RancherOS VMWare ISO, you can directly use the URL for the rancheros-vmware.iso.
-
-Example using the RancherOS VMWare latest link:
+Here is an example about using the RancherOS latest link:
```
-$ docker-machine create --driver vmwarevsphere --vmwarevsphere-username --vmwarevsphere-password --vmwarevsphere-memory-size --vmwarevsphere-boot2docker-url https://releases.rancher.com/os/latest/rancheros-vmware.iso --vmwarevsphere-vcenter --vmwarevsphere-vcenter-port --vmwarevsphere-disk-size
+$ docker-machine create -d vmwarevsphere \
+ --vmwarevsphere-username \
+ --vmwarevsphere-password \
+ --vmwarevsphere-memory-size \
+ --vmwarevsphere-boot2docker-url https://releases.rancher.com/os/latest/rancheros-vmware.iso \
+ --vmwarevsphere-vcenter \
+ --vmwarevsphere-vcenter-port \
+ --vmwarevsphere-disk-size \
+
```
That’s it! You should now have a RancherOS host running on VMWare VSphere. You can verify that you have a VMWare(ESXi) VM running on your host.
@@ -69,21 +75,18 @@ _Available as of v1.4_
Before moving forward, you’ll need to have VMWare Fusion installed. Once you have VMWare Fusion and Docker Machine installed, it’s just one command to get RancherOS running.
-```
-$ docker-machine create --driver vmwarefusion --vmwarefusion-no-share --vmwarefusion-memory-size --vmwarefusion-boot2docker-url
-```
-
-> **Note:** Instead of downloading the RancherOS VMWare ISO, you can directly use the URL for the rancheros-vmware.iso.
-
-Example using the RancherOS VMWare latest link:
+Here is an example about using the RancherOS latest link:
```
-$ docker-machine create --driver vmwarefusion --vmwarefusion-no-share --vmwarefusion-memory-size --vmwarefusion-boot2docker-url https://releases.rancher.com/os/latest/rancheros-vmware.iso
+$ docker-machine create -d vmwarefusion \
+ --vmwarefusion-no-share \
+ --vmwarefusion-memory-size \
+ --vmwarefusion-boot2docker-url https://releases.rancher.com/os/latest/rancheros-vmware.iso \
+
```
That’s it! You should now have a RancherOS host running on VMWare Fusion. You can verify that you have a VMWare Fusion VM running on your host.
-
### Logging into RancherOS
Logging into RancherOS follows the standard Docker Machine commands. To login into your newly provisioned RancherOS VM.
diff --git a/content/os/v1.x/en/overview/_index.md b/content/os/v1.x/en/overview/_index.md
index 6992b13feb0..dfd1b8b3a76 100644
--- a/content/os/v1.x/en/overview/_index.md
+++ b/content/os/v1.x/en/overview/_index.md
@@ -25,6 +25,8 @@ VMWare | 1280MB (rancheros.iso)
2048MB (rancheros-vmware.iso)
GCE | 1280MB
AWS | 1.7GB
+You can adjust memory requirements by custom building RancherOS, please refer to [reduce-memory-requirements]({{< baseurl >}}/os/v1.x/en/installation/custom-builds/custom-rancheros-iso/#reduce-memory-requirements)
+
### How this works
Everything in RancherOS is a Docker container. We accomplish this by launching two instances of Docker. One is what we call **System Docker**, the first process on the system. All other system services, like `ntpd`, `syslog`, and `console`, are running in Docker containers. System Docker replaces traditional init systems like `systemd`, and can be used to launch [additional system services]({{< baseurl >}}/os/v1.x/en/installation/system-services/adding-system-services/).
diff --git a/content/os/v1.x/en/quick-start-guide/_index.md b/content/os/v1.x/en/quick-start-guide/_index.md
index f9d8e7322e3..945ef763043 100644
--- a/content/os/v1.x/en/quick-start-guide/_index.md
+++ b/content/os/v1.x/en/quick-start-guide/_index.md
@@ -10,7 +10,10 @@ If you have a specific RanchersOS machine requirements, please check out our [gu
Before moving forward, you'll need to have [Docker Machine](https://docs.docker.com/machine/) and [VirtualBox](https://www.virtualbox.org/wiki/Downloads) installed. Once you have VirtualBox and Docker Machine installed, it's just one command to get RancherOS running.
```
-$ docker-machine create -d virtualbox --virtualbox-boot2docker-url https://releases.rancher.com/os/latest/rancheros.iso
+$ docker-machine create -d virtualbox \
+ --virtualbox-boot2docker-url https://releases.rancher.com/os/latest/rancheros.iso \
+ --virtualbox-memory 2048 \
+
```
That's it! You're up and running a RancherOS instance.
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md
index 3329ee951a5..be1486ea00a 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/azure-ad/_index.md
@@ -21,25 +21,16 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco
>**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later.
-1. [Register Rancher with Azure](#1-register-rancher-with-azure)
+
- Before enabling Azure AD within Rancher, you must register Rancher with Azure.
+- [1. Register Rancher with Azure](#1-register-rancher-with-azure)
+- [2. Create an Azure API Key](#2-create-an-azure-api-key)
+- [3. Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher)
+- [4. Add a Reply URL](#4-add-a-reply-url)
+- [5. Copy Azure Application Data](#5-copy-azure-application-data)
+- [6. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher)
-1. [Create an Azure API Key](#2-create-an-azure-api-key)
-
- From the Azure portal, create an API key. Rancher will use this key to authenticate with AD.
-
-1. [Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher)
-
- Next, set API permissions for Rancher within Azure.
-
-1. [Copy Azure Application Data](#4-copy-azure-application-data)
-
- As your final step in Azure, copy the data that you'll use to configure Rancher for Azure AD authentication.
-
-1. [Configure Azure AD in Rancher](#5-configure-azure-ad-in-rancher)
-
- From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration.
+
### 1. Register Rancher with Azure
@@ -119,7 +110,28 @@ Next, set API permissions for Rancher within Azure.
>**Note:** You must be signed in as an Azure administrator to successfully save your permission settings.
-### 4. Copy Azure Application Data
+### 4. Add a Reply URL
+
+To use Azure AD with Rancher you must whitelist Rancher with Azure. You can complete this whitelisting by providing Azure with a reply URL for Rancher, which is your Rancher Server URL followed with a verification path.
+
+
+1. From the **Setting** blade, select **Reply URLs**.
+
+ 
+
+1. From the **Reply URLs** blade, enter the URL of your Rancher Server, appended with the verification path: `/verify-auth-azure`.
+
+ >**Tip:** You can find your personalized Azure reply URL in Rancher on the Azure AD Authentication page (Global View > Security Authentication > Azure AD).
+ >
+ > 
+
+1. Click **Save**.
+
+**Result:** Your reply URL is saved.
+
+>**Note:** It can take up to five minutes for this change to take affect, so don't be alarmed if you can't authenticate immediately after Azure AD configuration.
+
+### 5. Copy Azure Application Data
As your final step in Azure, copy the data that you'll use to configure Rancher for Azure AD authentication and paste it into an empty text file.
@@ -157,7 +169,7 @@ As your final step in Azure, copy the data that you'll use to configure Rancher
- **OAuth 2.0 Token Endpoint** (Token Endpoint)
- **OAuth 2.0 Authorization Endpoint** (Auth Endpoint)
-### 5. Configure Azure AD in Rancher
+### 6. Configure Azure AD in Rancher
From the Rancher UI, enter information about your AD instance hosted in Azure to complete configuration.
@@ -175,15 +187,15 @@ Enter the values that you copied to your [text file](#tip).
The following table maps the values you copied in the Azure portal to the fields in Rancher.
- Rancher Field | Azure Value
- ---------|----------
- Tenant ID | Directory ID
- Application ID | Application ID
- Application Secret | Key Value
- Endpoint | https://login.microsoftonline.com/
- Graph Endpoint | Microsoft Azure AD Graph API Endpoint
- Token Endpoint | OAuth 2.0 Token Endpoint
- Auth Endpoint | OAuth 2.0 Authorization Endpoint
+ | Rancher Field | Azure Value |
+ | ------------------ | ------------------------------------- |
+ | Tenant ID | Directory ID |
+ | Application ID | Application ID |
+ | Application Secret | Key Value |
+ | Endpoint | https://login.microsoftonline.com/ |
+ | Graph Endpoint | Microsoft Azure AD Graph API Endpoint |
+ | Token Endpoint | OAuth 2.0 Token Endpoint |
+ | Auth Endpoint | OAuth 2.0 Authorization Endpoint |
1. Click **Authenticate with Azure**.
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md
index 700ec9fda08..ecf66b793bc 100644
--- a/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/_index.md
@@ -6,47 +6,34 @@ _Available as of v2.0.7_
If your organization uses Microsoft Active Directory Federation Services (AD FS) for user authentication, you can configure Rancher to allow your users to log in using their AD FS credentials.
->**Prerequisites:**
->
->- You must have a [Microsoft AD FS Server](https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services) configured.
->- Export a `federationmetadata.xml` file from your AD FS Server. For more information, see the [PingIdentity video](https://docs.pingidentity.com/bundle/ping_sm_videoLibrary/page/p1_IdentityBridgeADFS.html).
+## Prerequisites
-1. From the **Global** view, select **Security > Authentication** from the main menu.
-1. Select **Microsoft Active Directory Federation Services**.
+- You must have Rancher installed.
-1. Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The examples below describe how you can map AD attributes to fields within Rancher.
-
- 1. **Display Name Field**: Enter the AD attribute that contains the display name of users (example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`).
+ - Obtain your Rancher Server URL. During AD FS configuration, substitute this URL for the `` placeholder.
- 1. **User Name Field**: Enter the AD attribute that contains the user name/given name (example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`).
-
- 1. **UID Field**: Enter an AD attribute that is unique to every user (example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn`).
-
- 1. **Groups Field**: Make entries for managing group memberships (example: `http://schemas.xmlsoap.org/claims/Group`).
-
- 1. **Rancher API Host**: Enter the URL for your Rancher Server.
+ - You must have a global administrator account on your Rancher installation.
- 1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your AD FS.
-
- You can generate one using an openssl command. For example:
-
- ```
- openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
- ```
- 1. **Metadata XML**: The `federationmetadata.xml` file exported from your AD FS server. You can find this file at `https://your-AD-Server/federationmetadata/2007-06/federationmetadata.xml`.
+- You must have a [Microsoft AD FS Server](https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services) configured.
-
-1. After you complete the **Configure AD FS Account** form, click **Authenticate with AD FS**, which is at the bottom of the page.
+ - Obtain your AD FS Server IP/DNS name. During AD FS configuration, substitute this IP/DNS name for the `` placeholder.
- Rancher redirects you to the AD FS login page. Enter credentials that authenticate with Microsoft AD FS to validate your Rancher AD FS configuration.
+ - You must have access to add [Relying Party Trusts](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) on your AD FS Server.
- >**Note:** You may have to disable your popup blocker to see the AD FS login page.
-**Result:** Rancher is configured to work with MS FS. Your users can now sign into Rancher using their MS FS logins.
+
+## Setup Outline
+
+Setting up Microsoft AD FS with Rancher Server requires configuring AD FS on your Active Directory server, and configuring Rancher to utilize your AD FS server. The following pages serve as guides for setting up Microsoft AD FS authentication on your Rancher installation.
+
+- [1 — Configuring Microsoft AD FS for Rancher]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup)
+- [2 — Configuring Rancher for Microsoft AD FS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/rancher-adfs-setup)
>**Active Directory Federation Service Caveats:**
>
>- AD FS does not support search or lookup. When adding users to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), the exact IDs must be entered correctly.
>- When adding users to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), group IDs are not supported unless the admin who turned on access control is a member of the group.
->- When adding a group that includes an admin to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), add it from the drop-down rather than the search bar. If you add the group using the search bar, the group will not get added.
\ No newline at end of file
+>- When adding a group that includes an admin to [clusters]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/) or [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/), add it from the drop-down rather than the search bar. If you add the group using the search bar, the group will not get added.
+
+### [Next: Configuring Microsoft AD FS for Rancher]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup)
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup/_index.md
new file mode 100644
index 00000000000..a05c9709e29
--- /dev/null
+++ b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup/_index.md
@@ -0,0 +1,82 @@
+---
+title: 1 — Configuring Microsoft AD FS for Rancher
+weight: 1205
+---
+
+Before configuring Rancher to support AD FS users, you must add Rancher as a [relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts) in AD FS.
+
+1. Log into your AD server as an administrative user.
+
+1. Open the **AD FS Management** console. Select **Add Relying Party Trust...** from the **Actions** menu and click **Start**.
+
+ 
+
+1. Select **Enter data about the relying party manually** as the option for obtaining data about the relying party.
+
+ 
+
+1. Enter your desired **Display name** for your Relying Party Trust. For example, `Rancher`.
+
+ 
+
+1. Select **AD FS profile** as the configuration profile for your relying party trust.
+
+ 
+
+1. Leave the **optional token encryption certificate** empty, as Rancher AD FS will not be using one.
+
+ 
+
+1. Select **Enable support for the SAML 2.0 WebSSO protocol**
+ and enter `https:///v1-saml/adfs/saml/acs` for the service URL.
+
+ 
+
+1. Add `https:///v1-saml/adfs/saml/metadata` as the **Relying party trust identifier**.
+
+ 
+
+1. This tutorial will not cover multi-factor authentication; please refer to the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs) if you would like to configure multi-factor authentication.
+
+ 
+
+1. From **Choose Issuance Authorization RUles**, you may select either of the options available according to use case. However, for the purposes of this guide, select **Permit all users to access this relying party**.
+
+ 
+
+1. After reviewing your settings, select **Next** to add the relying party trust.
+
+ 
+
+
+1. Select **Open the Edit Claim Rules...** and click **Close**.
+
+ 
+
+1. On the **Issuance Transform Rules** tab, click **Add Rule...**.
+
+ 
+
+1. Select **Send LDAP Attributes as Claims** as the **Claim rule template**.
+
+ 
+
+1. Set the **Claim rule name** to your desired name (for example, `Rancher Attributes`) and select **Active Directory** as the **Attribute store**. Create the following mapping to reflect the table below:
+
+ | LDAP Attribute | Outgoing Claim Type |
+ | -------------------------------------------- | ------------------- |
+ | Given-Name | Given Name |
+ | User-Principal-Name | UPN |
+ | Token-Groups - Qualified by Long Domain Name | Group |
+ | SAM-Account-Name | Name |
+
+ 
+
+1. Download the `federationmetadata.xml` from your AD server at:
+```
+https:///federationmetadata/2007-06/federationmetadata.xml
+```
+
+**Result:** You've added Rancher as a relying trust party. Now you can configure Rancher to leverage AD.
+
+### [Next: Configuring Rancher for Microsoft AD FS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/rancher-adfs-setup/)
diff --git a/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/rancher-adfs-setup/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/rancher-adfs-setup/_index.md
new file mode 100644
index 00000000000..f5ba2a38b0e
--- /dev/null
+++ b/content/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/rancher-adfs-setup/_index.md
@@ -0,0 +1,45 @@
+---
+title: 2 — Configuring Rancher for Microsoft AD FS
+weight: 1205
+---
+_Available as of v2.0.7_
+
+After you complete [Configuring Microsoft AD FS for Rancher]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/microsoft-adfs/microsoft-adfs-setup/), enter your AD FS information into Rancher to allow AD FS users to authenticate with Rancher.
+
+>**Important Notes For Configuring Your AD FS Server:**
+>
+>- The SAML 2.0 WebSSO Protocol Service URL is: `https:///v1-saml/adfs/saml/acs`
+>- The Relying Party Trust identifier URL is: `https:///v1-saml/adfs/saml/metadata`
+>- You must export the `federationmetadata.xml` file from your AD FS server. This can be found at: `https:///federationmetadata/2007-06/federationmetadata.xml`
+
+
+1. From the **Global** view, select **Security > Authentication** from the main menu.
+
+1. Select **Microsoft Active Directory Federation Services**.
+
+1. Complete the **Configure AD FS Account** form. Microsoft AD FS lets you specify an existing Active Directory (AD) server. The examples below describe how you can map AD attributes to fields within Rancher.
+
+ | Field | Description |
+ | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | Display Name Field | The AD attribute that contains the display name of users.
Example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname` |
+ | User Name Field | The AD attribute that contains the user name/given name.
Example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` |
+ | UID Field | An AD attribute that is unique to every user.
Example: `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn` |
+ | Groups Field | Make entries for managing group memberships.
Example: `http://schemas.xmlsoap.org/claims/Group` |
+ | Rancher API Host | The URL for your Rancher Server. |
+ | Private Key / Certificate | This is a key-certificate pair to create a secure shell between Rancher and your AD FS. Ensure you set the Common Name (CN) to your Rancher Server URL.
[Certificate creation command](#cert-command) |
+ | Metadata XML | The `federationmetadata.xml` file exported from your AD FS server.
You can find this file at `https:///federationmetadata/2007-06/federationmetadata.xml`. |
+
+
+ >**Tip:** You can generate a certificate using an openssl command. For example:
+ >
+ > openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
+
+
+
+1. After you complete the **Configure AD FS Account** form, click **Authenticate with AD FS**, which is at the bottom of the page.
+
+ Rancher redirects you to the AD FS login page. Enter credentials that authenticate with Microsoft AD FS to validate your Rancher AD FS configuration.
+
+ >**Note:** You may have to disable your popup blocker to see the AD FS login page.
+
+**Result:** Rancher is configured to work with MS FS. Your users can now sign into Rancher using their MS FS logins.
diff --git a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md
index 1a36dbfcbc0..802cb2a5604 100644
--- a/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/pod-security-policies/_index.md
@@ -31,15 +31,15 @@ Rancher ships with two default Pod Security Policies (PSPs): the `restricted` an
- `restricted`
- This policy is equivilent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.
-
-- `unrestricted`
-
- This policy is based on the Kubernetes [example restricted policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies). It significantly restricts what types of pods can be deployed to a cluster or project. This policy:
+ This policy is based on the Kubernetes [example restricted policy](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml). It significantly restricts what types of pods can be deployed to a cluster or project. This policy:
- Prevents pods from running as a privileged user and prevents escalation of privileges.
- Validates that server-required security mechanisms are in place (such as restricting what volumes can be mounted to only the core volume types and preventing root supplemental groups from being added).
+- `unrestricted`
+
+ This policy is equivilent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project.
+
## Creating Pod Security Policies
1. From the **Global** view, select **Security** > **Pod Security Policies** from the main menu. Then click **Add Policy**.
diff --git a/content/rancher/v2.x/en/admin-settings/server-url/_index.md b/content/rancher/v2.x/en/admin-settings/server-url/_index.md
index 795d04931ee..3a397186163 100644
--- a/content/rancher/v2.x/en/admin-settings/server-url/_index.md
+++ b/content/rancher/v2.x/en/admin-settings/server-url/_index.md
@@ -6,15 +6,13 @@ aliases:
- /rancher/v2.x/en/tasks/global-configuration/server-url/
---
-This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL.
+This is the URL of your Rancher Server. All nodes in your cluster must resolve to this URL. This is also the URL that serves the Rancher API.
-- You are prompted for this URL upon the very first Rancher login.
-- You can edit this URL later by selecting **Settings**.
+You are prompted for this URL upon the very first Rancher login. You should set the URL to the main entry point to the Rancher Server. When a load balancer fronts a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
-The first time that you log into {{< product >}}, the system prompts you for the Rancher Server URL, which is the IP address or host name that your Kubernetes nodes register with.
+Even though you can edit the Rancher Server URL later in the **Settings** UI from the **Global** view, updating the Rancher Server URL must be done with extreme care.
-If you need to update this URL, select **Settings** from the **Global** view.
+- You must also update the SSL certificates to match the new URL.
+- Unless you make sure the old URL continues to work, you will have to re-register all the nodes and clusters so that they point to the new Rancher Server URL.
-### When Should I Update the Rancher Server URL?
-If the URL of your {{< product >}} Server changes, you must update the {{< product >}} Server URL so that your nodes can continue communicating with the {{< product >}} Server.
diff --git a/content/rancher/v2.x/en/backups/backups/ha-backups/_index.md b/content/rancher/v2.x/en/backups/backups/ha-backups/_index.md
index 5ce26b06500..61c731d2d43 100644
--- a/content/rancher/v2.x/en/backups/backups/ha-backups/_index.md
+++ b/content/rancher/v2.x/en/backups/backups/ha-backups/_index.md
@@ -102,5 +102,5 @@ In this documentation, as an example, we're using Amazon S3 as our safe location
```
root@node:~# s3cmd mb s3://rke-etcd-snapshots
-root@node:~# s3cmd /opt/rke/etcd-snapshots/snapshot.db s3://rke-etcd-snapshots/
+root@node:~# s3cmd put /opt/rke/etcd-snapshots/snapshot.db s3://rke-etcd-snapshots/
```
diff --git a/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md b/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md
index d8bc7910d9c..9ea7cce9ddf 100644
--- a/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md
+++ b/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md
@@ -6,41 +6,67 @@ aliases:
- /rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/
---
-After completing your single node installation of Rancher, you can create a backup of your current installation at any time. We recommend making a backup before [upgrading]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Use this backup as a restoration point in disaster scenarios or when you need to [rollback]({{< baseurl >}}/rancher/v2.x/en/backups/rollbacks/single-node-rollbacks/) to an older version.
+After completing your single node installation of Rancher, we recommend creating backups of it on a regular basis. Use these backups as a restoration point in a disaster scenario.
->**Prerequisite:** Open Rancher and write down the version number displayed in the lower-left of the browser (example: `v2.0.0`). You'll need this number during the backup process.
+## Before You Start
-1. Stop the container currently running Rancher Server. Replace `` with the ID of your Rancher container.
+During creation of your backup, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (``). Here's an example of a command with a placeholder:
+
+```
+docker run --volumes-from rancher-data- -v $PWD:/backup alpine tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher
+```
+
+In this command, `` is a placeholder for the date that the data container and backup were created. `9-27-18` for example.
+
+Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
+
+Terminal `docker ps` Command, Displaying Where to Find `` and ``
+
+
+| Placeholder | Example | Description |
+| -------------------------- | -------------------------- | --------------------------------------------------------- |
+| `` | `v2.0.5` | The rancher/rancher image you pulled for initial install. |
+| `` | `festive_mestorf` | The name of your Rancher container. |
+| `` | `v2.0.5` | The version of Rancher that you're creating a backup for. |
+| `` | `9-27-18` | The date that the data container or backup was created. |
+
+
+You can obtain `` and `` by logging into your Rancher Server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.
+
+## Creating a Backup
+
+This procedure creates a backup that you can restore to in case Rancher encounters a disaster scenario.
+
+
+1. Using a remote Terminal connection, log into the node running your Rancher Server.
+
+1. Stop the container currently running Rancher Server. Replace `` with the [name of your Rancher container](#before-you-start).
```
-docker stop
+ docker stop
```
-
- >**Tip:** You can obtain the ID for your Rancher container by entering the following command: `docker ps`.
-
-2. Create a data container. This container contains the data from your current Rancher Server, and can be used to start Rancher Server.
-
- - Replace `` with the same ID from the previous step.
- - Replace `` and `` with the version of Rancher that you are currently running, as mentioned in the **Prerequisite** above.
+1. Use the command below, replacing each [placeholder](#before-you-start), to create a data container from the Rancher container that you just stopped.
```
-docker create --volumes-from \
---name rancher-data- rancher/rancher:
+ docker create --volumes-from --name rancher-data- rancher/rancher:
```
-3. During upgrade, you point to a Rancher server to the same Rancher data container and the Rancher data in the data container will continue to be updated/changed. Therefore, you need to get a snapshot of the data to be used for disaster recovery or in case you need to rollback the upgrade.
+1. From the data container that you just created (`rancher-data-`), create a backup tarball (`rancher-data-backup--.tar.gz`). Use the following command, replacing each [placeholder](#before-you-start).
```
-docker run --volumes-from rancher-data- \
--v $PWD:/backup alpine tar zcvf \
-/backup/rancher-data-backup-.tar.gz /var/lib/rancher
+ docker run --volumes-from rancher-data- -v $PWD:/backup alpine tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher
```
-3. After you've created your backup, you can either restart Rancher server or [upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Replace `` with the ID of your Rancher container.
+ **Step Result:** A stream of commands runs on screen.
+
+1. Enter the `dir` command to confirm that the backup tarball was created. It will have a name similar to `rancher-data-backup--.tar.gz`.
+
+1. Move your backup tarball to a safe location external from your Rancher Server. Then delete the `rancher-data-` container from your Rancher Server.
+
+1. Restart Rancher Server. Replace `` with the name of your [Rancher container](#before-you-start).
```
-# Restart Rancher server
-docker start
+ docker start
```
-**Result:** A backup of your Rancher Server is created. If you ever need to restore your backup, see [Restoring Backups: Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/upgrades/restorations/single-node-restoration).
+**Result:** A backup tarball of your Rancher Server data is created. See [Restoring Backups: Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/single-node-restoration) if you need to restore backup data.
diff --git a/content/rancher/v2.x/en/backups/restorations/_index.md b/content/rancher/v2.x/en/backups/restorations/_index.md
index 88982fcc4bf..ccfb75a22e8 100644
--- a/content/rancher/v2.x/en/backups/restorations/_index.md
+++ b/content/rancher/v2.x/en/backups/restorations/_index.md
@@ -4,5 +4,5 @@ weight: 1010
---
If you lose the data on your Rancher Server, you can restore it if you have backups stored in a safe location.
-- [Restoring Backups—Single Node Installs](./single-node-restoration/)
-- [Restoring Backups—High Availablity Installs](./ha-restoration/)
\ No newline at end of file
+- [Restoring Backups—Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/single-node-restoration/)
+- [Restoring Backups—High Availability Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/ha-restoration/)
diff --git a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
index e60dbcc1c59..be03e233712 100644
--- a/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
+++ b/content/rancher/v2.x/en/backups/restorations/ha-restoration/_index.md
@@ -4,132 +4,191 @@ weight: 370
aliases:
- /rancher/v2.x/en/installation/after-installation/ha-backup-and-restoration/
---
-This procedure describes how to restore your a snapshot of `etcd` if you lose your Rancher data in a disaster scenario.
-## Restoration Outline
+This procedure describes how to use RKE to restore a snapshot of the Rancher Kubernetes cluster. The cluster snapshot will include Kubernetes configuration and the Rancher database and state.
-Following a disaster scenario, restoration of your HA Rancher installation requires you to pull your snapshot from your chosen external location and then restore it.
+## Restore Outline
-1. [Create New Nodes and Pull Snapshot and Certificates Bundle](#1-create-new-nodes-and-pull-snapshot-and-certificate-bundle)
+1. [Preparation](#1-preparation)
- If `etcd` nodes failed or quorum lost for any reason, you can create new nodes and restore the etcd snapshot and certificate bundle to it, first create the new nodes and then pull the most recent `etcd` snapshot to that node, and the most recent certificates pki bundle `pki.bundle.tar.gz`
+ Install utilities and create new or clean existing nodes to prepare for restore.
-2. [Restore etcd Database](#2-restore-etcd-database)
+2. [Place Snapshot and PKI Bundle](#2-place-snapshot-and-pki-bundle)
- After you pull the snapshot and the certificates bundle, run the RKE command to restore the `etcd` database.
+ Pick a node and place snapshot `.db` and `pki.bundle.tar.gz` files.
+
+3. [Configure RKE](#3-configure-rke)
+
+ Configure RKE `cluster.yml`. Remove `addons:` section and point configuration to the clean nodes.
+
+4. [Restore Database](#4-restore-database)
+
+ Run RKE command to restore the `etcd` database to a single node.
+
+5. [Bring Up the Cluster](#5-bring-up-the-cluster)
+
+ Run RKE commands to bring up cluster one a single node. Clean up old nodes. Verify and add additional nodes.
-### 1. Pull Snapshot and Certificates Bundle On New Nodes
-If `etcd` nodes failed, you can either:
+### 1. Preparation
-- Create a new nodes of your choice—baremetal, on-prem virtual machine, cloud-based virtual machine, and so on. Provision it according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/#host-requirements).
+You will need [RKE]({{< baseurl >}}/rke/v0.1.x/en/installation/) and [kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/) CLI utilities installed.
-- Use the existing nodes, but you should be make sure to clean each node using the following commands:
+Prepare by creating 3 new nodes to be the target for the restored Rancher instance. See [HA Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/) for node requirements.
+
+We recommend that you start with fresh nodes and a clean state. Alternatively you can clear Kubernetes and Rancher configurations from the existing nodes. This will destroy the data on these nodes. See [Node Cleanup]({{< baseurl >}}/rancher/v2.x/en/faq/cleaning-cluster-nodes/) for the procedure.
+
+> **IMPORTANT:** Before starting the restore make sure all the kubernetes services on the old cluster nodes are stopped. We recommend powering off the nodes to be sure.
+
+### 2. Place Snapshot and PKI Bundle
+
+Pick a one of the clean nodes. That node will be the "target node" for the initial restore. Place the snapshot and PKI certificate bundle files in the `/opt/rke/etcd-snapshots` directory on the "target node".
+
+* Snapshot - `.db`
+* PKI Bundle - `pki.bundle.tar.gz`
+
+### 3. Configure RKE
+
+Make a copy of your original `rancher-cluster.yml` file.
```
-docker rm -fv $(docker ps -qa)
-docker volume ls -q | xargs docker volume rm
-rm -rf /etc/kubernetes/ssl
-rm -rf /etc/kubernetes/.tmp
-rm -rf /var/lib/etcd
-rm -rf /etc/cni
-rm -rf /etc/kube-flannel/
+cp rancher-cluster.yml rancher-cluster-restore.yml
```
-in both cases you will need to pull the most recent working `etcd` snapshot and the certificates bundle to these nodes.
+Modify the copy and make the following changes.
-**To Pull the Latest Snapshot and Certificates Bundle:**
+* Remove or comment out entire the `addons:` section. The Rancher deployment and supporting configuration is already in the `etcd` database.
+* Change your `nodes:` section to point to the restore nodes.
+* Comment out the nodes that are not your "target node". We want the cluster to only start on that one node.
-1. Log in to each new node using a remote Terminal connection.
+*Example* `rancher-cluster-restore.yml`
-2. Create a directory that mirrors your other nodes' snapshot directories:
+```yaml
+nodes:
+- address: 52.15.238.179 # New Target Node
+ user: ubuntu
+ role: [ etcd, controlplane, worker ]
+# - address: 52.15.23.24
+# user: ubuntu
+# role: [ etcd, controlplane, worker ]
+# - address: 52.15.238.133
+# user: ubuntu
+# role: [ etcd, controlplane, worker ]
- ```
- root@newnode:~# mkdir -p /opt/rke/etcd-snapshots
- ```
+# addons: |-
+# ---
+# kind: Namespace
+# apiVersion: v1
+# metadata:
+# name: cattle-system
+# ---
+...
-3. On each node, pull your most recent snapshot onto the node. Replace `` with the name of the snapshot you're restoring to.
-
- ```
- root@newnode:~# s3cmd get s3://rke-etcd-snapshots/ /opt/rke/etcd-snapshots/
- ```
-
- >**Remember:** Our use of Amazon S3 is an example used for this documentation. The command for pulling your snapshot may vary.
-
-4. On each node, pull the most recent certificates pki bundle to the `/opt/rke/etcd-snapshots`:
-
- ```
- root@newnode:~# s3cmd get s3://rke-etcd-snapshots/pki.bundle.tar.gz /opt/rke/etcd-snapshots/pki.bundle.tar.gz
- ```
-
-### 2. Restore `etcd` Database
-
-To restore the most recent `etcd` snapshot on your new nodes, run RKE the command `rke etcd snapshot-restore`. This command reverts to any snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. When you run `rke etcd snapshot-restore`, RKE removes the old `etcd` container if it still exists. To restore operations, RKE creates a new `etcd` cluster using the snapshot you choose, and extracts the certificate bundle to be used on the next `rke up` run.
-
->**Warning:** Restoring an `etcd` snapshot deletes your current `etcd` cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, backup any important data in your current cluster.
->
->**Prerequisites:** {{< requirements_rollback >}}
-
-
-1. From your workstation, open `rancher-cluster.yml` in your favorite text editor.
-
-2. Replace the unresponsive nodes (`1.1.1.1`, `2.2.2.2`, `3.3.3.3` in this example) with your new one (`4.4.4.4`, `5.5.5.5`, and `6.6.6.6`). You IP addresses will be different obviously:
-```
- nodes:
- # - address: 1.1.1.1 # UNRESPONSIVE NODE
- # user: root
- # role: [controlplane,etcd,worker]
- # ssh_key_path: ~/.ssh/id_rsa
- # - address: 2.2.2.2 # UNRESPONSIVE NODE
- # user: root
- # role: [controlplane,etcd,worker]
- # ssh_key_path: ~/.ssh/id_rsa
- # - address: 3.3.3.3 # UNRESPONSIVE NODE
- # user: root
- # role: [controlplane,etcd,worker]
- # ssh_key_path: ~/.ssh/id_rsa
- - address: 4.4.4.4 # NEW NODE
- user: root
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
- - address: 5.5.5.5 # NEW NODE
- user: root
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
- - address: 6.6.6.6 # NEW NODE
- user: root
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
```
-3. Save and close `rancher-cluster.yml`.
+### 4. Restore Database
-4. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
+Use RKE with the new `rancher-cluster-restore.yml` configuration and restore the database to the single "target node".
-5. Run one of the following commands to restore the `etcd` database:
+```
+rke etcd snapshot-restore --name .db --config ./rancher-cluster-restore.yml
+```
- ```
- # MacOS
- ./rke_darwin-amd64 etcd snapshot-restore --name --config rancher-cluster.yml
- # Linux
- ./rke_linux-amd64 etcd snapshot-restore --name --config rancher-cluster.yml
- ```
+> **NOTE:** RKE will create an `etcd` container with the restored database on the "target node". This container will not complete the `etcd` initialization and stay in a running state until the cluster brought up in the next step.
+### 5. Bring Up the Cluster
-6. Run one of the following commands to bring your cluster back up:
+Use RKE and bring up the cluster on the single "target node".
- ```
- # MacOS
- ./rke_darwin-amd64 up --config rancher-cluster.yml
- # Linux
- ./rke_linux-amd64 up --config rancher-cluster.yml
- ```
+```
+rke up --config ./rancher-cluster-restore.yml
+```
-7. After restoring the cluster you have to restart the kubernetes components on all nodes, otherwise there will be some conflicts with resource versions of objects stored in `etcd`, this will include restart to kubernetes components and the network components, for more information please refer to [kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#etcd-upgrade-requirements), to do that you can run the following on each node:
+#### Testing the Cluster
- ```
- docker restart kube-apiserver kubelet kube-controller-manager kube-scheduler kube-proxy
- docker ps | grep flannel | cut -f 1 -d " " | xargs docker restart
- docker ps | grep calico | cut -f 1 -d " " | xargs docker restart
- ```
+Once RKE completes it will have created a credentials file in the local directory. Configure `kubectl` to use the `kube_config_rancher-cluster-restore.yml` credentials file and check on the state of the cluster. See [Installing and Configuring kubectl]({{< baseurl >}}/rancher/v2.x/en/faq/kubectl/#configuration) for details.
+
+Your new cluster will take a few minutes to stabilize. Once you see the new "target node" transition to `Ready` and three old nodes in `NotReady` you are ready to continue.
+
+```
+kubectl get nodes
+
+NAME STATUS ROLES AGE VERSION
+52.15.238.179 Ready controlplane,etcd,worker 1m v1.10.5
+18.217.82.189 NotReady controlplane,etcd,worker 16d v1.10.5
+18.222.22.56 NotReady controlplane,etcd,worker 16d v1.10.5
+18.191.222.99 NotReady controlplane,etcd,worker 16d v1.10.5
+```
+
+#### Cleaning up Old Nodes
+
+Use `kubectl` to delete the old nodes from the cluster.
+
+```
+kubectl delete node 18.217.82.189 18.222.22.56 18.191.222.99
+```
+
+#### Reboot the Target Node
+
+Reboot the target node to ensure the cluster networking and services are in a clean state before continuing.
+
+#### Check Kubernetes Pods
+
+Wait for the pods running in `kube-system`, `ingress-nginx` and the `rancher` pod in `cattle-system` to return to the `Running` state.
+
+> **Note:** `cattle-cluster-agent` and `cattle-node-agent` pods will be in an `Error` or `CrashLoopBackOff` state until Rancher server is up and the DNS/Load Balancer have been pointed at the new cluster.
+
+```
+kubectl get pods --all-namespaces
+
+NAMESPACE NAME READY STATUS RESTARTS AGE
+cattle-system cattle-cluster-agent-766585f6b-kj88m 0/1 Error 6 4m
+cattle-system cattle-node-agent-wvhqm 0/1 Error 8 8m
+cattle-system rancher-78947c8548-jzlsr 0/1 Running 1 4m
+ingress-nginx default-http-backend-797c5bc547-f5ztd 1/1 Running 1 4m
+ingress-nginx nginx-ingress-controller-ljvkf 1/1 Running 1 8m
+kube-system canal-4pf9v 3/3 Running 3 8m
+kube-system cert-manager-6b47fc5fc-jnrl5 1/1 Running 1 4m
+kube-system kube-dns-7588d5b5f5-kgskt 3/3 Running 3 4m
+kube-system kube-dns-autoscaler-5db9bbb766-s698d 1/1 Running 1 4m
+kube-system metrics-server-97bc649d5-6w7zc 1/1 Running 1 4m
+kube-system tiller-deploy-56c4cf647b-j4whh 1/1 Running 1 4m
+```
+
+#### Adding in Additional Nodes
+
+Edit the `rancher-cluster-restore.yml` RKE config file and uncomment the additional nodes.
+
+*Example* `rancher-cluster-restore.yml`
+
+```yaml
+nodes:
+- address: 52.15.238.179 # New Target Node
+ user: ubuntu
+ role: [ etcd, controlplane, worker ]
+- address: 52.15.23.24
+ user: ubuntu
+ role: [ etcd, controlplane, worker ]
+- address: 52.15.238.133
+ user: ubuntu
+ role: [ etcd, controlplane, worker ]
+
+# addons: |-
+# ---
+# kind: Namespace
+...
+
+```
+
+Run RKE and add the nodes to the new cluster.
+
+```
+rke up --config ./rancher-cluster-restore.yml
+```
+
+#### Finishing Up
+
+Rancher should now be running and available to manage your Kubernetes clusters. Swap your Rancher DNS or Load Balancer endpoints to target the new cluster. Once this is done the agents on your managed clusters should automatically reconnect. This may take 10-15 minutes due to reconnect back off timeouts.
+
+> **IMPORTANT:** Remember to save your new RKE config (`rancher-cluster-restore.yml`) and `kubectl` credentials (`kube_config_rancher-cluster-restore.yml`) files in a safe place for future maintenance.
diff --git a/content/rancher/v2.x/en/backups/restorations/single-node-restoration/_index.md b/content/rancher/v2.x/en/backups/restorations/single-node-restoration/_index.md
index 2b057b1384f..0a09c1c0684 100644
--- a/content/rancher/v2.x/en/backups/restorations/single-node-restoration/_index.md
+++ b/content/rancher/v2.x/en/backups/restorations/single-node-restoration/_index.md
@@ -6,26 +6,66 @@ aliases:
- /rancher/v2.x/en/installation/after-installation/single-node-backup-and-restoration/
---
-Restoring to a backup for your Rancher install if you encounter issues in your Rancher setup.
+If you encounter a disaster scenario, you can restore your Rancher Server to your most recent backup.
-1. Stop the container currently running Rancher Server. Replace `` with the ID of your Rancher container.
+## Before You Start
+
+During restoration of your backup, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (``). Here's an example of a command with a placeholder:
+
+```
+docker run --volumes-from -v $PWD:/backup
+alpine sh -c "rm /var/lib/rancher/* -rf &&
+tar zxvf /backup/rancher-data-backup--"
+```
+
+In this command, `` and `-` are environment variables for your Rancher deployment.
+
+Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
+
+Terminal `docker ps` Command, Displaying Where to Find `` and ``
+
+
+| Placeholder | Example | Description |
+| -------------------------- | -------------------------- | --------------------------------------------------------- |
+| `` | `v2.0.5` | The rancher/rancher image you pulled for initial install. |
+| `` | `festive_mestorf` | The name of your Rancher container. |
+| `` | `v2.0.5` | The version number for your Rancher backup. |
+| `` | `9-27-18` | The date that the data container or backup was created. |
+
+
+You can obtain `` and `` by logging into your Rancher Server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.
+
+## Restoring Backups
+
+Using a [backup]({{< baseurl >}}/rancher/v2.x/en/backups/backups/single-node-backups/) that you created earlier, restore Rancher to its last known healthy state.
+
+1. Using a remote Terminal connection, log into the node running your Rancher Server.
+
+1. Stop the container currently running Rancher Server. Replace `` with the [name of your Rancher container](#before-you-start).
```
-docker stop
+ docker stop
```
+1. Move the backup tarball that you created during completion of [Creating Backups—Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/backups/backups/single-node-backups/) onto your Rancher Server. Change to the directory that you moved it to. Enter `dir` to confirm that it's there.
-2. Go to the location where you saved your [backup tar balls]({{< baseurl >}}/rancher/v2.x/en/backups/backups/single-node-backups/#backup). Run the following command to delete your current state data and start your backup data:
+ If you followed the naming convention we suggested in [Creating Backups—Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/backups/backups/single-node-backups/), it will have a name similar to `rancher-data-backup--.tar.gz`.
+
+1. Enter the following command to delete your current state data and replace it with your backup data, replacing the [placeholders](#before-you-start). Don't forget to close the quotes.
+
+ >**Warning!** This command deletes all current state data from your Rancher Server container. Any changes saved after your backup tarball was created will be lost.
```
-docker run --volumes-from -v $PWD:/backup \
-alpine sh -c "rm /var/lib/rancher/* -rf && \
-tar zxvf /backup/.tar.gz"
+ docker run --volumes-from -v $PWD:/backup
+ alpine sh -c "rm /var/lib/rancher/* -rf &&
+ tar zxvf /backup/rancher-data-backup--.tar.gz"
```
- >**Warning!** Running this command will delete ALL current state data from your Rancher Server container. Any changes that happened after the backup point you are restoring will be lost.
+ **Step Result:** A series of commands should run.
-3. Start you rancher server container back. The container will start with the data from the restored backup.
+1. Restart your Rancher Server container, replacing the [placeholder](#before-you-start). It will restart using your backup data.
```
-docker start
+ docker start
```
+
+1. Wait a few moments and then open Rancher in a web browser. Confirm that the restoration succeeded and that your data is restored.
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/cluster-provisioning/_index.md b/content/rancher/v2.x/en/cluster-provisioning/_index.md
index baca10785ed..808214f97e8 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/_index.md
@@ -10,7 +10,7 @@ aliases:
## What's a Kubernetes Cluster?
-In the IT world, a cluster is a group of computing resources that work as a team to accomplish a goal.
+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.
@@ -18,7 +18,7 @@ A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestr
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 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.
diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
index 47515a3d332..d5f24679f95 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/_index.md
@@ -23,20 +23,4 @@ RKE launched clusters are separated into two categories:
### Requirements
-If you use RKE to set up a cluster, your cluster nodes must meet the following requirements.
-
-{{< accordion id="os" label="Operating System" >}}
- {{< requirements_os >}}
-{{< /accordion >}}
-{{< accordion id="hardware" label="Hardware" >}}
- {{< requirements_hardware >}}
-{{< /accordion >}}
-{{< accordion id="software" label="Software" >}}
- {{< requirements_software >}}
-{{< /accordion >}}
-{{< accordion id="ports-rancher" label="Ports for Rancher" >}}
- {{< requirements_ports_rancher >}}
-{{< /accordion >}}
-{{< accordion id="ports-rke" label="Ports for RKE" >}}
- {{< requirements_ports_rke >}}
-{{< /accordion >}}
\ No newline at end of file
+If you use RKE to set up a cluster, your cluster nodes must meet our [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
\ No newline at end of file
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 d8d02e2aa06..dd27877c907 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
@@ -42,22 +42,7 @@ Provision the host according to the requirements below.
### Requirements
-{{< accordion id="os" label="Operating System" >}}
- {{< requirements_os >}}
-{{< /accordion >}}
-{{< accordion id="hardware" label="Hardware" >}}
- {{< requirements_hardware >}}
-{{< /accordion >}}
-{{< accordion id="software" label="Software" >}}
- {{< requirements_software >}}
-{{< /accordion >}}
-{{< accordion id="ports-rancher" label="Ports for Rancher" >}}
- {{< requirements_ports_rancher >}}
-{{< /accordion >}}
-{{< accordion id="ports-rke" label="Ports for RKE" >}}
- {{< requirements_ports_rke >}}
-{{< /accordion >}}
-
+Each node in your cluster must meet our [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
## Create the Custom Cluster
diff --git a/content/rancher/v2.x/en/contributing/_index.md b/content/rancher/v2.x/en/contributing/_index.md
index 4bbae3d1f3d..a5230c092ff 100644
--- a/content/rancher/v2.x/en/contributing/_index.md
+++ b/content/rancher/v2.x/en/contributing/_index.md
@@ -7,16 +7,32 @@ aliases:
### Repositories
-All of repositories are located within our main GitHub organization. There are many repositories used for Rancher, but we’ll provide descriptions of some of the main ones used in Rancher.
+All of repositories are located within our main GitHub organization. There are many repositories used for Rancher, but we'll provide descriptions of some of the main ones used in Rancher.
-- [Rancher Repo](https://github.com/rancher/rancher): This repository is the main source code for Rancher 2.x.
+Repository | URL | Description
+-----------|-----|-------------
+Rancher | https://github.com/rancher/rancher | This repository is the main source code for Rancher 2.x.
+Types | https://github.com/rancher/types | This repository is the repository that has all the API types for Rancher 2.x.
+API Framework | https://github.com/rancher/norman | This repository is an API framework for building Rancher style APIs backed by Kubernetes Custom Resources.
+User Interface | https://github.com/rancher/ui | This repository is the source of the UI.
+(Rancher) Docker Machine | https://github.com/rancher/machine | This repository is the source of the Docker Machine binary used when using Node Drivers. This is a fork of the `docker/machine` repository.
+machine-package | https://github.com/rancher/machine-package | This repository is used to build the Rancher Docker Machine binary.
+kontainer-engine | https://github.com/rancher/kontainer-engine | This repository is the source of kontainer-engine, the tool to provision hosted Kubernetes clusters.
+RKE repository | https://github.com/rancher/rke | This repository is the source of Rancher Kubernetes Engine, the tool to provision Kubernetes clusters on any machine.
+CLI | https://github.com/rancher/cli | This repository is the source code for the Rancher CLI used in Rancher 2.x.
+(Rancher) Helm repository | https://github.com/rancher/helm | This repository is the source of the packaged Helm binary. This is a fork of the `helm/helm` repository.
+Telemetry repository | https://github.com/rancher/telemetry | This repository is the source for the Telemetry binary.
+loglevel repository | https://github.com/rancher/loglevel | This repository is the source of the loglevel binary, used to dynamically change log levels.
-- [Rancher Types Repo](https://github.com/rancher/types): This repository is the repo that has all the API types for Rancher 2.x.
+To see all libraries/projects used in Rancher, see the `vendor.conf` in the `rancher/rancher repository.
-- [Rancher API Framework Repo](https://github.com/rancher/norman): This repository is an API framework for building Rancher style APIs backed by Kubernetes Custom Resources.
+### Building
-- [Rancher CLI Repo](https://github.com/rancher/cli): This repository is the source code for the Rancher CLI used in Rancher 2.x.
+Every repository should have a Makefile and can be built using the `make` command. The `make` targets are based on the scripts in the `/scripts` directory in the repository (plus additional `trash` commands, please see below for more information about using `trash`), and each target will use [Dapper](https://github.com/rancher/dapper) to run the target in an isolated environment. The `Dockerfile.dapper` will be used for this process, and includes all the necessary build tooling needed.
+The default target is `ci`, and will run `./scripts/validate`, `./scripts/build`, `./scripts/test` and `./scripts/package`. The resulting binaries of the build will be in `./build/bin` and are usually also packaged in a Docker image.
+
+Dependencies on other libraries/projects are managed using [Trash](https://github.com/rancher/trash). See the [Trash README](https://github.com/rancher/trash/blob/master/README.md) to discover how it can be used. In short, it uses a `vendor.conf` file to specify the source repository and revision to fetch, checkout and copy to the `./vendor` directory. After updating `vendor.conf`, you can run `make trash` to update dependencies for your change. When the dependencies are updated, you can build the project again using `make` so that it will be built using the updated dependencies.
### Bugs, Issues or Questions
@@ -70,6 +86,6 @@ If you are experiencing performance issues, please provide as much of data (file
If you have any updates to our documentation, please make any pull request to our docs repo.
-- [Rancher 2.x Docs Repo](https://github.com/rancher/docs): This repo is where all the docs for Rancher 2.x are located. They are located in the `content` folder in the repo.
+- [Rancher 2.x Docs repository](https://github.com/rancher/docs): This repo is where all the docs for Rancher 2.x are located. They are located in the `content` folder in the repo.
-- [Rancher 1.x Docs Repo](https://github.com/rancher/rancher.github.io): This repo is where all the docs for Rancher 1.x are located. They are located in the `rancher` folder in the repo.
+- [Rancher 1.x Docs repository](https://github.com/rancher/rancher.github.io): This repo is where all the docs for Rancher 1.x are located. They are located in the `rancher` folder in the repo.
diff --git a/content/rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes/_index.md b/content/rancher/v2.x/en/faq/cleaning-cluster-nodes/_index.md
similarity index 97%
rename from content/rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes/_index.md
rename to content/rancher/v2.x/en/faq/cleaning-cluster-nodes/_index.md
index 29fda3d5053..4d9c627eedd 100644
--- a/content/rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes/_index.md
+++ b/content/rancher/v2.x/en/faq/cleaning-cluster-nodes/_index.md
@@ -1,6 +1,9 @@
---
title: Cleaning cluster nodes
weight: 375
+aliases:
+ - /rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes/
+ - /rancher/v2.x/en/installation/removing-rancher/
---
When adding a node to a cluster, resources (containers/(virtual) network interfaces) and configuration items (certificates/configuration files) are created. When removing a node from a cluster (if it is in `Active` state), those resources will be 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.
@@ -183,4 +186,4 @@ Chains |
iptables -L -t nat
iptables -L -t mangle
iptables -L
-```
+```
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/faq/kubectl/_index.md b/content/rancher/v2.x/en/faq/kubectl/_index.md
new file mode 100644
index 00000000000..b4172ab0a40
--- /dev/null
+++ b/content/rancher/v2.x/en/faq/kubectl/_index.md
@@ -0,0 +1,30 @@
+---
+title: Installing and Configuring kubectl
+weight: 100
+---
+
+`kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.
+
+### Installation
+
+See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubectl/) for installation on your operating system.
+
+### Configuration
+
+When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_rancher-cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`.
+
+You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`.
+
+```
+export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml
+```
+
+Test your connectivity with `kubectl` and see if you can get the list of nodes back.
+
+```
+kubectl get nodes
+ NAME STATUS ROLES AGE VERSION
+165.227.114.63 Ready controlplane,etcd,worker 11m v1.10.1
+165.227.116.167 Ready controlplane,etcd,worker 11m v1.10.1
+165.227.127.226 Ready controlplane,etcd,worker 11m v1.10.1
+```
diff --git a/content/rancher/v2.x/en/faq/networking/_index.md b/content/rancher/v2.x/en/faq/networking/_index.md
new file mode 100644
index 00000000000..ef4a030f7a8
--- /dev/null
+++ b/content/rancher/v2.x/en/faq/networking/_index.md
@@ -0,0 +1,9 @@
+---
+title: Networking
+weight: 8005
+---
+
+Networking FAQ's
+
+- [CNI Providers]({{< baseurl >}}/rancher/v2.x/en/faq/networking/cni-providers/)
+
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
new file mode 100644
index 00000000000..531303bafc3
--- /dev/null
+++ b/content/rancher/v2.x/en/faq/networking/cni-providers/_index.md
@@ -0,0 +1,135 @@
+---
+title: CNI Providers
+weight: 2300
+---
+
+## What is CNI?
+
+CNI (Container Network Interface), a [Cloud Native Computing Foundation project](https://cncf.io/), consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted.
+
+Kubernetes uses CNI as an interface between network providers and Kubernetes pod networking.
+
+
+
+For more information visit [CNI GitHub project](https://github.com/containernetworking/cni).
+
+### What Network Models are Used in CNI?
+
+CNI providers implement their network fabric using either an encapsulated network model such as Virtual Extensible Lan ([VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)) or an unencapsulated network model such as Border Gateway Protocol ([BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol)).
+
+#### What is an Encapsulated Network?
+
+This network model provides a logical Layer 2 (L2) network encapsulated over the existing Layer 3 (L3) network topology that spans the Kubernetes cluster nodes. With this model you have an isolated L2 network for containers without needing routing distribution, all at the cost of minimal overhead in terms of processing and increased IP package size, which comes from an IP header generated by overlay encapsulation. Encapsulation information is distributed by UDP ports between Kubernetes workers, interchanging network control plane information about how MAC addresses can be reached. Common encapsulation used in this kind of network model is VXLAN, Internet Protocol Security (IPSec), and IP-in-IP.
+
+In simple terms, this network model generates a kind of network bridge extended between Kubernetes workers, where pods are connected.
+
+This network model is used when an extended L2 bridge is preferred. This network model is sensible for L3 network latencies of the Kubernetes workers. If datacenters are in distinct geolocations, be sure to have low latencies between them to avoid eventual network segmentation.
+
+CNI providers using this network model include Flannel, Canal, and Weave.
+
+
+
+#### What is an Unencapsulated Network?
+
+This network model provides an L3 network to route packets between containers. This model doesn't generate an isolated l2 network, nor generates overhead. These benefits come at the cost of Kubernetes workers having to manage any route distribution that's needed. Instead of using IP headers for encapsulation, this network model uses a network protocol between Kubernetes workers to distribute routing information to reach pods, such as [BGP](https://en.wikipedia.org/wiki/Border_Gateway_Protocol).
+
+In simple terms, this network model generates a kind of network router extended between Kubernetes workers, which provides information about how to reach pods.
+
+This network model is used when a routed L3 network is preferred. This mode dynamically updates routes at the OS level for Kubernetes workers. It's less sensible to latency.
+
+CNI providers using this network model include Calico and Romana.
+
+
+
+### What CNI Providers are Supported by Rancher?
+
+Out-of-the-box, Rancher supports three different CNI providers for Kubernetes clusters: Canal, Flannel, and Calico. You can choose your CNI when you create new Kubernetes clusters from Rancher.
+
+#### Canal
+
+
+
+Canal is a CNI provider that gives you the best of Flannel and Calico. It allows users to easily deploy Calico and Flannel networking together as a unified networking solution, combining Calico’s network policy enforcement with the rich superset of Calico (unencapsulated) and/or Flannel (encapsulated) network connectivity options.
+
+In Rancher, Canal is the default CNI provider combined with Flannel and VXLAN encapsulation.
+
+Kubernetes workers should open UDP port `8472` (VXLAN) and `9099` (healthcheck).
+
+
+
+For more information, see the [Canal GitHub Page](https://github.com/projectcalico/canal).
+
+#### Flannel
+
+
+
+Flannel is a simple and easy way to configure L3 network fabric designed for Kubernetes. Flannel runs a single binary agent named flanneld on each host, which is responsible for allocating a subnet lease to each host out of a larger, preconfigured address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any auxiliary data (such as the host's public IP). Packets are forwarded using one of several backend mechanisms, with the default encapsulation being [VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan).
+
+Encapsulated traffic is unencrypted by default. Threfore, flannel provides an experimental backend for encryption, [IPSec](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#ipsec), which makes use of [strongSwan](https://www.strongswan.org/) to establish encrypted IPSec tunnels between Kubernetes workers.
+
+Kubernetes workers should open UDP port `8472` (VXLAN) and `9099` (healthcheck).
+
+
+
+For more information, see the [Flannel GitHub Page](https://github.com/coreos/flannel).
+
+#### Calico
+
+
+
+Calico enables networking and network policy in Kubernetes clusters across the cloud. Calico uses a pure, unencapsulated IP network fabric and policy engine to provide networking for your Kubernetes workloads. Workloads are able to communicate over both cloud infrastructure and on-premise using BGP.
+
+Calico also provides a stateless IP-in-IP encapsulation mode that can be used, if necessary. Calico also offers policy isolation, allowing you to secure and govern your Kubernetes workloads using advanced ingress and egress policies.
+
+Kubernetes workers should open TCP port `179` (BGP).
+
+
+
+For more information, see the following pages:
+
+- [Project Calico Official Site](https://www.projectcalico.org/)
+- [Project Calico GitHub Page](https://github.com/projectcalico/calico)
+
+
+### CNI Features by Provider
+
+The following table summarizes the different features available for each CNI provider supported by Rancher.
+
+| Provider | Network Model | Route Distribution | Network Policies | Mesh | External Datastore | Encryption | Ingress/Egress Policies | Commercial Support |
+| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
+| Canal | Encapsulated (VXLAN) | No | Yes | No | K8S API | No | Yes | No |
+| Flannel | Encapsulated (VXLAN) | No | No | No | K8S API | No | No | No |
+| Calico | Unencapsulated | Yes | Yes | Yes | Etcd | Yes | Yes | Yes |
+
+
+- Network Model: Encapsulated or unencapsulated. For more information, see [What Network Models are Used in CNI?](#what-network-models-are-used-in-cni)
+
+- Route Distribution: An exterior gateway protocol designed to exchange routing and reachability information on the Internet. BGP can assist with pod-to-pod networking between clusters. This feature is a must on unencapsulated CNI providers, and it is typically done by BGP. If you plan to build clusters split across network segments, route distribution is a feature that's nice-to-have.
+
+- Network Policies: Kubernetes offers functionality to enforce rules about which services can communicate with each other using network policies. This feature is stable as of Kubernetes v1.7 and is ready to use with supported networking plugins.
+
+- Mesh: This feature allows service-to-service networking communication between distinct Kubernetes clusters.
+
+- External Datastore: CNI providers with this feature need an external datastore for its data.
+
+- Encyption: 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.
+
+#### CNI Community Popularity
+
+The following table summarizes different GitHub metrics to give you an idea of each supported project's popularity and activity. This data was collected in July 2018.
+
+| Provider | Project | Stars | Forks | Contributors |
+| ---- | ---- | ---- | ---- | ---- |
+| Canal | https://github.com/projectcalico/canal | 536 | 75 | 19 |
+| flannel | https://github.com/coreos/flannel | 3.279 | 774 | 107 |
+| Calico | https://github.com/projectcalico/calico | 572 | 225 | 82 |
+
+### Which CNI Provider Should I Use?
+
+It depends on your project needs. There are many different providers, which each have various features and options. There isn't one provider that meets everyone's needs. At the moment, Rancher v2.0 supports the 3 most versatile CNI providers.
+
+As of Rancher v2.0.7, Canal is the default CNI provider. We recommend it for most use cases. It provides encapsulated networking for containers with Flannel, while adding Calico network policies that can provide project/namespace isolation in terms of networking.
+
+All of 3 solutions are capable CNI providers and will likely suit your needs.
diff --git a/content/rancher/v2.x/en/installation/_index.md b/content/rancher/v2.x/en/installation/_index.md
index d50710ea34d..55431c72e4f 100644
--- a/content/rancher/v2.x/en/installation/_index.md
+++ b/content/rancher/v2.x/en/installation/_index.md
@@ -4,38 +4,22 @@ weight: 50
---
This section contains instructions for installing Rancher in development and production environments.
-Choose from the following installation options:
+### Installation Options
-- [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install)
+- [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/)
- In this simple install scenario, you install Rancher on a single Linux host.
+ Install Rancher on a single Linux host. Single node installs are recommended for development and test environments, as setup is simple and the server doesn't have to be readily available for a user base—only the developer or tester.
-- [Single Node Installation with External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install-external-lb)
+- [High Availability Installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha/)
- In this scenario, you install Rancher on a single Linux host and access it using an external load balancer/proxy.
+ This install scenario creates a new Kubernetes cluster dedicated to running Rancher Server in a high-availability (HA) configuration, which runs Rancher Server on multiple hosts so that it's always accessible provided that one of your cluster nodes is running. We recommend high-availability installs in production environments, where your user base requires 24/7 access to your applications.
-- [High Availability Installation]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/)
+### Reference
- This install scenario creates a new Kubernetes cluster dedicated to running Rancher Server in a high-availabilty (HA) configuration.
+- [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/)
-- [High Availability Installation with External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb)
-
- This install scenario creates a new Kubernetes cluster dedicated to running Rancher Server in a high-availabilty (HA) configuration. A load balancer is placed in front of the HA configuration.
-
-- [Air Gap Installation]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/)
-
- We also have instructions for a more specialized use case where you install Rancher Server in an environment without an Internet connection.
-
-This section also includes help content for Rancher configuration and maintenance.
-
-- [Backups and Rollbacks]({{< baseurl >}}/rancher/v2.x/en/backups/)
-
- This page lists the ports you must open to operate Rancher.
+ A reference of hardware and software requirements for the server(s) hosting Rancher.
- [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/)
- This page lists the ports you must open to operate Rancher.
-
-- [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/proxy-configuration/)
-
- If your Rancher installation runs behind a proxy, this page provides information on how to configure Rancher for your proxy.
+ List of required ports you must open to operate Rancher.
diff --git a/content/rancher/v2.x/en/installation/air-gap-installation/_index.md b/content/rancher/v2.x/en/installation/air-gap-installation/_index.md
index a65c2d4614e..63e5add3d4d 100644
--- a/content/rancher/v2.x/en/installation/air-gap-installation/_index.md
+++ b/content/rancher/v2.x/en/installation/air-gap-installation/_index.md
@@ -1,32 +1,31 @@
---
-title: Air Gap Installation
-weight: 345
+title: Preparing for Air Gap Install
+weight: 300
---
Rancher supports installing from a private registry. In every [release](https://github.com/rancher/rancher/releases), we provide you with the needed Docker images and scripts to mirror those images to your own registry. The Docker images are used when nodes are added to a cluster, or when you enable features like pipelines or logging.
>**Prerequisite:** It is assumed you either have your own private registry or other means of distributing docker images to your machine. If you need help with creating a private registry, please refer to the [Docker documentation for private registries](https://docs.docker.com/registry/).
+>**Note:** In Rancher v2.0.x, registries with authentication are not supported for installing from a private registry. The Docker images can only be pulled from a registry without authentication enabled. This limitation only applies to Docker images.
->**Note:** In Rancher v2.0.0, registries with authentication are not supported for installing from a private registry. The Docker images can only be pulled from a registry without authentication enabled. This limitation only applies to Docker images.
-
-## Release files
+## Release Files
* **rancher-images.txt**: Contains all images needed for that release.
* **rancher-save-images.sh**: This script will pull all needed images from DockerHub, and save all of the images as a compressed file called `rancher-images.tar.gz`. This file can be transferred to your on-premise host that can access your private registry.
* **rancher-load-images.sh**: This script will load images from rancher-images.tar.gz and push them to your private registry. You have to supply the hostname of your private registry as first argument to the script.
`rancher-load-images.sh registry.yourdomain.com:5000`
-### Making the Rancher images available
+## Making the Rancher Images Available
We will cover two scenarios:
-* **Scenario 1**: You have one host that can access DockerHub to pull and save the images, and a separate host that access your private registry to push the images.
-* **Scenario 2**: You have one host that can access both DockerHub and your private registry.
+* **Scenario 1**: You have a node that can access DockerHub to pull and save the images, and a separate node(s) that access your private registry to push the images.
+* **Scenario 2**: You have node(s) that can access both DockerHub and your private registry.
-#### Scenario 1: One host that can access DockerHub, separate host that can access private registry
+### Scenario 1: A Node that Can Access DockerHub, Separate Node(s) That Can Access the Private Registry
-1. Browse to the release page of your version (i.e. `https://github.com/rancher/rancher/releases/tag/v2.0.0`) and download `rancher-save-images.sh` and `rancher-load-images.sh`
+1. Browse to the release page of your version of Rancher (e.g. `https://github.com/rancher/rancher/releases/tag/v2.0.0`) and download `rancher-save-images.sh` and `rancher-load-images.sh`.
2. Transfer and run `rancher-save-images.sh` on the host the can access DockerHub. This will require at least 20GB of disk space.
@@ -34,65 +33,66 @@ We will cover two scenarios:
4. Transfer and run `rancher-load-images.sh` on the host that can access the private registry. It should be run in the same directory as `rancher-images.tar.gz`.
-5. Complete installation of Rancher using the instructions in [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/).
-
- >**Note:**
- > When completing [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/), prepend your private registry URL to the image when running the `docker run` command.
- >
- > Example:
- > ```
- docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- /rancher/rancher:latest
- ```
-
-#### Scenario 2: You have one host that can access both DockerHub and your private registry.
+### Scenario 2: You have node(s) that can access both DockerHub and your private registry.
-1. Browse to the release page of your version (i.e. `https://github.com/rancher/rancher/releases/tag/v2.0.0`) and download `rancher-images.txt`
+1. Browse to the release page of your version of Rancher (e.g. `https://github.com/rancher/rancher/releases/tag/v2.0.0`) and download `rancher-images.txt`.
2. Pull all the images present in `rancher-images.txt`, re-tag each image with the location of your registry, and push the image to the registry. This will require at least 20GB of disk space. See an example script below:
-
- ```
-#!/bin/sh
-IMAGES=`curl -s -L https://github.com/rancher/rancher/releases/download/v2.0.0/rancher-images.txt`
-for IMAGE in $IMAGES; do
- until docker inspect $IMAGE > /dev/null 2>&1; do
+ ```
+ #!/bin/sh
+ IMAGES=`curl -s -L https://github.com/rancher/rancher/releases/download/v2.0.0/rancher-images.txt`
+ for IMAGE in $IMAGES; do
+ until docker inspect $IMAGE > /dev/null 2>&1; do
docker pull $IMAGE
+ done
+ docker tag $IMAGE /$IMAGE
+ docker push /$IMAGE
done
- docker tag $IMAGE /$IMAGE
- docker push /$IMAGE
-done
- ```
+ ```
-3. Complete installation of Rancher using the instructions in [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/).
+## Completing the Rancher Installation
- >**Note:**
- > When completing [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/), prepend your private registry URL to the image when running the `docker run` command.
- >
- > Example:
- > ```
- docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- /rancher/rancher:latest
- ```
+After your private registry is setup on all node(s) for your Rancher installation, complete your Rancher installation.
+### Single Node Install
-### Configuring Rancher to use the private registry
+Complete installation of Rancher using the instructions in [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/).
+
+>**Note:**
+> When completing [Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/), prepend your private registry URL to the image when running the `docker run` command.
+>
+> Example:
+> ```
+> docker run -d --restart=unless-stopped \
+> -p 80:80 -p 443:443 \
+> /rancher/rancher:latest
+ ```
+
+## Configuring Rancher to Use the Private Registry
Rancher needs to be configured to use the private registry as source for the needed images.
-1. Go into the Settings view.
- 
+1. Go into the **Settings** view.
+
+ 
+
2. Look for the setting called `system-default-registry` and choose **Edit**.
- 
-3. Change the value to your registry, e.g. `registry.yourdomain.com:port`. Do not prefix the registry with `http://` or `https://`
- 
+
+ 
+
+3. Change the value to your registry (e.g. `registry.yourdomain.com:port`). Do not prefix the registry with `http://` or `https://`.
+
+ 
->**Note:** If you want to configure the setting when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`. Example:
-```
-#!/bin/sh
-docker run -d -p 80:80 -p 443:443 -e CATTLE_SYSTEM_DEFAULT_REGISTRY= /rancher/rancher:v2.0.0
+>**Note:** If you want to configure the setting when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`.
+>
+> Example:
+> ```
+docker run -d --restart=unless-stopped \
+ -p 80:80 -p 443:443 \
+ -e CATTLE_SYSTEM_DEFAULT_REGISTRY= \
+ /rancher/rancher:v2.0.0
```
diff --git a/content/rancher/v2.x/en/installation/api-auditing/_index.md b/content/rancher/v2.x/en/installation/api-auditing/_index.md
new file mode 100644
index 00000000000..60c95c05b44
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/api-auditing/_index.md
@@ -0,0 +1,575 @@
+---
+title: API Auditing
+weight: 10000
+---
+
+Rancher ships with API Auditing to record the sequence of system events initiated by individual users. You can know what happened, when it happened, who initiated it, and what cluster it affected. API auditing records all requests and responses to and from the Rancher API, which includes use of the Rancher UI and any other use of the Rancher API through programmatic use.
+
+You can enable API Auditing during Rancher installation or upgrade.
+
+## API Auditing Usage
+
+The usage below defines rules about what the audit log should record and what data it should include:
+
+
+Parameter | Description |
+---------|----------|
+ `AUDIT_LEVEL` | `0` - Disable audit log (default setting).
`1` - Log event metadata.
`2` - Log event metadata and request body.`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.
See [Audit Level Logging](#audit-level-logging) for a table that displays what each setting logs. |
+ `AUDIT_LOG_PATH` | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host.
Usage Example: `AUDIT_LOG_PATH=/my/custom/path/`
|
+ `AUDIT_LOG_MAXAGE` | Defined the maximum number of days to retain old audit log files. Default is 10 days. |
+ `AUDIT_LOG_MAXBACKUP` | Defines the maximum number of audit log files to retain. Default is 10.
+ `AUDIT_LOG_MAXSIZE` | Defines the maximum size in megabytes of the audit log file before it gets rotated. Default size is 100M.
+
+
+#### Audit Level Logging
+
+The following table displays what parts of API transactions are logged for each [`AUDIT_LEVEL`](#audit-level) setting.
+
+| `AUDIT_LEVEL` Setting | Request Header | Request Body | Response Header | Response Header |
+| --------------------- | ------------------ | ------------ | ------------------- | ------------------- |
+| `0` | | | | |
+| `1` | ✓ | | | |
+| `2` | ✓ | ✓ | | |
+| `3` | ✓ | ✓ | ✓ | ✓ |
+
+## Enabling API Auditing
+
+To enable API auditing, stop the Docker container that's running Rancher, and then restart it using the following command. This command includes parameters that turns on API auditing. For more information about usage for each switch related to API auditing, see [API Auditing Usage](#api-auditing-usage).
+
+
+```
+docker run -d --restart=unless-stopped \
+ -p 80:80 -p 443:443 \
+ -v /root/var/log/auditlog:/var/log/auditlog \
+ -e AUDIT_LEVEL=1 \
+ -e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
+ -e AUDIT_LOG_MAXAGE=20 \
+ -e AUDIT_LOG_MAXBACKUP=20 \
+ -e AUDIT_LOG_MAXSIZE=100 \
+ rancher/rancher:latest
+```
+
+## Viewing API Audit Logs
+
+By default, you can view your audit logs on any of your cluster nodes at `root/var/log/auditlog/rancher-api-audit.log` using your favorite text editor. For example:
+
+```
+less /var/log/auditlog/rancher-api-audit.log
+```
+
+If you changed the `AUDIT_LOG_PATH` parameter, look in that location for `rancher-api-audit.log` instead.
+
+## Audit Log Samples
+
+After you enable auditing, each API request or response is logged by Rancher in the form of JSON. Each of the following code samples provide examples of how to identify each API transaction.
+
+### Metadata Level
+
+If you set your `AUDIT_LEVEL` to `1`, Rancher logs the metadata header for every API request, but not the body. The header provides basic information about the API transaction, such as the transaction's ID, who initiated the transaction, the time it occurred, etc.
+
+```json
+{
+ "auditID": "30022177-9e2e-43d1-b0d0-06ef9d3db183",
+ "requestURI": "/v3/schemas",
+ "sourceIPs": [
+ "::1"
+ ],
+ "user": {
+ "name": "user-f4tt2",
+ "group": [
+ "system:authenticated"
+ ]
+ },
+ "verb": "GET",
+ "stage": "RequestReceived",
+ "stageTimestamp": "2018-07-20 10:22:43 +0800"
+}
+```
+
+### Metadata and Request Body Level
+
+If you set your `AUDIT_LEVEL` to `2`, Rancher logs the metadata header and body for every API request.
+
+
+The code sample below depicts an API request, with both its metadata header and body.
+
+```json
+{
+ "auditID": "ef1d249e-bfac-4fd0-a61f-cbdcad53b9bb",
+ "requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+ "sourceIPs": [
+ "::1"
+ ],
+ "user": {
+ "name": "user-f4tt2",
+ "group": [
+ "system:authenticated"
+ ]
+ },
+ "verb": "PUT",
+ "stage": "RequestReceived",
+ "stageTimestamp": "2018-07-20 10:28:08 +0800",
+ "requestBody": {
+ "hostIPC": false,
+ "hostNetwork": false,
+ "hostPID": false,
+ "paused": false,
+ "annotations": {},
+ "baseType": "workload",
+ "containers": [
+ {
+ "allowPrivilegeEscalation": false,
+ "image": "nginx",
+ "imagePullPolicy": "Always",
+ "initContainer": false,
+ "name": "nginx",
+ "ports": [
+ {
+ "containerPort": 80,
+ "dnsName": "nginx-nodeport",
+ "kind": "NodePort",
+ "name": "80tcp01",
+ "protocol": "TCP",
+ "sourcePort": 0,
+ "type": "/v3/project/schemas/containerPort"
+ }
+ ],
+ "privileged": false,
+ "readOnly": false,
+ "resources": {
+ "type": "/v3/project/schemas/resourceRequirements",
+ "requests": {},
+ "limits": {}
+ },
+ "restartCount": 0,
+ "runAsNonRoot": false,
+ "stdin": true,
+ "stdinOnce": false,
+ "terminationMessagePath": "/dev/termination-log",
+ "terminationMessagePolicy": "File",
+ "tty": true,
+ "type": "/v3/project/schemas/container",
+ "environmentFrom": [],
+ "capAdd": [],
+ "capDrop": [],
+ "livenessProbe": null,
+ "volumeMounts": []
+ }
+ ],
+ "created": "2018-07-18T07:34:16Z",
+ "createdTS": 1531899256000,
+ "creatorId": null,
+ "deploymentConfig": {
+ "maxSurge": 1,
+ "maxUnavailable": 0,
+ "minReadySeconds": 0,
+ "progressDeadlineSeconds": 600,
+ "revisionHistoryLimit": 10,
+ "strategy": "RollingUpdate"
+ },
+ "deploymentStatus": {
+ "availableReplicas": 1,
+ "conditions": [
+ {
+ "lastTransitionTime": "2018-07-18T07:34:38Z",
+ "lastTransitionTimeTS": 1531899278000,
+ "lastUpdateTime": "2018-07-18T07:34:38Z",
+ "lastUpdateTimeTS": 1531899278000,
+ "message": "Deployment has minimum availability.",
+ "reason": "MinimumReplicasAvailable",
+ "status": "True",
+ "type": "Available"
+ },
+ {
+ "lastTransitionTime": "2018-07-18T07:34:16Z",
+ "lastTransitionTimeTS": 1531899256000,
+ "lastUpdateTime": "2018-07-18T07:34:38Z",
+ "lastUpdateTimeTS": 1531899278000,
+ "message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
+ "reason": "NewReplicaSetAvailable",
+ "status": "True",
+ "type": "Progressing"
+ }
+ ],
+ "observedGeneration": 2,
+ "readyReplicas": 1,
+ "replicas": 1,
+ "type": "/v3/project/schemas/deploymentStatus",
+ "unavailableReplicas": 0,
+ "updatedReplicas": 1
+ },
+ "dnsPolicy": "ClusterFirst",
+ "id": "deployment:default:nginx",
+ "labels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "name": "nginx",
+ "namespaceId": "default",
+ "projectId": "c-bcz5t:p-fdr4s",
+ "publicEndpoints": [
+ {
+ "addresses": [
+ "10.64.3.58"
+ ],
+ "allNodes": true,
+ "ingressId": null,
+ "nodeId": null,
+ "podId": null,
+ "port": 30917,
+ "protocol": "TCP",
+ "serviceId": "default:nginx-nodeport",
+ "type": "publicEndpoint"
+ }
+ ],
+ "restartPolicy": "Always",
+ "scale": 1,
+ "schedulerName": "default-scheduler",
+ "selector": {
+ "matchLabels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "type": "/v3/project/schemas/labelSelector"
+ },
+ "state": "active",
+ "terminationGracePeriodSeconds": 30,
+ "transitioning": "no",
+ "transitioningMessage": "",
+ "type": "deployment",
+ "uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
+ "workloadAnnotations": {
+ "deployment.kubernetes.io/revision": "1",
+ "field.cattle.io/creatorId": "user-f4tt2"
+ },
+ "workloadLabels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "scheduling": {
+ "node": {}
+ },
+ "description": "my description",
+ "volumes": []
+ }
+}
+```
+### Metadata, Request Body, and Response Body Level
+
+If you set your `AUDIT_LEVEL` to `3`, Rancher logs:
+
+- The metadata header and body for every API request.
+- The metadata header and body for every API response.
+
+#### Request
+
+The code sample below depicts an API request, with both its metadata header and body.
+
+```json
+{
+ "auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
+ "requestURI": "/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+ "sourceIPs": [
+ "::1"
+ ],
+ "user": {
+ "name": "user-f4tt2",
+ "group": [
+ "system:authenticated"
+ ]
+ },
+ "verb": "PUT",
+ "stage": "RequestReceived",
+ "stageTimestamp": "2018-07-20 10:33:06 +0800",
+ "requestBody": {
+ "hostIPC": false,
+ "hostNetwork": false,
+ "hostPID": false,
+ "paused": false,
+ "annotations": {},
+ "baseType": "workload",
+ "containers": [
+ {
+ "allowPrivilegeEscalation": false,
+ "image": "nginx",
+ "imagePullPolicy": "Always",
+ "initContainer": false,
+ "name": "nginx",
+ "ports": [
+ {
+ "containerPort": 80,
+ "dnsName": "nginx-nodeport",
+ "kind": "NodePort",
+ "name": "80tcp01",
+ "protocol": "TCP",
+ "sourcePort": 0,
+ "type": "/v3/project/schemas/containerPort"
+ }
+ ],
+ "privileged": false,
+ "readOnly": false,
+ "resources": {
+ "type": "/v3/project/schemas/resourceRequirements",
+ "requests": {},
+ "limits": {}
+ },
+ "restartCount": 0,
+ "runAsNonRoot": false,
+ "stdin": true,
+ "stdinOnce": false,
+ "terminationMessagePath": "/dev/termination-log",
+ "terminationMessagePolicy": "File",
+ "tty": true,
+ "type": "/v3/project/schemas/container",
+ "environmentFrom": [],
+ "capAdd": [],
+ "capDrop": [],
+ "livenessProbe": null,
+ "volumeMounts": []
+ }
+ ],
+ "created": "2018-07-18T07:34:16Z",
+ "createdTS": 1531899256000,
+ "creatorId": null,
+ "deploymentConfig": {
+ "maxSurge": 1,
+ "maxUnavailable": 0,
+ "minReadySeconds": 0,
+ "progressDeadlineSeconds": 600,
+ "revisionHistoryLimit": 10,
+ "strategy": "RollingUpdate"
+ },
+ "deploymentStatus": {
+ "availableReplicas": 1,
+ "conditions": [
+ {
+ "lastTransitionTime": "2018-07-18T07:34:38Z",
+ "lastTransitionTimeTS": 1531899278000,
+ "lastUpdateTime": "2018-07-18T07:34:38Z",
+ "lastUpdateTimeTS": 1531899278000,
+ "message": "Deployment has minimum availability.",
+ "reason": "MinimumReplicasAvailable",
+ "status": "True",
+ "type": "Available"
+ },
+ {
+ "lastTransitionTime": "2018-07-18T07:34:16Z",
+ "lastTransitionTimeTS": 1531899256000,
+ "lastUpdateTime": "2018-07-18T07:34:38Z",
+ "lastUpdateTimeTS": 1531899278000,
+ "message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
+ "reason": "NewReplicaSetAvailable",
+ "status": "True",
+ "type": "Progressing"
+ }
+ ],
+ "observedGeneration": 2,
+ "readyReplicas": 1,
+ "replicas": 1,
+ "type": "/v3/project/schemas/deploymentStatus",
+ "unavailableReplicas": 0,
+ "updatedReplicas": 1
+ },
+ "dnsPolicy": "ClusterFirst",
+ "id": "deployment:default:nginx",
+ "labels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "name": "nginx",
+ "namespaceId": "default",
+ "projectId": "c-bcz5t:p-fdr4s",
+ "publicEndpoints": [
+ {
+ "addresses": [
+ "10.64.3.58"
+ ],
+ "allNodes": true,
+ "ingressId": null,
+ "nodeId": null,
+ "podId": null,
+ "port": 30917,
+ "protocol": "TCP",
+ "serviceId": "default:nginx-nodeport",
+ "type": "publicEndpoint"
+ }
+ ],
+ "restartPolicy": "Always",
+ "scale": 1,
+ "schedulerName": "default-scheduler",
+ "selector": {
+ "matchLabels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "type": "/v3/project/schemas/labelSelector"
+ },
+ "state": "active",
+ "terminationGracePeriodSeconds": 30,
+ "transitioning": "no",
+ "transitioningMessage": "",
+ "type": "deployment",
+ "uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
+ "workloadAnnotations": {
+ "deployment.kubernetes.io/revision": "1",
+ "field.cattle.io/creatorId": "user-f4tt2"
+ },
+ "workloadLabels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "scheduling": {
+ "node": {}
+ },
+ "description": "my decript",
+ "volumes": []
+ }
+}
+```
+
+#### Response
+
+The code sample below depicts an API response, with both its metadata header and body.
+
+
+```json
+{
+ "auditID": "a886fd9f-5d6b-4ae3-9a10-5bff8f3d68af",
+ "responseStatus": "200",
+ "stage": "ResponseComplete",
+ "stageTimestamp": "2018-07-20 10:33:06 +0800",
+ "responseBody": {
+ "actionLinks": {
+ "pause": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=pause",
+ "resume": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=resume",
+ "rollback": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx?action=rollback"
+ },
+ "annotations": {},
+ "baseType": "workload",
+ "containers": [
+ {
+ "allowPrivilegeEscalation": false,
+ "image": "nginx",
+ "imagePullPolicy": "Always",
+ "initContainer": false,
+ "name": "nginx",
+ "ports": [
+ {
+ "containerPort": 80,
+ "dnsName": "nginx-nodeport",
+ "kind": "NodePort",
+ "name": "80tcp01",
+ "protocol": "TCP",
+ "sourcePort": 0,
+ "type": "/v3/project/schemas/containerPort"
+ }
+ ],
+ "privileged": false,
+ "readOnly": false,
+ "resources": {
+ "type": "/v3/project/schemas/resourceRequirements"
+ },
+ "restartCount": 0,
+ "runAsNonRoot": false,
+ "stdin": true,
+ "stdinOnce": false,
+ "terminationMessagePath": "/dev/termination-log",
+ "terminationMessagePolicy": "File",
+ "tty": true,
+ "type": "/v3/project/schemas/container"
+ }
+ ],
+ "created": "2018-07-18T07:34:16Z",
+ "createdTS": 1531899256000,
+ "creatorId": null,
+ "deploymentConfig": {
+ "maxSurge": 1,
+ "maxUnavailable": 0,
+ "minReadySeconds": 0,
+ "progressDeadlineSeconds": 600,
+ "revisionHistoryLimit": 10,
+ "strategy": "RollingUpdate"
+ },
+ "deploymentStatus": {
+ "availableReplicas": 1,
+ "conditions": [
+ {
+ "lastTransitionTime": "2018-07-18T07:34:38Z",
+ "lastTransitionTimeTS": 1531899278000,
+ "lastUpdateTime": "2018-07-18T07:34:38Z",
+ "lastUpdateTimeTS": 1531899278000,
+ "message": "Deployment has minimum availability.",
+ "reason": "MinimumReplicasAvailable",
+ "status": "True",
+ "type": "Available"
+ },
+ {
+ "lastTransitionTime": "2018-07-18T07:34:16Z",
+ "lastTransitionTimeTS": 1531899256000,
+ "lastUpdateTime": "2018-07-18T07:34:38Z",
+ "lastUpdateTimeTS": 1531899278000,
+ "message": "ReplicaSet \"nginx-64d85666f9\" has successfully progressed.",
+ "reason": "NewReplicaSetAvailable",
+ "status": "True",
+ "type": "Progressing"
+ }
+ ],
+ "observedGeneration": 2,
+ "readyReplicas": 1,
+ "replicas": 1,
+ "type": "/v3/project/schemas/deploymentStatus",
+ "unavailableReplicas": 0,
+ "updatedReplicas": 1
+ },
+ "dnsPolicy": "ClusterFirst",
+ "hostIPC": false,
+ "hostNetwork": false,
+ "hostPID": false,
+ "id": "deployment:default:nginx",
+ "labels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "links": {
+ "remove": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+ "revisions": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/revisions",
+ "self": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+ "update": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx",
+ "yaml": "https://localhost:8443/v3/project/c-bcz5t:p-fdr4s/workloads/deployment:default:nginx/yaml"
+ },
+ "name": "nginx",
+ "namespaceId": "default",
+ "paused": false,
+ "projectId": "c-bcz5t:p-fdr4s",
+ "publicEndpoints": [
+ {
+ "addresses": [
+ "10.64.3.58"
+ ],
+ "allNodes": true,
+ "ingressId": null,
+ "nodeId": null,
+ "podId": null,
+ "port": 30917,
+ "protocol": "TCP",
+ "serviceId": "default:nginx-nodeport"
+ }
+ ],
+ "restartPolicy": "Always",
+ "scale": 1,
+ "schedulerName": "default-scheduler",
+ "selector": {
+ "matchLabels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ },
+ "type": "/v3/project/schemas/labelSelector"
+ },
+ "state": "active",
+ "terminationGracePeriodSeconds": 30,
+ "transitioning": "no",
+ "transitioningMessage": "",
+ "type": "deployment",
+ "uuid": "f998037d-8a5c-11e8-a4cf-0245a7ebb0fd",
+ "workloadAnnotations": {
+ "deployment.kubernetes.io/revision": "1",
+ "field.cattle.io/creatorId": "user-f4tt2"
+ },
+ "workloadLabels": {
+ "workload.user.cattle.io/workloadselector": "deployment-default-nginx"
+ }
+ }
+}
+```
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/installation/custom-ca-root-certificate/_index.md b/content/rancher/v2.x/en/installation/custom-ca-root-certificate/_index.md
deleted file mode 100644
index 423c087784d..00000000000
--- a/content/rancher/v2.x/en/installation/custom-ca-root-certificate/_index.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Adding custom CA root certificates
-weight: 365
----
-Services that Rancher needs to access are sometimes configured with a certificate from an custom/internal Certificate Authority (CA) root, also known as self signed certificate. If the presented certificate from the service cannot be validated by Rancher, the following error will appear: `x509: certificate signed by unknown authority`.
-
-To validate the certificate, the CA root certificates need to be added to Rancher. As Rancher is written in Go, we can use the environment variable `SSL_CERT_DIR` to point to the directory where the CA root certificates are located in the container. The CA root certificates directory can be mounted using the Docker volume option (`-v host-source-directory:container-destination-directory`) when starting the Rancher container.
-
-Examples of services that Rancher can access:
-
-* Catalogs
-* Authentication providers
-* Accessing hosting/cloud API when using Node Drivers
-
-## Start Rancher Container with custom CA root certificates
-
-The requirements are:
-
-* Mount the host directory containing the CA root certificates in the container using the volume option.
-* Add the environment variable `SSL_CERT_DIR` with as value 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
-```
diff --git a/content/rancher/v2.x/en/installation/ha-server-install2/_index.md b/content/rancher/v2.x/en/installation/ha-server-install2/_index.md
deleted file mode 100644
index c936195f38a..00000000000
--- a/content/rancher/v2.x/en/installation/ha-server-install2/_index.md
+++ /dev/null
@@ -1,458 +0,0 @@
----
-title: High Availability Installation 2
-weight: 275
-draft: true
----
-This set of instructions creates a new Kubernetes cluster that's dedicated to running Rancher in a high-availability (HA) configuration. This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
-
-- Layer 4 load balancer (TCP)
-- NGINX ingress controller with SSL termination (HTTPS)
-
-
-
-## Installation Outline
-
-Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.
-
-1. [Provision Linux Hosts](#1-provision-linux-hosts)
-
- Provision three Linux hosts to serve as your Kubernetes cluster.
-
-2. [Configure Load Balancer](#2-configure-load-balancer)
-
- Configure your load balancer to have a highly available single point of entry to your Rancher cluster.
-
-3. [Configure DNS](#3-configure-dns)
-
- Make your setup accessible using a DNS name by configuring the DNS to point to your loadbalancer.
-
-4. [Download RKE](#4-download-rke)
-
- [RKE](https://github.com/rancher/rke/releases) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts.
-
-5. [Download RKE Config File Template](#5-download-rke-config-file-template)
-
- RKE uses a YAML config file to install and configure your Kubernetes cluster. Download one of our RKE config file templates to get started.
-
-6. [Configure Nodes](#6-configure-nodes)
-
- Configure the **Nodes** section of the RKE config template.
-
-7. [Configure Certificates](#7-configure-certificates)
-
- Configure the **Certificates** part of the template too.
-
-8. [Configure FQDN](#8-configure-fqdn)
-
- And the **FQDN** part.
-
-9. [Back Up Your RKE Config File](#9-back-up-your-rke-config-file)
-
- After you've completed configuration of the RKE config file: 1. it's no longer a template since you'll be using it, and 2. you should back up the RKE config file to a safe place. You will reuse this file for upgrades later.
-
-10. [Run RKE](#10-run-rke)
-
- Run RKE to deploy Rancher to your cluster.
-
-11. [Back Up Auto-Generated Config File](#11-back-up-auto-generated-config-file)
-
- During installation, RKE generates a config file that you'll use later for upgrades. Back it up to a safe location.
-
-12. **For those using a certificate signed by a recognized CA:**
-
- [Remove Default Certificates](#12-remove-default-certificates)
-
- If you chose [Option B](#option-b-bring-your-own-certificate-signed-by-recognized-ca) as your SSL option, log into the Rancher UI and remove the certificates that Rancher automatically generates.
-
-
-
-## 1. Provision Linux Hosts
-
-Before you install Rancher, confirm you meet the host requirements. Provision 3 new Linux hosts using the requirements below.
-
-### Host Requirements
-
-#### Operating System
-
-{{< requirements_os >}}
-
-#### Hardware
-
-{{< requirements_hardware >}}
-
-#### Software
-
-{{< requirements_software >}}
-
-{{< note_server-tags >}}
-
-#### Ports
-
-The following diagram depicts the basic port requirements for Rancher. For a comprehensive list, see [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/).
-
-
-
-## 2. Configure Load Balancer
-
-We will be using NGINX as our Layer 4 Load Balancer (TCP). NGINX will forward all connections to one of your Rancher nodes. If you want to use Amazon NLB, you can skip this step and use [Amazon NLB configuration]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/nlb/)
-
->**Note:**
-> In this configuration, the load balancer is positioned in front of your Linux hosts. The load balancer can be any host that you have available that's capable of running NGINX.
->
->One caveat: do not use one of your Rancher nodes as the load balancer.
-
-### A. Install NGINX
-
-Start by installing NGINX on your load balancer host. NGINX has packages available for all known operating systems.
-
-For help installing NGINX, refer to their [install documentation](https://www.nginx.com/resources/wiki/start/topics/tutorials/install/).
-
-### B. Create NGINX Configuration
-
-After installing NGINX, you need to update the NGINX config file, `nginx.conf`, with the IP addresses for your nodes.
-
-1. Copy and paste the code sample below into your favorite text editor. Save it as `nginx.conf`.
-
-2. From `nginx.conf`, replace `IP_NODE_1`, `IP_NODE_2`, and `IP_NODE_3` with the IPs of your [Linux hosts](#1-provision-linux-hosts).
-
- **Example NGINX config:**
- ```
- worker_processes 4;
- worker_rlimit_nofile 40000;
-
- events {
- worker_connections 8192;
- }
-
- http {
- server {
- listen 80;
- return 301 https://$host$request_uri;
- }
- }
-
- stream {
- upstream rancher_servers {
- least_conn;
- server IP_NODE_1:443 max_fails=3 fail_timeout=5s;
- server IP_NODE_2:443 max_fails=3 fail_timeout=5s;
- server IP_NODE_3:443 max_fails=3 fail_timeout=5s;
- }
- server {
- listen 443;
- proxy_pass rancher_servers;
- }
- }
- ```
-
-3. Save `nginx.conf` to your load balancer at the following path: `/etc/nginx/nginx.conf`.
-
-4. Load the updates to your NGINX configuration by running the following command:
-
- ```
- # nginx -s reload
- ```
-
-### Option - Run NGINX as Docker container
-
-Instead of installing NGINX as a package on the operating system, you can rather run it as a Docker container. Save the edited **Example NGINX config** as `/etc/nginx.conf` and run the following command to launch the NGINX container:
-
-```
-docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- -v /etc/nginx.conf:/etc/nginx/nginx.conf \
- nginx:1.14
-```
-
-## 3. Configure DNS
-
-Choose a fully qualified domain name (FQDN) that you want to use to access Rancher (e.g., `rancher.yourdomain.com`).
-
-1. Log into your DNS server a create a `DNS A` record that points to the IP address of your [load balancer](#2-configure-load-balancer).
-
-2. Validate that the `DNS A` is working correctly. Run the following command from any terminal, replacing `HOSTNAME.DOMAIN.COM` with your chosen FQDN:
-
- `nslookup HOSTNAME.DOMAIN.COM`
-
- **Step Result:** Terminal displays output similar to the following:
-
- ```
- $ nslookup rancher.yourdomain.com
- Server: YOUR_HOSTNAME_IP_ADDRESS
- Address: YOUR_HOSTNAME_IP_ADDRESS#53
-
- Non-authoritative answer:
- Name: rancher.yourdomain.com
- Address: HOSTNAME.DOMAIN.COM
- ```
-
-
-
-## 4. Download RKE
-
-RKE is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. We will be using RKE to setup our cluster and run Rancher.
-
-1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:
-
- - **MacOS**: `rke_darwin-amd64`
- - **Linux**: `rke_linux-amd64`
- - **Windows**: `rke_windows-amd64.exe`
-
-2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run one of the commands below.
-
- >**Using Windows?**
- >The file is already an executable. Skip to [Download RKE Config File Template](#5-download-rke-config-file-template).
-
- ```
- # MacOS
- $ chmod +x rke_darwin-amd64
- # Linux
- $ chmod +x rke_linux-amd64
- ```
-
-3. Confirm that RKE is now executable by running the following command:
-
- ```
- # MacOS
- $ ./rke_darwin-amd64 --version
- # Linux
- $ ./rke_linux-amd64 --version
- ```
-
- **Step Result:** You receive output similar to what follows:
- ```
- rke version v
- ```
-
-## 5. Download RKE Config File Template
-
-RKE uses a `.yml` config file to install and configure your Kubernetes cluster. There are 2 templates to choose from, depending on the SSL certificate you want to use.
-
-1. Download one of following templates, depending on the SSL certificate you're using.
-
- - [Template for self-signed certificate
`3-node-certificate.yml`](https://raw.githubusercontent.com/rancher/rancher/e9d29b3f3b9673421961c68adf0516807d1317eb/rke-templates/3-node-certificate.yml)
- - [Template for certificate signed by recognized CA
`3-node-certificate-recognizedca.yml`](https://raw.githubusercontent.com/rancher/rancher/e9d29b3f3b9673421961c68adf0516807d1317eb/rke-templates/3-node-certificate-recognizedca.yml)
-
-2. Rename the file to `rancher-cluster.yml`.
-
-## 6. Configure Nodes
-
-Once you have the `rancher-cluster.yml` config file template, edit the nodes section to point toward your Linux hosts.
-
-1. Open `rancher-cluster.yml` in your favorite text editor.
-
-2. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
-
- For each node in your cluster, update the following placeholders: `IP_ADDRESS_X` and `USER`.
-
-```
-nodes:
- - address: IP_ADDRESS_1
- # THE IP ADDRESS OR HOSTNAME OF THE NODE
- user: USER
- # USER WITH ADMIN ACCESS. USUALLY `root`
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
- # PATH TO SSH KEY THAT AUTHENTICATES ON YOUR WORKSTATION
- # USUALLY THE VALUE ABOVE
- - address: IP_ADDRESS_2
- user: USER
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
- - address: IP_ADDRESS_3
- user: USER
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
-```
-
-## 7. Configure Certificates
-
-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.
-
-Choose from the following options:
-
-- [Option A—Bring Your Own Certificate: Self-Signed](#option-a-bring-your-own-certificate-self-signed)
-- [Option B—Bring Your Own Certificate: Signed by Recognized CA](#option-b-bring-your-own-certificate-signed-by-recognized-ca)
-
-### Option A—Bring Your Own Certificate: Self-Signed
-
->**Prerequisites:**
->Create a self-signed certificate.
->
->- The certificate files must be in [PEM format](#pem).
->- The certificate files must be encoded in [base64](#base64).
->- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [Intermediate Certificates](#cert-order).
-
-1. In `kind: Secret` with `name: cattle-keys-ingress`:
-
- * Replace `` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
- * Replace `` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
-
- >**Note:**
- > The base64 encoded string should be on the same line as `tls.crt` or `tls.key`, without any newline at the beginning, in between or at the end.
-
- **Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
-
-```yaml
----
- apiVersion: v1
- kind: Secret
- metadata:
- name: cattle-keys-ingress
- namespace: cattle-system
- type: Opaque
- data:
- tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
- tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
-```
-
-2. In `kind: Secret` with `name: cattle-keys-server`, replace `` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`).
-
- >**Note:**
- > The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
-
-
- **Result:** The file should look like the example below (the base64 encoded string should be different):
- ```yaml
- ---
- apiVersion: v1
- kind: Secret
- metadata:
- name: cattle-keys-server
- namespace: cattle-system
- type: Opaque
- data:
- cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
- ```
-
-### Option B—Bring Your Own Certificate: Signed by Recognized CA
-
->**Note:**
-> If you are using Self Signed Certificate, [click here](#option-a-bring-your-own-certificate-self-signed) to proceed.
-
-If you are using a Certificate Signed By A Recognized Certificate Authority, you will need to generate a base64 encoded string for the Certificate file and the Certificate Key file. Make sure that your certificate file includes all the [intermediate certificates](#cert-order) in the chain, the order of certificates in this case is first your own certificate, followed by the intermediates. Please refer to the documentation of your CSP (Certificate Service Provider) to see what intermediate certificate(s) need to be included.
-
-In the `kind: Secret` with `name: cattle-keys-ingress`:
-
-* Replace `` with the base64 encoded string of the Certificate file (usually called `cert.pem` or `domain.crt`)
-* Replace `` with the base64 encoded string of the Certificate Key file (usually called `key.pem` or `domain.key`)
-
-After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
-
->**Note:**
-> The base64 encoded string should be on the same line as `tls.crt` or `tls.key`, without any newline at the beginning, in between or at the end.
-
-```yaml
----
-apiVersion: v1
-kind: Secret
-metadata:
- name: cattle-keys-ingress
- namespace: cattle-system
-type: Opaque
-data:
- tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
- tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
-```
-
-## 8. Configure FQDN
-
-There are two references to `` in the config file (one in this step and one in the next). Both need to be replaced with the FQDN chosen in [Configure DNS](#3-configure-dns).
-
-In the `kind: Ingress` with `name: cattle-ingress-http`:
-
-* Replace `` with the FQDN chosen in [Configure DNS](#3-configure-dns).
-
-After replacing `` with the FQDN chosen in [Configure DNS](#3-configure-dns), the file should look like the example below (`rancher.yourdomain.com` is the FQDN used in this example):
-
-```yaml
- ---
- apiVersion: extensions/v1beta1
- kind: Ingress
- metadata:
- namespace: cattle-system
- name: cattle-ingress-http
- annotations:
- nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
- nginx.ingress.kubernetes.io/proxy-read-timeout: "1800" # Max time in seconds for ws to remain shell window open
- nginx.ingress.kubernetes.io/proxy-send-timeout: "1800" # Max time in seconds for ws to remain shell window open
- spec:
- rules:
- - host: rancher.yourdomain.com
- http:
- paths:
- - backend:
- serviceName: cattle-service
- servicePort: 80
- tls:
- - secretName: cattle-keys-ingress
- hosts:
- - rancher.yourdomain.com
-```
-
-Save the `.yml` file and close it.
-
-## 9. Back Up Your RKE Config File
-
-After you close your `.yml` file, back it up to a secure location. You can use this file again when it's time to upgrade Rancher.
-
-## 10. Run RKE
-
-With all configuration in place, use RKE to launch Rancher. You can complete this action by running the `rke up` command and using the `--config` parameter to point toward your config file.
-
-1. From your workstation, make sure `rancher-cluster.yml` and the downloaded `rke` binary are in the same directory.
-
-2. Open a Terminal instance. Change to the directory that contains your config file and `rke`.
-
-3. Enter one of the `rke up` commands listen below.
-
-```
-# MacOS
-./rke_darwin-amd64 up --config rancher-cluster.yml
-# Linux
-./rke_linux-amd64 up --config rancher-cluster.yml
-```
-
-**Step Result:** The output should be similar to the snippet below:
-
-```
-INFO[0000] Building Kubernetes cluster
-INFO[0000] [dialer] Setup tunnel for host [1.1.1.1]
-INFO[0000] [network] Deploying port listener containers
-INFO[0000] [network] Pulling image [alpine:latest] on host [1.1.1.1]
-...
-INFO[0101] Finished building Kubernetes cluster successfully
-```
-
-## 11. Back Up Auto-Generated Config File
-
-During installation, RKE automatically generates a config file named `kube_config_rancher-cluster.yml` in the same directory as the RKE binary. Copy this file and back it up to a safe location. You'll use this file later when upgrading Rancher Server.
-
-## 12. Remove Default Certificates
-
-**For those using a certificate signed by a recognized CA:**
-
->**Note:** If you're using a self-signed certificate, you don't have to complete this procedure. Continue to [What's Next?](#what-s-next)
-
-By default, Rancher automatically generates self-signed certificates for itself after installation. However, since you've provided your own certificates, you must disable the certificates that Rancher generated for itself.
-
-**To Remove the Default Certificates:**
-
-1. Log into Rancher.
-
-2. Select **Settings** > **cacerts**.
-
-3. Choose `Edit` and remove the contents. Then click `Save`.
-
-## What's Next?
-
-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 Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
-
-
-
-## FAQ and Troubleshooting
-
-{{< ssl_faq_ha >}}
diff --git a/content/rancher/v2.x/en/installation/ha/_index.md b/content/rancher/v2.x/en/installation/ha/_index.md
new file mode 100644
index 00000000000..7ad2b6b25a3
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/_index.md
@@ -0,0 +1,40 @@
+---
+title: High Availability (HA) Install
+weight: 275
+---
+
+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.
+
+This procedure walks you through setting up a 3-node cluster with RKE and installing the Rancher chart with the Helm package manager.
+
+> **Note:** For the best performance, we recommend this Kubernetes cluster be dedicated only to the Rancher workload.
+
+## Recommended Architecture
+
+* DNS for Rancher should resolve to a layer 4 load balancer
+* The Load Balancer should forward ports 80 and 443 TCP to all 3 nodes in the Kubernetes cluster.
+* The Ingress controller will redirect http port 80 to https and terminate SSL/TLS on port 443.
+* The Ingress controller will forward traffic to port 80 on the pod in the Rancher deployment.
+
+HA Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers
+
+
+## Required Tools
+
+The following CLI tools are required for this install. Please make sure these tools are installed and available in your `$PATH`
+
+* [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl) - Kubernetes command-line tool.
+* [rke]({{< baseurl >}}/rke/v0.1.x/en/installation/) - Rancher Kubernetes Engine, cli for building Kubernetes clusters.
+* [helm](https://docs.helm.sh/using_helm/#installing-helm) - Package management for Kubernetes.
+
+## Installation Outline
+
+1. [Create Nodes and Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/)
+1. [Install Kubernetes with RKE]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/)
+1. [Initialize Helm (tiller)]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/)
+1. [Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/)
+
+## Additional Install Options
+
+* [Migrating from RKE add-on install]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/migrating-from-rke-add-on/)
+* [RKE add-on install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/rke-add-on/)
diff --git a/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
new file mode 100644
index 00000000000..bec3e28dd4c
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/_index.md
@@ -0,0 +1,28 @@
+---
+title: 1 - Create Nodes and Load Balancer
+weight: 185
+---
+
+Use your provider of choice to provision 3 nodes and a Load Balancer endpoint for your RKE install.
+
+> **Note:** These nodes must be in the same region/datacenter. You may place these servers in separate availability zones.
+
+**Don't forget to collect the SSH credentials and DNS or IP addresses of your nodes to provide to RKE in the next step.**
+
+### Host Requirements
+
+View the requirements for nodes hosting Rancher at [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
+
+### Load Balancer
+
+RKE will configure an ingress-controller pod, on each of your nodes. The ingress-controller pods are bound to ports 80 and 443 TCP on the host network and are the entry point for HTTPS traffic to the Rancher server.
+
+Configure a load balancer as a basic Layer 4 TCP forwarder. The exact configuration will vary depending on your environment.
+
+#### Examples
+
+* [Amazon NLB]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/nlb/)
+
+
+
+### [Next: Install Kubernetes with RKE]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/)
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/installation/ha-server-install/nlb/_index.md b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nlb/_index.md
similarity index 99%
rename from content/rancher/v2.x/en/installation/ha-server-install/nlb/_index.md
rename to content/rancher/v2.x/en/installation/ha/create-nodes-lb/nlb/_index.md
index 1bef7366ae0..ac7a95e5462 100644
--- a/content/rancher/v2.x/en/installation/ha-server-install/nlb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/create-nodes-lb/nlb/_index.md
@@ -1,5 +1,5 @@
---
-title: Amazon NLB configuration
+title: Amazon NLB
weight: 277
---
## Objectives
diff --git a/content/rancher/v2.x/en/installation/ha/helm-init/_index.md b/content/rancher/v2.x/en/installation/ha/helm-init/_index.md
new file mode 100644
index 00000000000..245775e475c
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/helm-init/_index.md
@@ -0,0 +1,33 @@
+---
+title: 3 - Initialize Helm (Install tiller)
+weight: 195
+---
+
+Helm is the package management tool of choice for Kubernetes. Helm "charts" provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh/).
+
+### Initialize Helm on the cluster
+
+Helm installs the `tiller` service on your cluster to manage charts. Since RKE enables RBAC by default we will need to use `kubectl` to create a `serviceaccount` and `clusterrolebinding` so `tiller` has permission to deploy to the cluster.
+
+* Create the `ServiceAccount` in the `kube-system` namespace.
+* Create the `ClusterRoleBinding` to give the `tiller` account access to the cluster.
+* Finally use `helm` to initialize the `tiller` service
+
+```
+kubectl -n kube-system create serviceaccount tiller
+kubectl create clusterrolebinding tiller \
+ --clusterrole cluster-admin \
+ --serviceaccount=kube-system:tiller
+```
+
+##### Helm init
+
+`helm init` installs the `tiller` service in the `kube-system` namespace on your cluster.
+
+```
+helm init --service-account tiller
+```
+
+> NOTE: This `tiller` install has full cluster access, which should be acceptable if the cluster is dedicated to Rancher server. Check out the [helm docs](https://docs.helm.sh/using_helm/#role-based-access-control) for restricting `tiller` access to suit your security requirements.
+
+### [Next: Install Rancher]({{< baseurl >}}/rancher/v2.x/en/installation/ha//helm-rancher/)
\ No newline at end of file
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
new file mode 100644
index 00000000000..72d5643838f
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/_index.md
@@ -0,0 +1,110 @@
+---
+title: 4 - Install Rancher
+weight: 200
+---
+
+Rancher installation is now managed using the Helm package manager for Kubernetes. Use `helm` to install the prerequisite and Rancher charts.
+
+### Add the Chart Repo
+
+Use `helm repo add` to add the Rancher chart repository.
+
+```
+helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+```
+
+For additional chart details, view the [source of these Rancher server charts](https://github.com/rancher/server-chart).
+
+### Install cert-manager
+
+> **Note:** cert-manager is only required for Rancher generated and LetsEncrypt issued certificates. You may skip this step if you are bringing your own certificates and using the `ingress.tls.source=secret` option.
+
+Rancher relies on [cert-manager](https://github.com/kubernetes/charts/tree/master/stable/cert-manager) from the Kubernetes Helm "stable" catalog to issue self-signed or LetsEncrypt certificates.
+
+Install `cert-manager` from the Helm stable catalog.
+
+```
+helm install stable/cert-manager \
+ --name cert-manager \
+ --namespace kube-system
+```
+
+### Choose your SSL Configuration
+
+Rancher server is designed to be "secure by default" and requires SSL/TLS configuration.
+
+There are three options for the source of the certificate.
+
+* `rancher` - (Default) Use Rancher generated CA/Certificates.
+* `letsEncrypt` - Use [LetsEncrypt](https://letsencrypt.org/) to issue a cert.
+* `secret` - Configure a Kubernetes Secret with your certificate files.
+
+
+
+#### (Default) Rancher Generated Certificates
+
+The default is for Rancher to generate a CA and use the `cert-manager` to issue the certificate for access to the Rancher server interface.
+
+The only requirement is to set the `hostname` to the DNS name you pointed at your Load Balancer.
+
+```
+helm install rancher-stable/rancher \
+ --name rancher \
+ --namespace cattle-system \
+ --set hostname=rancher.my.org
+```
+
+#### LetsEncrypt
+
+Use [LetsEncrypt](https://letsencrypt.org/)'s free service to issue trusted SSL certs. This configuration uses http validation so the Load Balancer must have a Public DNS record and be accessible from the internet.
+
+Set `hostname`, `ingress.tls.source=letEncrypt` and LetsEncrypt options.
+
+```
+helm install rancher-stable/rancher \
+ --name rancher \
+ --namespace cattle-system \
+ --set hostname=rancher.my.org \
+ --set ingress.tls.source=letsEncrypt \
+ --set letsEncrypt.email=me@example.org
+```
+
+#### Certificates from Files (Kubernetes Secret)
+
+Create Kubernetes Secrets from your own certificates for Rancher to use.
+
+> 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.
+
+Set `hostname` and `ingress.tls.source=secret`
+
+> NOTE: If you are using a Private CA signed cert, add `--set privateCA=true`
+
+```
+helm install rancher-stable/rancher \
+ --name rancher \
+ --namespace cattle-system \
+ --set hostname=rancher.my.org \
+ --set ingress.tls.source=secret
+```
+
+Now that Rancher is running, 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.
+
+### Advanced Configurations
+
+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)
+* [TLS Termination on an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/ha/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.
+
+### Save your options
+
+Make sure you save the `--set` options you used. You will need to use the same options when you upgrade Rancher to new versions with Helm.
+
+### Finishing Up
+
+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
diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/_index.md
new file mode 100644
index 00000000000..f31c8c02a6c
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/chart-options/_index.md
@@ -0,0 +1,92 @@
+---
+title: Chart Options
+weight: 276
+---
+
+### Common Options
+
+| Option | Default Value | Description |
+| --- | --- | --- |
+| `hostname` | " " | `string` - the Fully Qualified Domain Name for your Rancher Server |
+| `ingress.tls.source` | "rancher" | `string` - Where to get the cert for the ingress. - "rancher, letsEncrypt, secret" |
+| `letsEncrypt.email` | " " | `string` - Your email address |
+| `letsEncrypt.environment` | "production" | `string` - Valid options: "staging, production" |
+| `privateCA` | false | `bool` - Set to true if your cert is signed by a private CA |
+
+
+
+### Advanced Options
+
+| Option | Default Value | Description |
+| --- | --- | --- |
+| `debug` | false | `bool` - set debug flag on rancher server |
+| `imagePullSecrets` | [] | `list` - list of names of Secret resource containing private registry credentials |
+| `proxy` | "" | `string` - string - HTTP[S] proxy server for Rancher |
+| `noProxy` | "localhost,127.0.0.1" | `string` - comma seperated list of hostnames or ip address not to use the proxy |
+| `resources` | {} | `map` - rancher pod resource requests & limits |
+| `rancherImage` | "rancher/rancher" | `string` - rancher image source |
+| `rancherImageTag` | same as chart version | `string` - rancher/rancher image tag |
+| `tls` | "ingress" | `string` - Where to terminate SSL. - "ingress, external"
+
+
+
+### HTTP Proxy
+
+Rancher requires internet access for some functionality (helm charts). Use `proxy` to set your proxy server.
+
+Add your IP exceptions to the `noProxy` list. Make sure you add the Service cluster IP range (default: 10.43.0.1/16) and any worker cluster `controlplane` nodes. Rancher supports CIDR notation ranges in this list.
+
+```
+--set proxy="http://:@:/"
+--set noProxy="127.0.0.1,localhost,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
+```
+
+### Private Registry
+
+You can point to a private registry for the rancher image.
+
+#### Images
+
+Populate your private registry with Rancher images.
+
+You can get the list of images required for rancher and worker cluster installs from the [Releases](https://github.com/rancher/rancher/releases/latest) page.
+
+#### Create Registry Secret
+
+Use `kubectl` to create a docker-registry secret in the `cattle-system` namespace.
+
+```
+kubectl -n cattle-system create secret docker-registry regcred \
+ --docker-server="reg.example.com:5000" \
+ --docker-email=
+```
+
+#### Registry Options
+
+Add the `rancherImage` to point to your private registry image and `imagePullSecrets` to your install command.
+
+```
+--set rancherImage=reg.example.com:5000/rancher/rancher \
+--set imagePullSecrets[0].name=regcred
+```
+
+### External TLS Termination
+
+If you wish to terminate the SSL/TLS on a load-balancer external to the Rancher cluster (ingress), use the `--tls=external` option and point your load balancer at port http 80 on all of the rancher cluster nodes.
+
+> NOTE: If you are using a Private CA signed cert, add `--set privateCA=true` and see [Adding TLS Secrets - Private CA Signed - Additional Steps]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/#private-ca-signed---additional-steps) 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.
+
+> NOTE: The `tls=external` option will expose the Rancher interface on http port 80. Clients that are allowed to connect directly to the Rancher cluster will not be encrypted. We recommend that you restrict direct access at the network level to just your load balancer.
+
+#### Required headers
+
+* `Host`
+* `X-Forwarded-Proto`
+* `X-Forwarded-Port`
+* `X-Forwarded-For`
+
+#### Health checks
+
+Rancher will respond `200` to health checks on the `/healthz` endpoint.
diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
new file mode 100644
index 00000000000..fa2e65fe889
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/tls-secrets/_index.md
@@ -0,0 +1,27 @@
+---
+title: Adding TLS Secrets
+weight: 276
+---
+
+Kubernetes will create all the objects and services for Rancher, but it will not become available until we populate the `tls-rancher-ingress` secret in the `cattle-system` namespace with the certificate and key.
+
+Combine the server certificate followed by the intermediate cert chain your CA provided into a file named `tls.crt`. Copy your key into a file name `tls.key`.
+
+Use `kubectl` with the `tls` secret type to create the secrets.
+
+```
+kubectl -n cattle-system create secret tls tls-rancher-ingress \
+ --cert=./tls.crt \
+ --key=./tls.key
+```
+
+### Private CA Signed - Additional Steps
+
+If you are using a private CA, Rancher will need to have a copy of the CA cert to include when generating agent configs.
+
+Copy the CA cert into a file named `cacerts.pem` and use `kubectl` to create the `tls-ca` secret in the `cattle-system` namespace.
+
+```
+kubectl -n cattle-system create secret generic tls-ca \
+ --from-file=cacerts.pem
+```
diff --git a/content/rancher/v2.x/en/installation/ha/helm-rancher/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/ha/helm-rancher/troubleshooting/_index.md
new file mode 100644
index 00000000000..fd12a12e04f
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/helm-rancher/troubleshooting/_index.md
@@ -0,0 +1,123 @@
+---
+title: Troubleshooting
+weight: 276
+---
+
+### Where is everything
+
+Most of the troubleshooting will be done on objects in these 3 namespaces.
+
+* `cattle-system` - `rancher` deployment and pods.
+* `ingress-nginx` - Ingress controller pods and services.
+* `kube-system` - `tiller` and `cert-manager` pods.
+
+### "default backend - 404"
+
+A number of things can cause the ingress-controller not to forward traffic to your rancher instance. Most of the time its due to a bad ssl configuration.
+
+Things to check
+
+* [Is Rancher Running](#is-rancher-running)
+* [Cert CN is "Kubernetes Ingress Controller Fake Certificate"](#cert-cn-is-kubernetes-ingress-controller-fake-certificate)
+
+### Is Rancher Running
+
+Use `kubectl` to check the `cattle-system` system namespace and see if the Rancher pods are in a Running state.
+
+```
+kubectl -n cattle-system get pods
+
+NAME READY STATUS RESTARTS AGE
+pod/rancher-784d94f59b-vgqzh 1/1 Running 0 10m
+```
+
+If the state is not `Running`, run a `describe` on the pod and check the Events.
+
+```
+kubectl -n cattle-system describe pod
+
+...
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal Scheduled 11m default-scheduler Successfully assigned rancher-784d94f59b-vgqzh to localhost
+ Normal SuccessfulMountVolume 11m kubelet, localhost MountVolume.SetUp succeeded for volume "rancher-token-dj4mt"
+ Normal Pulling 11m kubelet, localhost pulling image "rancher/rancher:v2.0.4"
+ Normal Pulled 11m kubelet, localhost Successfully pulled image "rancher/rancher:v2.0.4"
+ Normal Created 11m kubelet, localhost Created container
+ Normal Started 11m kubelet, localhost Started container
+```
+
+### Checking the rancher logs
+
+Use `kubectl` to list the pods.
+
+```
+kubectl -n cattle-system get pods
+
+NAME READY STATUS RESTARTS AGE
+pod/rancher-784d94f59b-vgqzh 1/1 Running 0 10m
+```
+
+Use `kubectl` and the pod name to list the logs from the pod.
+
+```
+kubectl -n cattle-namespace logs -f rancher-784d94f59b-vgqzh
+```
+
+### Cert CN is "Kubernetes Ingress Controller Fake Certificate"
+
+Use your browser to check the certificate details. If it says the Common Name is "Kubernetes Ingress Controller Fake Certificate", something may have gone wrong with reading or issuing your SSL cert.
+
+> Note: if you are using LetsEncrypt to issue certs it can sometimes take a few minuets to issue the cert.
+
+#### cert-manager issued certs (Rancher Generated or LetsEncrypt)
+
+`cert-manager` has 3 parts.
+
+* `cert-manager` pod in the `kube-system` namespace.
+* `Issuer` object in the `cattle-system` namespace.
+* `Certificate` object in the `cattle-system` namespace.
+
+Work backwards and do a `kubectl describe` on each object and check the events. You can track down what might be missing.
+
+For example there is a problem with the Issuer:
+
+```
+kubectl -n cattle-system describe certificate
+...
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Warning IssuerNotReady 18s (x23 over 19m) cert-manager Issuer rancher not ready
+```
+
+```
+kubectl -n cattle-system describe issuer
+...
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Warning ErrInitIssuer 19m (x12 over 19m) cert-manager Error initializing issuer: secret "tls-rancher" not found
+ Warning ErrGetKeyPair 9m (x16 over 19m) cert-manager Error getting keypair for CA issuer: secret "tls-rancher" not found
+```
+
+#### Bring Your Own SSL Certs
+
+Your certs get applied directly to the Ingress object in the `cattle-system` namespace.
+
+Check the status of the Ingress object and see if its ready.
+
+```
+kubectl -n cattle-system describe ingress
+```
+
+If its ready and the SSL is still not working you may have a malformed cert or secret.
+
+Check the nginx-ingress-controller logs. Because the nginx-ingress-controller has multiple containers in its pod you will need to specify the name of the container.
+
+```
+kubectl -n ingress-nginx logs -f nginx-ingress-controller-rfjrq nginx-ingress-controller
+...
+W0705 23:04:58.240571 7 backend_ssl.go:49] error obtaining PEM from secret cattle-system/tls-rancher-ingress: error retrieving secret cattle-system/tls-rancher-ingress: secret cattle-system/tls-rancher-ingress was not found
+```
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
new file mode 100644
index 00000000000..55eaadac4d6
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/_index.md
@@ -0,0 +1,110 @@
+---
+title: 2 - Install Kubernetes with RKE
+weight: 190
+---
+
+Use RKE to install Kubernetes with a high-availability etcd configuration.
+
+### Create the rancher-cluster.yml file
+
+Using the sample below create the `rancher-cluster.yml` file. Replace the IP Addresses in the `nodes` list with the IP address or DNS names of the 3 Nodes you created.
+
+> **Note:** If your node has public and internal addresses, it is recommended to set the `internal_address:` so Kubernetes will use it for intra-cluster communication. Some services like AWS EC2 require setting the `internal_address:` if you want to use self-referencing security groups or firewalls.
+
+```yaml
+nodes:
+- address: 165.227.114.63
+ internal_address: 172.16.22.12
+ user: ubuntu
+ role: [controlplane,worker,etcd]
+- address: 165.227.116.167
+ internal_address: 172.16.32.37
+ user: ubuntu
+ role: [controlplane,worker,etcd]
+- address: 165.227.127.226
+ internal_address: 172.16.42.73
+ user: ubuntu
+ role: [controlplane,worker,etcd]
+```
+
+#### Common RKE nodes: options
+
+| Option | Description |
+| --- | --- |
+| `address` | (required) The public DNS or IP address |
+| `internal_address` | (optional) The private DNS or IP address for internal cluster traffic |
+| `role` | (required) List of Kubernetes roles assigned to the node |
+| `ssh_key_path` | (optional) Path to SSH private key used to authenticate to the node |
+| `user` | (required) A user that can run docker commands |
+
+
+
+#### Advanced configurations
+
+RKE has many configuration options for customizing the install to suit your specific environment.
+
+Please see the [RKE Documentation]({{< baseurl >}}/rke/v0.1.x/en/) for the full list of options and capabilities.
+
+### Run RKE
+
+```
+rke up --config ./rancher-cluster.yml
+```
+
+### Testing your cluster
+
+RKE should have created a file `kube_config_rancher-cluster.yml`. This file has the credentials for `kubectl` and `helm`.
+
+You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`.
+
+```
+export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml
+```
+
+Test your connectivity with `kubectl` and see if you can get the list of nodes back.
+
+```
+kubectl get nodes
+
+NAME STATUS ROLES AGE VERSION
+165.227.114.63 Ready controlplane,etcd,worker 11m v1.10.1
+165.227.116.167 Ready controlplane,etcd,worker 11m v1.10.1
+165.227.127.226 Ready controlplane,etcd,worker 11m v1.10.1
+```
+
+### Check the health of your cluster pods
+
+Check that all the required pods and containers are healthy are ready to continue.
+
+* Pods are in `Running` or `Completed` state.
+* `READY` column shows all the containers are running (i.e. `3/3`) for pods with `STATUS` `Running`
+* Pods with `STATUS` `Completed` are run-one Jobs. For these pods `READY` should be `0/1`.
+
+```
+kubectl get pods --all-namespaces
+
+NAMESPACE NAME READY STATUS RESTARTS AGE
+ingress-nginx nginx-ingress-controller-tnsn4 1/1 Running 0 30s
+ingress-nginx nginx-ingress-controller-tw2ht 1/1 Running 0 30s
+ingress-nginx nginx-ingress-controller-v874b 1/1 Running 0 30s
+kube-system canal-jp4hz 3/3 Running 0 30s
+kube-system canal-z2hg8 3/3 Running 0 30s
+kube-system canal-z6kpw 3/3 Running 0 30s
+kube-system kube-dns-7588d5b5f5-sf4vh 3/3 Running 0 30s
+kube-system kube-dns-autoscaler-5db9bbb766-jz2k6 1/1 Running 0 30s
+kube-system metrics-server-97bc649d5-4rl2q 1/1 Running 0 30s
+kube-system rke-ingress-controller-deploy-job-bhzgm 0/1 Completed 0 30s
+kube-system rke-kubedns-addon-deploy-job-gl7t4 0/1 Completed 0 30s
+kube-system rke-metrics-addon-deploy-job-7ljkc 0/1 Completed 0 30s
+kube-system rke-network-plugin-deploy-job-6pbgj 0/1 Completed 0 30s
+```
+
+### Save your files
+
+Save a copy of the `kube_config_rancher-cluster.yml` and `rancher-cluster.yml` files. You will need these files to maintain and upgrade your Rancher instance.
+
+### Issues or errors?
+
+See the [Troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/ha/kubernetes-rke/troubleshooting/) page.
+
+### [Next: Initialize Helm]({{< baseurl >}}/rancher/v2.x/en/installation/ha/helm-init/)
diff --git a/content/rancher/v2.x/en/installation/ha/kubernetes-rke/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/troubleshooting/_index.md
new file mode 100644
index 00000000000..bca5815cccd
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/kubernetes-rke/troubleshooting/_index.md
@@ -0,0 +1,52 @@
+---
+title: Troubleshooting
+weight: 276
+---
+
+#### canal Pods show READY 2/3
+
+The most common cause of this issue is port 8472/UDP is not open between the nodes. Check your local firewall, network routing or security groups.
+
+Once the network issue is resolved, the `canal` pods should timeout and restart to establish their connections.
+
+#### nginx-ingress-controller Pods show RESTARTS
+
+The most common cause of this issue is the `canal` pods have failed to establish the overlay network. See [canal Pods show READY `2/3`](#canal-pods-show-ready-2-3) for troubleshooting.
+
+#### Failed to set up SSH tunneling for host [xxx.xxx.xxx.xxx]: Can't retrieve Docker Info
+
+##### Failed to dial to /var/run/docker.sock: ssh: rejected: administratively prohibited (open failed)
+
+* User specified to connect with does not have permission to access the Docker socket. This can be checked by logging into the host and running the command `docker ps`:
+
+```
+$ ssh user@server
+user@server$ docker ps
+CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
+```
+
+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 [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.
+
+* 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:
+```
+$ nc xxx.xxx.xxx.xxx 22
+SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.10
+```
+
+##### Failed to dial ssh using address [xxx.xxx.xxx.xxx:xx]: Error configuring SSH: ssh: no key found
+
+* The key file specified as `ssh_key_path` cannot be accessed. Make sure that you specified the private key file (not the public key, `.pub`), and that the user that is running the `rke` command can access the private key file.
+
+##### 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 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
+
+* If you want to use encrypted private keys, you should use `ssh-agent` to load your keys with your passphrase. If the `SSH_AUTH_SOCK` environment variable is found in the environment where the `rke` command is run, it will be used automatically to connect to the node.
+
+##### Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
+
+* The node is not reachable on the configured `address` and `port`.
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/_index.md
new file mode 100644
index 00000000000..845423dcb06
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/_index.md
@@ -0,0 +1,11 @@
+---
+title: Advanced Install - RKE Add-on
+weight: 276
+---
+
+Rancher can be installed by providing the appropriate Kubernetes manifest configurations to RKE's `addons` feature. See the following instructions for examples appropriate to your environment.
+
+* [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/)
diff --git a/content/rancher/v2.x/en/installation/ha-server-install/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
similarity index 67%
rename from content/rancher/v2.x/en/installation/ha-server-install/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
index dfb67c355d3..bb6f251614d 100644
--- a/content/rancher/v2.x/en/installation/ha-server-install/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/_index.md
@@ -1,89 +1,45 @@
---
-title: High Availability Installation with External Load Balancer (TCP/Layer 4)
+title: HA Install with External Load Balancer (TCP/Layer 4)
weight: 275
+aliases:
+- /rancher/v2.x/en/installation/ha-server-install/
---
-This set of instructions creates a new Kubernetes cluster that's dedicated to running Rancher in a high-availability (HA) configuration. This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
+This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
- Layer 4 load balancer (TCP)
- [NGINX ingress controller with SSL termination (HTTPS)](https://kubernetes.github.io/ingress-nginx/)
+
+In a HA setup that uses a layer 4 load balancer, the load balancer accepts Rancher client connections over the TCP/UDP protocols (i.e., the transport level). The load balancer then forwards these connections to individual cluster nodes without reading the request itself. Because the load balancer cannot read the packets it's forwarding, the routing decisions it can make are limited.
+HA Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers
## Installation Outline
Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.
-1. [Provision Linux Hosts](#1-provision-linux-hosts)
+
- Provision three Linux hosts to serve as your Kubernetes cluster.
+- [1. Provision Linux Hosts](#1-provision-linux-hosts)
+- [2. Configure Load Balancer](#2-configure-load-balancer)
+- [3. Configure DNS](#3-configure-dns)
+- [4. Download RKE](#4-download-rke)
+- [5. Download RKE Config File Template](#5-download-rke-config-file-template)
+- [6. Configure Nodes](#6-configure-nodes)
+- [7. Configure Certificates](#7-configure-certificates)
+- [8. Configure FQDN](#8-configure-fqdn)
+- [9. Configure Rancher version](#9-configure-rancher-version)
+- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file)
+- [11. Run RKE](#11-run-rke)
+- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file)
-2. [Configure Load Balancer](#2-configure-load-balancer)
-
- Configure your load balancer to have a highly available single point of entry to your Rancher cluster.
-
-3. [Configure DNS](#3-configure-dns)
-
- Make your setup accessible using a DNS name by configuring the DNS to point to your loadbalancer.
-
-4. [Download RKE](#4-download-rke)
-
- [RKE](https://github.com/rancher/rke/releases) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts.
-
-5. [Download RKE Config File Template](#5-download-rke-config-file-template)
-
- RKE uses a YAML config file to install and configure your Kubernetes cluster. Download one of our RKE config file templates to get started.
-
-6. [Configure Nodes](#6-configure-nodes)
-
- Configure the **Nodes** section of the RKE config template.
-
-7. [Configure Certificates](#7-configure-certificates)
-
- Configure the **Certificates** part of the template too.
-
-8. [Configure FQDN](#8-configure-fqdn)
-
- And the **FQDN** part.
-
-9. [Back Up Your RKE Config File](#9-back-up-your-rke-config-file)
-
- After you've completed configuration of the RKE config file: 1. it's no longer a template since you'll be using it, and 2. you should back up the RKE config file to a safe place. You will reuse this file for upgrades later.
-
-10. [Run RKE](#10-run-rke)
-
- Run RKE to deploy Rancher to your cluster.
-
-11. [Back Up Auto-Generated Config File](#11-back-up-auto-generated-config-file)
-
- During installation, RKE generates a config file that you'll use later for upgrades. Back it up to a safe location.
+
## 1. Provision Linux Hosts
-Before you install Rancher, confirm you meet the host requirements. Provision 3 new Linux hosts using the requirements below.
-
-### Host Requirements
-
-#### Operating System
-
-{{< requirements_os >}}
-
-#### Hardware
-
-{{< requirements_hardware >}}
-
-#### Software
-
-{{< requirements_software >}}
-
-{{< note_server-tags >}}
-
-#### Ports
-
-The following diagram depicts the basic port requirements for Rancher. For a comprehensive list, see [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/).
-
-
+Provision three Linux hosts according to our [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
## 2. Configure Load Balancer
@@ -109,7 +65,7 @@ After installing NGINX, you need to update the NGINX config file, `nginx.conf`,
2. From `nginx.conf`, replace `IP_NODE_1`, `IP_NODE_2`, and `IP_NODE_3` with the IPs of your [Linux hosts](#1-provision-linux-hosts).
>**Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
-
+
**Example NGINX config:**
```
worker_processes 4;
@@ -225,8 +181,14 @@ RKE uses a `.yml` config file to install and configure your Kubernetes cluster.
1. Download one of following templates, depending on the SSL certificate you're using.
- - [Template for self-signed certificate
`3-node-certificate.yml`](https://raw.githubusercontent.com/rancher/rancher/e9d29b3f3b9673421961c68adf0516807d1317eb/rke-templates/3-node-certificate.yml)
- - [Template for certificate signed by recognized CA
`3-node-certificate-recognizedca.yml`](https://raw.githubusercontent.com/rancher/rancher/d8ca0805a3958552e84fdf5d743859097ae81e0b/rke-templates/3-node-certificate-recognizedca.yml)
+ - [Template for self-signed certificate
`3-node-certificate.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-certificate.yml)
+ - [Template for certificate signed by recognized CA
`3-node-certificate-recognizedca.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-certificate-recognizedca.yml)
+
+ >**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 [RKE Documentation: API Auditing]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/api-auditing).
+ >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+
2. Rename the file to `rancher-cluster.yml`.
@@ -236,33 +198,37 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
1. Open `rancher-cluster.yml` in your favorite text editor.
-2. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
+1. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
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/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+ > 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/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) >for RHEL/CentOS specific requirements.
+ nodes:
+ # The IP address or hostname of the node
+ - address: IP_ADDRESS_1
+ # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
+ # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
+ user: USER
+ role: [controlplane,etcd,worker]
+ # Path the SSH key that can be used to access to node with the specified user
+ ssh_key_path: ~/.ssh/id_rsa
+ - address: IP_ADDRESS_2
+ user: USER
+ role: [controlplane,etcd,worker]
+ ssh_key_path: ~/.ssh/id_rsa
+ - address: IP_ADDRESS_3
+ user: USER
+ role: [controlplane,etcd,worker]
+ ssh_key_path: ~/.ssh/id_rsa
+
+1. **Optional:** By default, `rancher-cluster.yml` is configured to take backup snapshots of your data. To disable these snapshots, change the `backup` directive setting to `false`, as depicted below.
+
+ services:
+ etcd:
+ backup: false
-```
-nodes:
- # The IP address or hostname of the node
- - address: IP_ADDRESS_1
- # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
- # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
- user: USER
- role: [controlplane,etcd,worker]
- # Path the SSH key that can be used to access to node with the specified user
- ssh_key_path: ~/.ssh/id_rsa
- - address: IP_ADDRESS_2
- user: USER
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
- - address: IP_ADDRESS_3
- user: USER
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
-```
## 7. Configure Certificates
@@ -270,10 +236,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
-- [Option A—Bring Your Own Certificate: Self-Signed](#option-a-bring-your-own-certificate-self-signed)
-- [Option B—Bring Your Own Certificate: Signed by Recognized CA](#option-b-bring-your-own-certificate-signed-by-recognized-ca)
-
-### Option A—Bring Your Own Certificate: Self-Signed
+{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
>**Prerequisites:**
>Create a self-signed certificate.
@@ -290,20 +253,20 @@ Choose from the following options:
>**Note:**
> The base64 encoded string should be on the same line as `tls.crt` or `tls.key`, without any newline at the beginning, in between or at the end.
- **Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+ **Step Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
-```yaml
----
- apiVersion: v1
- kind: Secret
- metadata:
- name: cattle-keys-ingress
- namespace: cattle-system
- type: Opaque
- data:
- tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
- tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
-```
+ ```yaml
+ ---
+ apiVersion: v1
+ kind: Secret
+ metadata:
+ name: cattle-keys-ingress
+ namespace: cattle-system
+ type: Opaque
+ data:
+ tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
+ tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
+ ```
2. In `kind: Secret` with `name: cattle-keys-server`, replace `` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`).
@@ -311,7 +274,8 @@ Choose from the following options:
> The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
- **Result:** The file should look like the example below (the base64 encoded string should be different):
+ **Step Result:** The file should look like the example below (the base64 encoded string should be different):
+
```yaml
---
apiVersion: v1
@@ -322,10 +286,11 @@ Choose from the following options:
type: Opaque
data:
cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
- ```
+ ```
-### Option B—Bring Your Own Certificate: Signed by Recognized CA
+{{% /accordion %}}
+{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
>**Note:**
> If you are using Self Signed Certificate, [click here](#option-a-bring-your-own-certificate-self-signed) to proceed.
@@ -353,6 +318,10 @@ data:
tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1RENDQWN5Z0F3SUJBZ0lKQUlHc25NeG1LeGxLTUEwR0NTcUdTSWIzRFFFQkN3VUFNQkl4RURBT0JnTlYKQkFNTUIzUmxjM1F0WTJFd0hoY05NVGd3TlRBMk1qRXdOREE1V2hjTk1UZ3dOekExTWpFd05EQTVXakFXTVJRdwpFZ1lEVlFRRERBdG9ZUzV5Ym1Ob2NpNXViRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DCmdnRUJBTFJlMXdzekZSb2Rib2pZV05DSHA3UkdJaUVIMENDZ1F2MmdMRXNkUUNKZlcrUFEvVjM0NnQ3bSs3TFEKZXJaV3ZZMWpuY2VuWU5JSGRBU0VnU0ducWExYnhUSU9FaE0zQXpib3B0WDhjSW1OSGZoQlZETGdiTEYzUk0xaQpPM1JLTGdIS2tYSTMxZndjbU9zWGUwaElYQnpUbmxnM20vUzlXL3NTc0l1dDVwNENDUWV3TWlpWFhuUElKb21lCmpkS3VjSHFnMTlzd0YvcGVUalZrcVpuMkJHazZRaWFpMU41bldRV0pjcThTenZxTTViZElDaWlwYU9hWWQ3RFEKYWRTejV5dlF0YkxQNW4wTXpnOU43S3pGcEpvUys5QWdkWDI5cmZqV2JSekp3RzM5R3dRemN6VWtLcnZEb05JaQo0UFJHc01yclFNVXFSYjRSajNQOEJodEMxWXNDQXdFQUFhTTVNRGN3Q1FZRFZSMFRCQUl3QURBTEJnTlZIUThFCkJBTUNCZUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdJR0NDc0dBUVVGQndNQk1BMEdDU3FHU0liM0RRRUIKQ3dVQUE0SUJBUUNKZm5PWlFLWkowTFliOGNWUW5Vdi9NZkRZVEJIQ0pZcGM4MmgzUGlXWElMQk1jWDhQRC93MgpoOUExNkE4NGNxODJuQXEvaFZYYy9JNG9yaFY5WW9jSEg5UlcvbGthTUQ2VEJVR0Q1U1k4S292MHpHQ1ROaDZ6Ci9wZTNqTC9uU0pYSjRtQm51czJheHFtWnIvM3hhaWpYZG9kMmd3eGVhTklvRjNLbHB2aGU3ZjRBNmpsQTM0MmkKVVlCZ09iN1F5KytRZWd4U1diSmdoSzg1MmUvUUhnU2FVSkN6NW1sNGc1WndnNnBTUXhySUhCNkcvREc4dElSYwprZDMxSk1qY25Fb1Rhc1Jyc1NwVmNGdXZyQXlXN2liakZyYzhienBNcE1obDVwYUZRcEZzMnIwaXpZekhwakFsCk5ZR2I2OHJHcjBwQkp3YU5DS2ErbCtLRTk4M3A3NDYwCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBdEY3WEN6TVZHaDF1aU5oWTBJZW50RVlpSVFmUUlLQkMvYUFzU3gxQUlsOWI0OUQ5ClhmanEzdWI3c3RCNnRsYTlqV09keDZkZzBnZDBCSVNCSWFlcHJWdkZNZzRTRXpjRE51aW0xZnh3aVkwZCtFRlUKTXVCc3NYZEV6V0k3ZEVvdUFjcVJjamZWL0J5WTZ4ZDdTRWhjSE5PZVdEZWI5TDFiK3hLd2k2M21uZ0lKQjdBeQpLSmRlYzhnbWlaNk4wcTV3ZXFEWDJ6QVgrbDVPTldTcG1mWUVhVHBDSnFMVTNtZFpCWWx5cnhMTytvemx0MGdLCktLbG81cGgzc05CcDFMUG5LOUMxc3MvbWZRek9EMDNzck1Xa21oTDcwQ0IxZmIydCtOWnRITW5BYmYwYkJETnoKTlNRcXU4T2cwaUxnOUVhd3l1dEF4U3BGdmhHUGMvd0dHMExWaXdJREFRQUJBb0lCQUJKYUErOHp4MVhjNEw0egpwUFd5bDdHVDRTMFRLbTNuWUdtRnZudjJBZXg5WDFBU2wzVFVPckZyTnZpK2xYMnYzYUZoSFZDUEN4N1RlMDVxClhPa2JzZnZkZG5iZFQ2RjgyMnJleVByRXNINk9TUnBWSzBmeDVaMDQwVnRFUDJCWm04eTYyNG1QZk1vbDdya2MKcm9Kd09rOEVpUHZZekpsZUd0bTAwUm1sRysyL2c0aWJsOTVmQXpyc1MvcGUyS3ZoN2NBVEtIcVh6MjlpUmZpbApiTGhBamQwcEVSMjNYU0hHR1ZqRmF3amNJK1c2L2RtbDZURDhrSzFGaUtldmJKTlREeVNXQnpPbXRTYUp1K01JCm9iUnVWWG4yZVNoamVGM1BYcHZRMWRhNXdBa0dJQWxOWjRHTG5QU2ZwVmJyU0plU3RrTGNzdEJheVlJS3BWZVgKSVVTTHM0RUNnWUVBMmNnZUE2WHh0TXdFNU5QWlNWdGhzbXRiYi9YYmtsSTdrWHlsdk5zZjFPdXRYVzkybVJneQpHcEhUQ0VubDB0Z1p3T081T1FLNjdFT3JUdDBRWStxMDJzZndwcmgwNFZEVGZhcW5QNTBxa3BmZEJLQWpmanEyCjFoZDZMd2hLeDRxSm9aelp2VkowV0lvR1ZLcjhJSjJOWGRTUVlUanZUZHhGczRTamdqNFFiaEVDZ1lFQTFBWUUKSEo3eVlza2EvS2V2OVVYbmVrSTRvMm5aYjJ1UVZXazRXSHlaY2NRN3VMQVhGY3lJcW5SZnoxczVzN3RMTzJCagozTFZNUVBzazFNY25oTTl4WE4vQ3ZDTys5b2t0RnNaMGJqWFh6NEJ5V2lFNHJPS1lhVEFwcDVsWlpUT3ZVMWNyCm05R3NwMWJoVDVZb2RaZ3IwUHQyYzR4U2krUVlEWnNFb2lFdzNkc0NnWUVBcVJLYWNweWZKSXlMZEJjZ0JycGkKQTRFalVLMWZsSjR3enNjbGFKUDVoM1NjZUFCejQzRU1YT0kvSXAwMFJsY3N6em83N3cyMmpud09mOEJSM0RBMwp6ZTRSWDIydWw4b0hGdldvdUZOTTNOZjNaNExuYXpVc0F0UGhNS2hRWGMrcEFBWGthUDJkZzZ0TU5PazFxaUNHCndvU212a1BVVE84b1ViRTB1NFZ4ZmZFQ2dZQUpPdDNROVNadUlIMFpSSitIV095enlOQTRaUEkvUkhwN0RXS1QKajVFS2Y5VnR1OVMxY1RyOTJLVVhITXlOUTNrSjg2OUZPMnMvWk85OGg5THptQ2hDTjhkOWN6enI5SnJPNUFMTApqWEtBcVFIUlpLTFgrK0ZRcXZVVlE3cTlpaHQyMEZPb3E5OE5SZDMzSGYxUzZUWDNHZ3RWQ21YSml6dDAxQ3ZHCmR4VnVnd0tCZ0M2Mlp0b0RLb3JyT2hvdTBPelprK2YwQS9rNDJBOENiL29VMGpwSzZtdmxEWmNYdUF1QVZTVXIKNXJCZjRVYmdVYndqa1ZWSFR6LzdDb1BWSjUvVUxJWk1Db1RUNFprNTZXWDk4ZE93Q3VTVFpZYnlBbDZNS1BBZApTZEpuVVIraEpnSVFDVGJ4K1dzYnh2d0FkbWErWUhtaVlPRzZhSklXMXdSd1VGOURLUEhHCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
```
+
+{{% /accordion %}}
+
+
## 8. Configure FQDN
@@ -391,11 +360,23 @@ After replacing `` with the FQDN chosen in [Configure DNS](#3-configure-dn
Save the `.yml` file and close it.
-## 9. Back Up Your RKE Config File
+## 9. Configure Rancher version
+
+The last reference that needs to be replaced is ``. This needs to be replaced with a Rancher version which is marked as stable. The latest stable release of Rancher can be found in the [GitHub README](https://github.com/rancher/rancher/blob/master/README.md). Make sure the version is an actual version number, and not a named tag like `stable` or `latest`. The example below shows the version configured to `v2.0.6`.
+
+```
+ spec:
+ serviceAccountName: cattle-admin
+ containers:
+ - image: rancher/rancher:v2.0.6
+ imagePullPolicy: Always
+```
+
+## 10. Back Up Your RKE Config File
After you close your `.yml` file, back it up to a secure location. You can use this file again when it's time to upgrade Rancher.
-## 10. Run RKE
+## 11. Run RKE
With all configuration in place, use RKE to launch Rancher. You can complete this action by running the `rke up` command and using the `--config` parameter to point toward your config file.
@@ -423,7 +404,7 @@ INFO[0000] [network] Pulling image [alpine:latest] on host [1.1.1.1]
INFO[0101] Finished building Kubernetes cluster successfully
```
-## 11. Back Up Auto-Generated Config File
+## 12. Back Up Auto-Generated Config File
During installation, RKE automatically generates a config file named `kube_config_rancher-cluster.yml` in the same directory as the RKE binary. Copy this file and back it up to a safe location. You'll use this file later when upgrading Rancher Server.
diff --git a/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/nlb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/nlb/_index.md
new file mode 100644
index 00000000000..316b0ce50f4
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-4-lb/nlb/_index.md
@@ -0,0 +1,174 @@
+---
+title: Amazon NLB Configuration
+weight: 277
+aliases:
+- /rancher/v2.x/en/installation/ha-server-install/nlb/
+---
+## Objectives
+
+Configuring an Amazon NLB is a multistage process. We've broken it down into multiple tasks so that it's easy to follow.
+
+1. [Create Target Groups](#create-target-groups)
+
+ Begin by creating two target groups for the **TCP** protocol, one regarding TCP port 443 and one regarding TCP port 80 (providing redirect to TCP port 443). You'll add your Linux nodes to these groups.
+
+2. [Register Targets](#register-targets)
+
+ Add your Linux nodes to the target groups.
+
+3. [Create Your NLB](#create-your-nlb)
+
+ Use Amazon's Wizard to create an Network Load Balancer. As part of this process, you'll add the target groups you created in **1. Create Target Groups**.
+
+
+## Create Target Groups
+
+Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but its convenient to add a listener for port 80 which will be redirected to port 443 automatically. The NGINX controller on the nodes will make sure that port 80 gets redirected to port 443.
+
+Log into the [Amazon AWS Console](https://console.aws.amazon.com/ec2/) to get started, make sure to select the **Region** where your EC2 instances (Linux nodes) are created.
+
+The Target Groups configuration resides in the **Load Balancing** section of the **EC2** service. Select **Services** and choose **EC2**, find the section **Load Balancing** and open **Target Groups**.
+
+
+
+Click **Create target group** to create the first target group, regarding TCP port 443.
+
+### Target Group (TCP port 443)
+
+Configure the first target group according to the table below. Screenshots of the configuration are shown just below the table.
+
+Option | Setting
+--------------------------------------|------------------------------------
+Target Group Name | `rancher-tcp-443`
+Protocol | `TCP`
+Port | `443`
+Target type | `instance`
+VPC | Choose your VPC
+Protocol
(Health Check) | `HTTP`
+Path
(Health Check) | `/healthz`
+Port (Advanced health check) | `override`,`80`
+Healthy threshold (Advanced health) | `3`
+Unhealthy threshold (Advanced) | `3`
+Timeout (Advanced) | `6 seconds`
+Interval (Advanced) | `10 second`
+Success codes | `200-399`
+
+
+**Screenshot Target group TCP port 443 settings**
+
+
+
+**Screenshot Target group TCP port 443 Advanced settings**
+
+
+
+
+Click **Create target group** to create the second target group, regarding TCP port 80.
+
+### Target Group (TCP port 80)
+
+Configure the second target group according to the table below. Screenshots of the configuration are shown just below the table.
+
+Option | Setting
+--------------------------------------|------------------------------------
+Target Group Name | `rancher-tcp-80`
+Protocol | `TCP`
+Port | `80`
+Target type | `instance`
+VPC | Choose your VPC
+Protocol
(Health Check) | `HTTP`
+Path
(Health Check) | `/healthz`
+Port (Advanced health check) | `traffic port`
+Healthy threshold (Advanced health) | `3`
+Unhealthy threshold (Advanced) | `3`
+Timeout (Advanced) | `6 seconds`
+Interval (Advanced) | `10 second`
+Success codes | `200-399`
+
+
+**Screenshot Target group TCP port 80 settings**
+
+
+
+**Screenshot Target group TCP port 80 Advanced settings**
+
+
+
+
+## Register Targets
+
+Next, add your Linux nodes to both target groups.
+
+Select the target group named **rancher-tcp-443**, click the tab **Targets** and choose **Edit**.
+
+
+
+Select the instances (Linux nodes) you want to add, and click **Add to registered**.
+
+
+**Screenshot Add targets to target group TCP port 443**
+
+
+
+
+**Screenshot Added targets to target group TCP port 443**
+
+
+
+When the instances are added, click **Save** on the bottom right of the screen.
+
+Repeat those steps, replacing **rancher-tcp-443** with **rancher-tcp-80**. The same instances need to be added as targets to this target group.
+
+## Create Your NLB
+
+Use Amazon's Wizard to create an Network Load Balancer. As part of this process, you'll add the target groups you created in [Create Target Groups](#create-target-groups).
+
+1. From your web browser, navigate to the [Amazon EC2 Console](https://console.aws.amazon.com/ec2/).
+
+2. From the navigation pane, choose **LOAD BALANCING** > **Load Balancers**.
+
+3. Click **Create Load Balancer**.
+
+4. Choose **Network Load Balancer** and click **Create**.
+
+5. Complete the **Step 1: Configure Load Balancer** form.
+ - **Basic Configuration**
+
+ - Name: `rancher`
+ - Scheme: `internet-facing`
+ - **Listeners**
+
+ Add the **Load Balancer Protocols** and **Load Balancer Ports** below.
+ - `TCP`: `443`
+
+ - **Availability Zones**
+
+ - Select Your **VPC** and **Availability Zones**.
+
+6. Complete the **Step 2: Configure Routing** form.
+
+ - From the **Target Group** drop-down, choose **Existing target group**.
+
+ - From the **Name** drop-down, choose `rancher-tcp-443`.
+
+ - Open **Advanced health check settings**, and configure **Interval** to `10 seconds`.
+
+7. Complete **Step 3: Register Targets**. Since you registered your targets earlier, all you have to do is click **Next: Review**.
+
+8. Complete **Step 4: Review**. Look over the load balancer details and click **Create** when you're satisfied.
+
+9. After AWS creates the NLB, click **Close**.
+
+## Add listener to NLB for TCP port 80
+
+1. Select your newly created NLB and select the **Listeners** tab.
+
+2. Click **Add listener**.
+
+3. Use `TCP`:`80` as **Protocol** : **Port**
+
+4. Click **Add action** and choose **Forward to...**
+
+5. From the **Forward to** drop-down, choose `rancher-tcp-80`.
+
+6. Click **Save** in the top right of the screen.
diff --git a/content/rancher/v2.x/en/installation/ha-server-install-external-lb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
similarity index 57%
rename from content/rancher/v2.x/en/installation/ha-server-install-external-lb/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
index 3b97214f35b..256a2543e46 100644
--- a/content/rancher/v2.x/en/installation/ha-server-install-external-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/_index.md
@@ -1,88 +1,43 @@
---
-title: High Availability Installation with External Load Balancer (HTTPS/Layer 7)
+title: HA Install with External Load Balancer (HTTPS/Layer 7)
weight: 276
+aliases:
+- /rancher/v2.x/en/installation/ha-server-install-external-lb/
---
-This set of instructions creates a new Kubernetes cluster that's dedicated to running Rancher in a high-availability (HA) configuration. This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
+This procedure walks you through setting up a 3-node cluster using the Rancher Kubernetes Engine (RKE). The cluster's sole purpose is running pods for Rancher. The setup is based on:
- Layer 7 Loadbalancer with SSL termination (HTTPS)
- [NGINX Ingress controller (HTTP)](https://kubernetes.github.io/ingress-nginx/)
+In a HA setup that uses a layer 7 load balancer, the load balancer accepts Rancher client connections over the HTTP protocol (i.e., the application level). This application-level access allows the load balancer to read client requests and then redirect to them to cluster nodes using logic that optimally distributes load.
+
+HA Rancher install with layer 7 load balancer, depicting SSL termination at load balancer
## Installation Outline
Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete.
-1. [Provision Linux Hosts](#1-provision-linux-hosts)
+
- Provision three Linux hosts to serve as your Kubernetes cluster.
+- [1. Provision Linux Hosts](#1-provision-linux-hosts)
+- [2. Configure Load Balancer](#2-configure-load-balancer)
+- [3. Configure DNS](#3-configure-dns)
+- [4. Download RKE](#4-download-rke)
+- [5. Download RKE Config File Template](#5-download-rke-config-file-template)
+- [6. Configure Nodes](#6-configure-nodes)
+- [7. Configure Certificates](#7-configure-certificates)
+- [8. Configure FQDN](#8-configure-fqdn)
+- [9. Configure Rancher version](#9-configure-rancher-version)
+- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file)
+- [11. Run RKE](#11-run-rke)
+- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file)
-2. [Configure Load Balancer](#2-configure-load-balancer)
- Configure your load balancer to have a highly available single point of entry to your Rancher cluster.
-
-3. [Configure DNS](#3-configure-dns)
-
- Make your setup accessible using a DNS name by configuring the DNS to point to your loadbalancer.
-
-4. [Download RKE](#4-download-rke)
-
- [RKE](https://github.com/rancher/rke/releases) is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts.
-
-5. [Download RKE Config File Template](#5-download-rke-config-file-template)
-
- RKE uses a YAML config file to install and configure your Kubernetes cluster. Download one of our RKE config file templates to get started.
-
-6. [Configure Nodes](#6-configure-nodes)
-
- Configure the **Nodes** section of the RKE config template.
-
-7. [Configure Certificates](#7-configure-certificates)
-
- Configure the **Certificates** part of the template too.
-
-8. [Configure FQDN](#8-configure-fqdn)
-
- And the **FQDN** part.
-
-9. [Back Up Your RKE Config File](#9-back-up-your-rke-config-file)
-
- After you've completed configuration of the RKE config file: 1. it's no longer a template since you'll be using it, and 2. you should back up the RKE config file to a safe place. You will reuse this file for upgrades later.
-
-10. [Run RKE](#10-run-rke)
-
- Run RKE to deploy Rancher to your cluster.
-
-11. [Back Up Auto-Generated Config File](#11-back-up-auto-generated-config-file)
-
- During installation, RKE generates a config file that you'll use later for upgrades. Back it up to a safe location.
-
-
+
## 1. Provision Linux Hosts
-Before you install Rancher, confirm you meet the host requirements. Provision 3 new Linux hosts using the requirements below.
-
-### Requirements
-
-#### Operating System
-
-{{< requirements_os >}}
-
-#### Hardware
-
-{{< requirements_hardware >}}
-
-#### Software
-
-{{< requirements_software >}}
-
-{{< note_server-tags >}}
-
-#### Ports
-
-The following diagram depicts the basic port requirements for Rancher. For a comprehensive list, see [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/).
-
-
+Provision three Linux hosts according to our [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements).
## 2. Configure Load Balancer
@@ -105,8 +60,8 @@ Health checks can be executed on the `/healthz` endpoint of the node, this will
We have example configurations for the following load balancers:
-* [Amazon ALB configuration]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb/alb)
-* [NGINX configuration]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb/nginx)
+* [Amazon ALB configuration](alb/)
+* [NGINX configuration](nginx/)
## 3. Configure DNS
@@ -174,8 +129,14 @@ RKE uses a YAML config file to install and configure your Kubernetes cluster. Th
1. Download one of following templates, depending on the SSL certificate you're using.
- - [Template for self-signed certificate
`3-node-externalssl-certificate.yml`](https://raw.githubusercontent.com/rancher/rancher/58e695b51096b1f404188379cea6f6a35aea9e4c/rke-templates/3-node-externalssl-certificate.yml)
- - [Template for certificate signed by recognized CA
`3-node-externalssl-recognizedca.yml`](https://raw.githubusercontent.com/rancher/rancher/7f60dc3afe1b45287ac36ba6bde6f7c6e35c11fe/rke-templates/3-node-externalssl-recognizedca.yml)
+ - [Template for self-signed certificate
`3-node-externalssl-certificate.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-externalssl-certificate.yml)
+ - [Template for certificate signed by recognized CA
`3-node-externalssl-recognizedca.yml`](https://raw.githubusercontent.com/rancher/rancher/master/rke-templates/3-node-externalssl-recognizedca.yml)
+
+ >**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 [RKE Documentation: API Auditing]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/api-auditing).
+ >- Want to know the other config options available for your RKE template? See the [RKE Documentation: Config Options]({{< baseurl >}}/rke/v0.1.x/en/config-options/).
+
2. Rename the file to `rancher-cluster.yml`.
@@ -185,33 +146,37 @@ Once you have the `rancher-cluster.yml` config file template, edit the nodes sec
1. Open `rancher-cluster.yml` in your favorite text editor.
-2. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
+1. Update the `nodes` section with the information of your [Linux hosts](#1-provision-linux-hosts).
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/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+ >
+ >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/v0.1.x/en/installation/os#redhat-enterprise-linux-rhel-centos) for RHEL/CentOS specific requirements.
+ nodes:
+ # The IP address or hostname of the node
+ - address: IP_ADDRESS_1
+ # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
+ # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
+ user: USER
+ role: [controlplane,etcd,worker]
+ # Path the SSH key that can be used to access to node with the specified user
+ ssh_key_path: ~/.ssh/id_rsa
+ - address: IP_ADDRESS_2
+ user: USER
+ role: [controlplane,etcd,worker]
+ ssh_key_path: ~/.ssh/id_rsa
+ - address: IP_ADDRESS_3
+ user: USER
+ role: [controlplane,etcd,worker]
+ ssh_key_path: ~/.ssh/id_rsa
-```
-nodes:
- # The IP address or hostname of the node
- - address: IP_ADDRESS_1
- # User that can login to the node and has access to the Docker socket (i.e. can execute `docker ps` on the node)
- # When using RHEL/CentOS, this can't be root due to https://bugzilla.redhat.com/show_bug.cgi?id=1527565
- user: USER
- role: [controlplane,etcd,worker]
- # Path the SSH key that can be used to access to node with the specified user
- ssh_key_path: ~/.ssh/id_rsa
- - address: IP_ADDRESS_2
- user: USER
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
- - address: IP_ADDRESS_3
- user: USER
- role: [controlplane,etcd,worker]
- ssh_key_path: ~/.ssh/id_rsa
-```
+1. **Optional:** By default, `rancher-cluster.yml` is configured to take backup snapshots of your data. To disable these snapshots, change the `backup` directive setting to `false`, as depicted below.
+
+ services:
+ etcd:
+ backup: false
## 7. Configure Certificates
@@ -219,11 +184,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
Choose from the following options:
-- [Option A—Bring Your Own Certificate: Self-Signed](#option-a-bring-your-own-certificate-self-signed)
-- [Option B—Bring Your Own Certificate: Signed by Recognized CA](#option-b-bring-your-own-certificate-signed-by-recognized-ca)
-
-### Option A—Bring Your Own Certificate: Self-Signed
-
+{{% accordion id="option-a" label="Option A—Bring Your Own Certificate: Self-Signed" %}}
>**Prerequisites:**
>Create a self-signed certificate.
>
@@ -231,30 +192,26 @@ Choose from the following options:
>- The certificate files must be encoded in [base64](#base64).
>- In your certificate file, include all intermediate certificates in the chain. Order your certificates with your certificate first, followed by the intermediates. For an example, see [SSL FAQ / Troubleshooting](#cert-order).
-1. In `kind: Secret` with `name: cattle-keys-ingress`:
+In `kind: Secret` with `name: cattle-keys-ingress`, replace `` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`)
- * Replace `` with the base64 encoded string of the CA Certificate file (usually called `ca.pem` or `ca.crt`)
+>**Note:** The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
- >**Note:**
- > The base64 encoded string should be on the same line as `cacerts.pem`, without any newline at the beginning, in between or at the end.
+After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
- **Result:** After replacing the values, the file should look like the example below (the base64 encoded strings should be different):
+ ---
+ apiVersion: v1
+ kind: Secret
+ metadata:
+ name: cattle-keys-server
+ namespace: cattle-system
+ type: Opaque
+ data:
+ cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
- ```
- ---
- apiVersion: v1
- kind: Secret
- metadata:
- name: cattle-keys-server
- namespace: cattle-system
- type: Opaque
- data:
- cacerts.pem: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvRENDQVlnQ0NRRHVVWjZuMEZWeU16QU5CZ2txaGtpRzl3MEJBUXNGQURBU01SQXdEZ1lEVlFRRERBZDAKWlhOMExXTmhNQjRYRFRFNE1EVXdOakl4TURRd09Wb1hEVEU0TURjd05USXhNRFF3T1Zvd0VqRVFNQTRHQTFVRQpBd3dIZEdWemRDMWpZVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFNQmpBS3dQCndhRUhwQTdaRW1iWWczaTNYNlppVmtGZFJGckJlTmFYTHFPL2R0RUdmWktqYUF0Wm45R1VsckQxZUlUS3UzVHgKOWlGVlV4Mmo1Z0tyWmpwWitCUnFiZ1BNbk5hS1hocmRTdDRtUUN0VFFZdGRYMVFZS0pUbWF5NU45N3FoNTZtWQprMllKRkpOWVhHWlJabkdMUXJQNk04VHZramF0ZnZOdmJ0WmtkY2orYlY3aWhXanp2d2theHRUVjZlUGxuM2p5CnJUeXBBTDliYnlVcHlad3E2MWQvb0Q4VUtwZ2lZM1dOWmN1YnNvSjhxWlRsTnN6UjVadEFJV0tjSE5ZbE93d2oKaG41RE1tSFpwZ0ZGNW14TU52akxPRUc0S0ZRU3laYlV2QzlZRUhLZTUxbGVxa1lmQmtBZWpPY002TnlWQUh1dApuay9DMHpXcGdENkIwbkVDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFHTCtaNkRzK2R4WTZsU2VBClZHSkMvdzE1bHJ2ZXdia1YxN3hvcmlyNEMxVURJSXB6YXdCdFJRSGdSWXVtblVqOGo4T0hFWUFDUEthR3BTVUsKRDVuVWdzV0pMUUV0TDA2eTh6M3A0MDBrSlZFZW9xZlVnYjQrK1JLRVJrWmowWXR3NEN0WHhwOVMzVkd4NmNOQQozZVlqRnRQd2hoYWVEQmdma1hXQWtISXFDcEsrN3RYem9pRGpXbi8walI2VDcrSGlaNEZjZ1AzYnd3K3NjUDIyCjlDQVZ1ZFg4TWpEQ1hTcll0Y0ZINllBanlCSTJjbDhoSkJqa2E3aERpVC9DaFlEZlFFVFZDM3crQjBDYjF1NWcKdE03Z2NGcUw4OVdhMnp5UzdNdXk5bEthUDBvTXl1Ty82Tm1wNjNsVnRHeEZKSFh4WTN6M0lycGxlbTNZQThpTwpmbmlYZXc9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
- ```
-
-### Option B—Bring Your Own Certificate: Signed by Recognized CA
-
-If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
+{{% /accordion %}}
+{{% accordion id="option-b" label="Option B—Bring Your Own Certificate: Signed by Recognized CA" %}}
+If you are using a Certificate Signed By A Recognized Certificate Authority, you don't need to perform any step in this part.
+{{% /accordion %}}
## 8. Configure FQDN
@@ -291,11 +248,23 @@ There is one reference to `` in the RKE config file. Replace this referenc
3. Save the file and close it.
-## 9. Back Up Your RKE Config File
+## 9. Configure Rancher version
+
+The last reference that needs to be replaced is ``. This needs to be replaced with a Rancher version which is marked as stable. The latest stable release of Rancher can be found in the [GitHub README](https://github.com/rancher/rancher/blob/master/README.md). Make sure the version is an actual version number, and not a named tag like `stable` or `latest`. The example below shows the version configured to `v2.0.6`.
+
+```
+ spec:
+ serviceAccountName: cattle-admin
+ containers:
+ - image: rancher/rancher:v2.0.6
+ imagePullPolicy: Always
+```
+
+## 10. Back Up Your RKE Config File
After you close your RKE config file, `rancher-cluster.yml`, back it up to a secure location. You can use this file again when it's time to upgrade Rancher.
-## 10. Run RKE
+## 11. Run RKE
With all configuration in place, use RKE to launch Rancher. You can complete this action by running the `rke up` command and using the `--config` parameter to point toward your config file.
@@ -323,15 +292,13 @@ With all configuration in place, use RKE to launch Rancher. You can complete thi
INFO[0101] Finished building Kubernetes cluster successfully
```
-## 11. Back Up Auto-Generated Config File
+## 12. Back Up Auto-Generated Config File
During installation, RKE automatically generates a config file named `kube_config_rancher-cluster.yml` in the same directory as the `rancher-cluster.yml` file. Copy this file and back it up to a safe location. You'll use this file later when upgrading Rancher Server.
## What's Next?
-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).
+- **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.
- 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/ha-server-install-external-lb/alb/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/alb/_index.md
similarity index 96%
rename from content/rancher/v2.x/en/installation/ha-server-install-external-lb/alb/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/alb/_index.md
index 424d35bdd3f..abeb64eaded 100644
--- a/content/rancher/v2.x/en/installation/ha-server-install-external-lb/alb/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/alb/_index.md
@@ -1,6 +1,8 @@
---
-title: Amazon ALB configuration
+title: Amazon ALB Configuration
weight: 277
+aliases:
+- /rancher/v2.x/en/installation/ha-server-install-external-lb/alb/
---
## Objectives
diff --git a/content/rancher/v2.x/en/installation/ha-server-install-external-lb/nginx/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/nginx/_index.md
similarity index 96%
rename from content/rancher/v2.x/en/installation/ha-server-install-external-lb/nginx/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/nginx/_index.md
index dbfba4ffe81..d62c2c2c53f 100644
--- a/content/rancher/v2.x/en/installation/ha-server-install-external-lb/nginx/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/layer-7-lb/nginx/_index.md
@@ -1,6 +1,8 @@
---
-title: NGINX configuration
+title: NGINX Configuration
weight: 277
+aliases:
+- /rancher/v2.x/en/installation/ha-server-install-external-lb/nginx/
---
## Install NGINX
diff --git a/content/rancher/v2.x/en/installation/proxy-configuration/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/proxy/_index.md
similarity index 78%
rename from content/rancher/v2.x/en/installation/proxy-configuration/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/proxy/_index.md
index fe2182510fa..05cb1f6ef2a 100644
--- a/content/rancher/v2.x/en/installation/proxy-configuration/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/proxy/_index.md
@@ -1,6 +1,6 @@
---
title: HTTP Proxy Configuration
-weight: 360
+weight: 277
---
If you operate Rancher behind a proxy and you want to access services through the proxy (such as retrieving catalogs), you must provide Rancher information about your proxy. As Rancher is written in Go, it uses the common proxy environment variables as shown below.
@@ -14,25 +14,6 @@ NO_PROXY | Network address(es), network address range(s) and do
> **Note** NO_PROXY must be in uppercase to use network range (CIDR) notation.
-## Single Node Installation
-
-Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. Required values for `NO_PROXY` in a [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/) are:
-
-* `localhost`
-* `127.0.0.1`
-* `0.0.0.0`
-
-The example below is based on a proxy server accessible at `http://192.168.0.1:3128`, and excluding usage the proxy when accessing network range `192.168.10.0/24` and every hostname under the domain `example.com`.
-
-```
-docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- -e HTTP_PROXY="http://192.168.10.1:3128" \
- -e HTTPS_PROXY="http://192.168.10.1:3128" \
- -e NO_PROXY="localhost,127.0.0.1,0.0.0.0,192.168.10.0/24,example.com" \
- rancher/rancher:latest
-```
-
## High Availability Installation
When using High Availability Installation, the environment variables need to be added to the RKE Config File template.
diff --git a/content/rancher/v2.x/en/installation/troubleshooting-ha/404-default-backend/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/404-default-backend/_index.md
similarity index 96%
rename from content/rancher/v2.x/en/installation/troubleshooting-ha/404-default-backend/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/404-default-backend/_index.md
index 81140055fae..78bbfc446b6 100644
--- a/content/rancher/v2.x/en/installation/troubleshooting-ha/404-default-backend/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/404-default-backend/_index.md
@@ -1,6 +1,8 @@
---
title: 404 - default backend
weight: 30
+aliases:
+- /rancher/v2.x/en/installation/troubleshooting-ha/404-default-backend/
---
To debug issues around this error, you will need to download the command-line tool `kubectl`. See [Install and Set Up kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) how to download `kubectl` for your platform.
diff --git a/content/rancher/v2.x/en/installation/troubleshooting-ha/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/_index.md
similarity index 50%
rename from content/rancher/v2.x/en/installation/troubleshooting-ha/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/_index.md
index 00ce37f6927..2ab9ccf7147 100644
--- a/content/rancher/v2.x/en/installation/troubleshooting-ha/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/_index.md
@@ -1,24 +1,25 @@
---
-title: Troubleshooting High Availability Installation
+title: Troubleshooting HA RKE Add-On Install
weight: 370
+aliases:
+- /rancher/v2.x/en/installation/troubleshooting-ha/
---
This section contains common errors seen when setting up a High Availability Installation.
Choose from the following options:
-- [Generic troubleshooting]({{< baseurl >}}/rancher/v2.x/en/installation/troubleshooting-ha/generic-troubleshooting)
+- [Generic troubleshooting](generic-troubleshooting/)
In this section, you can find generic ways to debug your Kubernetes cluster.
-- [Failed to set up SSH tunneling for host]({{< baseurl >}}/rancher/v2.x/en/installation/troubleshooting-ha/ssh-tunneling)
+- [Failed to set up SSH tunneling for host](ssh-tunneling/)
In this section, you can find errors related to SSH tunneling when you run the `rke` command to setup your nodes.
-- [Failed to get job complete status]({{< baseurl >}}/rancher/v2.x/en/installation/troubleshooting-ha/job-complete-status)
+- [Failed to get job complete status](job-complete-status/)
In this section, you can find errors related to deploying addons.
-- [404 - default backend]({{< baseurl >}}/rancher/v2.x/en/installation/troubleshooting-ha/404-default-backend)
+- [404 - default backend](404-default-backend/)
In this section, you can find errors related to the `404 - default backend` page that is shown when trying to access Rancher.
-
diff --git a/content/rancher/v2.x/en/installation/troubleshooting-ha/generic-troubleshooting/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/generic-troubleshooting/_index.md
similarity index 98%
rename from content/rancher/v2.x/en/installation/troubleshooting-ha/generic-troubleshooting/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/generic-troubleshooting/_index.md
index f68ffb9906a..41ead2d7934 100644
--- a/content/rancher/v2.x/en/installation/troubleshooting-ha/generic-troubleshooting/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/generic-troubleshooting/_index.md
@@ -1,6 +1,8 @@
---
title: Generic troubleshooting
-weight: 5
+weight: 5
+aliases:
+- /rancher/v2.x/en/installation/troubleshooting-ha/generic-troubleshooting/
---
Below are steps that you can follow to determine what is wrong in your cluster.
diff --git a/content/rancher/v2.x/en/installation/troubleshooting-ha/job-complete-status/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/job-complete-status/_index.md
similarity index 96%
rename from content/rancher/v2.x/en/installation/troubleshooting-ha/job-complete-status/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/job-complete-status/_index.md
index 375a6387346..eaec014af2d 100644
--- a/content/rancher/v2.x/en/installation/troubleshooting-ha/job-complete-status/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/job-complete-status/_index.md
@@ -1,6 +1,8 @@
---
title: Failed to get job complete status
weight: 20
+aliases:
+- /rancher/v2.x/en/installation/troubleshooting-ha/job-complete-status/
---
To debug issues around this error, you will need to download the command-line tool `kubectl`. See [Install and Set Up kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) how to download `kubectl` for your platform.
diff --git a/content/rancher/v2.x/en/installation/troubleshooting-ha/ssh-tunneling/_index.md b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/ssh-tunneling/_index.md
similarity index 97%
rename from content/rancher/v2.x/en/installation/troubleshooting-ha/ssh-tunneling/_index.md
rename to content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/ssh-tunneling/_index.md
index ee6573f52ed..d9e2d477628 100644
--- a/content/rancher/v2.x/en/installation/troubleshooting-ha/ssh-tunneling/_index.md
+++ b/content/rancher/v2.x/en/installation/ha/rke-add-on/troubleshooting/ssh-tunneling/_index.md
@@ -1,6 +1,8 @@
---
title: Failed to set up SSH tunneling for host
weight: 10
+aliases:
+- /rancher/v2.x/en/installation/troubleshooting-ha/ssh-tunneling/
---
### Failed to set up SSH tunneling for host [xxx.xxx.xxx.xxx]: Can't retrieve Docker Info
diff --git a/content/rancher/v2.x/en/installation/references/_index.md b/content/rancher/v2.x/en/installation/references/_index.md
index b6e59939422..3dcbb42a032 100644
--- a/content/rancher/v2.x/en/installation/references/_index.md
+++ b/content/rancher/v2.x/en/installation/references/_index.md
@@ -1,6 +1,6 @@
---
title: Port Requirements
-weight: 355
+weight: 280
aliases:
- /rancher/v2.x/en/hosts/amazon/#required-ports-for-rancher-to-work/
---
diff --git a/content/rancher/v2.x/en/installation/removing-rancher/_index.md b/content/rancher/v2.x/en/installation/removing-rancher/_index.md
deleted file mode 100644
index 3a9f7d56271..00000000000
--- a/content/rancher/v2.x/en/installation/removing-rancher/_index.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Removing Rancher
-weight: 375
----
-
-This section contains instructions on how to remove Rancher or nodes added to clusters.
-
-Choose from the following options:
-
-- [Cleaning cluster nodes]({{< baseurl >}}/rancher/v2.x/en/installation/removing-rancher/cleaning-cluster-nodes)
-
- In this section, you can find steps to clean nodes that have been added to clusters created in Rancher.
diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md
new file mode 100644
index 00000000000..930f75ce31a
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/requirements/_index.md
@@ -0,0 +1,75 @@
+---
+title: Node Requirements
+weight: 1
+aliases:
+---
+
+Whether you're configuring Rancher to run in a single-node or high-availability setup, each node running Rancher Server must meet the following requirements.
+
+{{% tabs %}}
+{{% tab "Operating Systems" %}}
+Rancher is supported on the following operating systems and their subsequent releases.
+
+* Ubuntu 16.04 (64-bit)
+* Red Hat Enterprise Linux 7.5 (64-bit)
+* RancherOS 1.4 (64-bit)
+{{% /tab %}}
+{{% tab "Hardware" %}}
+Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements.
+
+
+
+ | Deployment Size |
+ Clusters |
+ Nodes |
+ vCPUs |
+ RAM |
+
+
+ | Small |
+ Up to 10 |
+ Up to 50 |
+ 2 |
+ 4GB |
+
+
+ | Medium |
+ Up to 100 |
+ Up to 500 |
+ 8 |
+ 32GB |
+
+
+ | Large |
+ Over 100 |
+ Over 500 |
+ Contact Rancher |
+
+
+
+
+{{% /tab %}}
+{{% tab "Software" %}}
+A supported version of [Docker](https://www.docker.com/) is required.
+
+Supported Versions:
+
+* `1.12.6`
+* `1.13.1`
+* `17.03.2`
+
+[Docker Documentation: Installation Instructions](https://docs.docker.com/)
+{{% /tab %}}
+{{% tab "Ports" %}}
+
+When deploying Rancher in an HA cluster, certain ports on your nodes must be open to allow communication with Rancher. The ports that must be open change according to the type of machines hosting your cluster nodes. For example, if your are deploying Rancher on nodes hosted by an IaaS, port `22` must be open for SSH. The following diagram depicts the ports that are opened for each [cluster type]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning).
+
+Cluster Type Port Requirements
+
+
+
+{{< requirements_ports_rancher >}}
+{{< requirements_ports_rke >}}
+{{< ports_aws_securitygroup_nodedriver >}}
+{{% /tab %}}
+{{% /tabs %}}
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/installation/server-tags/_index.md b/content/rancher/v2.x/en/installation/server-tags/_index.md
index 2eae26dfe6d..2dde9a9e39b 100644
--- a/content/rancher/v2.x/en/installation/server-tags/_index.md
+++ b/content/rancher/v2.x/en/installation/server-tags/_index.md
@@ -1,6 +1,6 @@
---
title: Server Tags
-weight: 200
+weight: 230
---
{{< product >}} Server is distributed as a Docker image, which have _tags_ attached to them. Tags are used to identify what version is included in the image. Rancher includes additional tags that point to a specific version. Remember that if you use the additional tags, you must explicitly pull a new version of that image tag. Otherwise it will use the cached image on the host.
diff --git a/content/rancher/v2.x/en/installation/single-node-install/_index.md b/content/rancher/v2.x/en/installation/single-node-install/_index.md
deleted file mode 100644
index 6e16cafbc2f..00000000000
--- a/content/rancher/v2.x/en/installation/single-node-install/_index.md
+++ /dev/null
@@ -1,195 +0,0 @@
----
-title: Single Node Installation
-weight: 250
----
-For development 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 install Rancher on your host using a single Docker container.
-
-
->**Want to use an external load balancer?**
-> See [Single Node Installation with an External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install-external-lb) instead.
-
-
-
-## Installation Outline
-
-Installation of Rancher on a single node involves multiple procedures. Review this outline to learn about each procedure you need to complete.
-
-1. [Provision Linux Host](#1-provision-linux-host)
-
- Provision a single Linux host to launch your {{< product >}} Server.
-
-2. [Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher)
-
- Choose an SSL option for Rancher communication encryption. After choosing an option, run the command that accompanies it to deploy Rancher.
-
-## 1. Provision Linux Host
-
-Provision a single Linux host to launch your {{< product >}} Server.
-
-### Requirements
-
-#### Operating System
-
-{{< requirements_os >}}
-
-#### Hardware
-
-{{< requirements_hardware >}}
-
-#### Software
-
-{{< requirements_software >}}
-
-{{< note_server-tags >}}
-
-#### Ports
-
-The following diagram depicts the basic port requirements for Rancher. For a comprehensive list, see [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/).
-
-
-
-## 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.
-
->**Attention Air Gap Users:**
-> If you are visiting this page to complete [Air Gap Installation]({{< baseurl >}}/rancher/v2.x/en/installation/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. Replace `` with your private registry URL.
->
-> Example:
-```
-/rancher/rancher:latest
-```
-
-Choose from the following options:
-
-- [Option A—Default Self-Signed Certificate](#option-a-default-self-signed-certificate)
-- [Option B—Bring Your Own Certificate: Self-Signed](#option-b-bring-your-own-certificate-self-signed)
-- [Option C—Bring Your Own Certificate: Signed by Recognized CA](#option-c-bring-your-own-certificate-signed-by-recognized-ca)
-- [Option D—Let's Encrypt Certificate](#option-d-let-s-encrypt-certificate)
-
-### Option A—Default Self-Signed Certificate
-
-If you install Rancher without using your own certificate, Rancher generates a self-signed certificate that's used for encryption. If you're satisfied with this certificate, there's no need to obtain your own.
-
-**To Install Rancher Using the Default Certificate:**
-
-1. From your Linux host, run the Docker command to install Rancher without any additional parameters:
-
- ```
- docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- rancher/rancher:latest
- ```
-
-
-
-### Option B—Bring Your Own Certificate: Self-Signed
-
-Your Rancher install can use a self-signed certificate that you provide to encrypt communications.
-
->**Prerequisites:**
->Create a self-signed certificate.
->
->- 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).
-
-
-**To Install Rancher Using a Self-Signed Cert:**
-
-Your Rancher install can use a self-signed certificate that you provide to encrypt communications.
-
-1. After creating your certificate, run the Docker command to install Rancher, pointing toward your certificate files.
-
- ```
- docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- -v /etc//:/etc/rancher/ssl/cert.pem \
- -v /etc//:/etc/rancher/ssl/key.pem \
- -v /etc//:/etc/rancher/ssl/cacerts.pem \
- rancher/rancher:latest
- ```
-
-
-### Option C—Bring Your Own Certificate: Signed by Recognized CA
-
-If you're publishing your app publicly, you should ideally be using a certificate signed by a recognized CA.
-
->**Prerequisites:**
->
->- The certificate files must be in [PEM format](#pem).
->- Make sure that the container includes your certificate file and the key file. Because your certificate is signed by a recognized CA, mounting an additional CA certificate file is unnecessary.
->- Add `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
-
-**To Install Rancher Using a Certificate Signed by a Recognized CA:**
-
-1. After obtaining your certificate, run the Docker command to deploy Rancher while pointing toward your certificate files.
-
- ```
- docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- -v /etc/your_certificate_directory/fullchain.pem:/etc/rancher/ssl/cert.pem \
- -v /etc/your_certificate_directory/privkey.pem:/etc/rancher/ssl/key.pem \
- rancher/rancher:latest --no-cacerts
- ```
-
-### Option D—Let's Encrypt Certificate
-
-Rancher supports Let's Encrypt 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.
-
-
-**To Install Rancher Using a Let's Encrypt Certificate:**
-
-Run the following commands from your Linux host.
-
-1. Run the Docker command.
-
- ```
- docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- rancher/rancher:latest \
- --acme-domain rancher.mydomain.com
- ```
-
-
->
->**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/).
-
-## What's Next?
-
-You have a couple of options:
-
-- Create a backup of your Rancher Server in case of a disaster scenario: [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/).
-- Create a Kubernetes cluster: [Provisioning Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/).
-
-
-
-## FAQ and Troubleshooting
-
-{{< ssl_faq_single >}}
-
-## 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 advice 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
-```
-
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..0b5ac19717d
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/single-node/_index.md
@@ -0,0 +1,189 @@
+---
+title: Single Node Install
+weight: 250
+aliases:
+ - /rancher/v2.x/en/installation/single-node-install/
+ - /rancher/v2.x/en/installation/custom-ca-root-certificate/
+---
+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...**
+>
+>- Complete an Air Gap Installation?
+>- Record all transactions with the Rancher API?
+>
+>See [Advanced Options](#advanced-options) below before continuing.
+
+Choose from the following options:
+
+{{% accordion id="option-a" label="Option A—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.
+
+- Replace `` with the directory path to your certificate file.
+- Replace ``,``, and `` with your certificate names.
+
+```
+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.
+
+>**Prerequisite:** The certificate files must be in [PEM format](#pem).
+
+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.
+
+ - Replace `` with the directory path to your certificate file.
+ - Replace `` and `` with your certificate names.
+
+- Use the `--no-cacerts` as argument to the container to disable the default CA certificate generated by Rancher.
+
+```
+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—Bring Your Own Certificate: Private CA Root Certificate" %}}
+
+If you're using Rancher in a internal production environment where you aren't exposing apps publicly, use a certificate from a private certificate authority (CA).
+
+Services that Rancher needs to access are sometimes configured with a certificate from an custom/internal CA root, also known as self signed certificate. If the presented certificate from the service cannot be validated by Rancher, the following error displays: `x509: certificate signed by unknown authority`.
+
+To validate the certificate, the CA root certificates need to be added to Rancher. As Rancher is written in Go, we can use the environment variable `SSL_CERT_DIR` to point to the directory where the CA root certificates are located in the container. The CA root certificates directory can be mounted using the Docker volume option (`-v host-source-directory:container-destination-directory`) when starting the Rancher container.
+
+Examples of services that Rancher can access:
+
+* Catalogs
+* Authentication providers
+* Accessing hosting/cloud API when using Node Drivers
+
+Use the the command example to start a Rancher container with you 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
+```
+{{% /accordion %}}
+{{% accordion id="option-e" label="Option E—Let's Encrypt Certificate" %}}
+
+For production environments, you also have the options 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. Replace `` with your your domain.
+
+
+ docker run -d --restart=unless-stopped \
+ -p 80:80 -p 443:443 \
+ rancher/rancher:latest \
+ --acme-domain
+
+>**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/).
+{{% /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/).
+
+
+
+## FAQ and Troubleshooting
+
+{{< ssl_faq_single >}}
+
+## Advanced Options
+
+### API Auditing
+
+If you want to record all transations with the Rancher API, enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by adding the flags below into your install command.
+
+ -e AUDIT_LEVEL=1 \
+ -e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
+ -e AUDIT_LOG_MAXAGE=20 \
+ -e AUDIT_LOG_MAXBACKUP=20 \
+ -e AUDIT_LOG_MAXSIZE=100 \
+
+### Air Gap
+
+If you are visiting this page to complete an [Air Gap Installation]({{< baseurl >}}/rancher/v2.x/en/installation/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 advice 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
+```
diff --git a/content/rancher/v2.x/en/installation/single-node/proxy/_index.md b/content/rancher/v2.x/en/installation/single-node/proxy/_index.md
new file mode 100644
index 00000000000..9a82c8bbdc2
--- /dev/null
+++ b/content/rancher/v2.x/en/installation/single-node/proxy/_index.md
@@ -0,0 +1,36 @@
+---
+title: HTTP Proxy Configuration
+weight: 251
+aliases:
+- /rancher/v2.x/en/installation/proxy-configuration/
+---
+If you operate Rancher behind a proxy and you want to access services through the proxy (such as retrieving catalogs), you must provide Rancher information about your proxy. As Rancher is written in Go, it uses the common proxy environment variables as shown below.
+
+Make sure `NO_PROXY` contains the network addresses, network address ranges and domains that should be excluded from using the proxy.
+
+Environment variable | Purpose
+--------------------------|---------
+HTTP_PROXY | Proxy address to use when initiating HTTP connection(s)
+HTTPS_PROXY | Proxy address to use when initiating HTTPS connection(s)
+NO_PROXY | Network address(es), network address range(s) and domains to exclude from using the proxy when initiating connection(s)
+
+> **Note** NO_PROXY must be in uppercase to use network range (CIDR) notation.
+
+## Single Node Installation
+
+Passing environment variables to the Rancher container can be done using `-e KEY=VALUE` or `--env KEY=VALUE`. Required values for `NO_PROXY` in a [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install/) are:
+
+* `localhost`
+* `127.0.0.1`
+* `0.0.0.0`
+
+The example below is based on a proxy server accessible at `http://192.168.0.1:3128`, and excluding usage the proxy when accessing network range `192.168.10.0/24` and every hostname under the domain `example.com`.
+
+```
+docker run -d --restart=unless-stopped \
+ -p 80:80 -p 443:443 \
+ -e HTTP_PROXY="http://192.168.10.1:3128" \
+ -e HTTPS_PROXY="http://192.168.10.1:3128" \
+ -e NO_PROXY="localhost,127.0.0.1,0.0.0.0,192.168.10.0/24,example.com" \
+ rancher/rancher:latest
+```
diff --git a/content/rancher/v2.x/en/installation/single-node-install-external-lb/_index.md b/content/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/_index.md
similarity index 59%
rename from content/rancher/v2.x/en/installation/single-node-install-external-lb/_index.md
rename to content/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/_index.md
index 24e05fcf619..4ac255820ec 100644
--- a/content/rancher/v2.x/en/installation/single-node-install-external-lb/_index.md
+++ b/content/rancher/v2.x/en/installation/single-node/single-node-install-external-lb/_index.md
@@ -1,76 +1,42 @@
---
-title: Single Node Installation with External Load Balancer
-weight: 260
+title: Single Node Install with External Load Balancer
+weight: 252
+aliases:
+- /rancher/v2.x/en/installation/single-node-install-external-lb/
---
-For development environments, we recommend installing Rancher by running a single Docker container. In this installation scenario, you'll deploy Rancher to a Linux host using a single Docker container. Then you will configure an external load balancer to work with Rancher.
-
+For development and testing environments that have a special requirement to terminate TLS/SSL at a load balancer instead of your Rancher Server container, deploy Rancher and configure a load balancer to work with it it conjunction. This install procedure walks you through deployment of Rancher using a single container, and then provides a sample configuration for a layer 7 Nginx load balancer.
>**Want to skip the external load balancer?**
-> See [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install) instead.
-
-
+> See [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/single-node) instead.
## Installation Outline
+
-Installation of Rancher on a single node with an external load balancer involves multiple procedures. Review this outline to learn about each procedure you need to complete.
-
-1. [Provision Linux Host](#1-provision-linux-host)
-
- Provision a single Linux host to launch your {{< product >}} Server.
-
-2. [Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher)
-
- Choose an SSL option for Rancher communication encryption. After choosing an option, run the command that accompanies it to deploy Rancher.
-
-3. [Configure Load Balancer](#3-configure-load-balancer)
-
- Setup a load balancer to direct communications with Rancher and your Kubernetes cluster.
+- [1. Provision Linux Host](#1-provision-linux-host)
+- [2. Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher)
+- [3. Configure Load Balancer](#3-configure-load-balancer)
+
## 1. Provision Linux Host
-Provision a single Linux host to launch your {{< product >}} Server.
-
-### Host Requirements
-
-#### Operating System
-
-{{< requirements_os >}}
-
-#### Hardware
-
-{{< requirements_hardware >}}
-
-#### Software
-
-{{< requirements_software >}}
-
-{{< note_server-tags >}}
-
-#### Ports
-
-The following diagram depicts the basic port requirements for Rancher. For a comprehensive list, see [Port Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/references/).
-
-
+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.
->**Attention Air Gap Users:**
-> If you are visiting this page to complete [Air Gap Installation]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-installation/), you must prepend your private registry URL to the server tag when running the installation command in the option that you choose. Replace `` with your private registry URL.
+>**Do you want to...**
>
-> Example:
-```
-/rancher/rancher:latest
-```
+>- Complete an Air Gap Installation?
+>- Record all transactions with the Rancher API?
+>
+>See [Advanced Options](#advanced-options) below before continuing.
-- [Option A-Bring Your Own Certificate: Self-Signed](#option-a-bring-your-own-certificate-self-signed)
-- [Option B-Bring Your Own Certificate: Signed by Recognized CA](#option-b-bring-your-own-certificate-signed-by-recognized-ca)
+Choose from the following options:
-### Option A-Bring Your Own Certificate: Self-Signed
-
-If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the docker command to deploy Rancher, pointing it toward your certificate.
+{{% accordion id="option-a" label="Option A-Bring Your Own Certificate: Self-Signed" %}}
+If you elect to use a self-signed certificate to encrypt communication, you must install the certificate on your load balancer (which you'll do later) and your Rancher container. Run the Docker command to deploy Rancher, pointing it toward your certificate.
>**Prerequisites:**
>Create a self-signed certificate.
@@ -83,13 +49,13 @@ If you elect to use a self-signed certificate to encrypt communication, you must
```
docker run -d --restart=unless-stopped \
- -p 80:80 -p 443:443 \
- -v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
- rancher/rancher:latest
+ -p 80:80 -p 443:443 \
+ -v /etc/your_certificate_directory/cacerts.pem:/etc/rancher/ssl/cacerts.pem \
+ rancher/rancher:latest
```
-
-### Option B-Bring Your Own Certificate: Signed by Recognized CA
-
+
+{{% /accordion %}}
+{{% accordion id="option-b" label="Option B-Bring Your Own Certificate: Signed by Recognized CA" %}}
If your cluster is public facing, it's best to use a certificate signed by a recognized CA.
>**Prerequisites:**
@@ -106,7 +72,8 @@ If you use a certificate signed by a recognized CA, installing your certificate
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 \
rancher/rancher:latest --no-cacerts
- ```
+ ```
+{{% /accordion %}}
## 3. Configure Load Balancer
@@ -129,10 +96,10 @@ The load balancer or proxy has to be configured to support the following:
### Example Nginx configuration
-This Nginx configuration is tested on Nginx version 1.13 (mainline) and 1.14 (stable).
+This layer 7 Nginx configuration is tested on Nginx version 1.13 (mainline) and 1.14 (stable).
>**Note:** This Nginx configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - TCP and UDP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/).
-
+
```
upstream rancher {
server rancher-server:80;
@@ -173,9 +140,8 @@ server {
## What's Next?
-You have a couple of options:
-- Create a backup of your Rancher Server in case of a disaster scenario: [Single Node Backup and Restoration]({{< baseurl >}}/rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/).
+- **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/).
@@ -184,6 +150,26 @@ You have a couple of options:
{{< ssl_faq_single >}}
-## Persistent Data
+## Advanced Options
+
+### API Auditing
+
+If you want to record all transations with the Rancher API, enable the [API Auditing]({{< baseurl >}}/rancher/v2.x/en/installation/api-auditing) feature by adding the flags below into your install command.
+
+ -e AUDIT_LEVEL=1 \
+ -e AUDIT_LOG_PATH=/var/log/auditlog/rancher-api-audit.log \
+ -e AUDIT_LOG_MAXAGE=20 \
+ -e AUDIT_LOG_MAXBACKUP=20 \
+ -e AUDIT_LOG_MAXSIZE=100 \
+
+### Air Gap
+
+If you are visiting this page to complete an [Air Gap Installation]({{< baseurl >}}/rancher/v2.x/en/installation/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 >}}
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 302e22b9d06..be9c46a198e 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
@@ -23,7 +23,7 @@ Add SSL certificates to either projects, namespaces, or both. A project scoped c
- **Available to all namespaces in this project:** The certificate is available for any deployment in any namespaces in the project.
- - **Available to a single namespace:** The certificate is only available for the deployments in one namespace. If you choose this option, select a **Namespace** from the drop-down list or click **Add to a new namespace** to add the certificate to a namespace you create on the fly.
+ - **Available to a single namespace:** The certificate is only available for the deployments in one [namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces). If you choose this option, select a **Namespace** from the drop-down list or click **Add to a new namespace** to add the certificate to a namespace you create on the fly.
1. From **Private Key**, either copy and paste your certificate's private key into the text box (include the header and footer), or click **Read from a file** to browse to the private key on your file system. If possible, we recommend using **Read from a file** to reduce likelihood of error.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
index 82814cc4b52..67bde0843af 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/configmaps/_index.md
@@ -10,8 +10,8 @@ While most types of Kubernetes secrets store sensitive information, [ConfigMaps]
ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. After you upload a config map, any workload can reference it as either an environment variable or a volume mount.
->**Note:** ConfigMaps are only available within namespaces and not projects.
-
+>**Note:** ConfigMaps are only available within [namespaces]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) and not [projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects).
+({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces)
ConfigMaps store general configuration information for an application, such as configuration files, command-line arguments, environment variables, etc. ConfigMaps accept key value pairs in common string formats, like config files or JSON blobs. Add ConfigMaps to your Rancher workspaces so that you can add them to your workloads later. For more information on ConfigMaps, see the official [Kubernetes Documentation: Using ConfigMap](https://kubernetes-v1-4.github.io/docs/user-guide/configmap/).
>**Note:** ConfigMaps can only be applied to namespaces and not projects.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md
index 309e665b75c..3c7717bce77 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/editing-clusters/_index.md
@@ -3,9 +3,24 @@ title: Editing Clusters
weight: 3015
---
-## Editing the Cluster Membership
+After you provision a Kubernetes cluster using Rancher, you can still edit options and settings for the cluster. To edit your cluster, open the **Global** view, make sure the **Clusters** tab is selected, and then select **Ellipsis (...) > Edit** for the cluster that you want to edit.
-Following cluster creation, you can add users as cluster members so that they can access its resources.
+To Edit an Existing Cluster
+
+
+The options and settings available for an existing cluster change based on the method that you used to provision it. For example, only clusters [provisioned by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) have **Cluster Options** available for editing.
+
+The following table lists the options and settings available for each cluster type:
+
+ Cluster Type | Member Roles | Cluster Options | Node Pools
+---------|----------|---------|---------|
+ [RKE-Launched]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#rancher-launched-kubernetes) | ✓ | ✓ | ✓ |
+ [Hosted Kubernetes Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#hosted-kubernetes-cluster) | ✓ | | |
+ [Imported]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#import-existing-cluster) | ✓ | | |
+
+## 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.
>**Ping and MS FS Caveats:**
>
@@ -47,33 +62,99 @@ Following cluster creation, you can add users as cluster members so that they ca
## Cluster Options
->**Note:** These cluster options are only available for [clusters that Rancher has launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).
+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.
-### Adding/Changing a Pod Security Policy
+### Upgrading Kubernetes
-If you don't apply a PSP as you create your cluster, you can always add one later.
+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 versions of Kubernetes to ensure compatibility.
->**Prerequisite:**
->Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing cluster, 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/).
+>**Recommended:** Before upgrading Kubernetes, [backup your cluster]({{< baseurl >}}/rancher/v2.x/en/backups).
-1. From the **Global** view, find the cluster that you want to apply your PSP to. Select **Vertical Ellipsis (...) > Edit** for the cluster you want to enable PSPs for.
+1. From the **Global** view, find the cluster for which you want to upgrade Kubernetes. Select **Vertical Ellipsis (...) > Edit**.
-2. Expand the **Cluster Options** accordion.
+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.
+
+### 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:** Not all cluster providers support PSPs, so this option may not be available.
+ >**Note:** This option is only available for clusters [provisioned by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).
- **Step Result:** The **Default Pod Security Policy** drop-down activates.
+4. From the **Default Pod Security Policy** drop-down, select the policy you want to apply to the cluster.
-4. From **Default Pod Security Policy**, select the PSP 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 PSP is applied to the cluster and any projects within the cluster.
+**Result:** The pod security policy is applied to the cluster and any projects within the cluster.
->**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.
+>**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.
-### Node pools
+### 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.
+
+>**Note:** These options are not available for imported clusters or hosted Kubernetes clusters.
+
+Options for RKE Clusters
+
+
+
+Option | Description |
+---------|----------|
+ Kubernetes Version | The version of Kubernetes installed on each cluster node. For more detail, see [Upgrading Kubernetes](#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. |
+ Metrics Server Monitoring | Each cloud provider capable of launching a cluster using RKE can collect metrics and monitor for your cluster nodes. Enable this option to view your node metrics from your cloud provider's portal. |
+ Pod Security Policy Support | Enables [pod security policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/) for the cluster. After enabling this option, choose a policy using the **Default Pod Security Policy** drop-down. |
+ Docker version on nodes | Configures whether nodes are allowed to run versions of Docker that Rancher doesn't officially support. If you choose to require a [supported Docker version]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb/#software), Rancher will stop pods from running on nodes that don't have a supported Docker version installed. |
+ Docker Root Directory | The directory on your cluster nodes where you've installed Docker. If you install Docker on your nodes to a non-default directory, update this path. |
+ 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
+
+>**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`.
+
+Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available]({{< baseurl >}}/rke/v0.1.x/en/config-options/) in an RKE installation.
+
+- To edit an RKE config file directly from the Rancher UI, click **Edit as YAML**.
+- To read from an existing RKE file, click **Read from File**.
+
+
+
+For an example of RKE config file syntax, see the [RKE documentation]({{< baseurl >}}/rke/v0.1.x/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.
-Changing the nodes in a RKE cluster
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
new file mode 100644
index 00000000000..f3c06af67a8
--- /dev/null
+++ b/content/rancher/v2.x/en/k8s-in-rancher/horitzontal-pod-autoscaler/_index.md
@@ -0,0 +1,866 @@
+---
+title: Horizontal Pod Autoscaler
+weight: 2300
+---
+
+Using the Kubernetes [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) feature (HPA), you can configure your cluster to automatically scale the services it's running up or down.
+
+### Why Use Horizontal Pod Autoscaler?
+
+Using HPA, you can automatically scale the number of pods within a replication controller, deployment, or replica set up or down. HPA automatically scales the number of pods that are running for maximum efficiency. Factors that affect the number of pods include:
+
+- A minimum and maximum number of pods allowed to run, as defined by the user.
+- Observed CPU/memory use, as reported in resource metrics.
+- Custom metrics provided by third-party metrics application like Prometheus, Datadog, etc.
+
+HPA improves your services by:
+
+- Releasing hardware resources that would otherwise be wasted by an excessive number of pods.
+- Increase/decrease performance as needed to accomplish service level agreements.
+
+### How HPA Works
+
+
+
+HPA is implemented as a control loop, with a period controlled by the `kube-controller-manager` flags below:
+
+
+Flag | Default | Description |
+---------|----------|----------|
+ `--horizontal-pod-autoscaler-sync-period` | `30s` | How often HPA audits resource/custom metrics in a deployment.
+ `--horizontal-pod-autoscaler-downscale-delay` | `5m0s` | Following completion of a downscale operation, how long HPA must wait before launching another downscale operations.
+ `--horizontal-pod-autoscaler-upscale-delay` | `3m0s` | Following completion of an upscale operation, how long HPA must wait before launching another upscale operation.
+
+
+For full documentation on HPA, refer to the [Kubernetes Documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
+
+### Horizontal Pod Autoscaler API Objects
+
+HPA is an API resource in the Kubernetes `autoscaling` API group. The current stable version is `autoscaling/v1`, which only includes support for CPU autoscaling. To get additional support for scaling based on memory and custom metrics, use the beta version instead: `autoscaling/v2beta1`.
+
+For more information about the HPA API object, see the [HPA GitHub Readme](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object).
+
+### kubectl Commands
+
+You can create, manage, and delete HPAs using kubectl:
+
+- Creating HPA
+
+ - With manifest: `kubectl create -f `
+
+ - Without manifest (Just support CPU): `kubectl autoscale deployment hello-world --min=2 --max=5 --cpu-percent=50`
+
+- Getting HPA info
+
+ - Basic: `kubectl get hpa hello-world`
+
+ - Detailed description: `kubectl describe hpa hello-world`
+
+- Deleting HPA
+
+ - `kubectl delete hpa hello-world`
+
+### HPA Manifest Definition Example
+
+The following snippet demonstrates use of different directives in an HPA manifest. See the list below the sample to understand the purpose of each directive.
+
+```yml
+apiVersion: autoscaling/v2beta1
+kind: HorizontalPodAutoscaler
+metadata:
+ name: hello-world
+spec:
+ scaleTargetRef:
+ apiVersion: extensions/v1beta1
+ kind: Deployment
+ name: hello-world
+ minReplicas: 1
+ maxReplicas: 10
+ metrics:
+ - type: Resource
+ resource:
+ name: cpu
+ targetAverageUtilization: 50
+ - type: Resource
+ resource:
+ name: memory
+ targetAverageValue: 100Mi
+```
+
+
+Directive | Description
+---------|----------|
+ `apiVersion: autoscaling/v2beta1` | The version of the Kubernetes `autoscaling` API group in use. This example manifest uses the beta version, so scaling by CPU and memory is enabled. |
+ `name: hello-world` | Indicates that HPA is performing autoscaling for the `hello-word` deployment. |
+ `minReplicas: 1` | Indicates that the minimum number of replicas running can't go below 1. |
+ `maxReplicas: 10` | Indicates the maximum number of replicas in the deployment can't go above 10.
+ `targetAverageUtilization: 50` | Indicates the deployment will scale pods up when the average running pod uses more than 50% of its requested CPU.
+ `targetAverageValue: 100Mi` | Indicates the deployment will scale pods up when the average running pod uses more that 100Mi of memory.
+
+
+### Installation
+
+Before you can use HPA in your Kubernetes cluster, you must fulfill some requirements.
+
+#### Requirements
+
+Be sure that your Kubernetes cluster services are running with these flags at minimum:
+
+- kube-api: `requestheader-client-ca-file`
+- kubelet: `read-only-port` at 10255
+- kube-controller: Optional, just needed if distinct values than default are required.
+
+ - `horizontal-pod-autoscaler-downscale-delay: "5m0s"`
+ - `horizontal-pod-autoscaler-upscale-delay: "3m0s"`
+ - `horizontal-pod-autoscaler-sync-period: "30s"`
+
+For an RKE Kubernetes cluster definition, add this snippet in the `services` section. To add this snippet using the Rancher v2.0 UI, open the **Clusters** view and select **Ellipsis (...) > Edit** for the cluster in which you want to use HPA. Then, from **Cluster Options**, click **Edit as YAML**. Add the following snippet to the `services` section:
+
+```
+services:
+...
+ kube-api:
+ extra_args:
+ requestheader-client-ca-file: "/etc/kubernetes/ssl/kube-ca.pem"
+ kube-controller:
+ extra_args:
+ horizontal-pod-autoscaler-downscale-delay: "5m0s"
+ horizontal-pod-autoscaler-upscale-delay: "1m0s"
+ horizontal-pod-autoscaler-sync-period: "30s"
+ kubelet:
+ extra_args:
+ read-only-port: 10255
+```
+
+Once the Kubernetes cluster is configured and deployed, you can deploy metrics services.
+
+>**Note:** kubectl command samples in the sections that follow were tested in a cluster running Rancher v2.0.6 and Kubernetes v1.10.1.
+
+#### Configuring HPA to Scale Using Resource Metrics
+
+To create HPA resources based on resource metrics such as CPU and memory use, you need to deploy the `metrics-server` package in the `kube-system` namespace of your Kubernetes cluster. This deployment allows HPA to consume the `metrics.k8s.io` API.
+
+>**Prerequisite:** You must be running kubectl 1.8 or later.
+
+1. Connect to your Kubernetes cluster using kubectl.
+
+1. Clone the GitHub `metrics-server` repo:
+ ```
+ # git clone https://github.com/kubernetes-incubator/metrics-server
+ ```
+
+1. Install the `metrics-server` package.
+ ```
+ # kubectl create -f metrics-server/deploy/1.8+/
+ ```
+
+1. Check that `metrics-server` is running properly. Check the service pod and logs in the `kube-system` namespace.
+
+ 1. Check the service pod for a status of `running`. Enter the following command:
+ ```
+ # kubectl get pods -n kube-system
+ ```
+ Then check for the status of `running`.
+ ```
+ NAME READY STATUS RESTARTS AGE
+ ...
+ metrics-server-6fbfb84cdd-t2fk9 1/1 Running 0 8h
+ ...
+ ```
+ 1. Check the service logs for service availability. Enter the following command:
+ ```
+ # kubectl -n kube-system logs metrics-server-6fbfb84cdd-t2fk9
+ ```
+ Then review the log to confirm that that the `metrics-server` package is running.
+ {{% accordion id="metrics-server-run-check" label="Metrics Server Log Output" %}}
+ I0723 08:09:56.193136 1 heapster.go:71] /metrics-server --source=kubernetes.summary_api:''
+ I0723 08:09:56.193574 1 heapster.go:72] Metrics Server version v0.2.1
+ I0723 08:09:56.194480 1 configs.go:61] Using Kubernetes client with master "https://10.43.0.1:443" and version
+ I0723 08:09:56.194501 1 configs.go:62] Using kubelet port 10255
+ I0723 08:09:56.198612 1 heapster.go:128] Starting with Metric Sink
+ I0723 08:09:56.780114 1 serving.go:308] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key)
+ I0723 08:09:57.391518 1 heapster.go:101] Starting Heapster API server...
+ [restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] listing is available at https:///swaggerapi
+ [restful] 2018/07/23 08:09:57 log.go:33: [restful/swagger] https:///swaggerui/ is mapped to folder /swagger-ui/
+ I0723 08:09:57.394080 1 serve.go:85] Serving securely on 0.0.0.0:443
+ {{% /accordion %}}
+
+
+1. Check that the metrics api is accessible from kubectl.
+
+ - If you are accessing the cluster directly, enter your Server URL in the kubectl config in the following format: `https://:6443`.
+ ```
+ # kubectl get --raw /apis/metrics.k8s.io/v1beta1
+ ```
+ If the the API is working correctly, you should receive output similar to the output below.
+ ```
+ {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}
+ ```
+
+ - If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https:///k8s/clusters/`. Add the suffix `/k8s/clusters/` to API path.
+ ```
+ # kubectl get --raw /k8s/clusters//apis/metrics.k8s.io/v1beta1
+ ```
+ If the the API is working correctly, you should receive output similar to the output below.
+ ```
+ {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"metrics.k8s.io/v1beta1","resources":[{"name":"nodes","singularName":"","namespaced":false,"kind":"NodeMetrics","verbs":["get","list"]},{"name":"pods","singularName":"","namespaced":true,"kind":"PodMetrics","verbs":["get","list"]}]}
+ ```
+
+#### Configuring HPA to Scale Using Custom Metrics (Prometheus)
+
+You can also configure HPA to autoscale based on custom metrics provided by third-party software. The most common use case for autoscaling using third-party software is based on application-level metrics (i.e., HTTP requests per second). HPA uses the `custom.metrics.k8s.io` API to consume these metrics. This API is enabled by deploying a custom metrics adapter for the metrics collection solution.
+
+For this example, we are going to use [Prometheus](https://prometheus.io/). We are beginning with the following assumptions:
+
+- Prometheus is deployed in the cluster.
+- Prometheus is configured correctly and collecting proper metrics from pods, nodes, namespaces, etc.
+- Prometheus is exposed at the following URL and port: `http://prometheus.mycompany.io:80`
+
+Prometheus is available for deployment in the Rancher v2.0 catalog. Deploy it from Rancher catalog if it isn't already running in your cluster.
+
+For HPA to use custom metrics from Prometheus, package [k8s-prometheus-adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter) is required in the `kube-system` namespace of your cluster. To install `k8s-prometheus-adapter`, we are using the Helm chart available at [banzai-charts](https://github.com/banzaicloud/banzai-charts).
+
+1. Initialize Helm in your cluster.
+ ```
+ # kubectl -n kube-system create serviceaccount tiller
+ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
+ helm init --service-account tiller
+ ```
+
+1. Clone the `banzai-charts` repo from GitHub:
+ ```
+ # git clone https://github.com/banzaicloud/banzai-charts
+ ```
+
+1. Install the `prometheus-adapter` chart, specifying the Prometheus URL and port number.
+ ```
+ # helm install --name prometheus-adapter banzai-charts/prometheus-adapter --set prometheus.url="http://prometheus.mycompany.io",prometheus.port="80" --namespace kube-system
+ ```
+
+1. Check that `prometheus-adapter` is running properly. Check the service pod and logs in the `kube-system` namespace.
+
+ 1. Check that the service pod is `Running`. Enter the following command.
+ ```
+ # kubectl get pods -n kube-system
+ ```
+ From the resulting output, look for a status of `Running`.
+ ```
+ NAME READY STATUS RESTARTS AGE
+ ...
+ prometheus-adapter-prometheus-adapter-568674d97f-hbzfx 1/1 Running 0 7h
+ ...
+ ```
+ 1. Check the service logs to make sure the service is running correctly by entering the command that follows.
+ ```
+ # kubectl logs prometheus-adapter-prometheus-adapter-568674d97f-hbzfx -n kube-system
+ ```
+ Then review the log output to confirm the service is running.
+ {{% accordion id="prometheus-logs" label="Prometheus Adaptor Logs" %}}
+ ...
+ I0724 10:18:45.696679 1 round_trippers.go:436] GET https://10.43.0.1:443/api/v1/namespaces/default/pods?labelSelector=app%3Dhello-world 200 OK in 2 milliseconds
+ I0724 10:18:45.696695 1 round_trippers.go:442] Response Headers:
+ I0724 10:18:45.696699 1 round_trippers.go:445] Date: Tue, 24 Jul 2018 10:18:45 GMT
+ I0724 10:18:45.696703 1 round_trippers.go:445] Content-Type: application/json
+ I0724 10:18:45.696706 1 round_trippers.go:445] Content-Length: 2581
+ I0724 10:18:45.696766 1 request.go:836] Response Body: {"kind":"PodList","apiVersion":"v1","metadata":{"selfLink":"/api/v1/namespaces/default/pods","resourceVersion":"6237"},"items":[{"metadata":{"name":"hello-world-54764dfbf8-q6l82","generateName":"hello-world-54764dfbf8-","namespace":"default","selfLink":"/api/v1/namespaces/default/pods/hello-world-54764dfbf8-q6l82","uid":"484cb929-8f29-11e8-99d2-067cac34e79c","resourceVersion":"4066","creationTimestamp":"2018-07-24T10:06:50Z","labels":{"app":"hello-world","pod-template-hash":"1032089694"},"annotations":{"cni.projectcalico.org/podIP":"10.42.0.7/32"},"ownerReferences":[{"apiVersion":"extensions/v1beta1","kind":"ReplicaSet","name":"hello-world-54764dfbf8","uid":"4849b9b1-8f29-11e8-99d2-067cac34e79c","controller":true,"blockOwnerDeletion":true}]},"spec":{"volumes":[{"name":"default-token-ncvts","secret":{"secretName":"default-token-ncvts","defaultMode":420}}],"containers":[{"name":"hello-world","image":"rancher/hello-world","ports":[{"containerPort":80,"protocol":"TCP"}],"resources":{"requests":{"cpu":"500m","memory":"64Mi"}},"volumeMounts":[{"name":"default-token-ncvts","readOnly":true,"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount"}],"terminationMessagePath":"/dev/termination-log","terminationMessagePolicy":"File","imagePullPolicy":"Always"}],"restartPolicy":"Always","terminationGracePeriodSeconds":30,"dnsPolicy":"ClusterFirst","serviceAccountName":"default","serviceAccount":"default","nodeName":"34.220.18.140","securityContext":{},"schedulerName":"default-scheduler","tolerations":[{"key":"node.kubernetes.io/not-ready","operator":"Exists","effect":"NoExecute","tolerationSeconds":300},{"key":"node.kubernetes.io/unreachable","operator":"Exists","effect":"NoExecute","tolerationSeconds":300}]},"status":{"phase":"Running","conditions":[{"type":"Initialized","status":"True","lastProbeTime":null,"lastTransitionTime":"2018-07-24T10:06:50Z"},{"type":"Ready","status":"True","lastProbeTime":null,"lastTransitionTime":"2018-07-24T10:06:54Z"},{"type":"PodScheduled","status":"True","lastProbeTime":null,"lastTransitionTime":"2018-07-24T10:06:50Z"}],"hostIP":"34.220.18.140","podIP":"10.42.0.7","startTime":"2018-07-24T10:06:50Z","containerStatuses":[{"name":"hello-world","state":{"running":{"startedAt":"2018-07-24T10:06:54Z"}},"lastState":{},"ready":true,"restartCount":0,"image":"rancher/hello-world:latest","imageID":"docker-pullable://rancher/hello-world@sha256:4b1559cb4b57ca36fa2b313a3c7dde774801aa3a2047930d94e11a45168bc053","containerID":"docker://cce4df5fc0408f03d4adf82c90de222f64c302bf7a04be1c82d584ec31530773"}],"qosClass":"Burstable"}}]}
+ I0724 10:18:45.699525 1 api.go:74] GET http://prometheus-server.prometheus.34.220.18.140.xip.io/api/v1/query?query=sum%28rate%28container_fs_read_seconds_total%7Bpod_name%3D%22hello-world-54764dfbf8-q6l82%22%2Ccontainer_name%21%3D%22POD%22%2Cnamespace%3D%22default%22%7D%5B5m%5D%29%29+by+%28pod_name%29&time=1532427525.697 200 OK
+ I0724 10:18:45.699620 1 api.go:93] Response Body: {"status":"success","data":{"resultType":"vector","result":[{"metric":{"pod_name":"hello-world-54764dfbf8-q6l82"},"value":[1532427525.697,"0"]}]}}
+ I0724 10:18:45.699939 1 wrap.go:42] GET /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/%2A/fs_read?labelSelector=app%3Dhello-world: (12.431262ms) 200 [[kube-controller-manager/v1.10.1 (linux/amd64) kubernetes/d4ab475/system:serviceaccount:kube-system:horizontal-pod-autoscaler] 10.42.0.0:24268]
+ I0724 10:18:51.727845 1 request.go:836] Request Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1beta1","metadata":{"creationTimestamp":null},"spec":{"nonResourceAttributes":{"path":"/","verb":"get"},"user":"system:anonymous","group":["system:unauthenticated"]},"status":{"allowed":false}}
+ ...
+ {{% /accordion %}}
+
+
+
+1. Check that the metrics API is accessible from kubectl.
+
+ - If you are accessing the cluster directly, enter your Server URL in the kubectl config in the following format: `https://:6443`.
+ ```
+ # kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
+ ```
+ If the API is accessible, you should receive output that's similar to what follows.
+ {{% accordion id="custom-metrics-api-response" label="API Response" %}}
+ {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
+ {{% /accordion %}}
+
+ - If you are accessing the cluster through Rancher, enter your Server URL in the kubectl config in the following format: `https:///k8s/clusters/`. Add the suffix `/k8s/clusters/` to API path.
+ ```
+ # kubectl get --raw /k8s/clusters//apis/custom.metrics.k8s.io/v1beta1
+ ```
+ If the API is accessible, you should receive output that's similar to what follows.
+ {{% accordion id="custom-metrics-api-response-rancher" label="API Response" %}}
+ {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"custom.metrics.k8s.io/v1beta1","resources":[{"name":"pods/fs_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_rss","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_period","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_read","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_user","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/last_seen","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/tasks_state","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_quota","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/start_time_seconds","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_write","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_cache","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_cfs_throttled_periods","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_working_set_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_udp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes_free","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_inodes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_time_weighted","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failures","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_swap","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_cpu_shares","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_swap_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_io_current","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_failcnt","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_writes_merged","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/network_tcp_usage","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/memory_max_usage_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/spec_memory_reservation_limit_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_load_average_10s","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/cpu_system","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_reads_bytes","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]},{"name":"pods/fs_sector_reads","singularName":"","namespaced":true,"kind":"MetricValueList","verbs":["get"]}]}
+ {{% /accordion %}}
+
+
+#### Assigning Additional Required Roles to Your HPA
+
+By default, HPA reads resource and custom metrics with the user `system:anonymous`. Assign `system:anonymous` the the `view-resource-metrics` and `view-custom-metrics` in the ClusterRole and ClusterRoleBindings manifests. These roles are used to access metrics.
+
+To do it, follow these steps:
+
+1. Configure kubectl to connect to your cluster.
+
+1. Copy the ClusterRole and ClusterRoleBinding manifest for the type of metrics you're using for your HPA.
+ {{% accordion id="cluster-role-resource-metrics" label="Resource Metrics: ApiGroups resource.metrics.k8s.io" %}}
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRole
+ metadata:
+ name: view-resource-metrics
+ rules:
+ - apiGroups:
+ - metrics.k8s.io
+ resources:
+ - pods
+ - nodes
+ verbs:
+ - get
+ - list
+ - watch
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRoleBinding
+ metadata:
+ name: view-resource-metrics
+ roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: ClusterRole
+ name: view-resource-metrics
+ subjects:
+ - apiGroup: rbac.authorization.k8s.io
+ kind: User
+ name: system:anonymous
+ {{% /accordion %}}
+{{% accordion id="cluster-role-custom-resources" label="Custom Metrics: ApiGroups custom.metrics.k8s.io" %}}
+
+ ```
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRole
+ metadata:
+ name: view-custom-metrics
+ rules:
+ - apiGroups:
+ - custom.metrics.k8s.io
+ resources:
+ - "*"
+ verbs:
+ - get
+ - list
+ - watch
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRoleBinding
+ metadata:
+ name: view-custom-metrics
+ roleRef:
+ apiGroup: rbac.authorization.k8s.io
+ kind: ClusterRole
+ name: view-custom-metrics
+ subjects:
+ - apiGroup: rbac.authorization.k8s.io
+ kind: User
+ name: system:anonymous
+ ```
+{{% /accordion %}}
+1. Create them in your cluster using one of the follow commands, depending on the metrics you're using.
+ ```
+ # kubectl create -f
+ # kubectl create -f
+ ```
+
+
+### Testing HPAs with a Service Deployment
+
+For HPA to work correctly, service deployments should have resources request definitions for containers. Follow this hello-world example to test if HPA is working correctly.
+
+1. Configure kubectl to connect to your Kubernetes cluster.
+
+2. Copy the `hello-world` deployment manifest below.
+{{% accordion id="hello-world" label="Hello World Manifest" %}}
+ apiVersion: apps/v1beta2
+ kind: Deployment
+ metadata:
+ labels:
+ app: hello-world
+ name: hello-world
+ namespace: default
+ spec:
+ replicas: 1
+ selector:
+ matchLabels:
+ app: hello-world
+ strategy:
+ rollingUpdate:
+ maxSurge: 1
+ maxUnavailable: 0
+ type: RollingUpdate
+ template:
+ metadata:
+ labels:
+ app: hello-world
+ spec:
+ containers:
+ - image: rancher/hello-world
+ imagePullPolicy: Always
+ name: hello-world
+ resources:
+ requests:
+ cpu: 500m
+ memory: 64Mi
+ ports:
+ - containerPort: 80
+ protocol: TCP
+ restartPolicy: Always
+ ---
+ apiVersion: v1
+ kind: Service
+ metadata:
+ name: hello-world
+ namespace: default
+ spec:
+ ports:
+ - port: 80
+ protocol: TCP
+ targetPort: 80
+ selector:
+ app: hello-world
+{{% /accordion %}}
+
+
+
+1. Deploy it to your cluster.
+
+ ```
+ # kubectl create -f
+ ```
+
+1. Copy one of the HPAs below based on the metric type you're using:
+ {{% accordion id="service-deployment-resource-metrics" label="Hello World HPA: Resource Metrics" %}}
+ apiVersion: autoscaling/v2beta1
+ kind: HorizontalPodAutoscaler
+ metadata:
+ name: hello-world
+ namespace: default
+ spec:
+ scaleTargetRef:
+ apiVersion: extensions/v1beta1
+ kind: Deployment
+ name: hello-world
+ minReplicas: 1
+ maxReplicas: 10
+ metrics:
+ - type: Resource
+ resource:
+ name: cpu
+ targetAverageUtilization: 50
+ - type: Resource
+ resource:
+ name: memory
+ targetAverageValue: 1000Mi
+ {{% /accordion %}}
+ {{% accordion id="service-deployment-custom-metrics" label="Hello World HPA: Custom Metrics" %}}
+ apiVersion: autoscaling/v2beta1
+ kind: HorizontalPodAutoscaler
+ metadata:
+ name: hello-world
+ namespace: default
+ spec:
+ scaleTargetRef:
+ apiVersion: extensions/v1beta1
+ kind: Deployment
+ name: hello-world
+ minReplicas: 1
+ maxReplicas: 10
+ metrics:
+ - type: Resource
+ resource:
+ name: cpu
+ targetAverageUtilization: 50
+ - type: Resource
+ resource:
+ name: memory
+ targetAverageValue: 100Mi
+ - type: Pods
+ pods:
+ metricName: cpu_system
+ targetAverageValue: 20m
+ {{% /accordion %}}
+
+1. View the HPA info and description. Confirm that metric data is shown.
+ {{% accordion id="hpa-info-resource-metrics" label="Resource Metrics" %}}
+1. Enter the following command.
+ ```
+ # kubectl get hpa
+ ```
+ You should receive the output that follows:
+ ```
+ NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
+ hello-world Deployment/hello-world 1253376 / 100Mi, 0% / 50% 1 10 1 6m
+ # kubectl describe hpa
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Mon, 23 Jul 2018 20:21:16 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 1253376 / 100Mi
+ resource cpu on pods (as a percentage of request): 0% (0) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ ```
+ {{% /accordion %}}
+ {{% accordion id="hpa-info-custom-metrics" label="Custom Metrics" %}}
+1. Enter the following command.
+ ```
+ # kubectl describe hpa
+ ```
+ You should receive the output that follows.
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Tue, 24 Jul 2018 18:36:28 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 3514368 / 100Mi
+ "cpu_system" on pods: 0 / 20m
+ resource cpu on pods (as a percentage of request): 0% (0) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True ReadyForNewScale the last scale time was sufficiently old as to warrant a new scale
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ ```
+ {{% /accordion %}}
+
+
+1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).
+
+1. Test that pod autoscaling works as intended.
+ **To Test Autoscaling Using Resource Metrics:**
+ {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
+Use your load testing tool to to scale up to two pods based on CPU Usage.
+
+1. View your HPA.
+ ```
+ # kubectl describe hpa
+ ```
+ You should receive output similar to what follows.
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 10928128 / 100Mi
+ resource cpu on pods (as a percentage of request): 56% (280m) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
+ ```
+1. Enter the following command to confirm you've scaled to two pods.
+ ```
+ # 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.
+
+1. Enter the following command.
+ ```
+ # kubectl describe hpa
+ ```
+ You should receive output similar to what follows
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 9424896 / 100Mi
+ resource cpu on pods (as a percentage of request): 66% (333m) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal SuccessfulRescale 4m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
+ Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
+ ```
+2. Enter the following command to confirm three pods are running.
+ ```
+ # kubectl get pods
+ ```
+ You should receive output similar to what follows.
+ ```
+ NAME READY STATUS RESTARTS AGE
+ hello-world-54764dfbf8-f46kh 0/1 Running 0 1m
+ hello-world-54764dfbf8-k8ph2 1/1 Running 0 5m
+ hello-world-54764dfbf8-q6l4v 1/1 Running 0 3h
+ ```
+ {{% /accordion %}}
+ {{% accordion id="observe-downscale-1-pod" label="Downscale to 1 Pod: All Metrics Below Target" %}}
+Use your load testing to to scale down to 1 pod when all metrics are below target for `horizontal-pod-autoscaler-downscale-delay` (5 minutes by default).
+
+1. Enter the following command.
+ ```
+ # kubectl describe hpa
+ ```
+ You should receive output similar to what follows.
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Mon, 23 Jul 2018 22:22:04 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 10070016 / 100Mi
+ resource cpu on pods (as a percentage of request): 0% (0) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
+ Normal SuccessfulRescale 6m horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target
+ Normal SuccessfulRescale 1s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
+ ```
+ {{% /accordion %}}
+
+**To Test Autoscaling Using Custom Metrics:**
+ {{% accordion id="custom-observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
+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.
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 8159232 / 100Mi
+ "cpu_system" on pods: 7m / 20m
+ resource cpu on pods (as a percentage of request): 64% (321m) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 2
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal SuccessfulRescale 16s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
+ ```
+1. Enter the following command to confirm two pods are running.
+ ```
+ # 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
+ ```
+ {{% /accordion %}}
+{{% accordion id="observe-upscale-3-pods-cpu-cooldown-2" label="Upscale to 3 Pods: CPU Usage Up to Target" %}}
+Use your load testing tool to scale up to three pods when the cpu_system usage limit is up to target.
+
+1. Enter the following command.
+ ```
+ # kubectl describe hpa
+ ```
+ You should receive output similar to what follows:
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 8374272 / 100Mi
+ "cpu_system" on pods: 27m / 20m
+ resource cpu on pods (as a percentage of request): 71% (357m) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
+ Normal SuccessfulRescale 3s horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
+ ```
+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
+ NAME READY STATUS RESTARTS AGE
+ hello-world-54764dfbf8-5pfdr 1/1 Running 0 3m
+ hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
+ hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
+ ```
+{{% /accordion %}}
+{{% accordion id="observe-upscale-4-pods" label="Upscale to 4 Pods: CPU Usage Up to Target" %}}
+Use your load testing tool to upscale to four pods based on CPU usage. `horizontal-pod-autoscaler-upscale-delay` is set to three minutes by default.
+
+1. Enter the following command.
+ ```
+ # kubectl describe hpa
+ ```
+ You should receive output similar to what follows.
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 8374272 / 100Mi
+ "cpu_system" on pods: 27m / 20m
+ resource cpu on pods (as a percentage of request): 71% (357m) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 3
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from cpu resource utilization (percentage of request)
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
+ Normal SuccessfulRescale 3m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
+ Normal SuccessfulRescale 4s horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
+ ```
+1. Enter the following command to confirm four pods are running.
+ ```
+ # kubectl get pods
+ ```
+ You should receive output similar to what follows.
+ ```
+ NAME READY STATUS RESTARTS AGE
+ hello-world-54764dfbf8-2p9xb 1/1 Running 0 5m
+ hello-world-54764dfbf8-5pfdr 1/1 Running 0 2m
+ hello-world-54764dfbf8-m2hrl 1/1 Running 0 1s
+ hello-world-54764dfbf8-q6l82 1/1 Running 0 6h
+ ```
+{{% /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`.
+
+1. Enter the following command.
+ ```
+ # kubectl describe hpa
+ ```
+ You should receive similar output to what follows.
+ ```
+ Name: hello-world
+ Namespace: default
+ Labels:
+ Annotations:
+ CreationTimestamp: Tue, 24 Jul 2018 18:01:11 +0200
+ Reference: Deployment/hello-world
+ Metrics: ( current / target )
+ resource memory on pods: 8101888 / 100Mi
+ "cpu_system" on pods: 8m / 20m
+ resource cpu on pods (as a percentage of request): 0% (0) / 50%
+ Min replicas: 1
+ Max replicas: 10
+ Conditions:
+ Type Status Reason Message
+ ---- ------ ------ -------
+ AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 1
+ ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from memory resource
+ ScalingLimited False DesiredWithinRange the desired count is within the acceptable range
+ Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal SuccessfulRescale 10m horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target
+ Normal SuccessfulRescale 8m horizontal-pod-autoscaler New size: 3; reason: pods metric cpu_system above target
+ Normal SuccessfulRescale 5m horizontal-pod-autoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target
+ Normal SuccessfulRescale 13s horizontal-pod-autoscaler New size: 1; reason: All metrics below target
+ ```
+1. Enter the following command to confirm a single pods is running.
+ ```
+ # 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 %}}
+
+### Conclusion
+
+Horizontal Pod Autoscaling is a great way to automate the number of pod you have deployed for maximum efficency. You can use it to accomodate deployment scale to real service load and to meet service level agreements.
+
+By adjusting the `horizontal-pod-autoscaler-downscale-delay` and `horizontal-pod-autoscaler-upscale-delay` flag values, you can adjust the time needed before kube-controller scales your pods up or down.
+
+We've demonstrated how to setup an HPA based on custom metrics provided by Prometheus. We used the `cpu_system` metric as an example, but you can use other metrics that monitor service performance, like `http_request_number`, `http_response_time`, etc.
+
+>**Note:**To facilitate HPA use, we are working to integrate metric-server as an addon on RKE cluster deployments. This feature is included in RKE v0.1.9-rc2 for testing, but is not officially supported as of yet. It would be supported at rke v0.1.9.
\ 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 863a9c84a6e..8caf834db7e 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
@@ -13,7 +13,7 @@ Ingress can be added for workloads to provide load balancing, SSL termination an
1. Enter a **Name** for the ingress.
-1. Select an existing **Namespace** from the drop-down list. Alternatively, you can create a new namespace on the fly by clicking **Add to a new namespace**.
+1. Select an existing **Namespace** from the drop-down list. Alternatively, you can create a new [namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) on the fly by clicking **Add to a new namespace**.
1. Create ingress forwarding **Rules**.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
index a6bb609e2eb..fd379c81c4b 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/_index.md
@@ -9,19 +9,31 @@ aliases:
## Projects
-_Projects_ are objects that captures a set of policies for a set of namespaces. They are a new concept introduced by Rancher, and they are not a native Kubernetes construct.
+_Projects_ are organizational objects introduced in Rancher that ease the administrative burden of your cluster. You can use projects to support multi-tenancy.
+
+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:
+
+- 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!
+
+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.
You can use projects to perform actions like:
-- Assigning users to access to a group of namespaces (i.e., [project membership]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members))
-- Assigning users specific roles in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/). Policies include Kubernetes Role-Based Access Control (RBAC) policies.
-- Assigning Pod Security Policies.
+- Assign users access to a group of namespaces (i.e., [project membership]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/project-members)).
+- Assign users specific roles in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/).
+- Assign resources to the project.
+- Assign Pod Security Policies.
+
When you create a cluster, two project are automatically created within it:
- [Default Project](#default-project)
- [System Project](#system-project)
+
### Default Project
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.
@@ -43,29 +55,23 @@ The `system` project:
>**Note:** In clusters where both:
>
-> - The [Canal network plug-in]({{< baseurl >}}\rancher\v2.x\en\cluster-provisioning\rke-clusters\options\#canal) is in use.
+> - The [Canal network plug-in]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#canal) is in use.
> - The Project Network Isolation option is enabled.
>
>The `system` project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health.
-## Authorization
+### Authorization
Non-administrative users are only authorized for project access after an administrator 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.
-## Namespaces
-
-Kubernetes resources belong to specific namespaces. Rancher 2.0 relies on namespaces to isolate resources among users and apps. When the user deploys an app from the catalog, for example, he can choose to deploy that app into its own namespace, so that resource names in one app will not conflict with resource names in another. Namespaces must be globally unique. It is often difficult for users to pick unique namespace names. Rancher therefore encourages the pattern where users work with projects, and the system generates unique namespace names automatically.
-
-For more information, see the [Kubernetes Namespaces Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
-
-## 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.
@@ -75,9 +81,9 @@ For more information, see the [Kubernetes Namespaces Documentation](https://kube
1. **Optional:** Select a **Pod Security Policy**. 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.
+ - Override the cluster's default PSP.
+ - Apply the PSP to the project.
+ - Apply the PSP to any namespaces you add to the project later.
>**Note:** This option is only available if you've already created a Pod Security Policy. For instruction, see [Creating Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/).
@@ -101,14 +107,13 @@ For more information, see the [Kubernetes Namespaces Documentation](https://kube
1. To add more members, repeat substeps a—c.
-
1. Click **Create**.
**Result:** Your project is created. You can view it from the cluster's **Projects/Namespaces** view.
-## Switching Projects
+## Switching Clusters/Projects
-To switch between clusters, use the **Global** drop-down available in the main menu.
+To switch between clusters and projects, use the **Global** drop-down available in the main menu.
@@ -116,3 +121,54 @@ 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
+
+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.
+
+Although you assign resources at the project level so that each namespace can in the project can use them, you can override this inheritance by assigning resources explicitly to a namespace.
+
+Resources that you can assign directly to namespaces include:
+
+- [Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/)
+- [Load Balancers/Ingress]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/)
+- [Service Discovery Records]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/service-discovery/)
+- [Persistent Volume Claims]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/)
+- [Certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/)
+- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps/)
+- [Registries]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/registries/)
+- [Secrets]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/)
+
+>**Note:** Although you can assign role-based access to namespaces in the base version of Kubernetes, you cannot assign roles to namespaces in Rancher. Instead, assign role-based access at the project level.
+
+### Creating Namespaces
+
+Create a new namespace to isolate apps and resources in a project.
+
+>**Tip:** When working with project resources that you can assign to a namespace (i.e., [workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/), [certificates]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/certificates/), [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/configmaps), etc.) you can create a namespace on the fly.
+
+1. From the **Global** view, open the project where you want to create a namespace.
+
+ >**Tip:** As a best practice, we recommend creating namespaces from the project level. However, cluster owners and members can can create them from the cluster level as well.
+
+1. From the main menu, select **Namespace**. The click **Add Namespace**.
+
+1. Enter a **Name** and then click **Create**.
+
+**Result:** Your namespace is added to the project. You can begin assigning cluster resources to the namespace.
+
+### Moving Namespaces to Another Project
+
+Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.
+
+1. From the **Global** view, open the cluster that contains the namespace you want to move.
+
+1. From the main menu, select **Projects/Namespaces**.
+
+1. Select the namespace(s) that you want to move to a different project. Then click **Move**. You can move multiple namespaces at one.
+
+ >**Note:** Don't move the namespaces in the `System` project. Moving these namespaces can adversely affect cluster networking.
+
+1. Choose a new project for the new namespace and then click **Move**. Alternatively, you can remove the namespace from all projects by selecting **None**.
+
+**Result:** Your namespace is moved to a different project (or is unattached from all projects). If any project resources are attached to the namespace, the namespace releases them and then attached resources from the new project.
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 7a01092cee4..08cb22bfec2 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
@@ -23,7 +23,7 @@ Registries are secrets containing credentials used to authenticate with [private
>**Note:** Kubernetes classifies secrets, certificates, ConfigMaps, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace.
-1. Select a **Scope** for the registry.
+1. Select a **Scope** for the registry. You can either make the registry available for the entire project or a single [namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces).
1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry.
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 6d9521ffcd7..284ee126dfa 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
@@ -22,7 +22,7 @@ When creating a secret, you can make it available for any deployment within a pr
>**Note:** Kubernetes classifies secrets, certificates, ConfigMaps, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your secret must have a unique name among all secrets within your workspace.
-1. Select a **Scope** for the secret.
+1. Select a **Scope** for the secret. You can either make the registry available for the entire project or a single [namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces).
1. From **Secret Values**, click **Add Secret Value** to add a key value pair. Add as many values as you need.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/service-discovery/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/service-discovery/_index.md
index 6bc3693feb0..39308578377 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/service-discovery/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/service-discovery/_index.md
@@ -5,11 +5,10 @@ aliases:
- /rancher/v2.x/en/tasks/workloads/add-a-dns-record/
---
-
For every workload created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
`..svc.cluster.local`.
-However, you also have the option of creating additional Service Discovery records. You can use these additional records so that a given namespace resolves with one or more external IP addresses, an external hostname, an alias to another DNS record, other workloads, or a set of pods that match a selector that you create.
+However, you also have the option of creating additional Service Discovery records. You can use these additional records so that a given [namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) resolves with one or more external IP addresses, an external hostname, an alias to another DNS record, other workloads, or a set of pods that match a selector that you create.
1. From the **Global** view, open the project that you want to add a DNS record to.
@@ -50,6 +49,4 @@ However, you also have the option of creating additional Service Discovery recor
## Related Links
-### External Links
-
- [Adding entries to Pod /etc/hosts with HostAliases](https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/)
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/_index.md
index 9e4a90d8fa1..bbce60fb424 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/_index.md
@@ -11,72 +11,39 @@ There are two ways to create persistent storage in Kubernetes: Persistent Volume
## Persistent Volumes
-_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to pods later. For example, in Amazon EC2, you might want to create a number of Elastic Block Store (EBS) volumes before you start running your application. Each pre-provisioned EBS volume corresponds to a Kubernetes persistent volume. When the application starts, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.
+_Persistent Volumes_ are pre-provisioned storage volumes that you can bind to pods later. Each pre-provisioned volume corresponds to a Kubernetes persistent volume. When you start your application, it creates Persistent Volume Claims (PVCs) that bind to persistent volumes. A PVC corresponds to a Docker volume. Each PVC binds to one PV that includes the minimum resources that the PVC requires. The following figure illustrates the relationship between pods, PVCs, PVs, and the underlying cloud storage.
Rancher allows you to create PVs at the cluster level and bind them to PVCs later. Volumes are managed on a per-project basis.
-### Adding a Persistent Volume
-
-Your containers can store data on themselves, but if a container fails, that data is lost. To solve this issue, Kubernetes offers _persistent volumes_, which are external storage disks or file systems that your containers can access. If a container crashes, its replacement container can access the data in a persistent volume without any data loss.
-
-Persistent volumes can either be a disk or file system that you host on premise, or they can be hosted by a vendor, such as Amazon EBS or Azure Disk.
-
->**Prerequisites:**
->
->- Working with storage requires the `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference).
->- You must have a storage medium provisioned. For more information, see [Provisioning Storage]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/).
->- Create a storage volume either on premise or in the cloud, using one of the vendor services listed in [Types of Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes).
->- Gather metadata about your storage volume after you create it. You'll need to enter this information into Rancher.
-
-1. From the **Global** view, open the cluster running the containers that you want to add persistent volume storage to.
-
-1. From the main menu, select **Storage > Persistent Volumes**.
-
-1. Click **Add Volume**.
-
-1. Enter a **Name** for the persistent volume.
-
-1. Select the **Volume Plugin** for the disk type or service that you're using.
-
- >**Note:** If the cluster you are adding storage for is a cloud service that also offers cloud storage, you must enable the `cloud provider` option for the cluster, and you must use the service's plug-in to use cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it:
- >
- > - You must enable the `cloud provider` option for the EC2 cluster.
- > - You must use the `Amazon EBS Disk` volume plugin.
-
-1. Enter the **Capacity** of your volume in gigabytes.
-
-1. Complete the **Plugin Configuration** form. Each plugin type requires information specific to the vendor of disk type. For help regarding each plugin's form and the information that's required, refer to the plug-in's vendor documentation.
-
-1. **Optional:** Complete the **Customize** form. This form features:
-
- - [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes):
-
- This options sets how many nodes can access the volume, along with the node read/write permissions. The [Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) includes a table that lists which access modes are supported by the plugins available.
-
- - [Mount Options](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options):
-
- Each volume plugin allows you to specify additional command line options during the mounting process. You can enter these options in the **Mount Option** fields. Consult each plugin's vendor documentation for the mount options available.
-
- - **Assign to Storage Class:**
-
- If you later want to automatically provision persistent volumes identical to the volume that you've specified here, assign it a storage class. Later, when you create a workload, you can assign it a persistent volume claim that references the storage class, which will provision a persistent volume identical to the volume you've specified here.
-
- >**Note:** You must [add a storage class](#adding-storage-classes) before you can assign it to a persistent volume.
-
-1. Click **Save**.
-
-**Result:** Your new persistent volume is created.
-
## Storage Classes
Storage Classes allow you to create PVCs dynamically without having to create PVs first. For example, an Amazon EBS Storage Class will dynamically create EBS volumes and bind them to PVCs. A Storage Class is similar to the notion of a _storage driver_. The following figure illustrates how a PVC creation triggers the dynamic provisioning of an underlying EBS volume.
+
### Storage and Cloud Providers
+When you provision persistent storage for a cluster [launched by RKE]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters), you must host your storage with the same provider that hosts the cluster. For example, if you're hosting your cluster on Amazon EC2, you must host your storage on Amazon EBS. To setup storage for your RKE-launched cluster, you must complete two tasks: enabling the **Cloud Provider** option for your cluster, and adding storage using the same provider.
+
+Enabling Cloud Provider Option/Choosing Storage Provider
+
+
+Before you set up storage for a cluster launched by RKE, make sure that the **Cloud Provider** option for the cluster is enabled. [Cloud providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) are modules that allow you to use the provider's features in Rancher (like provisioning persistent storage).
+
+You can turn on the **Cloud Provider** option in one of two contexts:
+
+- [When provisioning your cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning)
+- [When editing your cluster]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters)
+
+When you begin setting up a [persistent volume](#adding-persistent-volumes) or [storage class](#adding-storage-classes), you can choose the storage plugin or provisioner for your cloud provider.
+
+#### Storage Classes and Cloud Providers
+
+Additionally, storage classes feature a few extra settings for cloud providers.
+
Each storage class contains the fields `provisioner`, `parameters`, and `reclaimPolicy`, which are used when a persistent volume that belongs to the class needs to be dynamically provisioned.
The `provisioner` determines which volume plugin is used to provision the persistent volumes.
@@ -107,10 +74,78 @@ Finally, you can define custom `MountOptions` for the persistent volume created.
`parameters` are specific to each cloud storage provisioner. For full information about the storage classes provisioner parameters, refer to the official [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/#parameters).
+### Adding Persistent Volumes
+
+Your containers can store data on themselves, but if a container fails, that data is lost. To solve this issue, Kubernetes offers _persistent volumes_, which are external storage disks or file systems that your containers can access. If a container crashes, its replacement container can access the data in a persistent volume without any data loss.
+
+Persistent volumes can either be a disk or file system that you host on premise, or they can be hosted by a vendor, such as Amazon EBS or Azure Disk.
+
+>**Prerequisites:**
+>
+>- Permissions: `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference)
+>- You must have [storage provisioned]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/).
+>- If provisioning storage for a cluster hosted in the cloud:
+>
+> - The storage and cluster hosts must be the [same provider](#storage-and-cloud-providers).
+> - The [cloud providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) option must be enabled.
+
+
+1. From the **Global** view, open the cluster running the containers that you want to add persistent volume storage to.
+
+1. From the main menu, select **Storage > Persistent Volumes**.
+
+1. Click **Add Volume**.
+
+1. Enter a **Name** for the persistent volume.
+
+1. Select the **Volume Plugin** for the disk type or service that you're using.
+
+ >**Note:** When adding storage to a cluster that's hosted by a cloud provider:
+ >
+ >- You must enable the [cloud provider]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) option for the cluster.
+ >- You must use the cloud provider's plug-in for cloud storage. For example, if you have a Amazon EC2 cluster and you want to use cloud storage for it:
+ >
+ > - You must enable the `cloud provider` option for the EC2 cluster.
+ > - You must use the `Amazon EBS Disk` volume plugin.
+
+1. Enter the **Capacity** of your volume in gigabytes.
+
+1. Complete the **Plugin Configuration** form. Each plugin type requires information specific to the vendor of disk type. For help regarding each plugin's form and the information that's required, refer to the plug-in's vendor documentation.
+
+1. **Optional:** Complete the **Customize** form. This form features:
+
+ - [Access Modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes):
+
+ This options sets how many nodes can access the volume, along with the node read/write permissions. The [Kubernetes Documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) includes a table that lists which access modes are supported by the plugins available.
+
+ - [Mount Options](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#mount-options):
+
+ Each volume plugin allows you to specify additional command line options during the mounting process. You can enter these options in the **Mount Option** fields. Consult each plugin's vendor documentation for the mount options available.
+
+ - **Assign to Storage Class:**
+
+ If you later want to automatically provision persistent volumes identical to the volume that you've specified here, assign it a storage class. Later, when you create a workload, you can assign it a persistent volume claim that references the storage class, which will provision a persistent volume identical to the volume you've specified here.
+
+ >**Note:** You must [add a storage class](#adding-storage-classes) before you can assign it to a persistent volume.
+
+1. Click **Save**.
+
+**Result:** Your new persistent volume is created.
+
+
### Adding Storage Classes
_Storage Classes_ allow you to dynamically provision persistent volumes on demand. Think of storage classes as storage profiles that are created automatically upon a request (which is known as a _persistent volume claim_).
+>**Prerequisites:**
+>
+>- Permissions: `Manage Volumes` [role]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-role-reference)
+>- You must have [storage provisioned]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/).
+>- If provisioning storage for a cluster hosted in the cloud:
+>
+> - The storage and cluster hosts must be the [same provider](#storage-and-cloud-providers).
+> - The [cloud providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/) option must be enabled.
+
1. From the **Global** view, open the cluster for which you want to dynamically provision persistent storage volumes.
1. From the main menu, select `Storage > Storage Classes`. Click `Add Class`.
diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/_index.md
index df46e081f85..46f28a147e7 100644
--- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/_index.md
+++ b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/_index.md
@@ -5,7 +5,7 @@ aliases:
- /rancher/v2.x/en/tasks/workloads/add-persistent-volume-claim
---
-_Persistent Volume Claims_ (or PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. When you create a deployment, you should usually attach a PVC so that your application can lay claim to persistent storage. This claim lets your deployment application store its data in an external location, so that if one of the application's containers fails, it can be replaced with a new container and continue accessing its data stored externally, as though an outage never occured.
+_Persistent Volume Claims_ (or PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. When you create a deployment, you should usually attach a PVC so that your application can lay claim to persistent storage. This claim lets your deployment application store its data in an external location, so that if one of the application's containers fails, it can be replaced with a new container and continue accessing its data stored externally, as though an outage never occurred.
- Rancher lets you create as many PVCs within a project as you'd like.
- You can mount PVCs to a deployment as you create it, or later after its running.
@@ -20,7 +20,7 @@ _Persistent Volume Claims_ (or PVCs) are objects that request storage resources
1. Enter a **Name** for the volume claim.
-1. Select the **Namespace** of the volume claim.
+1. Select the [Namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces) of the volume claim.
1. Select a **Source** option:
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 5586b67c182..b02a218e569 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
@@ -17,7 +17,7 @@ Deploy a workload to run an application in one or more containers.
1. From the **Docker Image** field, enter the name of the Docker image that you want to deploy to the project. During deployment, Rancher pulls this image from [Docker Hub](https://hub.docker.com/explore/). Enter the name exactly as it appears on Docker Hub.
-1. Either select an existing [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), or click **Add to a new namespace** and enter a new namespace.
+1. Either select an existing [namespace]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#namespaces), or click **Add to a new namespace** and enter a new namespace.
1. Click **Add Port** to enter a port mapping, which enables access to the application inside and outside of the cluster . For more information, see [Services]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/#services).
diff --git a/content/rancher/v2.x/en/overview/_index.md b/content/rancher/v2.x/en/overview/_index.md
index 1202ed219c8..d07ec95ea39 100644
--- a/content/rancher/v2.x/en/overview/_index.md
+++ b/content/rancher/v2.x/en/overview/_index.md
@@ -10,13 +10,13 @@ Kubernetes has become the container orchestration standard. Most cloud and virtu
## Meet IT requirements
-Rancher supports centralized authentication for all Kubernetes clusters under its control. For example, you can:
+Rancher supports centralized authentication, access control, and monitoring for all Kubernetes clusters under its control. For example, you can:
- Use your Active Directory credentials to access Kubernetes clusters hosted by cloud vendors, such as GKE.
- Setup and enforce access control and security policies across all users, groups, projects, clusters, and clouds.
- View the health and capacity of your Kubernetes clusters from a single-pane-of-glass.
-### Empower DevOps Teams
+## Empower DevOps Teams
Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user does not need to have in-depth knowledge of Kubernetes concepts to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including, for example, security tools, monitoring systems, container registries, and storage and networking drivers.
diff --git a/content/rancher/v2.x/en/quick-start-guide/deployment/_index.md b/content/rancher/v2.x/en/quick-start-guide/deployment/_index.md
index cfccadb294d..4ce36eb9634 100644
--- a/content/rancher/v2.x/en/quick-start-guide/deployment/_index.md
+++ b/content/rancher/v2.x/en/quick-start-guide/deployment/_index.md
@@ -7,6 +7,8 @@ The following are the current guides for provisioning Rancher Server and a clust
- [DigitalOcean Quick Start](./digital-ocean-qs) - We provide you with a Terraform configuration file that completely automates the set up of the Rancher Server and registers a cluster for you to get started with.
+- [Amazon AWS Quick Start](./amazon-aws-qs) - We provide you with an Amazon-specific Terraform configuration file that completely automates the set up of the Rancher Server and registers a cluster for you to get started with.
+
- [Vagrant Quick Start](./quickstart-vagrant) - We provide you with a Vagrant configuration that again completely automates the set up of the Rancher Server and registers a cluster for you to get started with.
- [Manual Quick Start](./quickstart-manual-setup) - This will guide you through the process and requirements of manually setting up Rancher in any environment.
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
new file mode 100644
index 00000000000..ed8c6e56580
--- /dev/null
+++ b/content/rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/_index.md
@@ -0,0 +1,58 @@
+---
+title: Amazon AWS Quick Start
+weight: 100
+---
+The following steps will quickly deploy a Rancher Server with a single node cluster attached.
+
+## Prerequisites
+
+>**Note**
+>Deploying to Amazon AWS will incur charges.
+
+- [Amazon AWS Account](https://aws.amazon.com/account/): An Amazon AWS Account is required to create resources for deploying Rancher and Kubernetes.
+- [Amazon AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html): Use this link to follow a tutorial to create an Amazon AWS Access Key if you don't have one yet.
+- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster in Amazon AWS.
+
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the AWS folder containing the terraform file by executing `cd quickstart/aws`.
+
+3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`.
+
+4. Edit `terraform.tfvars` and customize the following variables at minimum. To change node counts and sizes, see `node sizes`.
+
+ - `aws_access_key` - Amazon AWS Access Key
+ - `aws_secret_key` - Amazon AWS Secret Key
+ - `ssh_key_name` - Amazon AWS Key Pair Name
+ - `prefix` - Resource Prefix
+
+5. **Optional:** Modify the count of the various node types within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) for more information on the variables.
+
+6. Run `terraform init`.
+
+7. To initiate the creation of the environment, run `terraform apply`. Then wait for the following output:
+
+ ```
+ Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
+ Outputs:
+ rancher-url = [
+ https://xxx.xxx.xxx.xxx
+ ]
+ ```
+
+8. Paste the `rancher-url` from the output above into the browser. Log in when prompted (default password is `admin`).
+
+**Result:** Rancher Server and your Kubernetes cluster is installed in Amazon AWS.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/workload).
+
+## Destroying the Environment
+
+1. From the `quickstart/aws` folder, execute `terraform destroy --auto-approve`.
+
+2. Wait for confirmation that all resources have been destroyed.
diff --git a/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md b/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
index d46f7938548..2d4a3a0b82a 100644
--- a/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
+++ b/content/rancher/v2.x/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md
@@ -38,29 +38,8 @@ This Quick Start Guide is divided into different tasks for easier consumption.
>
> For a full list of port requirements, refer to [Single Node Installation]({{< baseurl >}}/rancher/v2.x/en/installation/references).
- Provision the host according to the requirements below.
+ Provision the host according to our [Requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/).
-{{% accordion id="os" label="Operating System" %}}
-{{< requirements_os >}}
-{{% /accordion %}}
-{{% accordion id="hardware" label="Hardware" %}}
-Memory: 4GB
-{{% /accordion %}}
-{{% accordion id="software" label="Software" %}}
-Docker
-
- **Supported Docker versions:**
-
- - `1.12.6`
- - `1.13.1`
- - `17.03.2`
-
- >**Notes:**
- >
- > - For Docker installation instructions, visit their [documentation](https://docs.docker.com/install/).
- > - Docker requirements apply to both your Linux host and your cluster nodes.
-{{% /accordion %}}
-
### 2. Install Rancher
To install Rancher on your host, connect to it and then use a shell to install.
diff --git a/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md
index a16a3c41d0d..e379bc4bba5 100644
--- a/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md
+++ b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md
@@ -75,5 +75,6 @@ Congratulations! You have successfully deployed a workload exposed via an ingres
When you're done using your sandbox, destroy the Rancher Server and your cluster. See one of the following:
+- [Amazon AWS: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/#destroying-the-environment)
- [DigitalOcean: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/#destroying-the-environment)
-- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment)
\ No newline at end of file
+- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment)
diff --git a/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/_index.md b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/_index.md
index d6f9b49bdc7..b2cfd1d4861 100644
--- a/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/_index.md
+++ b/content/rancher/v2.x/en/quick-start-guide/workload/quickstart-deploy-workload-nodeport/_index.md
@@ -149,5 +149,6 @@ Congratulations! You have successfully deployed a workload exposed via a NodePor
When you're done using your sandbox, destroy the Rancher Server and your cluster. See one of the following:
+- [Amazon AWS: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/amazon-aws-qs/#destroying-the-environment)
- [DigitalOcean: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/digital-ocean-qs/#destroying-the-environment)
-- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment)
\ No newline at end of file
+- [Vagrant: Destroying the Environment]({{< baseurl >}}/rancher/v2.x/en/quick-start-guide/deployment/quickstart-vagrant/#destroying-the-environment)
diff --git a/content/rancher/v2.x/en/tools/logging/_index.md b/content/rancher/v2.x/en/tools/logging/_index.md
index 143c56be407..fd35b6bfc8e 100644
--- a/content/rancher/v2.x/en/tools/logging/_index.md
+++ b/content/rancher/v2.x/en/tools/logging/_index.md
@@ -5,6 +5,45 @@ aliases:
- /rancher/v2.x/en/tasks/logging/
---
-Rancher has the capability to push out cluster and project logs to an external
-log monitoring tool such as Splunk or a Syslog server. This allows you to be
-alerted of errors and warnings in your Kubernetes infrastructure.
+Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
+
+Rancher supports the following services:
+
+- [Elasticsearch]({{< baseurl >}}/rancher/v2.x/en/tools/logging/elasticsearch)
+- [Splunk]({{< baseurl >}}/rancher/v2.x/en/tools/logging/splunk)
+- [Kafka]({{< baseurl >}}/rancher/v2.x/en/tools/logging/kafka)
+- [Syslog]({{< baseurl >}}/rancher/v2.x/en/tools/logging/syslog)
+
+## Advantages
+
+Setting up a logging service to collect logs from your cluster/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.
+
+## Logging Scope
+
+You can configure logging at either cluster or project level.
+
+>**Note:** You can only configure one logging service per cluster or project.
+
+- If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
+
+ Cluster logging writes logs for every pod in the cluster and, in [RKE clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters), Kubernetes system components. Logs from the following locations are sent to your logging service:
+
+
+ - The `/var/log/containers` path for pod logging.
+
+ - The `/var/lib/rancher/rke/logs/` path for Kubernetes system components.
+
+- If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
+
+ Project logging writes logs for every pod in the project (`/var/log/containers`).
+
+After collection, all logs are stored by your logging service. Log into your service to view them.
+
+## Related Links
+
+[Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/logging/elasticsearch/_index.md b/content/rancher/v2.x/en/tools/logging/elasticsearch/_index.md
new file mode 100644
index 00000000000..22650678cd7
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/logging/elasticsearch/_index.md
@@ -0,0 +1,63 @@
+---
+title: Elasticsearch
+weight: 200
+---
+
+If your organization uses [Elasticsearch](https://www.elastic.co/), either on premise or in the cloud, you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Elasticsearch deployment to view logs for your cluster or container.
+
+## Configuring Elasticsearch Logging
+
+You can configure Rancher to send logs from your cluster or project to your instance of Elasticsearch.
+
+>**Prerequisites:** Configure an [Elasticsearch deployment](https://www.elastic.co/guide/en/cloud/saas-release/ec-create-deployment.html).
+
+1. Browse to the cluster or project that you want to log.
+{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
+If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
+
+1. From the **Global** view, open the cluster that you want to configure logging for.
+
+1. From the main menu, select **Tools > Logging**.
+{{% /accordion %}}
+{{% accordion id="project" label="To Configure Project Logging:" %}}
+If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
+
+1. From the **Global** view, open the project that you want to configure logging for.
+
+1. From the main menu, select **Resources > Logging**.
+{{% /accordion %}}
+
+1. Select **Elasticsearch**.
+
+1. Complete the **Elasticsearch Configuration** form.
+
+ 1. From the **Endpoint** field, enter the IP address and port for your Elasticsearch instance. You can copy this information from the dashboard of your Elasticsearch deployment. Elasticsearch usually uses port `9243`.
+
+ 1. If you are using [X-Pack Security](https://www.elastic.co/guide/en/x-pack/current/xpack-introduction.html), enter your Elasticsearch **Username** and **Password** for authentication.
+
+ 1. Enter an [Index Pattern](https://www.elastic.co/guide/en/kibana/current/index-patterns.html).
+
+1. If your instance of Elasticsearch uses SSL, complete the **SSL Configuration** form.
+
+ 1. Enter a private key and client certificate. Either copy and paste them or browse to them using **Read from a file**. This certificate will be installed on your logging server.
+
+ You can use either a self-signed certificate or one provided by a certificate authority.
+
+ You can generate a self-signed certificate using an openssl command. For example:
+
+ openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
+
+
+ 1. Enter your private key password.
+
+ 1. If you are using a certificate from a certificate authority (and not a self-signed certificate), select the **Enabled - Input trusted server certificate** option and then enter your **Trusted Server Certificate**.
+
+1. Complete the **Additional Logging Configuration** form.
+
+ 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
+
+ 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes data to the logging server. Intervals are measured in seconds.
+
+1. Click **Save**.
+
+**Result:** Rancher is now configured to send cluster and container logs to Elasticsearch. Log into Elasticsearch or Kibana to view your cluster/project logs.
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/logging/kafka/_index.md b/content/rancher/v2.x/en/tools/logging/kafka/_index.md
new file mode 100644
index 00000000000..eb062b4fa37
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/logging/kafka/_index.md
@@ -0,0 +1,48 @@
+---
+title: Kafka
+weight: 400
+---
+
+You can configure Rancher to send cluster or project logs to a [Kafka](https://kafka.apache.org/) server.
+
+## Configuring Kafka Logging
+
+>**Prerequisite:** You must have a Kafka server configured.
+
+1. Browse to the cluster or project that you want to log.
+{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
+If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
+
+1. From the **Global** view, open the cluster that you want to configure logging for.
+
+1. From the main menu, select **Tools > Logging**.
+{{% /accordion %}}
+{{% accordion id="project" label="To Configure Project Logging:" %}}
+If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
+
+1. From the **Global** view, open the project that you want to configure logging for.
+
+1. From the main menu, select **Resources > Logging**.
+{{% /accordion %}}
+
+1. Select **Kafka**.
+
+1. Complete the **Kafka Configuration** form.
+
+ 1. From **Endpoint Type**, select the type of Kafka server you are using: **Zookeeper** or **Broker**.
+
+ 1. From the **Endpoint** field, enter the IP address and port for your Kafka server.
+
+ By default, Kafka uses port `9092`.
+
+ 1. From the **Topic** field, enter the name of a Kafka [topic](https://kafka.apache.org/documentation/#basic_ops_add_topic) that your Kubernetes cluster submits logs to.
+
+1. Complete the **Additional Logging Configuration** form.
+
+ 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
+
+ 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes logs to the logging server. Intervals are measured in seconds.
+
+1. Click **Save**.
+
+**Result:** Rancher is now configured to send logs to Kafka. View your Kafka stream to view logs for your cluster and containers.
diff --git a/content/rancher/v2.x/en/tools/logging/splunk/_index.md b/content/rancher/v2.x/en/tools/logging/splunk/_index.md
index e58082ca991..42976bb3134 100755
--- a/content/rancher/v2.x/en/tools/logging/splunk/_index.md
+++ b/content/rancher/v2.x/en/tools/logging/splunk/_index.md
@@ -1,85 +1,74 @@
---
title: Splunk
-weight: 3725
+weight: 300
aliases:
- /rancher/v2.x/en/tasks/logging/splunk/
---
-The following guide will demonstrate how to monitor your container
-infrastructure using Splunk.
+If your organization uses [Splunk](https://www.splunk.com/), you can configure Rancher to send it cluster or project logs. Afterwards logs are sent, you can use Splunk to view them.
-## Configure HTTP Event Collector
+## Configuring Splunk Logging
-The first step is to identify what port Splunk is using for the HTTP Event
-collector. Usually the port is either **8088** or **8089**. HEC is used to
-send log data from Rancher to Splunk using HTTP or HTTPS.
+You can configure Rancher to send Kubernetes logs to your instance of Splunk.
-Login to Splunk and go to:
+>**Prerequisites:**
+>
+>- Configure HTTP event collection for your Splunk Server (Splunk Enterprise or Splunk Cloud).
+>- Enable all tokens, and then create a new token.
+>
+>For more information, see [Splunk Documentation](http://docs.splunk.com/Documentation/Splunk/7.1.2/Data/UsetheHTTPEventCollector#About_Event_Collector_tokens).
-Settings > Data inputs > HTTP Event Collector > **Global Settings**
+1. Browse to the cluster or project that you want to log.
+{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
+If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
-
+1. From the **Global** view, open the cluster that you want to configure logging for.
-Make sure to click on **Enabled** for all tokens. By default it is set to
-disabled. This will allow Splunk to collect HTTP Event data sent from Rancher.
+1. From the main menu, select **Tools > Logging**.
+{{% /accordion %}}
+{{% accordion id="project" label="To Configure Project Logging:" %}}
+If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
-Click on **Save** to update the HEC settings.
+1. From the **Global** view, open the project that you want to configure logging for.
-## Generate Token
+1. From the main menu, select **Resources > Logging**.
+{{% /accordion %}}
-This step might not be applicable, if you already have a token. Now we will
-generate the token that will be used by Rancher to send HTTP Event data.
+1. Select **Splunk**.
-- Click Settings > Data inputs > HTTP Event Collector > **New Token**
-- Click monitor
-- Select HTTP Event Collector
-- In the Name field, enter a name for the token (ex. **rancher**)
-- Click Next
-- Select the indexe(s) desired (history, main, and summary)
-- You can also create a new index and add it to the step above
-- Click Review
-- Confirm that all settings for the token are what you want
-- Click Submit to generate the token
+1. Complete the **Splunk HTTP Event Collector Configuration** form.
-
+ 1. From the **Endpoint** field, enter the IP address and port for you Splunk instance (i.e. `http://splunk-server:8088`)
+
+ Splunk usually uses port `8088`. If you're using Splunk Cloud, you'll need to work with [Splunk support](https://www.splunk.com/en_us/support-and-services.html) to get an endpoint URL.
-Congratulations you now are ready to feed Splunk with HTTP Event data. You
-should see a page like the one below with your generated token. This is the
-token that will be used in Rancher to communicate with Splunk.
+ 1. Enter the **Token** you obtained while completing the prerequisites (i.e., when you created a token in Splunk).
-
+ 1. From the **Source** field, enter the name of the token as entered in Splunk.
-## Configure Cluster Logging
+ 1. **Optional:** Enter one or more [index](http://docs.splunk.com/Documentation/Splunk/7.1.2/Indexer/Aboutindexesandindexers) that's allowed for your token.
-In this section we will configure and enable Splunk cluster logging in Rancher.
+1. Complete the **Additional Logging Configuration** form.
-- Head on over to local > Tools > **Logging**
-- Select Splunk
-- Enter the Splunk endpoint using the port specified for **HEC** (ex. http://splunk-server:8088)
-- Enter the token generated above (ex. 8da70994-b1b0-4a79-b154-bfaae8f93432)
-- Enter the Source, name of the token created earlier (ex. **rancher**)
-- You can also enter an index, this is optional (ex. **main**)
+ 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
-
+ 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes event data to the logging server. Intervals are measured in seconds.
-
+1. Click **Save**.
-Repeat the same step for Project Logging, if desired. This is not required and is optional.
+**Result:** Rancher is now configured to send logs to Splunk. Log into your Spunk instance to view events for your cluster and containers.
-## View Logs
+## Viewing Logs
-You should now be receiving logging data from your cluster. Head on over to
-Splunk to view your logs.
+1. Log into your Splunk server.
-Click on **Search & Reporting**, you should see **Indexed Events** increasing.
-Click on Data Summary and select the Sources tab.
+1. Click on **Search & Reporting**. The number of **Indexed Events** listed should be increasing.
-
+1. Click on Data Summary and select the Sources tab.
+ 
-To view the actual logs click on the source that you declared earlier
-(ex. rancher -> http:**rancher**)
-
-
+1. To view the actual logs, click on the source that you declared earlier.
+ 
## Troubleshooting
@@ -91,12 +80,7 @@ $ curl http://splunk-server:8088/services/collector/event \
-d '{"event": "hello world"}'
```
-You should see **json** data returning Success code 0. You should be able
-to send logging data to HEC. If you received an error, check your configuration
-in Splunk & Rancher Cluster Logging.
+If Splunk is configured correctly, you should receive **json** data returning `success code 0`. You should be able
+to send logging data to HEC.
-## Reference
-
-For more information on Splunk, you can check out the following reference:
-
-[Splunk -> HTTP Event Collector](http://docs.splunk.com/Documentation/Splunk/7.0.0/Data/UsetheHTTPEventCollector)
+If you received an error, check your configuration in Splunk and Rancher.
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/tools/logging/syslog/_index.md b/content/rancher/v2.x/en/tools/logging/syslog/_index.md
new file mode 100644
index 00000000000..9bea75a6451
--- /dev/null
+++ b/content/rancher/v2.x/en/tools/logging/syslog/_index.md
@@ -0,0 +1,65 @@
+---
+title: Syslog
+weight: 500
+---
+
+You can configure Rancher to send Kubernetes logs to a [Syslog](https://tools.ietf.org/html/rfc5424) server.
+
+## Configuring Syslog
+
+You can configure Rancher to send cluster or project logs to Syslog.
+
+>**Prerequisite:** You must have a Syslog server configured.
+
+1. Browse to the cluster or project that you want to log.
+{{% accordion id="cluster" label="To Configure Cluster Logging:" %}}
+If you're a [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) who works in operations or security, configure cluster logging.
+
+1. From the **Global** view, open the cluster that you want to configure logging for.
+
+1. From the main menu, select **Tools > Logging**.
+
+{{% /accordion %}}
+{{% accordion id="project" label="To Configure Project Logging:" %}}
+If you're a [project owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) who works on an application, configure project logging.
+
+1. From the **Global** view, open the project that you want to configure logging for.
+
+1. From the main menu, select **Resources > Logging**.
+
+{{% /accordion %}}
+
+1. Select **Syslog**.
+
+1. Complete the **Syslog Configuration** form.
+
+ 1. From the **Endpoint** field, enter the IP address and port for your Syslog server. Additionally, select the protocol that your Syslog server uses from the drop-down.
+
+ 1. From the **Program** field, enter the name of the application sending logs to your Syslog server (i.e., Rancher).
+
+ 1. If you are using a cloud logging service (i.e., [Sumologic](https://www.sumologic.com/)), enter a **Token** that authenticates with your Syslog server. Use the cloud logging service to create this token.
+
+ 1. Select a **Log Severity** for events that are logged to the Syslog server. For more information on each severity level, see the [Syslog protocol documentation](https://tools.ietf.org/html/rfc5424#page-11).
+
+1. If your Syslog server uses **TCP** protocol, complete the **SSL Configuration** form.
+
+ 1. Enter a private key and client certificate. Either copy and paste them or browse to them using **Read from a file**. This certificate will be installed on your logging server.
+
+ You can use either a self-signed certificate or one provided by a certificate authority.
+
+ You can generate a self-signed certificate using an openssl command. For example:
+
+
+ openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
+
+ 1. If you are using a certificate from a certificate authority (and not a self-signed certificate), select the **Enabled - Input trusted server certificate** option and then enter your **Trusted Server Certificate**.
+
+1. Complete the **Additional Logging Configuration** form.
+
+ 1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
+
+ 1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes data to the logging server. Intervals are measured in seconds.
+
+1. Click **Save**.
+
+**Result:** Rancher is now configured to send logs to your Syslog server. View your Syslog stream to view logs for your cluster and containers.
\ No newline at end of file
diff --git a/content/rancher/v2.x/en/upgrades/ha-server-rollbacks/_index.md b/content/rancher/v2.x/en/upgrades/ha-server-rollbacks/_index.md
deleted file mode 100644
index 71a3d78fde6..00000000000
--- a/content/rancher/v2.x/en/upgrades/ha-server-rollbacks/_index.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: High Availability Rollback
-weight: 1025
-aliases:
- - /rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks
----
-
-If you upgrade Rancher, but the upgrade does not complete successfully, you may need to roll back your Rancher Server to its last healthy state before upgrade. To restore Rancher:
-
-- Restore the `etcd` snapshot taken before upgrade.
-- Run the command to revert to your prior version of Rancher.
-
->**Warning!**
->
-> Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
-
->
->**Prerequisites:** {{< requirements_rollback >}}
-
-1. Open **Terminal** and change directory to the location of the RKE binary that you used during upgrade.
-
-1. Run one of the following commands to restore the `etcd` snapshot [that you took]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/ha-server-upgrade/#snapshot) before your unsuccessful upgrade. Replace the `` placeholder with your snapshot.
-
- ```
- # MacOS
- ./rke_darwin-amd64 etcd snapshot-restore --name --config rancher-cluster.yml
- # Linux
- ./rke_linux-amd64 etcd snapshot-restore --name --config rancher-cluster.yml
- ```
-
-1. Run one of the following commands to bring your cluster back up:
-
- ```
- # MacOS
- ./rke_darwin-amd64 up --config rancher-cluster.yml
- # Linux
- ./rke_linux-amd64 up --config rancher-cluster.yml
- ```
-
-1. Lastly, restart the Kubernetes components on all cluster nodes to prevent potential `etcd` conflicts. Run this command on each of your nodes.
-
- ```
- docker restart kube-apiserver kubelet kube-controller-manager kube-scheduler kube-proxy
- docker ps | grep flannel | cut -f 1 -d " " | xargs docker restart
- docker ps | grep calico | cut -f 1 -d " " | xargs docker restart
- ```
-1. Enter the following command:
-
- ```
-kubectl --kubeconfig=kube_config_rancher-cluster.yml set image deployment/cattle cattle-server=rancher/rancher: -n cattle-system
- ```
- Replace `` with the version that you were running before upgrade. For a list of tags available, see the [Rancher Forum Announcements](https://forums.rancher.com/c/announcements).
-
- **Step Result:** The rollback begins. Rancher Server may be unavailable for a few minutes.
-
-1. Log into Rancher. Confirm that the rollback succeeded by checking the version displayed in the bottom-left corner of the browser window.
-
-## Troubleshooting
-
-With **RKE v0.1.8** and below, the **rke-bundle-cert** container is left over from a failed etcd restore. If you are having an issue with restoring an **etcd snapshot** then you can do the following on each etcd nodes before attempting to do another restore:
-
-```
-docker container rm --force rke-bundle-cert
-```
-
-The rke-bundle-cert container is usually removed when a backup or restore of **etcd** succeeds.
-Whenever something goes wrong, the **rke-bundle-cert** container will be left over. You can look
-at the logs or inspect the container to see what the issue is.
-
-```
-docker container logs --follow rke-bundle-cert
-docker container inspect rke-bundle-cert
-```
-
-The important thing to note is the mounts of the container and location of the **pki.bundle.tar.gz**.
-
-As of **RKE v0.1.9**, the **rke-bundle-cert** container is removed on both success and
-failure of a restore. To debug any issues, you will need to look at the **logs** generated from rke.
diff --git a/content/rancher/v2.x/en/upgrades/rollbacks/_index.md b/content/rancher/v2.x/en/upgrades/rollbacks/_index.md
new file mode 100644
index 00000000000..53b3f8920f9
--- /dev/null
+++ b/content/rancher/v2.x/en/upgrades/rollbacks/_index.md
@@ -0,0 +1,8 @@
+---
+title: Rollbacks
+weight: 1010
+---
+This section contains information about how to rollback your Rancher server to a previous version.
+
+- [Rolling back a Single Node Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/)
+- [Rolling back a High Availability Install]({{< baseurl >}}/rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/)
diff --git a/content/rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/_index.md b/content/rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/_index.md
new file mode 100644
index 00000000000..9dce2d7aa1e
--- /dev/null
+++ b/content/rancher/v2.x/en/upgrades/rollbacks/ha-server-rollbacks/_index.md
@@ -0,0 +1,15 @@
+---
+title: High Availability (HA) Rollback
+weight: 1025
+aliases:
+ - /rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks/
+ - /rancher/v2.x/en/upgrades/ha-server-rollbacks
+---
+
+If you upgrade Rancher and the upgrade does not complete successfully, you may need to rollback your Rancher Server to its last healthy state.
+
+To restore Rancher follow the procedure detailed here: [Restoring Backups — High Availability Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/ha-restoration)
+
+Restoring a snapshot of the Rancher Server cluster will revert Rancher to the version and state at the time of the snapshot.
+
+> **NOTE:** Managed cluster are authoritative for their state. This means restoring the rancher server will not revert workload deployments or changes made on managed clusters after the snapshot was taken.
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
new file mode 100644
index 00000000000..baee8b006ae
--- /dev/null
+++ b/content/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/_index.md
@@ -0,0 +1,83 @@
+---
+title: Single Node Rollback
+weight: 1015
+aliases:
+ - /rancher/v2.x/en/backups/rollbacks/single-node-rollbacks
+ - /rancher/v2.x/en/upgrades/single-node-rollbacks
+---
+
+If a Rancher upgrade does not complete successfully, you'll have to roll back to your Rancher setup that you were using before [Single Node Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrades/single-node-upgrade). Rolling back restores:
+
+- Your previous version of Rancher.
+- Your data backup created before upgrade.
+
+## Before You Start
+
+During rollback to a prior version of Rancher, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (``). Here's an example of a command with a placeholder:
+
+```
+docker pull rancher/rancher:
+```
+
+In this command, `` is the version of Rancher you were running before your unsuccessful upgrade. `v2.0.5` for example.
+
+Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the [procedure below](#creating-a-backup).
+
+Terminal `docker ps` Command, Displaying Where to Find `` and ``
+
+
+| Placeholder | Example | Description |
+| -------------------------- | -------------------------- | ------------------------------------------------------- |
+| `` | `v2.0.5` | The rancher/rancher image you used before upgrade. |
+| `` | `festive_mestorf` | The name of your Rancher container. |
+| `` | `v2.0.5` | The version of Rancher that the backup is for. |
+| `` | `9-27-18` | The date that the data container or backup was created. |
+
+
+You can obtain `` and `` by logging into your Rancher Server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.
+
+## 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.
+
+>**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
+
+1. Using a remote Terminal connection, log into the node running your Rancher Server.
+
+1. Pull the version of Rancher that you were running prior to upgrade. Replace the `` with [that version](#before-you-start).
+
+ For example, if you were running Rancher v2.0.5 before upgrade, pull v2.0.5.
+
+ ```
+ docker pull rancher/rancher:
+ ```
+
+1. Stop the container currently running Rancher Server. Replace `` with the name of your Rancher container.
+
+ ```
+ docker stop |