The basics of Kubernetes ingress is that it exposes HTTP and HTTPS routes from the outside of a cluster to services created inside the cluster. Ingress essentially works to implement rules to control traffic routes. Typically, ingress is set up to provide services to externally reachable URLs, load balance traffic, offer name-based virtual hosting and terminal secure sockets layers or transport layer security. It’s also important to note that ingress doesn’t expose all ports, only HTTP and HTTPS. 

We’re to tackle the big questions around Kubernetes ingress. From what it is, what types there are and what are the rules, you’ll have a better understanding of ingress. 

What Is An Ingress Resource?

Since ingress is a resource that uses a collection of rules and configurations for routing external HTTPs traffic to internal servers, an ingress resource acts as a method of using apiVersion, kind and metadata to function properly. Through this, you’re able to use an annotation to configure the ingress controller. Inside the spec section, you’ll find the load balancer or the proxy server.

What Are The Types Of Ingress?

There are three types of ingress.

  1. Single Service:
    Single Service works to reveal another single service. NodePort would be a good example of a single service ingress.
  2. Simple Fanout:
    A simple fanout routes traffic from a single IP address to many services based on URI.
  3. Name-Based Virtual Hosting:
    The final type of ingress works to route traffic to many hostnames on the same IP.

What Are The Rules?

A prerequisite for Kubernetes Ingress resource to work is that the cluster must have a ingress controller running. Ingress has a set of rules that are used to help process incoming traffic to the services in the cluster. Firstly, before anything else, you need to specify how this rule applies. You’re able to use HTTP/HTTPS or host-based rules. Secondly, then you must define the path and the backend service port that you’re looking to route to. It’s important to note that both the host and the path have to match the request before the load balancer will direct traffic to the referenced service. If you decide against defining a rule you risk having all your traffic brought to default back end that is specified in the ingress controller. Safe to say, that is not an ideal situation. 

What About Security?

No explanation of Kubernetes ingress is complete without discussing transport layer security, or TLS. It’s easy to secure an ingress. You need to begin by specifying a secret with a private key and certificate. Then review load balance, an ingress controller should have some load balancing policies applied to it. Two of the most common are the load balancing algorithm and the backend weight scheme. If you want your ingress resources to work securely you need to ensure that your ingress controller is running. Unlike the typical Kubernetes controllers, the ingress controller is separate from the cluster and must be deployed on its own. 

Thinking about maximizing your cloud infrastructure with Kubernetes? We are Certified Kubernetes and are ready to help you through everything from deployment, management and beyond. Curious to learn more

Would you like to know more about Zuul? So download our white paper and get reading!

How to up your DevOps game with Project Gating

How to Up Your DevOps Game with Project Gating:
Zuul – A CI/CD Gating Tool

Download White Paper