[social] batch: Why We Built These — problem-solution narrative for 6 plugins

social/queue/2026-03-10-why-we-built-these.md

@@ -0,0 +1,137 @@
+# Social Media Batch - 2026-03-10
+
+## Strategic Summary
+
+Six plugins. Each one exists because we had a specific problem in production with no good visibility. This batch is about "why" before "what" — explaining the actual Kubernetes pain point each plugin addresses, from our own experience. It's educational content that works pre-KubeCon: people don't need to know what Headlamp is to understand "oh, that problem sounds familiar." Also serves as support content for the KubeCon campaign dropping next week.
+
+---
+
+## 1. Ready to Post
+
+### Post 1: Rook-Ceph Problem
+
+**Platform**: Twitter/X
+
+**Post**:
+You deploy Ceph because it's the right choice for distributed storage. Then you're staring at `ceph status` in a terminal wondering which pool is actually filling up, what the OSD rebalance is doing, and why your capacity projections are off by 40%.
+
+We built headlamp-rook-plugin to see inside Ceph from a dashboard instead of grep-ing logs.
+
+github.com/privilegedescalation
+
+**CMO Note**: Opens with a relatable pain point (Ceph deployment without visibility), then delivers the specific solution (dashboards instead of CLI). No "exciting to announce" language. The problem-first framing resonates with people already running Ceph.
+
+---
+
+### Post 2: Sealed Secrets Problem
+
+**Platform**: Bluesky
+
+**Post**:
+Your team has a pattern:
+
+1. Someone generates a secret
+2. They echo it in Slack "here's the password"
+3. It's in the channel history forever
+4. Someone rotates it, forgets to tell the database
+5. 2am incident
+
+We built headlamp-sealed-secrets-plugin so the secret never leaves the browser and stays encrypted in your cluster. The plaintext never transits anywhere someone can screenshot it.
+
+**CMO Note**: Captures the actual workflow failure that sealed-secrets solves. The numbering of the failure pattern is specific and darkly funny. Bluesky audience appreciates the "this is how we actually mess up" honesty.
+
+---
+
+### Post 3: Polaris Problem
+
+**Platform**: Mastodon
+
+**Post**:
+Kubernetes best practices are things you know about the week after you've already deployed your application with none of them.
+
+Polaris audits your workloads against security and reliability policies. It shows you what you're doing wrong before it becomes a 3am outage.
+
+We built the headlamp-polaris-plugin so you can actually see the audit results in your dashboard instead of waiting for the automated security scan email you never read.
+
+**CMO Note**: Self-aware about human nature (learning best practices after deployment fails). Polaris is the solution. Mastodon audience gets the candor. Not preachy, just practical.
+
+---
+
+### Post 4: Intel GPU Problem
+
+**Platform**: Twitter/X
+
+**Post**:
+You provisioned Intel GPUs in your K8s cluster for ML workloads. Cool.
+
+Now: which node has available GPU? How hot are they running? Is the scheduler actually placing workloads on GPU nodes or just on CPU? Is anything actually using them?
+
+We built headlamp-intel-gpu-plugin to answer those questions from a dashboard instead of kernel logs.
+
+github.com/privilegedescalation
+
+**CMO Note**: Chains questions that GPU cluster operators actually have. Each question hints at a real visibility gap. The solution (dashboard instead of logs) is matter-of-fact. Specific pain point without corporate language.
+
+---
+
+### Post 5: TrueNAS CSI Problem
+
+**Platform**: Bluesky
+
+**Post**:
+Your storage driver is configured. Your benchmark says it can do 10k IOPS.
+
+But what's actually happening in production? You're scheduling workloads, moving data around, and your I/O profile looks nothing like the benchmark.
+
+We built headlamp-tns-csi-plugin so you can see kbench storage metrics live in your cluster dashboard. No "apply a manifest and wait for email," just see what your storage is actually doing.
+
+**CMO Note**: Contrasts lab conditions (benchmark) with production reality (actual I/O profile). Storage visibility without waiting. Appeal to operators frustrated with "set it and hope" storage management.
+
+---
+
+### Post 6: kube-vip Problem
+
+**Platform**: Twitter/X
+
+**Post**:
+You've got a load balancer. You've got virtual IPs floating around your cluster. And someone's asking "which service is that IP mapped to?"
+
+Now what? Grep the config? Check the VirtualIP manifest? It's 2025 and you're hunting through YAML.
+
+We built headlamp-kube-vip-plugin so virtual IPs and load balancer status show up in your dashboard where you can actually see them.
+
+github.com/privilegedescalation
+
+**CMO Note**: Specific frustration: answering "which service" requires config hunting. The solution is dashboard visibility. Dry tone emphasizing the absurdity of 2025-era manual lookups.
+
+---
+
+## 2. Risky but Worth Discussing
+
+### Post 7: Meta Comment (Optional)
+
+**Platform**: Twitter/X
+
+**Post**:
+Six Kubernetes plugins, and the common thread isn't "advanced observability" or "enterprise features."
+
+It's: we had a problem. The CLI wasn't good enough. The logs were hard to parse. So we built a dashboard for it.
+
+Sometimes the answer to "why do we exist" is "we got frustrated with grep."
+
+**CMO Note**: Self-aware meta-commentary on why all six plugins exist. The "we got frustrated with grep" line is the voice we're known for. Could feel slightly salty to some, but earns credibility with operators who've been there. Optional amplification of the whole batch theme.
+
+---
+
+## 3. Backlog (Evergreen)
+
+None for this batch — these posts work best as a thematic set posted over 3-5 days while driving toward KubeCon, then are less relevant after.
+
+---
+
+## Notes
+
+- Suggested posting schedule: 1 post per day starting tomorrow (March 11), finishing by March 15, giving time for engagement before KubeCon campaign drops March 21
+- Each post stands alone but builds narrative collectively
+- Educational angle differentiates from release announcements and provides value even for non-adopters
+- Heavy on problem framing, light on pitch — fits the voice and builds trust