Kubernetes API Server Principles

Kubernetes API Server Features

The core function of Kubernete API server is to provide an HTTP rest interface for kubernetes, deleting, changing, checking, and watch for various resource objects (such as Node,pod,service, etc.).
The API server is the central hub for data interaction and communication between the various functional modules in the cluster, in addition to the following features:

• API Portal for Cluster management
• Access to resource quota control
• Provides a complete cluster security mechanism

General API Interface

Kubernetes API Server provides services through the kube-apiserver process, typically listening on two ports, 8080 of HTTP (using parameter--insecure-port) and With HTTPS 6443 port (--secure-port=6443), both functions are the same, only HTTPS security is higher.

Common KUBECTL commands are also implemented through the rest call to API server.

You can get information about the rest API directly by using the Curl command.
View versions with local 8080 ports:

[[email protected] ~]# curl  127.0.0.1:8080/api{  "kind": "APIVersions",  "versions": [    "v1"  ],  "serverAddressByClientCIDRs": [    {      "clientCIDR": "0.0.0.0/0",      "serverAddress": "10.0.0.1:6443"    }  ]}

To view supported resource objects:

curl  127.0.0.1:8080/api/v1

To view resource object information:

 curl  127.0.0.1:8080/api/v1/nodes curl  127.0.0.1:8080/api/v1/pods curl  127.0.0.1:8080/api/v1/services curl  127.0.0.1:8080/api/v1/replicationcontrollers

can be specific to a specific object:

 curl 127.0.0.1:8080/api/v1/nodes/10.0.0.3

You can also specify which objects in different namespace to access:

 curl  http://127.0.0.1:8080/api/v1/namespaces/default/services/php-apache

You can also access back-end service content directly:

 curl  http://127.0.0.1:8080/api/v1/namespaces/default/services/http:tomcat-service:/proxy/ curl  http://127.0.0.1:8080/api/v1/namespaces/default/services/http:php-apache:/proxy/

In addition to other API information:

 curl 127.0.0.1:8080/apis/batch/v1

Kubernets Proxy API Interface

Kubernetes Proxy is primarily used for proxy rest requests. This proxy can be used to forward the rest request received by API server to a kubelet on a node, and the Kubelet is responsible for responding.

Create a proxy interface:

  kubectl proxy --port=8001 --accept-hosts=‘.*‘ --address=‘10.0.0.1‘ &

Here, create a listener on the local 10.0.0.1 8001 port.

If you need to restrict access to resources and source addresses, you can use regular matching to restrict access to services:

 kubectl  proxy --port=8001  --accept-hosts=‘.*‘  --address=10.0.0.1  --reject-paths=‘^/api/v1/services‘

This port allows direct access to this API proxy externally, and in the new version, Access is consistent with the URL of the regular access:

 curl  http://10.0.0.1:8001/api/v1/pods curl  http://10.0.0.1:8001/api/v1/nodes curl  http://10.0.0.1:8001/api/v1/services curl  http://10.0.0.1:8001/api/v1/replicationcontrollers curl  http://10.0.0.1:8001/api/v1/namespaces/default/pods/tomcat-deployment-65799d5fc4-5dx4h curl  http://10.0.0.1:8001/api/v1/namespaces/default/services/http:php-apache:/proxy/ curl  10.0.0.1:8001/apis/batch/v1

Interaction of API Server and cluster modules

API server, as the core of the cluster, is responsible for the communication between each functional module of the cluster, and each function module in the cluster is stored in the ETCD database through API server, and the data is obtained through the rest interface provided by API server through the use of get,list. Or watch method, which enables the interaction between the various modules.

View ETCD Data

ETCD V3 Operating Instructions

Reference links

When using the Etcd V3 version, because ETCD uses the V2 interface by default in order to achieve compatibility, kubernetes needs to use the V3 interface to view the data, so add this parameter before viewing it:

export ETCDCTL_API=3    # 修改默认接口版本为V3export ETCDCTL_API=2    # 修改默认接口版本为V2

In V3 and V2, the commands supported by the two are different, such as the Etcdctl ls command in the V2 version, but not in the V3 version, and the corresponding help information will change when the interface version is specified.

When using the default V2 interface, you ls can only see one directory using the command:

