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