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

01

k8s yaml文件中的关键字段

今天我们来看k8s中的yaml文件重点字段。我们先随便看一个yaml文件:

代码语言:javascript
复制
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的版本:

代码语言:javascript
复制
[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文件复制过来):

代码语言:javascript
复制
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等,后续慢慢分析。