Merge pull request #332 from deniseschannon/rke-updates

RKE updates
2026-09-14 13:04:31 +00:00 · 2018-06-22 12:08:34 -07:00
parent c0c5fd686b 31e5f1a73b
commit d19d3e4ebe
27 changed files with 951 additions and 842 deletions
@@ -4,3 +4,5 @@ shortTitle: RKE
 weight: 1
 draft: true
 ---
+
+Rancher Kubernetes Engine (RKE) is a lightweight tool for installing Kubernetes that supports installation on bare-metal and virtualized servers. RKE is a Kubernetes installer written in Golang. It’s easy to use and doesn’t require a lot of preparation from the user to get started. Kubernetes installation is considered one of the toughest problems for operators and DevOps. Because Kubernetes can run on various platforms and operating systems, there are so many factors that need to be considered during the installation process.
@@ -1,6 +1,6 @@
 ---
 title: Config Options
-weight: 3000
+weight: 200
 draft: true
 ---

@@ -21,15 +21,16 @@ There are several options that can be configured in cluster configuration option
 * [Kubernetes Version](#kubernetes-version)
 * [System Images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/)
 * [Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/)
+* [Extra Args and Binds and Environment Variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/services-extras/)
 * [External Etcd]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/)
-* [Extra Args and Binds]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/extra-args-and-binds/)
-* [Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/)
-* [Add-ons Jobs Timeout](#add-ons-jobs-timeout)
 * [Authentication]({{< baseurl >}}/rke/v0.1.x/en/config-options/authentication/)
 * [Authorization]({{< baseurl >}}/rke/v0.1.x/en/config-options/authorization/)
 * [Cloud Providers]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/)
