GKE - Google Kubernetes Engine
Plan Deploy And Manage Workloads On GKE
Section Introduction
Welcome to your guide on optimizing workloads in Google Kubernetes Engine (GKE). In this tutorial, you’ll learn how to plan, deploy, and operate a variety of workloads—ranging from stateless services to stateful applications and batch jobs—while ensuring performance, scalability, and resilience.
Table of Contents
Workload Planning
Before you deploy to GKE, identify which workload type best fits your application requirements:
Workload Type | Use Case | Kubernetes Resource |
---|---|---|
Stateless | Web front-ends, APIs | Deployment |
Stateful | Databases, message queues | StatefulSet |
Batch | Data processing, CI/CD tasks | Job / CronJob |
Daemon | Node log collection, monitoring agents | DaemonSet |
Stateless vs. Stateful
Stateless applications can scale horizontally without preserving local state.
Stateful workloads require stable network identities and persistent storage.
# Stateless Deployment example
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels: { app: nginx }
template:
metadata: { labels: { app: nginx } }
spec:
containers:
- name: nginx
image: nginx:latest
Batch Jobs
Batch workloads run to completion, ideal for data processing or scheduled tasks.
apiVersion: batch/v1
kind: Job
metadata:
name: data-processor
spec:
template:
spec:
containers:
- name: processor
image: gcr.io/my-project/data-processor:latest
restartPolicy: OnFailure
Note
Use CronJob
for recurring batch tasks, e.g., nightly backups or ETL pipelines.
DaemonSets
DaemonSets ensure one pod per node (or per subset of nodes), perfect for logging agents and metrics collectors.
apiVersion: apps/v1
kind: DaemonSet
metadata: { name: fluentd-logger }
spec:
selector: { matchLabels: { app: fluentd } }
template:
metadata: { labels: { app: fluentd } }
spec:
containers:
- name: fluentd
image: fluentd:v1.9
Node Taints and Tolerations
Taints and tolerations let you control which pods can schedule onto which nodes, improving resource utilization and workload isolation.
- Taint: Applied to a node to repel pods
- Toleration: Added to pod specs to allow scheduling onto tainted nodes
kubectl taint nodes node-1 key=value:NoSchedule
# Pod toleration example
apiVersion: v1
kind: Pod
metadata: { name: critical-app }
spec:
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"
containers:
- name: app
image: gcr.io/my-project/critical-app:latest
Warning
A pod without a matching toleration won’t schedule on a tainted node. Double-check your keys and effects.
Rolling Updates in GKE
Rolling updates ensure zero-downtime deployments by gradually replacing old pods with new versions.
apiVersion: apps/v1
kind: Deployment
metadata: { name: web-app }
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 2
template:
metadata: { labels: { app: web-app } }
spec:
containers:
- name: web
image: gcr.io/my-project/web-app:v2.0
Key parameters:
maxUnavailable
: Pods that can be down during the updatemaxSurge
: Additional pods to spin up above the desired replicas
Further Reading
For best practices on securing and optimizing your GKE workloads, visit the GKE Documentation.
Watch Video
Watch video content