Kubernetes Ingress部署位置及GKE、AWS负载均衡差异问询

Great questions—let's break these down clearly, since there's a bit of nuance here depending on your setup:

1. Are Kubernetes Ingress objects deployed in the cluster? #

Absolutely. An Ingress is a core Kubernetes API object, meaning it's stored as a resource in your cluster's etcd datastore—right alongside Deployments, Services, and Pods. That said, an Ingress object on its own doesn't do anything: you need an Ingress Controller (a running Pod/Deployment inside your cluster) to implement the routing rules defined in the Ingress. Without a controller, the Ingress is just a static configuration sitting in the API server, waiting for something to act on it.

2. Load Balancer Placement & Cloud Provider Differences (GKE vs AWS) #

This depends entirely on the Ingress Controller you're using, and yes, there are distinct cloud-provider-specific behaviors. Let's break it down for each platform:

Google Kubernetes Engine (GKE) #

• By default, creating an Ingress in GKE uses the managed GKE Ingress Controller, which runs as Pods in your cluster (usually in the gke-system namespace).
• The actual external traffic entry point is a Google Cloud Load Balancer (GCLB)—a fully managed cloud service. The GKE Ingress Controller communicates with GCP's APIs to configure the GCLB, which routes traffic to your cluster's nodes. From there, the controller's Pods handle path-based routing to your target Services based on your Ingress rules.
• You can opt for third-party controllers (like NGINX) in GKE too. In that case, you'd typically expose the controller via a NodePort or ClusterIP (or pair it with a custom external load balancer), but the default setup relies on the managed GCLB plus cluster-internal controller Pods.

Amazon Web Services (AWS) #

• The standard AWS setup uses the AWS Load Balancer Controller (formerly the ALB Ingress Controller), which runs as Pods inside your cluster.
• When you create an Ingress with this controller, it provisions an AWS Application Load Balancer (ALB) or Network Load Balancer (NLB)—both fully managed cloud services. The controller Pods interact with AWS APIs to configure the ALB/NLB, which routes traffic to your cluster's nodes. The controller then handles routing traffic to the correct Services based on your Ingress rules.
• Like GKE, you can use third-party controllers (e.g., NGINX) here. For those, you might expose the controller via a NodePort or use an AWS NLB to direct traffic to it, but the default managed flow uses AWS's LB service paired with the cluster-internal controller.

Key Takeaway #

• The Ingress Controller (the component that interprets your Ingress rules) is almost always deployed as Pods within your cluster—whether it's the cloud provider's managed controller or a third-party option.
• The external traffic entry point (the load balancer end-users hit) is typically a managed cloud service (GCLB, ALB/NLB) from your provider. The exception is bare-metal setups, where you might use a controller like NGINX with NodePort or host networking, making the cluster nodes themselves the load balancing entry point.

内容的提问来源于stack exchange，提问作者adrpino