Deep anatomy kubernetes API Server Trilogy-Part 1

Welcome to an in-depth study of the Kubernetes API Server series, in this series of articles we will delve into the implementation of Kubernetes API server. This series of articles can help you if you are interested in Kubernetes's internal implementation mechanisms or are working on the development of kubernetes projects. Learning to learn the go language will help you to better understand this series of articles in some ways.
In this installment, we'll start with a general overview of Kubernetes API server and then describe the technical terminology and request flow for the API. In the next few installments, the main interaction between API server and ETCD storage and the extension of API server are discussed.
General description of API server
Theoretically, Kubernetes is made up of a number of nodes with different roles. The master node as the control surface is primarily deployed with components such as API Server, controller Manager, and Scheduler (s). As the central administration in Kubernetes, API server is the only component that can interact with storage etcd. It is mainly able to provide the following services:

2. Serves as the server for the Kubernetes API, providing API services for nodes within the cluster as well as KUBECTL tools.
4. As a proxy for cluster components, such as the Kubernetes UI
6. Through the API server can be Kubernetes API objects such as pods,services and other operations such as adding and deleting.
8. Ensure that the Kubernetes API objects in the Distributed Storage System (ETCD) are in the same state.
   
   The Kubernetes API is an HTTP form of the Api,json format that is its primary serialization schema. It also supports the form of protocol buffers (Protocol buffers), which is mainly used in intra-cluster communication. For extensibility reasons, Kubernetes can support multiple API versions, differentiated by different API paths. For example,/API/V1 and/APIS/EXTENSIONS/V1BETA1, different API versions represent that the API is in a different version stability phase.
10. The Alpha phase, such as V1ALPHA1, is turned off by default. Supported in only one branch and may be discarded in the future. It is generally only supported for short-term use in test environments.
12. The beta phase, such as V2BETA3, is enabled by default. Indicates that this part of the code has been tested and the basic functionality has been validated. However, there is a possibility that incompatible changes will occur in the API object of this state in the future to over-stable the stable phase.
13. The stable phase, such as V1, is a stable software release phase, and API objects generally do not change much later.
    Next, let's introduce the main structure of the HTTP API. First we need to differentiate between three different API forms: the core Group API (under the/API/V1 path, which is not in the/APIS/CORE/V1 path for some historical reasons) and the named Groups API (in the corresponding/apis/$NAME/$ Version path) and the System-wide API (such as/metrics,/healthz).
    The main structure of an HTTP API is as follows:
    
    Next we will mainly enumerate the two API examples under batch group to illustrate the explanation. In the Kubernetes 1.5 release, the batch group has/APIS/BATCH/V1 and/APIS/BATCH/V2ALPHA1 two API editions that are intended for use by developers. Let's take a look at the overall implementation of the API (the API examples listed below are obtained through the proxy command Kubectl proxy--port=8080 direct access API).
    $ Curl HTTP://127.0.0.1:8080/APIS/BATCH/V1
    {
    "Kind": "Apiresourcelist",
    "Apiversion": "V1",
    "Groupversion": "Batch/v1",
    "Resources": [
    {
    "Name": "Jobs",
    "namespaced": true,
    "Kind": "Job"
    },
    {
    "Name": "Jobs/status",
    "namespaced": true,
    "Kind": "Job"
    }
    ]
    }
    In the future, the updated Alpha version will be used:
    $ Curl HTTP://127.0.0.1:8080/APIS/BATCH/V2ALPHA1
    {
    "Kind": "Apiresourcelist",
    "Apiversion": "V1",
    "Groupversion": "Batch/v2alpha1",
    "Resources": [
    {
    "Name": "Cronjobs",
    "namespaced": true,
    "Kind": "Cronjob"
    },
    {
    "Name": "Cronjobs/status",
    "namespaced": true,
    "Kind": "Cronjob"
    },
    {
    "Name": "Jobs",
    "namespaced": true,
    "Kind": "Job"
    },
    {
    "Name": "Jobs/status",
    "namespaced": true,
    "Kind": "Job"
    },
    {
    "Name": "Scheduledjobs",
    "namespaced": true,
    "Kind": "Scheduledjob"
    },
    {
    "Name": "Scheduledjobs/status",
    "namespaced": true,
    "Kind": "Scheduledjob"
    }
    ]
    }
    In general, the Kubernetes API supports adding and removing changes to API objects (create, update, delete, retrieve) by using JSON as the default format for HTTP (POST, PUT, delete, GET).
    Most API objects distinguish between the expected state that an object wants to achieve and the actual state of the current object. Therefore, a canonical API description should have a complete description of both states and be recorded in storage (ETCD).
    Terminology description for API server
    After a general description of the API server and the HTTP API structure, we will explain some of the terms. Kubernetes's main API objects are pods, services, endpoints, deployment, etc. An API object mainly consists of the following entries
    Kind: Is the type of an API object. It tells the entity type that the client (such as Kubectl) represents for the API object. Like a pod.
    Apiversion:v1
    Kind:pod
    Metadata
    Name:webserver
    Spec
    Containers
    • Name:nginx
      image:nginx:1.9
      Ports
    • Containerport:80
      There are currently three types of kinds in the API:
