Good day. It's Wednesday, Sep. 18, and in this issue, we're covering:

• Kubernetes Pod Disruption Budget Practical Guide

• Accelerate Ray in production with Ray Operator on GKE

• AT&T agrees to $13 million fine for third-party cloud breach

• An Opinionated Ramp Up Guide to AWS Pentesting

• Learn Linux: 30 commands for beginners [with cheat sheet]

• Top 20 DevOps Projects of 2024 [with source code]

Use Case

Kubernetes Pod Disruption Budget Practical Guide

Have you ever faced a situation where your application suddenly went down during a cluster upgrade or scaling event? Frustrating, right?

Losing pods at the wrong moment can mean downtime, unhappy users, and stress all around. Well, here’s where Pod Disruption Budgets (PDB) step in to save the day.

What Exactly is a Pod Disruption Budget (PDB)?

A PDB makes sure that during voluntary disruptions (like a node drain) or involuntary events (like a node crash), a certain number of pods remain running. Without it, Kubernetes could easily kill off too many pods at once, leaving your service unavailable.

What Happens Without a PDB?

Imagine this: you’ve got 3 nodes, and your app is running 2 pods—App 1 on Node 1 and App 2 on Node 2. When Node 1 gets drained, App 1 is terminated, but App 3 is still pending and hasn’t started on Node 3 yet.

Now, if Node 2 gets drained while App 3 is still pending, App 2 is terminated as well. What are you left with? No healthy pods. Your service is down until the new pod is up.

What Happens With a PDB?

If you configure a PDB requiring that at least 1 pod must be running, this changes everything. When Node 1 is drained and App 1 terminates, App 3 starts getting ready. But if the system tries to drain Node 2 before App 3 is running, Kubernetes will block the drain to keep App 2 alive. This way, you’ll never be left without healthy pods, ensuring continuous service.

How to Implement a Pod Disruption Budget ?

Let’s set up a techopsexamples deployment with 6 replicas and a PDB to ensure that at least 3 pods remain available during any disruption.

Step 1: Create the Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: teg-app
  namespace: production
spec:
  replicas: 6
  selector:
    matchLabels:
      app: teg
  template:
    metadata:
      labels:
        app: teg
    spec:
      containers:
      - name: teg-container
        image: teg-app:v1.0

Apply the deployment:

kubectl apply -f teg-deployment.yaml

Check your pods:

kubectl get pods

You should see something like:

NAME                          READY   STATUS
teg-app-6d9fc4fc8b-xyz        1/1     Running
teg-app-6d9fc4fc8b-abc        1/1     Running

Step 2: Create the PDB

Lets, create a PDB to ensure at least 3 pods are always available:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: teg-pdb
  namespace: production
spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: teg

Apply the PDB:

kubectl apply -f teg-pdb.yaml

Check the PDB:

kubectl get poddisruptionbudgets

You should see something like:

NAME     MIN AVAILABLE   ALLOWED DISRUPTIONS     AGE
teg-pdb    3               3                     30s

Step 3: Test the PDB by Draining a Node

Now simulate a disruption by draining a node:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

If too many pods would be impacted, Kubernetes will block the drain:

error: Cannot evict pod as it would violate the pod's disruption budget.

This confirms that your PDB is working and keeping your app alive during disruptions.

So, Why Use PDB?

If you’ve ever lost too many pods during scaling events, maintenance, or other disruptions, a PDB could be an ideal solution. It ensures your app always has enough healthy pods to keep serving users.

2024 is 71.6% complete. Start the idea you’ve been holding.

Tool Of The Day

kuma  - 🐻 The multi-zone service mesh for containers, Kubernetes and VMs.

Try it out !

Trends & Updates

Resources & Tutorials

Picture Of The Day

Did someone forward this email to you? Sign up here