# 如果没有TLS进行CA设置直接执行：# etcdctl ls/kubernetes# 如果设置了CA认证，使用如下参数，指定证书和秘钥文件：# etcdctl  --endpoints=https://10.0.0.1:2379  --ca-file=/opt/kubernetes/ssl/ca.pem   --cert-file=/opt/kubernetes/ssl/etcd.pem   --key-file=/opt/kubernetes/ssl/etcd-key.pem ls/kubernetes

Only a small amount of information is stored in this key:

[[email protected] ~]# etcdctl  --endpoints=https://10.0.0.2:2379  --ca-file=/opt/kubernetes/ssl/ca.pem   --cert-file=/opt/kubernetes/ssl/etcd.pem   --key-file=/opt/kubernetes/ssl/etcd-key.pem ls -r/kubernetes/kubernetes/network/kubernetes/network/config/kubernetes/network/subnets/kubernetes/network/subnets/10.2.70.0-24/kubernetes/network/subnets/10.2.67.0-24/kubernetes/network/subnets/10.2.49.0-24[[email protected] ~]# etcdctl  --endpoints=https://10.0.0.2:2379  --ca-file=/opt/kubernetes/ssl/ca.pem   --cert-file=/opt/kubernetes/ssl/etcd.pem   --key-file=/opt/kubernetes/ssl/etcd-key.pem get /kubernetes/network/subnets/10.2.49.0-24{"PublicIP":"10.0.0.2","BackendType":"vxlan","BackendData":{"VtepMAC":"a6:16:81:8a:af:71"}}

Switch to the V3 interface to get all the keys in the ETCD:

export ETCDCTL_API=3# 无ca认证：[[email protected] ~]# etcdctl get / --prefix --keys-only# CA认证，参数和V2版本不一样[[email protected] ~]# etcdctl  --endpoints=https://10.0.0.1:2379  --cacert=/opt/kubernetes/ssl/ca.pem   --cert=/opt/kubernetes/ssl/etcd.pem   --key=/opt/kubernetes/ssl/etcd-key.pem get / --prefix --keys-only

By querying the corresponding key, you can get the metadata for the Kubernete object:

[[email protected] ~]# etcdctl  --endpoints=https://10.0.0.1:2379  --cacert=/opt/kubernetes/ssl/ca.pem   --cert=/opt/kubernetes/ssl/etcd.pem   --key=/opt/kubernetes/ssl/etcd-key.pem get /registry/services/specs/default/php-apache -w=json|python -m json.tool

This uses JSON to format the output. You can see that all the data is stored in the key at the beginning of the/registry/.

Using the following script, the key value is converted and the same key value list can be output:

#!/bin/bash# Get kubernetes keys from etcdexport ETCDCTL_API=3# not use ca TLS# keys=`etcdctl get /registry --prefix -w json|python -m json.tool|grep key|cut -d ":" -f2|tr -d ‘"‘|tr -d ","`# USE TLS cakeys=`etcdctl --cacert=/opt/kubernetes/ssl/ca.pem   --cert=/opt/kubernetes/ssl/etcd.pem   --key=/opt/kubernetes/ssl/etcd-key.pem  get /registry --prefix -w json|python -m json.tool|grep key|cut -d ":" -f2|tr -d ‘"‘|tr -d ","`for x in $keys;do  echo $x|base64 -d|sortdone

Key naming rules are named by/registry, object type (plural), namespace, and specific object name.

API Server interaction with Kubelet

• Each node of the Kubelet sends its own state information to the rest interface of the API Server at intervals.
• After the API server receives this information, it is updated to ETCD.
• In addition, Kubelet listens to the pod's real-time change information through the watch interface of the API server, creates this pod if the new Pod object is being monitored, and, similarly, if the pod is deleted, the modification performs the corresponding action.

Kube-controller-manager interacting with API server

The node controller module in Kube-controller-manager monitors node's information in real-time through the watch interface provided by API server and handles it accordingly.

Kube-scheduler interacting with API server

Scheduler the information of the new pod copy is heard through the watch interface of the API server, it retrieves all the node lists that meet the pod requirements and begins to execute the pod dispatch logic. After the dispatch succeeds, bind the pod to the target node.

In order to alleviate the access pressure of each module to API server, each function module uses caching mechanism to cache the data, each function module 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 function module does not directly access the API server, but instead accesses the API server indirectly by accessing the cached data.

Kubernetes API Server Principles