Skip to main content
In this lesson, you’ll learn how to expose your containerized application on Google Kubernetes Engine (GKE) by extending your existing Deployment manifest with a Service resource. By the end of this sprint, you’ll be able to access your app through a stable, load-balanced endpoint.

Prerequisites

  • A running GKE cluster
  • kubectl configured to point at your GKE cluster
  • An existing gke-deployment.yaml that successfully deploys your container
Previously, we deployed our container to GKE, but the application wasn’t reachable from outside the cluster.
The image shows a YAML file icon with an arrow pointing to a diagram of a person, symbolizing the extension of a gke.yaml file to include code for exposing an application via an endpoint.

Why You Need a Service

A Kubernetes Service
  • Provides a stable IP or DNS name for your Pods
  • Handles load balancing across Pod replicas
  • Supports multiple types of exposure (ClusterIP, NodePort, LoadBalancer)
A Service decouples the network policy from your Pods. Even if your Pods get rescheduled or replaced, the Service IP/DNS remains constant.

Comparing Service Types

For GKE, LoadBalancer is the most straightforward way to get an external IP.

Updating gke-deployment.yaml

Add the following Service manifest below your existing Deployment spec in gke-deployment.yaml:
Then apply the changes:
Run kubectl get svc my-app-service to retrieve the external IP:
Your application is now accessible at http://34.68.12.34.
Provisioning a LoadBalancer can incur additional GCP costs. Be sure to delete unused Services when you’re done.

Watch Video