Marty Hernandez Avedon
6ccd0b7b6c
* Syncing sidebar labels with page titles Deploying Rancher Server: Update sidebar label to match title * Installing/Upgrading Rancher: Update title to match sidebar This is a reference/hub page for install guides with no step-by-step instructions, so we're breaking the -ing rule to match other reference pages as well as the current sidebar label * Cluster Access: Update title to match sidebar * Kubernetes Persistent Storage: Volumes and Storage Classes - Update title to match sidebar * Don't have a Kubernetes cluster? Try one of these tutorials: Update title to match sidebar and make old title intro to page * Don't have infrastructure for your Kubernetes cluster? Try one of these tutorials: Update title to match sidebar and make old title intro to page * versioning Deploying Rancher Server update to other sidebars * Setting Up Kubernetes Clusters in Rancher: Update sidebars to match title and other sidebar labels * capitalization * Creating a vSphere Cluster: Update sidebar to match title and other labels * Creating a Nutanix AOS Cluster: Update sidebar to match title and other labels * Kubernetes Clusters in Rancher Setup across the board for title and sidebar, to match convention in sidebar * Kubernetes Resources: Updated title to match sidebar and distinguish from identically-titled page in troubleshooting section * The Horizontal Pod Autoscaler: Updated title to match sidebar * Backups and Disaster Recovery: Update title to match sidebar * typo fix * revert to Installation and Upgrade of Rancher fix typo in title: Create Kubernetes Persistent files * fix typo in Persistent Storage files * Configuration: Update title to match sidebar item Monitoring V2 Configuration Guides * Setup Guide: Make both sidebar + title Istio Setup guides to match other sidebar labels * Best Practices: Update both to Best Practice Guides * Architecture: Update to match sidebar Rancher Architecture. Note that there are multiple pages with identical titles, one is on Fleet and another on some other subject * Architecture: Retitle logging-architecture.md files Logging Architecture * Architecture: Retitle fleet/architecture.md files Fleet Architecture * GKE Cluster Configuration: Update sidebar to match title and other labels in same section * Security: Update both to Rancher Security Guides * RKE Hardening Guide: Update to match sidebar * typo * RKE2 Hardening Guide: Update to match sidebar * K3s Hardening Guide: Update to match sidebar * various FAQ pages: Add FAQ to title to disambiguate content * Cloud Native Storage with Longhorn: Versioning so older pages match current title * rm international pages for now * typo in metadata killed build * updated sidebar: plural Istio Setup Guides * updating Monitoring Config Guides title/label and distinguishing from similar section under References * monitoring V2 config examples: rm 'V2' * Kubernetes Cluster Setup > Setting up a Kubernetes Cluster for Rancher Server
4.6 KiB
title, description
| title | description |
|---|---|
| Load Balancer and Ingress Controller Setup within Rancher | Learn how you can set up load balancers and ingress controllers to redirect service requests within Rancher, and learn about the limitations of load balancers |
Within Rancher, you can set up load balancers and ingress controllers to redirect service requests.
Load Balancers
After you launch an application, the app is only available within the cluster. It can't be reached from outside the cluster.
If you want your applications to be externally accessible, you must add a load balancer or ingress to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number.
Rancher supports two types of load balancers:
For more information, see load balancers.
Load Balancer Limitations
Load Balancers have a couple of limitations you should be aware of:
-
Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive.
-
If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), the load balancer must be running within that cloud provider's infrastructure. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters:
Ingress
As mentioned in the limitations above, the disadvantages of using a load balancer are:
- Load Balancers can only handle one IP address per service.
- If you run multiple services in your cluster, you must have a load balancer for each service.
- It can be expensive to have a load balancer for every service.
In contrast, when an ingress is used as the entrypoint into a cluster, the ingress can route traffic to multiple services with greater flexibility. It can map multiple HTTP requests to services without individual IP addresses for each service.
Therefore, it is useful to have an ingress if you want multiple services to be exposed with the same IP address, the same Layer 7 protocol, or the same privileged node-ports: 80 and 443.
Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster direct the request to the correct service based on service subdomains or path rules that you've configured.
Each Kubernetes Ingress resource corresponds roughly to a file in /etc/nginx/sites-available/ containing a server{} configuration block, where requests for specific files and folders are configured.
Your ingress, which creates a port of entry to your cluster similar to a load balancer, can reside within your cluster or externally. Ingress and ingress controllers residing in RKE-launched clusters are powered by Nginx.
Ingress can provide other functionality as well, such as SSL termination, name-based virtual hosting, and more.
:::note Using Rancher in a High Availability Configuration?
Refrain from adding an Ingress to the local cluster. The Nginx Ingress Controller that Rancher uses acts as a global entry point for all clusters managed by Rancher, including the local cluster. Therefore, when users try to access an application, your Rancher connection may drop due to the Nginx configuration being reloaded. We recommend working around this issue by deploying applications only in clusters that you launch using Rancher.
:::
- For more information on how to set up ingress in Rancher, see Ingress.
- For complete information about ingress and ingress controllers, see the Kubernetes Ingress Documentation
- When using ingresses in a project, you can program the ingress hostname to an external DNS by setting up a Global DNS entry.