Closed
Description
Description
Currently the CRD graphql gateway determines dynamically a graphql schema based on the the available and configured CRD definitions in a kubernetes cluster.
Task
Instead of using the CRD's as a basis the gateway should be adjusted to use the available api-resources in order to also work with kubernetes api server extensions and core kubernetes types which are not CRDs.
Solution Path
- Explore if the available open api definition which is exposed by the API server can be used for schema generation.
- Consider caching and performance considerations so that the gateway responds in a quick manner
Acceptence Criteria
- As a developer creating a graphql gateway, i can pass a scheme containing types that are available in the api of k8s. That are not custom resources. eg: i can pass https://pkg.go.dev/k8s.io/api/core/v1#pkg-variables like
utilruntime.Must(v1.AddToScheme(scheme.Scheme))
To my scheme. Then i see the resources like Pod
and ConfigMap
in the graphql schema.
- As a user of the graphql gateway, i can see all the resources that are in the scheme and the openapi definition in the same graph, to query the kubernetes api server.
Technical Details
- In all api requests to the kubernetes api server In all cases, the controller runtime package is used to is used as a client, since the unstructured client does not cache and has rate limits. Objects that are not in the scheme can currently not be fetched. If we want this in the future, we will do this with a dedicated task.
- Tests should be written, in other graphql projects we used apitest to perform the tests. For the faking of k8s objects the fake client should be used. Everything should run in the same process in memory
Useful Links
Tests
- Test the gateway with standard kubernetes types like configmaps or deployments against a local kind cluster for example.