Skip to content

Adjust CRD Gateway to be based on api-resources instead of CRDs #4

Closed
@nexus49

Description

@nexus49

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

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions