Deploying Containerized Applications on GKE

Configuration of Kubernetes Manifests and Resource Management is how a containerized application is described, placed, and configured on Google Kubernetes Engine (GKE) (opens in a new tab) without rebuilding its image. A manifest is a declarative file that states the desired Kubernetes resources, including replica count, update strategy, compute requests, and injected configuration. The same workflow separates the immutable container image from environment-specific settings so the tested image can move across environments.

1.1Kubernetes Deployment Manifests

A Kubernetes deployment manifest is a declarative file based on the Kubernetes Resource Model (KRM) that states the desired state of an application. The application repository typically holds the kubectl configuration or Helm chart, an Application resource with properties such as type, version, and maintainers, and provider scripts for deployment. To change behavior such as replica count or update strategy, the team edits the kubectl configuration or Helm chart before applying it to the cluster.

Manifests flow from source control to the cluster through the Kubernetes API, which administers, scales, and monitors workloads. Tools such as Cloud Build (opens in a new tab) with the gke-deploy builder apply Google recommended practices by updating the resource file to use the image digest instead of a tag, adding recommended labels, retrieving credentials for target clusters, and waiting until submitted resources are ready. Namespaces divide cluster resources among teams, an app instance name must be unique within its namespace, and namespaces ending in -system are reserved for GKE components and cannot host applications.

1.2Resource Requests and Cluster Utilization

Resource management in GKE centers on how Pods, which are sets of containers, are placed onto nodes, which are Compute Engine virtual machines grouped to form a cluster. The Kubernetes control plane runs the API server and system controllers on Google-operated instances, so operations staff focus on applications while Google manages scheduling and system components. Because containers decouple applications from host infrastructure, the same Pod definition can run across cloud, on-premises, hybrid, and multicloud environments at a higher level of abstraction than virtual machines alone.

Cluster utilization and cost depend on the relationship between what running Pods request and what nodes provide. GKE Autopilot manages nodes, scaling, and security for the customer, while GKE Standard leaves node management to the customer:

When using GKE Autopilot, scaling requirements must be checked against its scaling limits. Fault-tolerant workloads such as batch jobs can save cost by running on Spot Pods, which use spare capacity at a lower price.

1.3Externalized Configuration for Immutable Deployments

Externalized configuration is the practice of injecting configuration files and secrets into workloads at deployment time instead of baking environment values into the image. ConfigMaps and Secrets provide that externalized configuration in Kubernetes, so the same immutable artifact can move from development to quality assurance to production with only its injected configuration changing. This approach lowers production risk because the exact image that passed testing is the image that is promoted.

Assessment for containerization must check whether the current configuration injection system supports containers, along with networking, persistent storage, and fault tolerance needs. Persistent data for stateful workloads is separate from injected configuration and uses storage services rather than ConfigMaps and Secrets:

• Persistent disks managed with GKE for workload-attached block storage
• Fully managed database services like Cloud SQL, Firestore, and Spanner
• File storage services like Filestore
• Object storage services like Cloud Storage

Building images from tightly controlled base images, labeling each image with semantic versioning or Git commit hashes, and extending tests to cover both images and workloads keeps the immutable model reliable.

Service exposure on Google Kubernetes Engine (GKE) (opens in a new tab) is the practice of publishing containerized workloads so clients can reach them reliably from inside the cluster, from a private network, or from the internet. Three Kubernetes APIs divide this work by scope: Kubernetes Service groups Pod endpoints into one stable endpoint, Ingress routes external HTTP(S) traffic through a managed load balancer, and the Gateway API provides advanced Layer 7 routing through the GKE Gateway controller. All three depend on Cloud Load Balancing and on backend endpoints that GKE keeps updated as Pods start and stop.

2.1Kubernetes Services for Exposing Workloads

A Kubernetes Service is a resource that groups a set of Pod endpoints into a single stable address. A client sends a request to the stable address, and the request is routed to one of the healthy Pods in the Service, so individual Pod restarts do not break connectivity. By default the Service gets a stable cluster IP address usable only inside the cluster, while other Service types widen that reach.

The following Service types differ by who can reach them and how traffic flows to Pods:

A fifth type, Headless, is also part of the Service API. For HTTP(S) web traffic, a Service of type LoadBalancer handles TCP/UDP directly, while HTTP(S) routing uses a Service of type NodePort as the backend for Ingress.

