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

This article will explain in detail how the analysis of the principle of kubernetes API Server is, and the content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

One: brief introduction

K8s API Server provides the addition, deletion, modification and query of all kinds of K8s resource objects (pod,RC,Service, etc.) and HTTP Rest interfaces such as watch, which is the data bus and data center of the whole system. Functional features:

1. Is the API entry for cluster management

2. Is the entrance to resource quota control

3. It provides a perfect cluster security mechanism.

Two: an overview

You can usually interact with API Server through the command-line tool Kubectl, the interface between them is REST calls, and you can also use the curl command-line tool for quick verification. The access path to API Server is obtained by configuring the parameter KUBE_MASTER= "--master= http://10.116.137.196:8080" customer.

1. Get the version information of API

Curl 10.116.137.196:8080/api

Click (here) to collapse or open

{

"kind": "APIVersions"

"versions": [

V1

]

"serverAddressByClientCIDRs": [

{

"clientCIDR": "0.0.0.0amp 0"

"serverAddress": "10.116.137.196pur6443"

}

]

}

2. Gets the types of resource objects currently supported

Curl 10.116.137.196:8080/api/v1

{

"kind": "APIResourceList"

"groupVersion": "v1"

"resources": [

{

"name": "bindings"

"singularName":

"namespaced": true

"kind": "Binding"

"verbs": [

"create"

]

}

{

"name": "componentstatuses"

"singularName":

"namespaced": false

"kind": "ComponentStatus"

"verbs": [

"get"

"list"

]

"shortNames": [

"cs"

]

}

{

"name": "configmaps"

"singularName":

"namespaced": true

"kind": "ConfigMap"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"cm"

]

}

{

"name": "endpoints"

"singularName":

"namespaced": true

"kind": "Endpoints"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"ep"

]

}

{

"name": "events"

"singularName":

"namespaced": true

"kind": "Event"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"ev"

]

}

{

"name": "limitranges"

"singularName":

"namespaced": true

"kind": "LimitRange"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"limits"

]

}

{

"name": "namespaces"

"singularName":

"namespaced": false

"kind": "Namespace"

"verbs": [

"create"

"delete"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"ns"

]

}

{

"name": "namespaces/finalize"

"singularName":

"namespaced": false

"kind": "Namespace"

"verbs": [

"update"

]

}

{

"name": "namespaces/status"

"singularName":

"namespaced": false

"kind": "Namespace"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "nodes"

"singularName":

"namespaced": false

"kind": "Node"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"proxy"

"update"

"watch"

]

"shortNames": [

"no"

]

}

{

"name": "nodes/proxy"

"singularName":

"namespaced": false

"kind": "Node"

"verbs": []

}

{

"name": "nodes/status"

"singularName":

"namespaced": false

"kind": "Node"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "persistentvolumeclaims"

"singularName":

"namespaced": true

"kind": "PersistentVolumeClaim"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"pvc"

]

}

{

"name": "persistentvolumeclaims/status"

"singularName":

"namespaced": true

"kind": "PersistentVolumeClaim"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "persistentvolumes"

"singularName":

"namespaced": false

"kind": "PersistentVolume"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"pv"

]

}

{

"name": "persistentvolumes/status"

"singularName":

"namespaced": false

"kind": "PersistentVolume"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "pods"

"singularName":

"namespaced": true

"kind": "Pod"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"proxy"

"update"

"watch"

]

"shortNames": [

"po"

]

"categories": [

"all"

]

}

{

"name": "pods/attach"

"singularName":

"namespaced": true

"kind": "Pod"

"verbs": []

}

{

"name": "pods/binding"

"singularName":

"namespaced": true

"kind": "Binding"

"verbs": [

"create"

]

}

{

"name": "pods/eviction"

"singularName":

"namespaced": true

"group": "policy"

"version": "v1beta1"

"kind": "Eviction"

"verbs": [

"create"

]

}

{

"name": "pods/exec"

"singularName":

"namespaced": true

"kind": "Pod"

"verbs": []

}

{

"name": "pods/log"

"singularName":

"namespaced": true

"kind": "Pod"

"verbs": [

"get"

]

}

{

"name": "pods/portforward"

"singularName":

"namespaced": true

"kind": "Pod"

"verbs": []

}

{

"name": "pods/proxy"

"singularName":

"namespaced": true

"kind": "Pod"

"verbs": []

}

{

"name": "pods/status"

"singularName":

"namespaced": true

"kind": "Pod"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "podtemplates"

"singularName":

"namespaced": true

"kind": "PodTemplate"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

}

{

"name": "replicationcontrollers"

"singularName":

"namespaced": true

"kind": "ReplicationController"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"rc"

]

"categories": [

"all"

]

}

