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 .
Kr8s is modelled after kubectl instead of the REST API to try and be more accessible to developers.
I'm about to run my first bit of kr8s code!
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.
They no more preclude each other than garbage collected and non garbage collected programming languages like C and python do.
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.
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!
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.
If we have:
pod = Pod({
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "my-pod",
},
"spec": {
"containers": [{"name": "pause", "image": "gcr.io/google_containers/pause",}]
},
})
I am unlikely to be talking about Rust crates anywhere near the same conversation as kr8s code.
Krewbernetes?
Krates?
with Pod().read(name='thename', namespace='the-namespace') as p:
p.labels['new-label'] = 'value'They also work together and you can cast Lightkube objects to kr8s and back again.
Wish I had seen this thread before my talk, but the YouTube video will be online soon and I can link to it when they are uploaded.