2.2Ingress and External HTTP(S) Load Balancing

Ingress is a Kubernetes resource that encapsulates rules and configuration for routing external HTTP(S) traffic to internal Services. On GKE, the GKE Ingress controller implements Ingress by automatically creating and managing an external Application Load Balancer, which is the recommended method for HTTP(S) services on GKE. To use Ingress, the external Application Load Balancer add-on must be enabled, and GKE clusters have this add-on enabled by default.

When an Ingress object is created, the controller builds the load balancer from the manifest in a fixed dependency chain. The load balancer's URL map uses host rules and path matchers that reference one or more backend services, where each backend service corresponds to a GKE Service of type NodePort. The backends for each backend service are either instance groups or network endpoint groups (NEGs), and GKE creates a Google Cloud health check for each backend service based on the readiness probe settings of the referenced workload. Load balancers created by GKE are billed according to regular Cloud Load Balancing (opens in a new tab) pricing.

2.3Gateway API for Advanced Traffic Management

The GKE Gateway controller is Google's implementation of the Kubernetes Gateway API for Cloud Load Balancing, and it configures Layer 7 Application Load Balancers to expose HTTP(S) traffic. Gateway API is designed as a more expressive, flexible, and extensible successor to Ingress, with better support for advanced traffic management, multi-protocol use, and multi-tenancy. GKE Gateway is the recommended choice for new deployments with those needs, while GKE Ingress remains viable for simpler HTTP/HTTPS routing where migration effort outweighs the benefits.

Gateway API splits load balancer configuration across three cooperating resources:

• Gateway defines listener configuration such as ports, protocols, and hostnames and functions as the entry point for traffic.
• HTTPRoute specifies how traffic received by a Gateway is routed to Services and supports path-based routing, header matching, and traffic splitting.
• Policy defines how the underlying Google Cloud infrastructure should function when attached to a Gateway, Route, or Service.

Traffic therefore flows from the internet client to the Gateway listener, then through matching HTTPRoute rules to the target Service, with Policy controls applied to the infrastructure underneath.

2.4Container-Native Load Balancing With Network Endpoint Groups

Container-native load balancing is the practice of distributing traffic directly to individual Pod IP addresses rather than to nodes, using network endpoint groups (NEGs). With the GCE_VM_IP_PORT NEG type, each Pod endpoint is registered as a backend, which improves network performance, increases visibility, enables advanced load-balancing features, and enables use of Cloud Service Mesh. Because of these benefits, container-native load balancing is the recommended solution for load balancing through Ingress.

When NEGs are used with GKE Ingress, the Ingress controller facilitates creation of all Layer 7 load balancer aspects, including the virtual IP address, forwarding rules, health checks, and firewall rules. This direct-to-Pod path also protects connections during Cluster Autoscaler scale-downs, because for non-NEG load balancers programming and connection draining might not complete before node instances terminate. Container-native load balancing is enabled by default for Services when all of the following conditions are true:

• The Services were created in GKE clusters version 1.17.6-gke.7 and higher.
• The cluster is a VPC-native cluster.
• The cluster does not use a Shared VPC.
• The cluster does not use GKE Network Policy.

2.5Routing, Traffic Distribution, and Connectivity

Reliable access on GKE depends on how inbound traffic enters, how it is distributed to Pods, and how outbound traffic leaves the cluster. Service networking has three elements: the frontend defines where the load balancer listens with its network, region, IPs, ports, protocols, and TLS certificates; routing and load balancing define how traffic is processed by protocol, headers, and paths; and backends define the endpoint type and service-discovery integration that GKE updates as endpoints change. An external Application Load Balancer listens on the public internet through Google points of presence and terminates traffic at the edge close to clients, while an internal Application Load Balancer listens within a VPC network for private communication.

Inbound traffic to a workload follows an ordered path:

1. Client to load balancer: An internet client sends a request that first reaches the Google Cloud load balancer created by a Service of type LoadBalancer, an Ingress, or a Gateway resource.
2. Load balancer to node: The load balancer routes the request to a healthy node in the cluster.
3. Node to Pod: The node forwards the traffic to the appropriate Pod, handled by kube-proxy on clusters without GKE Dataplane V2 or by eBPF programs on clusters that use GKE Dataplane V2, and the destination Pod may be on the same node or a different node.

