This is the final post in a 4 part series. Here are links to the preceding in case you missed the previous posts:
1. Container to Container communications
2. Pod to Pod communications (CNI Plugin)
3. How we can track pods and provide external access (Kubernetes Service)
4. Rule based routing (Kubernetes Ingress)
Rule based routing
The final topic that we’ll cover in this series is rule based routing (HTTP hosts and paths) using the Kubernetes Ingress. An Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.
“Ingress can provide load balancing, SSL termination and name-based virtual hosting.”
https://kubernetes.io/docs/concepts/services-networking/ingress/
There are a number of ways to configure a Kubernetes Ingress and in this example we’ll use a fanout. A fanout configuration routes traffic from a single IP address to more than one service.
From the YAML file above we can see a set of rules defining two http paths, one to a Guestbook and one to a different application called the Sockshop.
Kubernetes Ingress Controller
Just like we learnt Kubernetes Services require an external loadbalancer, a Kubernetes Ingress itself does not provide the rule based routing. Instead it relies on an Ingress Controller to perform this function.
There are many ingress controller options available. In our lab we are using Cisco Container Platform which automatically deploys an Nginx Ingress Controller to each new Kubernetes tenant cluster.
https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
In the following screenshots you’ll see that we have an ingress controller, nginx-ingress-controller-xxxxx, running on each node. We also have a service of type LoadBalancer which will direct our incoming traffic into the Nginx controller.
Similar to how MetalLB worked for Kubernetes Services, the Nginx controller will look for any changes to the Kubernetes Ingress. When a new ingress is configured the Nginx configuration will be updated with the routing rules which have been configured in the ingress YAML file (see above for example YAML).
Each ingress controller also has options to provide annotations for custom configuration of the specific controller. For example here are the Nginx annotations you can use.
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
In this lab Nginx has noticed the new ingress defined and has created the routing rules and annotions as part of it’s configuration. We can confirm this by looking at the nginx.conf file on each nginx-ingress-controller-xxxxx pod.
Since the ingress controller is running in multiple pods we can use the Kubernetes Services outlined above to provide access. In our case we have a LoadBalancer type service configured to direct external traffic to one of the available Nginx controller pods.
From there the Nginx controller will redirect based on the path, either to the guestbook frontend service or the sockshop service. These will in turn forward the traffic onto an available pod managed by the respective service.
Why should I use an ingress?
Besides the routing rules that we’ve just described, a Kubernetes Ingress allows us to conserve IP addresses. When we use a service of type LoadBalancer we require an externally routable address for each service configured. Assigning these addresses on premises may not have a big impact however usually there is a cost associated to each IP address in a public cloud environment.
When using an ingress we can have a single external IP address assigned (for the ingress service), and each service behind the ingress can use a ClusterIP. In this scenario the services are only accesible through the ingress and therefore don’t require a public IP address.
As we’ve just alluded to the Kubernetes Ingress also provides a single ingress point to which we can define our routing rules and other configuration such as TLS termination.
Summary
Like any subject there’s always a lot more you can learn but hopefully by this stage you have a better understanding of Kubernetes networking at a high level. Here are the topics we’ve covered in this series:
1. Container to Container communications with shared folders and localhost
2. Pod to Pod communications using a CNI Plugin (Calico)
3. Tacking pods while providing internal and external access with the Kubernetes Service
4. Rule based routing and redirection to services using a Kubernetes Ingress
If you have any feedback, things I’ve missed, or any relevant topics you’d like more details on please feel free to post a comment.
Related resources:
- Learn network programmability basics
- Should you get a DevNet certification?
- Register to attend DevNet Create 2020
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
Hey Conor, this series is just awesome! LIKE 🙂
Great Work Conor!
(You make foggy stuff look simple ;-))
Pretty amazing man. Really! Very, very helpful!