Content-based routing using Kubernetes Ingress

Content-based routing using Kubernetes Ingress

Deeptiman Pattnaik's photo
Deeptiman Pattnaik
·Nov 6, 2020·

8 min read

Subscribe to my newsletter and never miss my upcoming articles

In this article, we will see the features Kubernetes Ingress provides for content-based routing and traffic control inside the cluster.

What is Kubernetes Ingress?

Kubernetes Ingress provides a rule-based workflow that will setup the routing API objects inside the cluster. The Ingress APIs will facilitate content-based routing for the services with the external endpoints using an HTTP(s) load balancer that connects with the public internet. In some cases, the internal routing technique inside a Virtual Private Cloud.

HTTP(s) Load Balancer

The exposed service requires an HTTP(s) Load Balancer to connect with external traffic in Google Kubernetes Engine and the user receives low latency HTTP(s) connection with the help of Google Points of Presence. So, the service is connected to various Google Load Balancers using the Anycast routing method that determines the low-cost path to reach any closest Load Balancer nodes in the network.

**Load Balancer**

It’s a technique that exposes the service to the public internet with a single IP address.

What is Anycast routing?

Anycast is a routing method that distributes the incoming request (a single IP address) into multiple routes based on regional, content-based, or any other priority methods. The prioritization of the routing node provides services within low latency bandwidth to the user. The shortest path algorithm of the Anycast network determines the closest or nearest nodes. In the real scenarios, the network request to reach any nearest CDN, data center to reduce traffic congestion in the high traffic volume applications.

Internal and External traffic control using Ingress

In Google Cloud, there are many different ways the HTTP(s) traffic is distributed in the network. The two different kinds of traffic requests will provide autoscaling, regional load balancing, integration of cache content delivery, and many other load balancing features.

Ingress for internal traffic Load Balancing

The internal HTTP(s) Load Balancer is only accessible to the selected region from the *Virtual Private Cloud(VPC)* network using an internal IP address.

Envoy Proxy as a Sidecar

The internal HTTP(s) Load Balancer uses Envoy Proxy to manage services in the cluster. The proxy service works as a *sidecar proxy* to provide service mesh to manage the internal traffic control in a region, VMs, or GKE nodes. The service instances are not connected to the external traffic but use the local proxy to communicate with another service within a zone. The Envoy proxy takes care of service discovery, load balancing, traffic control, circuit breaker, health check in a cluster.


It’s a supporting feature for the applications that are applied as a container, configuration element, logging, proxy services. The sidecar services work as an attachable and detachable component for an application lifecycle.

Path-based routing

