search

Arnavion / k8s-openapi

Rust definitions of the resource types in the Kubernetes client API
Apache License 2.0
373 stars 42 forks source link

How to use dymanically discovered api endpoints? #108

Closed nicklan closed 2 years ago

nicklan commented 2 years ago

Using https://arnavion.github.io/k8s-openapi/v0.12.x/k8s_openapi/fn.get_api_versions.html one can discover endpoints for deployed CRDs (as described here).

So if I get an APIGroup that includes a version saying groupVersion is stable.example.com/v1 I know there's an endpoint I can hit at /apis/stable.example.com/v1/ to discover what resources might exist there.

Are there any facilities in the crate to deal with this? I'm considering just building a dynamic type that implements all the required traits to make this a "normal" resource, but I wanted to check if there was a better way to do it already. Thanks!

Arnavion commented 2 years ago

It depends on what you know at compile-time and what you only know at runtime.

  1. Do you know what the CRD looks like at compile-time, just not whether it was actually registered with the cluster or not? If so, you can implement it at compile-time with [#[derive(k8s_openapi_derive::CustomResourceDefinition)](https://arnavion.github.io/k8s-openapi/v0.12.x/k8s_openapi_derive/derive.CustomResourceDefinition.html) and then choose whether or not to use it based on what the discovery API says.

  2. Do you not know anything about the CRD at all, and want to compile a binary specific to whatever cluster it's going to be used for? If so, you can ignore the k8s-openapi crate and instead generate your own one using k8s-openapi-codegen against your cluster's OpenAPI spec. Since your cluster's spec will include that CRD, the generated code will too.

  3. Do you not know anything about the CRD at all, and want to have a single binary that works with clusters that have it or don't? If so, this repo doesn't have much to help with, except maybe giving you inspiration of how you want to structure the dynamic API operations based on what the custom derive in (1) generates. You may find https://docs.rs/kube/0.60.0/kube/discovery/index.html more useful.

nicklan commented 2 years ago

Yep, I should have mentioned that this is totally dynamic, since it's for https://github.com/databricks/click, so it needs to work across arbitrary clusters. So that puts me in 3, which is what I was guessing.

Thanks for the pointer, that will likely help with my implementation.