Hacker News Reader

Hacker News

Comment by kungfufrog | Hacker News Reader

Full thread

kungfufrog

This looks great, will be giving it a go today to replace some increasingly complex bash scripts!

View on HN

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.

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

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)

Awesome! Let me know how you get on and don't hesitate to open issues if you run into problems or have thoughts about the API design.

Without opening a philosophical discussion on Python package management what were the pragmatic reasons from switching from Poetry to Hatch?

I'm about to run my first bit of kr8s code!

Poetry is a locking package manager. That’s extremely useful for applications where you don’t want dependencies to drift. However for a library you want pinning a to be looser so the benefits of poetry aren’t as strong. Given that hatch is the official method from the PyPA it felt like a better choice.

Reply on news.ycombinator.com