Kubernetes: How traffic flows from internet to container via Istio
Let’s walk through the traffic flow from the internet to your application containers in GKE using Istio. This will include how the traffic passes through various components such as NodePort, Istio Gateway, VirtualService, kube-proxy, Kubernetes services, sidecar (Envoy proxy), and ultimately reaches the application.
Given the configuration provided for the Istio Gateway and VirtualServices, this flow applies to both frontend.mydomain.com and backend.mydomain.com.
Traffic Flow
- Client Request: The client sends an HTTPS request to either frontend.mydomain.com or backend.mydomain.com.
- Passes through WAF → DDOS, SQL Injection, cross site scripting etc
- Cloud Load Balancer: Routes the traffic to the appropriate GKE node via a NodePort.
- Istio Ingress Gateway: Handles mutual TLS (mTLS) authentication and decrypts the traffic.
- VirtualService: Based on the host (frontend.mydomain.com or backend.mydomain.com), the VirtualService routes the traffic to the corresponding Kubernetes service.
- Kube-proxy and Kubernetes Service: The kube-proxy forwards the traffic from the ClusterIP service to the appropriate application pod.
- Envoy Sidecar: The Envoy proxy in the pod processes the request and forwards it to the application container.
- Application: The application processes the request and sends a response back, following the same path in reverse.

1. Traffic from Internet to Google Cloud Load Balancer
- A client (user or service) on the internet makes an HTTPS request to either frontend.mydomain.com or backend.mydomain.com.
- The request first reaches the Google Cloud Load Balancer (GCLB) associated with your GKE cluster. This load balancer is automatically provisioned by GKE when you define an Ingress or Gateway resource.
- The GCLB forwards the request to a NodePort on one of the GKE cluster nodes.
2. NodePort and Istio Ingress Gateway
- The NodePort on the GKE node receives the traffic and forwards it to the Istio Ingress Gateway pod, which is part of the istio-ingressgateway service running on the cluster nodes.
The Istio Ingress Gateway is defined in the Gateway resource:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: foocorp-gateway
namespace: default
spec:
selector:
istio: ingressgateway # Uses Istio's default ingress gateway
servers:
- port:
number: 443
name: https-frontend
protocol: HTTPS
tls:
mode: MUTUAL
credentialName: "backend-credential"
hosts:
- "backend.mydomain.com"
- port:
number: 443
name: https-backend
protocol: HTTPS
tls:
mode: MUTUAL
credentialName: "backend-credential"
hosts:
- "backend.mydomain.com"
The Istio Gateway handles mutual TLS (mTLS) based on the tls.mode: MUTUAL configuration. Both the client and the server authenticate each other using the “backend-credential” certificate stored in the cluster. This ensures secure communication between the client and the cluster.
3. VirtualService Routing
- Once the Istio Gateway accepts the connection and decrypts the traffic, it uses the VirtualService configuration to route the request. The traffic is matched based on the host and URI.
For requests to frontend.mydomain.com, the VirtualService for the frontend service is
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: frontend
spec:
hosts:
- "frontend.mydomain.com"
gateways:
- foocorp-gateway
http:
- match:
- uri:
exact: /
route:
- destination:
host: frontend.org-namespace.svc.cluster.local
port:
number: 80
For requests to backend.mydomain.com, the VirtualService for the backend service is :
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend
spec:
hosts:
- "backend.mydomain.com"
gateways:
- foocorp-gateway
http:
- match:
- uri:
exact: /
route:
- destination:
host: backend.org-namespace.svc.cluster.local
port:
number: 80
- The VirtualService directs the traffic to the corresponding Kubernetes service within the cluster (e.g., frontend.org-namespace.svc.cluster.local or backend.org-namespace.svc.cluster.local), forwarding the request to port 80.
4. Kubernetes Service (ClusterIP) and kube-proxy
- After the traffic is routed to the appropriate Kubernetes Service, the kube-proxy component comes into play.
- The ClusterIP service acts as an internal load balancer and directs traffic to the appropriate pods running your application (frontend or backend) by forwarding requests to the pod IPs.
- The kube-proxy manages the routing rules and forwards the traffic to one of the available pod instances.
5. Envoy Sidecar Proxy
- The request reaches the destination pod, but before entering the application container, it passes through the Envoy sidecar proxy. Istio injects this sidecar into every pod, and it is responsible for managing inbound and outbound traffic for the pod. The sidecar:
- Enforces security policies (like mTLS).
- Provides traffic observability.
- Routes traffic internally between services.
- Envoy then forwards the request to the actual application container running within the pod.
6. Application Container
- Finally, the request is processed by the application container (either frontend or backend, depending on the route). The application responds to the request and sends the response back to the client following the reverse path:
- Application → Sidecar (Envoy) → kube-proxy → ClusterIP service → Istio VirtualService → Istio Gateway → Google Cloud Load Balancer → Client.
Benefits of Using Istio in This Setup
- mTLS: Secure communication between clients and services via mutual TLS.
- Routing Control: Fine-grained routing rules managed by Istio’s Gateway and VirtualService resources.
- Service Discovery: Kubernetes services (frontend.org-namespace.svc.cluster.local, backend.org-namespace.svc.cluster.local) allow automatic service discovery and load balancing.
- Sidecar Proxy: The Envoy sidecar provides enhanced observability, security, and control over traffic at the pod level.
- This configuration ensures that traffic is securely and efficiently routed to the appropriate backend services in your GKE cluster.
Reverse traffic flow from Container to other application within a cluster through gateway
