Deploying and implementing Google Kubernetes Engine resources

Study guide for Associate Cloud Engineer, Unit 3 · Topic 2. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Deploying and implementing Google Kubernetes Engine resources. Considerations include:

1. Installing and configuring the command line interface (CLI) for Kubernetes (kubectl)
2. Deploying a Google Kubernetes Engine cluster with different configurations (e.g., Autopilot, regional clusters, private clusters, GKE Enterprise)
3. Deploying a containerized application to Google Kubernetes Engine

Deploying and implementing GKE resources

A tool, a cluster, an application — in that order

The tool: install kubectl and point it at the right cluster. The cluster: Autopilot or Standard, regional or zonal, private nodes or not — and which of those can never change. The application: a Deployment runs it, a Service exposes it.

This topic is the hands-on half of Google Kubernetes Engine, or GKE, and its three objectives are in the order an engineer meets them. First the tool: installing and configuring kubectl, the command-line tool that manages and accesses GKE clusters, and making sure it talks to the cluster you mean. Second the cluster itself: creating one in the configuration the workload needs — Autopilot, regional, with private nodes. Third the application: deploying a container to the cluster and exposing it. What GKE is, and whether to choose Autopilot or Standard, were taught in earlier decks; here the question is always which command does it, and which setting cannot be changed once the cluster exists.

Installing and configuring kubectl

Install the tool, install its auth plugin, then give it a context

• gcloud components install kubectl, then kubectl version --client
• Also install gke-gcloud-auth-plugin — kubectl needs it to reach GKE
• kubeconfig holds contexts: cluster, user, optional namespace
• gcloud container clusters get-credentials writes a context and switches to it

Worked example (synthetic). An engineer installs kubectl on a new laptop and every command fails to find the team's cluster. The tool is fine; the laptop's kubeconfig has never been given that cluster, so get-credentials is the missing step.

The first objective is installing and configuring the command-line interface, or CLI, for Kubernetes. Installation has two parts, and the second is the one people forget. Google says you can install kubectl using the Google Cloud CLI or an external package manager such as apt or yum; with the Google Cloud CLI it is gcloud components install kubectl, and kubectl version with the client flag confirms it. Then the authentication plugin: Google is explicit that you must install the gke-gcloud-auth-plugin to use kubectl and other clients to interact with Google Kubernetes Engine, or GKE, and it installs the same way, as a gcloud component. Configuration is about kubeconfig. Kubernetes uses a YAML file called kubeconfig to store cluster authentication information, and it holds contexts — each context contains a Kubernetes cluster, a user, and an optional default namespace. The current context is the cluster that is currently the default for kubectl. The command that puts a cluster into kubeconfig is gcloud container clusters get-credentials, with the cluster name and its location, and Google notes that running it also changes the current context to that cluster.

The commands, and what each one changes

Five commands between a new machine and a working kubectl

Worked example (synthetic). A release script must deploy to a staging cluster while an engineer's shell stays pointed at production. Adding --cluster to that one command does it; get-credentials would move the whole shell.

Here are the five commands in the order a new machine needs them. Install kubectl, install the authentication plugin, then generate a context with get-credentials — which, as Google notes, also switches the current context to that cluster. To see where you are, view the current context: Google defines it as the cluster that is currently the default for kubectl, and all kubectl commands run against it. And when you need one command to go somewhere else without moving your whole session, Google says you can run individual kubectl commands against a specific cluster by using the cluster flag. The difference between the last two rows is exactly what the exam tests: get-credentials changes the default for everything that follows, and the cluster flag changes only the one command it is on.

When kubeconfig already knows the cluster, and when it does not

Where the cluster was created decides whether you need get-credentials

Figure: A flow chart. If a cluster was created with gcloud from this machine, a kubeconfig entry is added and the current context switches automatically. If it was created in the console or from another computer, this machine's kubeconfig is not updated, and get-credentials must be run, which needs the container.clusters.get permission.

Worked example (synthetic). A colleague creates a cluster from their own laptop and says it is ready. Their kubeconfig was updated; yours was not. You run get-credentials, and you need the container.clusters.get permission to do it.

This is the situation that generates most kubectl confusion, drawn out. Google says that when you create a cluster using gcloud container clusters create-auto, an entry is automatically added to the kubeconfig file in your environment and the current context changes to that cluster. So the person who ran the command is ready immediately. But when a cluster is created using the Google Cloud console, or using the gcloud command-line interface, or CLI, from a different computer, your environment's kubeconfig file is not updated. Everyone else has to run get-credentials themselves — and Google notes the permission that requires: to generate a kubeconfig context in your environment, you need the container.clusters.get permission. When the exam describes a teammate who cannot see a cluster that plainly exists, it is almost always this branch.

