GKE Ingress with Load Balancer in GCP - Deep Dive

Overview - GKE Ingress with Load Balancer

What is it?

GKE Ingress with Load Balancer is a way to manage external access to services running inside a Google Kubernetes Engine cluster. It uses an Ingress resource to define rules for routing traffic and automatically creates a Google Cloud Load Balancer to distribute incoming requests. This setup helps expose your applications to the internet securely and efficiently.

Why it matters

Without GKE Ingress and Load Balancers, exposing multiple services would require manual setup of many external IPs and load balancers, which is complex and costly. This concept simplifies managing traffic, improves scalability, and ensures high availability for applications. It makes cloud applications easier to reach and maintain.

Where it fits

Before learning this, you should understand basic Kubernetes concepts like Pods, Services, and Deployments. After this, you can explore advanced traffic management with Ingress controllers, security with HTTPS and TLS, and autoscaling of services.

Mental Model

Core Idea

GKE Ingress with Load Balancer acts as a smart traffic director that listens at one point and sends requests to the right service inside the cluster.

Think of it like...

Imagine a receptionist in a large office building who receives all visitors at the front desk and directs each visitor to the correct department based on their purpose.

┌─────────────────────────────┐
│       External Traffic       │
└──────────────┬──────────────┘
               │
       ┌───────▼────────┐
       │  Google Cloud  │
       │ Load Balancer  │
       └───────┬────────┘
               │
       ┌───────▼────────┐
       │  GKE Ingress   │
       │ (Traffic Rules)│
       └───────┬────────┘
               │
   ┌───────────▼───────────┐
   │  Kubernetes Services  │
   │  (Pods & Deployments) │
   └───────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Kubernetes Services

Concept: Learn what Kubernetes Services are and how they expose Pods inside a cluster.

Kubernetes Services provide stable IP addresses and DNS names to Pods, which can change dynamically. They allow communication inside the cluster and can expose Pods to external traffic using types like ClusterIP, NodePort, and LoadBalancer.

Result

You understand how services group Pods and provide access points inside and outside the cluster.

Knowing Services is essential because Ingress depends on them to route traffic to the right Pods.

2

Foundation

What is an Ingress Resource?

Concept: Introduce the Ingress resource as a way to define rules for routing external HTTP(S) traffic to Services.

Ingress is a Kubernetes object that lets you configure how external requests reach your Services. It defines rules like hostnames and paths to decide which Service handles a request. Ingress itself does not handle traffic; it needs an Ingress controller.

Result

You can write simple rules to route traffic to different services based on URLs or hostnames.

Ingress centralizes traffic management, reducing the need for multiple external IPs or load balancers.

3

Intermediate

Role of the Ingress Controller

🤔Before reading on: do you think Ingress alone can route traffic, or does it need another component? Commit to your answer.

Concept: Explain that an Ingress controller is a component that watches Ingress resources and configures the actual load balancer to route traffic accordingly.

The Ingress controller runs inside the cluster and listens for changes to Ingress resources. For GKE, the default controller integrates with Google Cloud Load Balancer. When you create an Ingress, the controller creates or updates a Load Balancer to match the rules.

Result

Traffic sent to the Load Balancer is routed to the correct Service based on Ingress rules.

Understanding the controller's role clarifies why Ingress is declarative but needs a controller to work.

4

Intermediate

How GKE Creates the Load Balancer

🤔Before reading on: do you think the Load Balancer is created manually or automatically when you apply an Ingress? Commit to your answer.

Concept: Describe how GKE automatically provisions a Google Cloud Load Balancer when an Ingress resource is applied.

When you apply an Ingress in GKE, the Ingress controller talks to Google Cloud APIs to create a Load Balancer. It sets up forwarding rules, backend services, health checks, and firewall rules. This process is automatic and managed by GKE.

Result

You get a public IP and a Load Balancer that routes traffic to your cluster services without manual cloud setup.

Knowing this automation helps you trust that your Ingress rules translate into real, working infrastructure.

5

Intermediate

Configuring Path and Host Rules

🤔Before reading on: do you think Ingress can route traffic based on URL paths, hostnames, or both? Commit to your answer.

