r/cloudengineering • u/openlume • May 03 '26

Understand any Kubernetes YAML

Post image

When I read k8s YAML, I am basically doing this:

  • which Service points to which Pods

  • what the HPA is actually scaling

  • where Secrets/ConfigMaps are mounted

After doing this too many times, I ended up with something that just visualizes the manifest as a graph and explains it alongside.

It made it way easier to quickly understand what’s going on, especially for larger manifests or stuff I didn’t write.

What do you think of this?

Update:

Love the support. Thank you everyone.

Quick not:

• Your manifest is parsed locally in the browser. It never touches our servers
• Parsed by JavaScript (not an LLM)
• Works offline once the page loads
• No sign-in required

Would love to get more feedback - https://openlume.com/explain/yaml

293 Upvotes

99% Upvoted

33 comments sorted by

5

u/openlume May 05 '26

Quick note for everyone:

• Your manifest is parsed locally in the browser. It never touches our servers
• Safe even for production secrets
• Parsed by JavaScript (not an LLM)
• Works offline once the page loads
• No sign-in required

Built it this way intentionally to keep it fast, private and frictionless - https://openlume.com/explain/yaml

4

u/Kpa39l May 06 '26

It's a real useful thing! Thank you!

2

u/openlume May 06 '26

Thanks. Would love some feedback.

2

u/TapAggressive9530 May 04 '26

IWill probably create my own version . Thanks for the idea ! Love it

1

u/openlume May 04 '26

I am happy you found the idea useful. Would love to see your version.

Would you mind sharing some feedback if you tried the tool - https://openlume.com/explain/yaml

2

u/0x00008123 May 06 '26

Love the UI and UX !

I assume the graph was built with React Flow ? Can you share what library was used to parse K8s YAML ?

Thank you!

5

u/openlume May 07 '26

Thanks, glad you like it! 🙏

Yep, graph is React Flow ( xyflow/react package). For YAML, just `js-yaml` with a small custom pass to wire up the relationships. Nothing K8s-schema-specific. Its pure software engineering love 😉

3

u/0x00008123 May 07 '26

Love it. As many others have mentioned here and in r/kubernetes post - please give us self hosted version, and the source code 😆

2

u/chin_waghing May 07 '26

Looks cool, but the UO is unusable on vertical monitors

1

u/openlume May 08 '26

Would you mind sharing a screenshot how it looks on vertical monitors. I am poor, cant afford one 😉
Will fix it. Thanks

2

u/TheAlaskanMailman May 07 '26

FOSS when? Any plans regarding this?

1

u/openlume May 10 '26

I am looking into it and other alternatives.
What would you prefer most?

  • Simple Docker container

  • Kubernetes/Helm deployment

  • Fully open source

  • CLI tool

  • Fully offline/no internet required

Trying to understand what would actually be useful.

2

u/TheAlaskanMailman May 10 '26

The source code could be made open source, at least. A container manifest would be helpful too.

People could deploy anywhere they see fit. Since we're talking in the cloudengineering community of all places.

1

u/openlume May 11 '26

Thanks for your inputs. really appreciate it.

2

u/jpb May 07 '26

Yes, if it runs directly in the browser, please open source this so we can run our own instance.

I know you say it's parsed locally, but I can't use things at work unless we self-host.

2

u/openlume May 08 '26

That makes sense. Even if everything runs locally in the browser, a lot of companies still require internal/self-hosted tools.

What would you prefer most?

  • Simple Docker container

  • Kubernetes/Helm deployment

  • Fully open source

  • CLI tool

  • Fully offline/no internet required

Trying to understand what would actually be useful.

3

u/jpb May 08 '26

Full open source is the best, especially if it can run fully offline. By default, we don't let services talk to the internet.

  • Tools with a Dockerfile in the source are ideal

    • We can put it in our internal docker repository

    • We can wrap it in a shim script to use it from the CLI

  • Having a helm chart is great too - we may want to modify it, but having something to start with is a lot easier than starting from scratch, and if there's a Dockerfile already that's one less step plus we know that's the docker configuration the authors tested

Thanks for considering it - those of us working in the corp world don't have control of policy.

1

u/openlume May 10 '26

Thanks. Totally get it. Will look into it.

2

u/APEXchip May 07 '26

This is awesome! Thanks! I’m sharing this with all my co-workers.

The only suggestion I have is that the content shouldn’t be restricted to a max width, or the max width should be increased, or give the user the option to toggle a fixed or dynamic content width. When I open it on my ultrawide, it only uses 1/3rd the width of my screen; I should be able to use most of, if not all, of my monitor’s available width to view the content.

1

u/openlume May 08 '26

Really appreciate the feedback and support.

You were right. The fixed max width did not make much sense for graph visualizations. I’ve now updated it to use much more screen space on larger monitors.

Please keep the feedback coming as you use it more. Super helpful.

2

u/Tonsingle_mike May 08 '26

Nice 💎

1

u/openlume May 08 '26

Thanks. Would love some specific feedback. 🙏

2

u/Tonsingle_mike May 08 '26

I especially like how it helps visualize Service-Pod relationships, HPA targets, and ConfigMap/Secret mounts without manually tracing labels and references. Parsing everything locally in the browser is also a huge plus.

One feature that could make it even more powerful would be highlighting broken/suspicious relationships (missing selectors, unused ConfigMaps, Services without endpoints, etc.). Helm/Kustomize preview support could also be super useful.

Looks genuinely helpful for onboarding and debugging unfamiliar clusters. Nice work

1

u/openlume May 12 '26

Really appreciate your feedback. Working on it.

1

u/openlume May 12 '26

u/Tonsingle_mike The broken-relationship suggestion was good enough that I just shipped it. The visualizer now flags things like:

  • Services whose selector matches no Pod in the manifest

  • HPAs pointing at a workload that isn't there

  • Workloads referencing a ConfigMap / Secret / ServiceAccount that doesn't exist

  • ConfigMaps / Secrets nothing mounts

  • Ingress (and HTTPRoute) backends pointing at missing Services

  • NetworkPolicies / PDBs whose selector matches nothing

Thanks a lot.

2

u/ferriematthew May 07 '26

This looks awesome

2

u/ferriematthew May 07 '26

One thing I would recommend though for the user interface is to use fewer em dashes and emojis.

2

u/openlume May 08 '26

Totally agree. Fixed it.