{"id":277,"date":"2025-12-03T05:19:15","date_gmt":"2025-12-03T05:19:15","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=277"},"modified":"2025-12-03T05:19:15","modified_gmt":"2025-12-03T05:19:15","slug":"gateway-api-for-service-mesh","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=277","title":{"rendered":"How to Use Kubernetes Gateway API for Istio Service Mesh (GAMMA Approach)"},"content":{"rendered":"

In this blog we will look at how to use the Gateway API for internal Istio<\/a> traffic management (east-west traffic) using the GAMMA approach.<\/p>\n

We will also look at a real world case study of GAMMA approach used in production.<\/p>\n

In the earlier blog about Istio ingress with Gateway API<\/a>, we learned how Gateway API works with the Istio gateway controller to manage ingress and egress traffic.<\/p>\n

But the Gateway API<\/strong><\/a> is not only for ingress<\/strong>. With the GAMMA initiative, we can now use Gateway API for internal service-to-service routing inside the mesh as well.<\/p>\n

Also, when using Istio Ambient Mesh mode<\/a>, the L7 traffic management is managed using gateway API.<\/p>\n

First, let\u2019s understand what GAMMA is.<\/p>\n

GAMMA: The Future of Mesh Routing<\/h2>\n

GAMMA<\/a> stands for Gateway API for Mesh Management<\/strong> and Administration.<\/p>\n

Kubernetes Gateway API<\/a> was originally designed to manage ingress traffic. That means routing requests coming from outside the cluster to services inside the cluster (north-south traffic).<\/p>\n

GAMMA extends Gateway API to support internal service-to-service traffic<\/strong> (east-west traffic). This allows us to use the same Gateway API resources like HTTPRoute<\/code><\/strong> and GRPCRoute<\/code><\/strong> for both ingress and mesh traffic.<\/p>\n

\n
\ud83d\udca1<\/div>\n
Ideally we we are shifting away from Istio’s proprietary VirtualService<\/code> and use the Kubernetes standard HTTPRoute<\/code><\/div>\n<\/div>\n

Although we use the same HTTPRoute<\/code><\/strong> object, there is one key difference<\/strong> when using it for internal mesh traffic.<\/p>\n

When HTTPRoute is used for ingress traffic, we normally set the parentRefs to a Gateway<\/strong>, because the Gateway owns the IP and ports that receive external requests.<\/p>\n

But in the GAMMA approach, HTTPRoute parentRefs references a Kubernetes Service<\/strong> instead of Gateways. The HTTPRoute then controls how traffic arriving at that service is routed (weighting, traffic splitting, and more).<\/p>\n

\"Gateway<\/figure>\n

Another important point is that you cannot use the shared service + subsets<\/strong> pattern<\/strong> like we do in Istio with VirtualService and DestinationRule<\/code><\/strong>. The reason is that Gateway API is designed to be a vendor-neutral standard that works across different service mesh<\/strong> implementations, not only Istio.<\/p>\n

Now that we have an understanding of GAMMA, lets look at how to implement it practically.<\/p>\n

Implementing Canary Deployments with GAMMA<\/h2>\n

In this hands-on setup, we will implement a canary deployment with GAMMA approach.<\/p>\n

Here is what we are going to build.<\/p>\n

    \n
  1. Deploy two versions of the app<\/li>\n
  2. Expose them through their own services<\/li>\n
  3. Create a shared service that acts as the parent reference<\/strong> for the HTTPRoute<\/code><\/strong><\/li>\n
  4. Create an HTTPRoute with the shared service as the parentRef, splitting traffic 90\/10 between the two service endpoints<\/li>\n
  5. Create two DestinationRules to apply Istio features to the application traffic<\/li>\n
  6. Finally, validate the setup with a client request.<\/li>\n<\/ol>\n
    \"Implementing<\/figure>\n<\/p>\n
    \n
    \ud83d\udccc<\/div>\n
    I am showing a canary setup for demo purposes. You can also route all traffic to a single service endpoint if needed.<\/div>\n<\/div>\n

    Setup Prerequisites<\/h2>\n

    To follow this setup, you need to have the following.<\/p>\n

      \n
    1. Kubernetes cluster with Istio Installed<\/li>\n
    2. Gateway API CRD’s installed in the cluster.<\/li>\n<\/ol>\n
      \n
      \ud83d\udccc<\/div>\n
      Refer Istio Installtion Guide<\/a> if you dont have a Istio setup ready.<\/div>\n<\/div>\n

      Create Istio Enabled Namespace<\/h2>\n

      We will deploy all the objects in the istio-test namespace.<\/p>\n

      If you don\u2019t already have this namespace, use the command below to create it and enable Istio for it.<\/p>\n

      kubectl create ns istio-test\n\nkubectl label namespace istio-test istio-injection=enabled<\/code><\/pre>\n
      Deploy the Workloads (Backend v1 & v2)<\/h2>\n
      For testing Gateway API with the mesh, we will deploy two versions of the application and expose them through separate services (backend-v1<\/code> and backend-v2<\/code>)<\/p>\n
      Use the following manifest to deploy the apps and services.<\/p>\n
      cat <<'EOF' | kubectl apply -f -\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
      Configure the Root Service<\/h2>\n
      Now we have backend-v1<\/code> and backend-v2<\/code> services.<\/p>\n
      However, clients in the mesh need a single stable address (e.g., http:\/\/backend<\/code>) to call. You can call this the root service<\/strong>. The mesh will then split between v1 and v2 services.<\/strong><\/p>\n
      Use the following YAML to create the shared service (root service).<\/p>\n
      cat <<'EOF' | kubectl apply -f -\napiVersion: v1\nkind: Service\nmetadata:\n  name: backend\n  namespace: istio-test\nspec:\n  selector:\n    app: backend \n  ports:\n  - name: http\n    port: 80\n    targetPort: 5678\nEOF<\/code><\/pre>\n
      Deploy HTTPRoute For Canary Routing<\/h2>\n
      Now, lets create an HTTPRoute<\/code> that binds to the shared backend<\/code> Service. <\/p>\n
      We will define a 90\/10 c<\/strong>anary traffic splitting. <\/strong>Meaning, <\/strong>90% of traffic goes to V1 backend, and 10% goes to V2 backend.<\/p>\n
      cat <<'EOF' | kubectl apply -f -\napiVersion: gateway.networking.k8s.io\/v1\nkind: HTTPRoute\nmetadata:\n  name: backend-split\n  namespace: istio-test\nspec:\n  parentRefs:\n  - name: backend \n    kind: Service\n    group: \"\"\n    port: 80\n  rules:\n  - backendRefs:\n    - name: backend-v1\n      port: 80\n      weight: 90\n    - name: backend-v2\n      port: 80\n      weight: 10\nEOF\n<\/code><\/pre>\n
      Validate the HTTPRoute<\/p>\n
      $ kubectl get HTTPRoute -n istio-test\n\nNAME            HOSTNAMES   AGE\nbackend-split               9m48s<\/code><\/pre>\n
      Destination Rule To Apply Istio Features<\/h2>\n
      The  HTTPRoute<\/code> we created  in the previous step primarily handles the routing. Meaning, it knows which service to send traffic.<\/p>\n
      But it cannot implement advanced connection<\/em> settings like Load Balancing algorithms, Circuit Breaking, outlier detection etc.  It is still handled by the the Istio DestinationRule<\/strong>.<\/p>\n
      \n
      \ud83d\udca1<\/div>\n
      Note: <\/strong><\/b>The Gateway API is developing BackendLBPolicy<\/code>, for load-balancing, session-persistence, LB behavior etc but currently, DestinationRule<\/code> is the standard way to configure this in Istio<\/div>\n<\/div>\n
      For our canary traffic splitting, lets create DestinationRule that applies ROUND_ROBIN<\/code> algorithm and ISTIO_MUTUAL<\/code> tls mode for encryption.<\/p>\n
      We create two separate DestinationRule becuase, backend-v1<\/code> and backend-v2<\/code> are treated as independent destinations.<\/p>\n
      Deploy the DestinationRule using the following manifest.<\/p>\n
      cat <<EOF | kubectl apply -f -\napiVersion: networking.istio.io\/v1beta1\nkind: DestinationRule\nmetadata:\n  name: backend-v1-settings\n  namespace: istio-test\nspec:\n  host: backend-v1.istio-test.svc.cluster.local\n  trafficPolicy:\n    loadBalancer:\n      simple: ROUND_ROBIN\n    tls:\n      mode: ISTIO_MUTUAL\n---\napiVersion: networking.istio.io\/v1beta1\nkind: DestinationRule\nmetadata:\n  name: backend-v2-settings\n  namespace: istio-test\nspec:\n  host: backend-v2.istio-test.svc.cluster.local\n  trafficPolicy:\n    loadBalancer:\n      simple: ROUND_ROBIN\n    tls:\n      mode: ISTIO_MUTUAL\nEOF<\/code><\/pre>\n
      Lets validate the DestinationRule<\/strong><\/code> using istioctl<\/code>.<\/p>\n
      $ istioctl x describe service backend-v1 -n istio-test\n\nService: backend-v1\n   Port: http 80\/HTTP targets pod port 5678\nDestinationRule: backend-v1-settings for \"backend-v1.istio-test.svc.cluster.local\"\n   Traffic Policy TLS Mode: ISTIO_MUTUAL\n   Policies: load balancer\nSkipping Gateway information (no ingress gateway pods)<\/code><\/pre>\n
      DestinationRule: backend-v1-settings<\/strong><\/code> confirms that Istio has successfully linked the specific DestinationRule<\/code> we created to the backend-v1<\/code> service with tls and round robin algorithm.<\/p>\n
      Validate Canary Traffic<\/h2>\n
      Lets deploy a simple client pod with curl to validate the canary traffic.<\/p>\n
      Deploy the following manifest.<\/p>\n
      cat <<EOF | kubectl apply -f - \napiVersion: v1\nkind: Pod\nmetadata:\n  name: client\n  namespace: istio-test\n  labels:\n    app: sleep\nspec:\n  containers:\n  - name: curl\n    image: curlimages\/curl:8.8.0\n    command:\n    - sh\n    - -c\n    - sleep 3650d\nEOF<\/code><\/pre>\n
      Execute<\/p>\n
      $ kubectl exec -n istio-test client -- sh -c 'for i in $(seq 1 20); do curl -s http:\/\/backend; done'\n\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v2 <-- The Canary\nhello from backend v2 <-- The Canary\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1<\/code><\/pre>\n
      You should see approximately 18 responses from hello from backend v1<\/code> and 2 responses from hello from backend v2<\/code> as given above.<\/p>\n
      Thats it!<\/p>\n
      We have implemented a hybrid model that is becoming the standard for modern Istio. <\/p>\n
        \n
      1. Routing (GAMMA API)<\/strong>: HTTPRoute<\/code> is splitting traffic (90\/10) <\/li>\n
      2. Policy (Istio API)<\/strong>: DestinationRule<\/code> is securing and managing the connection to the specific workloads.<\/li>\n<\/ol>\n
        Production Case Study <\/h2>\n
        Careem<\/a> (the “Super App” of the Middle East) migrated a platform handling 5 Billion+ requests\/da<\/strong>y from Linkerd to Istio without a single second of downtime.<\/p>\n
        Migrating between service meshes (e.g., Linkerd to Istio) is typically risky. Becuase the configuration APIs are not compatible so it becomes labor-intensive.<\/p>\n
        For example, Linkerd uses ServiceProfile<\/code><\/strong> and annotations<\/code><\/strong> and Istio uses VirtualService<\/code><\/strong> and DestinationRule<\/code><\/strong>.<\/p>\n
        Now think of migrating 5 billion daily requests<\/strong>. <\/p>\n
        You will have to basically thousands of route configurations and risk downtime if the translatated confiruagtions are not perfect.<\/p>\n
        But Careem used the Gateway API <\/strong> as a vendor-neutral abstraction layer.<\/p>\n
        Meaning, instead of translating Linkerd configs to Istio configs, they used the “Define Once, Swap Implementation<\/em><\/strong>” strategy.<\/p>\n
        What they did was, they rewrote their routing rules into standard Kubernetes Gateway API<\/strong> resources (HTTPRoute<\/code>). It is supported by both latest Linkerd and Istio versions.<\/p>\n
        By doing this, the routing logic was no longer tied to Linkerd or Istio CRDs.<\/p>\n
        For migration here is what they did.<\/p>\n
          \n
        1. They deployed the standard HTTPRoute resources.<\/li>\n
        2. They installed Istio alongside the existing infrastructure configuring Permissive mTLS. That <\/strong>allowed services in different meshes to communicate without encryption errors.<\/li>\n
        3. They used Flagger<\/strong> to automate the rollout. It was configured to manipulate standard HTTPRoute<\/code> resources for traffic splitting.<\/li>\n
        4. Then they triggered deployments to inject Istio sidecars, allowing Flagger to gradually shift traffic weights<\/strong> in the HTTPRoute<\/code> from Linkerd-meshed pods to new Istio-meshed pods.<\/li>\n
        5. This canary-based approach validated metrics at every step, ensuring zero downtime<\/strong> before fully promoting Istio and removing Linkerd.<\/li>\n<\/ol>\n
          To ensure safety during the transition, they utilized a Blue\/Green Ingress<\/strong> strategy. Meaning, they set up a ‘Blue’ gateway (Istio) alongside the ‘Green’ gateway (Linkerd) and used DNS manipulation to route traffic into the specific mesh.<\/p>\n
          Here is the reference architecture.<\/p>\n
          \"\"
          Source: Kubecon Presentation<\/span><\/figcaption><\/figure>\n
          The key thing here is, there is not vendor specific lock-in now. If they ever change meshes again, the HTTPRoute<\/code> definitions can stay.<\/p>\n
          If you want to understand this migration in detail, please watch the GAMMA in action<\/a> video.<\/p>\n
          Conclusion<\/h2>\n
          The Gateway API is becoming the standard for Kubernetes Ingress and Mesh traffic management. <\/p>\n
          While Istio\u2019s VirtualService<\/code><\/strong> and DestinationRule<\/code><\/strong> APIs are still widely used, GAMMA provides a vendor-neutral approach. Meaning, you can use HTTPRoute for internal traffic and decouple the routing logic from the underlying mesh implementation. <\/p>\n
          It will also make migrations (as seen in the Careem case study) and multi-mesh operations significantly easier.<\/p>\n
          Over to you.<\/p>\n
          Have you started experimenting with Gateway API? Or are you planning for a migration?<\/p>\n
          Either way, lets me know your thoughts in the comments.<\/p>\n
          \n
          Ngu\u1ed3n:<\/strong> How to Use Kubernetes Gateway API for Istio Service Mesh (GAMMA Approach) \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
          Source: https:\/\/devopscube.com\/gateway-api-for-service-mesh\/<\/p>\n","protected":false},"author":1,"featured_media":278,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-277","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/277","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=277"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/277\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/278"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=277"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=277"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=277"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}