Daniele Polencic

Daniele PolencicOct 13, 2026

💡 One of the things I like about the LearnKube Telegram group is the discussion that follows the articles we share. We shared a case study about a payment service stuck in a restart loop. Its liveness probe depended on a downstream service. The author said that repeated restarts caused CPU and memory pressure. Someone asked: can restarts really push containers into a resource-constrained state? I think this is possible if your requests are tiny, but the actual CPU usage is significant. Or if the container has a huge CPU spike at startup. Imagine ten containers on a node with four CPUs. They use very little CPU during normal operation, but each wants a full CPU at startup. If they restart together, they all want that CPU at the same time. You still only have four CPUs, so the containers compete for them. With equal requests, each gets roughly 0.4 CPU. The startup work takes longer. The code that answers the liveness probe also needs CPU time, so the response can take longer. If the response takes too long, the probe fails. After enough consecutive failures, the kubelet restarts the container again. And now you repeat the same startup work, with the same competition for CPU. The next question was: if the container needs all that CPU at startup, how did it work in the first place? Because it can use spare CPU beyond its request. Starting one container while the others are quiet is different from restarting all ten together. The resource configuration is the same, but the available CPU is not. Even after the downstream service recovers, the containers can still struggle because they compete for CPU. It is also why requests matter beyond placement. They influence how CPU is shared when the node is busy. I wrote a book about CPU and memory requests and limits. It covers how they affect your apps, how Kubernetes uses them, and how to build resource policies around them. You can download it for free: https://lnkd.in/exn_G8Sy

Daniele PolencicOct 5, 2026

A boring update from me: our next online and Munich Kubernetes courses are confirmed. One reason teams come to LearnKube is that too much Kubernetes knowledge sits with one or two people. Every deployment question, networking problem, or unfamiliar error goes to the same colleague. AI agents can operate clusters and debug problems, but the team still needs to understand their actions and know when to intervene. I want more engineers to understand how the system works so they can investigate problems and make changes with confidence. If this is you, I want our courses to give you the confidence to investigate things yourself. Our next public Advanced Kubernetes courses: • Online: 22, 23, 29, and 30 October 2026 https://lnkd.in/gbePJyMm • Munich, in person: 16–19 November 2026 https://lnkd.in/g3RDphWk

Daniele PolencicOct 14, 2026

Learn Kubernetes Weekly 205 hot off the press, and those are my top picks: 🛡️ Scale by Rejection: How We Built a Streaming Telemetry Service that Survives Millions of Events per Second by Samir Savla: This case study shows how a telemetry gateway handles millions of events per second by rejecting overload at the edge and using two levels of autoscaling on Kubernetes. 🤖 Serving LLMs at Scale: A Practical Guide with KServe, KEDA,VLLM & Kubernetes by Sowmithdurusoju: This tutorial shows how to serve and scale large language models on Kubernetes with KServe, use KEDA for demand-based scaling, and run inference with vLLM. ⏰ Should your daily batch job live inside your main application? by Tayeb Gasmi: This tutorial shows how to move a daily Spring Boot batch job out of the web app and run it as a Kubernetes CronJob so memory spikes do not take down the API. 🧠 KubeIntellect: Human-Governed AI for Kubernetes: KubeIntellect lets you troubleshoot Kubernetes in plain English by checking kubectl, Prometheus, and Loki, while requiring human approval before it changes the cluster. If you prefer to read online (or receive it next week in your inbox), you can do so here: https://lnkd.in/gKecpaiG