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, such as in this case, the final HTTP path is https://

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.