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
  • Stateless vs. Stateful
  • Batch Jobs
  • DaemonSets
• Node Taints and Tolerations
• Rolling Updates in GKE
• Further Reading

Workload Planning

Before you deploy to GKE, identify which workload type best fits your application requirements:

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

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

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 update
• maxSurge: Additional pods to spin up above the desired replicas

Further Reading

• Google Kubernetes Engine Overview
• Kubernetes Workloads
• Managing GKE Clusters

For best practices on securing and optimizing your GKE workloads, visit the GKE Documentation.