一、概述

Kubernetes API Server 的核心功能是提供了 Kubernetes 各类资源对象（如 PodRC Service 等〉的增、删、改、查及 Watch HTTP Rest 接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。

  • 集群管理的 API 入口。
  • 资源配额控制的入口。
  • 提供了完备的集群安全机制。

通过一个个名为 kube-apiserver 的进程提供服务，该进程运行在 Master节点上。默认情况会在8080端口（-- insecure-port）提供REST服务。可以同时启动 HTTPS 安全端口（ --secure＝6443 ）来启动安全机制。

命令行工具kubectl就是与API Server进行交互的

如果我们想对外暴露部分 REST 服务，则可以在 Master 或其他任何节点上通过运行kubectl proxy 程启动一个 部代理来实现。

1
2
3
4
5
#运行下面的命令，在8001端口启动代理，并且拒绝客户端访问RC的API:
kubectl proxy --reject-paths="^/api/vl/replicationcontrollers" --port=8001 --v=2 

#验证
curl localhost : 8001/api/vl/replicationcontrollers

kubectl proxy 可以提供一个安全有效的机制，采用白名单限制非法客户端访问，

1
--accept-hosts="localhost$,^127\\.0\\.0\\.1$,^\\[::1\\]$"

通过编程的方式调用 Kubernetes API Server .

  • 运行在pod中的进程调用API，Pod是如何知道API Server的访问地址？因为本身也是一个Service，它的Cluster IP是地址池的第一个地址，它所服务的端口是 HTTPS 端口 443 

    1
    kubernetes     ClusterIP   10.96.0.1       <none>        443/TCP          14d

  • 开发基于 Kubernetes 的管理平台,比如调用 Kubernetes API完成Pod，Service ，RC 等资源对象的图形化创建和管理界面

二、独特的 Kubernetes Proxy API接口

最主要的REST接口是资源对象的增、删、改、 查，除此之外，它还提供了一类很特殊的REST 接口一 Kubernetes Proxy API 接口,这类接口的作用是代理REST 请求，即 Kubernetes API Server 把收到的 REST 请求转发到某个 Node 上的 kubelet守护进程的REST 端口上，由 kubelet 进程负责响应.

关于Node的接口，路径为/api/v1/proxy/nodes/{name}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/api/vl/proxy/nodes/{name}/pods/ ＃列出指定节点内所有 Pod 的信息
/api/vl/proxy/nodes/{name}/stats/ ＃列出指定节点内物理资源的统计信息
/api/vl/proxy/nodes/{name}/spec/ ＃列出指定节点的概要信息

这里数据来自Node 而非 etcd数据库，果 kubelet进程在启动时包含--enabledebugging-handlers=true参数
/api/vl/proxy/nodes/{name}/run 
/api/vl/proxy/nodes/{name}/exec 
＃在节点上运行某个容器
＃在节点上的某个容器中运行某条命令
/api/vl/proxy/nodes/{name}/attach ＃在节点上 attach 某个容器
/api/vl/proxy/nodes/{name}/portForward ＃实现节点上的 Pod 端口转发
/api/vl/proxy/nodes/{name}/logs ＃列出节点的各类日志信息，例如 tally log lastlog、wtmp、ppp/、rhsm/、 audit/、 tuned/和 anaconda/等
/api/vl/pr xy/nodes/{name}/metrics ＃列出和该节点相关的 Metrics 信息
/api/vl/proxy/nodes/{name}/runningpods ＃列出节点内运行中的 Pod 信息
/api/vl/proxy/nodes/{name}/debug/pprof ＃列出节点内当前 Web 服务的状态,包括 CPU 占用情况和内存使用情况等

关于Pod的接口，可以访问Pod中的服务

1
2
3
4
/api/vl/proxy/namespaces/{namespace}/pods/{name}/{path}#访问 Pod 的某个服务接口
/api/vl/proxy/namespaces/{namespace}/pods/{name} #访问 Pod
/api/vl/namespaces/{namespace}/pods/{name}/proxy/{path} #访问 Pod 的某个服务接口
/api/vl/namespaces/{namespace}/pods/{name}/proxy #访问 Pod

三、集群功能模块之间的通信

Kubernetes API Server 作为集群的核心， 负责集群各功能模块之间的通信 。集群内的各个功能模块通过 API Server 将信息存入 etcd 当需要获取和操作这些数据时，则通过 API Server 提供的阻ST 接口 （用 GET LIST WATCH )来实现，从而实现各模块之间的信息交互。

常见的一个交互场景是 kubelet 进程与 API Server 交互。每个 Node 节点上的 kubelet 每隔一个时间周期，就会调用一次 API Server REST 接口报告自身状态 API Server 接收到这些信息后，将节点状态信息更新到 etcd 此外， kubelet 也通过 API Server Watch 接口监昕Pod 信息，如果监听到新的 Pod 副本被调度绑定到本节点 ，则执行 Pod 容器的创建和启动逻辑：如果监听到 Pod 对象被删除，则删除本节点上的相应的 Pod 容器：如果监听到修改 Pod信息，则 kubelet 监听到变化后， 会相应地修改本节点的 Pod 容器。

交互 景是 kube-controller-manager 程与 API Server 交互。 kube-controller manager 中的 Node Controller 模块通过 API Sever 提供的 Watch 接口 实时监控 Node 信息并做相应处理。

image-20211107214252984

还有一个比较重要的交互场景是 kube-scheduler与API Server 的交互。当 Scheduler 通过 API Server Watch 接口监听到新建 Pod 副本的信息后，它会检索所有符合该 Pod 要求的 Node表，开始执行 Pod 调度逻辑，调度成功后将 Pod 绑定到目标节点上。

为了缓解集群各模块对 API Server 的访问压力，各功能模块都采用缓存机制来缓存数据。各功能模块定时从 API Server 获取指定的资源对象信息（通过 LIST WATCH 方法），然后将这些信息保存到本地缓存，功能模块在某些情况下不直接访问 API Server ，而是通过访问缓存数据来间接访问 API Server.