Kubernetes 1.2 新功能介绍：ConfigMap

什么是ConfigMap？

ConfigMap API用于存储已经在kubernetes中部署的配置数据，它主要聚焦：

• 为已经部署的应用提供动态的、分布式的配置管理
• 封装配置管理信息，简化kubernetes的部署管理
• 为kubernetes创建一个灵活的配置管理模型

设计ConfigMap的动机

ConfigMap的设计目标：

• 描述一个ConfigMap资源
• 描述ConfigMap作为环境变量的语义
• 描述ConfigMap作为数据卷文件

ConfigMap基本原理

容器的配置管理——把应用的代码和配置区分开，是被推荐的做法。我们希望能够让应用的开发者在Kubernetes里充分使用这样的模式。ConfigMap的API概念上来说很简单，从数据角度来看，ConfigMap的类型只是键值组。应用可以从不同角度来配置，所以关于给用户如何存储和使用配置数据，我们需要给他们一些弹性。在一个pod里面使用ConfigMap大致有三种方式：

（1）     命令行参数

（2）     环境变量

（3）     数据卷文件

这些不同的方法就需要有不同的数据建模方式来使用数据。为了尽可能提供多的弹性，我们使用ConfigMap来承载既有粗力度也有细粒度的数据。另外，由于应用会从环境变量和包含配置数据的文件读取配置信息，我们建立ConfigMap来支持这两者任何一种的读取方式。

一个简单的ConfigMap

我们先写个最简单的ConfigMap：

上面一个简单的ConfigMap，展示了如何存储一个键值对，接下来我们看一个更复杂的例子：

data的数据域中以键值对的形式定义了配置信息，从这些信息可以看出，ConfigMap既可以定义细粒度的配置信息（etc. example.property.1），也可定义粗粒度的信息（etc. example.property.file）。到目前为止，我们还不能清晰的知道ConfigMap如何的使用，接下来我们创建一个ConfigMap作为示例。

创建ConfigMaps

我们使用kubectl create configmap命令来创建ConfigMap，我们将演示不同的创建方式：从文本，从文件，或者从目录。

从目录创建ConfigMap

下面的例子中，game和ui的配置以键值对的形式分别写在两个文本文件中：

通过kubectl create configmap命令来创建该目录下的ConfigMap：

当使用—from-file选项指定ConfigMap的目录时，kubernetes会扫描目录下的所有文件，并将文件名作为键值对的key值，文件内容作为value值。

接下来我们查看我们的ConfigMap的更多细节：

我们使用kubectl describe命令来展示ConfigMap的更多细节，还可以使用如下方式：

删除ConfigMap：

从文件创建ConfigMap

从文本创建ConfigMap

使用–from-literal选项来指定一个key=value键值对来创建ConfigMap：

使用ConfigMap

我们将使用三个例子来介绍ConfigMap的不同的使用方式和场景。

场景1：ConfigMap以环境变量的形式使用

我们在Pod中使用这个ConfigMap：

创建这个Pod后，执行结果会包含如下两行：

SPECIAL_LEVEL_KEY=very

SPECIAL_TYPE_KEY=charm

场景2：ConfigMap作为命令行参数

我们仍然用刚才的ConfigMap作为例子：

为了将一个数值注入控制台命令行，我们必须使用像上面例子中的环境变量的方式，我们使用$(VAR_NAME)来在容器中的命令中引用这个配置：

执行的结果将是如下：

very charm

场景3：通过数据卷插件来使用ConfigMap

ConfigMap也可以在数据卷里面被使用。再次回到我们的ConfigMap的例子

在数据卷里面使用这个ConfigMap，我们有不同的选项。最基本的就是将文件填入数据卷，这个文件中，键就是文件名，键值就是文件内容：

当这个pod运行的时候，输出是这样的：

very

我们也可以在ConfigMap值被映射的数据卷里控制路径:

它运行后，将输出：

very

真实案例：配置Redis

让我们来看一下真实的案例：用Configmap配置redis。我们想要将redis作为一个缓存用推荐配置来输入redis。Redis 配置应该包括：

maxmemory 2mb
maxmemory-policy allkeys-lru

官方的例子存在与docs/user-guide/configmap/redis目录下，我们可以通过它来创建ConfigMap：

现在，让我们用这个配置来创建一个pod：

注意，这个pod有一个ConfigMap数据卷，它在一个叫redis.conf的文件里替代了 example-redis-config  ConfigMap的 redis-config密钥。这个数据卷增长到redis容器的 /redis-master目录里，在/redis-master/redis.conf里替代了我们的配置文件，/redis-master/redis.conf就是是image为master查找的redis配置文件。

如果我们kubectl exec到这个pod，并且运行redis-cli工具，我们可以检查到我们的配置被正确运用：

限制条件

ConfigMaps必须在pod中被使用之前创建。Controllers可以会被写来容忍某些配置文件数据的缺失。

Configmaps属于namespace。他们只有在相同的namespaces中通过pods被引用。

ConfigMap大小的配额是已经一个设置好的功能。

Kubelet只支持从API服务器的pods使用ConfigMap。这包括了任意的用Kubectl创建的pods，或者间接的通过replication controller创建的pods。它不包括通过Kubelet的 –manifest-url标志创建的pods，也不包括从它的REST API创建的pods（一般不用这些方法创建pods）。

推荐阅读：

Kubernetes 1.2 新功能介绍：Ingress 原理及实例

Kubernetes 1.2 新功能介绍：Deployment

Kubernetes 1.2 新功能介绍：Limit Range和Resource Quota

Kubernetes 1.2 新功能介绍：自动扩容算法