您现在的位置是：首页 > 文章详情

kubernetes 中的 ConfigMap 和 Secret

日期：2018-12-13点击：319收藏

为什么要有这俩玩意儿？

我们在kubernetes上部署应用的时候，经常会需要传一些配置给我们的应用，比如数据库地址啊，用户名密码啊之类的。我们要做到这个，有好多种方案，比如：

我们可以直接在打包镜像的时候写在应用配置文件里面，但是这种方式的坏处显而易见而且非常明显。
我们可以在配置文件里面通过env环境变量传入，但是这样的话我们要修改env就必须去修改yaml文件，而且需要重启所有的container才行。
我们可以在应用启动的时候去数据库或者某个特定的地方拿，没问题！但是第一，实现起来麻烦；第二，如果配置的地方变了怎么办？

当然还有别的方案，但是各种方案都有各自的问题。

而且，还有一个问题就是，如果说我的一个配置，是要多个应用一起使用的，以上除了第三种方案，都没办法进行配置的共享，就是说我如果要改配置的话，那得一个一个手动改。假如我们有100个应用，就得改100份配置，以此类推……

kubernetes对这个问题提供了一个很好的解决方案，就是用ConfigMap和Secret。

创建ConfigMap

ConfigMap让我们能够从容器镜像中把配置的详细信息给解耦出来。通过ConfigMap我们能够把配置以key-value对的形式传递到container或者别的系统组件（比如Controller）里面。我们可以通过两种方式来创建ConfigMap：

From Literal Values

我们可以用kubectl create来创建一个ConfigMap，然后通过kubectl get来获取：

# Create the ConfigMap $ kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2 configmap "my-config" created # Get the ConfigMap Details for my-config $ kubectl get configmaps my-config -o yaml apiVersion: v1 data: key1: value1 key2: value2 kind: ConfigMap metadata: creationTimestamp: 2017-05-31T07:21:55Z name: my-config namespace: default resourceVersion: "241345" selfLink: /api/v1/namespaces/default/configmaps/my-config uid: d35f0a3d-45d1-11e7-9e62-080027a46057

-o yaml的作用是通过yaml的形式来返回我们所要求的配置信息。

From Configuration File

除了上面的方式，我们还可以直接通过配置文件来创建（好吧，虽然我感觉是同一种，只不过是放到文件里面了而已……），首先，我们得有一个配置文件，假设名字叫做myconfigmap.yaml：

apiVersion: v1 kind: ConfigMap metadata: name: customer1 data: TEXT1: Customer1_Company TEXT2: Welcomes You COMPANY: Customer1 Company Technology Pct. Ltd.

然后，我们可以通过kubectl create -f来创建：

$ kubectl create -f myconfigmap.yaml configmap "customer1" created

使用ConfigMap

我们可以有两种方法来使用ConfigMap：

通过env

我们可以设置env从ConfigMap读取：

.... containers: - name: rsvp-app image: teamcloudyuga/rsvpapp env: - name: MONGODB_HOST value: mongodb - name: TEXT1 valueFrom: configMapKeyRef: name: customer1 key: TEXT1 - name: TEXT2 valueFrom: configMapKeyRef: name: customer1 key: TEXT2 - name: COMPANY valueFrom: configMapKeyRef: name: customer1 key: COMPANY ....

这样，我们的container就可以读取到ConfigMap里面存储的信息了。

不过一般情况下，我个人推荐使用另一种方式：

通过Volume

这种方式我比较推荐，因为随着ConfigMap被修改（比如你想要更新一些设置），container里面对应的文件内容也会被修改，这样可以不用重启Container就让应用能够得到最新的配置信息。

这个内容需要一些Volume相关的知识，在此不做更多讲解，大家可以去参考官方文档。

创建Secret

通过上面的部分，我们可以看到ConfigMap是用来做一些配置信息的，那么如果我们有一些机密信息比如说密钥、密码之类的信息，应该存在哪里呢？看到这个名字大家应该就明白了吧，kubernetes提供了Secret来存储相关的信息。

具体为什么要存在Secret里面，Secret和ConfigMap有什么区别，后面会讲到。

创建Secret

我们可以通过kubectl create secret来通过一个文件创建一个secret，如下：

# Create a file with password $ echo 'mysqlpassword' > password.txt # Make sure there is no trailing newline in the file, after our password.  # To remove any newline, we can use the tr command: $ tr -Ccsu '\n' < password.txt > .strippedpassword.txt && mv .strippedpassword.txt password.txt # Create the Secret  $ kubectl create secret generic my-password --from-file=password.txt secret "my-password" created

我们也可以手动创建一个Secret，不过要注意，所有的secret的data都要以base64进行加密：

$ cat password.txt | base64 bXlzcWxwYXN3b3JkCg== # and then use it in the configuration file: apiVersion: v1 kind: Secret metadata: name: my-password type: Opaque data: password: bXlzcWxwYXN3b3JkCg==

使用Secret

获取Secret

我们可以通过get和describe来获取Secret，不过我们发现，kubectl并没有向我们返回Secret具体的内容：

$ kubectl get secret my-password NAME TYPE DATA AGE my-password Opaque 1 8m $ kubectl describe secret my-password Name: my-password Namespace: default Labels: <none> Annotations: <none> Type Opaque Data ==== password.txt: 13 bytes

在Pod里面使用

和ConfigMap一样，我们可以通过设置成env或者挂载成volume来使容器可以使用我们的secret。

具体格式如下：

.... spec: containers: - image: wordpress:4.7.3-apache name: wordpress env: - name: WORDPRESS_DB_HOST value: wordpress-mysql - name: WORDPRESS_DB_PASSWORD valueFrom: secretKeyRef: name: my-password key: password.txt .....