GKE Ingress with Load Balancer in GCP - Mini Project: Build & Apply

GKE Ingress with Load Balancer

📖 Scenario: You are managing a Kubernetes cluster on Google Cloud Platform (GCP). You want to expose your application to the internet using a Load Balancer. To do this, you will create an Ingress resource in Google Kubernetes Engine (GKE) that automatically provisions a Google Cloud Load Balancer.This project will guide you step-by-step to create a simple web application deployment, configure a service, set up an Ingress resource, and verify the Load Balancer is working.

🎯 Goal: Build a GKE Ingress resource that exposes a web application through a Google Cloud Load Balancer. You will create a deployment, a service, and an ingress resource with the correct annotations and rules.

📋 What You'll Learn

Create a Kubernetes deployment named webapp with the image nginx:1.23 and 2 replicas

Create a service named webapp-service of type NodePort exposing port 80

Create an Ingress resource named webapp-ingress that routes HTTP traffic to webapp-service

Use the annotation kubernetes.io/ingress.class: "gce" to specify the GCP Load Balancer

Print the Ingress resource details to verify the Load Balancer IP

💡 Why This Matters

🌍 Real World

In real projects, exposing applications securely and reliably to the internet is essential. GKE Ingress with Load Balancer automates this process on Google Cloud.

💼 Career

Understanding how to configure GKE Ingress and Load Balancers is a key skill for cloud engineers and DevOps professionals working with Kubernetes on GCP.

1

Create the Deployment

Create a Kubernetes deployment named webapp with 2 replicas using the image nginx:1.23. Use the command kubectl create deployment webapp --image=nginx:1.23 --replicas=2.

GCP

# Create the deployment with 2 replicas and nginx:1.23 image
# Your code here

Hint

Use kubectl create deployment with the exact name webapp, image nginx:1.23, and replicas set to 2.

2

Create the Service

Create a service named webapp-service of type NodePort that exposes port 80 and targets the webapp deployment. Use the command kubectl expose deployment webapp --name=webapp-service --type=NodePort --port=80.

GCP

kubectl create deployment webapp --image=nginx:1.23 --replicas=2
# Create the NodePort service exposing port 80
# Your code here

Hint

Use kubectl expose deployment with the exact service name webapp-service, type NodePort, and port 80.

3

Create the Ingress Resource

Create an Ingress resource named webapp-ingress with the annotation kubernetes.io/ingress.class: "gce" that routes HTTP traffic to the webapp-service on port 80. Use the following YAML manifest and apply it with kubectl apply -f webapp-ingress.yaml.

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

GCP

kubectl create deployment webapp --image=nginx:1.23 --replicas=2
kubectl expose deployment webapp --name=webapp-service --type=NodePort --port=80
# Create the Ingress resource with annotation kubernetes.io/ingress.class: "gce"
# Your code here

Hint

Create a YAML file named webapp-ingress.yaml with the exact Ingress resource content and apply it using kubectl apply -f webapp-ingress.yaml.

4

Verify the Load Balancer IP

Run kubectl get ingress webapp-ingress to display the Ingress resource details and print the external IP address of the Load Balancer.

GCP

kubectl create deployment webapp --image=nginx:1.23 --replicas=2
kubectl expose deployment webapp --name=webapp-service --type=NodePort --port=80

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

kubectl apply -f webapp-ingress.yaml
# Run the command to get the ingress details and print the external IP
# Your code here

Hint

Use kubectl get ingress webapp-ingress to see the external IP address under the ADDRESS column.

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