Reference Documentation

Design docs, concept definitions, and references for APIs and CLIs.

Edit This Page

Third Party Resources

What is ThirdPartyResource?

Kubernetes comes with many built-in API objects. However, there are often times when you might need to extend Kubernetes with their own API objects in order to do custom automation.

ThirdPartyResource objects are a way to extend the Kubernetes API with a new API object type. The new API object type will be given an API endpoint URL and support CRUD operations, and watch API. You can then create custom objects using this API endpoint. You can think of ThirdPartyResources as being much like the schema for a database table. Once you have created the table, you can then start storing rows in the table. Once created, ThirdPartyResources can act as the data model behind custom controllers or automation programs.

Structure of a ThirdPartyResource

Each ThirdPartyResource has the following:

The kind for a ThirdPartyResource takes the form <kind name>.<domain>. You are expected to provide a unique kind and domain name in order to avoid conflicts with other ThirdPartyResource objects. Kind names will be converted to CamelCase when creating instances of the ThirdPartyResource. Hypens in the kind are assumed to be word breaks. For instance the kind camel-case would be converted to CamelCase but camelcase would be converted to Camelcase.

Other fields on the ThirdPartyResource are treated as custom data fields. These fields can hold arbitrary JSON data and have any structure.

You can view the full documentation about ThirdPartyResources using the explain command in kubectl.

$ kubectl explain thirdpartyresource

Creating a ThirdPartyResource

When you user create a new ThirdPartyResource, the Kubernetes API Server reacts by creating a new, namespaced RESTful resource path. For now, non-namespaced objects are not supported. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. ThirdPartyResources themselves are non-namespaced and are available to all namespaces.

For example, if a save the following ThirdPartyResource to resource.yaml:

apiVersion: extensions/v1beta1
kind: ThirdPartyResource
description: "A specification of a Pod to run on a cron style schedule"
- name: v1

And create it:

$ kubectl create -f resource.yaml
thirdpartyresource "" created

Then a new RESTful API endpoint is created at:


This endpoint URL can then be used to create and manage custom objects.

Creating Custom Objects

After the ThirdPartyResource object has been created you can create custom objects. Custom objects can contain custom fields. These fields can contain arbitrary JSON. In the following example, a cronSpec and image custom fields are set to the custom CronTab object. If you save the following YAML to my-crontab.yaml:

apiVersion: ""
kind: CronTab
  name: my-new-cron-object
cronSpec: "* * * * /5"
image: my-awesome-cron-image

and create it:

$ kubectl create -f my-crontab.yaml
crontab "my-new-cron-object" created

You can then manage our CronTab objects using kubectl. Note that resource names are not case-sensitive when using kubectl:

$ kubectl get crontab
NAME                 LABELS    DATA
my-new-cron-object   <none>    {"apiVersion":"","cronSpec":"...

You can also view the raw JSON data. Here you can see that it contains the custom cronSpec and image fields from the yaml you used to create it:

$ kubectl get crontab -o json
    "kind": "List",
    "apiVersion": "v1",
    "metadata": {},
    "items": [
            "apiVersion": "",
            "cronSpec": "* * * * /5",
            "image": "my-awesome-cron-image",
            "kind": "CronTab",
            "metadata": {
                "creationTimestamp": "2016-09-29T04:59:00Z",
                "name": "my-new-cron-object",
                "namespace": "default",
                "resourceVersion": "12601503",
                "selfLink": "/apis/",
                "uid": "6f65e7a3-8601-11e6-a23e-42010af0000c"


Create Issue Edit This Page