Merge pull request #2 from rancher/master

latest data
2026-09-26 04:58:07 +00:00 · 2019-05-17 10:56:15 -07:00
parent 5ff93ae339 687e2edf0d
commit 7027d3bcc6
50 changed files with 705 additions and 160 deletions
@@ -5,16 +5,28 @@ Rancher Docs

 The `rancher/docs:dev` docker image runs a live-updating server.  To run on your workstation, run:

+Linux
 ```bash
  ./scripts/dev
 ```

+Windows
+```powershell
+./scripts/dev-windows.ps1
+```
+
 and then navigate to http://localhost:9001/.  You can customize the port by passing it as an argument:

+Linux
 ```bash
  ./scripts/dev 8080
 ```

+Windows
+```powershell
+./scripts/dev-windows.ps1 -port 8080
+```
+
 License
 =======
 Copyright (c) 2014-2019 [Rancher Labs, Inc.](http://rancher.com)
@@ -15,7 +15,7 @@ rancher:
      auth: dXNlcm5hbWU6cGFzc3dvcmQ=
 ```

-The `auth` key is generated by base64 encoding a string of the form `username:password`. The `docker login` command can be be used to generate an `auth` key. After running the command and authenticating successfully, the key can be found in the `$HOME/.docker/config.json` file.
+The `auth` key is generated by base64 encoding a string of the form `username:password`. The `docker login` command can be used to generate an `auth` key. After running the command and authenticating successfully, the key can be found in the `$HOME/.docker/config.json` file.

 ```json
 {
@@ -30,7 +30,7 @@ The Rancher authentication proxy integrates with the following external authenti
 <br/>
 However, Rancher also provides [local authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/local/).

-In most cases, you should use an external authentication service over local authentication, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if Active Directory is down.
+In most cases, you should use an external authentication service over local authentication, as external authentication allows user management from a central location. However, you may want a few local authentication users for managing Rancher under rare circumstances, such as if your external authentication provider is unavailable or undergoing maintenance.

 ## Users and Groups

@@ -144,7 +144,7 @@ $ ldapsearch -x -D "acme\jdoe" -w "secret" -p 389 \
 -h ad.acme.com -b "dc=acme,dc=com" -s sub "sAMAccountName=jdoe"
 ```

-This command performs an LDAP search with the search base set to the domain root (`-b "dc=acme,dc=com"`) and a filter targeting the the user account (`sAMAccountNam=jdoe`), returning the attributes for said user:
+This command performs an LDAP search with the search base set to the domain root (`-b "dc=acme,dc=com"`) and a filter targeting the user account (`sAMAccountNam=jdoe`), returning the attributes for said user:

 ![LDAP User]({{< baseurl >}}/img/rancher/ldapsearch-user.png)

@@ -11,7 +11,7 @@ After you configure external authentication, the users that display on the **Use

 - If you are logged in as a local user, only local users display.

- If you are logged in an an external user, both external and local users display.
+- If you are logged in an external user, both external and local users display.

 ## Users and Roles

@@ -49,7 +49,7 @@ The following table lists each custom global permission available and whether it
 | Manage Roles                       | ✓             |               |
 | Manage Users                       | ✓             |               |
 | Create Clusters                    | ✓             | ✓             |
-| User Catalog Templates             | ✓             | ✓             |
+| Use Catalog Templates             | ✓             | ✓             |
 | Login Access                       | ✓             | ✓             |

 > **Notes:** 
@@ -3,7 +3,7 @@ title: Creating Backups—High Availability Installs
 weight: 50
 aliases:
  - /rancher/v2.x/en/installation/after-installation/ha-backup-and-restoration/
-  - /rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration/ 
+  - /rancher/v2.x/en/installation/backups-and-restoration/ha-backup-and-restoration/
 ---
 This section describes how to create backups of your high-availability Rancher install.

@@ -45,36 +45,51 @@ To take recurring snapshots, enable the `etcd-snapshot` service, which is a serv

 1. Open `rancher-cluster.yml` with your favorite text editor.

-2. Add the following code block to the bottom of the file:
+2. Edit the code for the `etcd` service to enable recurring snapshots. As of RKE v0.2.0, snapshots can be saved in a S3 compatible backend.  

-	```
-	services:
-	  etcd:
-	    snapshot: true # enables recurring etcd snapshots
-	    creation: 6h0s # time increment between snapshots
-	    retention: 24h # time increment before snapshot purge
-	```
+    _Using RKE v0.2.0+_

-3. Edit the code according to your requirements.
+    ```
+    services:
+      etcd:
+        backup_config:
+          enabled: true     # enables recurring etcd snapshots
+          interval_hours: 6 # time increment between snapshots
+          retention: 60     # time in days before snapshot purge
+          # Optional S3
+          s3_backup_config:
+            access_key: "myaccesskey"
+            secret_key:  "myaccesssecret"
+            bucket_name: "my-backup-bucket"
+            endpoint: "s3.eu-west-1.amazonaws.com"
+            region: "eu-west-1"
+    ```
+
+    _Using RKE v0.1.x_
+
+    ```
+    services:
+      etcd:
+        snapshot: true # enables recurring etcd snapshots
+        creation: 6h0s # time increment between snapshots
+        retention: 24h # time increment before snapshot purge
+    ```

 4. Save and close `rancher-cluster.yml`.
-
 5. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
-
 6. Run the following command:

 	```
 	rke up --config rancher-cluster.yml
 	```

-
-**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved to the following directory: `/opt/rke/etcd-snapshots/`.
+**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved locally to the following directory: `/opt/rke/etcd-snapshots/`. If configured, the snapshots are also uploaded to your S3 compatible backend.

 #### Option B: One-Time Snapshots

 When you're about to upgrade Rancher or restore it to a previous snapshot, you should snapshot your live image so that you have a backup of `etcd` in its last known state.

-**To Take a One-Time Snapshot:**
+**To Take a One-Time Local Snapshot:**

 1. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.

@@ -86,7 +101,25 @@ When you're about to upgrade Rancher or restore it to a previous snapshot, you s

 **Result:** RKE takes a snapshot of `etcd` running on each `etcd` node. The file is saved to `/opt/rke/etcd-snapshots`.

-### 2. Backup Snapshots to a Safe Location
+**To Take a One-Time S3 Snapshot:**
+
+_Available as of RKE v0.2.0_
+
+1. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
+
+2. Enter the following command. Replace `<SNAPSHOT.db>` with any name that you want to use for the snapshot (e.g. `upgrade.db`).
+
+    ```shell
+    rke etcd snapshot-save --config rancher-cluster.yml --name snapshot-name  \
+    --s3 --access-key S3_ACCESS_KEY --secret-key S3_SECRET_KEY \
+    --bucket-name s3-bucket-name --s3-endpoint s3.amazonaws.com
+    ```
+
+**Result:** RKE takes a snapshot of `etcd` running on each `etcd` node. The file is saved to `/opt/rke/etcd-snapshots`. It is also uploaded to the S3 compatible backend.
+
+### 2. Backup Local Snapshots to a Safe Location
+
+> **Note:** If you are using RKE v0.2.0, you can enable saving the backups to a S3 compatible backend directly and skip this step.

 After taking the `etcd` snapshots, save them to a safe location so that they're unaffected if your cluster experiences a disaster scenario. This location should be persistent.

@@ -7,15 +7,15 @@ _Available as of v2.2.0_

 In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.

-Rancher recommends enabling the ability to set up recurring snapshots, but one-time snapshots can easily be taken as well.  
+Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additonally, one-time snapshots can easily be taken as well.

 >**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).

 ## Configuring Recurring Snapshots for the Cluster

-By default, any [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) are enabled to take recurring snapshots that are saved locally.
+By default, [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) are configured to take recurring snapshots (saved to local disk). To protect against local disk failure, using the [S3 Target](#s3-backup-target) or replicating the path on disk is advised.

-During cluster provisioning or editing the cluster, the configuration about snapshots are in the advanced section for **Cluster Options**. Click on **Show advanced options**.
+During cluster provisioning or editing the cluster, the configuration for snapshots can be found in the advanced section for **Cluster Options**. Click on **Show advanced options**.

 In the **Advanced Cluster Options** section, there are several options available to configure:

@@ -39,7 +39,7 @@ By default, the `local` backup target is selected. The benefits of this option i

 #### S3 Backup Target

-The `S3` backup target allows users to configure a S3 compatible backend to store the snapshots. The main benefit of this option is that if the cluster loses all the etcd nodes, the cluster can still be restored as the snapshots are stored externally. The downside of using the `S3` backup target is that additional configuration is required in order to have these snapshots saved remotely.
+The `S3` backup target allows users to configure a S3 compatible backend to store the snapshots. The primary benefit of this option is that if the cluster loses all the etcd nodes, the cluster can still be restored as the snapshots are stored externally. Rancher recommends external targets like `S3` backup, however its configuration reuqirements do require additional effort that should be considered. 

 | Option | Description | Required|
 |---|---|---|
@@ -55,7 +55,7 @@ Select how often you want recurring snapshots to be taken as well as how many sn

 ## One-Time Snapshots

-Besides recurring snapshots, you might want to take a one-time snapshot in specific use cases. For example, if you're about to upgrade the Kubernetes version of your cluster, you might want to take a snapshot right before the upgrade.
+In addition to recurring snapshots, you may want to take a "one-time" snapshot. For example, before upgrading the Kubernetes version of a cluster it's best to backup the state of the cluster to protect against upgrade failure. 

 1. In the **Global** view, navigate to the cluster that you want to take a one-time snapshot.

@@ -3,12 +3,8 @@ title: Certificate Rotation
 weight: 2040
 ---

-_Available as of v2.2.0_
-
 By default, Kubernetes clusters require certificates and Rancher launched Kubernetes clusters automatically generate  certificates for the Kubernetes components. Rotating these certificates is important before the certificates expire as well as if a certificate is compromised. After the certificates are rotated, the Kubernetes components are automatically restarted.

-> **Note:** Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher Launched Kubernetes clusters.
-
 Certificates can be rotated for the following services:

 - etcd
@@ -18,6 +14,11 @@ Certificates can be rotated for the following services:
 - kube-scheduler
 - kube-controller-manager

+
+### Certificate Rotation in Rancher v2.2.x
+
+_Available as of v2.2.0_
+
 Rancher launched Kubernetes clusters have the ability to rotate the auto-generated certificates through the UI.

 1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
@@ -32,3 +33,24 @@ Rancher launched Kubernetes clusters have the ability to rotate the auto-generat
 4. Click **Save**.

 **Results:** The selected certificates will be rotated and the related services will be restarted to start using the new certificate.
+
+> **Note:** Even though the RKE CLI can use custom certificates for the Kubernetes cluster components, Rancher currently doesn't allow the ability to upload these in Rancher Launched Kubernetes clusters.
+
+
+### Certificate Rotation in Rancher v2.1.x and v2.0.x
+
+_Available as of v2.1.14 and v2.0.9_
+
+Rancher launched Kubernetes clusters have the ability to rotate the auto-generated certificates through the API.
+
+1. In the **Global** view, navigate to the cluster that you want to rotate certificates.
+
+2. Select the **Ellipsis (...) > View in API**.
+
+3. Click on **RotateCertificates**.
+
+4. Click on **Show Request**.
+
+5. Click on **Send Request**.
+
+**Results:** All kubernetes certificates will be rotated.
@@ -30,7 +30,14 @@ For [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provis

 > **Note:** By default, all Rancher Launched Kubernetes clusters have [Authorized Cluster Endpoint]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint) enabled.

-To find the name of the context(s), view the kubeconfig file.
+To find the name of the context(s), run:
+
+```
+kubectl config get-contexts --kubeconfig /custom/path/kube.config
+CURRENT   NAME                        CLUSTER                     AUTHINFO     NAMESPACE
+*         my-cluster                  my-cluster                  user-46tmn
+          my-cluster-controlplane-1   my-cluster-controlplane-1   user-46tmn
+```

 ### Clusters with FQDN defined as an Authorized Cluster Endpoint

@@ -8,7 +8,7 @@ aliases:

 Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.

-Rancher supports the following services:
+Rancher supports integration with the following services:

 - Elasticsearch
 - Splunk
@@ -56,7 +56,7 @@ As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global

 1. Select **Tools > Logging** in the navigation bar.

-1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports the following services:
+1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports integration with the following services:

   - [Elasticsearch]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/elasticsearch/)
   - [Splunk]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/splunk/)
@@ -39,7 +39,7 @@ As an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global

 ### Resource Consumption

-When enabling cluster monitoring, you need to ensure your worker nodes and Prometheus pod have enough resources. The tables below provides a guide of how much resource consumption will be used.
+When enabling cluster monitoring, you need to ensure your worker nodes and Prometheus pod have enough resources. The tables below provides a guide of how much resource consumption will be used. In larger deployments, it is strongly advised that the monitoring infrastructure be placed on dedicated nodes in the cluster.

 #### Prometheus Pod Resource Consumption

@@ -51,6 +51,24 @@ Number of Cluster Nodes | CPU (milli CPU) | Memory | Disk
 50| 2000 | 2 GB | ~5 GB/Day
 256| 4000 | 6 GB | ~18 GB/Day

+Additional pod resource requirements for cluster level monitoring.
+
+Workload | Container | CPU - Request | Mem - Request | CPU - Limit | Mem - Limit | Configurable
+---------|-----------|---------------|---------------|-------------|-------------|-------------
+Prometheus|Prometheus| 750m | 750Mi| 1000m | 1000Mi| Y
+ ||Prometheus-proxy| 50m | 50Mi | 100m | 100Mi| Y
+ ||Prometheus-auth| 100m | 100Mi | 500m | 200Mi | Y
+ ||Prometheus-config-reloader| - | - | 50m | 50Mi | N
+ ||rules-configmap-reloader | - | - | 100m | 25Mi | N
+Grafana | grafana-init-plugin-json-copy | 50m |50Mi|50m|50Mi|Y
+ ||grafana-init-plugin-json-modify|50m|50Mi|50m|50Mi|Y
+ ||grafana |100m|100Mi|200m|200Mi|Y
+ ||grafana-proxy|50m|50Mi|100m|100Mi|Y
+Kube-State Exporter|kube-state |100m|130Mi|100m|200Mi|Y
+Node Exporter | exporter-node | 200m | 200Mi | 200m | 200Mi|Y
+Operator | prometheus-operator | 100m | 50Mi | 200m | 100Mi | Y
+
+
 #### Other Pods Resource Consumption

 Besides the Prometheus pod, there are components that are deployed that require additional resources on the worker nodes.
@@ -28,6 +28,8 @@ The [node exporter](https://github.com/prometheus/node_exporter/blob/master/READ

 When configuring Prometheus and enabling the node exporter, enter a host port in the **Node Exporter Host Port** that will not produce port conflicts with existing applications. The host port chosen must be open to allow internal traffic between Prometheus and the Node Exporter.

+>**Warning:** In order for Prometheus to collect the metrics of the node exporter, after enabling cluster monitoring, you must open the **Node Exporter Host Port** in the host firewall rules to allow intranet access. By default, `9796` is used as that host port.
+
 ## Persistent Storage

 >**Prerequisite:** Configure one or more [storage class]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/#adding-storage-classes) to use as [persistent storage]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/) for your Prometheus or Grafana pod.
@@ -28,7 +28,7 @@ Use {{< product >}} to create a Kubernetes cluster in Azure.

 		{{< step_create-cloud-credential >}}

-		- **Placement** sets the geographical region where where your cluster is hosted and other location metadata.
+		- **Placement** sets the geographical region where your cluster is hosted and other location metadata.

 		- **Network** configures the networking used in your cluster.

@@ -140,7 +140,7 @@ Use {{< product >}} to create a Kubernetes cluster in Amazon EC2.
                "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:key-pair/*",
                "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:network-interface/*",
                "arn:aws:ec2:REGION:AWS_ACCOUNT_ID:security-group/*",
-                "arn:aws:iam::AWS_ACCOUNT_ID:role/your-role-name"
+                "arn:aws:iam::AWS_ACCOUNT_ID:role/YOUR_ROLE_NAME"
            ]
        },
        {
@@ -64,7 +64,7 @@ If you are using a private registry with authentication for your Docker images,

 _Available as of v2.2.0_

-Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher. This is enabled by default, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates. It is recommended to create an FQDN pointing to a load balancer which load balances across your nodes with the `controlplane` role. If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate which will be included in the generated kubeconfig to validate the certificate chain. See the [Kubeconfig Files]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubeconfig/) for more information.
+Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher. This is enabled by default, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates. It is recommended to create an FQDN pointing to a load balancer which load balances across your nodes with the `controlplane` role. If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate which will be included in the generated kubeconfig to validate the certificate chain. See the [Kubeconfig Files]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/kubeconfig/) and [API Keys]({{< baseurl >}}/v2.x/en/user-settings/api-keys/#creating-an-api-key) documentation for more information.

 ### Advanced Cluster Options

@@ -3,7 +3,12 @@ title: Configuring Custom Clusters for Windows (Experimental)
 weight: 2240
 ---

-_Available as of v2.1.0_
+>**Notes:**
+>
+>- Windows are new and improved for Rancher v2.3!  
+>- Still using v2.1.x or v2.2.x? As of v2.1.10 and v2.2.3, the previous Windows feature has been removed. See the windows documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/docs-for-2.1-and-2.2/).
+
+_Available as of v2.3.0-alpha1_

 >**Important:**
 >
@@ -11,106 +16,109 @@ _Available as of v2.1.0_

 When provisioning a [custom cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/) using Rancher, you can use a mix of Linux and Windows hosts as your cluster nodes.

-This guide walks you through create of a custom cluster that includes 3 nodes: a Linux node, which serves as a Kubernetes control plane node; another Linux node, which serves as a Kubernetes worker used to support Ingress for the cluster; and a Windows node, which is assigned the Kubernetes worker role and runs your Windows containers.
+This guide walks you through the creation of a custom cluster that includes three nodes.

->**Notes:**
->
->- For a summary of Kubernetes features supported in Windows, see [Using Windows in Kubernetes](https://kubernetes.io/docs/setup/windows/intro-windows-in-kubernetes/).
->- Windows containers must run on Windows Server 1803 nodes. Windows Server 1709 and earlier versions do not support Kubernetes properly.
->- Containers built for Windows Server 1709 or earlier do not run on Windows Server 1803. You must build containers on Windows Server 1803 to run these containers on Windows Server 1803.
+* A Linux node, which serves as a Kubernetes control plane node.
+* Another Linux node, which serves as a Kubernetes worker used to support Rancher Cluster agent, Metrics server, DNS and Ingress for the cluster.
+* A Windows node, which is assigned the Kubernetes worker role and runs your Windows containers.

+## Pre-Prerequisites

+For a summary of Kubernetes features supported in Windows, see [Using Windows Server Containers in Kubernetes](https://kubernetes.io/docs/getting-started-guides/windows/#supported-features).
+
+### Node Requirements
+
+In order to add Windows worker nodes, the node must be running Windows Server 2019 (i.e. core version 1809 or above). Any earlier versions (e.g. core version 1803 and earlier) do not properly support Kubernetes.
+
+Windows overlay networking requires that [KB4489899](https://support.microsoft.com/en-us/help/4489899) hotfix is installed. Most cloud-hosted VMs already have this hotfix.
+
+### Container Requirements
+
+Windows requires that containers must be built on the same Windows server version that they are being deployed on. Therefore, containers must be built on Windows Server 2019 in order to be used with the node requirements of running Windows Server 2019. If you have existing containers built for Windows Server 1803 or earlier, they must be re-built to use Windows Server 2019.

 ## Objectives for Creating Cluster with Windows Support

-When setting up a custom cluster with support for Windows nodes and containers, complete the series of tasks below.
+To set up a custom cluster with support for Windows nodes and containers, you will need to complete the series of tasks listed below.

 <!-- TOC -->

 - [1. Provision Hosts](#1-provision-hosts)
- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
- [3. Create the Custom Cluster](#3-create-the-custom-cluster)
- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
- [5. Adding Windows Workers](#5-adding-windows-workers)
- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
-
+- [2. Create the Custom Cluster](#2-create-the-custom-cluster)
+- [3. Add Linux Master Node](#3-add-linux-master-node)
+- [4. Add Linux Worker Node](#4-add-linux-worker-node)
+- [5. Add Windows Workers](#5-add-windows-workers)
+- [6. Cloud-host VM Routes Configuration for Host Gateway Mode (Optional)](#6-cloud-hosted-vm-routes-configuration-for-host-gateway-mode)
+- [7. Configuration for Azure Files (Optional)](#7-configuration-for-azure-files)
 <!-- /TOC -->

 ## 1. Provision Hosts

-To begin provisioning a custom cluster with Windows support, prepare your host servers. Provision three nodes according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/)—two Linux, one Windows. Your hosts can be:
+To begin provisioning a custom cluster with Windows support, prepare your hosts. Provision three nodes according to our [installation requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/) - two Linux, one Windows. Your hosts can be:

 - Cloud-hosted VMs
 - VMs from virtualization clusters
 - Bare-metal servers

-The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we're installing all three roles on this node. Node 2 is also a Linux worker, which is responsible for Ingress support. Finally, the third node is your Windows worker, which will run your Windows applications.
+The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we’re installing all three roles on this node. The second node is also a Linux worker, which is responsible for running a DNS server, Ingress controller, Metrics server and Rancher Cluster agent. Finally, the third node is the Windows worker, which will run your Windows applications.

 Node    | Operating System | Future Cluster Role(s)
 --------|------------------|------
-Node 1  | Linux (Ubuntu Server 16.04 recommended)           | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
-Node 2  | Linux (Ubuntu Server 16.04 recommended)           | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
-Node 3  | Windows (*Windows Server 1803 required*)          | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
+Node 1  | Linux (Ubuntu Server 18.04 recommended)           | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
+Node 2  | Linux (Ubuntu Server 18.04 recommended)           | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
+Node 3  | Windows (Windows Server 2019 required)            | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
+
+>**Notes:**
+>
+>- If you are using AWS, you should choose *Microsoft Windows Server 2019 Base with Containers* as the Amazon Machine Image (AMI).
+>- If you are using GCE, you should choose *Windows Server 2019 Datacenter for Containers* as the OS image.

 ### Requirements

- You can view node requirements for Linux and Windows nodes in the [installation section]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/).
- All nodes in a virtualization cluster or a bare metal cluster must be connected using a layer 2 network.
- To support [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), your cluster must include at least one Linux node dedicated to the worker role.
- Although we recommend the three node architecture listed in the table above, you can add additional Linux and Windows workers to scale up your cluster for redundancy.
+- You can view the general requirements for Linux and Windows nodes in the [installation section]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/).
+- For **Host Gateway (L2bridge)** networking, it's best to use the same Layer 2 network for all nodes. Otherwise, you need to configure the route rules for them.
+- For **VXLAN (Overlay)** networking, you must confirm that the Windows Server 2019 has the [KB4489899](https://support.microsoft.com/en-us/help/4489899) hotfix installed. Most cloud-hosted VMs already have this hotfix.
+- Your cluster must include at least one Linux worker node to run Rancher Cluster agent, DNS, Metrics server and Ingress related containers.
+- Although we recommend the three node architecture listed in the table above, you can always add additional Linux and Windows workers to scale up your cluster for redundancy.
+
+## 2. Create the Custom Cluster
+
+To create a custom cluster that supports Windows nodes, follow the instructions in [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster), starting from [2. Create the Custom Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster). While completing the linked instructions, look for steps that requires special actions for Windows nodes, which are flagged with a note. These notes will link back here, to the special Windows instructions listed below.


-## 2. Cloud-hosted VM Networking Configuration
+1. Select `v1.14 or above` version for **Kubernetes Version**.

->**Note:** This step only applies to nodes hosted on cloud-hosted virtual machines. If you're using virtualization clusters or bare-metal servers, skip ahead to [Create the Custom Cluster](#3-create-the-custom-cluster).
+1. Select **Flannel** as **Network Provider**.

-If you're hosting your nodes on any of the cloud services listed below, you must disable the private IP address checks for both your Linux or Windows hosts on startup. To disable this check for each node, follow the directions provided by each service below.
+1. Select **Enable** for **Windows Support**.
+
+1. Choose the **Flannel Backend**. There are two options [**Host Gateway (L2bridge)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) and [**VXLAN (Overlay)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan). Default is **VXLAN (Overlay)** mode.
+
+If your nodes are hosted by a **Cloud Provider** and you want automation support such as load balancers or persistent storage devices, see [Selecting Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) for configuration info.
+
+Finally, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 6]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-6).
+
+>**Important:**  If you are using *Host Gateway (L2bridge)* mode and hosting your nodes on any of the cloud services listed below, you must disable the private IP address checks for both your Linux or Windows hosts on startup. To disable this check for each node, follow the directions provided by each service below.

 Service | Directions to disable private IP address checks
 --------|------------------------------------------------
 Amazon EC2 | [Disabling Source/Destination Checks](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)
 Google GCE | [Enabling IP Forwarding for Instances](https://cloud.google.com/vpc/docs/using-routes#canipforward)
-Azure VM | [Enable or Disable IP Forwarding](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding)
+Azure VM   | [Enable or Disable IP Forwarding](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding)

-## 3. Create the Custom Cluster
+## 3. Add Linux Master Node

-To create a custom cluster that supports Windows nodes, follow the instructions in [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster), starting from [2. Create the Custom Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster). While completing the linked instructions, look for steps that requires special actions for Windows nodes, which are flagged with a note. These notes will link back here, to the special Windows instructions listed in the subheadings below.
-
-
-### Enable the Windows Support Option
-
-While choosing **Cluster Options**, set **Windows Support (Experimental)** to **Enabled**.
-
-![Enable Windows Support]({{< baseurl >}}/img/rancher/enable-windows-support.png)
-
-After you select this option, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 6]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-6).
-
-### Networking Option
-
-When choosing a network provider for a cluster that supports Windows, the only option available is Flannel, as [host-gw](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) is needed for IP routing.
-
-![Flannel]({{< baseurl >}}/img/rancher/flannel.png)
-
-If your nodes are hosted by a cloud provider and you want automation support such as load balancers or persistent storage devices, see [Selecting Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) for configuration info.
-
-### Node Configuration
-
-The first node in your cluster should be a Linux host that fills the Control Plane role. This role must be fulfilled before you can add Windows hosts to your cluster. At minimum, the node must have this role enabled, but we recommend enabling all three. The following table lists our recommended settings (we'll provide the recommended settings for nodes 2 and 3 later).
+The first node in your cluster should be a Linux host that fills both *Control Plane* and *etcd* role. Both of these two roles must be fulfilled before you can add Windows hosts to your cluster. At a minimum, the node must have 2 roles enabled, but we recommend enabling all three. The following table lists our recommended settings (we'll provide the recommended settings for nodes 2 and 3 later).

 Option | Setting
 -------|--------
 Node Operating System | Linux
-Node Roles | etcd <br/> Control Plane <br/> Worker
-
-![Recommended Linux Control Plane Configuration]({{< baseurl >}}/img/rancher/linux-control-plane.png)
+Node Roles            | etcd <br/> Control Plane <br/> Worker (optional)

 When you're done with these configurations, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 8]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-8).

+## 4. Add Linux Worker Node

-
-## 4. Add Linux Host for Ingress Support
-
-After the initial provisioning of your custom cluster, your cluster only has a single Linux host. Add another Linux host, which will be used to support Ingress for your cluster.
+After the initial provisioning of your custom cluster, your cluster only has a single Linux host. Add another Linux host, which will be used to support *Rancher cluster agent*, *Metrics server*, *DNS* and *Ingress* for your cluster.

 1. Using the content menu, open the custom cluster your created in [2. Create the Custom Cluster](#2-create-the-custom-cluster).

@@ -128,9 +136,11 @@ After the initial provisioning of your custom cluster, your cluster only has a s

 1. From **Rancher**, click **Save**.

-**Result:** The worker role is installed on your Linux host, and the node registers with Rancher.
+**Result:** The **Worker** role is installed on your Linux host, and the node registers with Rancher.

-## 5. Adding Windows Workers
+
+
+## 5. Add Windows Workers

 You can add Windows hosts to a custom cluster by editing the cluster and choosing the **Windows** option.

@@ -150,11 +160,13 @@ You can add Windows hosts to a custom cluster by editing the cluster and choosin

 1. **Optional:** Repeat these instruction if you want to add more Windows nodes to your cluster.

-**Result:** The worker role is installed on your Windows host, and the node registers with Rancher.
+**Result:** The **Worker** role is installed on your Windows host, and the node registers with Rancher.

-## 6. Cloud-hosted VM Routes Configuration

-In Windows clusters, containers communicate with each other using the `host-gw` mode of Flannel. In `host-gw` mode, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
+
+## 6. Cloud-hosted VM Routes Configuration for Host Gateway Mode
+
+If you are using the [**Host Gateway (L2bridge)**](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) backend of Flannel, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.

 - When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work.

@@ -171,7 +183,46 @@ Then follow the instructions for each cloud provider to configure routing rules
 Service | Instructions
 --------|-------------
 Google GCE | For GCE, add a static route for each node: [Adding a Static Route](https://cloud.google.com/vpc/docs/using-routes#addingroute).
-Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined).
+Azure VM   | For Azure, create a routing table: [Custom Routes: User-defined](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined).


-` `
+## 7. Configuration for Azure Files
+
+If you are using Azure VMs for your nodes, you can use [Azure files](https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv) as a [storage class]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/volumes-and-storage/#adding-storage-classes) for the cluster. 
+
+In order to have the Azure platform create the required storage resources, follow these steps:
+
+1. [Configure the Azure cloud provider.]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers/#azure)
+
+1. Configure `kubectl` to connect to your cluster.
+
+1. Copy the `ClusterRole` and `ClusterRoleBinding` manifest for service account.
+
+        ---
+        apiVersion: rbac.authorization.k8s.io/v1
+        kind: ClusterRole
+        metadata:
+          name: system:azure-cloud-provider
+        rules:
+        - apiGroups: ['']
+          resources: ['secrets']
+          verbs:     ['get','create']
+        ---
+        apiVersion: rbac.authorization.k8s.io/v1
+        kind: ClusterRoleBinding
+        metadata:
+          name: system:azure-cloud-provider
+        roleRef:
+          kind: ClusterRole
+          apiGroup: rbac.authorization.k8s.io
+          name: system:azure-cloud-provider
+        subjects:
+        - kind: ServiceAccount
+          name: persistent-volume-binder
+          namespace: kube-system
+
+1. Create these in your cluster using one of the follow command.
+
+    ```
+    # kubectl create -f <MANIFEST>
+    ```
@@ -0,0 +1,175 @@
+---
+title: v2.1.x and v2.2.x Windows Documentation (Experimental)
+weight: 9100
+---
+
+>**Note:** This section describes the Windows feature as implemented in Rancher v2.1.x and v2.2.x. If you are using Rancher v2.3 or later, where Windows have been significantly improved, please refer to the new documentation for [v2.3 or later]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/).
+
+_Available from v2.1.0 to v2.1.9 and v2.2.0 to v2.2.2_
+
+>**Important:**
+>
+>Support for Windows nodes is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using Windows nodes in a production environment.
+
+When provisioning a [custom cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/custom-clusters/) using Rancher, you can use a mix of Linux and Windows hosts as your cluster nodes.
+
+This guide walks you through create of a custom cluster that includes 3 nodes: a Linux node, which serves as a Kubernetes control plane node; another Linux node, which serves as a Kubernetes worker used to support Ingress for the cluster; and a Windows node, which is assigned the Kubernetes worker role and runs your Windows containers.
+
+>**Notes:**
+>
+>- For a summary of Kubernetes features supported in Windows, see [Using Windows in Kubernetes](https://kubernetes.io/docs/setup/windows/intro-windows-in-kubernetes/).
+>- Windows containers must run on Windows Server 1803 nodes. Windows Server 1709 and earlier versions do not support Kubernetes properly.
+>- Containers built for Windows Server 1709 or earlier do not run on Windows Server 1803. You must build containers on Windows Server 1803 to run these containers on Windows Server 1803.
+
+
+
+## Objectives for Creating Cluster with Windows Support
+
+When setting up a custom cluster with support for Windows nodes and containers, complete the series of tasks below.
+
+<!-- TOC -->
+
+- [1. Provision Hosts](#1-provision-hosts)
+- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration)
+- [3. Create the Custom Cluster](#3-create-the-custom-cluster)
+- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support)
+- [5. Adding Windows Workers](#5-adding-windows-workers)
+- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration)
+
+<!-- /TOC -->
+
+## 1. Provision Hosts
+
+To begin provisioning a custom cluster with Windows support, prepare your host servers. Provision three nodes according to our [requirements]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/)—two Linux, one Windows. Your hosts can be:
+
+- Cloud-hosted VMs
+- VMs from virtualization clusters
+- Bare-metal servers
+
+The table below lists the [Kubernetes roles]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) you'll assign to each host, although you won't enable these roles until further along in the configuration process—we're just informing you of each node's purpose. The first node, a Linux host, is primarily responsible for managing the Kubernetes control plane, although, in this use case, we're installing all three roles on this node. Node 2 is also a Linux worker, which is responsible for Ingress support. Finally, the third node is your Windows worker, which will run your Windows applications.
+
+Node    | Operating System | Future Cluster Role(s)
+--------|------------------|------
+Node 1  | Linux (Ubuntu Server 16.04 recommended)           | [Control Plane]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#control-plane-nodes), [etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#etcd), [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
+Node 2  | Linux (Ubuntu Server 16.04 recommended)           | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes) (This node is used for Ingress support)
+Node 3  | Windows (*Windows Server 1803 required*)          | [Worker]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#worker-nodes)
+
+### Requirements
+
+- You can view node requirements for Linux and Windows nodes in the [installation section]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/).
+- All nodes in a virtualization cluster or a bare metal cluster must be connected using a layer 2 network.
+- To support [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), your cluster must include at least one Linux node dedicated to the worker role.
+- Although we recommend the three node architecture listed in the table above, you can add additional Linux and Windows workers to scale up your cluster for redundancy.
+
+
+## 2. Cloud-hosted VM Networking Configuration
+
+>**Note:** This step only applies to nodes hosted on cloud-hosted virtual machines. If you're using virtualization clusters or bare-metal servers, skip ahead to [Create the Custom Cluster](#3-create-the-custom-cluster).
+
+If you're hosting your nodes on any of the cloud services listed below, you must disable the private IP address checks for both your Linux or Windows hosts on startup. To disable this check for each node, follow the directions provided by each service below.
+
+Service | Directions to disable private IP address checks
+--------|------------------------------------------------
+Amazon EC2 | [Disabling Source/Destination Checks](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck)
+Google GCE | [Enabling IP Forwarding for Instances](https://cloud.google.com/vpc/docs/using-routes#canipforward)
+Azure VM | [Enable or Disable IP Forwarding](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface#enable-or-disable-ip-forwarding)
+
+## 3. Create the Custom Cluster
+
+To create a custom cluster that supports Windows nodes, follow the instructions in [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster), starting from [2. Create the Custom Cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#2-create-the-custom-cluster). While completing the linked instructions, look for steps that requires special actions for Windows nodes, which are flagged with a note. These notes will link back here, to the special Windows instructions listed in the subheadings below.
+
+
+### Enable the Windows Support Option
+
+While choosing **Cluster Options**, set **Windows Support (Experimental)** to **Enabled**.
+
+After you select this option, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 6]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-6).
+
+### Networking Option
+
+When choosing a network provider for a cluster that supports Windows, the only option available is Flannel, as [host-gw](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) is needed for IP routing.
+
+If your nodes are hosted by a cloud provider and you want automation support such as load balancers or persistent storage devices, see [Selecting Cloud Providers]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/cloud-providers) for configuration info.
+
+### Node Configuration
+
+The first node in your cluster should be a Linux host that fills the Control Plane role. This role must be fulfilled before you can add Windows hosts to your cluster. At minimum, the node must have this role enabled, but we recommend enabling all three. The following table lists our recommended settings (we'll provide the recommended settings for nodes 2 and 3 later).
+
+Option | Setting
+-------|--------
+Node Operating System | Linux
+Node Roles | etcd <br/> Control Plane <br/> Worker
+
+![Recommended Linux Control Plane Configuration]({{< baseurl >}}/img/rancher/linux-control-plane.png)
+
+When you're done with these configurations, resume [Creating a Cluster with Custom Nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#create-the-custom-cluster) from [step 8]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/#step-8).
+
+
+
+## 4. Add Linux Host for Ingress Support
+
+After the initial provisioning of your custom cluster, your cluster only has a single Linux host. Add another Linux host, which will be used to support Ingress for your cluster.
+
+1. Using the content menu, open the custom cluster your created in [2. Create the Custom Cluster](#2-create-the-custom-cluster).
+
+1. From the main menu, select **Nodes**.
+
+1. Click **Edit Cluster**.
+
+1. Scroll down to **Node Operating System**. Choose **Linux**.
+
+1. Select the **Worker** role.
+
+1. Copy the command displayed on screen to your clipboard.
+
+1. Log in to your Linux host using a remote Terminal connection. Run the command copied to your clipboard.
+
+1. From **Rancher**, click **Save**.
+
+**Result:** The worker role is installed on your Linux host, and the node registers with Rancher.
+
+## 5. Adding Windows Workers
+
+You can add Windows hosts to a custom cluster by editing the cluster and choosing the **Windows** option.
+
+1. From the main menu, select **Nodes**.
+
+1. Click **Edit Cluster**.
+
+1. Scroll down to **Node Operating System**. Choose **Windows**.
+
+1. Select the **Worker** role.
+
+1. Copy the command displayed on screen to your clipboard.
+
+1. Log in to your Windows host using your preferred tool, such as [Microsoft Remote Desktop](https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients). Run the command copied to your clipboard in the **Command Prompt (CMD)**.
+
+1. From Rancher, click **Save**.
+
+1. **Optional:** Repeat these instruction if you want to add more Windows nodes to your cluster.
+
+**Result:** The worker role is installed on your Windows host, and the node registers with Rancher.
+
+## 6. Cloud-hosted VM Routes Configuration
+
+In Windows clusters, containers communicate with each other using the `host-gw` mode of Flannel. In `host-gw` mode, all containers on the same node belong to a private subnet, and traffic routes from a subnet on one node to a subnet on another node through the host network.
+
+- When worker nodes are provisioned on AWS, virtualization clusters, or bare metal servers, make sure they belong to the same layer 2 subnet. If the nodes don't belong to the same layer 2 subnet, `host-gw` networking will not work.
+
+- When worker nodes are provisioned on GCE or Azure, they are not on the same layer 2 subnet. Nodes on GCE and Azure belong to a routable layer 3 network. Follow the instructions below to configure GCE and Azure so that the cloud network knows how to route the host subnets on each node.
+
+To configure host subnet routing on GCE or Azure, first run the following command to find out the host subnets on each worker node:
+
+```bash
+kubectl get nodes -o custom-columns=nodeName:.metadata.name,nodeIP:status.addresses[0].address,routeDestination:.spec.podCIDR
+```
+
+Then follow the instructions for each cloud provider to configure routing rules for each node:
+
+Service | Instructions
+--------|-------------
+Google GCE | For GCE, add a static route for each node: [Adding a Static Route](https://cloud.google.com/vpc/docs/using-routes#addingroute).
+Azure VM | For Azure, create a routing table: [Custom Routes: User-defined](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview#user-defined).
+
+
+` `
@@ -7,7 +7,7 @@ aliases:

 Rancher needs to be configured to use the private registry in order to provision any [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) or [Rancher tools]({{< baseurl >}}/rancher/v2.x/en/tools/).

->**Note:** If you want to configure Rancher for your private registry when when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`.
+>**Note:** If you want to configure Rancher to use your private registry when starting the rancher/rancher container, you can use the environment variable `CATTLE_SYSTEM_DEFAULT_REGISTRY`.

 1. Log into Rancher and configure the default admin password.

@@ -6,7 +6,7 @@ aliases:

 ## A. Prepare System Charts

-The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as moniotring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach and configure Rancher to use that repository.
+The [System Charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. To be able to use these features in an air gap install, you will need to mirror the `system-charts` repository to a location in your network that Rancher can reach and configure Rancher to use that repository.

 ## B. Configure System Charts

@@ -15,7 +15,7 @@ kubectl -n cattle-system create secret tls tls-rancher-ingress \
  --key=tls.key
 ```

-> **Note:** If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. Replacing the certificate is only supported if the new certificate is signed by the same CA as the certificate currently in use.
+> **Note:** If you want to replace the certificate, you can delete the `tls-rancher-ingress` secret using `kubectl -n cattle-system delete secret tls-rancher-ingress` and add a new one using the command shown above. If you are using a private CA signed certificate, replacing the certificate is only possible if the new certificate is signed by the same CA as the certificate currently in use.

 ### Using a Private CA Signed Certificate

@@ -198,7 +198,7 @@ If you are using a Certificate Signed By A Recognized Certificate Authority, you

 ## 8. Configure FQDN

-There is one reference to `<FQDN>` in the RKE config file. Replace this reference with the FQDN you chose in in [3. Configure DNS](#3-configure-dns).
+There is one reference to `<FQDN>` in the RKE config file. Replace this reference with the FQDN you chose in [3. Configure DNS](#3-configure-dns).

 1. Open `rancher-cluster.yml`.

@@ -28,7 +28,7 @@ When using High Availability Installation, the environment variables need to be
 * [High Availability Installation with External Load Balancer (TCP/Layer 4) RKE Config File Template]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install/#5-download-rke-config-file-template)
 * [High Availability Installation with External Load Balancer (HTTPS/Layer 7) RKE Config File Template]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install-external-lb/#5-download-rke-config-file-template)

-The environment variables should be defined in the `Deployment` inside the RKE Config File Template. You only have to add the the part starting with `env:` to (but not including) `ports:`. Make sure the indentation is identical to the preceding `name:`. Required values for `NO_PROXY` are:
+The environment variables should be defined in the `Deployment` inside the RKE Config File Template. You only have to add the part starting with `env:` to (but not including) `ports:`. Make sure the indentation is identical to the preceding `name:`. Required values for `NO_PROXY` are:

 * `localhost`
 * `127.0.0.1`
@@ -74,6 +74,7 @@ These ports are typically opened on your Kubernetes nodes, regardless of what ty
 |    TCP   	|       2379       	| etcd client requests                           	|
 |    TCP   	|       2380       	| etcd peer communication                         	|
 |    UDP   	|       8472       	| Canal/Flannel VXLAN overlay networking          	|
+|    UDP   	|       4789       	| Flannel VXLAN overlay networking on Windows cluster |
 |    TCP   	|       9099       	| Canal/Flannel livenessProbe/readinessProbe      	|
 |    TCP   	|       6783       	| Weave Port      	|
 |    UDP   	|       6783-6784   | Weave UDP Ports      	|
@@ -11,17 +11,17 @@ Whether you're configuring Rancher to run in a single-node or high-availability
 <br>
 Rancher is tested on the following operating systems and their subsequent non-major releases with a supported version of [Docker](https://www.docker.com/).

-*   Ubuntu 16.04 (64-bit)
+*   Ubuntu 16.04 (64-bit x86)
  * Docker 17.03.x, 18.06.x, 18.09.x
-*   Ubuntu 18.04 (64-bit)
+*   Ubuntu 18.04 (64-bit x86)
  * Docker 18.06.x, 18.09.x
-*   Red Hat Enterprise Linux (RHEL)/CentOS 7.6 (64-bit)
+*   Red Hat Enterprise Linux (RHEL)/CentOS 7.6 (64-bit x86)
  * RHEL Docker 1.13
  * Docker 17.03.x, 18.06.x, 18.09.x
-*   RancherOS 1.5.1 (64-bit)
+*   RancherOS 1.5.1 (64-bit x86)
  * Docker 17.03.x, 18.06.x, 18.09.x
-*   Windows Server version 1803 (64-bit)
-  * Docker 17.06
+*   Windows Server 2019 (64-bit x86)
+  * Docker 18.09 
  * _Experimental, see [Configuring Custom Clusters for Windows]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/)_

 If you are using RancherOS, make sure you switch the Docker engine to a supported version using:<br>
@@ -32,7 +32,9 @@ sudo ros engine list
 # Switch to a supported version
 sudo ros engine switch docker-18.09.2
 ```
-
+See [Running on ARM64 (Experimental)]({{< baseurl >}}/rancher/v2.x/en/installation/arm64-platform/) if you plan to run Rancher on ARM64.
+<br>
+<br>
 [Docker Documentation: Installation Instructions](https://docs.docker.com/)
 <br>
 <br>
@@ -88,7 +88,7 @@ docker run -d --restart=unless-stopped \
 {{% /accordion %}}
 {{% accordion id="option-d" label="Option D-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.
+For production environments, you also have the option of using [Let's Encrypt](https://letsencrypt.org/) certificates. Let's Encrypt uses an http-01 challenge to verify that you have control over your domain. You can confirm that you control the domain by pointing the hostname that you want to use for Rancher access (for example, `rancher.mydomain.com`) to the IP of the machine it is running on. You can bind the hostname to the IP address by creating an A record in DNS.

 >**Prerequisites:**
 >
@@ -97,7 +97,7 @@ For production environments, you also have the options of using [Let's Encrypt](
 >- 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 `<YOUR.DNS.NAME>` with your your domain.
+After you fulfill the prerequisites, you can install Rancher using a Let's Encrypt certificate by running the following command. Replace `<YOUR.DNS.NAME>` with your domain.

 	docker run -d --restart=unless-stopped \
 	  -p 80:80 -p 443:443 \
@@ -186,7 +186,7 @@ If you are visiting this page to complete an air gap installation, you must pre-

 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.
+If a node is added to a cluster, it deploys the nginx ingress controller which will use port 80 and 443. This will conflict with the default ports we advise to expose for the `rancher/rancher` container.

 Please note that this setup is not recommended for production use, but can be convenient for development/demo purposes.

@@ -4,7 +4,7 @@ weight: 252
 aliases:
 - /rancher/v2.x/en/installation/single-node-install-external-lb/
 ---
-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.
+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 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) instead.
@@ -405,7 +405,7 @@ spec:
 1. Test that pod autoscaling works as intended.<br/></br>
  **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.
+Use your load testing tool to scale up to two pods based on CPU Usage.

 1. View your HPA.
    ```
@@ -491,7 +491,7 @@ Use your load testing tool to upspace to 3 pods based on CPU usage with `horizon
      ```
  {{% /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).
+Use your load testing 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.
  ```
@@ -794,7 +794,7 @@ To create HPA resources based on resource metrics such as CPU and memory use, yo
    ```
    # kubectl -n kube-system logs metrics-server-6fbfb84cdd-t2fk9
    ```
-    Then review the log to confirm that that the `metrics-server` package is running.
+    Then review the log to confirm 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
@@ -816,7 +816,7 @@ To create HPA resources based on resource metrics such as CPU and memory use, yo
    ```
    # kubectl get --raw /k8s/clusters/<CLUSTER_ID>/apis/metrics.k8s.io/v1beta1
    ```
-    If the the API is working correctly, you should receive output similar to the output below.
+    If 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"]}]}
    ```
@@ -825,7 +825,7 @@ To create HPA resources based on resource metrics such as CPU and memory use, yo
    ```
    # kubectl get --raw /apis/metrics.k8s.io/v1beta1
    ```
-    If the the API is working correctly, you should receive output similar to the output below.
+    If 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"]}]}
    ```
@@ -24,7 +24,7 @@ Load Balancers have a couple of limitations you should be aware of:

 - Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive.

- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), you must host your load balancer with the same cloud provider. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters:
+- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), the load balancer must be running within that cloud provider's infrastructure. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters:


    - [Support for Layer-4 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-4-load-balancing)
@@ -5,7 +5,7 @@ weight: 2520

 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.
+Although you assign resources at the project level so that each namespace 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:

@@ -28,7 +28,7 @@ Create a new namespace to isolate apps and resources in a project.

 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.
+    >**Tip:** As a best practice, we recommend creating namespaces from the project level. However, cluster owners and members can create them from the cluster level as well.

 1. From the main menu, select **Namespace**. The click **Add Namespace**.

@@ -31,7 +31,7 @@ The following steps will quickly deploy a Rancher Server with a single node clus

 6. Run `terraform init`.

-7. To initiate the creation of the environment, run `terraform apply`. Then wait for the the following output:
+7. To initiate the creation of the environment, run `terraform apply`. Then wait for the following output:

 	```
 	Apply complete! Resources: 2 added, 0 changed, 0 destroyed. 
@@ -115,4 +115,4 @@ When you run the command below, all the resources listed [above](#remove) will b
 | ---------------------------------------------- | ------------
 | `--kubeconfig <KUBECONFIG_PATH>, -c <KUBECONFIG_PATH>` | The cluster's kubeconfig file
 | `--namespace <NAMESPACE>, -n cattle-system`    | Rancher 2.x deployment namespace (`<NAMESPACE>`). If no namespace is defined, the options defaults to `cattle-system`.
-| `--force`                                      | Skips the the interactive removal confirmation and removes the Rancher deployment without prompt.
+| `--force`                                      | Skips the interactive removal confirmation and removes the Rancher deployment without prompt.
@@ -30,7 +30,7 @@ This section contains information to help you troubleshoot issues when using Ran

 - [Rancher HA]({{< baseurl >}}/rancher/v2.x/en/troubleshooting/rancherha/)

-    If you experience issues issues with your [High Availability (HA) Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/)
+    If you experience issues with your [High Availability (HA) Install]({{< baseurl >}}/rancher/v2.x/en/installation/ha/)

 - [Imported clusters]({{< baseurl >}}/rancher/v2.x/en/troubleshooting/imported-clusters/)

@@ -58,16 +58,22 @@ The cluster state (`/var/lib/etcd`) contains wrong information to join the clust

 ### etcd cluster and connectivity checks

-If any of the commands respond with `Error:  context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster)
+The address where etcd is listening depends on the address configuration of the host etcd is running on. If an internal address is configured for the host etcd is running on, the endpoint for `etcdctl` needs to be specified explicitly. If any of the commands respond with `Error:  context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster)

 * Check etcd members on all nodes

 Output should contain all the nodes with the `etcd` role and the output should be identical on all nodes.

+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl member list
 ```

+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list"
+```
+
 Example output:
 ```
 xxx, started, etcd-xxx, https://IP:2380, https://IP:2379,https://IP:4001
@@ -79,10 +85,16 @@ xxx, started, etcd-xxx, https://IP:2380, https://IP:2379,https://IP:4001

 The values for `RAFT TERM` should be equal and `RAFT INDEX` should be not be too far apart from each other.

+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table
 ```

+Command when internal address is configured on the host:
+```
+docker exec etcd etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table
+```
+
 Example output:
 ```
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
@@ -96,10 +108,16 @@ Example output:

 * Check endpoint health

+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl endpoint health --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")
 ```

+Command when internal address is configured on the host:
+```
+docker exec etcd etcdctl endpoint health --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")
+```
+
 Example output:
 ```
 https://IP:2379 is healthy: successfully committed proposal: took = 2.113189ms
@@ -109,6 +127,7 @@ https://IP:2379 is healthy: successfully committed proposal: took = 2.451201ms

 * Check connectivity on port TCP/2379

+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5"); do
  echo "Validating connection to ${endpoint}/health";
@@ -116,8 +135,17 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5
 done
 ```

+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5"); do
+  echo "Validating connection to ${endpoint}/health";
+  curl -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/health";
+done
+```
+
 If you are running on an operating system without `curl` (for example, RancherOS), you can use the following command which uses a Docker container to run the `curl` command.

+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5"); do
  echo "Validating connection to ${endpoint}/health";
@@ -125,6 +153,14 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5
 done
 ```

+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5"); do
+  echo "Validating connection to ${endpoint}/health";
+  docker run --net=host -v /opt/rke/etc/kubernetes/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/health"
+done
+```
+
 Example output:
 ```
 Validating connection to https://IP:2379/health
@@ -137,6 +173,7 @@ Validating connection to https://IP:2379/health

 * Check connectivity on port TCP/2380

+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4"); do
  echo "Validating connection to ${endpoint}/version";
@@ -144,8 +181,17 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4
 done
 ```

+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f4"); do
+  echo "Validating connection to ${endpoint}/version";
+  curl -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/version";
+done
+```
+
 If you are running on an operating system without `curl` (for example, RancherOS), you can use the following command which uses a Docker container to run the `curl` command.

+Command when no internal address is configured on the host:
 ```
 for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4"); do
  echo "Validating connection to ${endpoint}/version";
@@ -153,6 +199,14 @@ for endpoint in $(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f4
 done
 ```

+Command when internal address is configured on the host:
+```
+for endpoint in $(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f4"); do
+  echo "Validating connection to ${endpoint}/version";
+  docker run --net=host -v /opt/rke/etc/kubernetes/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -w "\n" --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) "${endpoint}/version"
+done
+```
+
 Example output:
 ```
 Validating connection to https://IP:2380/version
@@ -167,10 +221,16 @@ Validating connection to https://IP:2380/version

 etcd will trigger alarms, for instance when it runs out of space.

+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl alarm list
 ```

+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT alarm list"
+```
+
 Example output when NOSPACE alarm is triggered:
 ```
 memberID:x alarm:NOSPACE
@@ -186,11 +246,18 @@ Resolution:

 * Compact the keyspace

+Command when no internal address is configured on the host:
 ```
 rev=$(docker exec etcd etcdctl endpoint status --write-out json | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*')
 docker exec etcd etcdctl compact "$rev"
 ```

+Command when internal address is configured on the host:
+```
+rev=$(docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT endpoint status --write-out json | egrep -o '\"revision\":[0-9]*' | egrep -o '[0-9]*'")
+docker exec etcd sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT compact \"$rev\""
+```
+
 Example output:
 ```
 compacted revision xxx
@@ -198,10 +265,16 @@ compacted revision xxx

 * Defrag all etcd members

+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl defrag --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")
 ```

+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl defrag --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','")"
+```
+
 Example output:
 ```
 Finished defragmenting etcd member[https://IP:2379]
@@ -211,10 +284,16 @@ Finished defragmenting etcd member[https://IP:2379]

 * Check endpoint status

+Command when no internal address is configured on the host:
 ```
 docker exec etcd etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table
 ```

+Command when internal address is configured on the host:
+```
+docker exec etcd sh -c "etcdctl endpoint status --endpoints=$(docker exec etcd /bin/sh -c "etcdctl --endpoints=\$ETCDCTL_ENDPOINT member list | cut -d, -f5 | sed -e 's/ //g' | paste -sd ','") --write-out table"
+```
+
 Example output:
 ```
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
@@ -226,6 +305,32 @@ Example output:
 +-----------------+------------------+---------+---------+-----------+-----------+------------+
 ```

+### Log level
+
+The log level of etcd can be changed dynamically via the API. You can configure debug logging using the commands below.
+
+Command when no internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"DEBUG"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) https://localhost:2379/config/local/log
+```
+
+Command when internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"DEBUG"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv $ETCDCTL_ENDPOINT)/config/local/log
+```
+
+To reset the log level back to the default (`INFO`), you can use the following command.
+
+Command when no internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) https://localhost:2379/config/local/log
+```
+
+Command when internal address is configured on the host:
+```
+curl -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv $ETCDCTL_ENDPOINT)/config/local/log
+```
+
 ## controlplane

 This section applies to nodes with the `controlplane` role.
@@ -20,28 +20,30 @@ Run the command below and check the following:


 ```
-kubectl get nodes
+kubectl get nodes -o wide
 ``` 

 Example output:

 ```
-NAME                              STATUS    ROLES          AGE       VERSION   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
-etcd-0                            Ready     etcd           2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-etcd-1                            Ready     etcd           2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-etcd-2                            Ready     etcd           2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-controlplane-0                    Ready     controlplane   2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-controlplane-1                    Ready     controlplane   1m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-worker-0                          Ready     worker         2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
-worker-1                          Ready     worker         2m        v1.11.5   <none>        Ubuntu 16.04.5 LTS   4.4.0-138-generic   docker://17.3.2
+NAME             STATUS   ROLES          AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
+controlplane-0   Ready    controlplane   31m   v1.13.5   138.68.188.91    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
+etcd-0           Ready    etcd           31m   v1.13.5   138.68.180.33    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
+worker-0         Ready    worker         30m   v1.13.5   139.59.179.88    <none>        Ubuntu 18.04.2 LTS   4.15.0-47-generic   docker://18.9.5
 ```

 #### Get node conditions

+Run the command below to list nodes with [Node Conditions](https://kubernetes.io/docs/concepts/architecture/nodes/#condition)
+
+```
+kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}'
+```
+
 Run the command below to list nodes with [Node Conditions](https://kubernetes.io/docs/concepts/architecture/nodes/#condition) that are active that could prevent normal operation.

 ```
-kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{if ne .type "Ready"}}{{if eq .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{end}}{{end}}{{end}}'
+kubectl get nodes -o go-template='{{range .items}}{{$node := .}}{{range .status.conditions}}{{if ne .type "Ready"}}{{if eq .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{":"}}{{.status}}{{"\n"}}{{end}}{{else}}{{if ne .status "True"}}{{$node.metadata.name}}{{": "}}{{.type}}{{": "}}{{.status}}{{"\n"}}{{end}}{{end}}{{end}}{{end}}'
 ```

 Example output:
@@ -15,7 +15,7 @@ During upgrade, you'll enter a series of commands, filling placeholders with dat
 docker run  --volumes-from rancher-data -v $PWD:/backup alpine tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
 ```

-In this command, `<RANCHER_VERSION>-<DATE>` is the the version number and date of creation for a backup of Rancher.
+In this command, `<RANCHER_VERSION>-<DATE>` is the version number and date of creation for a backup of Rancher.

 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](#completing-the-upgrade).

@@ -25,9 +25,11 @@ API Keys are composed of four components:

 2. Click **Add Key**.

-3. **Optional:** Enter a description for the API key and select an expiration period. We recommend setting an expiration date.
+3. **Optional:** Enter a description for the API key and select an expiration period or a scope. We recommend setting an expiration date.

    The API key won't be valid after expiration. Shorter expiration periods are more secure.
+    
+    A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authroized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints]({{< baseurl >}}/v2.x/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint) for more information.

 4. Click **Create**.

@@ -183,7 +183,7 @@ Rancher v1.6 included the ability to deploy [global services]({{< baseurl >}}/ra

 In Rancher v2.x, you can schedule a pod to each node using a [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), which is a specific type of workload <!-- link -->). A _DaemonSet_ functions exactly like a Rancher v1.6 global service. The Kubernetes scheduler deploys a pod on each node of the cluster, and as new nodes are added, the scheduler will start new pods on them provided they match the scheduling requirements of the workload. Additionally, in v2.x, you can also limit a DaemonSet to be deployed to nodes that have a specific label.

-To create a daemonset while configuring a workload, choose **Run one pod on each node** from the the **Workload Type** options.
+To create a daemonset while configuring a workload, choose **Run one pod on each node** from the **Workload Type** options.

 ### Scheduling Pods Using Resource Constraints

@@ -80,7 +80,7 @@ INFO[0033] [worker] Successfully restarted Worker Plane..

 ### Rotating the CA and all service certificates

-If the CA certificate needs to be rotated, you are required to rotate all the services certificates as they need to be signed with the newly rotated CA certificate. To include rotating the CA with the service certificates, add the `--rotate-ca` option. After the the CA and all the service certificates are rotated, these services will automatically be restarted to start using the new certificate.
+If the CA certificate needs to be rotated, you are required to rotate all the services certificates as they need to be signed with the newly rotated CA certificate. To include rotating the CA with the service certificates, add the `--rotate-ca` option. After the CA and all the service certificates are rotated, these services will automatically be restarted to start using the new certificate.

 Rotating the CA certificate will result in restarting other system pods, that will also use the new CA certificate. This includes:

@@ -122,5 +122,3 @@ $ echo $SSH_AUTH_SOCK
 ### Add-ons Job Timeout

 You can define [add-ons]({{< baseurl >}}/rke/latest/en/config-options/add-ons/) to be deployed after the Kubernetes cluster comes up, which uses Kubernetes [jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/). RKE will stop attempting to retrieve the job status after the timeout, which is in seconds. The default timeout value is `30` seconds.
-
-```yaml
@@ -18,7 +18,7 @@ RKE only adds additional add-ons when using `rke up` multiple times. RKE does **

 As of v0.1.8, RKE will update an add-on if it is the same name.

-Prior to v0.1.8, update any add-ons by by using `kubectl edit`.
+Prior to v0.1.8, update any add-ons by using `kubectl edit`.


 ## Critical and Non-Critical Add-ons
@@ -18,7 +18,7 @@ RKE only adds additional add-ons when using `rke up` multiple times. RKE does **

 As of v0.1.8, RKE will update an add-on if it is the same name.

-Prior to v0.1.8, update any add-ons by by using `kubectl edit`.
+Prior to v0.1.8, update any add-ons by using `kubectl edit`.

 ## In-line Add-ons

@@ -158,14 +158,18 @@ $ rke etcd snapshot-restore --config cluster.yml --name mysnapshot

 _Available as of v0.2.0_

+> **Note:** Ensure your `cluster.rkestate` is present before starting the restore, as this contains your certificate data for the cluster
+
 When restoring etcd from a snapshot located in S3, the command needs the S3 information in order to connect to the S3 backend and retrieve the snapshot.

-```
+```shell
 $ rke etcd snapshot-restore --config cluster.yml --name snapshot-name \
 --s3 --access-key S3_ACCESS_KEY --secret-key S3_SECRET_KEY \
 --bucket-name s3-bucket-name --s3-endpoint s3.amazonaws.com
 ```
-## Example
+> **Note:** if you were restoring a cluster that had rancher installed the UI should start-up after a few minutes; you don't need to re-run helm.
+
+### Example Scenario of restoring from a Local Snapshot

 In this example, the Kubernetes cluster was deployed on two AWS nodes.

@@ -185,7 +189,7 @@ $ rke etcd snapshot-save --name snapshot.db --config cluster.yml
 ![etcd snapshot]({{< baseurl >}}/img/rke/rke-etcd-backup.png)


-### Store the Snapshot Externally to S3
+### Store the Snapshot Externally in S3

 As of v0.2.0, this step is no longer required, as RKE can upload and download snapshots automatically from S3 by adding in [S3 options](#options-for-rke-etcd-snapshot-save) when running the `rke etcd snapshot-save` command.

@@ -253,7 +257,7 @@ nodes:
 After the new node is added to the `cluster.yml`, run `rke etcd snapshot-restore` to launch `etcd` from the backup. The snapshot and `pki.bundle.tar.gz` file are expected to be saved at `/opt/rke/etcd-snapshots`.
 As of v0.2.0, if you want to directly retrieve the snapshot from S3, add in the [S3 options](#options-for-rke-etcd-snapshot-restore).

-> **Note:** As of v0.2.0, the file **pki.bundle.tar.gz** is no longer required for the restore process.
+> **Note:** As of v0.2.0, the file **pki.bundle.tar.gz** is no longer required for the restore process as the certificates required to restore are preserved within the `cluster.rkestate` 

 ```
 $ rke etcd snapshot-restore --name snapshot.db --config cluster.yml
@@ -294,3 +298,6 @@ 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**.
+
+
+
@@ -99,7 +99,7 @@ rpm -q docker-ce
 When using the upstream Docker packages, please follow [Manage Docker as a non-root user](https://docs.docker.com/install/linux/linux-postinstall/#manage-docker-as-a-non-root-user).

 #### Using RHEL/CentOS packaged Docker
-If you are using the Docker Docker package supplied by Red Hat / CentOS, the package name is `docker`. You can check the installed package by executing:
+If you are using the Docker package supplied by Red Hat / CentOS, the package name is `docker`. You can check the installed package by executing:

 ```
 rpm -q docker
@@ -21,8 +21,8 @@
          <td style="background-color: #3497DA; color:#ffffff;">git.rancher.io <sup>(2)</sup>:<br>35.160.43.145:32<br>35.167.242.46:32<br>52.33.59.17:32</td>
        </tr>
        <tr>
-          <td rowspan="5">etcd Plane Nodes</td>
-          <td rowspan="5" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
+          <td rowspan="6">etcd Plane Nodes</td>
+          <td rowspan="6" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
          <td style="background-color: #3497DA; color:#ffffff;">2379 TCP</td>
          <td></td>
          <td></td>
@@ -45,6 +45,10 @@
          <td colspan="3" style="background-color: #3497DA; color:#ffffff;">8472 UDP</td>
          <td></td>
        </tr>
+        <tr>
+          <td colspan="3" style="background-color: #3497DA; color:#ffffff;">4789 UDP <sup>(7)</sup></td>
+          <td></td>
+        </tr>
        <tr>
          <td style="background-color: #3497DA; color:#ffffff;">9099 TCP <sup>(4)</sup></td>
          <td></td>
@@ -52,8 +56,8 @@
          <td></td>
        </tr>
        <tr>
-          <td rowspan="7">Control Plane Nodes</td>
-          <td rowspan="7" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
+          <td rowspan="8">Control Plane Nodes</td>
+          <td rowspan="8" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
          <td style="background-color: #3497DA; color:#ffffff;">2379 TCP</td>
          <td></td>
          <td></td>
@@ -76,6 +80,10 @@
          <td colspan="3" style="background-color: #3497DA; color:#ffffff;">8472 UDP</td>
          <td></td>
        </tr>
+        <tr>
+          <td colspan="3" style="background-color: #3497DA; color:#ffffff;">4789 UDP <sup>(7)</sup></td>
+          <td></td>
+        </tr>
        <tr>
          <td colspan="3" style="background-color: #3497DA; color:#ffffff;">10250 TCP</td>
          <td></td>
@@ -93,8 +101,8 @@
          <td></td>
        </tr>
        <tr>
-          <td rowspan="4">Worker Plane Nodes</td>
-          <td rowspan="4" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
+          <td rowspan="5">Worker Plane Nodes</td>
+          <td rowspan="5" style="background-color: #3497DA; color:#ffffff;">443 TCP <sup>(3)</sup></td>
          <td></td>
          <td style="background-color: #3497DA; color:#ffffff;">6443 TCP</td>
          <td></td>
@@ -105,6 +113,10 @@
          <td colspan="3" style="background-color: #3497DA; color:#ffffff;">8472 UDP</td>
          <td></td>
        </tr>
+        <tr>
+          <td colspan="3" style="background-color: #3497DA; color:#ffffff;">4789 UDP <sup>(7)</sup></td>
+          <td></td>
+        </tr>
        <tr>
          <td></td>
          <td></td>
@@ -175,7 +187,7 @@
          <td></td>
        </tr>
        <tr>
-          <td colspan="7">Notes:<br><br>1. Nodes running standalone server or Rancher HA deployment.<br>2. Required to fetch Rancher chart library.<br>3. Only without external load balancer.<br>4. Local traffic to the node itself (not across nodes).<br>5. Load balancer / proxy that handles tragging to the Rancher UI / API.<br>6. Only if SSL is not terminated at external load balancer.</td>
+          <td colspan="7">Notes:<br><br>1. Nodes running standalone server or Rancher HA deployment.<br>2. Required to fetch Rancher chart library.<br>3. Only without external load balancer.<br>4. Local traffic to the node itself (not across nodes).<br>5. Load balancer / proxy that handles tragging to the Rancher UI / API.<br>6. Only if SSL is not terminated at external load balancer.<br>7. Only if using Overlay mode on Windows cluster.</td>
        </tr>
    </tbody>
 </table>
@@ -213,7 +213,29 @@
 	        <th>Port</th>
 	        <th align="left">Source</th>
 	        <th align="left">Description</th>
-	    </tr>
+		</tr>
+		<tr>
+			<td>TCP</td>
+			<td>22</td>
+			<td>
+				<ul>
+					<li><strong>Linux worker nodes only</strong></li>
+					<li>Any network that you want to be able to remotely access this node from.</li>
+				</ul>
+			</td>
+			<td>Remote access over SSH</td>
+		</tr>
+		<tr>
+			<td>TCP</td>
+			<td>3389</td>
+			<td>
+				<ul>
+					<li><strong>Windows worker nodes only</strong></li>
+					<li>Any network that you want to be able to remotely access this node from.</li>
+				</ul>
+			</td>
+			<td>Remote access over RDP</td>
+		</tr>
 	    <tr>
 	        <td>TCP</td>
 	        <td>80</td>
@@ -0,0 +1,74 @@
+#Requires -Version 5.0
+
+param (
+    [parameter(Mandatory = $false,HelpMessage="Build the build & dev images instead of pulling from the registry")] [switch]$buildBuild,
+    [parameter(Mandatory = $false,HelpMessage="Build the dev image instead of pulling from the registry")] [switch]$buildDev,
+    [parameter(Mandatory = $false,HelpMessage="Port to listen on")] [string]$port,
+    [parameter(Mandatory = $false,HelpMessage="Skip pulling build/dev images")] [switch]$skipPull,
+    [parameter(Mandatory = $false,HelpMessage="Use DIR to for the theme, to devlop the theme at the same time")] [string]$theme,
+    [parameter(Mandatory = $false,HelpMessage="Upload/push the build image after building")] [switch]$upload
+)
+
+$DefaultPort = 9001
+$ListenPort = $DefaultPort
+$Image = "rancher/docs"
+$Tag = "dev"
+$twitterConsumer = $env:TWITTER_CONSUMER
+$twitterSecret = $env:TWITTER_SECRET
+
+$dirPath = Split-Path -Parent $MyInvocation.MyCommand.Definition
+$baseDirPath = Get-Location
+if ($dirPath -eq $baseDirPath) {
+  $baseDirPath = (Resolve-Path "$dirPath\..").Path
+}
+pushd $baseDirPath
+
+if ($port) {
+    $ListenPort = $port
+}
+
+$ThemeVolume = ""
+if ($theme) {
+    Write-Host "Using theme from $theme"
+    $ThemeVolume = "-v ${baseDirPath}/${theme}:/run/node_modules/rancher-website-theme"
+}
+
+if ($buildBuild) {
+    Write-Host "Building ${Image}:build"
+    docker build --no-cache -f Dockerfile.build --build-arg TWITTER_CONSUMER=$twitterConsumer --build-arg TWITTER_SECRET=$twitterSecret -t ${Image}:build .
+    if ($upload) {
+        docker push ${Image}:build
+    }
+    $buildDev = $true
+} elseif ($skipPull) {
+    Write-Host "Skipping pull of ${Image}:build"
+} else {
+    Write-Host "Pulling ${Image}:build"
+    docker pull ${Image}:build
+}
+
+if ($buildDev) {
+    $Tag = "local"
+    Write-Host "Building ${Image}:${Tag}"
+    docker build -f Dockerfile.dev -t ${Image}:${Tag} .
+} elseif ($skipPull) {
+    Write-Host "Skipping pull of ${Image}:${Tag}"
+} else {
+    Write-Host "Pulling ${Image}:${Tag}"
+    docker pull ${Image}:${Tag}
+}
+
+Write-Host "Starting server on http://localhost:${ListenPORT}"
+docker run --rm -p ${ListenPort}:${ListenPort} -it `
+  -v ${baseDirPath}/archetypes:/run/archetypes `
+  -v ${baseDirPath}/assets:/run/assets `
+  -v ${baseDirPath}/content:/run/content `
+  -v ${baseDirPath}/data:/run/data `
+  -v ${baseDirPath}/layouts:/run/layouts `
+  -v ${baseDirPath}/scripts:/run/scripts `
+  -v ${baseDirPath}/static:/run/static `
+  -v ${baseDirPath}/.git:/run/.git `
+  -v ${baseDirPath}/config.toml:/run/config.toml `
+  ${ThemeVolume} ${Image}:${Tag} --port=${ListenPort}
+
+popd