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.
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:
- 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.
- The Virtual Service defines which backend service should handle the request.
- The Envoy proxy (sidecar) ensures traffic follows defined policies.
- 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.
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.
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
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
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
Pod Disruption Budget (PDB)
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: ingressgateway-pdb
namespace: istio-system
spec:
minAvailable: 1
selector:
matchLabels:
app: istio-ingressgateway
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
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"
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
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
- Istio Architecture Overview
- Istio Ingress Gateway vs. Kubernetes Ingress
- Istio Install Guide (Using Helm or Istioctl)
- Istio Operator & Profiles for Custom Deployments
- Best Practices for Istio Sidecar Injection
- Istio Traffic Management: VirtualServices, Gateways & DestinationRules
- Monitoring Istio with Prometheus & Grafana
- Prometheus Integration with Istio for Real-time Traffic Observability
- Istio Upgrade & Versioning Considerations
- Istio Security Best Practices: Authentication, Authorization & TLS
- Autoscaling Istio Ingress Gateway Using HPA
Originally published at https://dzone.com.
Top comments (14)
Implementing multiple ingress gateways indeed enhances scalability and control.
Excellent breakdown of traffic segmentation using multiple ingress gateways.
The comparison between single and multiple gateways is particularly insightful.
Your architecture diagrams effectively illustrate the benefits of traffic isolation.
The use of Envoy sidecars for secure traffic flow is well-explained.
growth like this is always nice to see. kinda makes me wonder - what keeps stuff going long-term? like, beyond just the early hype?
The discussion on applying different security policies per gateway is crucial for compliance.
The section on key components of Istio architecture is very informative.
Implementing zero-trust networking with sidecar proxies is well-articulated.
Great job highlighting the importance of traffic segmentation for performance scalability.