Concept: Teach how to write Ingress rules that route traffic based on hostnames and URL paths to different services.

Ingress rules can specify hosts (like example.com) and paths (like /app1 or /app2). Requests matching these rules are sent to the corresponding backend service. This allows multiple apps to share one IP and Load Balancer.

Result

You can expose multiple services under one IP with different URLs or domains.

This flexibility reduces costs and simplifies DNS management for multiple applications.

6

Advanced

Securing Ingress with TLS Certificates

🤔Before reading on: do you think TLS certificates are managed automatically or require manual setup in GKE Ingress? Commit to your answer.

Concept: Explain how to enable HTTPS by configuring TLS certificates in Ingress, including using Google-managed certificates.

You can add TLS blocks in your Ingress manifest to specify certificates for your domains. GKE supports Google-managed certificates that automatically renew. This secures traffic between users and the Load Balancer with encryption.

Result

Your applications are accessible securely over HTTPS without manual certificate management.

Understanding TLS integration is key to protecting user data and meeting security standards.

7

Expert

Advanced Load Balancer Features and Limitations

🤔Before reading on: do you think GKE Ingress supports all Google Cloud Load Balancer features by default? Commit to your answer.

Concept: Discuss advanced features like custom health checks, backend timeouts, and limitations such as lack of support for some protocols or complex routing.

GKE Ingress supports many Load Balancer features but has limits. For example, it mainly supports HTTP(S) traffic, not TCP or UDP. Customizing backend settings requires annotations. Understanding these helps design robust systems and know when to use alternatives like Service type LoadBalancer or custom proxies.

Result

You can optimize your Load Balancer setup and avoid surprises in production.

Knowing these details prevents misconfigurations and helps choose the right tool for complex needs.

Under the Hood

The GKE Ingress controller continuously watches Kubernetes API for Ingress resource changes. When it detects a new or updated Ingress, it translates the rules into Google Cloud Load Balancer configuration via Google Cloud APIs. This includes creating forwarding rules, backend services linked to Kubernetes Services, health checks to monitor Pod readiness, and firewall rules to allow traffic. The Load Balancer then routes external traffic to the cluster nodes, which forward it to the correct Pods.

Why designed this way?

This design separates declarative traffic rules (Ingress) from the actual traffic handling (Load Balancer), allowing Kubernetes to manage application logic while Google Cloud manages scalable, reliable networking. It avoids manual cloud setup and leverages Google's global infrastructure. Alternatives like manual Load Balancer setup were complex and error-prone, so automation improves developer productivity and system reliability.

┌───────────────────────────────┐
│ Kubernetes API Server          │
│ (Stores Ingress resource)     │
└───────────────┬───────────────┘
                │
      Watches Ingress changes
                │
┌───────────────▼───────────────┐
│ GKE Ingress Controller         │
│ (Runs inside cluster)          │
│ Translates Ingress to GCP API  │
└───────────────┬───────────────┘
                │
      Calls Google Cloud APIs
                │
┌───────────────▼───────────────┐
│ Google Cloud Load Balancer     │
│ (Forwarding rules, backends)   │
└───────────────┬───────────────┘
                │
       Routes traffic to Nodes
                │
┌───────────────▼───────────────┐
│ Kubernetes Nodes & Pods        │
│ (Runs application containers) │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does creating an Ingress automatically expose your service on the internet? Commit to yes or no.

Common Belief: Creating an Ingress resource alone exposes your service externally without any other setup.

Reality: Ingress requires an Ingress controller to be running in the cluster to actually create and manage the Load Balancer that exposes services.

Why it matters: Without the controller, your Ingress rules do nothing, leading to confusion and inaccessible services.

Quick: Can GKE Ingress handle TCP or UDP traffic by default? Commit to yes or no.

Common Belief: GKE Ingress can route any type of network traffic, including TCP and UDP.

Reality: GKE Ingress primarily supports HTTP and HTTPS traffic. TCP/UDP require other solutions like Service type LoadBalancer or custom proxies.

Why it matters: Trying to use Ingress for unsupported protocols causes failures and wasted troubleshooting time.

