Samuel
4406908fbe
- KUBECON_RESPONSE_TEMPLATES.md: 8 platform-specific response templates with trigger conditions * Pre-conference, main event, post-event coverage * Twitter/X, Bluesky, Mastodon, LinkedIn platforms * Timing guidance for day-of monitoring and engagement - FAQ_OBSERVABILITY_OPERATORS.md: 20+ real operator questions with honest answers * Plugin-specific guidance (when to use, when not to) * Vulnerability acknowledgment (we're young, not enterprise-grade yet) * Serves as reference for KubeCon conversations and post-conference follow-up These assets reduce day-of friction during the conference March 23-26. All responses are pre-approved tone and strategy, ready to deploy as conversation patterns appear.
237 lines
8.2 KiB
Markdown
237 lines
8.2 KiB
Markdown
# FAQ: Headlamp Plugins for Kubernetes Operators
|
|
|
|
**Context**: For operators who are thinking about observability, visibility, and management during/after KubeCon. Answer real questions with real context, not marketing language.
|
|
|
|
---
|
|
|
|
## Observability & Visibility
|
|
|
|
### Q: I have a Prometheus stack already. Why do I need Headlamp plugins?
|
|
|
|
A: You probably don't need them. Prometheus is good at what it does: metrics. But Prometheus is not a dashboard. You still need to *see* your cluster in human terms — what's running, where, and why it matters.
|
|
|
|
Headlamp plugins show you the cluster state in the UI. Your Prometheus metrics live somewhere else. They're complementary, not competitive.
|
|
|
|
If you're happy with kubectl and Prometheus graphs, keep going. If you find yourself switching between tools, Headlamp might fit.
|
|
|
|
---
|
|
|
|
### Q: Is this "observability"? I thought we needed traces, metrics, logs...
|
|
|
|
A: You're thinking of the marketing definition. In practice, operators need:
|
|
1. To see what's running (cluster state)
|
|
2. To understand if it's healthy (metrics)
|
|
3. To know what went wrong (logs, events)
|
|
|
|
Headlamp handles #1. Your existing stack handles #2 and #3. The magic is in integrating them, not replacing them.
|
|
|
|
Our plugins sit in the UI where you're already looking. That's the whole point.
|
|
|
|
---
|
|
|
|
## Individual Plugins
|
|
|
|
### Q: When should I use the Rook plugin?
|
|
|
|
A: When you're running Rook/Ceph and you're tired of bouncing between Ceph's CLI tools and Kubernetes dashboards to understand cluster health.
|
|
|
|
The Rook plugin shows:
|
|
- Cluster status (capacity, degradation, health warnings)
|
|
- Pool health (replication status, PG states)
|
|
- OSD states (up/down, full/nearfull)
|
|
- Filesystem status
|
|
|
|
Instead of `ceph osd tree`, `ceph df`, `rook ceph osd status`... you look at one place.
|
|
|
|
**Not for**: Teams that want deep Ceph debugging. For that, you still need Ceph's native tools.
|
|
|
|
---
|
|
|
|
### Q: What's the GPU plugin actually for?
|
|
|
|
A: Seeing which nodes have GPUs, how much capacity you have, and which workloads are using them.
|
|
|
|
If you're running ML workloads, inference servers, or anything with accelerators, you need to know:
|
|
- Which nodes have what hardware
|
|
- What's currently running on those nodes
|
|
- Whether utilization is balanced
|
|
|
|
Kubectl doesn't show you that easily. Prometheus might have the metrics if you instrument everything correctly. The GPU plugin shows it at a glance.
|
|
|
|
**Not for**: Teams not using GPUs. This is a specialized tool.
|
|
|
|
---
|
|
|
|
### Q: Why a sealed-secrets plugin? Isn't that a security risk — showing secrets in a UI?
|
|
|
|
A: The plugin doesn't show the secret *values*. It shows:
|
|
- Which secrets exist
|
|
- Which workloads reference them
|
|
- Where they're mounted
|
|
- Rotation status (if you implement that)
|
|
|
|
That's visibility without exposure. It answers "what secrets are in my cluster?" not "what are the passwords?"
|
|
|
|
Teams using sealed-secrets are usually the ones who care about secret governance. This plugin gives you governance visibility without breaking the security model.
|
|
|
|
---
|
|
|
|
### Q: What's the difference between your plugins and Rancher/Lens/other dashboards?
|
|
|
|
A: They're trying to be the entire dashboard. We're building plugins for the gaps.
|
|
|
|
If you like Headlamp's design but want specific functionality (Rook management, GPU visibility, sealed-secrets governance), our plugins slot in.
|
|
|
|
If you prefer Rancher's philosophy, great. Use Rancher. Our plugins are built for people who want a lightweight UI + specialized functionality, not an all-in-one platform.
|
|
|
|
---
|
|
|
|
## Operational Questions
|
|
|
|
### Q: Do I need to run Headlamp to use these plugins?
|
|
|
|
A: Yes. Our plugins extend Headlamp. Headlamp is lightweight (single container), but you need to be running it.
|
|
|
|
If you're not using Headlamp, these plugins don't help. If you are, they extend what you can see.
|
|
|
|
---
|
|
|
|
### Q: How do you handle RBAC? Can my developers see things they shouldn't?
|
|
|
|
A: Headlamp respects your cluster's RBAC. If a developer can't run `kubectl get secrets`, they can't see them in the plugin either.
|
|
|
|
Your security boundaries are your security boundaries. Our tools don't bypass them.
|
|
|
|
---
|
|
|
|
### Q: What's the upgrade path? Will my existing configuration break?
|
|
|
|
A: We try not to break things. Honest answer: we're still young. Check release notes before upgrading. If you find a breaking change, file an issue and we'll help.
|
|
|
|
If you need stability guarantees, we're not there yet. We're a small team shipping useful things, not a enterprise product with backwards-compatibility promises.
|
|
|
|
---
|
|
|
|
### Q: Can I run Headlamp + plugins in an air-gapped environment?
|
|
|
|
A: Yes. If you can run Headlamp, you can run the plugins. No external dependencies, no phone-home telemetry.
|
|
|
|
The only requirement: your cluster can reach the Headlamp instance (network security is your problem).
|
|
|
|
---
|
|
|
|
## Adoption & Getting Started
|
|
|
|
### Q: How do I know if these plugins are worth the effort?
|
|
|
|
A: Try one. Pick the one that solves a problem you're actually having.
|
|
|
|
Rook users: Use the Rook plugin for a week. See if it saves time. If not, delete it.
|
|
GPU users: Use the GPU plugin. See if you'd miss it.
|
|
Sealed-secrets users: Use the plugin for secret governance.
|
|
|
|
Don't add plugins "just in case." Add them when they're solving a real problem.
|
|
|
|
---
|
|
|
|
### Q: What's the support story? If something breaks, what happens?
|
|
|
|
A: GitHub issues. We're responsive (usually within 24-48 hours). If it's a security issue, email the maintainers directly (see repo).
|
|
|
|
We're not a SaaS with SLAs. We're open source with humans behind it who care. That's the tradeoff.
|
|
|
|
---
|
|
|
|
### Q: Where do I submit feature requests?
|
|
|
|
A: GitHub issues with the `feature-request` label. Be specific. "Make it faster" doesn't help. "Show OSD versions in the Rook plugin" does.
|
|
|
|
---
|
|
|
|
## Technical Depth
|
|
|
|
### Q: How much overhead do these plugins add?
|
|
|
|
A: Minimal. Plugins are JavaScript that runs in your browser. They query your cluster API, same as kubectl does.
|
|
|
|
If you're running Headlamp already, adding plugins is negligible overhead.
|
|
|
|
---
|
|
|
|
### Q: Can I modify the plugins for my own use?
|
|
|
|
A: Yes. All plugins are Apache-2.0 licensed. Fork, modify, deploy. We appreciate improvements back in PRs, but no obligation.
|
|
|
|
---
|
|
|
|
### Q: Do these plugins work with managed Kubernetes (EKS, GKE, AKS)?
|
|
|
|
A: If Headlamp works with your platform, the plugins work. Headlamp just needs API access.
|
|
|
|
We develop against standard Kubernetes. If you hit a managed-service-specific issue, let us know.
|
|
|
|
---
|
|
|
|
## When to Say No
|
|
|
|
### Q: Should I use these in production?
|
|
|
|
A: Depends on what you mean by "production." If you mean "will it crash my cluster," no. Headlamp + plugins are read-only.
|
|
|
|
If you mean "is this enterprise-grade," probably not yet. We're under 1 year old. We're useful, not bulletproof.
|
|
|
|
Try it. Monitor it. Have a fallback (you do have kubectl, right?). If it fails, switch back.
|
|
|
|
---
|
|
|
|
### Q: Can these plugins replace my existing monitoring stack?
|
|
|
|
A: No. Don't try. This is visibility, not comprehensive monitoring.
|
|
|
|
You still need logs, metrics, traces, alerting. We're the UI layer for cluster state + specialized views.
|
|
|
|
---
|
|
|
|
## Getting Help
|
|
|
|
### Q: I found a bug. What do I do?
|
|
|
|
A: GitHub issue with:
|
|
- What you were doing
|
|
- What happened
|
|
- What you expected to happen
|
|
- Your Kubernetes version
|
|
- Your Headlamp version
|
|
- Plugin version
|
|
|
|
Specificity helps. "It doesn't work" doesn't. "When I click the Rook tab, I get a 403 error" does.
|
|
|
|
---
|
|
|
|
### Q: I want to contribute. Where do I start?
|
|
|
|
A: GitHub issues with `good first issue` label. Read the CONTRIBUTING.md in each repo. Start small.
|
|
|
|
We're a small team. contributions that improve things make a real difference.
|
|
|
|
---
|
|
|
|
## The Honest Version
|
|
|
|
Headlamp plugins are for people who:
|
|
- Are already running Kubernetes in production
|
|
- Understand their observability gaps
|
|
- Want small, focused tools instead of monolithic platforms
|
|
- Are comfortable with "good enough" software from small teams
|
|
|
|
If you need enterprise support, SLAs, and hand-holding, we're not it (yet). If you want useful tools that respect your workflow and don't try to be everything, we might be.
|
|
|
|
Try us. If we don't fit, no hard feelings. There are plenty of other dashboards. Find the one that works for your team.
|
|
|
|
---
|
|
|
|
**Last updated**: March 13, 2026
|
|
**Audience**: Kubernetes operators, platform engineers, storage admins
|
|
**Tone**: Honest, not salesy, specific, realistic about limitations
|
|
|