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!
Show HN: Kubernetes Spec Explorer
21–30 of 33 posts
Re: Show HN: Kubernetes Spec Explorer
#22Official 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
Re: Show HN: Kubernetes Spec Explorer
#23This 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…
I find this hard-to-find official documentation so much easier to read: https://kubernetes.io/docs/reference/generated/kubernetes-ap...
In my opinion, it comes with better navigation, safe to open in new tabs to drill-deep and unwind when done, much better use of horizontal space. Even though it is generated, I looks to have much of the exact same text?
Re: Show HN: Kubernetes Spec Explorer
#24The 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.
Re: Show HN: Kubernetes Spec Explorer
#25A 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?
Re: Show HN: Kubernetes Spec Explorer
#26A 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 barel…
If you're so good you can intuite your way through AWS, you're good enough to do the same with K8s. It's about the same level of complexity, really. Don't listen to juniors who saw a cloud for the first time, shit the bed and went back to deploying onto something that looks more like their laptop.
Start with Minikube on Ubuntu via Snap if you want the really easy way. Deploy that on Hetzner or something using Cloud-init. Auto cluster discovery is a job for one evening. I like to use Pulumi or Terraform to see what I can play with on a cloud provider and operate it in a sane way.
And I use the K8s provider too: https://registry.terraform.io/providers/hashicorp/kubernetes...
Re: Show HN: Kubernetes Spec Explorer
#27It 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.
Re: Show HN: Kubernetes Spec Explorer
#28Please note that kubectl also contains something similar: e.g. kubectl explain deployment.spec
TIL
Re: Show HN: Kubernetes Spec Explorer
#29Really nice, GJ !
Re: Show HN: Kubernetes Spec Explorer
#30The 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 transmu…
k8s API is complex, a good fit for Protobuf, IMO, a poor fit for YAML.