Two controls shape this distribution. VPC firewall rules control inbound traffic at the node level and work with Kubernetes Network Policies at the Pod level for defense in depth, while GKE creates default rules so the control plane can reach nodes. Setting the externalTrafficPolicy field to Local avoids an extra hop by sending traffic only to nodes with healthy Pods, with the tradeoff of uneven distribution if Pods are unevenly spread. For an external LoadBalancer Service, weighted load balancing distributes traffic based on serving Pods per node, so nodes with more Pods receive more traffic.

Outbound and cross-network connectivity sit on the other side of the boundary. All GKE clusters require outbound connectivity to *.googleapis.com, *.gcr.io, and *.pkg.dev, plus working connectivity to the control plane IP. In private clusters where Pods lack public IPs, Cloud NAT lets Pods initiate outbound internet access without exposing them to incoming connections, and Private Google Access lets the cluster reach services such as Cloud Storage or Cloud SQL without traversing the public internet. For hybrid traffic, Cloud VPN or Cloud Interconnect connects GKE to on-premises networks, and Multi-cluster Services enable discovery across clusters, regions, or projects.

Configuring CI/CD workflows for container deployment means connecting source code changes to running workloads on Google Kubernetes Engine (GKE) through an automated chain of build, test, store, and deploy steps. In this chain, Cloud Build (opens in a new tab) builds and tests container images, Artifact Registry stores the approved images, and Cloud Deploy or the gke-deploy builder delivers them to GKE clusters. The workflow is triggered automatically when source code changes, so every commit can produce the same tested artifact and the same repeatable deployment.

3.1Build, Test, and Package Images with Cloud Build

Cloud Build is the managed build service that turns application source code and a Dockerfile into a tested container image. A Cloud Build trigger monitors the source repository, and when a change is committed to the main branch, the trigger starts the continuous integration (CI) pipeline that rebuilds the container, runs tests, and calls the delivery system to deploy to staging. This automation gives immediate feedback on each change and removes manual image production.

Producing each image follows the same ordered sequence:

1. Build the image: Cloud Build builds the container from source code and the Dockerfile and creates an image digest.
2. Run the test suite: Cloud Build runs unit, functional, integration, and load tests, plus Container Structure Tests that check commands, file locations, and file content inside the container.
3. Store the image in a registry: If tests succeed, Cloud Build pushes the container image to Artifact Registry and places build artifacts in a Cloud Storage bucket.

Cloud Build also performs vulnerability scanning against a Google Cloud-maintained database and only approves the image to continue after successful scan results. Binary Authorization then signs the approved image to confirm it passed required checks before deployment.

3.2Store and Identify Images in Artifact Registry

Artifact Registry is the central Google Cloud service for storing container images and dependencies for GKE deployments. Cloud Deploy (opens in a new tab) retrieves container images from Artifact Registry, so the registry sits between the CI pipeline that produces images and the continuous delivery (CD) pipeline that deploys them. To isolate the registry and its maintenance tasks, it is set up in a dedicated Google Cloud project.

Consistent naming makes each pipeline execution repeatable. Release images use semantic versioning tags, while images that still need work use an identifier tied to the codebase point, such as the Git commit hash from the main branch. Workload images are built from a small set of tightly controlled base images to avoid unsupported runtimes, and test suites are extended to cover the images themselves, not only the workloads inside them.

3.3Deploy Images to GKE with Automated Delivery

Automated delivery to Google Kubernetes Engine (GKE) moves a stored image from Artifact Registry to running Pods on GKE nodes through a delivery pipeline. Cloud Deploy manages this CD work by registering a delivery pipeline and targets, generating a new release for each source change, and deploying the release across a progression of targets. Targets represent GKE clusters, Cloud Run services or jobs, or GKE attached clusters, and Cloud Deploy stores the Skaffold rendering source and rendered manifests in a Cloud Storage bucket.

For direct deployment from Cloud Build, the gke-deploy builder is a wrapper around kubectl that applies recommended practices. The gke-deploy builder updates the Kubernetes resource file to use the image digest instead of a tag, adds recommended Kubernetes labels, retrieves credentials for the target GKE clusters, and waits for submitted resources to become ready. If no extra functionality is needed, the kubectl builder can deploy directly, and Helm or Kustomize builders support templated files. Deployment requires the Kubernetes Engine Developer role for Cloud Build, and the gke-deploy run step must specify the resource file, cluster location, and cluster name.

