DEV Community

Prabhu Chinnasamy
Prabhu Chinnasamy

Posted on

14 14 14 13 13

Enhancing Kubernetes Traffic Routing with an Additional Istio Ingress Gateway

1. Introduction

Istio is a powerful service mesh that provides advanced traffic management, security, and observability for Kubernetes workloads. By default, Istio deploys a single Ingress Gateway to handle external traffic. However, in certain scenarios—such as traffic segmentation, multi-tenancy, or improved performance—you might need an additional Ingress Gateway to route traffic more efficiently.

This blog explores why and how to set up an additional Istio Ingress Gateway, backed by hands-on steps, best practices, and key configurations.

Why Use an Additional Ingress Gateway?

Using an additional Istio Ingress Gateway provides several advantages:

  • Traffic Isolation: Route traffic based on workload-specific needs (e.g., API traffic vs. UI traffic or transactional vs. non-transactional applications).
  • Multi-Tenancy: Different teams can have their own gateway while still using a shared service mesh.
  • Scalability: Distribute traffic across multiple gateways to handle higher loads efficiently.
  • Security & Compliance: Apply different security policies to specific gateway instances.
  • Flexibility: You can create any number of additional ingress gateways based on project or application needs.
  • Best Practices: Kubernetes teams often use HorizontalPodAutoscaler (HPA), PodDisruptionBudget (PDB), Services, Gateways, and Region-Based Filtering (via Envoy Filters) to enhance reliability and performance.

2. Understanding Istio Architecture

Istio IngressGateway & Sidecar Proxy: Ensuring Secure Traffic Flow

In an Istio service mesh, every pod requires an Istio-Proxy (Envoy) sidecar to handle traffic.

  • Without a sidecar proxy, applications cannot communicate internally or with external sources.
  • The Istio IngressGateway manages external traffic entry, but relies on sidecar proxies for enforcing security and routing policies.
  • This enables zero-trust networking, observability, and resilience across microservices.

How Traffic Flows Through a Sidecar Proxy

  • All traffic—whether from an external client or between services—passes through Envoy sidecars.
  • Sidecars enable traffic control, load balancing, security enforcement, and monitoring.
  • This architecture ensures secure, observable, and policy-driven communication between services.

Key Components of Istio Architecture

  • Ingress Gateway: Handles external traffic, routing requests based on policies.
  • Sidecar Proxy: Ensures all service-to-service communication follows Istio-managed rules.
  • Control Plane: Manages traffic control, security policies, and service discovery.

By leveraging these components, organizations can configure multiple Istio Ingress Gateways to enhance traffic segmentation, security, and performance across multi-cloud environments.

The following diagram illustrates how Istio Gateway Resource, Primary and additional Ingress Gateway, Service Mesh, and Control Plane interact to manage Kubernetes traffic.

Istio Gateway Resource, Primary and additional Ingress Gateway, Service Mesh, and Control Plane interact to manage Kubernetes traffic

The diagram demonstrates how:

  • Traffic from external clients is routed through a Cloud Load Balancer to the Istio Gateway Resource.
  • The Ingress Gateways processes Traffic and forwards it to the appropriate Service Mesh components.
  • The Istio Control Plane manages traffic policies, security enforcement, and service discovery across the mesh.

3. Traffic Flow in Istio Single OR Multiple Ingressgateways

Once multiple ingress gateways are deployed, traffic flows through different gateways depending on the application type (UI, API, or transactional services). The flow is as follows:

  1. Requests from external clients reach Cloud Load Balancer first then Load Balancer forwards traffic to the Istio Gateway, which then routes it to the correct Ingress Gateway.
  2. The Virtual Service defines which backend service should handle the request.
  3. The Envoy proxy (sidecar) ensures traffic follows defined policies.
  4. Traffic reaches the correct backend service.

4. Comparison: Single vs. Multiple Ingress Gateways

