DevZero

What if Kubernetes workloads could resume instead of restart? Pod-Level Checkpoint/Restore is one of the most interesting alpha changes targeted for Kubernetes 1.37. Today, checkpointing in Kubernetes primarily operates at the individual-container level. KEP-5823 takes an important step toward treating the Pod—the unit Kubernetes actually schedules—as a whole. The first implementation introduces CheckpointPod and RestorePod methods in the Container Runtime Interface, establishing a standard way for the kubelet and container runtimes to coordinate Pod-level checkpoint and restore. This is foundational work rather than a complete live-migration workflow, but it creates a path toward faster recovery, warm starts, less disruptive node maintenance, and workload migration without rebuilding all runtime state from scratch. The broader feature is a Kubernetes community effort. One of its key implementation contributions, the new CRI methods, was authored by Radostin Stoyanov, a CRIU maintainer and member of the DevZero team. That connection is particularly relevant because DevZero already applies CRIU-based checkpoint/restore in its own migration and rightsizing workflows, preserving in-memory state and open connections without restarting the application. The CPU/GPU distinction matters too. CRIU can capture Linux process state for CPU workloads. GPU workloads require additional GPU-aware support because CUDA and device state sit outside what CRIU alone manages. Kubernetes is moving in the right direction: standardizing primitives that the wider ecosystem has already been developing and applying in practice. Still alpha, but a meaningful step forward. Read more: https://lnkd.in/dTZTPK86 CRIU: https://lnkd.in/daRhvKCY #Kubernetes #CloudNative #CRIU #CheckpointRestore #DevZero

Support for event notifications in the #MCP protocol is limited. That's about to change, and our August meetup digs into how. 👇 I will be talking about a new protocol extension currently in the design stage, that will allow AI Agents to subscribe to events happening in real world (a Slack message, a GitHub push, a 3am page) and wake up when they occur. Debosmit Ray (debo) (CEO & Co-founder of DevZero, ex-Uber infra) will also tell us about: "Live rightsizing in Kubernetes" - how resource tuning happens in k8s without restarts. Join Us 👉 lu.ma/h69eyb40 📅 Thursday, August 13 🕠 5:30 PM — Networking, pizza & drinks 📍 Docker, Inc, Seattle Maritime Building (Alaskan Way) 🍕 Food & drinks courtesy of our sponsor, DevZero

Cloud Native Seattle is back — Thursday, August 13 — with talks about real-time AI agents and smarter Kubernetes resource management. 🎉 🎙️ Aman Singh (Principal Engineer, Microsoft Azure CTO's office) A first look at #MCP Events — the draft protocol extension that lets #AI #agents subscribe to events happening in the real world (a Slack message, a GitHub push, a 3am page) and wake up when they occur. Straight from the MCP working group. 🎙️ Debosmit Ray (debo) (CEO & Co-founder of DevZero, ex-Uber infra) Live rightsizing in Kubernetes: tuning resource requests and limits at runtime, without pod restarts. Where VPA falls short, what "live" actually means in production, and what to watch for when you optimize continuously. 👉 RSVP - tinyurl.com/cncf-sea-04 📅 Thursday, August 13 🕠 5:30 PM — doors, networking, pizza & drinks 📍 Docker, Inc, Seattle Maritime Building (Alaskan Way) 🍕 Food & drinks courtesy of our sponsor, DevZero Run clusters or build with agents — there's something here for you. Come for the talks, stay for the networking. #MCP #AIAgents #CloudNative #Kubernetes #Seattle

Kubernetes Notes #4 — What actually lives inside a Pod spec The Pod spec is the only thing kubelet cares about. Everything you want to run, where it runs, how much resource it gets — it all lives here. Most people have seen this: apiVersion: v1 kind: Pod metadata:  name: nginx spec:  containers:  - name: nginx   image: nginx:1.14.2   ports:   - containerPort: 80 This works. But it is missing almost everything that matters in real usage. Here is the same Pod done properly: apiVersion: v1 kind: Pod metadata:  name: nginx  annotations:   my-tool/config: "some-value" spec:  nodeName: worker-node-1  containers:  - name: nginx   image: nginx:1.14.2   ports:   - containerPort: 80   env:   - name: ENV_NAME    value: "hello"   resources:    requests:     memory: "64Mi"     cpu: "250m"    limits:     memory: "128Mi"     cpu: "500m"   volumeMounts:   - name: shared-data    mountPath: /data  volumes:  - name: shared-data   emptyDir: {} Now let me explain every field that was added. — nodeName Pins the Pod to a specific node. Bypasses the scheduler completely. Use this when something on that node is required — like a file on disk. — annotations Key-value metadata. Kubelet ignores them. But other tools can read and act on them. This is how you pass information without touching the core Kubernetes API. — resources.requests The minimum the container needs. Kubernetes uses this to pick a node. No node has enough — Pod stays Pending forever. — resources.limits The maximum the container can use. Cross the memory limit — OOMKilled. No limit set — your container can eat the entire node. Always set this. — env Environment variables injected at start. Can come from hardcoded values, a ConfigMap, or a Secret. — volumes + volumeMounts volumes defines storage at the Pod level. volumeMounts connects it into the container at a path. Multiple containers in the same Pod can mount the same volume. The first spec is a car with no seatbelt. The second one is production ready. Both run. One is safe. --- Note #5 coming — Pod lifecycle phases. What Pending, Running, Succeeded actually mean under the hood. #GSoC #Kubernetes #CRIU #OpenSource

Day 1 at #KubeCon India was a success. We had great conversations with infra teams tackling some of the toughest challenges in Kubernetes today. A few themes kept coming up: • Balancing performance, reliability, and cost • Managing AI workloads efficiently • Reducing infrastructure complexity • Getting more out of existing resources without introducing risk Most importantly, we got to meet an incredible cloud native community that’s pushing the ecosystem forward. One thing we didn’t expect? You all cleaned us out of swag. 😅 If you missed us yesterday, don’t worry. We’ll be back at the booth today and we still have our biggest giveaways left: 📱 iPhone 17 💻 Mac mini Stop by, say hello, and enter for your chance to win. Thanks to everyone who stopped by on Day 1. Looking forward to another great day in Mumbai.