Live data from Hacker News

Show HN: Kubernetes Spec Explorer

kubespec.dev

1–10 of 33 posts

Show HN: Kubernetes Spec Explorer

#1
I built an interactive explorer for Kubernetes resources spec

A few things included:

- Tree view with schema, type and description of all native resources - History changes since version X (properties added/removed/modified) - Examples of some resources that you can easily copy as a starting point - Supports all versions since X, including the newly released 1.32 - I also want to add support for popular CRD, but I’m not sure how I’ll do that yet, I’m open to suggestions!

Everything is auto generated based on the OpenAPI spec, with some manual inputs for examples and external links.

Hope you like it and if there’s anything else you think it could be useful just let me know.

Show HN: Kubernetes Spec Explorer
kubespec.dev

Re: Show HN: Kubernetes Spec Explorer

#3
This is really nice! The context switching that comes from using the [official k8s reference](https://kubernetes.io/docs/reference/kubernetes-api/workload...) is a real pain. If your writing a deployment and need to check one thing about the pod spec all of a sudden you jump to a new page and lost where you were. Ontop of that this keeps track of the indentation level the spec your looking at within the context of whatever parent path your writing it for.

Maybe one nitpick would be to keep colon between the key and the type so one can copy paste multiple lines of relevant spec to be filled in your editor easily.

Re: Show HN: Kubernetes Spec Explorer

#6
post #5

This is what the official reference docs should look and work like. Well done.

I gravely disagree because having to click to open the description in the leaf nodes makes command-f not work. I would link to an example but it doesn't support permalinks and because they are all collapsed #:~:text=fieldRef doesn't work either

This also has a UX implication because let's say one wished to know what values could go into envFrom[].fieldRef.fieldPath so they click on fieldPath to expand that node. It says, unhelpfully, "Path of the field to select in the specified API version." and then they go on HN to bitch about how complicated kubernetes is. When in reality they wanted to click on "fieldRef" itself, which coughs up "Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['']`, `metadata.annotations['']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs." but only if you knew to click on it

Contrast that with https://kubernetes.io/docs/reference/generated/kubernetes-ap... (which, yes, takes 500 million years to load but works)

Re: Show HN: Kubernetes Spec Explorer

#8
Why order of fields is different? Example:

https://kubespec.dev/apps/v1/Deployment https://kubernetes.io/docs/reference/kubernetes-api/workload...

    minReadySeconds: integer
    paused: boolean
    progressDeadlineSeconds: integer
    ...
vs

    selector
    template
    replicas
    minReadySeconds
    ...
I'm very nitpicky about order of fields and I always follow kubernetes documentation order. Not sure where it really comes from, but generally it's good enough and better than alphabetical order (or inconsistent order).

Re: Show HN: Kubernetes Spec Explorer

#10

Why order of fields is different? Example: https://kubespec.dev/apps/v1/Deployment https://kubernetes.io/docs/reference/kubernetes-api/workload... minReadySeconds: integer paused: boolean progressDeadlineSeconds: integer ... vs selector template replicas minReadySeconds ... I'm very nitpicky about order of fields and I always follow kubernetes documentation order. Not sure where it really comes from, but generally it…

[deleted]
Post reply on HN