在深入探讨如何在Kubernetes中搭建应用程序的细节之前,有必要论述一下该如何管理配置本身。Kubernetes中的一切都以声明的方式呈现,这意味着你只需要为集群中的应用程序配置好期望的状态(通常配置在YAML或JSON文件中),这些声明的期望状态将会定义好应用程序的所有部分。声明式(declarative)的方式显然比命令式(imperative)更为可取。在命令式方式中,集群的状态是对集群进行一系列变更后产生的结果。如果采用命令式的方式配置集群,那么理解集群是如何达到当前状态以及复现此过程将会变得非常困难。这也使得理解应用程序故障为何发生或恢复应用程序变得非常具有挑战性。
Kubernetes同时支持YAML和JSON两种格式来声明应用程序的状态。人们通常更喜欢YAML,这是因为YAML比JSON更为简洁和易于编辑。然而值得注意的是YAML对缩进敏感,Kubernetes中的配置错误常常是由于YAML中的缩进错误造成的。如果情况不符合预期,最好首先检查缩进是否正确。
由于应用程序状态事实上来源于这些YAML文件中的状态声明,正确地管理这些状态声明对于应用程序的成功运行来说至关重要。在修改应用程序的期望状态时,你可能希望能够对这些变更进行管理,验证它们是否正确以及审计是谁执行了变更,并在变更失败时能够将其回滚。幸运的是,在软件工程领域,人们已经开发出管理状态声明变更以及审计和回滚所需的工具。这也意味着,与版本控制和代码评审相关的最佳实践同样适用于应用程序状态声明的管理。
如今大多数人将Kubernetes的配置存放在Git中。虽然具体采用什么样的版本控制系统并不重要,但Kubernetes生态系统中的许多工具都期望配置文件被存储在Git中。对于代码评审而言,审查的方式更加多样化,尽管基于GitHub的代码评审备受推崇,但本地代码评审工具或服务同样被人们广泛地使用。无论你采用哪种方式审查你的应用程序配置,都应该将它们视作源代码来对待。
在考虑如何组织应用程序的配置文件时,采用基于文件系统的目录结构来组织各个组件的配置文件是有价值的。通常,团队会将单个应用程序的所有配置文件放在同一个目录下,子组件的配置文件则存在对应的子目录中。
对于示例应用程序中的配置文件,我们按如下方式进行组织:
每个目录中都包含了配置应用程序所需的YAML文件。后续你会发现,随着我们将应用程序部署到多个不同的区域或者集群,该文件布局会变得越来越复杂。