1.5　使用ConfigMap配置应用程序

每个应用程序都需要一定的配置。这可能是每页显示的日志条目数量、特定页面的背景颜色、节假日的特殊显示或其他各种配置。通常，将配置信息与应用程序本身分离是一种值得遵循的最佳实践。

应用和配置分离有若干不同的原因。首先，你可能想要在不同的环境中对应用程序进行不同的配置。例如，你可能想要在欧洲推出复活节专题，而在中国展现春节专题。除了环境的特殊性之外，应用与配置的分离也能提高系统的灵活性。通常，一个发布的二进制文件中包含了多个不同的新功能。如果通过代码来启用这些新功能，那么唯一能够修改现有功能的方式是重新构建和发布新的二进制文件，这可能是一个昂贵且缓慢的过程。

使用配置来管理功能开关意味着你可以快速地（甚至动态地）开启或关闭相关的功能，以应对用户需求变化或代码功能缺陷。每个功能都支持独立开关的灵活性，这可以确保你能够持续地发布绝大多数的功能，哪怕某些功能需要回滚以解决性能或正确性问题。

Kubernetes使用ConfigMap来描述这样的配置。ConfigMap中包含多个用于描述配置信息或文件的键值对。这些配置可以通过文件或环境变量的方式注入Pod的容器中。如果想要配置上述示例中每页显示的日志条目数量，你可以定义一个如下所示的ConfigMap：

你需要将ConfigMap中的配置信息作为环境变量提供给应用程序。为此，可以在之前Deployment的容器资源部分添加以下内容：

以上配置展示了如何使用ConfigMap来配置应用程序，但在Deployment的实际应用中，你可能想要每周一次甚至更为频繁地进行常规的配置变更。看上去只需要简单地修改ConfigMap就可以让新的配置生效，然而这并不是一个最佳实践。其原因有很多：首先，更改配置实际上并不会触发现有Pod的更新。仅当Pod重启时，新的配置才会生效。因此，这种部署方式不是基于健康检查的，而且充满了临时性和随机性。

更好的实践是在ConfigMap的命名中加入版本号。比如采用 frontend-config-v1 而非 frontend-config 来命名ConfigMap。当你想要进行更改时，只需要创建一个新的 v2 版本，然后更新Deployment资源以使用该版本的ConfigMap，而不是直接更新现有的ConfigMap。这样，Deployment将会自动触发重新部署，执行恰当的健康检查和服务停顿以切换配置。此外，如果需要回滚，由于 v1 的配置仍然保留在集群中，你只需再次更新Deployment即可。 qGAlVInt+sBjrKbvWPioEI5yFdql9/OpW8NjHZ/JMiCdCLaCiTZcvgWKCKfJs8mh