Add support for deploying custom resources

[chinthanep-asml]

No description provided.

[pablochacin]

With the changes introduced in #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 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

"CronTab":  {Group: "crontabs.stable.example.com`", Version: "v1", Resource: "crontabs"},

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

[pablochacin]

#85 should make it possible to manipulate CRDs with this extension, but until #86 is completed we cannot ensure this.