kube-apiserver

在kubernetes架构里，分为master节点和worker节点，在不同节点上有不同的组件。

master节点的主要组件：

etcd
kube-apiserver
kube-scheduler
kube-controller-manager

worker节点的主要组件：

kubelet
kube-proxy
container runtime

之前已经了解了etcd的原理以及在kubernetes中的应用，etcd作为k8s的数据库，到底是谁在操纵这个数据库？答案就是本篇的主题，kube-apiserver。事实上，kube-apiserver不仅在操纵着etcd，而且还是唯一一个能够直接和etcd通信的组件。

我们可以用很多种方式来访问一个k8s集群，比如kubectl、各种语言的client，一般可能最常用的就是使用kubectl。那么在用kubeclt和集群交互时，本质上是在调用k8s提供的API。比如当kubectl apply -f xxx.yaml时，kubectl会做很多处理，校验之后转变成要调用k8s的API，然后发送给集群。实际上集群在接收API请求的时候，就是API server大显身手的时候。

可以认为API server就是一个集群的gateway，简单来说，其用于处理REST请求，验证请求，更新etcd中相应的object。当API server收到一个请求后，并不是直接就执行该请求，这中间要经过很多步骤，一般来讲至少要经过Authentication、Authorization和Admission Control。个人认为目前的修炼阶段或许不需要了解这三个过程的具体细节，只需要了解每个阶段做了什么事情就可以。

对于Authentication，验证一个请求的发起者是否合法，也就是这个请求到底是谁发起的，这个用户是否合法。该阶段处理的是身份的问题。
对于Authorization，在已经验证用户合法后，还要验证该用户具有哪些权限，有没有权限发起这个请求。该阶段处理的是权限的问题。
对于Admission Control，是资源对象保存到 etcd 之前的最后一个堡垒，封装了一系列额外的检查以确保操作不会产生意外或负面结果。和前面两个操作不同，前两个操作是为了判断用户的身份和权限能不能够发起这次请求，而对于Admission Control也就是准入控制，判断的是这次请求的内容会不会对集群产生什么负面影响。在准入控制阶段，要经过一个准入控制链，在准入控制链下有一系列的准入控制器，用于进行验证。

如果上述三个基本步骤都没有问题的话，那么API server就可以操作etcd了。

大致的流程是这样：