YAML文件的使用解析

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 在前⾯的课程中,我们在安装 kubernetes 集群的时候使⽤了⼀些 YAML ⽂件来创建相关的资源,但大家对 YAML ⽂件还是⾮常陌⽣。所以我们先来简单看⼀看 YAML ⽂件是如何⼯作的,并使⽤ YAML ⽂件来定义⼀个 k8s pod,然后再定义⼀个 k8s deployment吧。

0️⃣写在前面

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

1️⃣YAML基础

它的基本语法规则如下:

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

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

  • Lists
  • Maps

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


2️⃣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 ⽂件的语义化程度更⾼吧?


3️⃣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 ⽂件更复杂了呢?


4️⃣使⽤ YAML 创建 Pod

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

API 说明:$\color{#00C5CD}{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
  • image
  • command
  • args
  • workingDir
  • ports
  • env
  • resources
  • volumeMounts
  • livenessProbe
  • readinessProbe
  • livecycle
  • terminationMessagePath
  • imagePullPolicy
  • securityContext
  • stdin
  • stdinOnce
  • tty

明⽩了 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 
$ 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 ⽂档很重要。

可以使⽤$\color{#00C5CD}{http://www.yamllint.com/}$去检验 YAML ⽂件的合法性。

在这里插入图片描述

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
71 2
|
2月前
|
Java
Java“解析时到达文件末尾”解决
在Java编程中,“解析时到达文件末尾”通常指在读取或处理文件时提前遇到了文件结尾,导致程序无法继续读取所需数据。解决方法包括:确保文件路径正确,检查文件是否完整,使用正确的文件读取模式(如文本或二进制),以及确保读取位置正确。合理设置缓冲区大小和循环条件也能避免此类问题。
466 2
|
2月前
|
自然语言处理 数据处理 Python
python操作和解析ppt文件 | python小知识
本文将带你从零开始,了解PPT解析的工具、工作原理以及常用的基本操作,并提供具体的代码示例和必要的说明【10月更文挑战第4天】
457 60
|
29天前
|
消息中间件 存储 Java
RocketMQ文件刷盘机制深度解析与Java模拟实现
【11月更文挑战第22天】在现代分布式系统中,消息队列(Message Queue, MQ)作为一种重要的中间件,扮演着连接不同服务、实现异步通信和消息解耦的关键角色。Apache RocketMQ作为一款高性能的分布式消息中间件,广泛应用于实时数据流处理、日志流处理等场景。为了保证消息的可靠性,RocketMQ引入了一种称为“刷盘”的机制,将消息从内存写入到磁盘中,确保消息持久化。本文将从底层原理、业务场景、概念、功能点等方面深入解析RocketMQ的文件刷盘机制,并使用Java模拟实现类似的功能。
40 3
|
1月前
|
Kubernetes 监控 API
深入解析Kubernetes及其在生产环境中的最佳实践
深入解析Kubernetes及其在生产环境中的最佳实践
46 1
|
1月前
|
存储
文件太大不能拷贝到U盘怎么办?实用解决方案全解析
当我们试图将一个大文件拷贝到U盘时,却突然跳出提示“对于目标文件系统目标文件过大”。这种情况让人感到迷茫,尤其是在急需备份或传输数据的时候。那么,文件太大为什么会无法拷贝到U盘?又该如何解决?本文将详细分析这背后的原因,并提供几个实用的方法,帮助你顺利将文件传输到U盘。
|
1月前
|
运维 Kubernetes Cloud Native
Kubernetes云原生架构深度解析与实践指南####
本文深入探讨了Kubernetes作为领先的云原生应用编排平台,其设计理念、核心组件及高级特性。通过剖析Kubernetes的工作原理,结合具体案例分析,为读者呈现如何在实际项目中高效部署、管理和扩展容器化应用的策略与技巧。文章还涵盖了服务发现、负载均衡、配置管理、自动化伸缩等关键议题,旨在帮助开发者和运维人员掌握利用Kubernetes构建健壮、可伸缩的云原生生态系统的能力。 ####
|
2月前
|
数据安全/隐私保护 流计算 开发者
python知识点100篇系列(18)-解析m3u8文件的下载视频
【10月更文挑战第6天】m3u8是苹果公司推出的一种视频播放标准,采用UTF-8编码,主要用于记录视频的网络地址。HLS(Http Live Streaming)是苹果公司提出的一种基于HTTP的流媒体传输协议,通过m3u8索引文件按序访问ts文件,实现音视频播放。本文介绍了如何通过浏览器找到m3u8文件,解析m3u8文件获取ts文件地址,下载ts文件并解密(如有必要),最后使用ffmpeg合并ts文件为mp4文件。
|
1月前
|
存储 Kubernetes 调度
深度解析Kubernetes中的Pod生命周期管理
深度解析Kubernetes中的Pod生命周期管理
|
2月前
|
存储 Kubernetes 监控
深度解析Kubernetes在微服务架构中的应用与优化
【10月更文挑战第18天】深度解析Kubernetes在微服务架构中的应用与优化
137 0

推荐镜像

更多
下一篇
DataWorks