Bird
Raised Fist0
GCPcloud~5 mins

GKE Ingress with Load Balancer in GCP - Commands & Configuration

Choose your learning style10 modes available
Introduction
When you run apps on Google Kubernetes Engine, you often want to let users access them from the internet. GKE Ingress with Load Balancer helps by directing internet traffic to your app safely and efficiently.
When you want to expose a web app running in GKE to users on the internet.
When you need to balance traffic between multiple copies of your app for better speed and reliability.
When you want to use a single IP address to route traffic to different services inside your cluster.
When you want Google Cloud to automatically create and manage a load balancer for your app.
When you want to use HTTPS with automatic certificate management for your app.
Config File - ingress.yaml
ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - host: example-app.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

This file defines an Ingress resource for GKE.

apiVersion and kind specify this is an Ingress.

metadata includes the name and an annotation telling GKE to use the Google Cloud load balancer.

spec defines rules: traffic to example-app.com on any path goes to the Kubernetes service named example-service on port 80.

Commands
This command creates the Ingress resource in your GKE cluster. It tells GKE to set up a load balancer to route traffic to your app.
Terminal
kubectl apply -f ingress.yaml
Expected OutputExpected
ingress.networking.k8s.io/example-ingress created
This command checks the status of the Ingress and shows the external IP address assigned by Google Cloud load balancer.
Terminal
kubectl get ingress example-ingress
Expected OutputExpected
NAME CLASS HOSTS ADDRESS PORTS AGE example-ingress gce example-app.com 34.123.45.67 80 1m
This command shows detailed information about the Ingress, including backend services and events to help troubleshoot if needed.
Terminal
kubectl describe ingress example-ingress
Expected OutputExpected
Name: example-ingress Namespace: default Address: 34.123.45.67 Default backend: <none> Rules: Host Path Backends ---- ---- -------- example-app.com / example-service:80 Annotations: kubernetes.io/ingress.class: gce Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal CREATE 2m loadbalancer-controller Ingress example-ingress
Key Concept

If you remember nothing else from this pattern, remember: GKE Ingress creates a Google Cloud load balancer that routes internet traffic to your Kubernetes services.

Common Mistakes
Not adding the annotation 'kubernetes.io/ingress.class: "gce"' in the Ingress metadata.
Without this annotation, GKE does not know to create a Google Cloud load balancer for your Ingress.
Always include the annotation 'kubernetes.io/ingress.class: "gce"' in your Ingress metadata.
Using a service name or port that does not exist in the cluster.
The load balancer cannot route traffic if the backend service is missing or misconfigured, causing errors.
Verify your service exists and the port number matches before creating the Ingress.
Checking Ingress status immediately after creation without waiting for the external IP.
It takes some time for Google Cloud to provision the load balancer and assign an IP, so the ADDRESS field may be empty at first.
Wait a few minutes and run 'kubectl get ingress' again to see the external IP.
Summary
Create an Ingress YAML file that defines rules to route traffic from the internet to your Kubernetes service.
Apply the Ingress with 'kubectl apply -f ingress.yaml' to create the load balancer in Google Cloud.
Use 'kubectl get ingress' and 'kubectl describe ingress' to check the load balancer's external IP and details.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard