1. K8S CRD is concise and easy to use:

Introduction to CustomResourceDefinition:
Everything in Kubernetes can be regarded as resources. After Kubernetes 1.7, the secondary development capability of CRD custom resources is added to extend Kubernetes API. Through CRD, we can add new resource types to Kubernetes API without modifying Kubernetes source code to create a custom API server. This function greatly improves Kubernetes' expansion capability.
When you create a new custom resource definition (CRD), the Kubernetes API server will create a new RESTful resource path for each version you specify. We can create some self-defined type resources according to the api path. CRD can be namespace or cluster wide, which is specified in the scope (scpoe) field of CRD. Like existing built-in objects, deleting a namespace will delete all custom objects in the namespace. customresourcedefinition itself has no namespace, and all namespaces can be used.

Kuberneters official documents

1.1. Create custom resources through crd resources, that is, customize a Restful API:

$ vi resourcedefinition.yaml:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  # The name must match the following spec field in the format: < plural >. < group >
  name: crontabs.stable.example.com
spec:
  # Group name for REST API: / APIs / < group > / < version >
  group: stable.example.com
  # List of supported versions for this CustomResourceDefinition
  versions:
    - name: v1
      # Each version can be enabled / disabled through the service flag.
      served: true
      # One and only one version must be marked as a stored version.
      storage: true
  # Specify the scope of crd resource in namespace or cluster
  scope: Namespaced
  names:
    # Plural name used in URL: / APIs / < group > / < version > / < plural >
    plural: crontabs
    # A singular name used as an alias on the CLI (a parameter entered in the shell interface) and used for display
    singular: crontab
    # The kind field uses hump naming rules. The resource list uses this
    kind: CronTab
    # Short name allows a short string to match a resource on the CLI, which can be obtained by kubectl using the short name of the resource when viewing the resource.
    shortNames:
    - ct

