mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Merge pull request #409 from MBishop17/sangeethah-wokload_ingress_dns_sidecar
Review of Ingress/DNS Records/Sidecars
This commit is contained in:
Denise
@@ -12,7 +12,8 @@ For help installing NGINX, refer to their [install documentation](https://www.ng
|
||||
|
||||
After installing NGINX, you need to create the NGINX config file, `/etc/nginx/conf.d/rancher.conf`, with the IP addresses for your Linux nodes, chosen FQDN and location of the certificate file and certificate key file.
|
||||
|
||||
>**Note:** The example configuration below does not include all available Nginx options and may not be suitable for your production environment. For full configuration documentation, see [NGINX Load Balancing - HTTP Load Balancer](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
||||
>**Note:** The configuration example in this procedure includes the minimum configurations needed to use
|
||||
to use Nginx as a Layer 7 load balancer with Rancher. For full documentation on all Nginx Layer 7 configuration options available, see the [Nginx HTTP Load Balancer Documentation](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
|
||||
|
||||
1. Copy and paste the code sample below into your favorite text editor. Save it as `/etc/nginx/conf.d/rancher.conf`.
|
||||
|
||||
@@ -61,6 +62,8 @@ After installing NGINX, you need to create the NGINX config file, `/etc/nginx/co
|
||||
4. In `/etc/nginx/conf.d/rancher.conf`, replace `/certs/fullchain.pem` with the path to your certificate. If there are intermediates required for you certificate, they should be included in this file.
|
||||
5. In `/etc/nginx/conf.d/rancher.conf`, replace `/certs/privkey.pem` with the path to your certificate key.
|
||||
|
||||
|
||||
|
||||
## Run NGINX
|
||||
|
||||
* Reload or restart NGINX
|
||||
|
||||
@@ -1,6 +1,45 @@
|
||||
---
|
||||
title: Adding a DNS Record
|
||||
weight:
|
||||
draft: true
|
||||
weight: 75
|
||||
---
|
||||
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 that you want to add a DNS record to.
|
||||
|
||||
1. Select the **Service Discovery** tab. Then click **Add Record**.
|
||||
|
||||
1. Enter a **Name** for the DNS record. This name is used for DNS resolution.
|
||||
|
||||
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.
|
||||
@@ -1,6 +1,35 @@
|
||||
---
|
||||
title: Adding a Sidecar
|
||||
weight:
|
||||
draft: true
|
||||
weight: 200
|
||||
---
|
||||
Coming Soon
|
||||
A _sidecar_ is a container that extends or enhances the main container in a pod. The main container and the sidecar share a pod, and therefore share the same network space and storage. 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 main container.
|
||||
|
||||
1. From the **Docker Image** field, enter the name of the Docker image that you want to deploy in support of the main container. During deployment, Rancher pulls this image from [Docker Hub](https://hub.docker.com/explore/). Enter the name exactly as it appears on Docker Hub.
|
||||
|
||||
1. 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.
|
||||
|
||||
## Related Links
|
||||
|
||||
- [The Distributed System ToolKit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/)
|
||||
|
||||
@@ -1,6 +1,79 @@
|
||||
---
|
||||
title: Adding Ingress
|
||||
weight:
|
||||
draft: true
|
||||
weight: 50
|
||||
---
|
||||
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.
|
||||
|
||||
>**Note:** To use this option, you must be able to resolve to `xip.io` addresses.
|
||||
|
||||
1. Add a **Target Backend**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**.
|
||||
|
||||
1. **Optional:** If you want specify a workload or service 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 workload or service from the **Target** drop-down list for each target you've added.
|
||||
|
||||
1. Enter the **Port** number that each target operates on.
|
||||
|
||||
- **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**. By default, a workload is added to the ingress, but you can add more targets by clicking either **Service** or **Workload**.
|
||||
|
||||
1. **Optional:** If you want specify a workload or service 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 workload or service from the **Target** drop-down list for each target you've added.
|
||||
|
||||
1. Enter the **Port** number that each target operates on.
|
||||
|
||||
|
||||
- **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.
|
||||
|
||||
>**Note:** If you deployed Rancher using RKE, a default backend for 404s and 202s is already configured.
|
||||
|
||||
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.
|
||||
|
||||
For a list of annotations available for use, see the [Nginx Ingress Controller Documentation](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/).
|
||||
|
||||
**Result:** Your ingress is added to the project. The ingress begins enforcing your ingress rules.
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
title: Adding a Persistent Volume Claim
|
||||
weight:
|
||||
draft: true
|
||||
weight: 100
|
||||
---
|
||||
|
||||
_Persistent Volume Claims_ (or PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. When you create a deployment, you should usually attach a PVC so that your application can lay claim to persistent storage. This claim lets your deployment application store its data in an external location, so that if one of the application's containers fails, it can be replaced with a new container and continue accessing its data stored externally, as though an outage never occured.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Deploying Workloads
|
||||
weight:
|
||||
weight: 25
|
||||
---
|
||||
|
||||
Deploy a workload to run an application in one or more containers.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Rolling Back Workloads
|
||||
weight:
|
||||
weight: 150
|
||||
---
|
||||
|
||||
Sometimes there is a need to rollback to the previous version of the application, either for debugging purposes or because an upgrade did not go as planned.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Upgrading Workloads
|
||||
weight:
|
||||
weight: 125
|
||||
---
|
||||
When a new version of an application image is released on Docker Hub, you can upgrade any workloads running a previous version of the application to the new one.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user