Kubernetes 1.2 新功能解析：ConfigMap (下)

Kubernetes 1.2 版本添加了一个叫 ConfigMap 的新功能。这个功能提供给容器注入应用程序数据的方式。注入配置文件对于大部分应用程序来说很强大，但是新的 ConfigMap 功能不仅可以在容器开启时提供初始配置功能，还有在容器运行时更新自身配置的功能。在这篇帖子里，我将会给大家展示如何编写微服务来利用更新好的配置，并且在 fly 上面重构你的 service。

让我们来看看监控配置文件变化的简单网页 app 是怎么样的。

这个 app 有趣部分是 ConfigManager 和 WatchFile.

ConfigManager 的工作就是提供访问我们的 Config{}的路径结构，这样的话当 Kubernetes ConfigMap 给我们一个新的配置文件版本或者我们更新 Config{} 对象时候，竞争冲突不存在。

WatchFile 的工作就是为作出的修改查看我们的配置文件，并且运行读取配置文件的新版本回调函数，使用 ConfigManager 设置新的 Config{} 。

让我们看一下 ConfigManager 的安装启用。

这里是我们使用一个简单的 Mutex 用来避免竞争冲突的例子。通常你想要避免使用 Mutex，然后使用建立在 channel 里面的 golang。但是既然管理员的工作是保护配置对象的实例，那么使用 Mutex 也还是可以接受的。

怀着好奇心，我创建了一个这个对象的 golang channel 安装启用，然后运行一些基准点。你可以点击找到代码和基准点测试。

Mutex 版本没有死锁的风险，很高效。

而 FileWatcher 的实施会较复杂一点。它的目标是使任意额外的 fsnotify events 成为一个单独更新的 event，这样我们只要执行一次回调函数。查看完整代码请点击这里。

有意思的部分是 run()函数执行在线程中，然后运行回调函数。

你可能会觉得代码应该寻找 fsnotify.Writeevents 而不是 fsnotify.Remove，然而……ConfigMap 所呈现给应用程序的配置文件事实上是一个连接到我们配置文件的符号链接，而不是一个文件。当 ConfigMap 更新时，Kubernetes AtomicWriter()就可以实现强大的 ConfigMap 更新。

为了做到这样，AtomicWriter()创建了一个新的目录；编写更新好的 ConfigMap 内容到新的目录。一旦编写完成，那么它就会移动原始配置文件符号链接，然后用新的指向最新创建目录符号链接替换它。

我们的代码处理方式理论上应该是监控我们的配置文件符号链接，而不是为 events 的真实文件。然而，fsnotify.v1 并不允许我们提交 IN_DONT_FOLLOW 标志到 inotify，inotify 允许我们为修改监控符号链接。但是 fsnotify 取消引用符号链接，然后为 events 监控真实文件。这不太可能作出修改，因为 fsnotify 是为跨平台设计的，而且不是所有的平台都支持符号链接。

我继续使用 fsnotify 函数库，因为对于我来说，用它在 osx 上开发，在容器上部署都比较方便。以 Linux 为中心的实施应该直接使用"golang.org/x/exp/inotify"数据库。

现在我们有了我们的代码，我们可以创建一个 Docker 镜像然后更新到 Docker hub，为部署在我们 Kubernetes 集群做好准备。

假设你已经建立起了一个 Kubernetes 集群；让我们来创建一个 ConfigMap 配置，然后用我们的容器来使用它。

创建 ConfigMap

首先，我们创建一个密钥清单文件

这个定义了一个新的叫做 configmap-microservice-demo 的 ConfigMap，它包括了 data:配置文件名字叫做 configmap-microservice-demo.yaml

它的内容是 message: Hello World。

使用 kubectl 来创建 ConfigMap。

你可以检测到最新的创建好的 ConfigMap

接下来我们来定义一个 Replication Controller 密钥清单来运行我们的应用程序容器。

有趣的地方就是 volumes:和 volumeMounts:，这两者告诉运行在节点上的 kubelet 哪里可以安装我们的配置文件。当我们的容器运行的时候；数据卷插件会在我们的容器中安装一个叫做/etc/config 的目录，然后在这里面替换我们的配置文件 configmap-microservice-demo.yaml。

从我们的容器观点角度看，我们的配置文件完整途径将会是：/etc/config/configmap-microservice-demo.yaml

现在让我们来创建 Replication Controller。

我们现在可以检查我们正在运行的 pods 来寻找我们新 pod 的 IP 地址。

现在如果你登录到我们集群中的一个节点，我们在集群里可以用 pod 的 IP 地址从任何地方来访问应用程序。

如果这个部分让你很困惑，你可以点击这篇博客（http://www.dasblinkenlichten.com/kubernetes-101-networking/），它对于Kubernetes网络是如何运行的有很深层次的指导意义。这个是官方文档（http://kubernetes.io/docs/admin/networking/）。

更新 ConfigMap

现在为了有趣的部分，让我们来更新我们的配置，部署修改到 ConfigMap。

让我们打开原始的 ConfigMap 密钥清单文件，然后修改我们的 message: Hello World 到 message:Hello Grandma。

用我们更新的版本替代目前的 ConfigMap

我们可以验证到，通过在 configmap 资源上执行 get，更新很成功。

我们的应用程序很快得到了更新后的配置，我们可以通过看日志就来验证。

现在我们可以在集群里面 curl 我们的应用程序，我们应该看到更新的配置反应在我们的应用程序里。

本文转载自才云 Caicloud 公众号。

原文链接：https://mp.weixin.qq.com/s/GXia-Lyc7NdfZJTCGU7iQg