Kubernetes

The Question That Changed Everything # Over the past months, I’ve received a variation of the same question more than any other:

More Than Just a Login Screen # In our last post, we deployed a production-ready Keycloak cluster. But an Identity Provider (IdP) in isolation is just a database of users. Its true power lies in being the architectural enforcement point for your entire platform.

Take Back Control of Your Identity # Over the last few months, we’ve built a platform that rivals small enterprise setups. We have established a resilient networking layer with automated TLS, deployed distributed block storage with Longhorn, and mastered PostgreSQL on Kubernetes with CloudNativePG.

The “Stateful” Reality Check # In our last post, we solved the persistence layer by deploying Longhorn on Talos Linux. We finally have a place to put data. But a raw block device isn’t a database.

The Paradox of Statelessness # Kubernetes is designed to be ephemeral. Pods die, nodes are replaced, and the cluster heals itself. This “stateless” philosophy is efficient for application logic, but it hits a hard wall when you need to store data. Databases, message queues, and media servers all need a place to live that persists beyond a pod restart.

Locking it Down - From HTTP to HTTPS # In the preceding chapters, we established the networking foundation for a production-grade bare-metal Kubernetes platform.

From IP Address to Intelligent Gateway # In Chapter 1, we laid the foundational pillar by solving the bare-metal IP address problem with MetalLB. Our test NGINX service successfully acquired the IP 10.20.0.90, proving our cluster can now serve traffic like its cloud-native counterparts.

After building a Kubernetes cluster and setting up Argo CD to manage its configuration, what’s the very next thing you should install? For me, both in production and in my homelab, the answer is always the same: External Secrets Operator. This post explains why and shows you how I integrate it with 1Password to bring enterprise-grade secret management to my home setup.

In my last post, Stop Using the Wrong CNI: Why Your Homelab Deserves Cilium in 2026, we established a production-grade networking foundation for our Talos Kubernetes cluster. But a powerful CNI is only half the story. To truly manage our cluster like a professional, we must automate and declare everything.

In my last post, The Four-Repo GitOps Structure for My Homelab Platform, I laid out the architectural blueprint for managing my homelab like a production environment. Building on the automation I detailed in my popular post, Need for Speed: Automating Proxmox K8s Clusters with Talos Omni, we now have a cluster ready for a production-grade CNI. Now that we have a solid GitOps foundation and a running Talos Kubernetes cluster, it’s time to address a critical component: networking.