• Create a custom contab resource
  $ kubectl create -f resourcedefinition.yaml
  Then create a new RESTful API endpoint with a namespace in the following location:
  /apis/stable.example.com/v1/namespaces/*/crontabs /... Then we can use this url to create and manage custom object resources.
• View information about custom contab resources
  $ kubectl get contab/ct

1.2. Create custom resource objects:

Create a crontab type resource object according to the RESTful API created by the crd object resource
$ vi my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image

After creating the CustomResourceDefinition object, we can create the object of the custom resource. Custom objects can contain custom fields. These fields can contain any JSON. In the above example, the cronSpec and image custom fields are set in the custom object of CronTab type. The CronTab type comes from the specification of the CustomResourceDefinition object you created above.

• Create an object for a custom resource contab resource
  $ kubectl create -f my-crontab.yaml

1.3. Add validation for custom resources:

The purpose of validation is to create an object through a user-defined resource. If there is an invalid value in the object field after the user-defined resource is created, the request to create the object will be rejected, otherwise it will be created. We can add the "validation:" field in the crd file to add the corresponding validation mechanism.

We can verify our customized resource objects by using OpenAPI v3 mode, which also applies some restrictions:

• default, nullable, discriminator, readOnly, writeOnly, xml, deprecated and $ref cannot set these fields.
• The field uniqueItem cannot be set to true
• Field additionalProperties cannot be set to false

Of course, we can modify the kube-apiserver.yml file to limit it. Set customeresourcevalidation in the kube-apiserver.yml file to false (- - feature gates = customresourcevalidation = false)

Examples are as follows:
In the crd resource, the openapi v3 pattern verification is applied to the user-defined resource. In the user-defined resource, the cronSpec and replica fields are verified. If the rules are not met, the resource object will not be created.
$ vi resourcedefinition.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: #--Must be a string and must be in the form described by a regular expression
              type: string
              pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'
            replicas: #----Must be an integer, the minimum value must be 1 and the maximum value must be 10
              type: integer
              minimum: 1
              maximum: 10

• Create a custom resource with validation (Contab)
  $ kubectl create -f resourcedefinition.yaml

• Create a contab resource object that does not meet validation rules:
  $ vi my-crontab.yaml:

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * *"
  image: my-awesome-cron-image
  replicas: 15

• Create a contab resource object that does not conform to validation rules
  $ kubectl create -f my-crontab.yaml
  As a result, the creation of the Contab resource object failed

1.4. Add additional print columns for custom resources:

Starting with Kubernetes 1.11, kubectl uses server-side printing. The server determines which columns are displayed by the kubectl get command, that is, some list information (such as kubectl get nodes) will be displayed when we obtain a built-in resource. Here, we can use CustomResourceDefinition to customize these columns and display the list information we need when we view the customized resource information. By adding the "additionalPrinterColumns:" field in the crd file, declare the information of the column to be printed under this field.
For example:
Here, we add the list information to be displayed for custom resources in the crd object:
$ vi resourcedefinition.yaml:

 

apiVersion: apiextensions.k8s.io/v1beta1
  kind: CustomResourceDefinition
  metadata:
    name: crontabs.stable.example.com
  spec:
    group: stable.example.com
    version: v1
    scope: Namespaced
    names:
      plural: crontabs
      singular: crontab
      kind: CronTab
      shortNames:
      - ct
    additionalPrinterColumns:
    - name: Spec
      type: string
      description: The cron spec defining the interval a CronJob is run
      JSONPath: .spec.cronSpec
    - name: Replicas
      type: integer
      description: The number of jobs launched by the CronJob
      JSONPath: .spec.replicas
    - name: Age
      type: date
      JSONPath: .metadata.creationTimestamp

• Create a custom resource with display list information
  $ kubectl create -f resourcedefinition.yaml
• Create a contab custom resource object
  $ kubectl create -f my-crontab.yaml
• View basic information of custom resource object
  $ kubectl get crontab my-new-cron-object

NAME                       SPEC        REPLICAS   AGE
my-new-cron-object   * * * * *            1         7s
 be careful: name Columns do not need to be defined. They will be available by default

1.5. Add status and scaling configuration for customized resources:

Generally, if we do not configure some related configurations about the scaling and status information of resource objects in the user-defined resources, there will be nothing we can do when we want to elastically expand the container of the object through "kubectl scale" after creating the object through the user-defined resources. CRD allows us to add related configuration statements in this aspect, so that we can scale the user-defined resource objects. Add the "subresources:" field to declare status and scaling information.
In k8s, this is called a sub resource. We can turn it off or enable it through the "Kube apiserver. YML" file, "-- feature gates = customresourcesubresources = false".

Note: in the root directory of CRD OpenAPI authentication mode, only the following structures are allowed in the crd file:
Description,Example,ExclusiveMaximum,ExclusiveMinimum,ExternalDocs,Format,Items,Maximum,MaxItems,MaxLength,Minimum,MinItems,MinLength,MultipleOf,Pattern,Properties,Required,Title,Type,UniqueItems

State both status and scale sub resources in the following crd files:
$ vi resourcedefinition.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
  # Description of the child resource of the custom resource
  subresources:
    # Enable status sub resources.
    status: {}
    # Enable scale sub resources
    scale:
      specReplicasPath: .spec.replicas
      statusReplicasPath: .status.replicas
      labelSelectorPath: .status.labelSelector

• Create a custom resource with a child resource declaration
  $ kubectl create -f resourcedefinition.yaml
• Create a custom resource object
  $ kubectl create -f my-crontab.yaml

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-new-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-awesome-cron-image
  replicas: 3

• Expands the number of copies of custom resource objects
  $ kubectl scale --replicas=5 crontabs/my-new-cron-object

1.6. Assign a group to a user-defined resource:

Generally, when we create a user-defined resource, the resource is a group. In order to reduce the grouping information, we can allocate the user-defined resource to the corresponding existing group. Define the group to which our custom resource belongs through the "categories:" field. Add the "categories:" field to the crd file to declare the group.

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
    # The categories field specifies the group to which the custom resource belongs
    categories:
    - all

 

• After creating the above crd resource and the resource object my crontab, we can obtain the information under the all group by obtaining the all group
  $ kubectl get all