云原生系列Kubernetes深度解析YAML文件使用

目录写在前面YAML基础MapsLists使⽤ YAML 创建 Pod创建 Pod创建 Deployment

写在前面

在前⾯的课程中，我们在安装 kubernetes 集群的时候使⽤了⼀些 YAML ⽂件来创建相关的资源，但大家对 YAML ⽂件还是⾮常陌⽣。所以我们先来简单看⼀看 YAML ⽂件是如何⼯作的，并使⽤ YAML ⽂件来定义⼀个 k8s pod，然后再定义⼀个 k8s deployment吧。

YAML基础

它的基本语法规则如下：

⼤⼩写敏感使⽤缩进表示层级关系缩进时不允许使⽤Tab键，只允许使⽤空格。缩进的空格数⽬不重要，只要相同层级的元素左侧对⻬即可#表示注释，从这个字符⼀直到⾏尾，都会被解析器忽略。

在我们的 kubernetes 中，你只需要两种结构类型就⾏了：

ListsMaps

也就是说，你可能会遇到 Lists 的 Maps 和 Maps 的 Lists，等等。不过不⽤担⼼，你只要掌握了这两 种结构也就可以了，其他更加复杂的我们暂不讨论。

Maps

⾸先我们来看看 Maps，我们都知道 Map 是字典，就是⼀个 key:value 的键值对，Maps 可以让我们 更加⽅便的去书写配置信息，例如：

— apiVersion: v1 kind: Pod

第⼀⾏的 – – – 是分隔符，是可选的，在单⼀⽂件中，可⽤连续三个连字号 — 区分多个⽂件。这⾥我 们可以看到，我们有两个键： kind 和 apiVersion ，他们对应的值分别是：v1 和Pod。上⾯的 YAML ⽂件转换成 JSON 格式的话，你肯定就容易明⽩了：

{ “apiVersion”: “v1”, “kind”: “pod” }

我们在创建⼀个相对复杂⼀点的 YAML ⽂件，创建⼀个 KEY 对应的值不是字符串⽽是⼀个 Maps：

— apiVersion: v1 kind: Pod metadata: name: kube100-site labels: app: web

上⾯的 YAML ⽂件，metadata 这个 KEY 对应的值就是⼀个 Maps 了，⽽且嵌套的 labels 这个 KEY 的值⼜是⼀个 Map，你可以根据你⾃⼰的情况进⾏多层嵌套。

上⾯我们也提到了 YAML ⽂件的语法规则，YAML 处理器是根据⾏缩进来知道内容之间的嗯关联性 的。⽐如我们上⾯的 YAML ⽂件，我⽤了两个空格作为缩进，空格的数量并不重要，但是你得保持⼀ 致，并且⾄少要求⼀个空格（什么意思？就是你别⼀会缩进两个空格，⼀会缩进4个空格）。

我们可以看到 name 和 labels 是相同级别的缩进，所以 YAML 处理器就知道了他们属于同⼀个 MAP，⽽ app 是 labels 的值是因为 app 的缩进更⼤。

注意：在 YAML ⽂件中绝对不要使⽤ tab 键。

同样的，我们可以将上⾯的 YAML ⽂件转换成 JSON ⽂件：

{ “apiVersion”: “v1”, “kind”: “Pod”, “metadata”: { “name”: “kube100-site”, “labels”: { “app”: “web” } } }

或许你对上⾯的 JSON ⽂件更熟悉，但是你不得不承认 YAML ⽂件的语义化程度更⾼吧？

Lists

Lists 就是列表，说⽩了就是数组，在 YAML ⽂件中我们可以这样定义：

args – Cat – Dog – Fish

你可以有任何数量的项在列表中，每个项的定义以破折号（-）开头的，与⽗元素直接可以缩进⼀个空 格。对应的 JSON 格式如下：

{ “args”: [ Cat, Dog, Fish ] }

当然，list 的⼦项也可以是 Maps，Maps 的⼦项也可以是list如下所示：

— apiVersion: v1 kind: Pod metadata: name: kube100-site labels: app: web spec: containers: – name: front-end image: nginx ports: – containerPort: 80 – name: flaskapp-demo image: jcdemo/flaskapp ports: – containerPort: 5000

⽐如这个 YAML ⽂件，我们定义了⼀个叫 containers 的 List 对象，每个⼦项都由 name、image、 ports 组成，每个 ports 都有⼀个 key 为 containerPort 的 Map 组成，同样的，我们可以转成如下 JSON 格式⽂件：

{ “apiVersion”: “v1”, “kind”: “Pod”, “metadata”: { “name”: “kube100-site”, “labels”: { “app”: web” } }, “spec”: { “containers”: [{ “name”: “front-end”, “image”: “nginx”, “ports”: [{ “containerPort”: “80” }] }, { “name”: “flaskapp-demo”, “image”: “jcdemo/flaskapp”, “ports”: [{ “containerPort”: “5000” }] }] } }

是不是觉得⽤ JSON 格式的话⽂件明显⽐ YAML ⽂件更复杂了呢?

使⽤ YAML 创建 Pod

现在我们已经对 YAML ⽂件有了⼤概的了解了，我相信你应该没有之前那么懵逼了吧？我们还是来使⽤ YAML ⽂件来创建⼀个 Deployment 吧。

