[HN Gopher] Show HN: Kr8s - a Python client library for Kubernetes
___________________________________________________________________
Show HN: Kr8s - a Python client library for Kubernetes
Hey folks. I'm the author of kr8s. I've been working on kr8s for a
while now and one of my core goals is to build a Python library for
Kubernetes that is the most simple, readable and produces the most
maintainable code. It should enable folks to write clean code when
working with the Kubernetes API. If you're interested in how it
compares with other libraries then check out [this
post](https://jacobtomlinson.dev/posts/2023/comparison-of-
kr8s-vs-...). Happy to answer any questions you might have in the
comments here .
Author : jacobtomlinson
Score : 50 points
Date : 2023-09-13 19:38 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Nullabillity wrote:
| Requesting objects without a specific version/apigroup is pretty
| dangerous, you're effectively opting out of K8s' primary
| backwards compatibility measure.
| ledauphin wrote:
| does this provide sane default behavior for refreshing expired
| auth tokens and retrying random client timeouts? the "official"
| SDK has driven me absolutely crazy trying to wrap all the
| different pieces with retries so that basic long-running
| operations won't randomly raise spurious exceptions...
| kungfufrog wrote:
| This looks great, will be giving it a go today to replace some
| increasingly complex bash scripts!
| jacobtomlinson wrote:
| 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.
| kungfufrog wrote:
| 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!
| usrk0123961 wrote:
| Why not just use the official python kubernetes client?
| https://github.com/kubernetes-client/python
| dharmab wrote:
| 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.
| jacobtomlinson wrote:
| Kr8s already has things like port forwarding and I'm
| working on apply right now. Exec is next on my list
| jacobtomlinson wrote:
| 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.
| alpb wrote:
| 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?
| jacobtomlinson wrote:
| 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.
| galenmarchetti wrote:
| 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
| aknfxb3m wrote:
| I stopped at the 3rd example. Kr8s and lightkube are the only
| solutions I'd dare to use.
| jacobtomlinson wrote:
| Lightkube is also awesome. The focus of kr8s is on simplicity,
| similarity to kubectl and having batteries-included. Lightkube
| focuses on type safety and API correctness.
|
| They also work together and you can cast Lightkube objects to
| kr8s and back again.
| cpressland wrote:
| I have literally just spent the last few weeks writing pydantic
| models for Kubernetes for an internal testing tool. I'll see how
| this compares, it looks outstanding.
| jacobtomlinson wrote:
| Thanks!
| theptip wrote:
| In the past I used PyKube
| (https://pykube.readthedocs.io/en/latest/readme.html), which did
| the job. One issue that pykube has is that there is no
| autocomplete on API object fields. Does kr8s wire this up? Seems
| you could use a TypedDict on newer versions of Python.
|
| Back in the old days you wouldn't get autocomplete on k8s YAML
| files either, but now the schema is well-known and so your IDE
| will complete all the fields (even CRDs). These days you get this
| with Pulumi, if I'm not mistaken.
| jacobtomlinson wrote:
| I'm not exactly sure what you mean but we can definitely
| improve auto completion if that's valuable. Maybe you could try
| it out and give us some feedback in an issue?
| uneekname wrote:
| This is awesome. Jacob, your work on Dask Kubernetes has been
| immensely helpful to me. The world of distributed Python grows
| stronger!
| jacobtomlinson wrote:
| Thanks!
| dbragdon wrote:
| Awesome library, but I can't view the documentation at work since
| the doc site uses http. Please consider using https.
| whalesalad wrote:
| https://docs.kr8s.org/en/latest/
| jacobtomlinson wrote:
| The docs does use https. Let me know where you found an http
| link so I can fix it.
|
| https://docs.kr8s.org/en/latest/
| gustavus wrote:
| The cycle of tooling
|
| Step 1: Look I've made this new great tool that uses a
| declarative language, you simply declare what you want your
| environment to look like and boom it will build it out. No more
| having to figure out a complicated logic flows that can fail or
| having code that dies on weird error cases, and you don't have to
| be a developer to use it.
|
| Step 2: The tool isn't powerful or flexible enough and the
| declarative code is getting to cumbersome so we've introduced
| some basic templating and logic flow to this tool to make it more
| flexible and reduce bloat.
|
| Step 3: The control flow isn't powerful enough to really meet our
| needs so we have moved it entirely to a full programming
| language.
|
| Step 4: Go back to step 1.
| [deleted]
| aknfxb3m wrote:
| Steps 1,2,3 create separate solutions that people can use as
| they see fit. You make it seem like there is no place for
| anything but a declarative programming language in this area.
| hitchstory wrote:
| It's often better to provide both - especially for something
| like k8s. Declarative languages and programming languages serve
| entirely different use cases.
|
| They no more preclude each other than garbage collected and non
| garbage collected programming languages like C and python do.
| jacurtis wrote:
| To be fair... k8s offers both:
|
| Write declarative code with yaml and kubectl. This solves
| most use cases and interactions.
|
| Write operators in a variety of languages (usually golang) if
| you need direct control of the underlying control loop,
| advanced resources, and other use cases to extend or
| customize how your cluster works. This is far more flexible
| and powerful than most people understand and of itself has
| layers ranging from moderate to very complex.
|
| Furthermore there is the api aggregation layer you can extend
| if you need to customize the core api of your cluster.
| bjt12345 wrote:
| How do you connect remotely? The examples don't easily show this.
| jacobtomlinson wrote:
| The same way you do with kubectl, you configure your cluster in
| your kube config file. We can definitely add more examples
| though!
| multani wrote:
| This looks really cool!
|
| I wrote a few applications using both the official Kubernetes
| client and the asyncio variant from Tomasz. Both have the same
| problems to me (that you exposed on the comparison page):
|
| The documentation is really terrible (it's even non-existent for
| kubernetes-asyncio). For the official client, it's hidden deep
| inside the repository, across _hundreds_ of files (592 at the
| moment); half the link cross doc don 't work, there are rendering
| issues, etc. It's really a gigantic mess.
|
| The API is extremely verbose, directly the underlying Kubernetes
| API exposed to Python. It gets the job done and it's better than
| shell script, but the verbosity + the total lack of a decent
| documentation (cf. above) makes it hard to use and see what you
| can do with it. Most of the time, you have to fire the REPL and
| try a bunch of calls until it makes sense. I like that most of
| the responses are proper objects, but they display as dict in the
| REPL and of course, the responses format are not documented in
| the doc :)
|
| Last but not least: they both lack support for fancy
| authentication mechanism. We go to Kubernetes through a fancy
| proxy that require specific TLS settings + an external exec
| plugin to get the credentials. The official Kubernetes client
| should have the right support (for what we need at least) in the
| next major version but the asyncio variant not yet (I made a PR
| to fix this, but this requires a new version of aiohttp which is
| not released yet...) Both clients are very similar for the
| autogenerated code, but also subtly different for all the things
| around so you can't really expect 100% that what works on one
| will work on the other.
|
| I'm not sure how kr8s works with this fancy auth system, but at
| least for the first 2 points, it seems like a huge win, I'll give
| it a try!
| jacobtomlinson wrote:
| Awesome thanks! Kr8s supports the exec auth and TLS options. If
| you run into anything that's missing though please raise an
| issue and we will get it added.
| bjt12345 wrote:
| .
| willthames wrote:
| The comparison doesn't include the (perhaps confusingly named)
| openshift library. All the ansible kubernetes modules rely
| heavily on it because its support for dynamic client (where you
| just want to apply a manifest and don't know in advance that it's
| a Deployment and a Service and a ConfigMap) is first rate.
| jacobtomlinson wrote:
| Wow I've not heard of that one! Do you have a link?
___________________________________________________________________
(page generated 2023-09-13 23:00 UTC)