For custom resources, two mappings are needed: one for supporting the creation of CustomResourceDefinition objects, which can be trivially added to the mapping described above, and one introduced by the custom resource definition itself. This second mapping is now know until the resource CurstomResourceDefinition and must be somehow provided.
The example below helps to clarify this distinction. The yaml describes a CustomResoruceDefinition that introduces a new custom resource of kind CronTab that is mapped to the resource crontabs in the resource group crontabs.stable.example.com with version v1. This resource should therefore be added to the list of known kinds as
How This mapping can be dynamically introduced is the main issue for implementing the support for CRDs. Some options are:
Dynamically retrieve the supported api resources from the api server (in a similar way that the kubectl api-resources command does)
Create a function in the API for registering CRDs. This function would create the CRD and register the resource in the list of known kinds.
Example of a Custom Resource Definition
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# name must match the spec fields below, and be in the form: <plural>.<group>
name: crontabs.stable.example.com
spec:
# group name to use for REST API: /apis/<group>/<version>
group: stable.example.com
# list of versions supported by this CustomResourceDefinition
versions:
- name: v1
# Each version can be enabled/disabled by Served flag.
served: true
# One and only one version must be marked as the storage version.
storage: true
# either Namespaced or Cluster
scope: Namespaced
names:
# plural name to be used in the URL: /apis/<group>/<version>/<plural>
plural: crontabs
# singular name to be used as an alias on the CLI and for display
singular: crontab
# kind is normally the CamelCased singular type. Your resource manifests use this.
kind: CronTab
# shortNames allow shorter string to match your resource on the CLI
shortNames:
- ct
With the changes introduced in https://github.com/grafana/xk6-kubernetes/pull/70 it should be relatively easy to support custom resources as the API now works on generic resources (instead of been segregated by resource type). However, it implementation of this API requires to know the mapping between the resource Kind and the resource.
For custom resources, two mappings are needed: one for supporting the creation of
CustomResourceDefinition
objects, which can be trivially added to the mapping described above, and one introduced by the custom resource definition itself. This second mapping is now know until the resourceCurstomResourceDefinition
and must be somehow provided.The example below helps to clarify this distinction. The yaml describes a
CustomResoruceDefinition
that introduces a new custom resource of kindCronTab
that is mapped to the resourcecrontabs
in the resource groupcrontabs.stable.example.com
with versionv1
. This resource should therefore be added to the list of known kinds asHow This mapping can be dynamically introduced is the main issue for implementing the support for CRDs. Some options are:
kubectl api-resources
command does)Example of a Custom Resource Definition