云原生技术之kubernetes学习笔记(6)---yaml文件关键字段

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等，后续慢慢分析。