Using Gateway API for Istio Ingress<\/h2>\n
Istio<\/strong><\/a> is a service mesh<\/strong><\/a> that primarily manages the internal traffic, meaning the service-to-service communication (east-west traffic<\/em>).<\/p>\n However, we also need to handle north-south traffic (external to internal<\/em>). To do that, we need an ingress setup similar to native Kubernetes.<\/p>\n For this, Istio provides its own However, Istio now supports the Kubernetes Gateway API for handling external traffic. Also it is intended to become the default API<\/strong> in the future for managing ingress\/egress traffic in Istio-enabled clusters. <\/p>\n The image below shows the high-level architecture of what we are going to build. Once you finish the setup, come back to this diagram. It will make more sense then.<\/p>\n Although there is support, here is what the official Istio documentation says about using the Gateway API for ingress:<\/p>\n While the Gateway APIs offer a lot of rich routing functionality, it does not yet cover 100% of Istio\u2019s feature set. (istio.io)<\/p><\/blockquote>\n Now, lets understand the Gateway API integration practically.<\/p>\n To get started with this setup you need an Istio-enabled Kubernetes cluster.<\/a><\/p>\n We have covered the full Istio setup using sidecar mode in a detailed blog. Please refer to the following guide for that setup. <\/p>\n Set up Istio on a Kubernetes Cluster<\/a><\/p><\/blockquote>\n So please make sure to deploy them as well.<\/p><\/div>\n<\/div>\n The first step is to install the Kubernetes Gateway API CRDs. This way Kubernetes understands the Gateway API custom objects<\/a> and Istio can watch for those Gateway API objects and act on them.<\/p>\n To install the Gateway API CRDs, use the following command.<\/p>\n Once the installation is completed, we can list them to ensure the installation.<\/p>\n The output confirms that the CRDs have been successfully installed and that they are used to define the routing rules.<\/p>\n However, since we are using Istio, its built-in gateway controller<\/strong><\/b> acts as a Gateway API controller<\/a>. So we do not need to install a separate controller.<\/div>\n<\/div>\n To use Gateway API, the first thing that we need is the GatewayClass<\/strong>. It tells Kubernetes which controller<\/strong> will implement the gateways. In our case its the istio When we install Istio on a Kubernetes cluster, it automatically creates a You can list the GatewayClasses using the following command.<\/p>\n Here, you can see two Gateway Classes.<\/p>\n Next, let\u2019s deploy a demo application that we will use to test ingress connectivity using the Gateway API.<\/p>\n For this demo, we are using the same application deployment<\/a> from the Istio setup blog.<\/p>\n If you are already following that blog and have the demo app running, you can skip this step. Otherwise, you can follow the deployment instructions here.<\/p>\n Use the following manifest to deploy the demo apps and its related service endpoints ( Once the deployment is completed, ensure that the resources are running without any issues as given below.<\/p>\n Now that the required application and other basic setup is ready, we can start configuring ingress using Gateway API objects.<\/p>\n Follow the steps given below.<\/p>\n Gateway<\/strong> is a Custom Resource of Gateway API where we define what type of traffic the Controller should handle.<\/p>\n For this demo, we will use the following.<\/p>\n When we deploy a Gateway object, the Gateway controller (Istio controller) creates an Envoy proxy pod<\/strong> to route traffic to your backend pods. It also creates an external load balancer<\/strong> (on the cloud) so that external traffic can reach the proxy.<\/p>\n Copy the following code on your terminal to create a Gateway YAML configuration file.<\/p>\n Please update these annotations based on the cloud provider you are using. The rest of the configuration remains the same.<\/p><\/div>\n<\/div>\n To apply this configuration, use the following command.<\/p>\n It will deploy a proxy pod (Data plane controller) and service type Use the following command to validate that the proxy pod and service are deployed.<\/p>\n If you describe the Proxy pod, you will see Now use the following command list the Gateway object and see its created and valid.<\/p>\n In the above output, Now our gateway is ready. This means traffic from external sources<\/strong> can reach the cluster through the Gateway load balancer that was created.<\/p>\n Next, we need to configure routes so that the gateway proxy pod inside the cluster knows which pods<\/strong> to send the traffic to and how<\/strong> it should route that traffic.<\/p>\n In the Even if you do not have one continue with the following hostname configurations<\/strong><\/b>. We will cover local DNS resolution in the next steps.<\/div>\n<\/div>\n To create a To apply this, use the following command. It will create a HttpRoute in the Now, validate the Now that we have defined the routing rules, the gateway proxy pod knows which Kubernetes service endpoint to send the traffic to and how to split it in a canary style.<\/p>\n The Gateway API standard doesn’t yet have mature features for circuit breaking or connection pooling.<\/p>\n So, if you want to use Istio features like circuit breaking, custom load-balancing algorithms, mTLS or rate limiting<\/strong> at the application service level, you need to add Istio Istio For example, in our Copy the following to the terminal to create the To apply, use the following command.<\/p>\n It creates two destination rules for each backend services. Both uses the same traffic policy configurations.<\/p>\n Now list the Now, we are going to create a temporary DNS entry on our local machine so that we can test the traffic with the If your load balancer endpoint is a DNS name, get the public IP of the load balancer using the following command.<\/p>\n You will get a similar like output.<\/p>\n Now, open the For example,<\/p>\n Here is how it looks<\/p>\n Once the IP is mapped with the hostname, save the file and exit.<\/p>\n Now our entire ingress configuration is ready. The next step is to validate the end-to-end traffic flow.<\/p>\n Now lets test the complete ingress traffic flow.<\/p>\n The following linux script runs the The following output shows that the external traffic is properly routed to both backend services.<\/p>\n In this blog we have covered how to configure Istio + Kubernetes Gateway API to manage ingress (north-south) traffic in a Kubernetes cluster. We practically walked through how a Gateway + HTTPRoute can expose Istio mesh services externally.<\/strong><\/p>\n With the graduation of mesh support in Gateway <\/a>API, Gateway API supports internal (east-west) traffic routing inside a service mesh via the GAMMA Initiative <\/a>(Gateway API for Mesh Management and Administration).<\/p>\n That means Gateway API is no longer limited just to ingress\/egress. <\/p>\n You can use HTTPRoute, GRPCRoute, etc..to declare how services talk to each other inside the Istio service mesh. This actually brings consistency to both external and internal<\/strong> traffic management.<\/p>\n Refer the Managing East-West Traffic with Gateway API<\/a> blog to see it in action.<\/p>\n If you want a real world example, you can look at Careem use case. They recently migrated to Istio with Gateway API + GAMMA to enable a \u201cdefine-once, route-everywhere\u201d model.<\/p>\nGateway<\/code> + VirtualService<\/code> API to handle ingress\/egress.<\/p>\n![\"Gateway](\"https:\/\/storage.ghost.io\/c\/5f\/2f\/5f2f4d20-2abf-4534-8d40-7aa233aedd43\/content\/images\/2025\/11\/image-100.png\")
Setup Prerequisites<\/h2>\n
Install Gateway API CRD’s<\/h2>\n
kubectl apply -f https:\/\/github.com\/kubernetes-sigs\/gateway-api\/releases\/download\/v1.3.0\/standard-install.yaml\n<\/code><\/pre>\n$ kubectl get crds | grep gateway\n\ngatewayclasses.gateway.networking.k8s.io 2025-05-21T13:49:23Z\ngateways.gateway.networking.k8s.io 2025-05-21T13:49:29Z\ngrpcroutes.gateway.networking.k8s.io 2025-05-21T13:49:32Z\nhttproutes.gateway.networking.k8s.io 2025-05-21T13:49:35Z\nreferencegrants.gateway.networking.k8s.io 2025-05-21T13:49:36Z<\/code><\/pre>\nDefault Istio GatewayClass<\/h2>\n
gateway-controller<\/code>.<\/strong><\/p>\nGatewayClass<\/code><\/strong>.<\/p>\n$ kubectl get gc\n\nNAME CONTROLLER ACCEPTED AGE\nistio istio.io\/gateway-controller True 3h43m\nistio-remote istio.io\/unmanaged-gateway True 3h43m\n<\/code><\/pre>\n\n
istio<\/code> – This is Istio’s built-in controller that manages Gateway resources. It creates and manages actual gateway pods (like istio-ingressgateway) in your cluster.<\/li>\nistio-remote<\/code> – It references gateways that exist in another. Meaning the controller is in another cluster and especially useful for the multi cluster mesh management.<\/li>\n<\/ul>\nDeploy Demo Application<\/h2>\n
backend-v1<\/code><\/strong> & backend-v2<\/code><\/strong>).<\/p>\ncat <<'EOF' | kubectl apply -f -\napiVersion: v1\nkind: Namespace\nmetadata:\n labels:\n istio-injection: enabled\n name: istio-test\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: backend-v1\n namespace: istio-test\nspec:\n replicas: 3\n selector:\n matchLabels: { app: backend, version: v1 }\n template:\n metadata:\n labels: { app: backend, version: v1 }\n spec:\n containers:\n - name: echo\n image: hashicorp\/http-echo\n args: [\"-text=hello from backend v1\"]\n ports:\n - containerPort: 5678\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: backend-v2\n namespace: istio-test\nspec:\n replicas: 2\n selector:\n matchLabels: { app: backend, version: v2 }\n template:\n metadata:\n labels: { app: backend, version: v2 }\n spec:\n containers:\n - name: echo\n image: hashicorp\/http-echo\n args: [\"-text=hello from backend v2\"]\n ports:\n - containerPort: 5678\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: backend-v1\n namespace: istio-test\nspec:\n selector:\n app: backend\n version: v1\n ports:\n - name: http\n port: 80\n targetPort: 5678\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: backend-v2\n namespace: istio-test\nspec:\n selector:\n app: backend\n version: v2\n ports:\n - name: http\n port: 80\n targetPort: 5678\nEOF<\/code><\/pre>\n$ kubectl -n istio-test get po,svc\n\nNAME READY STATUS RESTARTS AGE\npod\/backend-v1-7c88547fc6-9755x 2\/2 Running 0 10s\npod\/backend-v1-7c88547fc6-97hvg 2\/2 Running 0 10s\npod\/backend-v1-7c88547fc6-tdjb2 2\/2 Running 0 10s\npod\/backend-v2-86c767bf6b-9vplh 2\/2 Running 0 10s\npod\/backend-v2-86c767bf6b-bs2kg 2\/2 Running 0 10s\n\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\nservice\/backend-v1 ClusterIP 10.100.171.193 <none> 80\/TCP 10s\nservice\/backend-v2 ClusterIP 10.100.185.97 <none> 80\/TCP 9s<\/code><\/pre>\nCreating Istio Ingress With Gateway API<\/h2>\n
Step 1: Create a Gateway <\/h3>\n
\n
cat << EOF > istio-gateway.yaml\napiVersion: gateway.networking.k8s.io\/v1\nkind: Gateway\nmetadata:\n name: istio-gateway\n namespace: istio-test\n annotations:\n service.beta.kubernetes.io\/aws-load-balancer-type: \"nlb\"\nspec:\n gatewayClassName: istio\n listeners:\n - name: http\n protocol: HTTP\n port: 80\n allowedRoutes:\n namespaces:\n from: Same\nEOF<\/code><\/pre>\nkubectl apply -f istio-gateway.yaml<\/code><\/pre>\nLoadBalancer<\/code><\/strong> in the istio-test<\/code><\/strong> namespace.<\/p>\n$ kubectl get po,svc -n istio-test -l gateway.networking.k8s.io\/gateway-name=istio-gateway\n\n\nNAME READY STATUS RESTARTS AGE\npod\/istio-gateway-istio-67584dc449-qmkpx 1\/1 Running 0 4m31s\n\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\nservice\/istio-gateway-istio LoadBalancer 10.100.77.16 ad8805f370c854e749a18ed03f2bb2e0-4940c029a9c83906.elb.us-west-2.amazonaws.com 15021:31161\/TCP,80:31432\/TCP 4m31s<\/code><\/pre>\nistio\/proxyv2<\/code> <\/strong>image being used. It is a envoy based proxy.<\/p>\n$ kubectl -n istio-test get gateway\n\nNAME CLASS ADDRESS PROGRAMMED AGE\nistio-gateway istio ad8805f370c854e749a18ed03f2bb2e0-4940c029a9c83906.elb.us-west-2.amazonaws.com True 17s<\/code><\/pre>\n...9a9c83906.elb.us-west-2.amazonaws.com<\/code><\/strong> is the DNS name of the created Network Load Balancer<\/a>. If you are using Google Cloud or Azure, you will see the respective load balancer endpoint instead.<\/p>\nStep 2: Create an HTTPRoute<\/h3>\n
HTTPRoute<\/code><\/strong> is another Gateway API Custom Resource to defines the routing rules (where to send the traffic internally).<\/p>\nHTTPRoute<\/code><\/strong> configuration, we will primarily define the following.<\/p>\n\n
backend-v1<\/code><\/strong> & backend-v1<\/code><\/strong>)<\/li>\nHTTPRoute<\/code><\/strong> manifest, copy the following in the terminal.<\/p>\ncat << EOF > istio-httproute.yaml\napiVersion: gateway.networking.k8s.io\/v1\nkind: HTTPRoute\nmetadata:\n name: backend-route\n namespace: istio-test\nspec:\n parentRefs:\n - name: istio-gateway\n namespace: istio-test\n hostnames:\n - \"test.devopscube.com\"\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: \/\n backendRefs:\n - name: backend-v1\n port: 80\n weight: 50\n - name: backend-v2\n port: 80\n weight: 50\nEOF<\/code><\/pre>\nistio-test<\/code><\/strong> namespace.<\/p>\nkubectl apply -f istio-httproute.yaml<\/code><\/pre>\nHttpRoute<\/code><\/strong> resource using the following command.<\/p>\n$ kubectl -n istio-test get httproutes\n\nNAME HOSTNAMES AGE\nbackend-route [\"test.devopscube.com\"] 85s<\/code><\/pre>\nStep 4: Create a Destination Rule<\/h3>\n
DestinationRule<\/code><\/strong> resources for those services.<\/p>\nDestinationRule<\/code><\/strong> defines policies that apply to traffic intended for a service after<\/strong> routing has occurred.<\/p>\nDestinationRule<\/code><\/strong> we are going to define ROUND_ROBIN<\/code> <\/strong>algorithm, maxConnections<\/code><\/strong> and Outlier Detection.<\/p>\nDestinationRule<\/code> <\/p>\ncat << EOF > istio-destinationrule.yaml\napiVersion: networking.istio.io\/v1beta1\nkind: DestinationRule\nmetadata:\n name: backend-destination-rule\n namespace: istio-test\nspec:\n host: backend-v1.istio-test.svc.cluster.local\n trafficPolicy:\n loadBalancer:\n simple: ROUND_ROBIN\n connectionPool:\n tcp:\n maxConnections: 100\n http:\n http1MaxPendingRequests: 50\n http2MaxRequests: 100\n maxRequestsPerConnection: 2\n outlierDetection:\n consecutive5xxErrors: 5\n interval: 30s\n baseEjectionTime: 30s\n maxEjectionPercent: 50\n---\napiVersion: networking.istio.io\/v1beta1\nkind: DestinationRule\nmetadata:\n name: backend-v2-destination-rule\n namespace: istio-test\nspec:\n host: backend-v2.istio-test.svc.cluster.local\n trafficPolicy:\n loadBalancer:\n simple: ROUND_ROBIN\n connectionPool:\n tcp:\n maxConnections: 100\n http:\n http1MaxPendingRequests: 50\n http2MaxRequests: 100\n maxRequestsPerConnection: 2\n outlierDetection:\n consecutive5xxErrors: 5\n interval: 30s\n baseEjectionTime: 30s\n maxEjectionPercent: 50\nEOF<\/code><\/pre>\nkubectl apply -f istio-destinationrule.yaml<\/code><\/pre>\nDestinationRule<\/code><\/strong> resources and validate it.<\/p>\n$ kubectl -n istio-test get destinationrules\n\nNAME HOST AGE\nbackend-destination-rule backend-v1.istio-test.svc.cluster.local 106m\nbackend-v2-destination-rule backend-v2.istio-test.svc.cluster.local 106m<\/code><\/pre>\nStep 5: Configure Local DNS Resolution (Optional)<\/h3>\n
test.devopscube.com<\/code> hostname we used in the HttpRoute.<\/p>\ndig +short <Load Balancer DNS Name><\/code><\/pre>\n$ dig +short ad8805f370c854e749a18ed03f2bb2e0-4940c029a9c83906.elb.us-west-2.amazonaws.com\n\n35.95.166.48<\/code><\/pre>\n\/etc\/hosts<\/code> on your local machine and paste IP and the hostname name you have given in the HTTPRoute<\/strong> config.<\/p>\n35.95.166.48 test.devopscube.com<\/code><\/pre>\n$ sudo vim \/etc\/hosts\nPassword:\n\n$ cat \/etc\/hosts\n\n##\n# Host Database\n#\n# localhost is used to configure the loopback interface\n# when the system is booting. Do not change this entry.\n##\n127.0.0.1 localhost\n255.255.255.255 broadcasthost\n::1 localhost\n\n35.95.166.48 test.devopscube.com<\/code><\/pre>\nStep 4: Validate the Ingress Traffic Flow <\/h3>\n
curl test.devopscube.com<\/code> command 10 times in a row. This helps us validate whether the canary traffic split is happening between the v1 and v2 services as configured in the HttpRoute<\/code><\/p>\nfor i in {1..10}; do curl test.devopscube.com; done<\/code><\/pre>\n$ for i in {1..10}; do curl test.devopscube.com; done\n\nhello from backend v1\nhello from backend v2\nhello from backend v2\nhello from backend v1\nhello from backend v2\nhello from backend v2\nhello from backend v1\nhello from backend v1\nhello from backend v2\nhello from backend v1<\/code><\/pre>\nConclusion<\/h2>\n