Shulou(Shulou.com)06/02 Report--

In the first two parts of this series, we introduced the overall process of API Server and how API objects are stored in etcd. In this article, we will explore how to extend API resources.

In the beginning, the only way to extend API resources is to extend the relevant API source code and integrate it into the resources you need. Or, push a whole new type of API into the community code for the new core object. However, this results in an increasing number of core API resource types until API is overloaded. To avoid this unlimited extension of API resources, two ways to extend the core API are provided in Kubernetes:

1. Using a custom resource definition (CRDs), it was initially called a third-party resource (TPRs). With CRD you can define your own resource object types in a simple and flexible way and let API server handle the entire lifecycle.

two。 Use the user API Servers (UAS) that runs in parallel with the main API Servers. In this way, there may be more design code development, which may require more time and effort. Of course, this approach can also give you a more detailed and comprehensive understanding of API resources.

In this paper, we mainly discuss the definition and use of CRD.

Declaration and creation of CRDs

As mentioned in the first part of this series, each API resource is classified according to the Group group, and each object has a corresponding version number associated with the HTTP path. Now if you want to implement a CRD, the first thing you need is to name a new API Group group that cannot be duplicated with an existing group. In your own new API group, you can have any number of resources, and they can have the same name as resources in other groups. Let's give a practical example:

As we mentioned earlier, each version of the Kubernetes resource managed by the API group is related to the HTTP path. CRD is similar to the definition of a class in object-oriented programming, and the actual use of CR can be seen as a set of instances of it. First of all, let's explain some of the fields in the example. The CRD apiVersion in the first line is defined in this way after kube-apiserver 1.7. After line 5, we define the relevant fields for spec. In line 6, spec.group is the API group that defines the CRD you created (defined as example.com in this example). Line 7 defines the version of the CRD object. There is only one fixed version of each resource, but there can still be multiple different versions of the resource in the API group. Line 8 spec.names has two required entries: kind, by convention the first letter is capitalized, plural, by convention all lowercase, this field is related to the resulting HTTP path, for example, in this case, the final HTTP path is https://

The kind above is mainly used to describe the type of object, while the resource resource is related to the HTTP path. In most cases, the two match; however, in some specific cases, an impassable kind may be returned under the same API HTTP path (for example, the Status error object will return another kind).

It is worth noting that the resource resource (in this case, databases) and the group group (in this case, example.com) must match the metadata.name field (in this case, the fourth line databases.example.com).

Now let's create a CRD based on the YAML file above:

$kubectl create-f databases-crd.yaml

Customresourcedefinition "databases.example.com" created

Since the creation process is asynchronous, you must check the status of the CRD you created, make sure that the CRD you created does not conflict with other resources, and that the API Server has called the relevant handler to complete the creation. You can do this by polling in a script or code. Finally, we can get the following status:

$kubectl get crd databases.example.com-o yaml

ApiVersion: apiextensions.k8s.io/v1beta1

Kind: CustomResourceDefinition

Metadata:

CreationTimestamp: 2017-08-09T09:21:43Z

Name: databases.example.com

ResourceVersion: 792

SelfLink: / apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/databases.example.com

Uid: 28c94a05-7ce4-11e7-888c-42010a9a0fd5

Spec:

Group: example.com

Names:

Kind: Database

ListKind: DatabaseList

Plural: databases

Singular: database

Scope: Namespaced

Version: v1

Status:

AcceptedNames:

Kind: Database

ListKind: DatabaseList

Plural: databases

Singular: database

Conditions:

-lastTransitionTime: null

Message: no conflicts found

Reason: NoConflicts

Status: "True"

Type: NamesAccepted

-lastTransitionTime: 2017-08-09T09:21:43Z

Message: the initial names have been accepted

Reason: InitialNamesAccepted

Status: "True"

Type: Established

Above, we can see that the CRD we created earlier can be seen through kubectl, and some status information of CRD is displayed.

The use of CRDs

After opening Kubernetes API to the local agent through kubectl proxy, take a look at the CRD we just created:

$http 127.0.0.1:8001/apis/example.com

HTTP/1.1 200 OK

Content-Length: 223

Content-Type: application/json

Date: Wed, 09 Aug 2017 09:25:44 GMT

{

"apiVersion": "v1"

"kind": "APIGroup"

"name": "example.com"

"preferredVersion": {

"groupVersion": "example.com/v1"

"version": "v1"

}

"serverAddressByClientCIDRs": null

"versions": [

{

"groupVersion": "example.com/v1"

"version": "v1"

}

]

}

Note that by default, kubectl looks at the cache stored in the ~ / .kube / cache/discovery directory for ten minutes. So it may take 10 minutes for you to see your newly created CRD resource. However, when there is no cache and kubectl cannot find the required resource, it will be re-cached.

Next, let's look at an example of CRD:

$cat wordpress-database.yaml

ApiVersion: example.com/v1

Kind: Database

Metadata:

Name: wordpress

Spec:

User: wp

Password: secret

Encoding: unicode

$kubectl create-f wordpress-databases.yaml

Database "wordpress" created

$kubectl get databases.example.com

NAME KIND

Wordpress Database.v1.example.com

To monitor the creation and update of resources through API, you can monitor watch by modifying a resourceVersion (we use curl to monitor the specified version of database).