3.4Use Workflow Patterns for Consistent and Repeatable Deployments

Repeatable deployment patterns ensure the image tested in CI is the same image running in staging and production. The core rule is to build once and promote the immutable container image through environments, rather than rebuilding at each stage, because rebuilding can introduce minor differences or untested code. Promotion depends on keeping environment-specific configuration separate from the image, so configuration is externalized and read at runtime while secrets and config files are injected during deployment.

Two supporting patterns keep pipelines fast and traceable. GitOps stores declarative application and cluster configuration in Git repositories, so changes are reviewed through merge or pull requests, the full state is accessible at any point, and snapshots simplify recovery. Skaffold provides a common configuration format shared across development, staging, and production, which increases parity and lets Cloud Code with minikube, Cloud Build, and Cloud Deploy reuse the same definitions.

CI speed is managed with two pipeline types:

CD pipelines can run much longer than CI pipelines, especially with strategies such as blue-green deployments, and promotion from staging to production typically requires manual approval by an operator.

3.5Establish Security Early in the Pipeline

Pipeline security in GKE CI/CD means adding checks as early as possible so risks are found before artifacts are built or deployed. Early detection reduces the time and cost of fixing vulnerabilities and prevents risky images from reaching clusters. Security controls apply across the development environment, the CI system, and production governance.

Common early controls include:

• Require subject matter expert review for code integrated into the production repository.
• Run linting and static code analysis early to find weaknesses such as unescaped inputs or raw input in SQL queries.
• Scan built images for vulnerabilities with Artifact Registry vulnerability scanning.
• Block vulnerable images with Binary Authorization, which requires a GKE Enterprise subscription and can also require attestations such as passed vulnerability scan, passed QA testing, and product owner sign-off.

Integration of secure image management and Workload Identity is the practice of storing container images in a trusted registry and giving GKE workloads controlled access to Google Cloud. Artifact Registry (opens in a new tab) stores and protects the images that move through the deployment pipeline, while Workload Identity Federation for GKE lets each application authenticate to Google Cloud APIs with least privilege. Together they keep the same tested image moving from development to production without sharing broad credentials.

4.1Secure Image Storage in Artifact Registry

Artifact Registry is the managed Google Cloud service for storing container images and other build artifacts for deployment to Google Kubernetes Engine (GKE). Teams set up the registry in a dedicated Google Cloud project to isolate the registry and its maintenance tasks from workload projects. Images flow from the build system into Artifact Registry repositories, and deployment processes then pull those same images into GKE clusters across development, testing, and production environments. Existing images can be copied into Artifact Registry with tools such as gcrane during migration, which supports rollbacks while migration is in progress.

4.2Automated and Repeatable Image Production

Automated image production is the pipeline that builds, tests, and stores a container image every time source code changes. The build is automatically triggered by a code change so developers get immediate feedback, and Cloud Build can run the full sequence and store the result in Artifact Registry only when tests succeed. Each image follows an ordered workflow:

1. Build the image: Build the workload image from a tightly controlled base image.
2. Run the test suite: Run code tests plus image tests that check commands, file locations, and compliance of the runtime environment.
3. Store the image in a registry: Push the passing image to Artifact Registry with a repeatable tag.

Base images serve as the shared starting point for workload images, and the set of base images stays small and supported to avoid unsupported runtime environments. Tools such as Container Structure Tests and InSpec extend testing from application code to the structure and compliance of the image itself.

Tagging conventions make every pipeline execution repeatable and traceable from code to image:

The same tagged, immutable artifact is promoted through development, quality assurance, and production instead of being rebuilt in each environment. Rebuilding between stages can introduce small differences or untested code, so promotion guarantees that the image tested is the image deployed.

4.3Hardening Images Before Deployment to GKE

Hardening images before deployment means combining repository controls, vulnerability scanning, and deployment policy so only trusted images reach GKE. Artifact Registry provides controls that protect artifacts at rest and in transit, and Binary Authorization enforces policy at deploy time and after deployment. The controls work together as layered defenses around the registry and the cluster:

• Access control limits who and what can push, pull, and manage images through repository permissions.
• Data exfiltration prevention helps prevent unauthorized copying of artifacts outside approved boundaries.
• Vulnerability scanning through Artifact Analysis scans stored images for known vulnerabilities.
• Deployment enforcement through Binary Authorization blocks images that violate policy from being deployed.

