Managing Ingress Controllers on Kubernetes: Part 1

What is an Ingress Controller

Photo by Chris Bair on Unsplash

Kubernetes isolates the services that are deployed on a cluster from the world outside of the cluster. It does this, in order to protect the services from unsolicited attention. More often than not, however, we need one or more of our deployed services, to be made available for consumption outside of the cluster. Kubernetes provides a number of mechanisms for achieving this, but perhaps the most flexible technique it provides, is that provided by Ingress.

Why not use a LoadBalancer type Service?

It may be tempting to deploy a LoadBalancer type Service, instead of using the Ingress API, where an external load balancer (e.g. AWS ELB) is automatically created and configured to route external traffic to the pods that represent the service. The problem with this approach, however, is that it provides a fairly limited solution, and that it creates an external load balancer for each and every Service of this type. The creation of numerous external, cloud-specific load balancers, can end up becoming an expensive proposition, in terms of cost, but also in terms of administrative overhead. By contrast, the Kubernetes Ingress API provides a lot of flexibility for configuring Ingress to a Kubernetes cluster, and ingress controllers can be deployed as a replicated service or services behind a single, external load balancer.

What makes using Ingress a Good Choice?

Ingress provides layer 7 HTTP routing, and enables you to use a single domain name to serve multiple services, load balance traffic across service replicas, terminate SSL, implement SSL passthrough, amongst other things.

In Kubernetes, the Ingress concept is implemented as a Kubernetes API resource, and an implementation-specific controller, called an Ingress controller. Let’s briefly touch on their function, before we take a look at some of the different Ingress controllers available in the ecosystem.

Getting Started: Creating an Ingress Resource

An Ingress resource is used to define the routing rules that determine how external clients access the services running in a Kubernetes cluster. These rules allow for routing based on the host and the path of the URL request.

The simple example below, shows a rule for Ingress traffic addressed to the host acme.com , where requests which match the path acme.com/foo are routed to the backend service named svc1 on port 80 , and those that match the path acme.com/bar are routed to service named svc2 on port 80 :

apiVersion: extensions/v1beta1 kind: Ingress metadata: name: acme-app-ingress spec: rules: - host: acme.com http: paths: - path: /foo backend: serviceName: svc1 servicePort: 80 - path: /bar backend: serviceName: svc2 servicePort: 80

Sample Ingress resource, you could save this to a file and apply it to you cluster using: kubectl apply -f ingress.yml

Written by Puja Abbassi — Developer Advocate @ Giant Swarm

Ready to get your cloud native project into production? Simply request your free trial at https://giantswarm.io/