Chapter2. Kubernetes API Basics
•API Server
API Server在Kubernetes中是一个核心组件，集群中所有的组件都是通过API Server来和底层的分布式存储etcd进行交互的。API Server的主要指责有几下几点:
1.所有的组件通过API Server来解耦，通过API Server来产生事件和消费事件。2.负责对象的存储和读取，API Server最终还会和底层的etcd交互，将Kubernetes中的对象存储在etcd中。3.API Server负责给集群内部的组件做代理，例如对Kubernetes dashboard、strea logs、service ports、以及kubectl exec等
API Server提供了符合RESTful类型的接口，主要是用于处理HTTP请求去查询和操作Kubernetes的资源，不同的HTTP method所代表的语义不同:
1.Get
获取到指定类型的资源，比如POD、或者是获取一个资源list，例如一个namespace下的所有POD2.POST
创建一个资源，比如service、deployment等3.PUT
更新一个已经存在的资源，比如改变一个POD中的容器镜像4.PATCH
部分更新存在的资源，更多细节见: Use a JSON merge patch to update a Deployment[1]5.DELETE
销毁一个资源
kubectl -n THENAMESPACE get pods 等同于 HTTP GET api/v1/namespaces/THENAMESPACE/pods的结果。
•API Terminology
In Kubernetes programs, a kind directly corresponds with a Golang type.
1.Kind:
表示实体的类型，每一个对象都有一个Kind字段，kind主要有三类。
1. 表示一个持久化的实体对象，比如Pod、Endpoints等2. 一个或多个kind实体，比如PodList、NodeLists等3. 特殊目的，比如binding、scale复制
1.API Group: 一堆Kind的逻辑上所属集合2.Version: API group或者是对象的版本，一个group或对象可以存在多个版本。3.Resource: 通常小写、复数形式(pods) 用来识别一系列的HTTP endpoints路径，用来暴露对象的CRUD语义，例如: .../pods/nginx
查看名为nginx的pod
所有的Resource都是具有CRUD语义的，但是也存在一些Resource可以支持更多的action，比如
.../pod/nginx/port-forward
，这个时候我们称之为Subresources
。这需要通过自定义协议来替代RESET。例如exec是通过WebSockets
来实现的。
在Kubernetes中，每一个Kind是直接映射到一个Golang类型的。
Resources和Kind是相互的，Resources指定HTTP endpoints，而Kind是这个endpoints返回对象的类型，也是etcd中持久化的对象。每一个对象都可以按照version v1来表示，也可以按照v1beta1来表示，可以返回不同的版本
Resources
是API group和version的一部分，三者被称之为GVR(GroupVersionResource)，一个GVR
唯一标示一个HTTP path。例如: /apis/batch/v1/namespaces/default/jobs
通过GVR
可以获取到类型为kind的对象，同理这个对象也是属于这个version和Group的。因此称之为GVK
(GroupVersionKind)
核心组zai api/v1，命名组zai apis/$name/$version，，为什么核心组不是/apis/core/v1呢? 这是因为历史原因导致的，API Group是核心组之后引入的。
例如下面这个http paths，就可以映射到一个GVR
，通过GVR
可以获取到类型为Kind的对象，也就间接的映射到了一个GVK
。
GVK到GVR的映射在Kubernetes中被称之为
REST Mapping
。除了GVR描述的HTTP path外，还存在另外一种类型的HTTP path，比如/metrics
、logs
、healthz
等 通过在HTTP path后面添加?watch=true
就可以watch到请求的资源，具体细节见: watch modus[2]
知道了HTTP path就可以通过curl访问API Server获取到资源，平时我们通过kubectl命令获取资源的方式内部其实也是通过访问HTTP path的方式来获取的，下面列举了两种通过HTTP path获取资源的方式。
kubectl proxy --port=8080curl http://127.0.0.1:8080/apis/batch/v1或kubectl get --raw /apis/batch/v1复制
•API Server如何处理请求
1.首先HTTP request会被DefaultBuildHandlerChain
注册的filters chain来处理(鉴权、admission、validation等)2.接着根据HTTP path走到分发器，通过分发器来路由到最终的handler3.每一个gvr都会注册一个handler
Reference
•Use a JSON merge patch to update a Deployment[1]•watch modus[2]