Binary Authorization requires attestations, which are signed statements that an image completed a required process. Examples include passed vulnerability scan, passed quality assurance testing, and sign-off from the product owner. Continuous validation extends that check through the Pod lifecycle by logging policy conformance in Cloud Logging, so Pods that violate an updated policy or were deployed with dry run or breakglass are recorded.

4.4Workload Identity for Least-Privilege Access from GKE

Workload Identity Federation for GKE is the mechanism that lets a Kubernetes workload act as a Google Cloud Identity and Access Management (IAM) service account without managing keys. Traffic flows from a Pod using its Kubernetes service account to Google Cloud APIs, and Google Cloud trusts that identity through the federation between the cluster and IAM. The recommended pattern is to use a unique Kubernetes service account for each Kubernetes Service, and that account acts as its linked IAM service account. Because each application gets only the IAM permissions its own identity carries, the blast radius is limited if one workload is compromised.

The same isolation principle applies to the pipeline itself, where each deployment process step uses at least its own service account. One service account can produce the artifact while a different service account manages storage of that artifact in the repository, so the build system depends on separate identities with separate permissions. Using a distinct set of service accounts per environment makes development, testing, and production independent from each other. That separation adds operational complexity, but it lets teams test and validate changes to deployment processes in one environment without affecting the others.

Implementation of deployment strategies and health monitoring on Google Kubernetes Engine (GKE) (opens in a new tab) is the practice of updating containerized applications without losing service availability. GKE acts as the container orchestration tool that manages scaling and upgrading logic, so teams compose deployment logic with built-in mechanisms instead of building upgrade automation themselves. Health monitoring works with those mechanisms by observing production behavior and triggering rollback when a new version fails.

5.1Rolling Update Deployments

Rolling update deployment is a GKE update pattern that replaces application instances in small groups instead of all at once. Traffic continues to flow to the mix of old and new Pods while the controller first updates a subset of running instances, then progressively updates more instances until all instances run the new version. Because only a subset is unavailable or changing at any moment, the service stays available during the transition and a faulty update affects fewer users before it is stopped.

5.2Recreate, Blue-Green, and Canary Patterns

Recreate, blue-green, and canary patterns are alternative deployment patterns on GKE that trade downtime and risk differently from rolling updates. The choice depends on business goals, such as whether the team must deploy changes without any downtime or must expose changes to a subset of users before general availability.

• Recreating a deployment fully scales down the existing application version before it scales up the new application version.
• Blue-green deployment deploys an additional parallel set of instances with the upgraded version alongside existing production instances, then switches traffic from the old instances to the new instances when ready.
• Canary deployment releases the change to a limited environment or subset of users before making the feature generally available, which requires confirming that the container orchestration tool supports that pattern.

GKE has built-in support for the recreate and rolling strategies, which can be triggered remotely with kubectl from a continuous integration (CI) system or a separate deployment step. More elaborate patterns such as blue-green and canary depend on additional tooling or scripting, such as Spinnaker, which has built-in support for GKE, or Cloud Deploy, which implements deployment processes for containerized workloads.

5.3Maintaining Service Availability During Transitions

Maintaining service availability during transitions on GKE means combining a robust deployment strategy with production monitoring and automated rollback. No amount of pre-production testing guarantees correct behavior, because edge cases in data and user access patterns appear only in production, so teams must monitor the application in production and keep automated rollback and deployment mechanisms ready. Google Cloud Observability, with integrated logging and monitoring, provides the signals for that monitoring, and using a more robust strategy limits the blast radius so fewer end users are affected when an issue arises.

Key Facts

• GKE Autopilot bills only for compute resources requested by running Pods, while GKE Standard bills for all resources on nodes regardless of Pod requests.
• ConfigMaps and Secrets inject configuration at deployment time so the same immutable container image can be promoted from development to production.
• A Kubernetes Service provides a stable address that routes traffic to healthy Pods, while Ingress routes external HTTP(S) traffic through a managed Application Load Balancer and Gateway API adds traffic splitting and header matching.
• Cloud Build builds and tests images, Artifact Registry stores them with semantic version or commit-hash tags, and Cloud Deploy or gke-deploy delivers the exact image digest to GKE.
• Vulnerability scanning finds known issues in stored images, while Binary Authorization blocks non-compliant images from running on GKE and Workload Identity Federation for GKE gives each workload least-privilege access without managing keys.