Continental Innovates with Rancher and Kubernetes
This how-to guide describes how to set up a Network Load Balancer (NLB) in Amazon’s EC2 service that will direct traffic to multiple instances on EC2.
These examples show the load balancer being configured to direct traffic to three Rancher server nodes. If Rancher is installed on an RKE Kubernetes cluster, three nodes are required. If Rancher is installed on a K3s Kubernetes cluster, only two nodes are required.
This tutorial is about one possible way to set up your load balancer, not the only way. Other types of load balancers, such as a Classic Load Balancer or Application Load Balancer, could also direct traffic to the Rancher server nodes.
Rancher only supports using the Amazon NLB when terminating traffic in tcp mode for port 443 rather than tls mode. This is due to the fact that the NLB does not inject the correct headers into requests when terminated at the NLB. This means that if you want to use certificates managed by the Amazon Certificate Manager (ACM), you should use an ALB.
tcp
tls
Configuring an Amazon NLB is a multistage process:
These instructions assume you have already created Linux instances in EC2. The load balancer will direct traffic to these nodes.
Begin by creating two target groups for the TCP protocol, one with TCP port 443 and one regarding TCP port 80 (providing redirect to TCP port 443). You’ll add your Linux nodes to these groups.
Your first NLB configuration step is to create two target groups. Technically, only port 443 is needed to access Rancher, but it’s convenient to add a listener for port 80, because traffic to port 80 will be automatically redirected to port 443.
Regardless of whether an NGINX Ingress or Traefik Ingress controller is used, the Ingress should redirect traffic from port 80 to port 443.
Note: Health checks are handled differently based on the Ingress. For details, refer to this section.
Configure the first target group according to the table below.
rancher-tcp-443
instance
TCP
443
Health check settings:
override
80
3
6 seconds
10 seconds
Click Create target group to create the second target group, regarding TCP port 80.
Configure the second target group according to the table below.
rancher-tcp-80
traffic port
Next, add your Linux nodes to both target groups.
Select the target group named rancher-tcp-443, click the tab Targets and choose Edit.
Select the instances (Linux nodes) you want to add, and click Add to registered.
Screenshot Add targets to target group TCP port 443
Screenshot Added targets to target group TCP port 443
When the instances are added, click Save on the bottom right of the screen.
Repeat those steps, replacing rancher-tcp-443 with rancher-tcp-80. The same instances need to be added as targets to this target group.
Use Amazon’s Wizard to create a Network Load Balancer. As part of this process, you’ll add the target groups you created in 1. Create Target Groups.
From your web browser, navigate to the Amazon EC2 Console.
From the navigation pane, choose LOAD BALANCING > Load Balancers.
Click Create Load Balancer.
Choose Network Load Balancer and click Create. Then complete each form.
Set the following fields in the form:
rancher
internal
internet-facing
Since you registered your targets earlier, all you have to do is click Next: Review.
Look over the load balancer details and click Create when you’re satisfied.
After AWS creates the NLB, click Close.
Select your newly created NLB and select the Listeners tab.
Click Add listener.
Use TCP:80 as Protocol : Port
Click Add action and choose Forward to…
From the Forward to drop-down, choose rancher-tcp-80.
Click Save in the top right of the screen.
K3s and RKE Kubernetes clusters handle health checks differently because they use different Ingresses by default.
For RKE Kubernetes clusters, NGINX Ingress is used by default, whereas for K3s Kubernetes clusters, Traefik is the default Ingress.
/ping
/healthz
ingress-nginx
To simulate an accurate health check, it is a best practice to use the Host header (Rancher hostname) combined with /ping or /healthz (for K3s or for RKE clusters, respectively) wherever possible, to get a response from the Rancher Pods, not the Ingress.