15. Object objects represent persistent entities in the system, and a single Object object may have multiple resources to allow the client to perform certain operations. Like pods and namespace.
17. Lists represents a collection of resources or object entity objects. Like Podlists and nodelists.
18. Represents an operation on an entity object or a state process in which a non-entity exists. such as binding or status.
    API Group: is a collection of related kind. For example, in Kind:job and kind:schedulejob belong to batch's API Group.
    Version: Multiple versions of version can exist under each API group. For example, in a group group the first V1ALPHA1 version, later developed into the V1BETA1 version, eventually developed to V1 stable version. If a v1beta1 version of an object is created on the system, it can be retrieved by any supported version of group (such as V1). This is because API server can support lossless conversions between different versions of objects.
    Resource: Represents a resource entity that is sent or retrieved in JSON format over HTTP. It can either make a separate resource resource (such as .../namespaces/default) or a set of resource resources (such as .../jobs)
    An API group group, a version, and a resource (GVR) resource can define a unique HTTP path.
    
    In fact, the API path for a Job object is/apis/batch/v1/namespaces/$NAMESPACE/jobs, because jobs is not a resource on the cluster side, so a NAMESPACE field is required. As opposed to node as a resource on the cluster side, its API path has no $namespace part.
    It is important to note that kinds does not necessarily have different versions of version under the same group group, it may have different version versions in different group groups. For example, deployment initially existed as an alpha version in the Extensions group group, but eventually it developed into GA version with a new independent group group Apps.k8s.io. Therefore, if you want to differentiate between unique kinds, you must have the API Group,version and kind (GVK) three parts.
    API Request Flow Process
    After understanding the terminology in the Kubernetes API, we will discuss the process of API requests. The related API is primarily visible in K8s.io/pkg/api, which handles API requests from within the cluster as well as API requests from outside the cluster.
    When API server receives an HTTP Kubernetes API request, its main processing flow is as follows:
20. The HTTP request is handled by a set of filter handlers defined in the Defaultbuildhandlerchain () () (Config.go) function, and related operations are performed (the relevant filtering handler functions are shown). These filtering handlers save the HTTP request to Central CTX. Requestinfo, such as the user's relevant authentication information, or the corresponding HTTP request return code.
22. Then Multiplexer (CONTAINER.GO) based on the HTTP path will send the HTTP request to the corresponding respective processing handlers.
24. The routes (defined in routes/*) Route associates the HTTP path with the handlers processor.
26. According to each API group registered handler gets the HTTP request related content object (such as user, permission, etc.) and stores the requested content object in storage.
    The complete processing flow is as shown
    
    Again, for the sake of brevity, we omit the $namespace field in the HTTP path.
    Let's take a closer look at the related filters filter handlers defined in the Defaultbuildhandlerchain () (config.go) function:
28. The Withrequestinfo () function, defined in Requestinfo.go, primarily gets the requestinfo content of the HTTP request.
30. The Withmaxinflightlimit () function that is defined in Maxinflight.go limits the number of in-flight requested.
32. The Withtimeoutfornonlongrunningrequests () function, defined in Timeout.go, defines the time-out for non-long-running requests like get, PUT, POST, delete, and so on.
34. The Withpanicrecovery () function, defined in Wrap.go, mainly defines the related processing when panic occurs.
36. The withcors () function defined in Cors.go provides the cors implementation primarily. Cors stands for cross-origin resource sharing, which is a mechanism that allows xmlhttprequests requests to be processed by JavaScript embedded in HTML pages.
38. The withauthentication () function defined in Authentication.go primarily validates the user information in the request and saves the user information in the appropriate context. If the authentication succeeds, then the authorization HTTP header will be removed from the request body.
40. The Withaudit () function, defined in Audit.go, mainly deals with the user information of the request. The source IP, user name, user action and namespace of request requests are then credited to the relevant audit log.
42. The Withimpersonation () function, defined in Impersonation.go, primarily handles user impersonation by trying to modify the way the requested user (such as sudo) works.
44. The Withauthorization () function in Authorization.go defines the user right in the primary request for authentication, and if the validation is sent to the appropriate handler for processing, the request is rejected if the authorization is not passed, and a corresponding error is returned.
    This part of the article is a general introduction to API server. In the next section, we will explore the serialization of API resources and how to deposit them into related distributed storage. Https://www.huaweicloud.com/product/cce.html

Deep anatomy kubernetes API Server Trilogy-Part 1