$http 127.0.0.1:8001/apis/example.com/v1/namespaces/default/databases

HTTP/1.1 200 OK

Content-Length: 593

Content-Type: application/json

Date: Wed, 09 Aug 2017 09:38:49 GMT

{

"apiVersion": "example.com/v1"

"items": [

{

"apiVersion": "example.com/v1"

"kind": "Database"

"metadata": {

"clusterName":

"creationTimestamp": "2017-08-09T09:38:30Z"

"deletionGracePeriodSeconds": null

"deletionTimestamp": null

"name": "wordpress"

"namespace": "default"

"resourceVersion": "2154"

"selfLink": "/ apis/example.com/v1/namespaces/default/databases/wordpress"

"uid": "8101a7af-7ce6-11e7-888c-42010a9a0fd5"

}

"spec": {

"encoding": "unicode"

"password": "secret"

"user": "wp"

}

}

]

"kind": "DatabaseList"

"metadata": {

"resourceVersion": "2179"

"selfLink": "/ apis/example.com/v1/namespaces/default/databases"

}

}

We can monitor the HTTP path of / apis/example.com/v1/namespaces/default/databases/wordpressCRD through the "resourceVersion": "2154" of the curl command pair watch:

$curl-f 127.0.0.1:8001/apis/example.com/v1/namespaces/default/databases?watch=true&resourceVersion=2154

Now that we open a new shell conversation window and delete the wordpress CRD resources, we can see if the monitoring watch window just received this message:

$kubectl delete databases.example.com/wordpress

Please note that we can use kubectl delete database wordpress to delete CRD resources because there are no database resources defined in Kubernetes before. In addition, database is the spec.name.singular field in our CRD, derived from English grammar.

We can see the update status returned by the monitoring watch CRD databases from API Server:

{"type": "DELETED", "object": {"apiVersion": "example.com/v1", "kind": "Database", "metadata": {"clusterName": "" creationTimestamp ":" 2017-0 [0amp 515]

: 38deletionTimestamp 30Z "," deletionGracePeriodSeconds ": null," deletionTimestamp ": null," name ":" wordpress "," namespace ":" default "," resourceVersion ":" 2154 "," selfLink ":" / apis/example.com/v1/namespaces/ "

Default/databases/wordpress "," uid ":" 8101a7af-7ce6-11e7-888c-42010a9a0fd5 "}," spec ": {" encoding ":" unicode "," password ":" secret "," user ":" wp "}

The operation and output of the above shell session are shown in the following figure:

Finally, let's take a look at how each piece of data from CRD database is stored in etcd. The following is the data obtained by accessing etcd directly through HTTP API:

$curl-s localhost:2379/v2/keys/registry/example.com/databases/default | jq.

{

"action": "get"

"node": {

"key": "/ registry/example.com/databases/default"

"dir": true

"nodes": [

{

"key": "/ registry/example.com/databases/default/wordpress"

"value": "{\" apiVersion\ ":\" example.com/v1\ ",\" kind\ ":\" Database\ ",\" metadata\ ": {\" clusterName\ ":\",\ "creationTimestamp\":\ "2017-08-09T14:53:40Z\",\ "deletionGracePeriodSeconds\": null,\ "deletionTimestamp\": null,\ "name\":\ "wordpress\",\ "namespace\":\ "default\",\ "selfLink\":\ "\" \ "uid\":\ "8837f788-7d12-11e7-9d28-080027390640\"},\ "spec\": {\ "encoding\":\ "unicode\",\ "password\":\ "secret\",\ "user\":\ "wp\"}\ n "

"modifiedIndex":

"createdIndex":

}

]

"modifiedIndex":

"createdIndex":

}

}

As you can see above, CRD data ends up in an unparsed state in etcd. Now delete CRD, and all CRD instances will be deleted as well, which is a cascading delete operation.

The present situation, limitation and Future Prospect of CRDs

The development status of CRDs is as follows:

1. In Kubernetes 1.7, CRDs begins to replace ThirdPartyResources (TPRs), and TPRs will be removed in Kubernetes 1.8.

two。 You can refer to the document migration for migrating TPRs to CRDs instances.

3. Only a single version version in a CRD is supported, of course, there may be multiple version versions in a group.

4.CRDs provides an API solution, which is basically no different from Kubernetes's native API resources from a user's point of view.

5.CRDs is the foundation of multi-version and multi-branch stability. For format validation of JSON-Schema for CRD resources, please refer to the document CRD validation proposal. For more information on resource recovery, please refer to the document Garbage collection.

Next let's take a look at some of the limitations of CRDs:

1.CRD does not provide version conversion, that is, there can be only one version per CRD (CRD version conversion is not expected to be seen in the near or medium term).

two。 In Kubernetes1.7, there is no relevant check validation for CRD at present.

3. There is no fast, real-time access (admission) mechanism (but can support initialization and admission in the form of webhooks).

4. You cannot define a sub-resources in Kubernetes1.7, such as scale or status, but there is a discussion of proposal in this area.

5.CRD currently does not support default configuration, that is, defaults for specific fields (which may be supported in subsequent versions of Kubernetes1.7).

To solve the above problems and flexibly extend Kubernetes, you can run a user API Servers in parallel with the main API Server. We will explain in detail how to write UAS and write a custom controller that uses CRD in detail later in this blog.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.