Deploying a cluster in the configuration you need

Autopilot, regional or zonal, private nodes — and what is permanent

• Autopilot: gcloud container clusters create-auto — always regional
• Standard: gcloud container clusters create — regional or zonal, your choice
• Regional replicates the control plane across zones; zonal has one
• Zonal and regional cannot be swapped after creation

Worked example (synthetic). A team creates a zonal Standard cluster for a pilot, then promotes the pilot to production and asks to "make it regional". It cannot be converted; the production cluster has to be created regional from the start.

The second objective asks you to deploy a Google Kubernetes Engine cluster with different configurations, and the guide names Autopilot, regional clusters, private clusters and GKE Enterprise. Start with Autopilot, because it has the fewest choices. It is created with gcloud container clusters create-auto, and Google says the minimum you need is a name, a project and a region — region, because Autopilot clusters are always regional. Standard clusters are created with gcloud container clusters create, and there you choose: regional clusters have multiple control plane replicas across multiple zones in a region, while zonal clusters have a single control plane in a single zone. Google's best practice is to use regional clusters for production workloads, because they generally offer higher availability. And the fact the exam likes most: these settings cannot be updated after creation. A zonal cluster cannot become a regional cluster, and a regional cluster cannot become a zonal cluster. The choice is made once, at the create command.

What a regional cluster actually is

A control plane replica and nodes in every zone, one endpoint in front

Figure. kubectl sends API requests to the cluster's control plane endpoint. Behind it, the region us-east1 contains three zones, us-east1-b, c and d, each holding a control plane replica and worker nodes. The callout notes that a zonal cluster has one control plane in one zone and cannot later become regional.

Worked example (synthetic). Zone us-east1-c goes down during a scheduled upgrade window. On a regional cluster the Kubernetes API stays reachable and the nodes in b and d keep serving; on a zonal cluster in us-east1-c, both would stop.

Drawn out, a regional cluster explains its own advantages. Google says regional clusters increase availability by replicating the control plane across multiple zones in a region, and that if a single zone becomes unavailable, your control plane is not impacted. The replicas also mean you can reach the Kubernetes application programming interface, or API, even during upgrades. The nodes are spread the same way: by default regional clusters are created as multi-zonal clusters, so worker nodes are distributed across multiple zones — and the default replicates each node pool across three zones of the control plane's region. kubectl never talks to a zone directly; it reaches the cluster through its control plane endpoint. Compare the callout: a zonal cluster has a single control plane instance in a single zone, so that one zone is the whole cluster's failure domain.

Three create commands, side by side

What each configuration fixes at creation

Worked example (synthetic). An engineer creates a regional Standard cluster with --num-nodes 2, expecting two nodes, and finds six. Google's own example is exactly this: three zones with two nodes each.

Side by side, the three create commands differ in one flag value and in what that value commits you to. Autopilot uses create-auto with a region, and is always regional. A regional Standard cluster uses create with a region as its location. A zonal Standard cluster uses create with a zone. One flag behaves differently than candidates expect: on a regional cluster, the number-of-nodes flag is counted per zone. Google's own example creates a regional cluster with the number of nodes set to two and describes the result as six nodes — three zones with two nodes each. And the last column repeats the rule from the previous slide because it is the one that costs the most to learn late: a zonal cluster can't become a regional cluster, so the location you pass here is permanent.

Two guide terms, in Google's current words

"Private clusters" and "GKE Enterprise" have both moved

Figure. Two cards. Private clusters are now described as network isolation with private nodes: nodes get only internal IP addresses, set with the enable-private-nodes flag, and cannot reach the internet unless NAT is enabled. GKE Enterprise's features are now part of standard GKE, a single offering without editions or tiers.

Worked example (synthetic). Nodes created with private nodes fail to pull a public image from the internet. Nothing is broken: without NAT on the cluster's network, nodes with no external IP address cannot reach the internet.

The guide names two configurations in words Google has since changed, so learn both. The guide says private clusters. Google's legacy page describes them the same way the exam does — in a private cluster, nodes only have internal internet protocol, or IP, addresses, so nodes and Pods are isolated from the internet by default. Google's current documentation frames it as network isolation: you can customize network access for the control plane and nodes to improve security, and the node half is called private nodes — provisioning nodes only with internal IP addresses so external clients cannot reach them. The flag is enable-private-nodes. The consequence to remember is on the way out, not in: workloads on nodes without an external address cannot reach the internet unless network address translation, or NAT, is enabled on the cluster's network. The guide also names GKE Enterprise. Google's archived release notes say its features have become part of the standard Google Kubernetes Engine offering, and that GKE is now a single offering without editions or tiers. On the exam, GKE Enterprise may still be the named answer; in the console, there is nothing separate to create.

