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.

Practice

1. What is the main purpose of using an Ingress with a Load Balancer in GKE?

easy

A. To restrict access to the cluster nodes only

B. To expose multiple services through a single external IP address

C. To create multiple IP addresses for each pod

D. To manage internal DNS records automatically

Solution

1. Step 1: Understand Ingress role in GKE

   Ingress allows routing external traffic to multiple services inside the cluster using one IP.

2. Step 2: Recognize Load Balancer function

   The Load Balancer created by Ingress exposes a single external IP to route traffic.

3. Final Answer:

   To expose multiple services through a single external IP address -> Option B

4. Quick Check:

   Ingress + Load Balancer = Single IP for many services [OK]

Hint: Ingress combines services under one IP address [OK]

Common Mistakes:

• Thinking each pod gets its own IP
• Confusing internal DNS with external exposure
• Assuming Load Balancer creates multiple IPs

2. Which annotation is used in a GKE Ingress resource to specify the creation of a Google Cloud HTTP(S) Load Balancer?

easy

A. cloud.google.com/load-balancer-type: 'internal'

B. kubernetes.io/ingress.class: 'nginx'

C. kubernetes.io/ingress.class: 'gce'

D. networking.gke.io/load-balancer: 'external'

Solution

1. Step 1: Identify GKE Ingress annotation for Load Balancer

   The annotation 'kubernetes.io/ingress.class: gce' tells GKE to use Google Cloud Load Balancer.

2. Step 2: Differentiate from other ingress classes

   'nginx' is for NGINX ingress controller, not GCP Load Balancer.

3. Final Answer:

   kubernetes.io/ingress.class: 'gce' -> Option C

4. Quick Check:

   Use 'gce' annotation for GCP Load Balancer [OK]

Hint: Use 'kubernetes.io/ingress.class: gce' for GCP Load Balancer [OK]

Common Mistakes:

• Using 'nginx' instead of 'gce' annotation
• Confusing internal vs external load balancer annotations
• Using non-existent annotation keys

3. Given this Ingress YAML snippet, what will happen when a user visits http://example.com/api?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

medium

A. Traffic to /api goes to api-service; all other paths go to web-service

B. Traffic to /api goes to web-service; all other paths go to api-service

C. All traffic goes to api-service regardless of path

D. Ingress will reject traffic because of conflicting paths

Solution

1. Step 1: Analyze path rules in Ingress

   The rule for path '/api' with pathType Prefix directs matching requests to 'api-service'.

2. Step 2: Understand default path routing

   The path '/' with Prefix matches all other requests and routes them to 'web-service'.

3. Final Answer:

   Traffic to /api goes to api-service; all other paths go to web-service -> Option A

4. Quick Check:

   Specific path matches first, then default [OK]

Hint: Specific paths route before general '/' path [OK]

Common Mistakes:

• Assuming '/' path overrides /api
• Thinking all traffic goes to one service
• Believing Ingress rejects overlapping paths

4. You created an Ingress with annotation kubernetes.io/ingress.class: nginx in GKE but no external IP is assigned. What is the likely cause?

medium

A. GKE does not create a Google Cloud Load Balancer for 'nginx' ingress class

B. The Ingress resource is missing the service port definition

C. The cluster nodes are not labeled correctly

D. The Ingress controller is automatically created and running

Solution

1. Step 1: Understand Ingress class annotation effect

   Annotation 'nginx' tells GKE to use NGINX ingress controller, which does not create a GCP Load Balancer automatically.

2. Step 2: Recognize Load Balancer creation requirements

   Only 'gce' ingress class triggers Google Cloud Load Balancer creation with external IP.

3. Final Answer:

   GKE does not create a Google Cloud Load Balancer for 'nginx' ingress class -> Option A

4. Quick Check:

   'nginx' ingress needs separate controller, no auto Load Balancer [OK]

Hint: Use 'gce' annotation for auto Load Balancer in GKE [OK]

Common Mistakes:

• Assuming 'nginx' creates GCP Load Balancer automatically
• Blaming missing service port for no IP
• Thinking cluster node labels affect Load Balancer creation

5. You want to expose two services, frontend and backend, on the same IP but different paths using GKE Ingress with a Load Balancer. Which YAML snippet correctly configures this?

hard

A. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
annotations:
kubernetes.io/ingress.class: "gce"
spec:
rules:
- http:
paths:
- path: /frontend
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
- path: /backend
pathType: Prefix
backend:
service:
name: backend
port:
number: 80

B. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
spec:
rules:
- host: "*"
http:
paths:
- path: /frontend
backend:
serviceName: frontend
servicePort: 80
- path: /backend
backend:
serviceName: backend
servicePort: 80

C. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
spec:
rules:
- host: example.com
http:
paths:
- path: /frontend
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
- path: /backend
pathType: Prefix
backend:
service:
name: backend
port:
number: 80

D. apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-service-ingress
annotations:
kubernetes.io/ingress.class: "gce"
spec:
rules:
- host: example.com
http:
paths:
- path: /frontend
pathType: Prefix
backend:
service:
name: frontend
port:
number: 80
- path: /backend
pathType: Prefix
backend:
service:
name: backend
port:
number: 80

Solution

1. Step 1: Confirm correct annotation for GCP Load Balancer

   Options A and D use 'kubernetes.io/ingress.class: gce', which is correct for GKE Load Balancer.

2. Step 2: Check pathType and host usage

   apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress annotations: kubernetes.io/ingress.class: "gce" spec: rules: - host: example.com http: paths: - path: /frontend pathType: Prefix backend: service: name: frontend port: number: 80 - path: /backend pathType: Prefix backend: service: name: backend port: number: 80 uses 'Prefix' pathType with a host, ensuring precise routing for /frontend and /backend paths on example.com.

3. Step 3: Identify deprecated or incorrect syntax

   apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress spec: rules: - host: "*" http: paths: - path: /frontend backend: serviceName: frontend servicePort: 80 - path: /backend backend: serviceName: backend servicePort: 80 uses deprecated 'serviceName' and 'servicePort' keys and lacks annotation; apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress annotations: kubernetes.io/ingress.class: "nginx" spec: rules: - host: example.com http: paths: - path: /frontend pathType: Prefix backend: service: name: frontend port: number: 80 - path: /backend pathType: Prefix backend: service: name: backend port: number: 80 uses 'nginx' ingress class, not GCE; apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: multi-service-ingress annotations: kubernetes.io/ingress.class: "gce" spec: rules: - http: paths: - path: /frontend pathType: Prefix backend: service: name: frontend port: number: 80 - path: /backend pathType: Prefix backend: service: name: backend port: number: 80 is missing host and incomplete.

4. Final Answer:

   Option D correctly configures two services on same IP with prefix path matching and GCE Load Balancer -> Option D

5. Quick Check:

   Use 'gce' annotation + prefix paths + host for precise multi-service routing [OK]

Hint: Use 'gce' annotation and prefix pathType for multi-service routing [OK]

Common Mistakes:

• Using 'nginx' annotation instead of 'gce'
• Using deprecated serviceName/servicePort keys
• Not specifying host or using wrong pathType