Kubernetes Ingress

Updated April 13, 2023

Introduction to Kubernetes Ingress

Kubernetes clusters or pods in the cluster are connected to each other internally. But if you want to use the services like HTTP to be exposed to outside work you need a tool to do it efficiently w.r.t. pods. There are NodePorts, LoadBanalncers available to achieve the same but Kubernetes Ingress is such an API object in Kubernetes environment, which can control the HTTP and https inbound traffic from external sources to the services.

This is achieved by Ingress Resource which defines how you want requests routed to the backing services and Ingress Controllers, responsible for reading the Ingress Resource information and processing that data accordingly.

What is Kubernetes Ingress?

Kubernetes Ingress is used when you want to expose your services, which are running in Kubernetes Cluster, to external networks which can be internet or anything outside your Kubernetes cluster.

This is mainly used for exposing HTTP and https routes, to give externally reachable URLs, load balance traffic with help of load balancer, terminate SSL and TLS or offer name-based virtual hosting. Ingress has resources or rules and controller which is responsible for implementing the resource rules. External Users request ingress by using the Ingress resource to the API server i.e. Ingress Controller. Below Picture might help you understand it a bit more: –

To deploy an Ingress, use “kubectl create -f <filename>” command with a YAML file having the definition, paths, rules, and other mandatory fields. The Ingress controller will create an implementation-specific Internal LB (loadbalancer) that goes with the Ingress until the services in concern exist. You can see the address of the loadbalancer under the last column of the output, when you run the “kubectl get ing” command.

Types of Kubernetes Ingress

Below are the types mentioned:

1. Single Service Ingress

You can create an Ingress by specifying a default backend with no rules inside spec in file Ingress_sample.yaml, like below:

Apply it with below command:

There will be an IP assigned by Ingress Controller to the Ingress setup. Sometimes it takes some time to allocate the IP and till then you will see the Address as Pending in output of below command: –

2. Simple fanout 

Pods within Kubernetes have IPs only visible on the cluster network, so we need a loadbalancer to accept ingress traffic and sending it to designate endpoints. But Ingress lets you work with a single LB (LoadBalancers). For example, a setup like: –

Code:

webserver.example.com -> 10.10.10.101 -> /dir1  serv1:80
webserver.example.com -> 10.10.10.101 -> /dir2  serv2:80

Output:

3. Name-based virtual hosting

Name-based virtual hosts use more than one hostnames for the same IP address as below: –

Code:

webserver.example.com -> 10.10.10.101 -> webserver.example.com serv1:80
appserver.example.com -> 10.10.10.101 -> appserver.example.com serv2:80

The below Ingress tells the backing LB (LoadBalancer) to route requests based on the host header

If in your resources file you don’t define the host field for a service, then any web traffic requesting to your Ingress controller will be forwarded without any name-based virtual host tagged to it. For example, in the following, Web traffic for webserver.example.com will be forwarded to serv1, appserver.example.com to serv2, and any web traffic to the IP address with no host field defined, will be sent to ser3.

4. TLS

Ingress can be made secure by adding: –

• Secret containing TLS private
• Certificate

With current versions, Ingress only supports single TLS port 443 and consider TLS termination. Also, to note that TLS secret should have keys named as tls.crt and tls.key that contains the cert. and private key to use be used for TLS

When using this secret, the Ingress controller secures the communication from the client to the LB (LoadBalancer) using TLS. One point to make sure that the TLS secret from certificate contains CN or FQDN for your host like for ssltest.example.com in this example. The resource will look like below: –

5. Load Balancing

A Controller is attached with a load-balancing policy like load balancing algorithm etc. that it applies to all Ingress traffic. Advanced load balancing concepts like persistent sessions etc. are not yet available through the Ingress. But if you need these features then you can use a generic load balancer.

Updating Ingress

When you have an Ingress already deployed and you want to update it to add a new target service or Host target, you can do it by updating the resource file, use below steps: –

1. Check the current ingress details: –

#kubectl describe ingress <ingress_name>

2. Edit the ingress resource using the command, this will open YAML file in default editor: –

#kubectl edit ingress <ingress_name>

3. Once your changes are saved, kubectl updates the resources to API server, which then updates the Ingress controller to update the LB (load balancer). Verify this using below command:

#kubectl describe ingress <ingress_name>

#kubectl replace -f <Filename>

Prerequisites

To work with Kubernetes Ingress, you should have below available or you will not be able to use it at all or use it to the full extent.

• A running Kubernetes Controller, locally like HAProxy Ingress, ingress-nginx, etc. or on cloud-like AWS ALB Ingress Controller which enables Ingress using the AWS Application Load Balancer. But an Ingress Controllers should fit in your requirement specifications as different Ingress controllers operate slightly
• Kubernetes Resources means the rules which you must define as per your needs and based on the availability of NodePort or LoadBalancers. An example is below:

• Further Kubernetes Ingress needs apiVersion, kind, and metadata fields in the resource file. So you should know these. Along with these fields, if the host is defined, then rules will apply to that target, if no host is defined, then rules will be applied to all inbound HTTP (or HTTPS) traffic. Also, the field path (/var/mytestpath in above example) has a backend defined with a Service Name and Service Port. Both host and path fields should match the content of a request in web traffic, before the Load Balancer (if any present) forwards traffic to the concerned Service.
• A backend, which is a combination of serviceName and servicePort. HTTP (or HTTPS, in case) requests to the Ingress that matches the host field and the path field of the rule are sent to the backends mentioned in the resource. A default backend mostly configured in a controller to serve any requests that don’t match any path in

Conclusion

Ingress allows you to configure multiple Virtual Hosts, Sticky sessions, Path rewrites, and custom configurations, providing a powerful flexible routing mechanism for Kubernetes. When you have chosen an Ingress Controller and respecting Ingress resources check the respective Ingress documentation to get its understanding, capability and learn different ways to route requests.

Recommended Articles

We hope that this EDUCBA information on “Kubernetes Ingress” was beneficial to you. You can view EDUCBA’s recommended articles for more information.

1. Kubernetes Architecture
2. Kubernetes Operators
3. What is Kubernetes?
4. Kubernetes Namespace