These low-level constructs in the client libraries exist so that people can build controllers and operators on top of it, no? There's a lot that goes into making of implementing a Kubernetes client such as keeping up with semantic changes (dry run, server-side apply, tracing, rate limiting, patch support etc). Does your library also cover these?
Anything you can do with the official library you can do with kr8s. Some things will require writing low level HTTP requests if we haven’t implemented them yet, but it’s not so different to the official low level auto generated API.
The goal here is to make easy things easy, while ensuring anything is possible.
Comments
I built kr8s because the official autogenerated library is extremely verbose, low level and hard to use.
Kr8s is modelled after kubectl instead of the REST API to try and be more accessible to developers.
These low-level constructs in the client libraries exist so that people can build controllers and operators on top of it, no? There's a lot that goes into making of implementing a Kubernetes client such as keeping up with semantic changes (dry run, server-side apply, tracing, rate limiting, patch support etc). Does your library also cover these?
Anything you can do with the official library you can do with kr8s. Some things will require writing low level HTTP requests if we haven’t implemented them yet, but it’s not so different to the official low level auto generated API.
The goal here is to make easy things easy, while ensuring anything is possible.