01
k8s yaml文件中的关键字段
今天我们来看k8s中的yaml文件重点字段。我们先随便看一个yaml文件：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
为了有一个比较直观的理解，我们先不去关注很细节的字段，先来看最左侧的四个绿色的字段，分别是apiVersion、kind、metadata、spec
apiVersion
k8s的版本在快速的迭代，所以搞清楚apiVersion这个字段就比较重要，我们可以通过下面的命令来查看apiVersion的版本：
[root@VM-16-13-centos ~]# kubectl api-versions
apps/v1beta1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1beta1
autoscaling/v1
batch/v1
certificates.k8s.io/v1alpha1
extensions/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1alpha1
storage.k8s.io/v1beta1
v1
可以看到类似apps/v1beta1等字样，下面对这些关键字做下解释：
1、包含alpha的，说明在alpha测试阶段，该版本可能有错误，而且随时可能丢弃。通常线上环境我们不会使用这些版本
2、包含beta的，说明软件被测试过了，功能比较安全，默认情况下是开启的，该功能在后续版本不会被删除。
3、只有一个v1的，说明它是k8s api的稳定版本，包含了很多的核心镜像。
4、包含v1和beta1的，说明本身v1这个版本是稳定的，后来进行了beta测试操作，但是依旧是稳定的。
在k8s刚出来的时候，很多控制器包含在extensions/v1beta1中，随后被迁移到在apps/v1beta1中。
在k8s 1.8版本之后，出现了v1beta2版本，它是完全兼容v1beta1的，它将部分控制器迁入了apps/v1beta2中。
k8s 1.9版本出来以后，引入了apps/v1,因此，部分控制器资源又被从extensions/v1beta1、apps/v1beta1、apps/v1beta2迁移到了apps/v1中，原来的v1beta1被废弃。
5、包含batch/v1的，代表job相关的api组合，一般在老版本中常见。
k8s 1.8版本中，新增了batch/v1beta1组合，cronjob迁移到了这个版本，后续又被迁移到了batch/v1
这里我们只需要知道包含batch的，跟cronjob相关即可。
通过上面的描述，其实不难看出，这个apiVersion的版本和k8s的版本有着密切的联系，一般情况下，我们线上不会使用带alpha的版本，当你需要输入版本的时候，最好查看下当前版本下，你的控制对象保存在哪个apiVersion中。
kind
这个字段表示的是api对象的类型，它可以是pod、Daemonset、Service、Deployment等等，这里不再一一展开，因为每个类型都包含很多知识点，后续用到的时候，再来分享。
这里我们需要了解的是，如果你要创建一个Pod，这个字段的值就应该写Pod。
例子中，kind的类型是deployment，它是一个定义多副本应用的对象，后面我们会说。
metadata
这个字段是api对象的标识，也就是元数据，它是我们从k8s中找到这个对象的主要依据。
spec
这个字段存放的是当前这个对象独有的定义，用来描述它想要表达的功能。
02
其他字段
一个完整的yaml文件，其实就是一个api对象，我们把这个yaml文件交给k8s之后，k8s会根据这个对象的描述，来为我们创建这些对象所定义的容器。
一个k8s对象的定义，大体上可以分为metadata和spec这2个部分，其中，metadata存放的这个对象的元数据，不同的api对象，这部分的字段和格式基本上是一样的；而spec部分，才是区分对象的关键部分。
在上面的4个字段之外，还有一些隶属于spec下面的字段，这里我们也简单介绍下（为方便观看，我把这个yaml文件复制过来）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
首先，我们的kind类型是一个deployment，它是一个控制器，用来控制同时运行pod应用的个数。
spec.replicas这个字段表示它将控制集群中始终保持有2个pod对象，那么这2个Pod对象有什么特征呢？就要用到template模板了。
spec.template
它代表一个模板，这个模板描述了我们要创建的Pod对象细节，这些Pod里面有1个容器，容器镜像是nginx:1.7.9,端口是80
spec.selector.matchlabels
这3个字段，共同构成了一个label selector，也就是标签选择器，这里我们可以看到matchlabels字段后面跟的值是app：nginx。这是一个k-v结构，带有这个k-v结构的Pod对象，将会被这个Deployment管理
这个例子中的部分字段介绍就到这里，当然，这还远远不足够让我们揭开yaml文件的神秘面纱。后续将会继续描述其他字段。
这里，要说另外一点，像这种deployment对象控制Pod对象的方式，在k8s中，我们称之为"控制器"，常见的控制器有很多，例如deployment、statefulset等，后续慢慢分析。