{

"name": "replicationcontrollers/scale"

"singularName":

"namespaced": true

"group": "autoscaling"

"version": "v1"

"kind": "Scale"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "replicationcontrollers/status"

"singularName":

"namespaced": true

"kind": "ReplicationController"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "resourcequotas"

"singularName":

"namespaced": true

"kind": "ResourceQuota"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"quota"

]

}

{

"name": "resourcequotas/status"

"singularName":

"namespaced": true

"kind": "ResourceQuota"

"verbs": [

"get"

"patch"

"update"

]

}

{

"name": "secrets"

"singularName":

"namespaced": true

"kind": "Secret"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

}

{

"name": "serviceaccounts"

"singularName":

"namespaced": true

"kind": "ServiceAccount"

"verbs": [

"create"

"delete"

"deletecollection"

"get"

"list"

"patch"

"update"

"watch"

]

"shortNames": [

"sa"

]

}

{

"name": "services"

"singularName":

"namespaced": true

"kind": "Service"

"verbs": [

"create"

"delete"

"get"

"list"

"patch"

"proxy"

"update"

"watch"

]

"shortNames": [

"svc"

]

"categories": [

"all"

]

}

{

"name": "services/proxy"

"singularName":

"namespaced": true

"kind": "Service"

"verbs": []

}

{

"name": "services/status"

"singularName":

"namespaced": true

"kind": "Service"

"verbs": [

"get"

"patch"

"update"

]

}

]

}

3. If you want to expose only part of the REST service to the public, you can do this by running the kubectl proxy process to start an internal agent on Master or any other node

Kubectl proxy-port=8001

Three: Kubernetes Proxy API interface

The main REST interface of API Server is the addition, deletion, modification and query of resource objects. In addition, there is a special kind of REST interface-Kubernetes Proxy API interface, which acts as a proxy for REST requests, that is, kubernetes API Server forwards the received REST requests to the REST port of the kubelet daemon on a Node, and the kubelet process is responsible for responding.

1.Node-related interfaces

Click (here) to collapse or open

/ api/v1/proxy/nodes/ {name} / pods/ # lists the information of all Pod in the specified node

/ api/v1/proxy/nodes/ {name} / stats/ # lists the statistics of physical resources within a specified node

/ api/v1/prxoy/nodes/ {name} / spec/ # lists the summary information of the specified node

The Pod information obtained here comes from Node rather than etcd database, and there may be a deviation between the two points in time.

2.Pod-related interfaces

Click (here) to collapse or open

/ api/v1/proxy/namespaces/ {namespace} / pods/ {name} / {path:*} # access a service interface of pod

/ api/v1/proxy/namespaces/ {namespace} / pods/ {name} # visit Pod

# the following is written differently, but the function is the same

/ api/v1/namespaces/ {namespace} / pods/ {name} / proxy/ {path:*} # access a service interface of pod

/ api/v1/namespaces/ {namespace} / pods/ {name} / proxy # visit Pod

The function of Pod's proxy API: access the service (HTTP service) of a pod container outside the kubernetes cluster, which can be implemented with Proxy API. This scenario is mostly used for management purposes, such as checking the Pod copies of Service one by one and checking which Pod services have abnormal problems.

3.Service-related interfaces

Click (here) to collapse or open

/ api/v1/proxy/namespaces/ {namespace} / services/ {name}

Four: communication between cluster function modules

As the core of the cluster, kubernetes API Server is responsible for the communication between the functional modules of the cluster. each functional module in the cluster stores the information in etcd through API Server, and when it needs to obtain and operate these data, it is realized through the REST interface provided by API Server (GET\ LIST\ WATCH method), so as to realize the information exchange between the modules.

1. Kubelet interacts with API SERVER

Kubelet on each Node node periodically calls API Server's REST interface to report its own status. After receiving this information, API Server updates the node status information to etcd. Kubelet also listens for Pod information through the Watch interface of API Server, thus managing POD on Node machines.

2. Kube-controller-manager interacts with API SERVER

The Node Controller module in kube-controller-manager monitors the information of Node in real time through the Watch interface provided by API Server, and deals with it accordingly.

3.kube-scheduler interacts with API SERVER

After Scheduler listens to the information of the newly created Pod copy through the Watch interface of API Server, it retrieves all the Node lists that meet the requirements of the Pod and starts executing the Pod scheduling logic. Bind the Pod to the target node after scheduling is successful.

Five: explanation

In order to alleviate the pressure of each module to access API Server, each functional module uses caching mechanism to cache data. Each functional module regularly obtains the specified resource object information (LIST/WATCH method) from API Server, and then saves the information to the local cache. In some cases, the functional module does not directly access API Server, but indirectly accesses API Server by accessing cached data.

On the kubernetes API Server principle analysis is how to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.