API Server
1. 认证
2.鉴权
3.准入
- Mutating
- Validating
- Admission
4.限流
5.API Server 对象的实现
所谓的api-server其实就是整个kubernetes集群控制面的api网关。针对于任何api网关，它都要做自我保护，第一你需要做认证，我要知道你这个请求来自哪里，鉴权我要知道一个请求有没有操作权限。
任何的请求都会以一个对象，object形式发过来，发到apiserver这一端，我还要去校验你这个请求的合法性，除了我要知道你是谁，你有没有这个操作权限，还要看你的request是不是合法的，比如说你的属性设置错了，或者说需要对你的request里面某些属性做变形，上面这些事情都是准入去做的。准入就包含了mutating，validating。
限流也是apisever自我保护的机制， 能够限制同一时间内，最大多少request，这样防止把自己打死。
kube-apiserver 是Kubernetes最重要的核心组件之一，主要提供以下的功能∶
- 提供集群管理的REST API接口，包括认证授权、数据校验以及集群状态变更等
- 提供其他模块之间的数据交互和通信的枢纽（其他模块通过 APIServer 查询或修改数据，只有API Server 才直接操作 etcd）（在k8s技术栈里面，应该只有apiserver自己去连etcd，因为apiserver这边可以对etcd做些保护操作，比如限流的操作，认证鉴权的操作，它是挡在etcd之前的一个守护者，apiserver这边又有缓存的机制，其实很多的读操作就在apiserver这边处理掉了，它不会再将请求转到etcd里面去，这样的话其实有效的减少了整个集群对etcd的并发请求）。
访问控制概览
Kubernetes API的每个请求都会经过多阶段的访问控制之后才会被接受，这包括认证、授权以及准入控制（Admission Control）等。
从apiserver接收到请求，到数据存储到数据库，中间经历了哪些流转。
request发送到apiserver，首先最开始有HTTP handle，这个handle接收到这个请求之后，请求会被发送到认证鉴权两个模块，认证其实就是就是api网关最基础的能力，我要知道你是谁，这里提供了一系列的认证手段。
鉴权：我知道的你是谁之后，然后要知道你有没有操作权限。
认证鉴权之后，比如说某个请求属性没有设置，我希望给你一个默认值，或者修改你的属性值。这个时候我希望在apiserver端对你的request增加一些属性，这个对方就会走mutating，所谓的mutating就是变形，它是支持webhook的，除了kubernetes自身可以对你这个数据做一些修改，你还可以通过一些webhook来针对这些对象做一些修改。
mutating做完之后，就走入了k8s自定义的这些对象的schema validation，由于之前做过变形，我要去看变形之后的对象是不是合法的，是不是符合kubermetes的规范。
做完上面的之后，如果你还要去做一些附加的校验，比如说k8s规定的名字不能超过255，但是我希望名字在我自己的生产环境里面不超过63，那么你就可以附加一些最强的validation在webhook里面，通过validating admission plugin来调用你的webhook，把你的校验逻辑加上去。
最后所有的这些流转做完了之后，整个数据才会存放到etcd里面去，到此位置，数据的持久化就做完了。
访问控制细节
apiserver在收到请求之后，进来之后是panic recovery，因为apiserver相对于一个服务器，它会启动不同的goroutine来处理不同的请求，当这些请求出现panic的时候，这时候就要确保某个goroutine panic不会将整个http server搞死，所以这里就有panic recovery的机制。
之后就是设置request-timeout，request超时时间，假设后面的请求没有被及时的处理，那么request就失败了，如果不设置request超时时间就意味着这个connection一直连接着的。
接下来做认证，认证玩了就去做审计，这里面会去记录谁对哪些对象做了哪些操作，所以审计很多时候是有效的，比如是平台的维护方，上面跑了很多的应用，很多时候经常有用户跑过来说为什么跑在你集群上面的对象我的业务无缘无故就消失了，肯定是你们做了什么操作，这个时候查auditlog，几乎百分之百就是客户自己删除的，因为作为运营方不会去碰用户的业务。
impersonation：它是一个request发送到http server这一端的时候，你可以为这个request加上header，这些header可以模拟这个request给谁用，request代表哪个用户，现在用的不太广泛。
在以前集群联邦的层面，我从联邦集群发下来的request，集群联邦连每一个member cluster的时候用的是root的kubeconfig，但是集群联邦的层面是代用户去分发这些request，通过impersonation我们就会将用户的真实的信息填在这个request里面，那么这个request发到集群下面的话，那么api server就会去读impersonation的信息来判断request是谁的，以此来做权限的校验，来判断用户有没有这个对象的操作权限。
max-in-flight是原来做限流的，也就是apiserver里面能够最多处理多少个请求，如果超过就拒绝。
限流之后完了就去做鉴权，鉴权去判断你有没有这个操作权限。
然后接下来会有一个比较重要的组件，kube-aggregator，因为apiserver本身是http处理器，它可以将request转走，在这里面aggregate就会判断说现在的request是不是标准的k8s对象，如果是，那么默认的apiserver就处理掉了，但是你想做扩展，比如说你自定义的k8s一些对象，然后你有另外的apiserver来支撑这些新对象，那么你就可以在这里面做些配置，k8s会去判断好像有些请求不是k8s内定的，通过读取配置将你的request转到其他地方，那么它就会将request发到aggregate apiserver，也就是它本身是一个代理了，有些请求就转出去了，没有转出去的request会被本地处理。
到本地这里，之前的request都是json，这里面就要去做decoding，就是将这个对象给它反序列化，反序列化就变成了go的一个个对象了，这里需要做一个conversion，也即是将外部的结构转化为内部的结构，k8s任何的对象都有external version和internal version，external version是面向用户的，internal version是面向自己的实现，然后他就将对象转化为internal version，你可以理解将internal version存在了etcd里面。
先去做转换conversion，然后去做admission，admission就是有几个步骤，先去看有没有mutating webhook，有就调用，如果没有就走内置的validating这个流程，那么内置的validating k8s自己对象里面会去实现，比如对pod来说做哪些校验规则，它会去调用这些方法来校验这个pod是不是合法的，比如容器的image没有提供，那么这里面肯定是不过的。
做完内置的validating你想做附加的validating那么它就去看看你没有附加的validating webhook，如果有的话就去调用。
上面这些都通过了就存入到etcd，etcd存完了之后就返回客户端。