In a single ingress gateway setup, all traffic is routed through a single gateway, which can create bottlenecks and security challenges. On the other hand, multiple ingress gateways allow Better traffic segmentation for APIs, UI, and transaction-based workloads, Improved security enforcement by isolating sensitive traffic, Scalability & high availability, ensuring each type of request is handled optimally.

The following diagram compares a Single Istio Ingress Gateway with Multiple Ingress Gateways for handling API and Web traffic.

Single Istio Ingress Gateway with Multiple Ingress Gateways comparison

Key takeaways from the comparison:

  • A Single Istio Ingress Gateway routes all traffic through a single entry point, which may become a bottleneck.
  • Multiple Ingress Gateways allow better traffic segmentation, handling API traffic and UI traffic separately.
  • Security policies and scaling strategies can be defined per gateway, making it ideal for multi-cloud or multi-region deployments.

Key takeaways of comparing single and multiple ingress gateways

5. Setting Up an Additional Ingress Gateway

How Additional Ingress Gateways Improve Traffic Routing

The diagram below illustrates how multiple Istio Ingress Gateways efficiently manage API, UI, and transactional traffic

multiple Istio Ingress Gateways efficiently manage API, UI, and transactional traffic

How it Works

Cloud Load Balancer forwards traffic to the Istio Gateway Resource, which determines routing rules

Traffic is directed to different Ingress Gateways

The Primary Ingress Gateway handles UI traffic

The API Ingress Gateway handles API requests

The Transactional Ingress Gateway ensures financial transactions and payments are processed securely

The Service Mesh enforces security, traffic policies, and observability

Step 1: Install Istio and Configure Operator

Prerequisites

  • Kubernetes cluster with Istio installed
  • Helm installed for deploying Istio components

Ensure you have Istio installed. If not, install it using the following commands:

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=$(istio_version) TARGET_ARCH=x86_64 sh -

export PATH="$HOME/istio-$ISTIO_VERSION/bin:$PATH"

Initialize the Istio Operator:

istioctl operator init

Verify the installation:

kubectl get crd | grep istio

Alternative Installation Using Helm

Istio ingress gateway configurations can be managed using Helm charts for better flexibility and reusability. This allows teams to define customizable values.yaml files and deploy gateways dynamically.

helm upgrade --install istio-ingress istio/gateway -f values.yaml

This allows dynamic configuration management, making it easier to manage multiple ingress gateways.

Step 2: Configure Additional Ingress Gateways with IstioOperator

Create an Istio Operator configuration file (additional-ingressgateway.yaml) to define new gateways as needed. Below is an example configuration to create multiple additional ingress gateways for different traffic types.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: additional-ingressgateways
  namespace: istio-system
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway-ui
      enabled: true
      k8s:
        service:
          type: LoadBalancer
    - name: istio-ingressgateway-api
      enabled: true
      k8s:
        service:
          type: LoadBalancer
Enter fullscreen mode Exit fullscreen mode

Step 3: Additional Configuration Examples for Helm

Below are sample configurations for key Kubernetes objects that enhance the ingress gateway setup:

