How to Expose Services in an Istio Mesh Using Nginx Ingress Controller

1. Overview

API gateway has long been the entry point for client‑to‑backend traffic (north‑south). Service mesh, such as Istio, manages internal (east‑west) traffic and also includes a gateway, which leads to confusion about the relationship between service mesh and API gateway, whether Istio replaces an API gateway, how Istio’s gateway works, and how to expose services inside an Istio mesh.

2. Main Points

The purpose of service mesh is to solve internal traffic management for distributed applications, while API gateways have existed for a long time.

Although Istio provides a built‑in Gateway, you can still use a custom Ingress Controller to proxy external traffic.

API gateways and service meshes are moving toward convergence.

3. Ways to Expose Services in an Istio Mesh

The diagram below shows four ways: Istio Gateway, Kubernetes Ingress, API Gateway, and NodePort/LoadBalancer.

The shaded area represents the Istio mesh (internal east‑west traffic). Client requests to the cluster are north‑south traffic. Because Ingress Controllers and Istio Gateways run as Pods inside the cluster, traffic between these Pods and other services can be considered internal.

Four exposure methods:

NodePort/LoadBalancer (Kubernetes) – basic load balancing.

Kubernetes Ingress (Ingress Controller) – load balancing, TLS, virtual hosts, traffic routing.

Istio Gateway (Istio) – load balancing, TLS, virtual hosts, advanced routing, other Istio features.

API Gateway (API Gateway) – load balancing, TLS, virtual hosts, traffic routing, API lifecycle management, authentication, data aggregation, billing, rate limiting.

All four can serve as entry points for client traffic into the cluster. Istio Gateway offers more customization than Kubernetes Ingress and can apply Istio monitoring and routing rules. API gateways are typically deployed as microservices (e.g., open‑source Zuul). NodePort/LoadBalancer is a basic method often used for testing.

In our production environment we use Nginx Ingress Controller as the entry point and do not rely on Istio Gateway’s advanced features, so the article focuses on exposing services with Nginx Ingress.

4. Exposing Services with Kubernetes Ingress

Kubernetes clients cannot directly reach Pod IPs; services are exposed via NodePort or LoadBalancer, or via Ingress for virtual hosts and IP saving.

Ingress acts as the external entry point, forwarding URL requests to services, similar to Nginx/Apache load balancers, with routing rules defined by the Ingress controller.

4.1 Using Nginx Ingress Controller as Istio Mesh Entry

1. Inject a sidecar into the Nginx Ingress Controller pod so it can participate in Istio traffic management.

2. Add the following annotations to the Ingress resource (replace service name and namespace):

nginx.ingress.kubernetes.io/service-upstream: 'true'

nginx.ingress.kubernetes.io/upstream-vhost: <service>.<namespace>.svc.cluster.local

Explanation of the annotations:

nginx.ingress.kubernetes.io/service-upstream – When true, Nginx uses the Service’s ClusterIP and port as the upstream, avoiding upstream changes caused by pod migration.

nginx.ingress.kubernetes.io/upstream-vhost – Sets the Host header sent to the upstream server, e.g., my-service.default.svc.cluster.local, overriding the client’s original domain.