Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To deploy a microservice application on Google Kubernetes Engine (GKE), create a Google Cloud project, enable billing and the required APIs, provision a cluster, connect kubectl, deploy the application’s container images and Kubernetes resources, then expose and verify the services that need network access. This walkthrough uses GKE Autopilot for the cluster example and distinguishes a single-container smoke test from a real multi-service deployment.
Before you create the cluster
This is a learning deployment, not a production architecture. You need a Google Cloud project with billing enabled, the GKE API enabled, and an identity with permission to provision and administer the resources involved. If your application images are in Artifact Registry, enable that API and ensure the cluster can access the images. Google’s GKE quickstart is aimed at operators and developers who provision cloud resources and deploy apps and services.
Cloud Shell is a convenient starting point: it includes the Google Cloud CLI and kubectl. Confirm the project selected in the CLI before running commands; cluster creation, deployment, and billing all apply to the active project.
gcloud config get-value projectIf the result is not the project you intend to use, select the correct one:
#1 Best Overall
gcloud config set project PROJECT_IDReplace PROJECT_ID with your project’s actual ID. Enable billing for that project and enable the GKE API if it is not already enabled. Use an account with the permissions required by your organization’s IAM policies; the exact roles depend on how the project and cluster are administered.
Choose a GKE mode and location
For a first deployment, Autopilot reduces the amount of cluster and node configuration you manage. Google recommends Autopilot for most production use cases, but that is not a universal rule: workload, network, and operational requirements should determine the mode. Standard is the alternative when you need more direct control over cluster and node configuration. See Google’s Autopilot overview and cluster types documentation for the current distinctions.
| Choice | What it means | Consider it when |
|---|---|---|
| Autopilot | Google manages more cluster configuration and node provisioning. | You want a simpler operational starting point and the workload fits Autopilot’s capabilities. |
| Standard | You manage more of the cluster and node configuration. | Your workload or operating model needs the additional control and you can manage it. |
The command below follows Google’s documented Autopilot quickstart pattern and uses us-central1 as an example region. Choose a location that fits your latency, availability, compliance, and networking needs rather than copying the example by default.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutegcloud container clusters create-auto hello-cluster --location=us-central1Cluster creation provisions cloud resources and can take several minutes. Production deployments need deliberate network design: Google cautions that deploying your own applications requires more careful IP address planning than tutorial defaults provide.
Rank #2
Connect kubectl to the cluster
After creation, fetch credentials using the cluster name and location you actually chose. This updates the local Kubernetes configuration so commands such as kubectl get pods and kubectl apply target that cluster.
gcloud container clusters get-credentials hello-cluster --location=us-central1Before applying resources, check the active context so you do not accidentally deploy to a different cluster:
kubectl config current-contextDeploy an application
A Kubernetes Deployment manages a set of Pods for an application workload; each Pod runs one or more containers. A single Deployment is useful for checking that the cluster can run an image, but it is not by itself a multi-service microservice application.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Option 1: Run a single-workload smoke test
Google’s quickstart deploys the versioned hello-app:1.0 sample image from Artifact Registry:
kubectl create deployment hello-app --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0This creates a Deployment and its Pod from the specified image. It is a quick way to verify a basic workload, not an example of service-to-service communication in a multi-service system.
Option 2: Apply manifests for a multi-service application
For a real microservice application, build or otherwise obtain each service’s container image, push the images to a registry such as Artifact Registry, and make each Kubernetes Deployment refer to the correct image path and version. Keep configuration, secrets, ports, probes, and resource requests appropriate to each service; the hello-app command does not supply these application-specific settings.
Apply the Kubernetes manifests that define the Deployments and Services together, for example:
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitcheskubectl apply -f ./k8s/The directory and manifest names are examples: use the path and resource definitions in your application. Google’s Cymbal Books microservices tutorial demonstrates a multi-module application with Artifact Registry images and Kubernetes resources including Services, Deployments, and Pods. Kubernetes Service names provide stable in-cluster addresses that application modules can use to reach one another; configure each service to listen on the expected port and use the appropriate Service name.
Rank #4
After applying resources, inspect their status and address errors such as an unavailable image, incorrect image path, failed container startup, or mismatched ports:
kubectl get deployments,pods,servicesMake the service reachable and verify it
Pods and Deployments do not automatically create a public endpoint. For the hello-app smoke test, the quickstart exposes the Deployment with a Kubernetes Service of type LoadBalancer:
kubectl expose deployment hello-app --type=LoadBalancer --port=80 --target-port=8080This maps external port 80 to the application’s port 8080 and requests a Compute Engine load balancer. Check the Service for an assigned external IP:
kubectl get service hello-appIf the external IP shows as <pending>, allow time for Google Cloud to provision the network resources, then check again. Once an address appears, open it in a browser using HTTP, or test it with a client. For a multi-service app, expose only the entry point that needs external traffic; internal-only services can remain reachable through their Kubernetes Service names within the cluster.
A public LoadBalancer endpoint is one option, not the default answer for every production application. Choose an ingress and network security design based on which users and systems need access, and account for the load balancer’s separate charges.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Understand the main costs
As of Google Cloud’s pricing page accessed in 2026, GKE lists a cluster management fee of $0.10 per cluster per hour across cluster modes and topologies. The same page lists a $74.40 monthly GKE free-tier credit per billing account, described as equivalent to one Autopilot or zonal Standard cluster per month. That credit does not cover every charge: it does not cover compute charges, and it does not cover the cluster fee for regional clusters. See GKE pricing for current terms.
These figures are not a guaranteed total for a deployment. VM or other compute resources, a LoadBalancer Service’s Compute Engine load balancer, location, workload size, and time running can change the bill. Estimate the configuration using Google Cloud’s current pricing page or calculator, and check actual project billing after deployment.
Remove learning resources when finished
Deleting the LoadBalancer Service removes the load balancer created for it. Then delete the cluster if you no longer need it:
kubectl delete service hello-app
gcloud container clusters delete hello-cluster --location=us-central1Use the matching Service, cluster name, and location if you chose different values. If you created a dedicated project solely for this exercise and have confirmed it contains nothing else you need, deleting that project is another cleanup option. Verify that no remaining resources in the project can continue generating charges.
Choose the right deployment path for your workload
GKE or Cloud Run?
GKE is a Kubernetes platform suited to workloads that need Kubernetes resources, more infrastructure control, stateful services, or coordination among complex microservices. Cloud Run can be a simpler fit for stateless request- or event-driven services where a managed, pay-per-use execution model matches the workload. Compare the infrastructure control you need, scaling behavior, runtime requirements, and pricing model rather than choosing only by familiarity. Google’s Cloud Run overview explains that service’s model.
Console, CLI, or Terraform?
The Google Cloud Console can help newcomers see resource settings and status; the CLI makes the tutorial sequence explicit and repeatable from a shell. Terraform is an infrastructure-as-code option when cluster configuration should be declared, reviewed, and recreated consistently. Google documents GKE provisioning with Terraform. These methods can complement one another, but avoid managing the same infrastructure independently in multiple places without a clear ownership plan.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
