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

[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

• 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

• https://pkg.go.dev/k8s.io/client-go/discovery#NewDiscoveryClientForConfig

Tests

• Test the gateway with standard kubernetes types like configmaps or deployments against a local kind cluster for example.

[vertex451]

meeting notes(08.11.24):

1. Check if we can do hot reload(update) of grapqhl schema without restarting the service
2. Dynamically add new endpoints when a new API server(KCP workspace) is added. The same is for the removal.

[vertex451]

Tasks:

1. Create a Workspace Manager and integrate it with schema/endpoints generation. (@vertex451)
2. Create a Event Listener and integrate it with Workspace Manager. (@fourthisle)
3. Write integration tests for it.

[vertex451]

UPD:
This issue is moved here #48

Just found an issue of the fields with oneOf statement:

        "targetPort": {
          "oneOf": [
            {
              "type": "integer",
              "format": "int32"
            },
            {
              "type": "string"
            }
          ]
        },

The issue were spotted in Service, when I tried to pass "8080" as target port, and K8S validation failed because in case of string, non-numeric value is expected.
And the problem is that my graqphl schema doesn't support int.
Leaving it here, will fix after.

[aaronschweig]

Current gaps for KCP integration

• Deploy a Gateway that is able to work with different workspaces in KCP based on its request path

  • Per Request cluster url adjustment of the rest.Config
  • Per Request token adjustment of the client

• Create a helm-chart that deploys the gateway and the schema-generator

  • Make sure both services are able to work together
  • Identify missing pieces of the discovery and KCP integration
  • Dockerfile
  • Documentation

• Integrate it into the central pipeline

  • Add workflow files
  • Test coverage
  • Linting

• Ensure at the local-setup first, that a deployed version of the service is working

  • Proper OIDC configuration of KCP and the cluster
  • All necessary permissions for the service are present
  • How does the kubeconfig need to look like in order for it to properly work in a real environment
  • Make sure all the necessary configuration is in place in the helm chart as well as locally

• Make RESTMapper gateway specific, figure out if you need it at all, if yes - take it from spec

[vertex451]

UPD:
Moved to #49

Follow up tasks after PoC:

crd-gql-gateway

• fix UI overlay issue Adjust CRD Gateway to be based on api-resources instead of CRDs #4 (comment)
• Cleanup listnener Taskfile and adjust root taskfile to run tests
• Implement otel tracing for the subscriptions
• Remove dirs and files from test coverage exclude section
• Improve tests coverage
• Remove t.Skip() in tests
• Addess Adjust CRD Gateway to be based on api-resources instead of CRDs #4 (comment)
• Document local setup
• Actualize README
• (clarify it) Integrate crd-gql-gateway inside openmfp deployment https://github.com/openmfp/helm-charts-priv/blob/415dfc386ac0e881fe57fa517dfe67ae932d9d54/charts/openmfp/Chart.yaml#L23-L26

chart

• chart should work out of the box with the default values
• chart should use commons construction

[vertex451]

UPD:
Fixed in #37