yaml文件详解
一、yaml文件简介
Kubernetes只支持YAML和JSON格式创建资源对象,JSON格式用于接口之间消息的传递,适用于开发;YAML格式用于配置和管理,适用于云平台管理,YAML是一种简洁的非标记性语言。
1)yaml的语法规则:
- 大小写敏感
- 使用缩进表示层级关系
- 缩进时不允许使用Tal键,只允许使用空格
- 缩进的空格数目不重要,只要相同层级的元素左侧对齐即可
- ”#” 表示注释,从这个字符一直到行尾,都会被解析器忽略
- 注:- - - 为可选的分隔符 ,当需要在一个文件中定义多个结构的时候需要使用
2)在Kubernetes中,只需要知道两种结构类型即可:
- Lists
- Maps
2.1)YAML Maps Map顾名思义指的是字典,即一个Key:Value 的键值对信息。例如:
1 | apiVersion: v1 |
上述内容表示有两个键apiVersion和kind,分别对应的值为v1和Pod。
Maps的value既能够对应字符串也能够对应一个Maps。例如:
1 | apiVersion: v1 |
注:上述的YAML文件中,metadata这个KEY对应的值为一个Maps,而嵌套的labels这个KEY的值又是一个Map。实际使用中可视情况进行多层嵌套。
YAML处理器根据行缩进来知道内容之间的关联。上述例子中,使用两个空格作为缩进,但空格的数据量并不重要,只是至少要求一个空格并且所有缩进保持一致的空格数 。例如,name和labels是相同缩进级别,因此YAML处理器知道他们属于同一map;它知道app是lables的值因为app的缩进更大。
2.2)YAML Lists List即列表,说白了就是数组,例如:
1 | args |
可以指定任何数量的项在列表中,每个项的定义以破折号(-)开头,并且与父元素之间存在缩进。
当然Lists的子项也可以是Maps,Maps的子项也可以是List,例如:
1 | apiVersion: v1 |
如上述文件所示,定义一个containers的List对象,每个子项都由name、image、ports组成,每个ports都有一个KEY为containerPort的Map组成。
二、yaml常见语法
1)apiVersion
查看当前所有可用的API版本
1 | $ kubectl api-versions |
1.6版本之前 apiVsersion:extensions/v1beta1 1.6版本到1.9版本之间:apps/v1beta1 1.9版本之后:apps/v1
常用apiversion
只要记住6个常用的apiversion一般就够用了。
- v1: Kubernetes API的稳定版本,包含很多核心对象:pod、service等。
- apps/v1: 包含一些通用的应用层的api组合,如:Deployments, RollingUpdates, and ReplicaSets。
- batch/v1: 包含与批处理和类似作业的任务相关的对象,如:job、cronjob。
- autoscaling/v1: 允许根据不同的资源使用指标自动调整容器。
- networking.k8s.io/v1: 用于Ingress。
- rbac.authorization.k8s.io/v1:用于RBAC。
2)kind
kind指定这个资源对象的类型,如 pod、deployment、statefulset、job、cronjob
3)metadata
metadata常用的配置项有 name,namespace,即配置其显示的名字与归属的命名空间。
4)spec
一个嵌套字典与列表的配置项,也是主要的配置项,支持的子项非常多,根据资源对象的不同,子项会有不同的配置。
如一个pod的spec配置:
1 | apiVersion: v1 #必选,版本号,例如v1 |
一个service 的 spec 的配置:
1 | apiVersion: v1 |
这里是将nginx映射到外网,访问地址就是本机ip:31111
三、port详解
- port:port是k8s集群内部访问service的端口,即通过clusterIP: port可以访问到某个service
- nodePort:nodePort是外部访问k8s集群中service的端口,通过nodeIP: nodePort可以从外部访问到某个service。
- targetPort:targetPort是pod的端口,从port和nodePort来的流量经过kube-proxy流入到后端pod的targetPort上,最后进入容器。
- containerPort:containerPort是pod内部容器的端口,targetPort映射到containerPort。
四、yaml简单示例
接下来就是看看deployment、pod、service 这三种资源的说明书例子
1)deployment
1 | apiVersion: apps/v1 # 1.9.0 之前的版本使用 apps/v1beta2,可通过命令 kubectl api-versions 查看 |
执行以下命令创建 deployment 资源
1 | $ kubectl create -f nginx.yaml |
2)pod
1 | apiVersion: v1 |
执行以下命令创建 pod 资源
1 | $ kubectl create -f pod-redis.yaml |
3)service
1 | apiVersion: v1 |
执行以下命令创建 service 资源
1 | $ kubectl create -f httpd-svc.yaml |
五、Label与Selector
1)Label
Label是Kubernetes系列中另外一个核心概念。是一组绑定到K8s资源对象上的key/value对。同一个对象的labels属性的key必须唯一。label可以附加到各种资源对象上,如Node,Pod,Service,RC等。
通过给指定的资源对象捆绑一个或多个不用的label来实现多维度的资源分组管理功能,以便于灵活,方便地进行资源分配,调度,配置,部署等管理工作。
示例如下:
- 版本标签:”release” : “stable” , “release” : “canary”…
- 环境标签:”environment” : “dev” , “environment” : “production”
- 架构标签:”tier” : “frontend” , “tier” : “backend” , “tier” : “middleware”
- 分区标签:”partition” : “customerA” , “partition” : “customerB”…
- 质量管控标签:”track” : “daily” , “track” : “weekly”
2)Selector
Label selector是Kubernetes核心的分组机制,通过label selector客户端/用户能够识别一组有共同特征或属性的资源对象。符合这个标签的 Pod 会作为这个 Service 的 backend。
1 | apiVersion: v1 |
六、kubectl create还是 kubectl replace二者区别
kubectl create -f 还是 kubectl replace -f 都可以创建资源,但是有什么区别呢,请细品下面讲解。
kubectl create:
- kubectl create命令可创建新资源。 因此,如果再次运行该命令,则会抛出错误,因为资源名称在名称空间中应该是唯一的。
kubectl apply:
- kubectl apply命令将配置应用于资源。 如果资源不在那里,那么它将被创建。 kubectl apply命令可以多次运行,因为它只是应用如下所示的配置。 在这种情况下,配置没有改变。 所以,pod没有改变。
- 简单来说,如果在单个文件上运行操作以创建资源,则create和apply基本相同。 但是, apply允许您在目录下的多个文件上同时创建和修补。