Deploying a containerized application

A Deployment runs the image; a Service gives it an address

• kubectl create deployment NAME --image=IMAGE runs the container
• No image version given means the default latest tag
• kubectl expose deployment NAME --type LoadBalancer makes it reachable
• Images belong in Artifact Registry; Container Registry is shut down

Worked example (synthetic). A team deploys my-app without a version tag and later cannot tell which build is running. Google's quickstart says an untagged image pulls latest, so pinning a version like :1.0 is the fix.

The third objective is deploying a containerized application to Google Kubernetes Engine, or GKE, and Google's quickstart is the whole sequence in five commands. Create a cluster — the quickstart uses create-auto with a region. Then two Kubernetes objects. Google says Kubernetes provides the Deployment object for deploying stateless applications like web servers, and Service objects define rules and load balancing for accessing your application from the internet. The Deployment is created with kubectl create deployment and an image flag; Google notes the image flag specifies the container image to deploy, and that if you don't specify a version, the image with the default latest tag is used. The Service is created with kubectl expose deployment, and passing the type LoadBalancer flag creates a Compute Engine load balancer for your container. Where the image lives matters too: Google says Artifact Registry is the recommended service for container image storage, and that Container Registry was shut down on March 18, 2025, so writing images to it is no longer possible.

From an image to a public address

The quickstart sequence, and where it can stall

Figure: A flow chart: create an Autopilot cluster, create a Deployment from an image, expose it with a LoadBalancer Service, then read the external IP from kubectl get service. If the external IP shows pending, wait several minutes and run the command again.

Worked example (synthetic). An engineer runs kubectl get service straight after expose and sees pending, then files a ticket. Google's quickstart says the external address can take several minutes to populate.

Drawn as a sequence, the deployment has one step that looks like a failure and is not. After exposing the Deployment, you inspect the Service with kubectl get service, and Google says to copy the Service's external address from the EXTERNAL-IP column. Often it is not there yet. Google's note is plain: you might need to wait several minutes before the Service's external internet protocol, or IP, address populates, and if it shows pending, run the command again. The load balancer is being created behind that column. Cleaning up follows the same logic in reverse — Google notes that deleting the Service deletes the Compute Engine load balancer that exposing the Deployment created.

Service types, and who can reach each

The type decides whether the internet can call your Pods

Worked example (synthetic). A team exposes an API with kubectl expose but leaves out the type flag, and external users cannot reach it. The default type is ClusterIP, which is internal.

Every Service does the same basic job. Google says the idea of a Service is to group a set of Pod endpoints into a single resource, and that a Service gives you a stable internet protocol, or IP, address that lasts for the life of the Service, even as the member Pods' addresses change. What the type decides is who can use that address. ClusterIP is the default: internal clients send requests to a stable internal address. NodePort lets clients send requests to a node's address on a specified port. LoadBalancer lets clients send requests to the address of a network load balancer — which is why the quickstart passes that type to kubectl expose. The exam trap is the default: a Service created without a type is ClusterIP, and ClusterIP is internal.

What this topic actually tests

Three discriminations, three objectives

Does this machine's kubeconfig know the cluster? if not, get-credentials. Can the setting change later? zonal and regional cannot. Who can reach the app? ClusterIP by default — --type LoadBalancer for the internet.

Close on the three discriminations this topic turns on. First, whether kubectl can see a cluster: if the cluster was created in the console or on another computer, this machine's kubeconfig was not updated, and get-credentials is the fix — which also switches the current context. Second, whether a configuration can change: Autopilot clusters are always regional, and zonal and regional can never be swapped after creation, so the location in the create command is permanent. Third, who can reach the application: a Service without a type is ClusterIP and internal, and the LoadBalancer type is what gives it an internet-facing address. The next topic moves from Google Kubernetes Engine to Cloud Run and Cloud Run functions, where there is no cluster to create at all.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 3
• Install kubectl and configure cluster access
• Create an Autopilot cluster
• About cluster configuration choices
• Quickstart: Deploy an app to a GKE cluster
• Transition from Container Registry
• Regional clusters
• Create a regional cluster
• Create a zonal cluster
• Creating a private cluster (legacy)
• About network isolation in GKE
• Customize your network isolation
• GKE Enterprise release notes (archive)
• About Services