YAML语言似乎已经成为了事实标准的“云配置”语言,无论是容器事实标准docker(主要是docker-compose使用)、SDN,还是容器编排王者kubernetes,又或是虚拟机时代的王者openstack采用的配置文件都是yaml文件格式。不过需要承认的是我个人最初刚接触yaml时还不是很适应(个人更适应json),在后续运维kubernetes时,每每都要去参考k8s doc中的各种k8s对象的模板才能把yaml文件写“正确”。本文是一篇译文,这篇文章很好地讲解了yaml语言的语法格式,并用kubernetes deployment配置来作为示例。至少我看完这篇文章后是受益多多,因此这里将该文章快速翻译出来,供广大的k8s爱好者、实践者参考。
在之前的文章中,我们一直在讨论如何使用Kubernetes来启动和操作资源实例。到目前为止,我们一直都专注于命令行操作。但其实有一种更简单,更有用的方法:使用YAML创建配置文件。在本文中,我们将了解YAML的工作原理,并使用它来先定义一个Kubernetes Pod,然后再定义一个Kubernetes Deployment。
YAML基础
如果您正在做与一些软件领域相关的事情 - 尤其是涉及Kubernetes,SDN和OpenStack等领域,那么你将很难“摆脱”YAML 。YAML是一种人类可读的、专门用于配置信息的文本格式,例如,在本文中,我们将使用YAML定义创建第一个Pod,然后是Deployment。YAML可以理解为Yet Another Markup Language的缩写,也可以理解为"YAML Ain’t Markup Language"的缩写,这取决于你问的是谁。
使用YAML进行K8s定义会带来许多优势,包括:
方便:您不再需要将所有参数都添加到命令行中
可维护: YAML文件可以添加到源代码版本控制仓库中,因此你可以跟踪文件的修改
灵活性:通过YAML,您能够创建比在命令行上更为复杂的结构
YAML是JSON的超集,这意味着任何有效的JSON文件也是有效的YAML文件。所以一方面,如果你知道JSON并且你只想写自己的YAML(而不是阅读其他人的那些),那么你就完全可以开始了。另一方面,不幸的是,这不太可能。即使你只是想在网上找些例子,他们更有可能是YAML格式(非JSON),所以我们不妨来习惯这种格式。尽管如此,在某些情况下JSON格式可能更为方便,因此最好知道JSON仍然可供您使用。
幸运的是,在YAML中你只需要了解两种类型的结构:
Lists(列表)
Maps
没错!你可能会用maps of lists和lists of maps,等等,但是一旦你掌握了这两个结构,那么你就可以开始了。这并不是说你不能做更复杂的事情,但总的来说,这就是你开始时需要的全部内容了。
YAML Maps
让我们先来看看YAML maps。maps允许您关联键值对(name-value pairs),在尝试设置配置信息时,这非常方便。例如,您可能有一个如下所示的配置文件:
---
apiVersion: v1
kind: Pod
第一行是分隔符,除非您尝试在单个文件中定义多个结构,否则它是可选的。在那之后,如您所见,我们有两个值:v1 和Pod ,映射到两个键:apiVersion 和kind 。
当然,这种事情非常简单,它等价于下面的JSON内容:
{
"apiVersion": "v1",
"kind": "Pod"
}
请注意,在我们的YAML版本中,引号是可选的; 处理程序可以告诉您正在查看基于这种格式的一个字符串。
您还可以通过创建一个映射到另一个map而不是字符串的键来指定更为复杂的结构,如下所示:
---
apiVersion: v1
kind: Pod
metadata:
name: rss-site
labels:
app: web
在这种情况下,我们有一个键: metadata,其值为一个带有2个键:name和labels的map。该labels键本身有一个map作为其值。您可以根据需要嵌套这些。
YAML处理程序之所以知道所有这些部分是如何相互关联的,是因为我们做了行缩进。在这个例子中,我使用了2个空格以便于阅读,但空格的数量并不重要 - 只要它至少为1,并且只要你的缩进是一致的。例如,name和labels处于相同的缩进级别,因此处理程序知道它们都是同一个map的一部分; 它知道app 是labels的值,因为它进一步缩进了。
**注意:永远不要在YAML文件中使用tab **
因此,如果我们将其转换为JSON,它将是如下所示这样的:
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "rss-site",
"labels": {
"app": "web"
}
}
}