kubernetsk 8 sconfig地图容器(kubernetes configmap)的技术分析

1.什么是ConfigMap？Map是一个用于存储配置文件的Kubernetes资源对象。配置对象存储在Etcd中，配置形式可以是完整的配置文件、键/值等。

2.ConfigMap能带来什么好处？在传统的应用服务中，每个服务都有自己的配置文件，每个配置文件都存储在服务所在的节点中。对于单个应用程序，这个存储没有问题。但是，随着用户的激增，一个节点无法满足在线用户的需求，因此服务可能会从一个节点扩展到十个节点，这导致如果一个配置发生变化，就需要相应地修改十次配置文件。

这种人肉处理显然不能满足线上部署的要求，于是推出了各种类似ZooKeeper中间件的配置中心，但配置中心属于& ldquo侵入性& rdquo设计需要修改引入第三方类库，需要每个业务调用特定的配置接口，破坏了系统本身的完整性。Kubernetes曾利用Volume函数设计了一套配置中心，其核心对象是ConfigMap，在使用过程中无需修改任何原设计即可无缝检查ConfigMap。为什么？

如图(1)所示，

ConfigMap相当于放入原生应用的配置文件，可以是一个或多个；容器启动后，从主机拉取ConfigMap的内容生成本地文件，以卷的形式映射到容器内部的指定目录；容器中的应用程序以原始方式读取容器特定目录中的配置文件。从容器的角度来看，配置文件就像是包装在容器内部的特定目录，整个过程对应用程序没有入侵。

3.ConfigMap通过三种方式指定文字量来创建，创建命令如下:ku bectl create config map config maptest --from -literal = foo = bar --from -literal = one = two。创建完成后，通过以下方式进行检查:

3.通过以下方式检查环境变量是否有效，可以发现ConfigMap中的环境变量已经存在于容器环境中。

您可以通过以下方式检查环境变量是否有效。如下所示，每个环境变量都根据预设添加了前缀。有人可能会说，我的配置文件里本来配置的东西，没必要加预置前缀。请如图(4)所示进行检查。通过将前缀设置为空字符串，可以保持原始的配置模式。

当用于在args模式下传递环境变量的容器启动时，它可以用于将变量传递给服务并运行shell脚本。具体设置方法如图(5)所示:

以上通过在yaml中设置env引用ConfigMap解释了configuration作为环境变量的使用。在使用过程中，我查阅了《Kubernetes在行动》这本书，发现这本书里有一段是这样描述的，如图(6):

这可能意味着配置键不能包含破折号，如果包含破折号，也不能设置到环境变量中。这部分书是基于Kubernetes 1.6编译的，我用的是kubernetes 1.14。不知道是因为Kubernetes改进了，还是其他原因。我有两个难题。

破折号(& mdash& mdash)大多指极长的符号。很少有人在编码过程中使用这个，即使使用，Kubernetes也根本无法保存成功。

环境变量呢？将会出现如图(7)和图(8)所示的错误提示:

破折号改成英文半角字符-中破折号怎么办？如图(9)所示，保存成功。当然也可以用在环境变量中。

当然，按照上述方式设置后，可以直接使用容器内部的环境变量来读取设置的配置。然而，使用环境变量的方法有一个致命的缺点。当外部ConfigMap更新配置时，容器内的环境变量不会改变。这是因为env是在容器启动时注入的，启动后Kubernetes不会改变env的值，即配置不能同步更新，只有重启容器配置才能生效。

5.挂载卷的方法是以卷的形式映射到容器内部的指定目录，容器内部的进程直接读取目录中的特定文件。这种方法是我们常用的，具体用法如下:

......-container port:80 volume mounts:-mount path:/usr/local/nginx/conf/vhost/name:http -mount path:/usr/local/nginx/html/foo子路径:foo name:ngin X-html volumes:-name:http config map:name:ngin X-conf -name:ng X-html config map:name:configmaptestitems:-key:foo path:foo.....volumes是容器内指定的挂载目录，Volumes是引用目录，即主机设置configmap文件地址。

