Hacker News Reader

Comment by usrk0123961 | Hacker News Reader

Why not just use the official python kubernetes client? https://github.com/kubernetes-client/python

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.

The official python client does not have feature parity with kubectl; I had to reimplement parts of kubectl in my own scripts, like the 'apply' and 'exec' subcommands and less-flaky CRD deployments.

Kr8s already has things like port forwarding and I’m working on apply right now. Exec is next on my list

here, take my code: https://github.com/dharmab/homelab-k3s/blob/2f46393aeeb73673...

Heh thanks. We are trying to avoid binary dependencies like kubectl because you can’t install the with pip.

that exec function is pure python, and the order of operations in that deploy function is important (initial deployment of resource out of order will likely either fail outright or cause certain Pods to fail to become read)

seconding the answer given by OP...I've also found the raw clients very low level and hard to use. I appreciate the higher level abstraction here, emphasis on "batteries included" and usability mirroring kubectl

Reply on news.ycombinator.com