Expose Istio Mesh Services with Nginx Ingress: A Step‑by‑Step Guide

1. Overview

API gateways have long served as entry points for client‑to‑backend traffic (north‑south). Service meshes like Istio manage internal (east‑west) traffic and also include a gateway, which can cause confusion about their relationship. This article clarifies the differences, explains whether Istio replaces an API gateway, how Istio’s API gateway works, and how to expose services inside an Istio mesh.

2. Key Points

Service meshes were created to manage internal traffic of distributed applications; API gateways have existed for a long time.

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

API gateways and service meshes are converging.

3. Ways to Expose Services in an Istio Mesh

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

The shaded area represents the Istio mesh (internal east‑west traffic). Client‑to‑cluster traffic is north‑south. Since Ingress Controllers and Istio Gateways run inside the cluster, their traffic to other services can be considered internal.

Method

Controller

Features

NodePort/LoadBalancer

Kubernetes

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, auth, data aggregation, billing, rate limiting

All four methods can serve as entry points for client traffic into the Kubernetes cluster. Istio Gateway offers more customization than a standard Ingress and can apply Istio features to inbound traffic. The official Istio docs recommend using Istio Gateway to leverage the full feature set. API gateways are typically deployed as microservices inside the cluster, often using open‑source solutions such as Zuul. NodePort/LoadBalancer is a basic exposure method suitable 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 following sections focus on exposing services with Nginx Ingress.

4. Exposing Services with Kubernetes Ingress

Kubernetes clients cannot directly reach Pod IPs; services are exposed via NodePort, LoadBalancer, or Ingress for virtual hosting and IP conservation. The following diagram illustrates the Ingress architecture.

Ingress acts as the entry point from outside the cluster, forwarding URL requests to appropriate services, similar to Nginx or Apache load balancers, with routing rules provided by the Ingress controller.

4.1 Using Nginx Ingress Controller as the Istio Mesh Entry

1. Inject the 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):

<code>nginx.ingress.kubernetes.io/service-upstream: 'true'
nginx.ingress.kubernetes.io/upstream-vhost: &lt;service&gt;.&lt;namespace&gt;.svc.cluster.local</code>

Explanation of the annotations:

Annotation

Type/Options

Description

nginx.ingress.kubernetes.io/service-upstream

true or false

By default Nginx uses Pod IPs as upstream members; setting true makes it use the Service’s ClusterIP and port, avoiding upstream changes when Pods move.

nginx.ingress.kubernetes.io/upstream-vhost

string

Overrides the Host header sent to the upstream server, allowing you to specify the internal service DNS name (e.g., my-service.default.svc.cluster.local).