What is the advantage of pykube-ng vs official Kubernetes Python client?

[SongGithub]

there is an official lib

And when choosing a Python lib for a k8s project, what is pro/con of choosing this lib? I guess you and the original author would know this fact best.

[hjacobs]

Yes, we should add this information to the README:

• pykube-ng is much more "Pythonic" and opinionated than the official Kubernetes Python client
• pykube-ng uses the human-friendly requests library and plays nice with it (the official Python client uses urllib3 from Swagger-Codegen)
• pykube-ng is lightweight and has nearly no dependencies (the official client pulls in a ton of dependencies, some only for specific cloud providers)
• pykube-ng does not generate any code, i.e. the code should be well understood and readable (probably not 100% the case) and is not "boilerplate autogenerated by some tool"
• pykube-ng is much smaller (switching from the official Python client to pykube-ng saves ~21MB (!), see Switch to pykube-ng as Kubernetes client kube-resource-report#69 (comment))

There are obviously some downsides:

• pykube-ng does not generate any code, i.e. Kubernetes API changes currently need to manually be updated in the library
• pykube-ng does not have full cloud-provider support (custom authentication mechanisms)
• pykube-ng does not have full API support (but everything can be called/added if needed), e.g. paging is not implemented (API response paging for large data sets #8)
• pykube-ng is not part of the official Kubernetes org
• probably other downsides I can't see right now because I'm biased 😏

So for me it's mostly about having a lightweight library to interact with the Kubernetes API when not needing a full-blown client with many dependencies. So it's near perfect for my use cases (kube-janitor, kube-downscaler, kube-ops-view, kube-resource-report), but maybe not the right choice for others.

[hjacobs]

@SongGithub as pykube-ng is opinionated, I also want to discuss the future pykube-ng API interface, see #13

[SongGithub]

thanks for your reply! I think if we value portability among infrastructures, not mandating custom authentication mechanisms is actually a benefit.

[igor47]

i really like that this client uses python dictionaries to specify resources. this means you can keep your resources in standard-looking yaml files and apply them by invoking kubectl, but also programmatically apply them without resorting to shelling out to kubectl. using the official API client, converting between a dictionary representation and the expected object representation is a PITA.

[hjacobs]

FYI: a colleague of mine created a high-level Python Operator Framework ("Kopf") which makes it really easy to create operators for CRDs with just a few lines of Python: https://github.com/zalando-incubator/kopf

[ekhaydarov]

@hjacobs a bit off topic, sorry for hijacking thread.

I am trying to interact with a custom operator and not sure how to do it with pykube. The last comment you left leads me to believe it should be possible but im not sure I can find the documentation for it. ThirdPartyResource doesnt seem to be it.

For completeness I am trying to interact with https://github.com/GoogleCloudPlatform/spark-on-k8s-operator. If anyone could point in the right direction. That would be great

[hjacobs]

@ekhaydarov what do you want to do? Do you want to modify a CRD resource?

You can always create a custom class for custom resources and use it, e.g.:

class SparkApplication(NamespacedAPIObject):

    version = "sparkoperator.k8s.io/v1beta1"
    endpoint = "sparkapplications"
    kind = "SparkApplication"    

api = pykube.HTTPClient(pykube.KubeConfig.from_env())
for sparkapp in SparkApplication.objects(api):
    print(sparkapp.name, sparkapp.labels)

This would create a class for the CRD referenced here: https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/manifest/spark-operator-crds.yaml#L18