您可以直接将目录挂载到容器中。当主机以如下方式修改configmap时，容器的内部配置将被改变，并且所有文件将被一次修改。但是，使用这种方法有一个问题。如果容器内的文件夹中有其他文件，此方法将直接覆盖原始文件夹中的文件。[root @ k8s -master ~]# ku ectl编辑配置图configmaptest如果有特定要求，需要挂载特定文件，但不允许覆盖原文件。可以挂载到指定的文件，通过subPath与指定的文件协同工作。而单文件挂载的方式无法实现热更新，即当主机的ConfigMap文件发生变化时，容器不会自动重装。至于物品的使用，就比较简单了。如果一个ConfigMap包含多个配置文件，但只有其中一些文件被公开，则可以通过项目来指定它。当然，也可以对文件设置读写权限。

6.Secret使用Secret，它类似于ConfigMap，支持两种使用形式:

将Secret作为环境变量公开给容器进程。该秘密通过卷数据卷被提供给容器进程。这里你可能要说，一切都是一样的。你为什么需要秘密？配置图解决了这个问题，但事实上，它不是。Secret，顾名思义，是用来存储加密数据的。老版本的Kubernetes只支持base64加密。学过计算机的人都知道base64不是加密，只是对字符串进行编码，明文可以通过decode直接解码。

但后来新版Kubernetes已经实现了真正意义上的加密解密，所以Secret的存在就有了一定的意义。它的使用方式与ConfigMap类似，但命令确实不同。

1.为创建密码输入以下内容:

kuctl create Secret generic nginx -SSL --from -file = ca . key --from -file = ca . cert 2。按如下方式检查机密输入:

[root @ k8s -master ~]# ku ectl get secret name类型数据age default -token -7h5z 9 kubernetes.io/服务-account -token 3 6d 13 hnginx -SSL Opaque 2 21h[root @ k8s -master ~]# ku ectl get secret ngin x-SSL -o yamla version:v1 DATA:ca . CRT:qmfnief 0 dhjpynv 0 zxmkicagigzy.......................ca . key:qmfnief 0 dhjpynv 0 zxmkic agig zy......................善良:秘密.....................3.Pod引用:

.....................-容器端口:80卷装载:-装载路径:/home/nginx/nginx/conf/cert/name:nginx -SSL卷:-name:nginx -SSL secret:secret name:nginx -SSL.....................

7.应用程序如何在不重启的情况下读取最新的配置？上面已经提到环境变量和单文件挂载形式不能用于热更新，但是数据卷形式可以用于主机和Pod的读取配置的实时更新。然而，应当注意，配置图被更新，并且数据量也被更新。如果您的应用程序进程没有重新加载配置，也就是说，没有实时读取配置数据，它仍然会使用旧的配置。

这个问题可以通过将Pod的副本数减少到0来重建Pod来解决。这种方式虽然可以解决服务重载的问题，但是也会带来问题。

由于可能导致同一组服务配置不一致，如果业务要求高实时性，建议更改服务实时加载配置。综上所述，Kubernetes只是将配置实时同步到数据卷配置文件。至于加载时机，就看自己的应用了。

比如nginx配置存储在Kubernetes ConfigMap中，公钥信息存储在Secret中，nginx在服务中充当反向代理。由于端口资源规划问题，nginx配置文件中的端口需要修改。修改完成后，Pod中的数据量配置信息发生变化，但nginx不会重载修改后的配置信息。

通过下面的命令行修改，修改完成后发现Pod中的nginx配置生效。

ku bectl exec nginx -c nginx --/usr/local/nginx/sbin/nginx -s reload

总结ConfigMap本身就是一个很接地气的设计。借助volume，无需修改任何代码，即可实现原有服务的无缝连接。如果您使用过其他分布式配置管理服务，如DisConf、Apollo等。，可以保持原来的方式，继续使用。

以上是Kubernetes k8s configmap容器技术分析的详细内容。更多关于k8s configmap容器技术的信息，请关注主机频道zhujipindao的其他相关文章。com！