Advanced

“Autonomous cluster management” — the promise that an AI can monitor your Kubernetes cluster, diagnose problems, and perhaps even fix them without human intervention. It sounds like the holy grail for platform engineers. The reality is more nuanced. In this post I test K8sGPT with a locally running Llama 3.3 70B model on Apple Silicon. No cloud APIs, no data leaving your network, fully sovereign. Is this usable for real cluster diagnosis? Let’s find out. ...

You scanned your images with Trivy. You enforced policies with Kyverno. Your workloads have cryptographic identity via SPIFFE. But what happens after deployment? What if a container gets compromised at runtime? What if an attacker exploits a zero-day? Prevention isn’t enough. You need detection. Falco is a runtime security tool that monitors system calls in your cluster. It sees everything containers do — file access, network connections, process execution — and alerts when something looks wrong. ...

How does Service A know that Service B is actually Service B? In traditional networks, we trusted network location. If traffic came from the right IP, it was legitimate. Zero trust killed that assumption. Now every service must prove its identity, every time, regardless of network position. SPIFFE (Secure Production Identity Framework for Everyone) is a standard for service identity. SPIRE is its production-ready implementation. Together, they give every workload a cryptographic identity — automatically, without static secrets. ...

Rules that exist only in documentation don’t get followed. Rules enforced by computers do. Kubernetes gives you incredible flexibility. Every team can deploy whatever they want, configured however they like. This freedom becomes chaos without guardrails. Kyverno is a policy engine for Kubernetes. It validates, mutates, and generates resources based on policies you define — as Kubernetes-native YAML. Why Kyverno? There are multiple policy engines: Open Policy Agent (OPA) with Gatekeeper, Kyverno, Kubewarden. I chose Kyverno because: ...

Every deployment is a risk. The question isn’t whether something will go wrong — it’s how much damage it will cause when it does. Traditional Kubernetes deployments are all-or-nothing. You push a new version, and within seconds, 100% of your traffic hits the new code. If there’s a bug, everyone sees it. If the service crashes, all users are affected. Progressive delivery changes this equation. Instead of deploying to everyone at once, you gradually shift traffic to the new version, validating at each step. If something goes wrong, only a fraction of users are affected. ...