本文已参与「新人创作礼」活动，一起开启掘金创作之路。
作者按：
熟悉k8s的小伙伴应该知道，master节点的核心就是api服务，REST API是k8s的基本架构。在k8s中一切都可抽象为资源，平台视一切为API对象，通过api调用。所以api server提供http api，能够提供用户、集群中的不同的组件和外部的组件之间的同行，可以查询操作k8s中的api对象的状态（pod、ns、configmap、event）。下面就来研究一番。
1、API版本控制
不同API版本代表不同稳定性和支持级别，每个级别简要介绍：
- Alpha：例如v1alphal，可能有bug、有些特性会随时删除、缺乏长期支持、仅用于短期测试。
- Beta：例如v1beta2，被很好的测试过，特性是长期支持、api对象可能会在后期发生改变，不建议生产使用，后期可能无法兼容。
- Stable：例如vx，x为整数，表明特性稳定，长期支持，稳定版。
2、API组
这个能够简化k8s后期api的扩展，api组信息会出现在REST路径当中,也出现在序列化对象apiVersion字段中：
- 核心组：路径api/v1，核心组不作为apiversion字段的一部分
- 指定组：路径/apis/组名字/版本，例如apiVerison:btach/v1.具体可上官网的API参考文档查看
编辑搜图
API组
3、Apiserver功能
- 提供集权管理RESTAPI接口，（数据校验、认证授权、集群状态变更等）
- 模块与模块之间的通信（通过apiserver查询、修改，因为只有apiserver能够直接操作etcd数据库）
- 集群状态存储操作通过etcd
4、REST API
K8s的apiserver提供https和http AP。Https默认监听端口6443（--secure-port修改默认端口），非本地ip（启动参数—bind-address修改默认）、http是本地locahost（启动参数—insecure-bind-address修改默认ip）的8080端口，启动参数值（--insecure-port修改默认端口）http api是非安全接口，不能做任何授权机制、生产环境不建议启用、两个接口提供的REST API格式是一样的，调用格式上官网查询，这里引用一下（openshift blog）网图
API组
5、API访问
Kube-apiserver进程提供服务，运行在master节点上。实际使用，是通过kubectl命令行工具或其他openapi支持的语言，或者kubectl proxy，作为普通客户端访问apiserver的代理，（kuetl proxy –port=8080）。来访问apiserver、kubectl相关常用命令相信大家已经很熟悉了，在我另一篇文章中有写，可以参考。可以通过kubectl api-versions kubectl api-resources查询api支持的版本和资源对象。Api的每个请求会经过多个阶段访问控制（认证、授权、准入控制等）。
Apiserver最主要的REST接口是资源对象的增删改查，特殊的接口还有proxy api，用来代理REST请求，apiserver收到的REEST请求转发到node上的kublet守护进程的REST端口
6、交互场景
- Kubelet与apiserver：每个node节点上kubelet每隔一段时间周期，就会调用apiserver REST接口汇报自身状态，apiserver接收到后，将节点状态信息更新到etcd，kubelet通过apiserver watch接口监听pod、pod如果调度到本节点，就进行创建删除修改pod。
- Kube-controller-manager与apiserver：通过apiserver提供的watch接口监控node信息，实时监控node，如果不可用进行标记等相应操作。
- Kube-scheduler与apiserver：watch接口监听新建pod信息，检索符合pod要求的node，开始调度、将pod绑定到目标节点。
注意：调用比较多，api压力如何分担，利用缓存机制缓存数据，是从api获取指定对象，将信息保存到本地、然后部分情况不直接访问apiserver、是通过缓存访问。
