{"id":48797,"date":"2025-03-19T06:51:48","date_gmt":"2025-03-19T06:51:48","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=48797"},"modified":"2026-02-21T07:26:56","modified_gmt":"2026-02-21T07:26:56","slug":"kubernetes-tutorials-kubernetes-gateway-api-complete-guide","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/kubernetes-tutorials-kubernetes-gateway-api-complete-guide\/","title":{"rendered":"Kubernetes Tutorials: Kubernetes Gateway API Complete Guide"},"content":{"rendered":"\n
\n

Yes, the Kubernetes Gateway API<\/strong> is intended to be an evolution and successor to the traditional Ingress API<\/strong> in Kubernetes.<\/p>\n\n\n\n

First lets understand the differnce between ingress vs egress traffic<\/h2>\n<\/blockquote>\n\n\n\n
\n

Ingress = something from outside coming in<\/strong><\/p>\n\n\n\n

Egress = something from inside going out<\/strong><\/p>\n<\/blockquote>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Now, Lets understand what are the ingress options we have in Kubernetes<\/h2>\n\n\n\n
    \n
  • Kubernetes NodePort Service<\/li>\n\n\n\n
  • Kubernetes LoadBalancer Service<\/li>\n\n\n\n
  • Kubernetes Ingress Resource (Legacy)<\/li>\n\n\n\n
  • Kubernetes Gateway API (Modern)<\/li>\n<\/ul>\n\n\n\n
    \n
    \"\"<\/figure>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    \"\"<\/figure>\n<\/figure>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    Now, Lets understand How Kubernetes Ingress resources works?<\/h2>\n\n\n\n

    \ud83e\udde9 Components of Kubernetes Ingress<\/h3>\n\n\n\n

    There are primarily three main components<\/strong> that make up a functional Kubernetes Ingress setup:<\/p>\n\n\n\n

      \n
    1. Ingress Resource<\/strong> (Kubernetes Object)<\/li>\n\n\n\n
    2. Ingress Controller<\/strong><\/li>\n\n\n\n
    3. Load Balancer (Optional, based on infrastructure)<\/strong><\/li>\n<\/ol>\n\n\n\n

      Let’s understand each clearly:<\/p>\n\n\n\n

      \ud83d\udd39 1. Ingress Resource<\/strong><\/h4>\n\n\n\n
        \n
      • It’s a Kubernetes API object<\/strong> (Ingress<\/code>) defined in YAML.<\/li>\n\n\n\n
      • Defines how external HTTP\/HTTPS traffic is routed to Kubernetes services based on rules like host<\/strong> and path<\/strong>.<\/li>\n<\/ul>\n\n\n\n

        \ud83d\udd39 2. Ingress Controller<\/strong><\/h4>\n\n\n\n
          \n
        • Ingress Controller<\/strong> is a specialized controller pod running inside Kubernetes.<\/li>\n\n\n\n
        • Continuously monitors Kubernetes Ingress objects and updates its internal configuration based on these definitions.<\/li>\n<\/ul>\n\n\n\n

          Examples of popular Ingress Controllers:<\/strong><\/h4>\n\n\n\n
            \n
          • NGINX Ingress Controller<\/strong> (most common)<\/em><\/li>\n\n\n\n
          • Traefik<\/strong><\/li>\n\n\n\n
          • AWS Load Balancer Controller (ALB)<\/strong><\/li>\n\n\n\n
          • HAProxy Ingress<\/strong><\/li>\n\n\n\n
          • Contour (Envoy-based)<\/strong>, etc.<\/li>\n\n\n\n
          • Ingress Controllers<\/strong> do:\n
              \n
            • Watch Kubernetes API for changes in Ingress resources.<\/li>\n\n\n\n
            • Dynamically update configurations (e.g., NGINX config, Traefik config, Envoy proxy settings).<\/li>\n\n\n\n
            • Perform L7 routing (based on hosts\/paths), SSL termination, and load balancing.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

              \ud83d\udd39 3. Load Balancer (Optional Component)<\/strong><\/h3>\n\n\n\n
                \n
              • External load balancer<\/strong> (like AWS ELB, ALB, GCP LB, Azure LB, or MetalLB) provides a single entry point (external IP) to your Ingress Controller pods.<\/li>\n\n\n\n
              • If you’re on a cloud-managed Kubernetes service (e.g., EKS), this load balancer is typically automatically created by setting the ingress controller\u2019s service type to LoadBalancer<\/code>.<\/li>\n\n\n\n
              • It distributes incoming external traffic across multiple Ingress Controller pods, ensuring high availability<\/strong> and scalability<\/strong>.<\/li>\n<\/ul>\n\n\n\n

                \ud83d\udd39 4. Ingress Controller Pod (Deployed as Deployment or DaemonSet)<\/strong><\/h3>\n\n\n\n
                  \n
                • This component runs inside Kubernetes as pods (part of Deployment or DaemonSet).<\/li>\n\n\n\n
                • Continuously updates load-balancing rules as per changes in Ingress resources.<\/li>\n\n\n\n
                • Manages configurations for the underlying proxy (NGINX, Traefik, Envoy, HAProxy, etc.)<\/li>\n<\/ul>\n\n\n\n

                  \ud83d\udd39 How the Components Work Together:<\/strong><\/h3>\n\n\n\n
                  External Traffic
                        |
                  Load Balancer (e.g., AWS ELB\/ALB, NGINX)
                        |
                  Ingress Controller Pods (e.g., NGINX or Traefik)
                        |
                  Ingress Resource YAML rules (Routing Rules)
                        |
                  Kubernetes Service
                        |
                  Application Pods
                  <\/code><\/pre>\n\n\n\n
                    \n
                  • External traffic hits a Load Balancer.<\/li>\n\n\n\n
                  • The load balancer forwards traffic to your Ingress Controller pods<\/strong>.<\/li>\n\n\n\n
                  • The Ingress Controller checks the Ingress Resource rules from Kubernetes API.<\/li>\n\n\n\n
                  • It routes requests to the correct Kubernetes Services<\/strong> and ultimately to Pods<\/strong>.<\/li>\n<\/ul>\n\n\n\n
                    \n
                    \"\"<\/figure>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    \"\"<\/figure>\n<\/figure>\n\n\n\n
                    Now, Lets understand Kubernetes Gateway API <\/h2>\n\n\n\n
                    Here’s a clear, precise, and practical overview of:<\/p>\n\n\n\n
                    \n\n\n\n
                    \ud83c\udf00 What is Kubernetes Gateway API?<\/strong><\/h2>\n\n\n\n
                    The Kubernetes Gateway API<\/strong> is a modern, standardized set of Kubernetes resources designed to route and manage network traffic into, out of, and within Kubernetes clusters.<\/p>\n\n\n\n
                    It\u2019s a successor and evolution to the traditional Kubernetes Ingress Resource<\/strong>, created to solve limitations of the legacy Ingress and support advanced use cases in a standardized, extensible, and portable manner.<\/p>\n\n\n\n
                    \n\n\n\n
                    \ud83c\udfaf Why was Gateway API Created?<\/strong><\/h2>\n\n\n\n
                      \n
                    • Traditional Ingress had limitations:\n
                        \n
                      • HTTP\/HTTPS only<\/strong>, limited multi-protocol support.<\/li>\n\n\n\n
                      • Complexity with vendor-specific annotations.<\/li>\n\n\n\n
                      • Lack of advanced routing and traffic management features.<\/li>\n\n\n\n
                      • Poor support for multi-team and multi-tenant scenarios.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                        The Gateway API addresses these gaps by introducing a cleaner<\/strong>, standardized<\/strong>, and more flexible<\/strong> set of APIs.<\/p>\n\n\n\n
                        \n\n\n\n
                        \ud83d\udccc Key Components of Gateway API<\/strong><\/h2>\n\n\n\n
                        Gateway API introduces several new Kubernetes objects:<\/p>\n\n\n\n
                          \n
                        1. GatewayClass<\/strong><\/li>\n\n\n\n
                        2. Gateway<\/strong><\/li>\n\n\n\n
                        3. HTTPRoute, TCPRoute, UDPRoute<\/strong> (and other route types)<\/em><\/li>\n\n\n\n
                        4. ReferenceGrant<\/strong> (security-related resource)<\/em><\/li>\n<\/ol>\n\n\n\n
                          \n\n\n\n
                          1. \ud83d\udea9 GatewayClass<\/strong><\/h3>\n\n\n\n
                            \n
                          • Defines a type of load balancer or gateway, managed by a specific controller.<\/li>\n\n\n\n
                          • Similar conceptually to StorageClass for persistent storage.<\/li>\n<\/ul>\n\n\n
                            apiVersion: gateway.networking.k8s.io\/v1\nkind: GatewayClass\nmetadata:\n  name: aws-alb\nspec:\n  controller: ingress.k8s.aws\/alb\n<\/code><\/span><\/pre>\n\n\n
                            \n\n\n\n
                            2. \ud83d\udeaa Gateway<\/strong><\/h3>\n\n\n\n
                              \n
                            • Represents the actual load balancer instance or network gateway itself.<\/li>\n\n\n\n
                            • Defines listeners (protocols, ports), certificates, and overall traffic entry points.<\/li>\n<\/ul>\n\n\n
                              apiVersion: gateway.networking.k8s.io\/v1\nkind: Gateway\nmetadata:\n  name: main-gateway\nspec:\n  gatewayClassName: aws-alb\n  listeners:\n  - protocol: HTTPS\n    port: 443\n    name: https\n    tls:\n      mode: Terminate\n      certificateRefs:\n      - name: example-com-cert\n<\/code><\/span><\/pre>\n\n\n
                              \n\n\n\n
                              3. \ud83d\udd17 HTTPRoute (TCPRoute, UDPRoute, etc.)<\/strong><\/h3>\n\n\n\n
                                \n
                              • Defines detailed routing rules based on hostnames, paths, headers, etc.<\/li>\n\n\n\n
                              • Routes attach to Gateways.<\/li>\n<\/ul>\n\n\n\n
                                Example HTTPRoute<\/strong>:<\/p>\n\n\n
                                apiVersion: gateway.networking.k8s.io\/v1\nkind<\/span>: HTTPRoute\nmetadata<\/span>:\n  name: my-app-route\nspec<\/span>:\n  parentRefs:\n  - name: main-gateway\n  rules<\/span>:\n  - matches:\n    - path:\n        type: PathPrefix\n        value<\/span>: \"\/api\"<\/span>\n    backendRefs<\/span>:\n    - name: api-service\n      port<\/span>: 80<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                4. \ud83d\udd12 ReferenceGrant<\/strong><\/h3>\n\n\n\n
                                  \n
                                • Manages security by explicitly allowing namespaces to reference resources across namespace boundaries.<\/li>\n\n\n\n
                                • Prevents unauthorized cross-namespace configurations.<\/li>\n<\/ul>\n\n\n\n
                                  \n\n\n\n
                                  \ud83d\udcd0 High-Level Architecture of Gateway API<\/strong><\/h2>\n\n\n
                                  External Traffic\n      |\n Gateway (Load Balancer\/Proxy<\/span>)\n      |\n HTTPRoute\/TCPRoute Rules\n      |\n Kubernetes Service\n      |\n Application Pods\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                    \n
                                  • Gateway<\/strong>: Entry point for network traffic, defined through a GatewayClass.<\/li>\n\n\n\n
                                  • Route Resources<\/strong>: Define how traffic flows to internal services.<\/li>\n\n\n\n
                                  • GatewayClass<\/strong>: Connects Gateways to Controllers (Istio, AWS ALB, Contour, etc.).<\/li>\n<\/ul>\n\n\n\n
                                    \n\n\n\n
                                    \ud83d\udee0\ufe0f Key Benefits of Kubernetes Gateway API<\/strong><\/h2>\n\n\n\n
                                      \n
                                    • \u2705 Standardized & Vendor-Neutral<\/strong>\n
                                        \n
                                      • Works consistently across multiple Kubernetes providers (AWS, GKE, Azure).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                      • \u2705 Advanced Traffic Management<\/strong>\n
                                          \n
                                        • Multi-protocol support (HTTP, HTTPS, TCP, UDP).<\/li>\n\n\n\n
                                        • Rich routing capabilities: header-based, weighted, and path-based routing.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                        • \u2705 Role-based Access Control (RBAC)<\/strong>\n
                                            \n
                                          • Separate Gateway and Route resources allowing multiple teams to securely manage traffic.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                          • \u2705 Multi-tenant Friendly<\/strong>\n
                                              \n
                                            • Clear separation between infrastructure operators (Gateways) and application developers (Routes).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                            • \u2705 Extensible & Portable<\/strong>\n
                                                \n
                                              • Clear APIs enable easy extension and interoperability across environments.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                                                \n\n\n\n
                                                \ud83d\ude80 Controllers Supporting Gateway API:<\/strong><\/h2>\n\n\n\n
                                                  \n
                                                • AWS Gateway API Controller (ALB integration)<\/strong><\/li>\n\n\n\n
                                                • Istio Gateway<\/strong><\/li>\n\n\n\n
                                                • Traefik Gateway API Controller<\/strong><\/li>\n\n\n\n
                                                • Contour (Envoy-based)<\/strong><\/li>\n\n\n\n
                                                • Ambassador Edge Stack<\/strong><\/li>\n\n\n\n
                                                • GKE Gateway Controller<\/strong> (Google Kubernetes Engine)<\/em><\/li>\n<\/ul>\n\n\n\n
                                                  \n\n\n\n
                                                  \ud83d\udd04 Ingress vs. Gateway API (Summary)<\/strong><\/h2>\n\n\n\n
                                                  Feature<\/th>Ingress Resource (Legacy)<\/th>Gateway API (Modern)<\/th><\/tr><\/thead>
                                                  Routing<\/td>HTTP\/HTTPS only<\/td>HTTP, HTTPS, TCP, UDP, gRPC, etc.<\/td><\/tr>
                                                  Multi-protocol Support<\/td>Limited<\/td>Extensive<\/td><\/tr>
                                                  Advanced Routing Rules<\/td>Limited (annotations required)<\/td>Rich, explicit API<\/td><\/tr>
                                                  Role Separation & Security<\/td>Limited<\/td>Explicit (Gateway & Routes)<\/td><\/tr>
                                                  Vendor neutrality<\/td>Poor (annotations)<\/td>Strong (standardized APIs)<\/td><\/tr>
                                                  Extensibility<\/td>Limited<\/td>High (designed to be extensible)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                  \n\n\n\n
                                                  \u2705 When Should You Use Gateway API?<\/strong><\/h2>\n\n\n\n
                                                    \n
                                                  • You’re running modern, production-level Kubernetes environments.<\/li>\n\n\n\n
                                                  • You require advanced routing, security, observability, and multi-protocol support.<\/li>\n\n\n\n
                                                  • You want clear role separation (RBAC) between infrastructure teams and developers.<\/li>\n\n\n\n
                                                  • You’re looking for a standardized approach compatible with multiple Kubernetes providers.<\/li>\n<\/ul>\n\n\n\n
                                                    \n\n\n\n
                                                    \ud83c\udfaf Quick Practical Example (Complete)<\/strong>:<\/h2>\n\n\n
                                                    # GatewayClass<\/span>\napiVersion: gateway.networking.k8s.io\/v1\nkind: GatewayClass\nmetadata:\n  name: external-lb\nspec:\n  controller: example.io\/gateway-controller\n\n---\n# Gateway<\/span>\napiVersion: gateway.networking.k8s.io\/v1\nkind: Gateway\nmetadata:\n  name: my-gateway\nspec:\n  gatewayClassName: external-lb\n  listeners:\n  - protocol: HTTPS\n    port: 443<\/span>\n    name: https\n    tls:\n      mode: Terminate\n      certificateRefs:\n      - name: example-cert\n\n---\n# HTTPRoute<\/span>\napiVersion: gateway.networking.k8s.io\/v1\nkind: HTTPRoute\nmetadata:\n  name: frontend-route\nspec:\n  parentRefs:\n  - name: my-gateway\n  hostnames:\n  - \"example.com\"<\/span>\n  rules:\n  - matches:\n    - path:\n        type: PathPrefix\n        value: \"\/\"<\/span>\n    backendRefs:\n    - name: frontend-service\n      port: 80<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                    This simple example clearly demonstrates how Gateway API is structured and how components interact.<\/p>\n\n\n\n
                                                    \n\n\n\n
                                                    \ud83d\udcdd Summary (One-line):<\/strong><\/h2>\n\n\n\n
                                                    Gateway API<\/strong> is the modern Kubernetes standard for flexible, secure, and advanced multi-protocol traffic routing and management in Kubernetes.<\/p>\n\n\n\n
                                                    That’s the Kubernetes Gateway API explained practically, clearly, and comprehensively!<\/p>\n\n\n\n
                                                    \n
                                                    \"\"<\/figure>\n<\/figure>\n\n\n\n
                                                    \n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n\n\n\n
                                                    \"\"<\/figure>\n<\/figure>\n","protected":false},"excerpt":{"rendered":"
                                                    Yes, the Kubernetes Gateway API is intended to be an evolution and successor to the traditional Ingress API in Kubernetes. First lets understand the differnce between ingress vs egress traffic Ingress = something from outside coming in Egress = something from inside going out Now, Lets understand what are the ingress options we have in…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_joinchat":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-48797","post","type-post","status-publish","format-standard","hentry","category-uncategorised"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/48797","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=48797"}],"version-history":[{"count":6,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/48797\/revisions"}],"predecessor-version":[{"id":58926,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/48797\/revisions\/58926"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=48797"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=48797"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=48797"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}