API 说明：https://kubernetes.io/docs/reference/generated/kubernetes−api/v1.10/color{#00C5CD}{https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/ }https://kubernetes.io/docs/reference/generated/kubernetes−api/v1.10/

创建 Pod

— apiVersion: v1 kind: Pod metadata: name: kube100-site labels: app: web spec: containers: – name: front-end image: nginx ports: – containerPort: 80 – name: flaskapp-demo image: jcdemo/flaskapp ports: – containerPort: 5000

这是我们上⾯定义的⼀个普通的 POD ⽂件，我们先来简单分析下⽂件内容：

apiVersion，这⾥它的值是 v1，这个版本号需要根据我们安装的 kubernetes 版本和资源类型进⾏ 变化的，记住不是写死的kind，这⾥我们创建的是⼀个 Pod，当然根据你的实际情况，这⾥资源类型可以是 Deployment、 Job、Ingress、Service 等待。metadata：包含了我们定义的 Pod 的⼀些 meta 信息，⽐如名称、namespace、标签等等信息。spec：包括⼀些 containers，storage，volumes，或者其他 Kubernetes 需要知道的参数，以及诸 如是否在容器失败时重新启动容器的属性。你可以在特定 Kubernetes API 找到完整的 Kubernetes Pod 的属性。

让我们来看⼀个典型的容器的定义：

…spec: containers: – name: front-end image: nginx ports: – containerPort: 80 …

在这个例⼦中，这是⼀个简单的最⼩定义：⼀个名字（front-end），基于 nginx 的镜像，以及容器将会监听的⼀个端⼝（80）。在这些当中，只有名字是⾮常需要的，你也可以指定⼀个更加复杂的属性，例如在容器启动时运⾏的命令，应使⽤的参数，⼯作⽬录，或每次实例化时是否拉取映像的新副本。以下是⼀些容器可选的设置属性：

name

imagecommandargsworkingDirportsenvresourcesvolumeMountslivenessProbereadinessProbelivecycleterminationMessagePathimagePullPolicysecurityContextstdinstdinOncetty

明⽩了 POD 的定义后，我们将上⾯创建 POD 的 YAML ⽂件保存成 pod.yaml，然后使⽤ kubectl 创建 POD：

$ kubectl create -f pod.yaml pod “kube100-site” created

然后我们就可以使⽤我们前⾯⽐较熟悉的 kubectl 命令来查看 POD 的状态了：

$ kubectl get pods NAME READY STATUS RESTARTS AGE kube100-site 2/2 Running 0 1m

到这⾥我们的 POD 就创建成功了，如果你在创建过程中有任何问题，我们同样可以使⽤前⾯的 kubectl describe 进⾏排查。我们先删除上⾯创建的POD：

$ kubectl delete -f pod.yaml pod “kube100-site” deleted

创建 Deployment

现在我们可以来创建⼀个真正的 Deployment。在上⾯的例⼦中，我们只是单纯的创建了⼀个 POD 实 例，但是如果这个 POD 出现了故障的话，我们的服务也就挂掉了，所以 k8s 提供了⼀ 个 Deployment 的概念，可以让 kubernetes 去管理⼀组 POD 的副本，也就是副本集，这样就可以保 证⼀定数量的副本⼀直可⽤的，不会因为⼀个 POD 挂掉导致整个服务挂掉。我们可以这样定义⼀个 Deployment：

— apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kube100-site spec: replicas: 2

注意这⾥ apiVersion 对应的值是 extensions/v1beta1 ，当然 kind 要指定为 Deployment，因为这 就是我们需要的，然后我们可以指定⼀些 meta 信息，⽐如名字，或者标签之类的。最后，最重要的 是 spec 配置选项，这⾥我们定义需要两个副本，当然还有很多可以设置的属性，⽐如⼀个 Pod 在没 有任何错误变成准备的情况下必须达到的最⼩秒数。 我们可以在Kubernetes v1beta1 API参考中找到 ⼀个完整的 Depolyment 可指定的参数列表。 现在我们来定义⼀个完整的 Deployment 的 YAML ⽂件：

— apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kube100-site spec: replicas: 2 template: metadata: labels: app: web spec: containers: – name: front-end image: nginx ports: – containerPort: 80 – name: flaskapp-demo image: jcdemo/flaskapp ports: – containerPort: 5000

看起来是不是和我们上⾯的 pod.yaml 很类似啊，注意其中的 template，其实就是对 POD 对象的定义。将上⾯的 YAML ⽂件保存为 deployment.yaml，然后创建 Deployment：

$ kubectl create -f deployment.yaml deployment “kube100-site” created “`同样的，想要查看它的状态，我们可以检查 Deployment的列表： “`go $ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE kube100-site 2 2 2 2 2m

我们可以看到所有的 Pods 都已经正常运⾏了。 到这⾥我们就完成了使⽤ YAML ⽂件创建 Kubernetes Deployment 的过程，在了解了 YAML ⽂件的基础后，定义 YAML ⽂件其实已经很简单了，最主要的是要根据实际情况去定义 YAML ⽂件，所以查阅 Kubernetes ⽂档很重要。

可以使⽤http://www.yamllint.com/去检验 YAML ⽂件的合法性

以上就是云原生系列Kubernetes深度解析YAML文件使用的详细内容，更多关于Kubernetes解析YAML文件的资料请关注其它相关文章！