Kubernetes API的使用方式
Kubernetes API属于声明式API编程， 它和常用的命令式编程有一些区别。 通俗的说，命令式编程是第一人称，我要做什么，我要怎么做。 操作系统最喜欢这种编程范式了， 操作系统几乎不用"思考", 只要一对一的将代码翻译成指令就可以了。 而声明式编程则类似于"第二人称"， 也就是你要做什么。 有点"产品经理"和"开发“之间的关系， "产品经理"只负责提需求，而"开发"怎么实现他不并关心。
用户相对Kubernetes就是"产品经理"的角色， 用户只需要给Kubernetes提需求就可以了，比如说你(Kubernetes)给我(用户)创建一个运行Mysql服务的Demployment，这个Deployment运行的Pod镜像是xxxx，运行参数是xxxxx，挂载的数据卷是xxxxx。。。。。 等等。 开发(Kubernetes)接受到这个需求后，看看需求是否合理(验证Deployment里面的参数是否正确)，然后就开始创建了。 等待创建成功后，就告诉"产品经理"(用户)Deployment创建成功。
在创建过程中，用户并没有(也不需要)关心服务是如何创建的。 这种操作方式就是声明式API。
对于Kubernetes来说，声明式API最大的难点就在于如何提一个正确的需求了。 所以下面来看看如何给Kubernetes提需求。
API的载体 -- Yaml
用户可以通过kubectl与Kubernetes交互，使用kubectl会通过读取指定的资源定义文件来要求kubernetes创建各种资源，这里的资源文件指的就是"需求文档"，在里面规定了各种资源的"大小"，"规格"。 为了用户可以方便理解里面的内容(实际使用过程中，感觉使用yaml其实并不方便。尤其是当数据层次多的时候，经常出现空白符不匹配导致解析失败的问题)，资源文件使用了yaml格式(yaml对用户友好，kubectl提交需求时，会将yaml转换成json格式，所以Kubernetes其实最终读取的是json格式的需求文档).
我经常在编辑完之后，通过 https://codebeautify.org/yaml-validator 来验证格式是否正确。
编辑Yaml过程中，有如下几个注意事项:
- 通过空格控制缩进，不支持Tab
- 如果参数是以空格开始，则需要单引号将其包含起来， 如果参数中包括单引号，则需要进行转义操作
- 冒号后一定要有空格
- 使用一个短横+一个空格表示列表，同样的缩进层级表示属于同一个列表
- 空值使用null或者~表示。
API文档总览
Kubernetes的API文档在 https://kubernetes.io/docs/reference/ 点击版本号，就可以看到相对应的API文档说明。
Kubernetes API大致分为以下几类(个人起的名称，未必准确)：
- 计算类
- 负载类
- 配置类
- 管理类
计算类对应是Workload，主要是Pod，Job，Deployment，ReplicaSet之类涉及到CPU计算的各种资源。 负载类指的是LB类资源，配置类指的是ConfigMap之类涉及到外部资源的数据资源， 而管理类指的是对集群的管理，例如创建命名空间，节点隔离等
对Kubernetes的资源操作，绝大多数就是对上面四类资源的操作。
一个标准的Kubernetes 资源文件，其结构大致是下面的样子:
apiVersion:
kind:
metadata:
spec:
status:apiVersion表示API版本，服务端会通过读取这个版本号，来进行内容验证。 这个版本号可以通过API文档获取，例如要编写一个Deployment资源，首先查看API文档(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#daemonset-v1-apps)如下：
版本号由Group/Version这样的格式组成，因此Deployment的apiVersion就是apps/v1。 需要注意下面一行小字: "Other API versions of this object exist: v1beta2 v1beta1 v1beta1"，因此apps/v1beta2， apps/v1beta1这样的版本号也是合法的。 具体使用哪个版本号，最终要取决于集群支持哪个版本号。
kind表示操作的是什么资源， 向上面要操作Deployment，kind就是Deployment。 如果要创建Pod，则Kind就是Pod。
metadata则是此资源的一些元数据， 如何设置后面会聊到
spec是具体如何创建这个资源，同样放到后面再聊
status是此资源状态数据，用户不需要设置，即便设置，集群也会过滤掉
总结一下:
用户通过apiversion+kind告之集群，准备按照哪个API版本所规定的协议创建何种资源。 集群确认支持指定版本和资源后，就会读取后面的资源详细参数。 但需要注意，未必所有资源都有这几项，例如Configmap就没有Spec,但却增加了data. 后面会聊到如何通过API文档来组织资源文件
创建资源
来看metadata。每种资源有不同的metadata规范， 大部分场景中可以通用的，也就是说虽然资源不同，但metadata格式相同，只是里面的参数不同。 当需要查看具体metadata时，直接点击metadata下面的ObjectMeta,如下图：
会跳到ObjectMeata定义页面中：
这里仍然假设需要创建一个Deployment，apiVersion和kind此时都已经确定了(如果仍然不明白，建议再看一下上面一节)。 然后开始写metedata. 通过ObjectMeta可以看到里面有很多属性，例如annotations表示一些注释信息，类型是obejct，通过后面的链接: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ 可以得知是一个key=value格式的map。 如果要添加注释信息，可以按照如下方式编写:
apiVersion: apps/v1beta2
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"在创建任何资源时，name和namesapce都是需要指定的(namespace如果不指定，默认是default，但指定namespace是一个好习惯)。查看name和namespace的定义:
都是字符串格式，因此在上面基础之上在添加name和namespace：
apiVersion: apps/v1beta2
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
name: envoy-01
namespace: tio在某些场景中(其实是大多数场景)，需要通过label来筛选对应的workload，所以有必要给我的Deployment添加特定的Label， 查看一下Label的定义:
查看后面的链接 (https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) 可以看出也是一个key=value格式的map，和annotations一样，所以添加label如下：
apiVersion: apps/v1beta2
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
labels:
k8s-app: envoy-01
name: envoy-01
namespace: tiometadata的定义就先看到这里，下面来看spec应该如何定义。
同样，直接点击deploymentspec下面的类型定义，
每个资源的spec都不同，下面是DeploymentSpec的定义:
每个属性都有解释，这里就不逐一翻译了， 我们假设这个Deployment预期两个Pod，因此replicas=2，通过selector来匹配ReplicaSet，设定strategy为滚动更新。 在上面资源文件的基础之上，我们继续定义spec，如下：
apiVersion: apps/v1beta2
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
labels:
k8s-app: envoy-01
name: envoy-01
namespace: tio
spec:
replicas: 1
selector:
matchLabels:
k8s-app: envoy-01
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdateselector可以参考(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#labelselector-v1-meta)规定的规范， strategy可以参看(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/#deploymentstrategy-v1-apps)。
这些定义完成后，就剩下Template了，这个用来定义应该如何来创建Pod(或者说表示用户想要一个什么样的Pod)。
点击下面的Pod数据定义:
可以看到Pod Template有两个属性:
因此资源文件大致应该是如下的样子:
apiVersion: apps/v1beta2
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
labels:
k8s-app: envoy-01
name: envoy-01
namespace: tio
spec:
replicas: 1
selector:
matchLabels:
k8s-app: envoy-01
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
spec:metadata和spec. 其中metadata和上面我们所设置的metadata一样，这里就不赘述了。spec通过下面的定义可以得知是podspec。
点击podspec后可以看到和经常设置的docker container参数有一些类似了：
我们继续在上面资源文件基础上补充podspec的内容
apiVersion: apps/v1beta2
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
labels:
k8s-app: envoy-01
name: envoy-01
namespace: tio
spec:
replicas: 1
selector:
matchLabels:
k8s-app: envoy-01
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
labels:
k8s-app: envoy-01
spec:
containers:
- args:
- -c
- /etc/envoy/envoy.yaml
- --service-node
- sn1
- --service-cluster
- sc1
command:
- envoy
image: envoyproxy/envoy
imagePullPolicy: IfNotPresent
name: envoy
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 250m
memory: 256Mi
securityContext:
privileged: false
procMount: Default
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /etc/envoy
name: conf至此，一个最简单的Deployment资源文件就写好了。 剩下的就是通过kubectl提交这个需求给Kubernetes集群，然后就可以等待Kubernetes慢慢创建资源了。