added prereq stating to copy etcd snapshot to all your etcd nodes

content/rancher/v2.x/en/tasks/workloads/add-a-dns-record/_index.md

@@ -3,4 +3,44 @@ title: Adding a DNS Record
 weight: 
 draft: true
 ---
-Coming Soon
+For every workload created, a complementing Service Discovery entry is created. This Service Discovery entry enables DNS resolution for the workload's pods using the following naming convention:
+`<workload>.<namespace>.svc.cluster.local`.
+
+However, you also have the option of creating additional Service Discovery records. You can use these additional records so that a given namespace resolves with one or more external IP addresses, an external hostname, an alias to another DNS record, other workloads, or a set of pods that match a selector that you create.
+
+1. From the **Global** view, open the project running ingress.
+
+1. Select the **Service Discovery** tab. Then click **Add Record**.
+
+1. Enter a **Name** for the DNS record.
+
+1. Select a **Namespace** from the drop-down list. Alternatively, you can create a new namespace on the fly by clicking **Add to a new namespace**.
+
+1. Select one of the **Resolves To** options to route requests to the DNS record.
+
+    1. **One or more external IP addresses**
+
+        Enter an IP address in the **Target IP Addresses** field. Add more IP addresses by clicking **Add Target IP**.
+
+    1. **An external hostname**
+
+        Enter a **Target Hostname**.
+
+    1. **Alias of another DNS record's value**
+
+        Click **Add Target Record** and select another DNS record from the **Value** drop-down.
+
+    1. **One or more workloads**
+
+        Click **Add Target Workload** and select another workload from the **Value** drop-down.
+
+    1. **The set of pods which match a selector**
+
+        Enter key value pairs of [label selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) to create a record for all pods that match your parameters.
+
+1. Click **Create**
+
+**Result:** A new DNS record is created.
+
+- You can view the record by from the project's **Service Discovery** tab.
+- When you visit the new DNS name for the new record that you created (`<recordname>.<namespace>.svc.cluster.local`), it resolves the chosen namespace.

content/rancher/v2.x/en/tasks/workloads/add-a-sidecar/_index.md

@@ -3,4 +3,28 @@ title: Adding a Sidecar
 weight: 
 draft: true
 ---
-Coming Soon
+A _sidecar_ is a container that extends or enhances the main container in a pod. You can add sidecars to existing workloads by using the **Add a Sidecar** option.
+
+1. From the **Global** view, open the project running the workload you want to add a sidecar to.
+
+1. Select the **Workloads** tab.
+
+1. Find the workload that you want to extend. Select **Ellipsis icon (...) > Add a Sidecar**.
+
+1. Enter a **Name** for the sidecar.
+
+1. Select a **Sidecar Type**. This option determines if the sidecar container is deployed before or after the main container is deployed.
+
+    - **Standard Container:**
+        
+        The sidecar container is deployed after the main container.
+
+    - **Init Container:**
+        
+        The sidecar container is deployed before the mainer container.
+
+1. Set the remaining options. You can read about them in [Deploying Workloads](../deploy-workloads).
+
+1. Click **Launch**.
+
+**Result:** The sidecar is deployed according to your parameters. Following its deployment, you can view the sidecar by selecting **Ellipsis icon (...) > Edit** for the main deployment.

content/rancher/v2.x/en/tasks/workloads/add-ingress/_index.md

@@ -3,4 +3,75 @@ title: Adding Ingress
 weight: 
 draft: true
 ---
-Coming Soon
+
+Ingress can be added for workloads to provide load balancing, SSL termination and host/path based routing.
+
+1. From the **Global** view, open the project that you want to add ingress to.
+
+1. Select the **Load Balancing** tab. Then click **Add Ingress**.
+
+1. Enter a **Name** for the ingress.
+
+1. Select an existing **Namespace** from the drop-down list. Alternatively, you can create a new namespace on the fly by clicking **Add to a new namespace**.
+
+1. Create ingress forwarding **Rules**.
+
+    - **Automatically generate a xip.io hostname**
+    
+        If you choose this option, ingress routes requests to hostname to a DNS name that's automatically generated. Rancher uses [xip.io](http://xip.io/) to automatically generates the DNS name. This option is best used for testing, _not_ production environments.
+        
+        1. Add a **Target Backend**. Click either **Service** or **Workload** to add the target.
+        
+        1. **Optional:** If you want specify a service or workload when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field.
+
+            Typically, the first rule that you create does not include a path.
+
+        1. Select a service or workload from the **Target** drop-down list.
+
+        1. Enter the **Port** that the service or workload operates on.
+
+        1. If you want to add additional **Target Backends**, repeat these substeps.
+
+    - **Specify a hostname to use**
+    
+        If you use this option, ingress routes requests for a hostname to the service or workload that you specify.
+
+        1. Enter the hostname that your ingress will handle request forwarding for. For example, `www.mysite.com`.
+        
+        1. Add a **Target Backend**. Click either **Service** or **Workload** to add the target.
+
+        1. **Optional:** If you want specify a service or workload when a request is sent to a particular hostname path, add a **Path** for the target. For example, if you want requests for `www.mysite.com/contact-us` to be sent to a different service than `www.mysite.com`, enter `/contact-us` in the **Path** field.
+
+           Typically, the first rule that you create does not include a path.
+        
+        1. Select a service or workload from the **Target** drop-down list.
+
+        1. Enter the **Port** that the service or workload operates on.
+        
+        1. If you want to add additional **Target Backends**, repeat these substeps.
+
+    - **Use as the default backend**
+        
+        Use this option to set an ingress rule for handling requests that don't match any other ingress rules. For example, use this option to route requests that can't be found to a `404` page.
+        
+        1. Add a **Target Backend**. Click either **Service** or **Workload** to add the target.
+        
+        1. Select a service or workload from the **Target** drop-down list.
+
+1. **Optional:** click **Add Rule** to create additional ingress rules. For example, after you create ingress rules to direct requests for your hostname, you'll likely want to create a default backend to handle 404s.
+
+1. If any of your ingress rules handle requests for encrypted ports, add a certificate to encrpyt/decrypt communications.
+
+    >**Note:** You must have an SSL certificate that the ingress can use to encrypt/decrypt communications. For more information see [Adding SSL Certificates](../../projects/add-ssl-certificates/).
+
+    1. Click **Add Certificate**.
+
+    1. Select a **Certificate** from the drop-down list.
+
+    1. Enter the **Host** using encrypted communication.
+
+    1. To add additional hosts that use the certitificate, click **Add Hosts**.
+
+1. **Optional:** Add [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) and/or [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to provide metadata for your ingress.
+
+**Result:** Your ingress is added to the project. The ingress begins enforcing your ingress rules.