Horizontal Pod Autoscaler (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ingressgateway-hpa
  namespace: istio-system
spec:
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: istio-ingressgateway
Enter fullscreen mode Exit fullscreen mode

Pod Disruption Budget (PDB)

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ingressgateway-pdb
  namespace: istio-system
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: istio-ingressgateway

Enter fullscreen mode Exit fullscreen mode

Region-Based Envoy Filter

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: region-header-filter
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
            subFilter:
              name: envoy.filters.http.router
      proxy:
        proxyVersion: ^1\.18.*
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.lua
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
          inlineCode: |
            function envoy_on_response(response_handle)
              response_handle:headers():add("X-Region", "us-eus");
            end
Enter fullscreen mode Exit fullscreen mode

Step 4: Deploy Additional Ingress Gateways

Apply the configuration using istioctl:
istioctl install -f additional-ingressgateway.yaml

Verify that the new ingress gateways are running:
kubectl get pods -n istio-system | grep ingressgateway

Step 5: Define Gateway Resources for Each Ingress

Each ingress gateway should have a corresponding Gateway resource. Below is an example of defining separate gateways for UI, API, transactional, and non-transactional traffic.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: my-ui-gateway
  namespace: default
spec:
  selector:
    istio: istio-ingressgateway-ui
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "ui.example.com"
Enter fullscreen mode Exit fullscreen mode

Repeat similar configurations for API, transactional, and non-transactional ingress gateways.

Step 6: Route Traffic Using Virtual Services

Once the gateways are configured, create Virtual Services to control traffic flow to respective services.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-api-service
  namespace: default
spec:
  hosts:
  - "api.example.com"
  gateways:
  - my-api-gateway
  http:
  - route:
    - destination:
        host: my-api
        port:
          number: 80
Enter fullscreen mode Exit fullscreen mode

Repeat similar configurations for UI, transactional, and non-transactional services.

6. Resilience & High Availability with Additional Ingress Gateways

Deploying additional IngressGateways enhances resilience and fault tolerance in a Kubernetes environment.

  • If the primary ingress gateway fails, additional ingress gateways can take over traffic seamlessly.
  • When performing rolling upgrades or Kubernetes version upgrades, separating ingress traffic reduces downtime risk.
  • In multi-region or multi-cloud Kubernetes clusters, additional ingress gateways allow better control of regional traffic and compliance with local regulations.

7. Best Practices & Lessons Learned

Many teams forget that Istio sidecars must be injected into every application pod to ensure service-to-service communication.

  • When deploying additional ingress gateways, consider implementing:
  • Horizontal Pod Autoscaler (HPA): Automatically scale ingress gateways based on CPU and memory usage.
  • Pod Disruption Budgets (PDB): Ensure high availability during node upgrades or failures.
  • Region-Based Filtering (Envoy Filter): Optimize traffic routing by dynamically setting request headers with the appropriate region.
  • Dedicated Services & Gateways: Separate logical entities for better security and traffic isolation.
  • Ensure automatic sidecar injection is enabled in your namespace: kubectl label namespace <your-namespace> istio-injection=enabled
  • Validate that all pods have sidecars using: kubectl get pods -n <your-namespace> -o wide
  • Without sidecars, services will not be able to communicate, leading to failed requests and broken traffic flow.
  • When upgrading additional ingress gateways, consider following:
  • Backup Before Upgrade:

kubectl get all -n istio-system -o yaml > istio-backup.yaml

  • Delete Old Istio Configurations (If Needed) - If you are upgrading or modifying Istio, delete outdated configurations:

kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector

kubectl get crd --all-namespaces | grep istio | awk '{print $1}' | xargs kubectl delete crd

  • Ensure updates to proxyVersion, deployment image, and service labels during upgrades to avoid compatibility issues.
  • Scaling Down Istio Operator: Before upgrading, scale down Istio Operator to avoid disruptions.

kubectl scale deployment -n istio-operator istio-operator --replicas=0

8. Monitoring & Observability with Grafana

With Istio's built-in monitoring, Grafana dashboards provide a way to segregate traffic flow by ingress type:

  • Monitor API, UI, transactional, and non-transactional traffic separately.
  • Quickly identify which traffic type is affected when an issue occurs in Production using Prometheus-based metrics
  • Istio Gateway metrics can be monitored in Grafana & Prometheus to track traffic patterns, latency, and errors.
  • It provides real-time metrics for troubleshooting and performance optimization.
  • Set up alerts for anomalies and high error rates.

9. Conclusion

Implementing multiple Istio Ingress Gateways significantly enhances traffic control, scalability, security, and observability in Kubernetes environments. By segmenting traffic into dedicated ingress gateways for UI, API, transactional, and non-transactional services, teams achieve greater isolation, load balancing, and policy enforcement.

This approach is particularly critical in multi-cloud Kubernetes environments, such as Azure AKS, Google GKE, Amazon EKS, Red Hat OpenShift, VMware Tanzu Kubernetes Grid, IBM Cloud Kubernetes Service, Oracle OKE, and self-managed Kubernetes clusters, where regional traffic routing, failover handling, and security compliance must be carefully managed.

By leveraging best practices, including:

  • Sidecar proxies for service-to-service security
  • HPA (HorizontalPodAutoscaler) for autoscaling
  • PDB (PodDisruptionBudget) for availability
  • Envoy filters for intelligent traffic routing
  • Helm-based deployments for dynamic configuration

organizations can build a highly resilient and efficient Kubernetes networking stack.

Additionally, monitoring dashboards like Grafana and Prometheus provide deep observability into ingress traffic patterns, latency trends, and failure points, allowing real-time tracking of traffic flow, quick root-cause analysis, and proactive issue resolution.

By following these principles, organizations can optimize their Istio-based service mesh architecture, ensuring high availability, enhanced security posture, and seamless performance across distributed cloud environments.

References

  1. Istio Architecture Overview
  2. Istio Ingress Gateway vs. Kubernetes Ingress
  3. Istio Install Guide (Using Helm or Istioctl)
  4. Istio Operator & Profiles for Custom Deployments
  5. Best Practices for Istio Sidecar Injection
  6. Istio Traffic Management: VirtualServices, Gateways & DestinationRules
  7. Monitoring Istio with Prometheus & Grafana
  8. Prometheus Integration with Istio for Real-time Traffic Observability
  9. Istio Upgrade & Versioning Considerations
  10. Istio Security Best Practices: Authentication, Authorization & TLS
  11. Autoscaling Istio Ingress Gateway Using HPA

Originally published at https://dzone.com.

Image of Timescale

Timescale – the developer's data platform for modern apps, built on PostgreSQL

Timescale Cloud is PostgreSQL optimized for speed, scale, and performance. Over 3 million IoT, AI, crypto, and dev tool apps are powered by Timescale. Try it free today! No credit card required.

Try free

Top comments (14)

Collapse
 
zajayy_c5894f7d7ada profile image
Zajay Yura

Implementing multiple ingress gateways indeed enhances scalability and control.

Collapse
 
kajay_e966b00c0e5e4 profile image
Kajay Dera

Excellent breakdown of traffic segmentation using multiple ingress gateways.

Collapse
 
bojaytrra_41fd7ba44 profile image
Bojay Trra

The comparison between single and multiple gateways is particularly insightful.

Collapse
 
sojays_6704b9d719a6 profile image
Sojay Scra

Your architecture diagrams effectively illustrate the benefits of traffic isolation.

Collapse
 
benjamin_moore_5b9987cfa0 profile image
Benjamin Moore

The use of Envoy sidecars for secure traffic flow is well-explained.

Collapse
 
nathan_tarbert profile image
Nathan Tarbert

growth like this is always nice to see. kinda makes me wonder - what keeps stuff going long-term? like, beyond just the early hype?

Collapse
 
amjayj_38060f8b551f profile image
Amjay Jara

The discussion on applying different security policies per gateway is crucial for compliance.

Collapse
 
hajay_3e0584c8bc6d4 profile image
Hajay Kora

The section on key components of Istio architecture is very informative.

Collapse
 
kwame_mensah_031f40132829 profile image
Kwame Mensah

Implementing zero-trust networking with sidecar proxies is well-articulated.

Collapse
 
henry_taylor_218588ddde67 profile image
Henry Taylor

Great job highlighting the importance of traffic segmentation for performance scalability.

Redis image

Short-term memory for faster
AI agents

AI agents struggle with latency and context switching. Redis fixes it with a fast, in-memory layer for short-term context—plus native support for vectors and semi-structured data to keep real-time workflows on track.

Start building

👋 Kindness is contagious

Explore this insightful piece, celebrated by the caring DEV Community. Programmers from all walks of life are invited to contribute and expand our shared wisdom.

A simple "thank you" can make someone’s day—leave your kudos in the comments below!

On DEV, spreading knowledge paves the way and fortifies our camaraderie. Found this helpful? A brief note of appreciation to the author truly matters.

Let’s Go!