浅说Kubernetes中API的概念

一、Kubernetes API Conventions
	· 个人觉得深入Kubernetes之前，首先学习一下Kubernetes的API基本概念可能会更有利于去理解整体的代码设计；

	· 从整体看，大体分为了Kind、Resource、API Group三个模块；
	  其中Kind最为负责，下面又分为了Simple Kind、List、Object三类；
	  Object下面又有CRD(Customer Resource Definition) 去定义 CR(Customer Resource)；


二、Resource
	· Resource是Kubernetes中API Conventions中最重要的一个模块；

	· Resource是Kubernetes中的实体，api server以yaml或者json等格式在HTTP协议下接收或者发送；
	  Resource可以单独对API server外部暴露，通过一个URL定位到一个具体的Resource；
	  也可以通过集合的方式对外暴露一组同类型的Resource；

	· Resource可以理解为Restful中的资源概念，例如 用户数据库中的一个用户就是resource；
	  一个Resource逻辑上就是一个 有唯一id的 实体； 一个Resource与他的URL一一对应；


三、API Group
	· API Group就是对一组Resource的集合，代表了一组一同暴露的Resource，这组Resource划分为不同的Version暴露出去(GVK中的G)；

	· group的命名方式采用域名式命名，而kubernetes自己可以使用空域名定义group，例如"apps"、"events"、"node"、"policy"(这些都是group但是没有域名)；

	· Group和Version共同构建了API Version的概念，格式为group/Version(也就是GVK中的GV)，例如"policy.k8s.io/v1"；
	  一个Group下面可以有多个Version，例如"apps/v1beta1"、"apps/v1beta2"、"apps/v1"；


四、Kind
	· 每一个Kind就是一个"Schema"，就是定义一个事务可以拥有什么属性的"文档"；

	· 例如 可以说"狮子"是一个Kind，"大象"又是另一个Kind，它们分别定义了两种事物拥有不同的属性的集合；

	· 在Kubernetes中，常见的Kind有"Pod"、"ReplicaSet"、"StatefulSet"等等，它们都是不同属性集，而不同方法的对象就是不同的Kind；

	· Kind和Resource的关系：
		举个例子，Resource就像是动物园中一只只动物构成的群体，而Kind就是教科书上"狮子"、"大象"的类型定义；
		每一个Resource对应唯一的Kind，而Kind可能需要多个Resource构成，例如 Pod(Kind)需要除了Pods(Resource)以外还需要status等；

	· Kind的三种类型(Type：sub category)：
		1. Object：	表示该type下kind的实例代表的是存储的实体(etcd)；
		2. List：	表示该type下Kind的实例代表一组实体；
		3. Simple Kind：	表示该type下的kin的实例一般是那些临时使用的、虚拟的、不会单独存储的实体；

	· Object：	
		· Object代表了存储在系统中的实体的类型，
		  使用者创建一个Object实例时描述的是"期望"，记录在Spec部分；
		  而系统在得到这个实例时，会负责满足该期望，把实时状态记录在Status中；

		· 一个Object实例可以通过一个或者多个Resource来进行操作；
		  例如一个Pod实例，可以通过操作pods Resource和其status Resource进行操作；

		· Object定义的Schema中必要的属性：
			1. apiVersion + kind：也就是GVK；
			2. metadata：用于区分于其他对象的信息，例如"name"、"annotation"等等；
			3. spec：用于描述实例期待的资源状态；
		  可以发现这就是yaml文件中的字段。

	· List：	
		· List类型的Kind是以List结尾，他代表了一个类型，该类型的实例是由多个resource实例构成的集合；
		  List描述的是这类集合具有的属性(Schema)；
		  可以通过URL返回该Kind对应的所有Resource(所有Object实例中的Resource)

		· 例如 PodList、ServiceList、NodeList

	· Simple Kind：	
		· 是一些不会被单独存储的实体类型，往往以子Object的形式出现，用于对外暴露针对主Object某些方面；

		· 例如 Scale就是一个Simple Kind，它是deployment Kind的一个"投影"，通过Scale使用者使用"Kubectl scale"命令来对deployment进行扩容或者缩容；
		  同时作为一个资源，它也会对应Url，就可以被外界通过restful访问；

		· 当主Object过大，内容过多时，如果他的"操作面"始终是整体的话，那么所有使用者就能修改那些与自己无关的部分；
		  通过定制小粒度的simple kind，让它只包含一部分object属性，去暴露给相关的操作人，就可以正对这个simple Kind去制定RBAC(基于角色的访问控制)；
		  从这个角度来看，simple kind可以理解为view；


五、CRD 和 CR
	· CRD：
		· Custom Resource Definition(自定义资源类型)，根据之前的介绍，或许成为COD更合适一点；
		  它的产物是Custom Resource (Custom Object)，是一个Schema，规定了一类实体可以有什么属性；

		· CRD自身也是一个API Object(Kind -- Object)，它的GVK是：
			"group": "apiextensions.k8s.io",
			"kind": "CustomResourceDefinition",
			"version": "v1"

	· CR：
		· CR(或者说CO)是CRD的产物，根据CRD确定自身有什么属性，为这些属性赋值来定义一个该实例；

		· 一个CR实例可以直接类比为一个Pod实例，可以像Pod这个Object一样去使用一个CR；