Shulou(Shulou.com)05/31 Report--

How to understand Kubernetes API, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Kubernetes treats all the resources it manages as API objects and provides REST-style API to manipulate these objects. Kubernetes API is provided by kube-apiserver components, and the communication between Kubernetes components and kube-apiserver is also driven by API. In addition, command-line tools such as kubectl and various Kubernetes client programs use API to communicate with Kubernetes.

API format

The Kubernetes API format is prefix/group/version/resource. For example, the API representing the Deployment resource list is / apis/apps/v1/deployments, where apis represents the prefix, apps represents the API group, v1 represents the version of the API group, and deployments represents the resource name, as shown in the following figure:

API prefix

The prefix in API will undoubtedly increase the length of the URL, which makes us think about the following questions:

What is the meaning of prefixes?

What prefixes does Kubernetes API have?

To answer this question, we should start from the definition of API. The full name of API is Application Programming Interface, that is, application programming interface. So in a broad sense, all the endpoints exposed by the kube-apiserver component of Kubernetes can be called API, such as:

/ api/v1 "," / apis/admissionregistration.k8s.io "," / apis/apps "," / apis/authentication.k8s.io "," / healthz "," / livez "," / metrics "," / version "

Applications can use these interfaces to implement specific functions, such as / api/v1 or apis/apps interfaces to create resources, and / healthz to query the cluster health status, so these interfaces are all API.

However, often what we call Kubernetes API is a narrow concept, that is, it specifically refers to those API that represent Kubernetes resources, so in order to distinguish from other API, Kubernetes deliberately adds an api prefix, which means that these API are used to manage Kubernetes resources.

The API prefix used to manage Kubernetes resources is not only api, but also apis. In the early design of Kubernetes, only the api prefix was used. Later, in order to introduce the design of the API group, the apis prefix was added. To put it simply, the API using the api prefix is the core group of API of the Kubernetes, while the API using the apis prefix is the packet API introduced in the development of Kubernetes.

API group

It was mentioned earlier that in the early days of Kubernetes, there were only API prefixed with api, and these API provided the core functions of Kubernetes. With the continuous evolution of Kubernetes, Kubernetes needs to introduce more functions, that is, it needs to provide more API, which not only brings a heavy burden to Kubernetes, but also brings trouble to users.

On the one hand, with the increase of functions provided by Kubernetes, it becomes more and more difficult to develop and maintain Kubernetes itself. On the other hand, users often only need some of the functions provided by Kubernetes. So in order to make Kubernetes easier to expand and evolve, while allowing users to selectively turn on and off non-core functions, Kubernetes designers put forward the idea of API grouping.

The so-called API grouping concept means that the API of Kubernetes is grouped by function. When this concept is proposed, Kubernetes already has a set of core API prefixed with api. Considering the compatibility policy, this group of API is not suitable for modification, so API grouping is actually aimed at non-core extended API. Subsequent newly added functions are prefixed with apis, and the API is divided by group. Some API groups are as follows:

"/ apis/apps" / apis/autoscaling "" / apis/rbac.authorization.k8s.io "...

After the prefix apis is the API group. For example, apps represents a set of API,autoscaling for application management, a set of API,rbac.authorization.k8s.io for application automatic extension, and a set of API for role-based control.

The biggest advantage of grouping API is that users are free to turn on and off the corresponding non-core functions. Users can explicitly control whether a function is enabled or not by using the-runtime-config parameter provided by the kube-apiserver component. For example:

-- runtime-config=autoscaling/v1=false,rbac.authorization.k8s.io/v1=true

The above configuration explicitly turns off the autoscaling function and turns the rbac.authorization.k8s.io function on. It should be noted that a considerable number of API groups are enabled by default, for example, the rbac.authorization.k8s.io group API is enabled by default, which means that rbac.authorization.k8s.io/v1=true is redundant in the above configuration. In this example, it is only used to indicate that the API group can explicitly control enabling and disabling.

Another very important benefit of grouping API is that it can divide each group of API into different versions according to functional maturity, such as v1alpha 1, v1 beta 1, and so on.

API version

Each group of API has a corresponding version to indicate its maturity. For example, there are multiple versions of autoscaling:

"/ apis/autoscaling/v1", "/ apis/autoscaling/v2beta1", "/ apis/autoscaling/v2beta2"

The significance of providing a version for API and the coexistence of multiple versions is to provide users with a clear maturity reference. For example, if the version name contains alpha, it means that the feature is being tested and the application is not recommended in the production environment, so Kubernetes does not enable these features by default. The version name contains beta, which means that the feature is basically available, and users are expected to try and provide feedback. Therefore, Kubernetes often enables these features by default. The version named vx means that the function is fixed, and the corresponding API will not be modified, so users can rest assured to use it.

Multiple versions of each API are provided for API grouping at the same time, which allows each set of functions to evolve at different speeds without having to influence each other.

To understand the functions of an application, starting with API, you can often quickly get an overview of the application, including what it is, what it can do and how to use it. This section briefly introduces the API design of Kubernetes so that readers can have a basic understanding of Kubernetes API macroscopically, laying the foundation for a detailed understanding of each function point, that is, each specific API in the future.

The grouping design of Kubernetes API provides it with unlimited scalability, and this mechanism can easily provide extended functions for Kubernetes. Users can not only use the CRD (Custom Resource Definition) function to provide new API, but also extend the function by extending apiserver.

As mentioned earlier, before the concept of API grouping was proposed, Kubernetes had a set of API prefixed with api, which maintained compatibility. This group of core API was not divided into specific groups, and its API format was prefix/version/resource (missing group name), such as / api/v1/Pods. Usually when we talk about the API version, we often mean group/version, that is, with the group name and version. For the convenience of description, community developers often refer to this special group of API as the core group when they communicate with each other.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.