from Hacker News

Show HN: Kubernetes Spec Explorer

by goenning on 12/12/24, 3:02 PM with 30 comments

• by abuckenheimer on 12/12/24, 4:42 PM

  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.

• by emmanueloga_ on 12/12/24, 11:09 PM

  The most frustrating part of Kubernetes (and I like k8s) is its data schema story:

  * Go types are converted to Protobuf via go-to-protobuf.

  * Protobuf generates OpenAPI specs and JSONSchemas via kube-openapi.

  * Users rely on tools and DSLs to manage the complexity of YAML manifests.

  This pipeline prioritizes some convenience for the core team over simplicity for end users. In the end, that minimal convenience transmutes into layers of convoluted code generators to maintain for the core team, and unwieldy, tens-of-thousands-of-lines schemas for the end users.

  Also, does Kubernetes really benefit enough from Protobuf to justify the complexity? k8s IPC and network traffic likely account for a small fraction of overall app traffic. Perhaps JSON and schemas for validation could be enough.

  The proliferation of tools to manage YAML manifests is a sign of room for improvement. Perhaps a "k8s 2.0" could start with JSONSchemas: this could encourage minimal, flat, simple, and user-friendly schemas, and hopefully a more coherent internal pipeline.

• by joushx on 12/12/24, 9:21 PM

  Please note that kubectl also contains something similar: e.g. kubectl explain deployment.spec

• by leg100 on 12/12/24, 6:34 PM

  I like the version diffs.

  Perhaps add an "expand all" button to avoid clicking individually on properties to see their descriptions?

  I usually rely on the official generated docs (all on one giant page):

  https://kubernetes.io/docs/reference/generated/kubernetes-ap...

• by fikama on 12/12/24, 9:36 PM

  Official Kubernetes docs are terrible. No versioning (most of the links on the internet are dead). A lot of text with not much exmaples. This one looks nice. Spec with full list of options, version history and examples. That's everything anyone would need. It reminds me of my favorite ansible documentation/spec which is a pleasure to use. Love it

• by robinhoodexe on 12/12/24, 4:38 PM

  Very nice!

  Adding support for CRDs would be very nice. Maybe look up popular CNCF projects and find their official helm charts, that contain the CRDs?

• by vbezhenar on 12/12/24, 5:11 PM

  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).

• by hintymad on 12/13/24, 12:25 AM

  A naive question: why does k8s require more documentation and understanding than using EC2 + EBS, if I don't have to consider cost. To set up my infrastructure, I launch clusters for my services, I map EBS or use ephemeral storage for stateful services. I use EC2's APIs to operate my clusters, such as autoscaling and auto healing. I don't have to worry about networking except probably private IP vs public IP. I barely need to spend time learning about EC2/EBS and simply use my intuitive to look up documentation when needed. Most of the EC2/EBS concepts are just intuitive. So, why do so many people say that k8s is complex and hard to get right? Shouldn't the default setup as easy as EC2+EBS, and leave the doors to more advanced stuff?

• by keisku on 12/14/24, 12:31 AM

  This CLI should solve similar issues!

  https://github.com/keisku/kubectl-explore

• by imcritic on 12/12/24, 9:31 PM

  If you only knew how I hate and struggle with the official docs and how your service is a very needed breath of fresh air! Thank you a lot!

• by JohnMakin on 12/12/24, 6:23 PM

  This is so awesome and at a glance far better than the official documentation. Thank you!

• by astonex on 12/13/24, 4:36 PM

  This is great thank you. Been a k8s admin for many years but obviously still need to look up fields from time to time, and trying to find it or an example in the k8s documentation is always difficult

• by wpm on 12/12/24, 4:50 PM

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

• by elliot07 on 12/13/24, 6:40 AM

  It would be great if you could paste in an existing k8s file to analyze as well. Would help for onboarding/modifying existing templates you haven't worked on in awhile, etc.

• by JeffMcCune on 12/12/24, 7:49 PM

  Very nice, would love to see a kubectl explain type plugin to integrate with this somehow.

• by nosefrog on 12/12/24, 5:46 PM

  Very cool! Finding the Kubernetes API docs is such a pain.

• by lormayna on 12/12/24, 6:57 PM

  Thank you! This is really really useful

• by swills on 12/12/24, 8:58 PM

  Looks very nice! Thanks!

• by pythops on 12/13/24, 9:48 AM

  Really nice, GJ !

• by devops99 on 12/12/24, 4:47 PM

  Nice.