k8s从入门到精通（六）：三张图理解 kube-apiserver

Apiserver是Kubernetes最核心的组件，它是整个集群API的入口，每个组件都需要和他交互。Kubernetes所有资源数据都是通过Apiserver保存到后端Etcd，当然它本身还提供了对资源的缓存。因为apiserver本身是无状态的，所以在集群的高可用部署中，可以部署成多活。

Kubernetes API接口主要分为组、版本和资源三层，如下所示整个接口层次，对于“/apis/batch/v1/jobs”接口，batch是组，v1是版本，jobs是资源。Kubernetes的核心资源都放在“/api”这个接口下面，扩展的接口放在“/apis”下。

Kubernetes资源会同时存在多个版本，当新的资源接口刚加入还不成熟通常会说使用alpha版本，伴随着充分测试逐渐成熟后会变更为beta版本，最终稳定版本v1 版本。譬如job这个资源当前是在“/apis/batch/v2alpha1”和“/apis/batch/v1beta1”中都存在，伴随着该功能的完善，后期将会迁移到V1下面。

Apiserver启动后会将每个版本的接口都注册到一个核心的路由分发器（Mux），当客户端请求到达Apiserver后首先经过Authentication认证和Authorization授权，认证支持Basic、Token以及证书认证等，授权目前默认使用的是RBAC。经过路由分发到指定的接口，为了兼容多个资源版本，请求的不同版本的资源类型会统一转化为一个内部资源类型，然后进入Admission准入控制和Validation资源校验，在准入控制采用插件机制，用户可以定义自己的注入控制器验证并更改资源配置，资源校验主要是验证参数是否合法，必传参数是否齐备等。最后再转化到用户最初的资源版本并保存到ETCD中。整个流程如下所示：

了将外部传入不同版本的资源类型统一转化为对应的内部类型，那么需要这个内部资源类型能够兼容不同版本的外部资源。下图截取autoscaling部分代码结构图，内部的版本定义在types.go文件中，如果是其他版本和内部版本之间转化可以通过自动生成的zz_generated.conversion.go或者自定义的conversion.go完成。由于v2beta2版本的autoscaling可以直接转化为内部autoscaling，而v1版本的autoscaling并不支持多指标（只能根据CPU扩容），所以需要在conversion.go中将CPU指标当做多指标中的一个指标处理。