whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Release docs for Kubernetes 1.11 (#9171)

Browse Source 
* Seperate priority and preemption (#8144)

* Doc about PID pressure condition. (#8211)

* Doc about PID pressure condition.

Signed-off-by: Da K. Ma <klaus1982.cn@gmail.com>

* "so" -> "too"

* Update version selector for 1.11

* StorageObjectInUseProtection is GA (#8291)

* Feature gate: StorageObjectInUseProtection is GA

Update feature gate reference for 1.11

* Trivial commit to re-trigger Netlify

* CRIContainerLogRotation is Beta in 1.11 (#8665)

* Seperate priority and preemption (#8144)

* CRIContainerLogRotation is Beta in 1.11

xref: kubernetes/kubernetes#64046

* Bring StorageObjectInUseProtection feature to GA (#8159)

* StorageObjectInUseProtection is GA (#8291)

* Feature gate: StorageObjectInUseProtection is GA

Update feature gate reference for 1.11

* Trivial commit to re-trigger Netlify

* Bring StorageObjectInUseProtection feature to GA

StorageObjectInUseProtection is Beta in K8s 1.10.

It's brought to GA in K8s 1.11.

* Fixed typo and added feature state tags.

* Remove KUBE_API_VERSIONS doc (#8292)

The support to the KUBER_API_VERSIONS environment variable is completely
dropped (no deprecation). This PR removes the related doc in
release-1.11.

xref: kubernetes/kubernetes#63165

* Remove InitialResources from admission controllers (#8293)

The feature (was experimental) is dropped in 1.11.

xref: kubernetes/kubernetes#58784

* Remove docs related to in-tree support to GPU (#8294)

* Remove docs related to in-tree support to GPU

The in-tree support to GPU is completely removed in release 1.11.
This PR removes the related docs in release-1.11 branch.

xref: kubernetes/kubernetes#61498

* Update content updated by PR to Hugo syntax

Signed-off-by: Misty Stanley-Jones <mistyhacks@google.com>

* Update the doc about extra volume in kubeadm config (#8453)

Signed-off-by: Xianglin Gao <xianglin.gxl@alibaba-inc.com>

* Update CRD Subresources for 1.11 (#8519)

* coredns: update notes in administer-cluster/coredns.md (#8697)

CoreDNS is installed by default in 1.11.
Add notes on how to install kube-dns instead.

Update notes about CoreDNS->CoreDNS upgrades as in 1.11
the Corefile is retained.

Add example on upgrading from kube-dns to CoreDNS.

* kubeadm-alpha: CoreDNS related changes (#8727)

Update note about CoreDNS feature gate.

This change also updates a tab as a kubeadm sub-command
will change.

It looks for a new generated file:
generated/kubeadm_alpha_phase_addon_coredns.md
instead of:
generated/kubeadm_alpha_phase_addon_kube-dns.md

* Update cloud controller manager docs to beta 1.11 (#8756)

* Update cloud controller manager docs to beta 1.11

* Use Hugo shortcode for feature state

* kubeadm-upgrade: include new command `kubeadm upgrade diff` (#8617)

Also:
- Include note that this was added in 1.11.
- Modify the note about upgrade guidance.

* independent: update CoreDNS mentions for kubeadm (#8753)

Give CoreDNS instead of kube-dns examples in:
- docs/setup/independent/create-cluster-kubeadm.md
- docs/setup/independent/troubleshooting-kubeadm.md

* update 1.11 --server-print info (#8870)

* update 1.11 --server-print info

* Copyedit

* Mark ExpandPersistentVolumes feature to beta (#8778)

* Update version selector for 1.11

* Mark ExpandPersistentVolumes Beta

xref: kubernetes/kubernetes#64288

* fix shortcode, add placeholder files to fix deploy failures (#8874)

* declare ipvs ga (#8850)

* kubeadm: update info about CoreDNS in kubeadm-init.md (#8728)

Add info to install kube-dns instead of CoreDNS, as CoreDNS
is the default DNS server in 1.11.

Add notes that kubeadm config images can be used to list and pull
the required images in 1.11.

* kubeadm: update implementation-details.md about CoreDNS (#8829)

- Replace examples from kube-dns to CoreDNS
- Add notes about the CoreDNS feature gate status in 1.11
- Add note that the service name for CoreDNS is also
called `kube-dns`

* Update block device support for 1.11 (#8895)

* Update block device support for 1.11

* Copyedits

* Fix typo 'fiber channel' (#8957)

Signed-off-by: Misty Stanley-Jones <mistyhacks@google.com>

* kubeadm-upgrade: add the 'node [config]' sub-command (#8960)

- Add includes for the generated pages
- Include placeholder generated pages

* kubeadm-init: update the example for the MasterConfiguration (#8958)

- include godocs link for MasterConfiguration
- include example MasterConfiguration
- add note that `kubeadm config print-default` can be used

* kubeadm-config: include new commands (#8862)

Add notes and includes for these new commands in 1.11:
- kubeadm config print-default
- kubeadm config migrate
- kubeadm config images list
- kubeadm config images pull

Include placeholder generated files for the above.

* administer-cluster/coredns: include more changes (#8985)

It was requested that for this page a couple of methods
should be outlined:
- manual installation for CoreDNS explained at the Kubernetes
section of the GitHub project for CoreDNS
- installation and upgrade via kubeadm

Make the above changes and also add a section "About CoreDNS".

This commit also lowercases a section title.

* Update CRD subresources doc for 1.11 (#8918)

* Add docs for volume expansion and online resizing (#8896)

* Add docs for volume expansion going beta

* Copyedit

* Address feedback

* Update exec plugin docs with TLS credentials (#8826)

* Update exec plugin docs with TLS credentials

kubernetes/kubernetes#61803 implements TLS client credential support for
1.11.

* Copyedit

* More copyedits for clarification

* Additional copyedit

* Change token->credential

* NodeRestriction admission prevents kubelet taint removal (#8911)

* dns-custom-namerserver: break down the page into mutliple sections (#8900)

* dns-custom-namerserver: break down the page into mutliple sections

This page is currently about kube-dns and is a bit outdated.
Introduce the heading `# Customizing kube-dns`.

Introduce a separate section about CoreDNS.

* Copyedits, fix headings for customizing DNS

Hey Lubomir,
I coypedited pretty heavily because this workflow is so much easier for docs and because I'm trying to help improve everything touching kubeadm as much as possible.

But there's one outstanding issue wrt headings and intro content: you can't add a heading 1 to a topic to do what you wanted to do. The page title in the front matter is rendered as a heading 1 and everything else has to start at heading 2. (We still need to doc this better in the docs contributing content, I know.)

Instead, I think we need to rewrite the top-of-page intro content to explain better the relationship between kube-dns and CoreDNS. I'm happy to write something, but I thought I'd push this commit first so you can see what I'm doing.

Hope it's all clear -- ping here or on Slack with any questions ~ Jennifer

* Interim fix for talking about CoreDNS

* Fix CoreDNS details

* PSP readOnly hostPath (#8898)

* Add documentation for crictl (#8880)

* Add documentation for crictl

* Copyedit

Signed-off-by: Misty Stanley-Jones <mistyhacks@google.com>

* Final copyedit

* VolumeSubpathEnvExpansion alpha feature (#8835)

* Note that Heapster is deprecated (#8827)

* Note that Heapster is deprecated

This notes that Heapster is deprecated, and migrates the relevant
docs to talk about metrics-server or other solutions by default.

* Copyedits and improvements

Signed-off-by: Misty Stanley-Jones <mistyhacks@google.com>

* Address feedback

* fix shortcode to troubleshoot deploy (#9057)

* update dynamic kubelet config docs for v1.11 (#8766)

* update dynamic kubelet config docs for v1.11

* Substantial copyedit

* Address feedback

* Reference doc for kubeadm (release-1.11) (#9044)

* Reference doc for kubeadm (release-1.11)

* fix shortcode to troubleshoot deploy (#9057)

* Reference doc for kube-components (release-1.11) (#9045)

* Reference doc for kube-components (release-1.11)

* Update cloud-controller-manager.md

* fix shortcode to troubleshoot deploy (#9057)

* Documentation on lowercasing kubeadm init apiserver SANs (#9059)

* Documentation on lowercasing kubeadm init apiserver SANs

* fix shortcode to troubleshoot deploy (#9057)

* Clarification in dynamic Kubelet config doc (#9061)

* Promote sysctls to Beta (#8804)

* Promote sysctls to Beta

* Copyedits

Signed-off-by: Misty Stanley-Jones <mistyhacks@google.com>

* Review comments

* Address feedback

* More feedback

* kubectl reference docs for 1.11 (#9080)

* Update Kubernetes API 1.11 ref docs (#8977)

* Update v1alpha1 to v1beta1.

* Adjust left nav for 1.11 ref docs.

* Trim list of old ref docs.

* Update Federation API ref docs for 1.11. (#9064)

* Update Federation API ref docs for 1.11.

* Add titles.

* Update definitions.html

* CRD versioning Public Documentation (#8834)

* CRD versioning Public Documentation

* Copyedit

Signed-off-by: Misty Stanley-Jones <mistyhacks@google.com>

* Address feedback

* More rewrites

* Address feedback

* Update main CRD page in light of versioning

* Reorg CRD docs

* Further reorg

* Tweak title

* CSI documentation update for raw block volume support (#8927)

* CSI documetation update for raw block volume support

* minor edits for "CSI raw block volume support"

Some small grammar and style nits.

* minor CSIBlockVolume edits

* Update kubectl component ref page for 1.11. (#9094)

* Update kubectl component ref page for 1.11.

* Add title. Replace stevepe with username.

* crd versioning doc: fix nits (#9142)

* Update `DynamicKubeletConfig` feature to beta (#9110)

xref: kubernetes/kubernetes#64275

* Documentation for dynamic volume limits based on node type (#8871)

* add cos for storage limits

* Update docs specific for aws and gce

* fix some minor things

* Update storage-limits.md

* Add k8s version to feature-state shortcode

* The Doc update for ScheduleDaemonSetPods (#8842)

Signed-off-by: Da K. Ma <klaus1982.cn@gmail.com>

* Update docs related to PersistentVolumeLabel admission control (#9109)

The said admission controller is disabled by default in 1.11
(kubernetes/kubernetes#64326) and scheduled to be removed in future
release.

* client exec auth: updates for 1.11 (#9154)

* Updates HA kubeadm docs (#9066)

* Updates HA kubeadm docs

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* kubeadm HA - Add stacked control plane steps

* ssh instructions and some typos in the bash scripts

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* Fix typos and copypasta errors

* Fix rebase issues

* Integrate more changes

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* copyedits, layout and formatting fixes

* final copyedits

* Adds a sanity check for load balancer connection

Signed-off-by: Chuck Ha <ha.chuck@gmail.com>

* formatting fixes, copyedits

* fix typos, formatting

* Document the Pod Ready++ feature (#9180)

Closes: #9107
Xref: kubernetes/kubernetes#64057

* Mention 'KubeletPluginsWatcher' feature (#9177)

* Mention 'KubeletPluginsWatcher' feature

This feature is more developers oriented than users oriented, so simply
mention it in the feature gate should be fine.
In future, when the design doc is migrated from Google doc to the
kubernetes/community repo, we can add links to it for users who want to
dig deeper.

Closes: #9108
Xref: kubernetes/kubernetes#63328, kubernetes/kubernetes#64605

* Copyedit

* Amend dynamic volume list docs (#9181)

The dynamic volume list feature has been documented but the feature gate
related was not there yet.

Closes: #9105

* Document for service account projection (#9182)

This adds docs for the service account projection feature.

Xref: kubernetes/kubernetes#63819, kubernetes/community#1973
Closes: #9102

* Update pod priority and preemption user docs (#9172)

* Update pod priority and preemption user docs

* Copyedit

* Documentation on setting node name with Kubeadm (#8925)

* Documentation on setting node name with Kubeadm

* copyedit

* Add kubeadm upgrade docs for 1.11 (#9089)

* Add kubeadm upgrade docs for 1.11

* Initial docs review feedback

* Add 1-11 to outline

* Fix formatting on tab blocks

* Move file to correct location

* Add `kubeadm upgrade node config` step

* Overzealous ediffing

* copyedit, fix lists and headings

* clarify --force flag for fixing bad state

* Get TOML ready for 1.11 release

* Blog post for 1.11 release (#9254)

* Blog post for 1.11 release

* Update 2018-06-26-kubernetes-1.11-release-announcement.md

* Update 2018-06-26-kubernetes-1.11-release-announcement.md

* Update 2018-06-26-kubernetes-1.11-release-announcement.md
This commit is contained in:
Misty Linville
2018-06-27 15:26:18 -07:00
committed by k8s-ci-robot
parent e091e29a5d
commit 5f30e7d4c3
171 changed files with 126686 additions and 6525 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions.md
+573
View File
@@ -0,0 +1,573 @@
---
title: Extend the Kubernetes API with CustomResourceDefinitions
reviewers:
- deads2k
- enisoc
content_template: templates/task
weight: 20
---
{{% capture overview %}}
This page shows how to install a
[custom resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
into the Kubernetes API by creating a
[CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions).
{{% /capture %}}
{{% capture prerequisites %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
* Make sure your Kubernetes cluster has a master version of 1.7.0 or higher.
* Read about [custom resources](/docs/concepts/api-extension/custom-resources/).
{{% /capture %}}
{{% capture steps %}}
## Create a CustomResourceDefinition
When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server
creates a new RESTful resource path for each version you specify. The CRD can be
either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As
with existing built-in objects, deleting a namespace deletes all custom objects
in that namespace. CustomResourceDefinitions themselves are non-namespaced and
are available to all namespaces.
For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:
```yaml
apiVersion: apiextensions.k8s.io/v1beta1
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
```
And create it:
```shell
kubectl create -f resourcedefinition.yaml
```
Then a new namespaced RESTful API endpoint is created at:
```
/apis/stable.example.com/v1/namespaces/*/crontabs/...
```
This endpoint URL can then be used to create and manage custom objects.
The `kind` of these objects will be `CronTab` from the spec of the
CustomResourceDefinition object you created above.
It might take a few seconds for the endpoint to be created.
You can watch the `Established` condition of your CustomResourceDefinition
to be true or watch the discovery information of the API server for your
resource to show up.
## Create custom objects
After the CustomResourceDefinition 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, the `cronSpec` and `image` custom fields are set in a
custom object of kind `CronTab`. The kind `CronTab` comes from the spec of the
CustomResourceDefinition object you created above.
If you save the following YAML to `my-crontab.yaml`:
```yaml
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
```
and create it:
```shell
kubectl create -f my-crontab.yaml
```
You can then manage your CronTab objects using kubectl. For example:
```shell
kubectl get crontab
```
Should print a list like this:
```console
NAME AGE
my-new-cron-object 6s
```
Resource names are not case-sensitive when using kubectl, and you can use either
the singular or plural forms defined in the CRD, as well as any short names.
You can also view the raw YAML data:
```shell
kubectl get ct -o yaml
```
You should see that it contains the custom `cronSpec` and `image` fields
from the yaml you used to create it:
```console
apiVersion: v1
items:
- apiVersion: stable.example.com/v1
kind: CronTab
metadata:
clusterName: ""
creationTimestamp: 2017-05-31T12:56:35Z
deletionGracePeriodSeconds: null
deletionTimestamp: null
name: my-new-cron-object
namespace: default
resourceVersion: "285"
selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
uid: 9423255b-4600-11e7-af6a-28d2447dc82b
spec:
cronSpec: '* * * * */5'
image: my-awesome-cron-image
kind: List
metadata:
resourceVersion: ""
selfLink: ""
```
## Delete a CustomResourceDefinition
When you delete a CustomResourceDefinition, the server will uninstall the RESTful API endpoint
and **delete all custom objects stored in it**.
```shell
kubectl delete -f resourcedefinition.yaml
kubectl get crontabs
```
```console
Error from server (NotFound): Unable to list "crontabs": the server could not find the requested resource (get crontabs.stable.example.com)
```
If you later recreate the same CustomResourceDefinition, it will start out empty.
## Serving multiple versions of a CRD
See [Custom resource definition versioning](custom-resource-definition-versioning)
for more information about serving multiple versions of your
CustomResourceDefinition and migrating your objects from one version to another.
{{% /capture %}}
{{% capture discussion %}}
## Advanced topics
### Finalizers
*Finalizers* allow controllers to implement asynchronous pre-delete hooks.
Custom objects support finalizers just like built-in objects.
You can add a finalizer to a custom object like this:
```yaml
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
finalizers:
- finalizer.stable.example.com
```
Finalizers are arbitrary string values, that when present ensure that a hard delete
of a resource is not possible while they exist.
The first delete request on an object with finalizers merely sets a value for the
`metadata.deletionTimestamp` field instead of deleting it. Once this value is set,
entries in the `finalizer` list can only be removed.
This triggers controllers watching the object to execute any finalizers they handle.
This will be represented via polling update requests for that
object, until all finalizers have been removed and the resource is deleted.
The time period of polling update can be controlled by `metadata.deletionGracePeriodSeconds`.
It is the responsibility of each controller to removes its finalizer from the list.
Kubernetes will only finally delete the object if the list of finalizers is empty,
meaning all finalizers are done.
### Validation
Validation of custom objects is possible via
[OpenAPI v3 schema](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject).
Additionally, the following restrictions are applied to the schema:
- The fields `default`, `nullable`, `discriminator`, `readOnly`, `writeOnly`, `xml`,
`deprecated` and `$ref` cannot be set.
- The field `uniqueItems` cannot be set to true.
- The field `additionalProperties` cannot be set to false.
This feature is __beta__ in v1.9.
You can disable this feature using the `CustomResourceValidation` feature gate on
the [kube-apiserver](/docs/admin/kube-apiserver):
```
--feature-gates=CustomResourceValidation=false
```
The schema is defined in the CustomResourceDefinition. In the following example, the
CustomResourceDefinition applies the following validations on the custom object:
- `spec.cronSpec` must be a string and must be of the form described by the regular expression.
- `spec.replicas` must be an integer and must have a minimum value of 1 and a maximum value of 10.
Save the CustomResourceDefinition to `resourcedefinition.yaml`:
```yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
version: v1
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
validation:
# openAPIV3Schema is the schema for validating custom objects.
openAPIV3Schema:
properties:
spec:
properties:
cronSpec:
type: string
pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
replicas:
type: integer
minimum: 1
maximum: 10
```
And create it:
```shell
kubectl create -f resourcedefinition.yaml
```
A request to create a custom object of kind `CronTab` will be rejected if there are invalid values in its fields.
In the following example, the custom object contains fields with invalid values:
- `spec.cronSpec` does not match the regular expression.
- `spec.replicas` is greater than 10.
If you save the following YAML to `my-crontab.yaml`:
```yaml
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * *"
image: my-awesome-cron-image
replicas: 15
```
and create it:
```shell
kubectl create -f my-crontab.yaml
```
you will get an error:
```console
The CronTab "my-new-cron-object" is invalid: []: Invalid value: map[string]interface {}{"apiVersion":"stable.example.com/v1", "kind":"CronTab", "metadata":map[string]interface {}{"name":"my-new-cron-object", "namespace":"default", "deletionTimestamp":interface {}(nil), "deletionGracePeriodSeconds":(*int64)(nil), "creationTimestamp":"2017-09-05T05:20:07Z", "uid":"e14d79e7-91f9-11e7-a598-f0761cb232d1", "selfLink":"", "clusterName":""}, "spec":map[string]interface {}{"cronSpec":"* * * *", "image":"my-awesome-cron-image", "replicas":15}}:
validation failure list:
spec.cronSpec in body should match '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
spec.replicas in body should be less than or equal to 10
```
If the fields contain valid values, the object creation request is accepted.
Save the following YAML to `my-crontab.yaml`:
```yaml
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
replicas: 5
```
And create it:
```shell
kubectl create -f my-crontab.yaml
crontab "my-new-cron-object" created
```
### Subresources
Custom resources support `/status` and `/scale` subresources.
This feature is __beta__ in v1.11 and enabled by default.
You can disable this feature using the `CustomResourceSubresources` feature gate on
the [kube-apiserver](/docs/admin/kube-apiserver):
```
--feature-gates=CustomResourceSubresources=false
```
The status and scale subresources can be optionally enabled by
defining them in the CustomResourceDefinition.
#### Status subresource
When the status subresource is enabled, the `/status` subresource for the custom resource is exposed.
- The status and the spec stanzas are represented by the `.status` and `.spec` JSONPaths respectively inside of a custom resource.
- `PUT` requests to the `/status` subresource take a custom resource object and ignore changes to anything except the status stanza.
- `PUT` requests to the `/status` subresource only validate the status stanza of the custom resource.
- `PUT`/`POST`/`PATCH` requests to the custom resource ignore changes to the status stanza.
- Any changes to the spec stanza increments the value at `.metadata.generation`.
- `properties`, `required` and `description` are the only constructs allowed in the root of the CRD OpenAPI validation schema.
#### Scale subresource
When the scale subresource is enabled, the `/scale` subresource for the custom resource is exposed.
The `autoscaling/v1.Scale` object is sent as the payload for `/scale`.
To enable the scale subresource, the following values are defined in the CustomResourceDefinition.
- `SpecReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `Scale.Spec.Replicas`.
- It is a required value.
- Only JSONPaths under `.spec` and with the dot notation are allowed.
- If there is no value under the `SpecReplicasPath` in the custom resource,
the `/scale` subresource will return an error on GET.
- `StatusReplicasPath` defines the JSONPath inside of a custom resource that corresponds to `Scale.Status.Replicas`.
- It is a required value.
- Only JSONPaths under `.status` and with the dotation are allowed.
- If there is no value under the `StatusReplicasPath` in the custom resource,
the status replica value in the `/scale` subresource will default to 0.
- `LabelSelectorPath` defines the JSONPath inside of a custom resource that corresponds to `Scale.Status.Selector`.
- It is an optional value.
- It must be set to work with HPA.
- Only JSONPaths under `.status` and with the dotation are allowed.
- If there is no value under the `LabelSelectorPath` in the custom resource,
the status selector value in the `/scale` subresource will default to the empty string.
In the following example, both status and scale subresources are enabled.
Save the CustomResourceDefinition to `resourcedefinition.yaml`:
```yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
# subresources describes the subresources for custom resources.
subresources:
# status enables the status subresource.
status: {}
# scale enables the scale subresource.
scale:
# specReplicasPath defines the JSONPath inside of a custom resource that corresponds to Scale.Spec.Replicas.
specReplicasPath: .spec.replicas
# statusReplicasPath defines the JSONPath inside of a custom resource that corresponds to Scale.Status.Replicas.
statusReplicasPath: .status.replicas
# labelSelectorPath defines the JSONPath inside of a custom resource that corresponds to Scale.Status.Selector.
labelSelectorPath: .status.labelSelector
```
And create it:
```shell
kubectl create -f resourcedefinition.yaml
```
After the CustomResourceDefinition object has been created, you can create custom objects.
If you save the following YAML to `my-crontab.yaml`:
```yaml
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
replicas: 3
```
and create it:
```shell
kubectl create -f my-crontab.yaml
```
Then new namespaced RESTful API endpoints are created at:
```
/apis/stable.example.com/v1/namespaces/*/crontabs/status
```
and
```
/apis/stable.example.com/v1/namespaces/*/crontabs/scale
```
A custom resource can be scaled using the `kubectl scale` command.
For example, the following command sets `.spec.replicas` of the
custom resource created above to 5:
```shell
kubectl scale --replicas=5 crontabs/my-new-cron-object
crontabs "my-new-cron-object" scaled
kubectl get crontabs my-new-cron-object -o jsonpath='{.spec.replicas}'
5
```
### Categories
Categories is a list of grouped resources the custom resource belongs to (eg. `all`).
You can use `kubectl get <category-name>` to list the resources belonging to the category.
This feature is __beta__ and available for custom resources from v1.10.
The following example adds `all` in the list of categories in the CustomResourceDefinition
and illustrates how to output the custom resource using `kubectl get all`.
Save the following CustomResourceDefinition to `resourcedefinition.yaml`:
```yaml
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: crontabs.stable.example.com
spec:
group: stable.example.com
versions:
- name: v1
served: true
storage: true
scope: Namespaced
names:
plural: crontabs
singular: crontab
kind: CronTab
shortNames:
- ct
# categories is a list of grouped resources the custom resource belongs to.
categories:
- all
```
And create it:
```shell
kubectl create -f resourcedefinition.yaml
```
After the CustomResourceDefinition object has been created, you can create custom objects.
Save the following YAML to `my-crontab.yaml`:
```yaml
apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
name: my-new-cron-object
spec:
cronSpec: "* * * * */5"
image: my-awesome-cron-image
```
and create it:
```shell
kubectl create -f my-crontab.yaml
```
You can specify the category using `kubectl get`:
```
kubectl get all
```
and it will include the custom resources of kind `CronTab`:
```console
NAME AGE
crontabs/my-new-cron-object 3s
```
{{% /capture %}}
{{% capture whatsnext %}}
* Learn how to [Migrate a ThirdPartyResource to CustomResourceDefinition](/docs/tasks/access-kubernetes-api/migrate-third-party-resource/).
* See [CustomResourceDefinition](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#customresourcedefinition-v1beta1-apiextensions-k8s-io).
* Serve [multiple versions](custom-resource-definitions-versioning) of a
CustomResourceDefinition
{{% /capture %}}