learnings
Infrastructure
Kubernetes
Workloads

Workloads

Workloads are the applications that run on a Kubernetes cluster. Rather than deploying containers directly, Kubernetes uses different workload resources to manage the lifecycle, scaling, and reliability of your applications.

Kubernetes provides several resources to manage workloads, such as Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs. Each of these resources is designed to manage a specific type of workload.

Workload Types

Deployments

Deployments are the most common workload type in Kubernetes. They are used to manage stateless applications that can be scaled horizontally. A Deployment defines a desired state for your application, such as the number of replicas, the container image, and the environment variables. It manages a set of Pods that run your application and ensures that the desired state is maintained.

Usecases:

  • Web applications
  • APIs
  • Microservices

Key Features

  • Rolling Updates: Deployments support rolling updates, allowing you to update your application without downtime.
  • Rollback: If an update fails, you can easily rollback to a previous version.
  • Scaling: You can scale your application up or down by changing the number of replicas.
  • Self-Healing: Deployments automatically restart failed Pods and replace them with new ones.
  • Versioning: Deployments support versioning, allowing you to manage multiple versions of your application.

Configuration Example 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

ReplicaSets

ReplicaSets are used by Deployments to manage the number of replicas of a Pod. You typically don’t create ReplicaSets directly but use Deployments instead.

Usecases:

  • Ensure a specific number of Pod replicas are running
  • Scale Pods horizontally
  • Replace failed Pods

Key Features

  • Replicas: ReplicaSets ensure that a specified number of Pod replicas are running.
  • Scaling: ReplicaSets can scale the number of replicas up or down.
  • Self-Healing: ReplicaSets automatically replace failed Pods.
  • Selectors: ReplicaSets use selectors to match Pods.
  • Pod Template: ReplicaSets define a Pod template that is used to create new Pods.

Configuration Example 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5

StatefulSets

StatefulSets are used to manage stateful applications that require stable, unique network identifiers and persistent storage. They are similar to Deployments but provide additional guarantees for stateful applications.

Usecases:

  • Databases
  • Key-value stores
  • Message brokers
  • Stateful applications
  • Message brokers

Key Features

  • Ordered deployment and scaling: StatefulSets ensure that Pods are deployed and scaled in a specific order.
  • Stable network identities: Pods are named with a stable, unique identifier.
  • Persistent storage per Pod: Each Pod has its own persistent storage volume.
  • Predictable Pod names: Pods are named with a stable, unique identifier.

Configuration Example 

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  minReadySeconds: 10 # by default is 0
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.24
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

DaemonSets

DaemonSets are used to run a copy of a Pod on every node in the cluster.

Usecases:

  • Monitoring agents
  • Log collectors
  • System daemons

Key Features

  • Run on every node: A Pod is scheduled on every node in the cluster.
  • Automatic scaling: Pods are automatically added or removed as nodes are added or removed from the cluster.

Configuration Example 

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
    selector:
        matchLabels:
        app: fluentd
    template:
        metadata:
        labels:
            app: fluentd
        spec:
        containers:
        - name: fluentd
            image: fluentd:latest
            ports:
            - containerPort: 24224

Jobs

Jobs are used to run a task to completion.

Usecases:

  • Run a specific task until completion
  • Can run multiple Pods in parallel
  • Retry on failure

Key Features

  • Run to completion: A Job runs a task to completion.
  • Parallelism: Jobs can run multiple Pods in parallel.
  • Retry on failure: Jobs can be configured to retry on failure.

Configuration Example 

apiVersion: batch/v1
kind: Job
metadata:
  name: send-queued-emails
spec:
    template:
        metadata:
        name: send-queued-emails
        spec:
        containers:
        - name: send-queued-emails
            image: email-sender:latest
            command: ["./send-emails.sh"]
    backoffLimit: 4

CronJobs

CronJobs are used to run Jobs on a schedule.

Usecases:

  • Batch processing
  • Data migrations
  • Periodic backups
  • Scheduled reports

Key Features

  • Schedule Jobs: CronJobs run Jobs on a schedule using cron syntax.
  • Automatic Job creation: CronJobs automatically create and delete Jobs based on the schedule.
  • History: CronJobs keep a history of Jobs that have run.
  • Concurrency: CronJobs can be configured to limit the number of concurrent Jobs.
  • Retries: CronJobs can be configured to retry Jobs on failure.
  • Timezone: CronJobs can be configured to run in a specific timezone.
  • Suspend: CronJobs can be suspended to prevent Jobs from running.

Configuration Example 

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
    schedule: "*/1 * * * *"
    jobTemplate:
        spec:
        template:
            spec:
            containers:
            - name: hello
                image: busybox
                args:
                - /bin/sh
                - -c
                - date; echo Hello from the Kubernetes cluster
            restartPolicy: OnFailure

Resource Management

Each workload type has its own resource management features.

Requests and Limits

Every workload can define resource requests and limits for CPU and memory. Requests are used to reserve resources for a Pod, while limits are used to restrict the amount of resources a Pod can use. For requests, you can define the minimum amount of resources that a Pod needs to run. For limits, you can define the maximum amount of resources that a Pod can use. For example:

resources:
  requests:
    memory: "64Mi" # Minimum 64Mi of memory (Mi = Mebibytes, which is 2^20 bytes)
    cpu: "250m" # Minimum 250m of CPU (m = millicores or milliCPU, which is  1/1000 of a CPU core)
  limits:
    memory: "128Mi" # Maximum 128Mi of memory
    cpu: "500m" # Maximum 500m of CPU
KubectlLifecycle