In November 2025, I came across an announcement on the Kubernetes blog – Ingress NGINX Retirement: What You Need to Know, which made me dig into how we control network traffic in Kubernetes workloads.
In this series of blog posts, I will discuss network traffic in Kubernetes clusters, both inter-cluster and intra-cluster, and the various services offered by the hyper-scale cloud providers.
In the first part of this series, I will discuss ingress (North-South) traffic to an application deployed on the Kubernetes cluster.
Terminology
Before we deep dive into the article, let's review some important concepts:
- North-South traffic: The network traffic flowing between external clients outside the cluster and services inside the Kubernetes cluster, encompassing both incoming requests and outgoing responses or API calls.
- East-West traffic: The network traffic that flows internally between services or pods within the same Kubernetes cluster, enabling communication and data exchange inside the cluster without leaving its boundary.
- Ingress Controller: A specialized software component running inside a cluster that monitors Ingress resources and manages external HTTP and HTTPS traffic by routing, load balancing, and applying the configured rules to direct incoming requests to appropriate internal services (Reference: Ingress Controllers).
- Kubernetes Gateway API: An extensible, role-oriented Kubernetes API that provides a standardized way to manage and route traffic within and into clusters (Reference: Gateway API).
- LoadBalancer: A Kubernetes LoadBalancer service exposes an application running in a cluster to external networks by provisioning an external load balancer that distributes incoming traffic to the backend Pods, typically integrating with a cloud provider’s load balancing infrastructure (Reference: Service Type).
Common Traffic Flow
A common network traffic coming from external customers into an application deployed on top of Kubernetes might look like this:
External Request → CNI (connectivity) → Network Policies (security/filtering) → Ingress Controller or Gateway API (north-south routing) → Service Mesh (east-west routing, if used) → Application.
Note: This is just an example, and not all applications are deployed using all the above-mentioned components (which we will discuss in this series of blog posts).
Ingress Controller
A Kubernetes Ingress controller is needed to efficiently manage and route external HTTP and HTTPS traffic into a Kubernetes cluster by translating Ingress resource rules into actual traffic routing, load balancing, SSL termination, and access control, providing a centralized and secure way to expose multiple services through a single-entry point.
Amazon
The Amazon EKS ingress controller service is typically the AWS ALB Ingress Controller (also known as the AWS Load Balancer Controller), which is the recommended solution for managing external HTTP/HTTPS traffic to Kubernetes services running on Amazon EKS.
Azure
Azure Application Gateway Ingress Controller (AGIC) is a Kubernetes application that enables Azure Kubernetes Service (AKS) clusters to use Azure's native Application Gateway as the ingress for external traffic.
Google Cloud Platform
The GKE (Google Kubernetes Engine) ingress controller is the default solution for managing external HTTP/HTTPS traffic to Kubernetes services running on GKE. It is also known as the GCE Ingress Controller or GKE Ingress Controller.
Here is a comparison table of the various capabilities of Ingress Controllers offered by AWS, Azure, and GCP:
Open-Source Alternatives for Ingress Controller
Other than the built-in Ingress controllers offered by AWS, Azure, and GCP, there are open-source solutions that can be integrated into a Kubernetes cluster when building a cloud-agnostic architecture. Below are some examples:
Traefik
Traefik is a modern, cloud-native reverse proxy and load balancer that also serves as a Kubernetes Ingress Controller. It acts as an in-cluster application that integrates with the Kubernetes API to automatically detect Ingress resources and dynamically configure itself to route incoming HTTP/HTTPS traffic to the appropriate backend services within the cluster.
Kong Ingress Controller (KIC)
The Kong Ingress Controller (KIC) is an open-source Kubernetes Ingress Controller that allows you to run Kong Gateway as the ingress point for your Kubernetes cluster. It works by monitoring Kubernetes resources like Ingress and Gateway API objects, then translating these into Kong Gateway configurations to manage incoming traffic. This enables routing, load balancing, and API management for services within the cluster.
Emissary-ingress (formerly Ambassador)
Emissary-ingress is an open-source Kubernetes-native API Gateway and Ingress controller built on Envoy Proxy. It acts as a scalable Layer 7 load balancer that routes traffic into Kubernetes clusters with advanced features like TLS termination, retries, circuit breakers, rate limiting, and fine-grained traffic management. Emissary-ingress supports Kubernetes Custom Resource Definitions (CRDs) such as Listener and Mapping to define routing and traffic policies more flexibly than standard Ingress resources. It integrates well with popular service meshes and supports multi-cluster environments.
Kubernetes Gateway API
The Kubernetes Gateway API is a modern, extensible Kubernetes API that provides a standardized way to manage and configure traffic routing within Kubernetes clusters. It improves on the older Ingress API by supporting advanced routing features like Layer 4 and Layer 7 protocols, cross-namespace routing, traffic splitting, and role-based management.
Amazon
The AWS Gateway API Controller for Amazon VPC Lattice is a Kubernetes controller that integrates Amazon VPC Lattice with Kubernetes, enabling users to manage service networking and routing using Kubernetes Gateway API resources. It automates provisioning of VPC Lattice service networks and routes, simplifying multi-cluster and multi-VPC service connectivity without custom code or proxies. This allows consistent, secure, and observable traffic management across clusters and accounts.
Azure
Azure Application Gateway for Containers (AGC) is a managed application load balancer for Kubernetes workloads on AKS. It runs an ALB controller inside the cluster that manages Azure Application Gateway resources based on Kubernetes Gateway API objects like Gateway and HTTPRoute. AGC provides advanced Layer 7 routing, TLS termination, autoscaling, and integrates deeply with Azure networking and security services. It enables seamless traffic management for containerized applications using native Azure infrastructure and Kubernetes-native APIs without manual configuration of the load balancer.
Google Cloud Platform
The GKE Gateway controller is Google's managed implementation of the Kubernetes Gateway API in Google Kubernetes Engine. It watches Gateway API resources in Kubernetes and provisions corresponding Google Cloud load balancers to route traffic based on those configurations. It supports single-cluster and multi-cluster Gateways, enabling scalable, flexible, and secure load balancing beyond traditional Ingress.
Here is a comparison table of the various capabilities of Kubernetes Gateway APIs offered by AWS, Azure, and GCP:
Open-Source Alternatives for Kubernetes Gateway API
Other than the built-in Kubernetes Gateway APIs offered by AWS, Azure, and GCP, there are open-source solutions that can be integrated into a Kubernetes cluster when building a cloud-agnostic architecture. Below are some examples:
Envoy Gateway
Envoy Gateway is a CNCF-hosted open-source Kubernetes-native API gateway project built on Envoy Proxy. It provides a simplified, standardized implementation of the Kubernetes Gateway API to manage ingress and routing at Layer 7 with advanced traffic control features such as rate limiting, authentication (OIDC, JWT), API key validation, and CORS handling. Envoy Gateway aims to unify existing projects like Contour and Emissary-ingress into a common core with extensibility for vendors and users.
Emissary-ingress (formerly Ambassador API Gateway)
Emissary-ingress, formerly known as Ambassador API Gateway, is an open-source, Kubernetes-native API gateway and ingress controller built on Envoy Proxy. It is a CNCF incubating project designed to route and manage incoming traffic to Kubernetes services with advanced features like TLS termination, retries, circuit breakers, rate limiting, and traffic shadowing. Emissary-ingress supports various protocols, including HTTP/3 and gRPC, and integrates natively with service meshes and multi-cluster Kubernetes environments.
Ingress Controller vs. Kubernetes Gateway API
Choosing between Kubernetes Ingress Controller and Kubernetes Gateway API depends on your cluster size, complexity, and traffic management needs:
Summary
In the first part of this series, I have explained the different alternatives for controlling ingress traffic into applications deployed on top of a Kubernetes cluster, and the various managed services offered by AWS, Azure, and GCP.
When deciding between Kubernetes Ingress Controller and Kubernetes Gateway API, choose Ingress Controller for simple, stable HTTP ingress needs with familiar tooling and ease of use. In contrast, opt for Gateway API if your environment requires advanced traffic features, multi-team support, protocol-agnostic routing, and a standardized, extensible API for modern multi-protocol workloads. Gateway API provides enhanced flexibility, scalability, and portability, making it the future-proof choice for complex Kubernetes networking scenarios.
In the second part of this series, I will explain how to control not just ingress and egress traffic, but also how to control traffic between different Pods within the same Kubernetes cluster – stay tuned.
Disclaimer: AI tools were used to research and edit this article. Graphics are created using AI.
About the author
Eyal Estrin is a seasoned cloud and information security architect, AWS Community Builder, and author of Cloud Security Handbook and Security for Cloud Native Applications. With over 25 years of experience in the IT industry, he brings deep expertise to his work.
Connect with Eyal on social media: https://linktr.ee/eyalestrin.
The opinions expressed here are his own and do not reflect those of his employer.
Top comments (0)