The internal load balancer follows the *L7 routing method that allows forming certain URL types to define various paths to connect with the backend service using a single internal IP address. The [URL map]( creates path rules to direct the traffic to content-based routing backend services.


There is a BASE URL “mymediaservice.internal” that has two backend service “video”, “image”. So the path rule will decide to connect to multiple internal backend services or buckets using a single URL.

  1. https://mymediaservice.internal/video — connects to video backend service.
  2. https://mymediaservice.internal/image — connects to the image cloud storage backend bucket.

Internal Microservice ArchitectureInternal Microservice Architecture

The internal backend services are hosted inside multiple instance groups within the VMs that work as internal microservices for internal clients.

L7 Traffic Management

The L7 internal routing follows traffic management methods to route traffic intelligently and provides high-performance routing facilities in the production environment.

  • Traffic Steering (header-based routing)

The HTTP(s) request headers will direct the traffic to the destination service instance by setting user-agent.


If the user has a mobile device, then the request param with “user-agent: Mobile” in the header, and for other users “user-agent: Desktop”, so the traffic can redirect to the required service instance based on the user’s device usability. So the traffic steering mechanisms enable intelligent routing in regional, zonal routing applications.

Traffic Steering based on user device typeTraffic Steering based on user device type

  • Traffic Action (weight-based traffic splitting)

The traffic action is useful for managing the newer version of the service in the network. The migration of service with the “version-2” can be split into multiple sets of “95%” and “5%”. The first set of the traffic will be running the “version-1” of the service and other running the “version-2” of the service until the performance is stable, release ratio will slowly increase in the network. The traffic action highly performant in-service migration, A/B testing, and other release processes of the services in the production environment.

Updating Service by traffic splittingUpdating Service by traffic splitting

Ingress for external traffic Load Balancing

The Ingress for external traffic in Google Kubernetes Engine works as a global load balancer providing the HTTP(s) load balancer as Pod. The load balancer is globally distributed which exposes the applications to the public internet. The load balancer can be connected with multiple backend types to facilitate external traffic using IPv4 and IPv6 with path-based routing.

Multiple Backends

The external HTTP(s) load balancer enables the services to connect with public backend services such as Cloud CDNs, Content-based storage backend, Geography regional services, and similar backend services with a single IP address.

  1. Instance Group

There will be many collections of VMs running within a single cluster that forms an instance group. There are *Managed Instance and [Unmanaged Instance]( *that functions VMs differently in a Google Cloud Computing environment.

Managed Instance Groups (MIG)

Many types of stateless and stateful applications run in Pods, Services within a cluster. The performance scalability of these instances is possible by creating multiple identical VMs that will provide autoscaling, autohealing, regional deployment, and automatic updating.

Advantages of Managed Instance Groups

  • There are multiple replicas of VMs running as instance group that will provide seamless workflow in the cluster, so if any of the VM instances goes down another replica VM instance will resume the work.

  • The regional MIGs will distribute the app load across several zones as a replica VM in the network that will reduce the traffic load to a single instance of VM.

  • The autoscaling methods will enable the feature to increase the computation resource requirement for the application, so the MIGs can automatically grow the instance in the cluster as per the demand, the same applies to reduce the instances group if the demand drops.

  • The auto rollout of software updates into the instances are very flexible as the migration to a newer version can be controlled based on the stable testing across all the region.

  • The stateful workload will create unique identical replicas that will handle auto-healing, recreation, updates, and more for all kinds of stateful applications.

Unmanaged Instance Group

There will be manual efforts to optimize, scale, health check for the instances that are running inside the VMs. The UIG does not offer automatic processing like scaling, rollout, healing, or anything that will be managed automatically in the cluster.

2. Network Endpoint Groups (NEGs)

In general, the Network Endpoint Groups defines the collection of backend endpoints or services running within a container. There are a small set of backend instances can be created for each endpoint running under the VMs.

Zonal NEGs

  1. The Compute Engine VMs that runs endpoints must have a combination of IP:port.

  2. The *Zonal NEGs *run multiple set of containers that runs under a VM.

  3. There will be a range of *subnet IPs* for each container followed by the alias IP of the VM.

2 Zonal NEGs running 2 VMs2 Zonal NEGs running 2 VMs

Serverless NEGs

  1. Serverless NEGs is a backend service that can run from IPv4 and IPv6 addresses which are not shared with other services.

  2. There will be only one base URL that can be spread as an identical serverless application running across the different regions. So, the user can be beneficial to reach the closest *CDNs, data centers to access the service. So, the same URL can be used as a single HTTP(s) load balancer to send traffic to other Google Cloud Technologies such as [Cloud Run](, App Engine, Cloud Functions, Compute Engine, Google Kubernetes Engine, and [Cloud Storage](*.

Internet NEGs

The backend services reside outside the Google Cloud forms an *Internet NEGs *defines multiple backend endpoints of load balancers to connect to the public internet.

Static IP address for external HTTP(s) load balancers

  • In general, the ingress object creates an external IP address that the client can use to connect to the public internet but the same IP address will change to a new one if the Ingress service dies or recreated in the cluster.

  • We can assign a static IP address that remains permanently as an ingress annotation.

kind: Ingress
  name: cache-ingress


The HTTP(s) load balancers mostly work as a proxy that will either expose the service to the public internet or create an internal IP address to communicate with Virtual Private Cloud. The proxies work on the *HTTP(s) Forwarding Rule to send the request to the backend VM or external cloud services. The Google Kubernetes Engine provides [Ingress Controllers]( that will automate the configuration of sidecar proxies in the load balancers, path-based routing, SSL without manually handling them in the production environment.







So, this is the overview of traffic control and content-based routing using Kubernetes Ingress and the strong relationship with Google Cloud HTTP(s) Load Balancer.

I hope you find this article useful :)


Share this