-* [Network Plugins]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/)
-* [Ingress Controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controller/)
+* [Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/)
+  * [Network Plugins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
+  * [Ingress Controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
+  * [User-Defined-Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/user-defined-add-ons/)
+  * [Add-ons Jobs Timeout](#add-ons-jobs-timeout)

 ## Cluster Level Options

@@ -94,6 +95,19 @@ RKE supports using ssh connection configuration from a local ssh agent. The defa
 ssh_agent_auth: true
 ```

+If you want to use an SSH private key with a passphrase, you will need to add your key to `ssh-agent` and have the environment variable `SSH_AUTH_SOCK` configured.
+
+```bash
+$ eval "$(ssh-agent -s)"
+Agent pid 3975
+$ ssh-add /home/user/.ssh/id_rsa
+Enter passphrase for /home/user/.ssh/id_rsa:
+Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
+$ echo $SSH_AUTH_SOCK
+/tmp/ssh-118TMqxrXsEx/agent.3974
+```
+
+
 ### Add-ons Job Timeout

 You can define [add-ons]({{< baseurl >}}/rke/v0.1.x/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.
@@ -1,74 +1,39 @@
 ---
 title: Add-Ons
-weight: 3000
+weight: 250
 draft: true
 ---

+RKE supports pluggable add-ons. Add-ons are used to deploy several cluster components including:

-RKE supports pluggable add-ons. Addons are used to deploy several cluster components including:
- Network plugin
- KubeDNS
- Ingress controller
+* [Network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/)
+* [Ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/)
+* KubeDNS

-In addition, a user can specify an addon yaml manifests in the cluster.yml file. RKE will deploy the user-defined add-ons after the cluster  deployment is complete.
+The images used for these add-ons under the [`system_images` directive]({< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each add-on, but these can be overridden by changing the image tag in `system_images`.

-RKE first uploads the yaml manifest as a configmap to the Kubernetes cluster. Next, it will run a kubernetes job that mounts this configmap and deploy the addon by running `kubectl apply -f`.
+In addition to these pluggable add-ons, you can specify an add-on that you want deployed after the cluster deployment is complete.

-> **Note: RKE doesn't support removal or update of cluster add-ons when doing `rke up` with a different list of add-ons. Please update the add-ons by using `kubectl edit`.**
+RKE only adds additional add-ons when using `rke up` multiple times. RKE does **not** support removing of cluster add-ons when doing `rke up` with a different list of add-ons.
+
+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`.


+## Critical and Non-Critical Add-ons

-#### Critical and non-critical add-ons
-As of version `0.1.7`, add-ons are split into two categories:
+As of version v0.1.7, add-ons are split into two categories:

 - **Critical add-ons:** If these add-ons fail to deploy for any reason, RKE will error out.
- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying other add-ons.
+- **Non-critical add-ons:** If these add-ons fail to deploy, RKE will only log a warning and continue deploying any other add-ons.

+Currently, only the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/) is considered critical. KubeDNS, [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/) and [user-defined add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/user-defined-add-ons/) are considered non-critical.

-Currently, only the network plugin is considered critical. KubeDNS, Ingress and user-defined add-ons are considered non-critical.
+## Add-on deployment jobs

-## Defining User Addons
+RKE uses Kubernetes jobs to deploy add-ons. In some cases, add-ons deployment takes longer than expected. As of with version v0.1.7, RKE provides an option to control the job check timeout in seconds. This timeout is set at the cluster level.

-User defined add-ons can be added by either defining the yaml directly in the RKE config or pointing to a file. Adding a yaml directly into the file uses the `addons` directive, while pointing to a file uses the `addons_include:` directive.
-
-> **Note**: When using user-defined add-ons, you *must* define a namespace for *all* your resources, otherwise they will end up in the `kube-system` namespace.
-
-##### In-line Addons
-To define an add-on directly in the yaml file, make sure to use the yaml's block indicator `|-` as the `addons` directive is a multi-line string option. It's possible to specify multiple yaml resource definitions by separating them using the `---` directive.
-
-```yaml
-addons: |-
-    ---
-    apiVersion: v1
-    kind: Pod
-    metadata:
-      name: my-nginx
-      namespace: default
-    spec:
-      containers:
-      - name: my-nginx
-        image: nginx
-        ports:
-        - containerPort: 80
-```
-
-
-#### Referencing files for Add-ons
-
-User defined add-ons support referencing a local file or a URL.
-
-```yaml
-addons_include:
-    - https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-operator.yaml
-    - https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-cluster.yaml
-    - /opt/manifests/example.yaml
-    - ./nginx.yaml
-```
-
-
-#### Addon deployment jobs
-
-RKE uses kubernetes Jobs to deploy add-ons. In some cases, add-ons deployment takes longer than expected. Starting with version `0.1.7-rc1`, RKE provides an option to control the job check timeout in seconds:
 ```yaml
 addon_job_timeout: 30
 ```
@@ -0,0 +1,53 @@
+---
+title: Ingress Controllers
+weight: 252
+draft: true
+---
+
+By default, RKE deploys the nginx ingress controller on all schedulable nodes.
+
+> **Note:** As of v0.1.8, only workers are considered schedulable nodes, but prior to v0.1.8, worker and controlplane nodes were considered schedulable nodes.  
+
+RKE will deploy the ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
+
+The images used for ingress controller is under the [`system_images` directive]({< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with the ingress controller, but these can be overridden by changing the image tag in `system_images`.
+
+## Scheduling Ingress Controllers
+
+If you only wanted ingress controllers to be deployed on specific nodes, you can set a `node_selector` for the ingress. The label in the `node_selector` would need to match the label on the nodes for the ingress controller to be deployed.
+
+```yaml
+nodes:
+    - address: 1.1.1.1
+      role: [controlplane,worker,etcd]
+      user: root
+      labels:
+        app: ingress
+
+ingress:
+    provider: nginx
+    node_selector:
+      app: ingress
+```
+
+## Disabling the Default Ingress Controller
+
+You can disable the default controller by specifying `none` to  the ingress `provider` directive in the cluster configuration.
+
+```yaml
+ingress:
+    provider: none
+```
+## Nginx Ingress Controller
+
+For the configuration of nginx, there are some configuration options. There are a [list of options](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/configmap.md) for the nginx config map and [command line extra_args](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/cli-arguments.md).
+
+```yaml
+ingress:
+    provider: nginx
+    options:
+      map-hash-bucket-size: "128"
+      ssl-protocols: SSLv2
+    extra_args:
+      enable-ssl-passthrough: ""
+```
@@ -0,0 +1,70 @@
+---
+title: Network Plug-ins
+weight: 251
+draft: true
+---
+
+RKE supports the following network plug-ins that are deployed as add-ons:
+
+- Flannel
+- Calico
+- Canal
+- Weave
+
+By default, the network plug-in is `canal`. If you want to use another network plug-in, you need to specify which network plug-in to enable at the cluster level in the `cluster.yml`.
+
+```yaml
+# Setting the flannel network plug-in
+network:
+    plugin: flannel
+```
+
+The images used for network plug-ins are under the [`system_images` directive]({< baseurl >}}/rke/v0.1.x/en/config-options/system-images/). For each Kubernetes version, there are default images associated with each network plug-in, but these can be overridden by changing the image tag in `system_images`.
+
+## Network Plug-in Options
+
+Besides the different images that could be used to deploy network plug-ins, certain network plug-ins support additional options that can be used to customize the network plug-in.
+
+### Canal Network Plug-in Options
+
+```yaml
+network:
+    plugin: canal
+    options:
+        canal_iface: eth1
+```
+
+#### Canal Interface
+
+By setting the `canal_iface`, you can configure the interface to use for inter-host communication.
+
+### Flannel Network Plug-in Options
+
+```yaml
+network:
+    plugin: flannel
+    options:
+      flannel_iface: eth1
+```
+
+#### Flannel Interface
+
+By setting the `flannel_iface`, you can configure the interface to use for inter-host communication.
+
+
+### Calico Network Plug-in Options
+
+```yaml
+network:
+    plugin: calico
+    calico_cloud_provider: aws
+```
+
+#### Cloud Provider
+
+Calico currently only supports 2 cloud providers, AWS or GCE, which can be set using `calico_cloud_provider`.
+
+**Valid Options**
+
+- `aws`
+- `gce`
@@ -0,0 +1,52 @@
+---
+title: User-Defined Add-Ons
+weight: 253
+draft: true
+---
+
+Besides the [network plug-in]({{< baseurl >}}/rke/v0.1.x/en/config-options/network-plugins/) and [ingress controllers]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/), you can define any add-on that you want deployed after the Kubernetes cluster is deployed.
+
+There are two ways that you can specify an add-on.
+
+- [In-line Add-ons](#inline-add-ons)
+- [Referencing YAML Files for Add-ons](#referencing-yaml-files-for-add-ons)
+
+> **Note:** When using user-defined add-ons, you *must* define a namespace for *all* your resources, otherwise they will end up in the `kube-system` namespace.
+
+RKE uploads the YAML manifest as a configmap to the Kubernetes cluster. Then, it runs a Kubernetes job that mounts the configmap and deploys the add-on using `kubectl apply -f`.
+
+RKE only adds additional add-ons when using `rke up` multiple times. RKE does **not** support removing of cluster add-ons when doing `rke up` with a different list of add-ons.
+
+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`.
+
+## In-line Addons
+To define an add-on directly in the YAML file, make sure to use the YAML's block indicator `|-` as the `addons` directive is a multi-line string option. It's possible to specify multiple YAML resource definitions by separating them using the `---` directive.
+
+```yaml
+addons: |-
+    ---
+    apiVersion: v1
+    kind: Pod
+    metadata:
+      name: my-nginx
+      namespace: default
+    spec:
+      containers:
+      - name: my-nginx
+        image: nginx
+        ports:
+        - containerPort: 80
+```
+
+## Referencing YAML files for Add-ons
+Use the `addons_include` directive to reference a local file or a URL for any user-defined add-ons.  
+
+```yaml
+addons_include:
+    - https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-operator.yaml
+    - https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/rook-cluster.yaml
+    - /opt/manifests/example.yaml
+    - ./nginx.yaml
+```
@@ -1,15 +1,15 @@
 ---
 title: Authentication
-weight: 3000
+weight: 235
 draft: true
 ---

-RKE supports x509 authentication strategy. You can additionally define a list of SANs (Subject Alternative Names) to add to the Kubernetes API Server PKI certificates. This allows you to connect to your Kubernetes cluster API Server through a load balancer, for example, rather than a single node.
+RKE supports x509 authentication strategy. You can additionally define a list of SANs (Subject Alternative Names) to add to the Kubernetes API Server PKI certificates. As an example, this allows you to connect to your Kubernetes cluster API Server through a load balancer instead of a single node.

 ```yaml
 authentication:
-  strategy: x509
-  sans:
-  - "10.18.160.10"
-  - "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
+    strategy: x509
+    sans:
+      - "10.18.160.10"
+      - "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
 ```
@@ -1,16 +1,15 @@
 ---
 title: Authorization
-weight: 3000
+weight: 240
 draft: true
 ---

-Kubernetes supports multiple [Authorization Modules](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules). Currently, RKE provides support for the [RBAC module](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) only.
+Kubernetes supports multiple [Authorization Modules](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules). Currently, RKE only supports the [RBAC module](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).

-RBAC is enabled by default in RKE. It's possible to disable authorization support by seeting the authorization mode to `none`
+By default, RBAC is already enabled. If you wanted to turn off RBAC support, **which isn't recommended**, you set the authorization mode to `none`.

 ```yaml
-# Use `mode: none` to disable authorization
 authorization:
-  mode: rbac
+    # Use `mode: none` to disable authorization
+    mode: rbac
 ```
-<!-- explain cluster authorization configuration-->
@@ -1,6 +1,6 @@
 ---
 title: Bastion/Jump Host Configuration
-weight: 3015
+weight: 220
 draft: true
 ---

@@ -8,15 +8,15 @@ Since RKE uses `ssh` to connect to [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-

 ```yaml
 bastion_host:
-  address: x.x.x.x
-  user: ubuntu
-  port: 22
-  ssh_key_path: /home/user/.ssh/bastion_rsa
-  # or
-  # ssh_key: |-
-  #   -----BEGIN RSA PRIVATE KEY-----
-  #
-  #   -----END RSA PRIVATE KEY-----
+    address: x.x.x.x
+    user: ubuntu
+    port: 22
+    ssh_key_path: /home/user/.ssh/bastion_rsa
+    # or
+    # ssh_key: |-
+    #   -----BEGIN RSA PRIVATE KEY-----
+    #
+    #   -----END RSA PRIVATE KEY-----
 ```

 ## Bastion Host Options
@@ -1,6 +1,6 @@
 ---
 title: Cloud Providers
-weight: 3000
+weight: 245
 draft: true
 ---

@@ -21,7 +21,7 @@ To enable the AWS cloud provider, there are no configuration options. You only n

 ```yaml
 cloud_provider:
-  name: aws
+    name: aws
 ```

 #### IAM Requirements
@@ -74,17 +74,17 @@ To enable the Azure cloud provider, besides setting the name as `azure`, there a

 ```yaml
 cloud_provider:
-  name: azure
-  azureCloudProvider:
-    aadClientId: xxxxxxxxx
-    aadClientSecret: xxxxxxxxx
-    location: xxxxxxxxx
-    resourceGroup: xxxxxxxxx
-    subnetName: xxxxxxxxx
-    subscriptionId: xxxxxxxxx
-    vnetName: xxxxxxxxx
-    tenantId: xxxxxxxxx
-    securityGroupName: xxxxxxxxx
+    name: azure
+    azureCloudProvider:
+      aadClientId: xxxxxxxxx
+      aadClientSecret: xxxxxxxxx
+      location: xxxxxxxxx
+      resourceGroup: xxxxxxxxx
+      subnetName: xxxxxxxxx
+      subscriptionId: xxxxxxxxx
+      vnetName: xxxxxxxxx
+      tenantId: xxxxxxxxx
+      securityGroupName: xxxxxxxxx
 ```

 #### Overriding the hostname
@@ -93,13 +93,13 @@ Since the Azure node name must match the Kubernetes node name, you override the

 ```yaml
 nodes:
-  - address: x.x.x.x
-    hostname_override: azure-rke1
-    user: ubuntu
-    role:
-    - controlplane
-    - etcd
-    - worker
+    - address: x.x.x.x
+      hostname_override: azure-rke1
+      user: ubuntu
+      role:
+        - controlplane
+        - etcd
+        - worker
 ```

 #### Azure Configuration Options
@@ -143,22 +143,22 @@ To enable the Openstack cloud provider, besides setting the name as `openstack`,

 ```yaml
 cloud_provider:
-  name: openstack
-  openstackCloudProvider:
-    global:
-      username: xxxxxxxxxxxxxx
-      password: xxxxxxxxxxxxxx
-      auth-url: https://1.2.3.4/identity/v3
-      tenant-id: xxxxxxxxxxxxxx
-      domain-id: xxxxxxxxxxxxxx
-    load_balancer:
-      subnet-id: xxxxxxxxxxxxxx
-    block_storage:
-      ignore-volume-az: true
-    route:
-      router-id: xxxxxxxxxxxxxx
-    metadata:
-      search-order: xxxxxxxxxxxxxx
+    name: openstack
+    openstackCloudProvider:
+      global:
+        username: xxxxxxxxxxxxxx
+        password: xxxxxxxxxxxxxx
+        auth-url: https://1.2.3.4/identity/v3
+        tenant-id: xxxxxxxxxxxxxx
+        domain-id: xxxxxxxxxxxxxx
+      load_balancer:
+        subnet-id: xxxxxxxxxxxxxx
+      block_storage:
+        ignore-volume-az: true
+      route:
+        router-id: xxxxxxxxxxxxxx
+      metadata:
+        search-order: xxxxxxxxxxxxxx
 ```

 #### Overriding the hostname
@@ -247,32 +247,32 @@ To enable the vSphere cloud provider, besides setting the name as `vsphere`, the

 ```yaml
 cloud_provider:
-  name: vsphere
-  vsphereCloudProvider:
-    global:
-      user: user
-      password: pass
-      server: 1.2.3.4
-      port: 22
-    virtual_center:
-      1.2.3.4:
-        user: test
-        password: test
-        port: test
-      5.6.7.8:
-        user: test
-        password: test
-        port: test
-    workspace:
-      server: test.test.com
-      datacenter: test
-      folder: test
-      default-datastore: test
-      resourcepool-path: test
-    network:
-      public-network: xxxxxxxxxxxxxx
-    disk:
-      scsicontrollertype: xxxxxxxxxxxxxx
+    name: vsphere
+    vsphereCloudProvider:
+      global:
+        user: user
+        password: pass
+        server: 1.2.3.4
+        port: 22
+      virtual_center:
+        1.2.3.4:
+          user: test
+          password: test
+          port: test
+        5.6.7.8:
+          user: test
+          password: test
+          port: test
+      workspace:
+        server: test.test.com
+        datacenter: test
+        folder: test
+        default-datastore: test
+        resourcepool-path: test
+      network:
+        public-network: xxxxxxxxxxxxxx
+      disk:
+        scsicontrollertype: xxxxxxxxxxxxxx
 ```

 #### vSphere Configuration Options
@@ -311,14 +311,14 @@ These are the options that are available under `virtual_center`, which is a dict

 ```yaml
 virtual_center:
-  <vcenter1-ip>:
-    user: test
-    password: test
-    port: test
-  <vcenter2-ip>:
-    user: test
-    password: test
-    port: test
+    <vcenter1-ip>:
+      user: test
+      password: test
+      port: test
+    <vcenter2-ip>:
+      user: test
+      password: test
+      port: test
 ```

 For each `virtual_center`, these are the available configuration options to be used under the each virtual center. The virtual center's are separated from each other based on their IP.
@@ -376,11 +376,11 @@ To add this cloud config file to RKE, the `cloud_provider` would be need to be s

 ```yaml
 cloud_provider:
-  name: ovirt
-  # Note the pipe as this is what indicates a multiline string
-  customCloudProvider: |-
-    [connection]
-    uri = https://localhost:8443/ovirt-engine/api
-    username = admin@internal
-    password = admin
+    name: ovirt
+    # Note the pipe as this is what indicates a multiline string
+    customCloudProvider: |-
+      [connection]
+      uri = https://localhost:8443/ovirt-engine/api
+      username = admin@internal
+      password = admin
 ```
@@ -1,135 +1,112 @@
 ---
 title: Example Cluster.ymls
-weight: 3000
+weight: 205
 draft: true
 ---

+There are lots of different config options that can be set in the cluster configuration file for RKE. Here are some examples of files:

-### Minimal `cluster.yml` example
+## Minimal `cluster.yml` example

-```
-# default k8s version: v1.8.10-rancher1-1
-# default network plugin: canal
+```yaml
 nodes:
-  - address: 1.2.3.4
-    user: ubuntu
-    role: [controlplane,worker,etcd]
+    - address: 1.2.3.4
+      user: ubuntu
+      role:
+        - controlplane
+        - etcd
+        - worker
+      ssh_key_path: /home/user/.ssh/id_rsa
+      port: 22    
 ```

-### Full `cluster.yml` example
+## Full `cluster.yml` example

 ```yaml
 ---
 nodes:
-  - address: 1.1.1.1
-    user: ubuntu
-    role:
-    - controlplane
-    - etcd
-    ssh_key_path: /home/user/.ssh/id_rsa
-    port: 2222
-  - address: 2.2.2.2
-    user: ubuntu
-    role:
-    - worker
-    ssh_key: |-
-      -----BEGIN RSA PRIVATE KEY-----
+    - address: 1.1.1.1
+      user: ubuntu
+      role:
+        - controlplane
+        - etcd
+      ssh_key_path: /home/user/.ssh/id_rsa
+      port: 2222
+    - address: 2.2.2.2
+      user: ubuntu
+      role:
+        - worker
+      ssh_key: |-
+        -----BEGIN RSA PRIVATE KEY-----

-      -----END RSA PRIVATE KEY-----
-  - address: example.com
-    user: ubuntu
-    role:
-    - role
-    hostname_override: node3
-    internal_address: 192.168.1.6
-    labels:
-      app: ingress
+        -----END RSA PRIVATE KEY-----
+    - address: example.com
+      user: ubuntu
+      role:
+        - worker
+      hostname_override: node3
+      internal_address: 192.168.1.6
+      labels:
+        app: ingress

 services:
-  etcd:
-    # if external etcd is used
-    # path: /etcdcluster
-    # external_urls:
-    #   - https://etcd-example.com:2379
-    # ca_cert: |-
-    #   -----BEGIN CERTIFICATE-----
-    #   xxxxxxxxxx
-    #   -----END CERTIFICATE-----
-    # cert: |-
-    #   -----BEGIN CERTIFICATE-----
-    #   xxxxxxxxxx
-    #   -----END CERTIFICATE-----
-    # key: |-
-    #   -----BEGIN PRIVATE KEY-----
-    #   xxxxxxxxxx
-    #   -----END PRIVATE KEY-----
-  kube-api:
-    service_cluster_ip_range: 10.43.0.0/16
-    pod_security_policy: false
-    # add additional arguments to the kubernetes component
-    # Note that this WILL OVERRIDE existing defaults
-    extra_args:
-      # Enable audit log to stdout
-      audit-log-path: "-"
-      # Increase number of delete workers
-      delete-collection-workers: 3
-      # Set the level of log output to debug-level
-      v: 4
-  kube-controller:
-    cluster_cidr: 10.42.0.0/16
-    service_cluster_ip_range: 10.43.0.0/16
-  scheduler:
-  kubelet:
-    cluster_domain: cluster.local
-    cluster_dns_server: 10.43.0.10
-    infra_container_image: gcr.io/google_containers/pause-amd64:3.0
-    # Optionally define additional volume binds to a service
-    extra_binds:
-      - "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins"
-  kubeproxy:
-
-# supported plugins are:
-# flannel
-# calico
-# canal
-# weave
-#
-# If you are using calico on AWS or GCE, use the network plugin config option:
-# 'calico_cloud_provider: aws'
-# or
-# 'calico_cloud_provider: gce'
-# network:
-#   plugin: calico
-#   options:
-#     calico_cloud_provider: aws
-#
-# To specify flannel interface, you can use the 'flannel_iface' option:
-# network:
-#   plugin: flannel
-#   options:
-#     flannel_iface: eth1
-# To specify flannel interface for canal plugin, you can use the 'canal_iface' option:
-# network:
-#   plugin: canal
-#   options:
-#     canal_iface: eth1
-
+    etcd:
+      # if external etcd is used
+      # path: /etcdcluster
+      # external_urls:
+      #   - https://etcd-example.com:2379
+      # ca_cert: |-
+      #   -----BEGIN CERTIFICATE-----
+      #   xxxxxxxxxx
+      #   -----END CERTIFICATE-----
+      # cert: |-
+      #   -----BEGIN CERTIFICATE-----
+      #   xxxxxxxxxx
+      #   -----END CERTIFICATE-----
+      # key: |-
+      #   -----BEGIN PRIVATE KEY-----
+      #   xxxxxxxxxx
+      #   -----END PRIVATE KEY-----
+    kube-api:
+      # This must match the service_cluster_ip_range in kube-controller
+      service_cluster_ip_range: 10.43.0.0/16
+      pod_security_policy: false
+      # add additional arguments to the kubernetes component
+      # Note that this WILL OVERRIDE existing defaults
+      extra_args:
+        # Enable audit log to stdout
+        audit-log-path: "-"
+        # Increase number of delete workers
+        delete-collection-workers: 3
+        # Set the level of log output to debug-level
+        v: 4
+    kube-controller:
+      cluster_cidr: 10.42.0.0/16
+      # This must match the service_cluster_ip_range in kube-api
+      service_cluster_ip_range: 10.43.0.0/16
+    scheduler:
+    kubelet:
+      cluster_domain: cluster.local
+      cluster_dns_server: 10.43.0.10
+      # Optionally define additional volume binds to a service
+      extra_binds:
+        - "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins"

 network:
-  plugin: flannel
-  options:
+    plugin: flannel
+    options:

 # At the moment, the only authentication strategy supported is x509.
 # You can optionally create additional SANs (hostnames or IPs) to add to
 #  the API server PKI certificate. This is useful if you want to use a load balancer
 #  for the control plane servers, for example.
 authentication:
-  strategy: x509
-  sans:
-  - "10.18.160.10"
-  - "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
+    strategy: x509
+    sans:
+      - "10.18.160.10"
+      - "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"

-# all addon manifests MUST specify a namespace
+# All addon manifests MUST specify a namespace
 addons: |-
    ---
    apiVersion: v1
@@ -150,27 +127,31 @@ addons_include:
    - /path/to/manifest

 system_images:
-  etcd: rancher/etcd:v3.0.17
-  kubernetes: rancher/hyperkube:v1.10.1
-  alpine: rancher/rke-tools:v0.1.4
-  nginx_proxy: rancher/rke-tools:v0.1.4
-  cert_downloader: rancher/rke-tools:v0.1.4
-  kubernetes_services_sidecar: rancher/rke-tools:v0.1.4
-  kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.5
-  dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.5
-  kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.5
-  kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
-  flannel: rancher/coreos-flannel:v0.9.1
-  flannel_cni: rancher/coreos-flannel-cni:v0.2.0
-
+    etcd: rancher/etcd:v3.0.17
+    kubernetes: rancher/hyperkube:v1.10.1
+    alpine: rancher/rke-tools:v0.1.4
+    nginx_proxy: rancher/rke-tools:v0.1.4
+    cert_downloader: rancher/rke-tools:v0.1.4
+    kubernetes_services_sidecar: rancher/rke-tools:v0.1.4
+    kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.5
+    dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.5
+    kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.5
+    kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
+    flannel: rancher/coreos-flannel:v0.9.1
+    flannel_cni: rancher/coreos-flannel-cni:v0.2.0

+# Global SSH private key
 ssh_key_path: ~/.ssh/test

+# Enable use of SSH agent to use SSH private keys with passphrase
+# This requires the environment `SSH_AUTH_SOCK` configured pointing to your SSH agent which has the private key added
+ssh_agent_auth: true
+
 # Kubernetes authorization mode
 # Use `mode: rbac` to enable RBAC
 # Use `mode: none` to disable authorization
 authorization:
-  mode: rbac
+    mode: rbac

 # If set to true, rke won't fail when unsupported Docker version is found
 ignore_docker_version: false
@@ -186,9 +167,9 @@ cluster_name: mycluster
 # List of registry credentials, if you are using a Docker Hub registry,
 # you can omit the `url` or set it to `docker.io`
 private_registries:
-  - url: registry.com
-    user: Username
-    password: password
+    - url: registry.com
+      user: Username
+      password: password

 # Currently only nginx ingress provider is supported.
 # To disable ingress controller, set `provider: none`
@@ -211,20 +192,20 @@ private_registries:
 #     enable-ssl-passthrough: ""

 ingress:
-  provider: nginx
+    provider: nginx

 cloud_provider:
-  name: aws
+    name: aws

 # Bastion/Jump host configuration
 bastion_host:
-  address: x.x.x.x
-  user: ubuntu
-  port: 22
-  ssh_key_path: /home/user/.ssh/bastion_rsa
-  # or
-  # ssh_key: |-
-  #   -----BEGIN RSA PRIVATE KEY-----
-  #
-  #   -----END RSA PRIVATE KEY-----
+    address: x.x.x.x
+    user: ubuntu
+    port: 22
+    ssh_key_path: /home/user/.ssh/bastion_rsa
+    # or
+    # ssh_key: |-
+    #   -----BEGIN RSA PRIVATE KEY-----
+    #
+    #   -----END RSA PRIVATE KEY-----
  ```
@@ -1,33 +0,0 @@
---
-title: Ingress Controller
-weight: 3000
-draft: true
---
-
-
-RKE will deploy Nginx controller by default, user can disable this by specifying `none` to ingress `provider` option in the cluster configuration, user also can specify list of options for nginx config map listed in this [doc](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/configmap.md), and command line extra_args listed in this [doc](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/cli-arguments.md), for example:
-```
-ingress:
-  provider: nginx
-  options:
-    map-hash-bucket-size: "128"
-    ssl-protocols: SSLv2
-  extra_args:
-    enable-ssl-passthrough: ""
-```
-By default, RKE will deploy ingress controller on all schedulable nodes (controlplane and workers), to specify only certain nodes for ingress controller to be deployed, user has to specify `node_selector` for the ingress and the right label on the node, for example:
-```
-nodes:
-  - address: 1.1.1.1
-    role: [controlplane,worker,etcd]
-    user: root
-    labels:
-      app: ingress
-
-ingress:
-  provider: nginx
-  node_selector:
-    app: ingress
-```
-
-RKE will deploy Nginx Ingress controller as a DaemonSet with `hostnetwork: true`, so ports `80`, and `443` will be opened on each node where the controller is deployed.
@@ -1,34 +0,0 @@
---
-title: Network Plug-ins
-weight: 3000
-draft: true
---
-
-RKE supports the following network plugins that are deployed as add-ons:
-
- Flannel
- Calico
- Canal
- Weave
-
-To use a specific network plugin configure `cluster.yml` to include:
-
-```yaml
-network:
-  plugin: flannel
-```
-Additionally, some plugins support additional options that can be used to customize their behavior.
-
-If this section is not specified in the cluster configration, the default network plugin will be used. The default is `canal`.
-
-### Network Options
-
-There are extra options that can be specified for each network plugin:
-
-#### Flannel
-
- **flannel_iface**: Interface to use for inter-host communication
-
-#### Calico
-
- **calico_cloud_provider**: Cloud provider where Calico will operate, currently supported values are: `aws`, `gce`
@@ -1,6 +1,6 @@
 ---
 title: Nodes
-weight: 3005
+weight: 210
 draft: true
 ---

@@ -8,30 +8,30 @@ The `nodes` directive is the only required section in the `cluster.yml` file. It

 ```yaml
 nodes:
-  nodes:
-  - address: 1.1.1.1
-    user: ubuntu
-    role:
-    - controlplane
-    - etcd
-    ssh_key_path: /home/user/.ssh/id_rsa
-    port: 2222
-  - address: 2.2.2.2
-    user: ubuntu
-    role:
-    - worker
-    ssh_key: |-
-      -----BEGIN RSA PRIVATE KEY-----
+    nodes:
+    - address: 1.1.1.1
+      user: ubuntu
+      role:
+      - controlplane
+      - etcd
+      ssh_key_path: /home/user/.ssh/id_rsa
+      port: 2222
+    - address: 2.2.2.2
+      user: ubuntu
+      role:
+      - worker
+      ssh_key: |-
+        -----BEGIN RSA PRIVATE KEY-----

-      -----END RSA PRIVATE KEY-----
-  - address: example.com
-    user: ubuntu
-    role:
-    - role
-    hostname_override: node3
-    internal_address: 192.168.1.6
-    labels:
-      app: ingress
+        -----END RSA PRIVATE KEY-----
+    - address: example.com
+      user: ubuntu
+      role:
+      - worker
+      hostname_override: node3
+      internal_address: 192.168.1.6
+      labels:
+        app: ingress
 ```

 ## Node Options
@@ -76,13 +76,12 @@ You can specify the list of roles that you want the node to be as part of the Ku

 * **etcd**

-With this role, the `etcd` container will be run on these nodes. Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration. Etcd is a distributed reliable key-value store which stores all Kubernetes state.
+With this role, the `etcd` container will be run on these nodes.  Etcd keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. Although you can run etcd on just one node, it typically takes 3, 5 or more nodes to create an HA configuration. Etcd is a distributed reliable key-value store which stores all Kubernetes state.

 * **controlplane**

 With this role, the stateless components that are used to deploy Kubernetes will run on these nodes. These components are used to run the API server, scheduler, and controllers.

-
 * **worker**

 With this role, any workloads or pods that are deployed will land on these nodes.
@@ -95,14 +94,4 @@ If the Docker socket is different than the default, you can set the `docker_sock

 ### Labels

-You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controller/) `node_selector` option.
-
-
-
-
-
-
-
-
-
-<!-- explain how to set up nodes in yaml with examples and what is required-->
+You have the ability to add an arbitrary map of labels for each node. It can be used when using the [ingress controller's]({{< baseurl >}}/rke/v0.1.x/en/config-options/ingress-controllers/) `node_selector` option.
@@ -1,6 +1,6 @@
 ---
 title: Private Registries
-weight: 3010
+weight: 215
 draft: true
 ---

@@ -8,12 +8,12 @@ RKE supports the ability to configure multiple private Docker registries. By pas

 ```yaml
 private_registries:
-  - url: registry.com
-    user: Username
-    password: password
-  - url: myregistry.com
-    user: myuser
-    password: mypassword
+    - url: registry.com
+      user: Username
+      password: password
+    - url: myregistry.com
+      user: myuser
+      password: mypassword
 ```

 ### Air-gapped Setups
@@ -1,99 +1,97 @@
 ---
-title: Kubernetes Services
-weight: 3025
+title: Kubernetes Default Services
+weight: 230
 draft: true
 ---

-## Default services
+To deploy Kubernetes, RKE deploys several core components or services in Docker containers on the nodes. Based on the roles of the node, the containers deployed may be different.

-<!--Talk about the default services launched and options around them-->
+**All services support additional [custom arguments, Docker mount binds and extra environment variables]({{< baseurl >}}/rke/v0.1.x/en/config-options/services-extra).**

-To deploy Kubernetes, RKE deploys several core components or services in Docker containers on the cluster nodes. The deployed containers depend on the role(s) assigned to each node.
+## etcd

-All RKE services support additional [custom arguments and Docker mount binds]({{< baseurl >}}/rke/v0.1.x/en/config-options/extra-args-and-binds).
+Kubernetes uses [etcd](https://github.com/coreos/etcd/blob/master/Documentation/docs.md) as a store for cluster state and data. Etcd is a reliable, consistent and distributed key-value store.

-Various examples and configurations can be found in the [example YMALs]({{< baseurl >}}/rke/v0.1.x/en/config-options/example-yamls/)
+RKE supports running etcd in a single node mode or in HA cluster mode. It also supports adding and removing etcd nodes to the cluster.

-### etcd
+By default, RKE will deploy a new etcd service, but you can also run Kubernetes with an [external etcd service]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/).

-Kubernetes uses [Etcd](https://github.com/coreos/etcd/blob/master/Documentation/docs.md) as a store for cluster state and data. Etcd is a reliable, consistent and distributed key-value store.
-
-RKE supports running Etcd in a single node mode or in HA cluster mode. It also supports adding and removing Etcd nodes to the cluster.
-
-RKE also supports running Kubernetes with an [external Etcd service]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/external-etcd/).
-
-
-### kube-api
+## Kubernetes API Server

 The [Kubernetes API](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) REST service, which handles requests and data for all Kubernetes objects and provide shared state for all the other Kubernetes components.

-In addition to extra arguments and binds, RKE supports the following options for kube-api:
+```yaml
+services:
+  kube-api:
+    # IP range for any services created on Kubernetes
+    service_cluster_ip_range: 10.43.0.0/16
+    # Expose a different port range for NodePort services
+    service_node_port_range: 30000-32767    
+    pod_security_policy: false
+```

-##### `service_cluster_ip_range`
+### Kubernetes API Server Options

-This is the virtual IP address that will be assigned to services created on Kubernetes. The default value for this option is `10.43.0.0/16`.
+RKE supports the following options for the `kube-api` service :

+- **Service Cluster IP Range** (`service_cluster_ip_range`) - This is the virtual IP address that will be assigned to services created on Kubernetes. By default, the service cluster IP range is `10.43.0.0/16`. If you change this value, then it must also be set with the same value on the Kubernetes Controller Manager (`kube-controller`).
+- **Node Port Range** (`service_node_port_range`) - The port range to be used for Kubernetes services created with the [type](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types) `NodePort`. By default, the port range is `30000-32767`.
+- **Pod Security Policy** (`pod_security_policy`) - An option to enable the [Kubernetes Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). By default, we do not enable pod security policies as it is set to `false`.

-##### `service_node_port_range`
-The port range to be used for Kubernetes services created with the [type](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types) `NodePort`.
+    > **Note:** If you set `pod_security_policy` value to `true`, RKE will configure an  open policy to allow any pods to work on the cluster. You will need to configure your own policies to fully utilize PSP.

-The default value for this option is `30000-32767`.
+## Kubernetes Controller Manager

-##### `pod_security_policy`
+ kube-controller

-An option to enable the [Kubernetes Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/).
+The [Kubernetes Controller Manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) service is the component responsible for running Kubernetes main control loops. The controller manager monitors the cluster desired state through the Kubernetes API server and makes the necessary changes to the current state to reach the desired state.

-The default value for this option is `false`, which disables PSP.
+```yaml
+services:
+    kube-controller:
+      # CIDR pool used to assign IP addresses to pods in the cluster
+      cluster_cidr: 10.42.0.0/16
+      #
+      service_cluster_ip_range: 10.43.0.0/16
+```

-> **Note**: RKE will configure an initially open policy to allow pods to work on the cluster. You will need to configure your own policies to fully utilize PSP.
+### Kubernetes Controller Manager Options

+RKE support the following options for the `kube-controller` service:

-### `kube-controller`
+- **Cluster CIDR** (`cluster_cidr`) - The CIDR pool used to assign IP addresses to pods in the cluster. By default, each node in the cluster is assigned a `/24` network from this pool for pod IP assignments. The default value for this option is `10.42.0.0/16`.
+- **Service Cluster IP Range** (`service_cluster_ip_range`) - This is the virtual IP address that will be assigned to services created on Kubernetes. By default, the service cluster IP range is `10.43.0.0/16`. If you change this value, then it must also be set with the same value on the Kubernetes API server (`kube-api`).

-The [Kubernetes Controller Manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/) service. This is the component responsible for running Kubernetes main control loops. The controller manager monitors the cluster desired state through the kube-apiserver and make the necessary changes to the current state to reach the desired state.
+## Kubelet

-RKE support the following options for the controller service:
+The [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) services acts as a "node agent" for Kubernetes. It runs on all nodes deployed by RKE, and gives Kubernetes the ability to manage the container runtime on the node.

-##### `cluster_cidr`
-The CIDR pool used to assign IP addresses to Pods in the cluster. By default, each node in the cluster is assigned a /24 network from this pool for Pod IP assignment on this node.
+```yaml
+services:
+    kubelet:
+     # Base domain for the cluster
+     cluster_domain: cluster.local
+     # IP address for the DNS service endpoint
+     cluster_dns_server: 10.43.0.10
+     # Fail if swap is on
+     fail_swap_on: false
+```

-The default value for this option is `10.42.0.0/16`.
-
-##### `service_cluster_ip_range`
-
-This is the virtual IP address that will be assigned to services created on Kubernetes. The default value for this option is `10.43.0.0/16`.
-
-
-### `scheduler`
-
-The [Kubernetes Scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) service. The Kubernetes Scheduler is responsible for scheduling cluster workloads based on various configurations, metrics, resource requirements and workload-specific requirements.
-
-RKE doesn't support any specific options for the scheduler service at this time.
-
-
-### `kubelet`
-
-The [Kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) services acts as a "node agent" for Kubernetes. It runs on all nodes deployed by RKE, and gives Kubernetes the ability to manage the container runime one the node.
+### Kubelet Options

 RKE supports the following options for the `kubelet` service:

-##### cluster_domain
+- **Cluster Domain** (`cluster_domain`) - The [base domain](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) for the cluster. All services and DNS records created on the cluster. By default, the domain is set to `cluster.local`.
+- **Cluster DNS Server** (`cluster_dns_server`) - The IP address assigned to the DNS service endpoint within the cluster. DNS queries will be sent to this IP address which is used by KubeDNS. The default value for this option is `10.43.0.10`
+- **Fail if Swap is On** (`fail_swap_on`) - In Kubernetes, the default behavior for the kubelet is to **fail** if swap is enabled on the node. RKE does **not** follow this default and allows deployments on nodes with swap enabled. By default, the value is `false`. If you'd like to revert to the default kubelet behavior, set this option to `true`.  

-The [base domain](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) for the cluster. All services and DNS records created on the cluster. The default value for this option is `cluster.local`
+## Kubernetes Scheduler

-##### `cluster_dns_server`
+The [Kubernetes Scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) service is responsible for scheduling cluster workloads based on various configurations, metrics, resource requirements and workload-specific requirements.

-The IP address assigned to the DNS service endpoint within the cluster. DNS queries will be sent to this IP address which is used by KubeDNS. The default value for this option is `10.43.0.10`
+Currently, RKE doesn't support any specific options for the `scheduler` service.

+## Kubernetes Network Proxy
+The [Kubernetes network proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) service runs on all nodes and manages endpoints created by Kubernetes for TCP/UDP ports.

-##### `fail_swap_on`
-
-The default behavior for Kubelet is to _fail_ if swap is enabled on the node. However, RKE doesn't follow this default, and allows deployments on nodes with swap enabled. If you like to revert to the default Kubelet behavior, set this option to `true`.
-
-The defualt for this option is `false`.
-
-
-### `kube-proxy`
-The [Kubernetes Network Proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) service runs on all nodes and manages endpoints created by Kubernetes for TCP/UDP ports.
-
-RKE doesn't support any specific options for the `kube-proxy` service at this time.
+Currently, RKE doesn't support any specific options for the `kube-proxy` service.
@@ -1,6 +1,6 @@
 ---
 title: External etcd
-weight: 3027
+weight: 232
 draft: true
 ---

@@ -8,24 +8,24 @@ By default, RKE will launch etcd servers, but RKE also supports being able to us

 > **Note:** RKE will not accept having external etcd servers in conjunction with [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) with the `etcd` role.

-```
+```yaml
 services:
-  etcd:
-    path: /etcdcluster
-    external_urls:
-      - https://etcd-example.com:2379
-    ca_cert: |-
-      -----BEGIN CERTIFICATE-----
-      xxxxxxxxxx
-      -----END CERTIFICATE-----
-    cert: |-
-      -----BEGIN CERTIFICATE-----
-      xxxxxxxxxx
-      -----END CERTIFICATE-----
-    key: |-
-      -----BEGIN PRIVATE KEY-----
-      xxxxxxxxxx
-      -----END PRIVATE KEY-----
+    etcd:
+      path: /etcdcluster
+      external_urls:
+        - https://etcd-example.com:2379
+      ca_cert: |-
+        -----BEGIN CERTIFICATE-----
+        xxxxxxxxxx
+        -----END CERTIFICATE-----
+      cert: |-
+        -----BEGIN CERTIFICATE-----
+        xxxxxxxxxx
+        -----END CERTIFICATE-----
+      key: |-
+        -----BEGIN PRIVATE KEY-----
+        xxxxxxxxxx
+        -----END PRIVATE KEY-----
 ```

 ## External etcd Options
@@ -1,36 +0,0 @@
---
-title: Extra Args and Binds
-weight: 3026
-draft: true
---
-
-RKE supports the ability to configure your Kubernetes components by adding in extra service arguments to these components.
-
-## Extra Args
-
-For any of the Kubernetes services, you can update the `extra_args` to change the existing defaults.
-
-As of `v0.1.3`, using `extra_args` will add new arguments and **override** any existing defaults. For example, if you need to modify the default admission controllers list, you need to include the default list and edit it with your changes so all changes are included.
-
-Prior to `v0.1.3`, using `extra_args` would only add new arguments to the list and there was no ability to change the default list.
-
-```yaml
-services:
-  # ...
-  kube-controller:
-    extra_args:
-      cluster-name: "mycluster"
-```
-
-## Extra Binds
-
-Additional volume binds can be made to services using the `extra_binds` arguments.
-
-```yaml
-services:
-  # ...
-  kubelet:
-    extra_binds:
-      - "/host/dev:/dev"
-      - "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins:z"
-```
@@ -0,0 +1,45 @@
+---
+title: Extra Args, Extra Binds, and Extra Environment Variables
+weight: 231
+draft: true
+---
+
+RKE supports additional service arguments, volume binds and environment variables.
+
+### Extra Args
+
+For any of the Kubernetes services, you can update the `extra_args` to change the existing defaults.
+
+As of `v0.1.3`, using `extra_args` will add new arguments and **override** any existing defaults. For example, if you need to modify the default admission controllers list, you need to include the default list and edit it with your changes so all changes are included.
+
+Prior to `v0.1.3`, using `extra_args` would only add new arguments to the list and there was no ability to change the default list.
+
+```yaml
+services:
+    kube-controller:
+      extra_args:
+        cluster-name: "mycluster"
+```
+
+### Extra Binds
+
+Additional volume binds can be added to services using the `extra_binds` arguments.
+
+```yaml
+services:
+    kubelet:
+      extra_binds:
+        - "/host/dev:/dev"
+        - "/usr/libexec/kubernetes/kubelet-plugins:/usr/libexec/kubernetes/kubelet-plugins:z"
+```
+
+### Extra Environment Variables
+
+Additional environment variables can be added to services by using the `extra_env` arguments.
+
+```yaml
+services:
+    kubelet:
+      extra_env:
+        - "HTTP_PROXY=http://your_proxy"
+```
@@ -1,55 +1,63 @@
 ---
 title: System Images
-weight: 3020
+weight: 225
 draft: true
 ---
 When RKE is deploying Kubernetes, there are several images that are pulled. These images are used as Kubernetes system components as well as helping to deploy these system components.  

 As of `v0.1.6`, the functionality of a couple of the system images were consolidated into a single `rancher/rke-tools` image to simplify and speed the deployment process.

+You can configure the [network plug-ins]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/network-plugins/) and [ingress controller]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/ingress-controllers/) as well as the options for these add-ons separately.
+
 This is the example of the full list of system images used to deploy Kubernetes through RKE. The image tags are dependent on the [Kubernetes image/version used](https://github.com/rancher/types/blob/master/apis/management.cattle.io/v3/k8s_defaults.go).

 > **Note:** As versions of RKE are released, the tags on these images will no longer be up to date. This list is specific for `v1.10.3-rancher2`.

 ```yaml
 system_images:
-  kubernetes: rancher/hyperkube:v1.10.3-rancher2
-  etcd: rancher/coreos-etcd:v3.1.12
-  alpine: rancher/rke-tools:v0.1.9
-  nginx_proxy: rancher/rke-tools:v0.1.9
-  cert_downloader: rancher/rke-tools:v0.1.9
-  kubernetes_services_sidecar: rancher/rke-tools:v0.1.9
-  kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.8
-  dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.8
-  kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.8
-  kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
-  pod_infra_container: rancher/pause-amd64:3.1
+    kubernetes: rancher/hyperkube:v1.10.3-rancher2
+    etcd: rancher/coreos-etcd:v3.1.12
+    alpine: rancher/rke-tools:v0.1.9
+    nginx_proxy: rancher/rke-tools:v0.1.9
+    cert_downloader: rancher/rke-tools:v0.1.9
+    kubernetes_services_sidecar: rancher/rke-tools:v0.1.9
+    kubedns: rancher/k8s-dns-kube-dns-amd64:1.14.8
+    dnsmasq: rancher/k8s-dns-dnsmasq-nanny-amd64:1.14.8
+    kubedns_sidecar: rancher/k8s-dns-sidecar-amd64:1.14.8
+    kubedns_autoscaler: rancher/cluster-proportional-autoscaler-amd64:1.0.0
+    pod_infra_container: rancher/pause-amd64:3.1

-  # Networking Options
-  flannel: rancher/coreos-flannel:v0.9.1
-  flannel_cni: rancher/coreos-flannel-cni:v0.2.0
-  calico_node: rancher/calico-node:v3.1.1
-  calico_cni: rancher/calico-cni:v3.1.1
-  calico_ctl: rancher/calico-ctl:v2.0.0
-  canal_node: rancher/calico-node:v3.1.1
-  canal_cni: rancher/calico-cni:v3.1.1
-  canal_flannel: rancher/coreos-flannel:v0.9.1
-  weave_node: weaveworks/weave-kube:2.1.2
-  weave_cni: weaveworks/weave-npc:2.1.2
+    # Flannel Networking Options
+    flannel: rancher/coreos-flannel:v0.9.1
+    flannel_cni: rancher/coreos-flannel-cni:v0.2.0

-  # Ingress OPTIONS
-  ingress: rancher/nginx-ingress-controller:0.10.2-rancher3
-  ingressBackend: rancher/nginx-ingress-controller-defaultbackend:1.4
+    # Calico Networking Options
+    calico_node: rancher/calico-node:v3.1.1
+    calico_cni: rancher/calico-cni:v3.1.1
+    calico_ctl: rancher/calico-ctl:v2.0.0
+
+    # Canal Networking Options
+    canal_node: rancher/calico-node:v3.1.1
+    canal_cni: rancher/calico-cni:v3.1.1
+    canal_flannel: rancher/coreos-flannel:v0.9.1
+
+    # Weave Networking Options
+    weave_node: weaveworks/weave-kube:2.1.2
+    weave_cni: weaveworks/weave-npc:2.1.2
+
+    # Ingress Options
+    ingress: rancher/nginx-ingress-controller:0.10.2-rancher3
+    ingressBackend: rancher/nginx-ingress-controller-defaultbackend:1.4
 ```

 Prior to `v0.1.6`, instead of using the `rancher/rke-tools` image, we used the following images:

 ```yaml
 system_images:
-  alpine: alpine:latest
-  nginx_proxy: rancher/rke-nginx-proxy:v0.1.1
-  cert_downloader: rancher/rke-cert-deployer:v0.1.1
-  kubernetes_services_sidecar: rancher/rke-service-sidekick:v0.1.0
+    alpine: alpine:latest
+    nginx_proxy: rancher/rke-nginx-proxy:v0.1.1
+    cert_downloader: rancher/rke-cert-deployer:v0.1.1
+    kubernetes_services_sidecar: rancher/rke-service-sidekick:v0.1.0
 ```

 ### Air-gapped Setups
@@ -4,47 +4,74 @@ weight: 50
 draft: true
 ---

-<!-- Mohamed: Refer to the blog to see how this could be better written-->
+
+
+RKE is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can get started in a couple of quick and easy steps:
+
+1. [Download the RKE Binary](#download-the-rke-bindary)
+2. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
+3. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
+4. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
+5. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)

 ## Requirements

- Docker versions `1.11.2` up to `1.13.1` and `17.03.x` are validated for Kubernetes versions 1.8, 1.9 and 1.10
- OpenSSH 7.0+ must be installed on each node for stream local forwarding to work.
- The SSH user used for node access must be a member of the `docker` group:
+- For  Kubernetes versions 1.8, 1.9 and 1.10, Docker versions `1.11.2` up to `1.13.1` and `17.03.x` are validated
+- OpenSSH 7.0+ must be installed on each node for stream local forwarding to work
+- The SSH user used for node access must be a member of the `docker` group on the node:

-```bash
-usermod -aG docker <user_name>
-```
+   ```bash
+   usermod -aG docker <user_name>
+   ```

 - Ports 6443, 2379, and 2380 should be opened between cluster nodes.
- Swap disabled on worker nodes.
+- Swap should be disabled on any worker nodes

-### Download the rke binary
+## Download the RKE binary

-Browse to the [latest release](https://github.com/rancher/rke/releases/latest) and download `rke_darwin-amd64` for MacOS and `rke_linux-amd64` if you use a Linux machine.
+1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:

-When you have downloaded the binary, you can make it executable by running `chmod +x rke_darwin-amd64` or `chmod +x rke_linux-amd64`.
+    - **MacOS**: `rke_darwin-amd64`
+    - **Linux**: `rke_linux-amd64`
+    - **Windows**: `rke_windows-amd64.exe`

-After, you can test if it's executable by running `./rke_darwin-amd64 -version` or `./rke_linux-amd64 -version`.
+2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run one of the commands below.

-```bash
-$ chmod +x rke_darwin-amd64
-$ ./rke_darwin-amd64 -version
-rke version v0.1.5
-```
+    >**Using Windows?**
+    >The file is already an executable. Skip to [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster).

-### Preparing Linux machines to be used in the cluster
+    ```
+    # MacOS
+    $ chmod +x rke_darwin-amd64
+    # Linux
+    $ chmod +x rke_linux-amd64
+    ```

-The Kubernetes cluster components are launched using Docker on a Linux machine. You can use any Linux you want, as long as you can install Docker on it. The most commonly used OS is the current Ubuntu LTS release, 16.04. Kubernetes runs integration tests on the following Docker versions: `1.11.2` to `1.13.1`, and `17.03.x`. We follow these tested Docker versions by marking them as supported. To make installing Docker easy, we've created `install-docker` scripts. Pick the version you want to install and run the command in the `Install Script` column to install it.
+3.  Confirm that RKE is now executable by running the following command:

-Version   | Supported? | Install Script |
----------|------------|------------------
-`1.11.2`  | Yes        | <code>curl https://releases.rancher.com/install-docker/1.11.sh &#124; sh</code> |
-`1.12.6`  | Yes        | <code>curl https://releases.rancher.com/install-docker/1.12.sh &#124; sh</code> |
-`1.13.1`  | Yes        | <code>curl https://releases.rancher.com/install-docker/1.13.sh &#124; sh</code> |
-`17.03.2` | Yes        | <code>curl https://releases.rancher.com/install-docker/17.03.sh &#124; sh</code> |
+    ```
+    # MacOS
+    $ ./rke_darwin-amd64 --version
+    # Linux
+    $ ./rke_linux-amd64 --version
+    ```

-You can test if Docker is installed correctly by running `docker version`, it should show the client and server version.
+## Prepare the Nodes for the Kubernetes cluster
+
+The Kubernetes cluster components are launched using Docker on a Linux machine. You can use any Linux you want, as long as you can install Docker on it. The most commonly used OS is the current Ubuntu LTS release, 16.04. Kubernetes runs integration tests on the following Docker versions: `1.11.2` to `1.13.1`, and `17.03.x`. We follow these tested Docker versions by marking them as supported.
+
+### Install Docker
+
+You can either follow the [Docker installation](https://docs.docker.com/install/) instructions or you can use one of Rancher's [install scripts](https://github.com/rancher/install-docker) to install Docker.
+
+Docker Version   | Install Script |
+----------|------------------
+1.11.2  |  <code>curl https://releases.rancher.com/install-docker/1.11.sh &#124; sh</code> |
+1.12.6  |  <code>curl https://releases.rancher.com/install-docker/1.12.sh &#124; sh</code> |
+1.13.1  | <code>curl https://releases.rancher.com/install-docker/1.13.sh &#124; sh</code> |
+17.03.2 |  <code>curl https://releases.rancher.com/install-docker/17.03.sh &#124; sh</code> |
+
+Confirm that a Kubernetes supported version of Docker is installed on your machine, by running  `docker version`.

 ```bash
 $ docker version
@@ -66,9 +93,11 @@ Server:
 Experimental: false
 ```

-To connect to the Kubernetes cluster, port `TCP/6443` needs to be opened to the machine. If you are using an external firewall, make sure you have this opened between the machine you are using to run `rke` and the machine you are going to use in the cluster. If you are using `iptables` or `firewalld`, you can use the following commands:
+### Port Requirements

-Example opening port TCP/6443 using `iptables`
+In order for the Kubernetes cluster to be deployed, port `TCP/6443` needs to be opened to the machine. If you are using an external firewall, make sure you have this port opened between the machine you are using to run `rke` and the machine you are going to use in the cluster.
+
+#### Opening port TCP/6443 using `iptables``

 ```bash
 # Open TCP/6443 for all
@@ -78,7 +107,7 @@ iptables -A INPUT -p tcp --dport 6443 -j ACCEPT
 iptables -A INPUT -p tcp -s your_ip_here --dport 6443 -j ACCEPT
 ```

-Example opening port TCP/6443 using `firewalld`
+#### Opening port TCP/6443 using `firewalld`

 ```bash
 # Open TCP/6443 for all
@@ -93,102 +122,60 @@ firewall-cmd --permanent --zone=public --add-rich-rule='
 firewall-cmd --reload
 ```

-## Creating your cluster configuration
+## Creating the Cluster Configuration File

-### Using RKE to generate a cluster.yml
+RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes) for your Kubernetes cluster.

-RKE provides the command `rke config` to generate a cluster configuration template or to interactivity generate a working cluster configuration file.
+There are two easy ways to create a `cluster.yml`:

-Start by running the following command:
+- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/v0.1.x/en/config-options/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
+- Using `rke config` to query for all the information needed.

+### Using `rke config`
+
+RKE provides the command `rke config` to generate a cluster configuration template or to interactivity generate a working cluster configuration file. Review [our cluster configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) to understand what each question means.
+
+#### Creating a Basic `cluster.yml`
 ```bash
-rke config --name cluster.yml
+$ rke config --name cluster.yml
 ```

-RKE will interactivity prompt the user for cluster configuration such as number of the hosts, IP addresses or hostnames, ssh users..etc.
+After answering the list of questions, there is a `cluster.yml` created in the directory where you launched the `rke config` command.

-You can also use the `--empty` flag, which will generate an empty cluster.yml template:
-```bash
-rke config --empty --name cluster.yml
-```
+#### Creating an Empty `cluster.yml`

-Additionally, it's possible to print the generated configuration to stdout and skip creating a file using the `--print` flag:
+If you want an empty `cluster.yml` template, you can use the `--empty` flag so that a template is produced, but there are no values in the template.

 ```bash
-rke config --print
+$ rke config --empty --name cluster.yml
 ```

+#### Printing the `cluster.yml`

-
-### Creating your first Kubernetes cluster
-
-For this quick start, we will be configuring one machine. There are 3 roles you can define on a machine:
-
-Role   | Description |
----------|----------|
-etcd  | Keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. |
-controlplane  | Responsible of running all the master components of your cluster, like the `kube-apiserver`, `controller-manager` and the `scheduler`.  |
-worker | Workers will run the actual workloads. |
-
-<br>
-
-To create the `cluster.yml`, you can run `./rke_darwin-amd64 config` or `./rke_linux-amd64 config`. It will query you for all the information needed to build your cluster.
+Instead of creating a file, you can print the generated configuration to stdout using the `--print` flag.

 ```bash
-./rke_darwin-amd64 config
-# SSH private key location to use
-[+] Cluster Level SSH Private Key Path [~/.ssh/id_rsa]: ~/.ssh/your_rsa_key
-# For this example we'll be using one host
-[+] Number of Hosts [1]:
-# Address where the host is reachable over SSH
-[+] SSH Address of host (1) [none]: 10.0.0.1
-# SSH Port to use
-[+] SSH Port of host (1) [22]:
-# You can configure SSH keys per configured host, not needed in this example
-[+] SSH Private Key Path of host (10.0.0.1) [none]:
-[-] You have entered empty SSH key path, trying fetch from SSH key parameter
-[+] SSH Private Key of host (10.0.0.1) [none]:
-[-] You have entered empty SSH key, defaulting to cluster level SSH key: ~/.ssh/your_rsa_key
-# Username to use for the SSH connection
-[+] SSH User of host (10.0.0.1) [ubuntu]: root
-# We'll be configuring all three roles onto this single host
-[+] Is host (10.0.0.1) a control host (y/n)? [y]: y
-[+] Is host (10.0.0.1) a worker host (y/n)? [n]: y
-[+] Is host (10.0.0.1) an Etcd host (y/n)? [n]: y
-# If you want to override the hostname for this host, you can specify that here
-[+] Override Hostname of host (10.0.0.1) [none]:
-# If the host has multiple network connections, you can specify a private network connection here
-[+] Internal IP of host (10.0.0.1) [none]:
-# The location of the Docker socket
-[+] Docker socket path on host (10.0.0.1) [/var/run/docker.sock]:
-# Network plugin to use for your cluster
-[+] Network Plugin Type (flannel, calico, weave, canal) [flannel]:
-# We will be using certificates as authentication strategy
-[+] Authentication Strategy [x509]:
-# RBAC will be turned on
-[+] Authorization Mode (rbac, none) [rbac]:
-# Images to use for your cluster
-[+] Etcd Docker Image [rancher/coreos-etcd:v3.0.17]:
-[+] Kubernetes Docker image [rancher/k8s:v1.8.9-rancher1-1]:
-# Internal cluster domain to be used
-[+] Cluster domain [cluster.local]:
-# IP ranges to be used by the clusters
-[+] Service Cluster IP Range [10.233.0.0/18]:
-# If we want to use PodSecurityPolicy
-[+] Enable PodSecurityPolicy [n]:
-[+] Cluster Network CIDR [10.233.64.0/18]:
-[+] Cluster DNS Service IP [10.233.0.3]:
-# The container image to be used by Kubernetes pods
-[+] Infra Container image [rancher/pause-amd64:3.0]:
+$ rke config --print
 ```

-There should be a `cluster.yml` created in the directory where you launched the rke command. If you have to correct anything, you can do that directly in the `cluster.yml` file.
+### High Availability

-If you are satisfied with the configuration, you can start building your cluster by using `./rke_darwin-amd64 up` or `./rke_linux-amd64 up`.
+RKE is HA ready, you can specify more than one `controlplane` node in the `cluster.yml` file. RKE will deploy master components on all of these nodes and the kubelets are configured to connect to `127.0.0.1:6443` by default which is the address of `nginx-proxy` service that proxy requests to all master nodes.

-### Running RKE
+To create an HA cluster, specify more than one host with role `controlplane`. 

+## Deploying Kubernetes with RKE

+After you've created your `cluster.yml`, you can deploy your cluster with a simple command. This command assumes the `cluster.yml` file is in the same directory as where you are running the command.
+
+```
+# MacOS
+$ ./rke_darwin-amd64 up
+# Linux
+$ ./rke_linux-amd64 up
+```
+
+There will be log statements as the Kubernetes cluster is created.

 ```bash
 $ ./rke_darwin-amd64 up
@@ -200,22 +187,23 @@ INFO[0000] [network] Pulling image [alpine:latest] on host [10.0.0.1]
 INFO[0101] Finished building Kubernetes cluster successfully
 ```

-The last line should read `Finished building Kubernetes cluster successfully` to indicate that your cluster is ready to use. A kubeconfig file has been written to `kube_config_cluster.yml` to be used to interact with your cluster.
+The last line should read `Finished building Kubernetes cluster successfully` to indicate that your cluster is ready to use. As part of the Kubernetes creation process, a `kubeconfig` file has been created and written at `kube_config_cluster.yml`, which can be used to start interacting your Kubernetes cluster.

-### Interacting with your cluster
+### Interacting with your Kubernetes cluster

-The way you interact with your cluster is by the use of a binary called `kubectl`. Before we can issue commands to our cluster, we need to download the `kubectl` binary. Please follow [the intructions](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on the Kubernetes documentation page to install `kubectl`. You can verify the installation of `kubectl` and the connection to the cluster using `kubectl --kubeconfig kube_config_cluster.yml version`.
+In order to start interacting with your Kubernetes cluster, you will use a different binary called `kubectl`. You will need to [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local machine. You can connect to the RKE created cluster by using the `kube_config_cluster.yml` that was generated when you deployed Kubernetes.

 ```bash
+# Confirm that kubectl is working by checking the version of your Kubernetes cluster
 $ kubectl --kubeconfig kube_config_cluster.yml version
 Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
 Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.9-rancher1", GitCommit:"68595e18f25e24125244e9966b1e5468a98c1cd4", GitTreeState:"clean", BuildDate:"2018-03-13T04:37:53Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
 ```

-The client and server version are reported, indicating that you have a local `kubectl` client and are able to request the server version from the newly built cluster. Now you can issue any command to your cluster, like requesting the nodes that are in the cluster using `kubectl --kubeconfig kube_config_cluster.yml get nodes`
+The client and server version are reported, indicating that you have a local `kubectl` client and are able to request the server version from the newly built cluster. Now, you can issue any command to your cluster, like requesting the nodes that are in the cluster.

 ```bash
 $ kubectl --kubeconfig kube_config_cluster.yml get nodes
 NAME            STATUS    ROLES                      AGE       VERSION
-10.0.0.1         Ready     controlplane,etcd,worker   35m       v1.8.9-rancher1
+10.0.0.1         Ready     controlplane,etcd,worker   35m       v1.10.3-rancher1
 ```
@@ -1,16 +1,17 @@
 ---
 title: Backups and Disaster Recovery
-weight: 3000
+weight: 65
 draft: true
 ---

-You can configure a Rancher Kubernetes Engine (RKE) cluster to automatically take snapshots of etcd. In a disaster scenario, you can restore these snapshots, which are stored on other cluster nodes.
+As of v0.1.7, you can configure a RKE cluster to automatically take snapshots of etcd. In a disaster scenario, you can restore these snapshots, which are stored on other nodes in the cluster.

-### One-Time Snapshots
+## One-Time Snapshots

-RKE introduce a new command that can take a snapshot of a running etcd node in rke cluster, the snapshot will be automatically saved in `/opt/rke/etcd-snapshots`, the commands works as following:
-```
-./rke etcd snapshot-save --config cluster.yml     
+RKE can take a one-time snapshot of a running etcd node in a RKE cluster. The snapshot is automatically saved in `/opt/rke/etcd-snapshots`.
+
+```bash
+$ rke etcd snapshot-save --config cluster.yml     

 WARN[0000] Name of the snapshot is not specified using [rke_etcd_snapshot_2018-05-17T23:32:08+02:00]
 INFO[0000] Starting saving snapshot on etcd hosts       
@@ -26,15 +27,16 @@ INFO[0006] [etcd] Successfully started [etcd-snapshot-once] container on host [z
 INFO[0006] Finished saving snapshot [rke_etcd_snapshot_2018-05-17T23:32:08+02:00] on all etcd hosts
 ```

-The command will save a snapshot of etcd from each etcd node in the cluster config file and will save it in `/opt/rke/etcd-snapshots`. This command also creates a container for taking the snapshot. When the process completes, the container is automatically removed.
+The command will save a snapshot of etcd from each etcd node in the cluster config file and will save it in `/opt/rke/etcd-snapshots`. When running the command, an additional container is created to take the snapshot. When the snapshot is completed, the container is automatically removed.

-### Etcd Recurring Snapshots
+## Etcd Recurring Snapshots

-To schedule a recurring automatic etcd snapshot save, enable the `etcd-snapshot` service. `etcd-snapshot` runs in a service container alongside the `etcd` container. `etcd-snapshot` automatically takes a snapshot of etcd and stores them to its local disk in `/opt/rke/etcd-snapshots`.
+To schedule a recurring automatic etcd snapshot save, you can enable the `etcd-snapshot` service. `etcd-snapshot` runs in a service container alongside the `etcd` container. `etcd-snapshot` automatically takes a snapshot of etcd and stores them to its local disk in `/opt/rke/etcd-snapshots`.

-To enable `etcd-snapshot` in RKE CLI, configure the following three variables:

-```
+In the `cluster.yml`, you need to turn enable `snapshot` as part of the `etcd service`. Additionally, you want to specify `creation` and `retention` for the snapshot service.
+
+```yaml
 services:
  etcd:
    snapshot: true
@@ -42,20 +44,11 @@ services:
    retention: 24h
 ```

- `snapshot`: Enables/disables etcd snapshot recurring service in the RKE cluster.

-	Default value: `false`.
- `creation`: Time period in which `etcd-sanpshot` take snapshots.
+When a cluster is launched with the etcd snapshot service enabled, you can view the `etcd-snapshot` logs to confirm backups are being created automatically.

-	Default value: `5m0s`
-
- `retention`: Time period before before an etcd snapshot expires. Expired snapshots are purged.
-
-	Default value: `24h`
-
-After RKE runs, view the `etcd-snapshot` logs to confirm backups are being created automatically:
 ```
-# docker logs etcd-snapshot
+$ docker logs etcd-snapshot

 time="2018-05-04T18:39:16Z" level=info msg="Initializing Rolling Backups" creation=1m0s retention=24h0m0s
 time="2018-05-04T18:40:16Z" level=info msg="Created backup" name="2018-05-04T18:40:16Z_etcd" runtime=108.332814ms
@@ -63,17 +56,31 @@ time="2018-05-04T18:41:16Z" level=info msg="Created backup" name="2018-05-04T18:
 time="2018-05-04T18:42:16Z" level=info msg="Created backup" name="2018-05-04T18:42:16Z_etcd" runtime=83.67642ms
 time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:43:16Z_etcd" runtime=86.298499ms
 ```
-Backups are saved to the following directory: `/opt/rke/etcd-snapshots/`. Backups are created on each node that runs etcd.

+For every node that has the `etcd` role, these `backups` are saved to `/opt/rke/etcd-snapshots/`.

-### Etcd Disaster recovery
+### Snapshot Options

-`etcd snapshot-restore` is used for etcd Disaster recovery, it reverts to any snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. When you run `etcd snapshot-restore`, RKE removes the old etcd container if it still exists. To restore operations, RKE creates a new etcd cluster using the snapshot you choose.
+**Snapshot**

->**Warning:** Restoring an etcd snapshot deletes your current etcd cluster and replaces it with a new one. Before you run the `etcd snapshot-restore` command, backup any important data in your current cluster.
+By default, the recurring snapshot service is disabled. To enable the service, you need to define it as part of `etcd` and set it to `true`.

-```
-./rke etcd snapshot-restore --name snapshot --config cluster.yml
+**Creation**
+
+By default, the snapshot service will take snapshots every 5 minutes (`5m0s`). You can change the time between snapshots as part of the `creation` directive for the `etcd` service.
+
+**Retention**
+
+By default, all snapshots are saved for 24 hours (`24h`) before being deleted and purged. You can change how long to store a snapshot as part of the `retention` directive for the `etcd` service.
+
+## Etcd Disaster recovery
+
+If there is a disaster with your Kubernetes cluster, you can use `rke etcd snapshot-restore` to recover your etcd. This command will revert to a specific snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. During the restore process, RKE also removes the old `etcd` container before creating a new `etcd` cluster using the snapshot that you have chosen.
+
+>**Warning:** Restoring an etcd snapshot deletes your current etcd cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, you should back up any important data in your cluster.
+
+```bash
+$ rke etcd snapshot-restore --name mysnapshot --config cluster.yml
 INFO[0000] Starting restore on etcd hosts
 INFO[0000] [dialer] Setup tunnel for host [x.x.x.x]
 INFO[0002] [dialer] Setup tunnel for host [y.y.y.y]
@@ -115,62 +122,43 @@ INFO[0027] Finished restoring on all etcd hosts

 ## Example

-In this example we will assume that you started RKE on two nodes:
+In this example, the Kubernetes cluster was deployed on two AWS nodes.

 |  Name |    IP    |          Role          |
 |:-----:|:--------:|:----------------------:|
 | node1 | 10.0.0.1 | [controlplane, worker] |
 | node2 | 10.0.0.2 | [etcd]                 |

-### 1. Setting up rke cluster
-A minimal cluster configuration file for running k8s on these nodes should look something like the following:
+### Back up the `etcd` cluster

-```
-nodes:
-  - address: 10.0.0.1
-    hostname_override: node1
-    user: ubuntu
-    role: [controlplane,worker]
-  - address: 10.0.0.2
-    hostname_override: node2
-    user: ubuntu
-    role: [etcd]
-```
+Take a snapshot of the Kubernetes cluster.

-After running `rke up` you should be able to have a two node cluster, the next step is to run few pods on node1:
-
-```
-kubectl --kubeconfig=kube_config_cluster.yml run nginx --image=nginx --replicas=3
-```
-
-### 2. Backup etcd cluster
-
-Now lets take a snapshot using RKE:
-
-```
-rke etcd snapshot-save --name snapshot.db --config cluster.yml
+```bash
+$ rke etcd snapshot-save --name snapshot.db --config cluster.yml
 ```

 ![etcd snapshot](img/rke-etcd-backup.png)

-### 3. Store snapshot externally
+### Store the snapshot externally

-After taking the etcd backup on node2 we should be able to save this backup in a persistence place, one of the options to do that is to save the backup taken on a s3 bucket or tape backup, for example:
+After taking the etcd snapshot on `node2`, we recommend saving this backup in a persistence place. One of the options is to save the backup on a S3 bucket or tape backup.

-```
+```bash
+# If you're using an AWS host and have the ability to connect to S3
 root@node2:~# s3cmd mb s3://rke-etcd-backup
 root@node2:~# s3cmd /opt/rke/etcdbackup/snapshot.db s3://rke-etcd-backup/
 ```

-### 4. Pull the backup on a new node
+### Place the backup on a new node

-To simulate the failure lets powerdown node2 completely:
+To simulate the failure, let's power down `node2`.

-```
+```bash
 root@node2:~# poweroff
 ```

-Now its time to pull the backup saved on s3 on a new node:
+Before restoring etcd and running `rancher up`, we need to retrieve the backup saved on S3 to a new node, e.g. `node3`.
+

 |  Name |    IP    |          Role          |
 |:-----:|:--------:|:----------------------:|
@@ -178,14 +166,18 @@ Now its time to pull the backup saved on s3 on a new node:
 | ~~node2~~ | ~~10.0.0.2~~ | ~~[etcd]~~                 |
 | node3 | 10.0.0.3 | [etcd]                 |
 |   |   |   |
-```
+
+```bash
+# Make a Directory
 root@node3:~# mkdir -p /opt/rke/etcdbackup
+$ Get the Backup from S3
 root@node3:~# s3cmd get s3://rke-etcd-backup/snapshot.db /opt/rke/etcdbackup/snapshot.db
 ```

-### 5. Restore etcd on the new node
+###  Restore `etcd` on the new node from the backup
+
+Before updating and restoring etcd, you will need to add the new node into the Kubernetes cluster with the `etcd` role. In the `cluster.yml`, comment out the old node and add in the new node. `

-Now lets do a restore to restore and run etcd on the third node, in order to do that you have first to add the third node to the cluster configuration file:
 ```
 nodes:
  - address: 10.0.0.1
@@ -201,17 +193,22 @@ nodes:
    user: ubuntu
    role: [etcd]
 ```
-and then run `rke etcd restore`:
-```
-rke etcd snapshot-restore --name snapshot.db --config cluster.yml
+
+After the new node is added to the `cluster.yml`, run `rke etcd snapshot-restore` to launch `etcd` from the backup.  ]
+
+```bash
+$ rke etcd snapshot-restore --name snapshot.db --config cluster.yml
 ```

-The previous command will restore the etcd data dir from the snapshot and run etcd container on this node, the final step is to restore the operations on the cluster by making the k8s api to point to the new etcd, to do that we run `rke up` again on the new cluster.yml file:
-```
-rke up --config cluster.yml
-```
-You can make sure that operations have been restored by checking the nginx deployment we created earlier:
+Finally, we need to restore the operations on the cluster by making the Kubernetes API point to the new `etcd`  by running `rke up` again using the new `cluster.yml`.
+
+```bash
+$ rke up --config cluster.yml
 ```
+
+Confirm that your Kubernetes cluster is functional by checking the pods on your cluster.
+
+```bash
 > kubectl get pods                                                    
 NAME                     READY     STATUS    RESTARTS   AGE
 nginx-65899c769f-kcdpr   1/1       Running   0          17s
@@ -1,25 +1,34 @@
 ---
 title: Managing RKE Clusters
-weight: 51
+weight: 60
 draft: true
 ---

-## Adding/Removing Nodes
+### Adding/Removing Nodes

-RKE supports adding/removing nodes for worker and controlplane hosts, in order to add additional nodes you will only need to update the `cluster.yml` file with additional nodes and run `rke up` with the same file.
+RKE supports adding/removing [nodes]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes/) for worker and controlplane hosts.

-To remove nodes just remove them from the hosts list in the cluster configuration file `cluster.yml`, and re run `rke up` command.
+In order to add additional nodes, you update the original `cluster.yml` file with any additional nodes and specify their role in the Kubernetes cluster.

-## Cluster Remove
+In order to remove nodes, remove the node information from the nodes list in the original `cluster.yml`.

-RKE supports `rke remove` command, the command does the following:
+After you've made changes to add/remove nodes, run `rke up` with the updated `cluster.yml`.

- Connect to each host and remove the kubernetes services deployed on it.
+### Removing Kubernetes Clusters from Nodes
+
+In order to remove the Kubernetes components from nodes, you use the `rke remove` command.
+
+> **Note:** This command is irreversible and will destroy the Kubernetes cluster.
+
+This command does the following to each node in the `cluster.yml`:
+
+
+- Remove the Kubernetes services deployed on it
 - Clean each host from the directories left by the services:
+  ```
  - /etc/kubernetes/ssl
  - /var/lib/etcd
  - /etc/cni
  - /opt/cni
  - /var/run/calico
-
-Note that this command is irreversible and will destroy the kubernetes cluster entirely.
+  ```
@@ -1,26 +1,50 @@
 ---
 title: Operating System Notes
-weight: 60
+weight: 55
 draft: true
 ---

 <!-- Add some information about requirements on most operating systems
 Add in notes of which OS are currently used-->

+### OS Requirements

-### Atomic OS
+- For  Kubernetes versions 1.8, 1.9 and 1.10, Docker versions `1.11.2` up to `1.13.1` and `17.03.x` are validated
+- OpenSSH 7.0+ must be installed on each node for stream local forwarding to work
+- The SSH user used for node access must be a member of the `docker` group on the node:

- Container volumes may have some issues in Atomic OS due to SELinux, most of volumes are mounted in rke with option `z`, however user still need to run the following commands before running rke:
-```
+   ```bash
+   usermod -aG docker <user_name>
+   ```
+
+- Ports 6443, 2379, and 2380 should be opened between cluster nodes.
+- Swap should be disabled on any worker nodes
+
+
+## Atomic Hosts
+
+Before trying to use RKE with Atomic hosts, there are a couple of updates to the OS that need to occur in order to get RKE working.
+
+### Container Volumes
+
+In RKE, most of the volumes are mounted with option `z`, but there are some container volumes that may have some issues in Atomic due to SELinux.
+
+Before running RKE, users will need to run the following commands to make some additional directories:
+
+```bash
 # mkdir /opt/cni /etc/cni
 # chcon -Rt svirt_sandbox_file_t /etc/cni
 # chcon -Rt svirt_sandbox_file_t /opt/cni
 ```
- OpenSSH 6.4 shipped by default on Atomic CentOS which doesn't support SSH tunneling and therefore breaks rke, upgrading OpenSSH to the latest version supported by Atomic host will solve this problem:
-```
-# atomic host upgrade
-```
- Atomic host doesn't come with docker group by default, you can change ownership of docker.sock to enable specific user to run rke:
-```
+
+### OpenSSH version
+
+By default, Atomic hosts ship with OpenSSH 6.4, which doesn't support SSH tunneling, which is a core RKE requirement. If you upgrade to the latest version of OpenSSH supported by Atomic, it will correct the SSH issue.
+
+### Creating a Docker Group
+
+By default, Atomic hosts do not come with a Docker group. You can update the ownership of the Docker socket by enabling the specific user in order to launch RKE.
+
+```bash
 # chown <user> /var/run/docker.sock
 ```
@@ -1,37 +1,49 @@
 ---
 title: Upgrades
-weight: 1000
+weight: 70
 draft: true
 ---

-You can upgrade your Kubernetes cluster or upgrade any of the service arguments.
+After RKE has deployed Kubernetes, you can upgrade the versions of the components in your Kubernetes cluster, [definition of the Kubernetes services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) or [add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/).

-## Cluster Upgrade
+## Version Upgrades

-RKE supports kubernetes cluster upgrade through changing the image version of services, in order to do that change the image option for each services, for example:
+RKE supports version upgrades by changing the image tags of the [system-images]({{< baseurl >}}/rke/v0.1.x/en/config-options/system-images/).
+
+For example, to change the deployed Kubernetes version, you update the `rancher/hyperkube` tag from `v1.9.7` to `v1.10.3` in the `cluster.yml` that was originally used to deploy your Kubernetes cluster.
+
+Original YAML

 ```yaml
-image: rancher/hyperkube:v1.9.7
+system-images:
+  kubernetes: rancher/hyperkube:v1.9.7
 ```

-TO
+Updated YAML

 ```yaml
-image: rancher/hyperkube:v1.10.1
+system-images:
+  kubernetes: rancherhyperkube:v1.10.3
 ```

-And then run:
+After updating your `cluster.yml` with the required changes, all you need to do is run `rke up` to upgrade Kubernetes.

 ```bash
-rke up --config cluster.yml
+$ rke up --config cluster.yml
 ```

-RKE will first look for the local `kube_config_cluster.yml` and then tries to upgrade each service to the latest image.
+First, RKE will use the local `kube_config_cluster.yml` to confirm the versions of the existing components in the Kubernetes cluster before upgrading to the latest image.

-> Note that rollback isn't supported in RKE and may lead to unxpected results
+> **Note:** RKE does not support rollback to previous versions.

-## Service Upgrade
+## Service Upgrades

-Service can also be upgraded by changing any of the services arguments or extra args and run `rke up` again with the updated configuration file.
+[Services]({{< baseurl >}}/rke/v0.1.x/en/config-options/services/) can be upgraded by changing any of the services arguments or `extra_args` and running `rke up` again with the updated configuration file.

-> Please note that changing the following arguments: `service_cluster_ip_range` or `cluster_cidr` will result in a broken cluster, because currently the network pods will not be automatically upgraded.
+> **Note:** The following arguments, `service_cluster_ip_range` or `cluster_cidr`, cannot be changed as any changes to these arguments will result in a broken cluster. Currently, network pods are not automatically upgraded.
+
+## Add-Ons Upgrades
+
+As of v0.1.8, upgrades to add-ons are supported.
+
+[Add-ons]({{< baseurl >}}/rke/v0.1.x/en/config-options/add-ons/) can also be upgraded by changing any of the add-ons and running `rke up` again with the updated configuration file.
@@ -1,7 +0,0 @@
---
-title: Overview
-weight: 1
-draft: true
---
-
-Rancher Kubernetes Engine (RKE) is an extremely simple, lightning fast Kubernetes installer that works everywhere.
@@ -5,32 +5,59 @@ weight: 25
 draft: true
 ---

-### Get the rke binary
+RKE is a fast, versatile Kubernetes installer that you can use to install Kubernetes on your Linux hosts. You can get started in a couple of quick and easy steps:

-Browse to the [latest release](https://github.com/rancher/rke/releases/latest) and download `rke_darwin-amd64` for MacOS and `rke_linux-amd64` if you use a Linux machine.
+1. [Download the RKE Binary](#download-the-rke-bindary)
+2. [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster)
+3. [Creating the Cluster Configuration File](#creating-the-cluster-configuration-file)
+4. [Deploying Kubernetes with RKE](#deploying-kubernetes-with-rke)
+5. [Interacting with your Kubernetes Cluster](#interacting-with-your-kubernetes-cluster)

-When you have downloaded the binary, you can make it executable by running `chmod +x rke_darwin-amd64` or `chmod +x rke_linux-amd64`.
+## Download the RKE binary

-After, you can test if it's executable by running `./rke_darwin-amd64 -version` or `./rke_linux-amd64 -version`.
+1. From your workstation, open a web browser and navigate to our [RKE Releases](https://github.com/rancher/rke/releases/latest) page. Download the latest RKE installer applicable to your Operating System:

-```bash
-$ chmod +x rke_darwin-amd64
-$ ./rke_darwin-amd64 -version
-rke version v0.1.5
-```
+    - **MacOS**: `rke_darwin-amd64`
+    - **Linux**: `rke_linux-amd64`
+    - **Windows**: `rke_windows-amd64.exe`

-### Preparing Linux machines to be used in the cluster
+2. Make the RKE binary that you just downloaded executable. Open Terminal, change directory to the location of the RKE binary, and then run one of the commands below.

-The Kubernetes cluster components are launched using Docker on a Linux machine. You can use any Linux you want, as long as you can install Docker on it. The most commonly used OS is the current Ubuntu LTS release, 16.04. Kubernetes runs integration tests on the following Docker versions: `1.11.2` to `1.13.1`, and `17.03.x`. We follow these tested Docker versions by marking them as supported. To make installing Docker easy, we've created `install-docker` scripts. Pick the version you want to install and run the command in the `Install Script` column to install it.
+    >**Using Windows?**
+    >The file is already an executable. Skip to [Prepare the Nodes for the Kubernetes Cluster](#prepare-the-nodes-for-the-kubernetes-cluster).

-Version   | Supported? | Install Script |
----------|------------|------------------
-`1.11.2`  | Yes        | <code>curl https://releases.rancher.com/install-docker/1.11.sh &#124; sh</code> |
-`1.12.6`  | Yes        | <code>curl https://releases.rancher.com/install-docker/1.12.sh &#124; sh</code> |
-`1.13.1`  | Yes        | <code>curl https://releases.rancher.com/install-docker/1.13.sh &#124; sh</code> |
-`17.03.2` | Yes        | <code>curl https://releases.rancher.com/install-docker/17.03.sh &#124; sh</code> |
+    ```
+    # MacOS
+    $ chmod +x rke_darwin-amd64
+    # Linux
+    $ chmod +x rke_linux-amd64
+    ```

-You can test if Docker is installed correctly by running `docker version`, it should show the client and server version.
+3.  Confirm that RKE is now executable by running the following command:
+
+    ```
+    # MacOS
+    $ ./rke_darwin-amd64 --version
+    # Linux
+    $ ./rke_linux-amd64 --version
+    ```
+
+## Prepare the Nodes for the Kubernetes cluster
+
+The Kubernetes cluster components are launched using Docker on a Linux machine. You can use any Linux you want, as long as you can install Docker on it. The most commonly used OS is the current Ubuntu LTS release, 16.04. Kubernetes runs integration tests on the following Docker versions: `1.11.2` to `1.13.1`, and `17.03.x`. We follow these tested Docker versions by marking them as supported.
+
+### Install Docker
+
+You can either follow the [Docker installation](https://docs.docker.com/install/) instructions or you can use one of Rancher's [install scripts](https://github.com/rancher/install-docker) to install Docker.
+
+Docker Version   | Install Script |
+----------|------------------
+1.11.2  |  <code>curl https://releases.rancher.com/install-docker/1.11.sh &#124; sh</code> |
+1.12.6  |  <code>curl https://releases.rancher.com/install-docker/1.12.sh &#124; sh</code> |
+1.13.1  | <code>curl https://releases.rancher.com/install-docker/1.13.sh &#124; sh</code> |
+17.03.2 |  <code>curl https://releases.rancher.com/install-docker/17.03.sh &#124; sh</code> |
+
+Confirm that a Kubernetes supported version of Docker is installed on your machine, by running  `docker version`.

 ```bash
 $ docker version
@@ -52,9 +79,11 @@ Server:
 Experimental: false
 ```

-To connect to the Kubernetes cluster, port `TCP/6443` needs to be opened to the machine. If you are using an external firewall, make sure you have this opened between the machine you are using to run `rke` and the machine you are going to use in the cluster. If you are using `iptables` or `firewalld`, you can use the following commands:
+### Port Requirements

-Example opening port TCP/6443 using `iptables`
+In order for the Kubernetes cluster to be deployed, port `TCP/6443` needs to be opened to the machine. If you are using an external firewall, make sure you have this port opened between the machine you are using to run `rke` and the machine you are going to use in the cluster.
+
+#### Opening port TCP/6443 using `iptables``

 ```bash
 # Open TCP/6443 for all
@@ -64,7 +93,7 @@ iptables -A INPUT -p tcp --dport 6443 -j ACCEPT
 iptables -A INPUT -p tcp -s your_ip_here --dport 6443 -j ACCEPT
 ```

-Example opening port TCP/6443 using `firewalld`
+#### Opening port TCP/6443 using `firewalld`

 ```bash
 # Open TCP/6443 for all
@@ -79,71 +108,54 @@ firewall-cmd --permanent --zone=public --add-rich-rule='
 firewall-cmd --reload
 ```

-### Creating `cluster.yml` and Kubernetes cluster
+## Creating the Cluster Configuration File

-For this quick start, we will be configuring one machine. There are 3 roles you can define on a machine:
+RKE uses a cluster configuration file, referred to as `cluster.yml` to determine what nodes will be in the cluster and how to deploy Kubernetes. There are [many configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) that can be set in the `cluster.yml`. In our example, we will be assuming the minimum of one [node]({{< baseurl >}}/rke/v0.1.x/en/config-options/nodes) for your Kubernetes cluster.

-Role   | Description |
----------|----------|
-etcd  | Keeps the state of your cluster and is the most important component in your cluster, single source of truth of your cluster. |
-controlplane  | Responsible of running all the master components of your cluster, like the `kube-apiserver`, `controller-manager` and the `scheduler`.  |
-worker | Workers will run the actual workloads. |
+There are two easy ways to create a `cluster.yml`:

-<br>
+- Using our [minimal `cluster.yml`]({{< baseurl >}}/rke/v0.1.x/en/config-options/example-yamls/#minimal-cluster-yml-example) and updating it based on the node that you will be using.
+- Using `rke config` to query for all the information needed.

-To create the `cluster.yml`, you can run `./rke_darwin-amd64 config` or `./rke_linux-amd64 config`. It will query you for all the information needed to build your cluster.
+### Using `rke config`
+
+To create a new `cluster.yml`, you can run `rke config` and this command will query for all the information needed to build your cluster. Review [our cluster configuration options]({{< baseurl >}}/rke/v0.1.x/en/config-options/) to understand what each question means. The ones that are required for this quick start guide are in the example below.
+
+> **Note:** As features are added into RKE, the list and order of questions may change.

 ```bash
 ./rke_darwin-amd64 config
-# SSH private key location to use
-[+] Cluster Level SSH Private Key Path [~/.ssh/id_rsa]: ~/.ssh/your_rsa_key
-# For this example we'll be using one host
-[+] Number of Hosts [1]:
+
+# This example is using one host
+[+] Number of Hosts [1]: 1
 # Address where the host is reachable over SSH
 [+] SSH Address of host (1) [none]: 10.0.0.1
 # SSH Port to use
-[+] SSH Port of host (1) [22]:
-# You can configure SSH keys per configured host, not needed in this example
-[+] SSH Private Key Path of host (10.0.0.1) [none]:
-[-] You have entered empty SSH key path, trying fetch from SSH key parameter
-[+] SSH Private Key of host (10.0.0.1) [none]:
-[-] You have entered empty SSH key, defaulting to cluster level SSH key: ~/.ssh/your_rsa_key
+[+] SSH Port of host (1) [22]: 22
+[+] SSH Private Key Path of host (10.0.0.1) [none]:  ~/.ssh/your_rsa_key
 # Username to use for the SSH connection
 [+] SSH User of host (10.0.0.1) [ubuntu]: root
+
 # We'll be configuring all three roles onto this single host
 [+] Is host (10.0.0.1) a control host (y/n)? [y]: y
 [+] Is host (10.0.0.1) a worker host (y/n)? [n]: y
 [+] Is host (10.0.0.1) an Etcd host (y/n)? [n]: y
-# If you want to override the hostname for this host, you can specify that here
-[+] Override Hostname of host (10.0.0.1) [none]:
-# If the host has multiple network connections, you can specify a private network connection here
-[+] Internal IP of host (10.0.0.1) [none]:
-# The location of the Docker socket
-[+] Docker socket path on host (10.0.0.1) [/var/run/docker.sock]:
-# Network plugin to use for your cluster
-[+] Network Plugin Type (flannel, calico, weave, canal) [flannel]:
-# We will be using certificates as authentication strategy
-[+] Authentication Strategy [x509]:
-# RBAC will be turned on
-[+] Authorization Mode (rbac, none) [rbac]:
-# Images to use for your cluster
-[+] Etcd Docker Image [rancher/coreos-etcd:v3.0.17]:
-[+] Kubernetes Docker image [rancher/k8s:v1.8.9-rancher1-1]:
-# Internal cluster domain to be used
-[+] Cluster domain [cluster.local]:
-# IP ranges to be used by the clusters
-[+] Service Cluster IP Range [10.233.0.0/18]:
-# If we want to use PodSecurityPolicy
-[+] Enable PodSecurityPolicy [n]:
-[+] Cluster Network CIDR [10.233.64.0/18]:
-[+] Cluster DNS Service IP [10.233.0.3]:
-# The container image to be used by Kubernetes pods
-[+] Infra Container image [rancher/pause-amd64:3.0]:
 ```

-There should be a `cluster.yml` created in the directory where you launched the rke command. If you have to correct anything, you can do that directly in the `cluster.yml` file.
+After answering the list of questions, there is a `cluster.yml` created in the directory where you launched the `rke config` command. After the `cluster.yml` is created, you can edit the file to make any changes.

-If you are satisfied with the configuration, you can start building your cluster by using `./rke_darwin-amd64 up` or `./rke_linux-amd64 up`.
+## Deploying Kubernetes with RKE
+
+After you've created your `cluster.yml`, you can deploy your cluster with a simple command. This command assumes the `cluster.yml` file is in the same directory as where you are running the command.
+
+```
+# MacOS
+$ ./rke_darwin-amd64 up
+# Linux
+$ ./rke_linux-amd64 up
+```
+
+There will be log statements as the Kubernetes cluster is created.

 ```bash
 $ ./rke_darwin-amd64 up
@@ -155,22 +167,23 @@ INFO[0000] [network] Pulling image [alpine:latest] on host [10.0.0.1]
 INFO[0101] Finished building Kubernetes cluster successfully
 ```

-The last line should read `Finished building Kubernetes cluster successfully` to indicate that your cluster is ready to use. A kubeconfig file has been written to `kube_config_cluster.yml` to be used to interact with your cluster.
+The last line should read `Finished building Kubernetes cluster successfully` to indicate that your cluster is ready to use. As part of the Kubernetes creation process, a `kubeconfig` file has been created and written at `kube_config_cluster.yml`, which can be used to start interacting your Kubernetes cluster.

-### Interacting with your cluster
+### Interacting with your Kubernetes cluster

-The way you interact with your cluster is by the use of a binary called `kubectl`. Before we can issue commands to our cluster, we need to download the `kubectl` binary. Please follow [the intructions](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on the Kubernetes documentation page to install `kubectl`. You can verify the installation of `kubectl` and the connection to the cluster using `kubectl --kubeconfig kube_config_cluster.yml version`.
+In order to start interacting with your Kubernetes cluster, you will use a different binary called `kubectl`. You will need to [install kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on your local machine. You can connect to the RKE created cluster by using the `kube_config_cluster.yml` that was generated when you deployed Kubernetes.

 ```bash
+# Confirm that kubectl is working by checking the version of your Kubernetes cluster
 $ kubectl --kubeconfig kube_config_cluster.yml version
 Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
 Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.9-rancher1", GitCommit:"68595e18f25e24125244e9966b1e5468a98c1cd4", GitTreeState:"clean", BuildDate:"2018-03-13T04:37:53Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
 ```

-The client and server version are reported, indicating that you have a local `kubectl` client and are able to request the server version from the newly built cluster. Now you can issue any command to your cluster, like requesting the nodes that are in the cluster using `kubectl --kubeconfig kube_config_cluster.yml get nodes`
+The client and server version are reported, indicating that you have a local `kubectl` client and are able to request the server version from the newly built cluster. Now, you can issue any command to your cluster, like requesting the nodes that are in the cluster.

 ```bash
 $ kubectl --kubeconfig kube_config_cluster.yml get nodes
 NAME            STATUS    ROLES                      AGE       VERSION
-10.0.0.1         Ready     controlplane,etcd,worker   35m       v1.8.9-rancher1
+10.0.0.1         Ready     controlplane,etcd,worker   35m       v1.10.3-rancher1
 ```