Kubernetes

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: ...

Kubernetes Secrets are not secrets. They’re base64-encoded plain text, stored in etcd, often visible to anyone with cluster access. This is the default, and it’s terrifying. Every cloud provider offers a Key Management Service. AWS has Secrets Manager, Google has Secret Manager, Azure has Key Vault. They work fine — until you need to migrate, or you want to understand what happens to your secrets, or you simply don’t want your most sensitive data in someone else’s infrastructure. ...

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. ...

I run GitLab self-hosted. Not because it’s trendy, but because I want to own my CI/CD pipeline. No vendor can change pricing, deprecate features, or access my code without my knowledge. This is sovereignty applied to CI/CD. And GitLab makes it practical. Let me show you how to build a complete pipeline: from code commit to running in Kubernetes. Why Self-Hosted GitLab? Before we dive into pipelines, the “why” matters: Data sovereignty: Your code, your builds, your artifacts stay on your infrastructure No usage limits: Unlimited CI minutes, unlimited storage, unlimited users Network locality: Builds run close to your clusters, faster artifact transfers Customization: Configure runners exactly how you need them Air-gap capable: Works in offline environments The trade-off is operational overhead. You maintain GitLab. For me, that’s worth it. ...

GitOps promises that Git is the source of truth. But what if someone kubectl edits a deployment? What if a mutating webhook changes a resource? What if the cluster silently diverges from what Git says it should be? This is configuration drift, and it’s one of the most insidious problems in Kubernetes operations. ArgoCD can help you detect it — if you configure it correctly. What Is Configuration Drift? Drift happens when the actual state of your cluster differs from the desired state in Git. ...