Quick: Does the Load Balancer created by GKE Ingress have a static IP by default? Commit to yes or no.

Common Belief: The Load Balancer IP address is always static and never changes once created.

Reality: By default, the IP is ephemeral unless you reserve a static IP and specify it in the Ingress configuration.

Why it matters: Assuming a static IP without reserving it can break DNS and client connections if the IP changes.

Quick: Is it possible to have multiple Ingress controllers in one GKE cluster? Commit to yes or no.

Common Belief: You can only have one Ingress controller per cluster.

Reality: You can run multiple Ingress controllers in a cluster, each managing different Ingress resources or namespaces.

Why it matters: Knowing this allows advanced traffic management and multi-team setups without conflicts.

Expert Zone

1

GKE Ingress annotations control subtle Load Balancer behaviors like timeout settings, connection draining, and backend protocol, which are not obvious from the Ingress spec alone.

2

The Ingress controller reconciles state asynchronously, so changes may take minutes to reflect, which can confuse debugging if not understood.

3

Google-managed certificates simplify TLS but have limits on supported domains and renewal timing, requiring fallback plans for critical applications.

When NOT to use

Avoid GKE Ingress when you need to expose non-HTTP(S) protocols like TCP or UDP, or require advanced Layer 7 features not supported by the default controller. Instead, use Service type LoadBalancer, Network Load Balancers, or custom proxies like Envoy or Istio.

Production Patterns

In production, teams use Ingress with path-based routing to consolidate multiple microservices under one IP. They combine it with Google-managed certificates for HTTPS and use annotations to tune performance. For complex needs, they deploy multiple Ingress controllers or service meshes alongside Ingress.

Connections

Reverse Proxy

GKE Ingress acts like a reverse proxy by routing client requests to backend services.

Understanding reverse proxies in web servers helps grasp how Ingress manages traffic routing and load balancing.

DNS (Domain Name System)

Ingress relies on DNS to map domain names to the Load Balancer's IP address.

Knowing DNS fundamentals clarifies how users reach services exposed by Ingress and why static IPs matter.

Traffic Control in Road Networks

Ingress and Load Balancer direct traffic like traffic lights and signs control cars on roads.

This cross-domain view helps understand traffic routing, congestion management, and failover in networks.

Common Pitfalls

#1 Not running an Ingress controller after creating Ingress resources.

Wrong approach:

kubectl apply -f ingress.yaml
# No Ingress controller installed or running

Correct approach:

kubectl apply -f ingress.yaml
# Ensure GKE Ingress controller is enabled or install a compatible controller

Root cause:

Misunderstanding that Ingress is just a resource and requires a controller to function.

#2 Using Ingress to expose TCP services directly.

Wrong approach:

apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
rules:
- host: tcp.example.com
http:
paths:
- path: /
backend:
service:
name: tcp-service
port:
number: 3306

Correct approach:

Use Service type LoadBalancer for TCP:
apiVersion: v1
kind: Service
spec:
type: LoadBalancer
ports:
- port: 3306
protocol: TCP
selector:
app: tcp-service

Root cause:

Confusing Ingress as a universal load balancer instead of HTTP(S) traffic only.

#3 Not reserving a static IP for the Load Balancer and relying on ephemeral IP.

Wrong approach:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
service:
name: my-service
port:
number: 80

Correct approach:

Reserve a static IP and specify it:
gcloud compute addresses create my-static-ip --global

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.global-static-ip-name: my-static-ip
spec:
backend:
service:
name: my-service
port:
number: 80

Root cause:

Not understanding IP lifecycle and its impact on DNS and client connections.

Key Takeaways

GKE Ingress with Load Balancer simplifies exposing multiple Kubernetes services through a single external IP and domain.

Ingress resources define routing rules, but an Ingress controller is required to implement those rules by managing the Google Cloud Load Balancer.

Load Balancers created by GKE Ingress handle HTTP(S) traffic and can be secured with TLS certificates, including Google-managed ones.

Understanding the automation and limitations of GKE Ingress helps design scalable, secure, and maintainable cloud applications.

Advanced users must know how to tune Load Balancer settings, handle asynchronous updates, and choose alternatives for non-HTTP protocols.