Understanding Ingress Gateway in Istio: A Detailed Guide

Istio, as a service mesh, streamlines service-to-service communication, security, and observability within a microservices environment. However, challenges arise when external traffic needs to interact with services running inside the mesh. Without proper routing and control mechanisms, requests bypass the service mesh, losing out on Istio’s core benefits like observability, security, and traffic management.

In this blog, we will dive into the role of Ingress Controllers and Gateways in Istio. We’ll explore their architecture, the challenges they solve, and how they work with Virtual Services and Destination Rules to route traffic effectively through the service mesh. Practical steps and configuration examples are included to solidify your understanding.

The Problem: Traffic Without a Gateway

Imagine a scenario where external clients send HTTP or HTTPS requests to your microservices running inside a Kubernetes cluster. Without a gateway, these requests bypass the Istio service mesh, directly hitting the application pods. This approach presents several challenges:

1. Lack of Security: No control over the incoming traffic.
2. No Observability: Traffic metrics, logs, and traces are not collected.
3. No Traffic Management: Cannot apply Istio features like retries, circuit breakers, or route-specific policies.

This makes it difficult to maintain consistency, security, and observability for both internal and external traffic.

The Solution: Ingress Controller and Gateway in Istio

To address these challenges, Istio uses a Gateway and a Virtual Service to control and manage external traffic entering the service mesh.

What Is an Istio Gateway?

An Istio Gateway acts as an entry point for external traffic into the mesh. It provides:

1. Traffic Control: Directs traffic through the service mesh instead of bypassing it.
2. Security: Enforces TLS termination and other security features.
3. Integration with Service Mesh: Enables observability, traffic management, and policies for external traffic.

Unlike Kubernetes’ native Ingress Controller, Istio’s Gateway is not tied to a specific implementation (e.g., NGINX). Instead, it uses Envoy sidecars for flexibility and advanced features.

Istio Gateway Architecture

Here’s how Istio handles traffic from an external client to the final microservice:

1. Ingress Controller: Acts as a Kubernetes-native component to expose services externally (if required).
2. Istio Gateway: A Kubernetes resource that defines how traffic enters the mesh. It works with Envoy proxies to handle tasks like TLS termination and routing.
3. Virtual Service: Maps gateway traffic to specific services. It defines routes and policies for requests.
4. Destination Rule: Configures how traffic is handled after reaching the service, such as load balancing, subsets, and policies.
5. Sidecar Proxy (Envoy): Handles traffic between the services within the mesh.

Practical Steps: Setting Up an Istio Gateway

Let’s set up an Istio Gateway to route external HTTP traffic to a microservice in the service mesh.

Step 1: Set Up Istio on Your Kubernetes Cluster

For setting up Istio, refer this blog :-

https://medium.com/@harsh05/introduction-to-istio-and-service-mesh-a-complete-guide-03d3d112866b

• After this, must ensure the Istio control plane is running:-

kubectl get pods -n istio-system

Step 2: Deploy a Sample Application

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myd
  name: myd
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myd
  template:
    metadata:
      labels:
        app: myd
        version: one
    spec:
      containers:
      - image: kennethreitz/httpbin
        name: httpbin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myd1
  name: myd1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myd
  template:
    metadata:
      labels:
        app: myd
        version: two
    spec:
      containers:
      - image: kennethreitz/httpbin
        name: httpbin
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: myd
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

• Apply this yaml code in your kubernetes workspace.

kubectl apply -f basic-deploy.yml

• Make sure that the application is running on webui. Copy the External-IP of my-service and after testing, change its type from LoadBalancer to ClusterIP.

Step 3: Define the Istio Gateway

• Istio Ingress Gateway is already being given.

• So we need to define the Yaml file for our gateway. Create an Istio Gateway to expose the application externally:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  selector:
    istio: ingressgateway  # Use the Istio ingress gateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "a6dc702c0113246d790da61fdb311126-946205948.ap-south-1.elb.amazonaws.com"  # Replace with domain of istio-ingress 

Step 4: Configure the Destination Rule

Create a Destination Rule :

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service-dr
spec:
    host: my-service
    subsets:
      - labels:
          version: one
        name: one
      - labels:
          version: two
        name: two

Step 5: Configure the Virtual Service

Create a Virtual Service to route traffic from the gateway to the httpbin service:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
   name: my-service-vs
spec:
  hosts:
    - "a6dc702c0113246d790da61fdb311126-946205948.ap-south-1.elb.amazonaws.com"
  gateways:
    - httpbin-gateway
  http:
    - route:
         - destination:
              host: my-service
              subset: one
           weight: 90
         - destination:
              host: my-service
              subset: two
           weight: 10

Step 6: Test the Setup

1. Retrieve the external IP:

kubectl get svc istio-ingressgateway -n istio-system

2. Test the setup using browser:

3. Monitor using kiali web UI. See your Traffic flow from ingress to endpoint with different weight.

Traffic Flow: End-to-End Overview

Let’s break down the flow of a request:

1. Ingress Gateway: External traffic enters through the Istio Gateway, which handles tasks like TLS termination and hostname matching.
2. Virtual Service: Routes the request to the appropriate Kubernetes service (httpbin) based on the hostname.
3. Destination Rule: Applies traffic policies (e.g., load balancing) to the traffic routed to the service.
4. Sidecar Proxy: The Envoy proxy in the service’s pod handles communication with other services in the mesh.

Why Use a Gateway in Istio?

Here’s why routing traffic through a Gateway is critical:

1. Full Observability: All incoming traffic is captured for monitoring and tracing.
2. Traffic Management: Enables retries, timeouts, and routing policies for external traffic.
3. Security: Allows TLS termination and mutual TLS (mTLS) for secure communication.
4. Consistency: Ensures external traffic follows the same service mesh policies as internal traffic.

Advanced Features

Adding TLS Termination

Modify the Gateway to enable HTTPS:

servers:  
- port:  
    number: 443  
    name: https  
    protocol: HTTPS  
  tls:  
    mode: SIMPLE  
    credentialName: httpbin-credential  # Secret containing TLS certs  
  hosts:  
  - "httpbin.example.com"

Create a Kubernetes secret with the TLS certificate:

kubectl create -n istio-system secret tls httpbin-credential \  
  --key /path/to/tls.key --cert /path/to/tls.crt

Summary

In this blog, we explored the role of the Ingress Controller and Gateway in Istio:

1. Challenges without Gateways: External traffic bypasses the service mesh, leading to security and observability gaps.
2. Istio Gateway: Acts as the entry point, ensuring all traffic flows through the service mesh.
3. Virtual Service and Destination Rule: Together, they route and manage traffic effectively within the mesh.
4. Traffic Flow: From Ingress Gateway to sidecar proxies, Istio provides a seamless and controlled traffic pipeline.

By leveraging Gateways and associated resources, Istio ensures that external traffic is managed with the same robustness as internal communication, enabling a secure, observable, and efficient service mesh environment.