ConfigMap 和 Secret 是 Kubernetes 系统上两种特殊类型的存储卷，前者用于为容器中的应用提供配置数据以定制程序的行为，而敏感的配置信息，例如密钥、证书等则通常由后者来配置。ConfigMap 和 Secret 将相应的配置信息保存于资源对象中，而后在 Pod 对象上以存储卷的形式将其挂载并加载相关的配置，降低了配置与镜像文件的耦合关系。
Dockerfile 中的 ENTRYPOINT 和 CMD 指令用于指定容器启动时要运行的程序及其相关的参数。其中，CMD 指令以列表形式指定要运行的程序及其相关的参数，若同时存在 ENTRYPOINT 指令，则 CMD 指令中的列表所有元素均被视作由 ENTRYPOINT 指定程序的命令行参数。另外，在基于某镜像创建容器时，可以通过向 ENTRYPOINT 中的程序传递额外的自定义参数，甚至还可以修改要运行的应用程序本向。
配置文件嵌入镜像文件，是指用户在 Dockerfile 中使用 COPY 指令把定义好的配置文件复制到镜像文件系统上的目标位置，或者使用 RUN 指令调用 sed 或 echo 一类的命令修改配置文件，从而达到为容器化应用提供自定义配置文件之目的。
Docker 存储卷能够将宿主机之上的任何文件或目录映射进容器文件系统上，因此，可以事先将配置文件放置于宿主机之上的某特定路径中，而后在启动容器时进行加载。这种方式灵活易用，但也依赖于用户事先将配置数据提供在宿主机上的特定路径。
通过环境变量配置容器化应用时，需要在容器配置段中嵌套使用 env 字段，它的值是一个由环境变量构建的列表。每个环境变量通常由 name 和 value（或 valueFrom）字段构成。
name
value
ConfigMap 资源用于在运行时将配置文件、命令行参数、环境变量、端口号以及其他配置工件绑定至 Pod 的容器和系统组件。Kubernetes 借助于 ConfigMap 对象实现了将配置文件从容器镜像中解耦，从而增强了工作负载的可移植性，使配置更易于更改和管理，并防止将配置数据硬编码到 Pod 配置清单中。但 ConfigMap 资源用于存储和共享非敏感、未加密的配置信息，若要在集群中使用敏感信息，则必须使用 Secret 资源。
一个 ConfigMap 对象就是一系列配置数据的集合，这些数据可注入到 Pod 的容器当中为容器应用所使用，注入的途径有直接挂载存储卷和传递为环境变量两种。ConfigMap 支持存储诸如单个属性一类的细粒度的信息，也可用于存储粗粒度的信息，例如将整个配置文件保存在 ConfigMap 对象之中。
ConfigMap 是 Kubernetes 标准的 API 资源类型，它隶属名称空间级别，支持命令式命令、命令式对象配置及声明式对象配置 3 种管理接口。命令式命令的创建操作可通过 kubectl create configmap 进行，它支持基于目录、文件或字面量（literal）值获取配置数据完成 ConfigMap 对象的创建。
Pod 资源配置清单中，除了使用 value 字段直接给定变量值之外，容器环境变量的赋值还支持通过在 valueFrom 字段中嵌套 configMapKeyRef 来引用 ConfigMap 对象的键值。
以存储卷方式引用的 ConfigMap 对象必须先于 Pod 对象存在，除非在 Pod 对象中把它们统统标记为 optional，否则将会导致 Pod 无法正常启动；同样，即使 ConfigMap 对象存在，但引用的键名不存在时，也会导致同样的错误。
以环境变量方式引用的 ConfigMap 对象的键不存在时会被忽略，Pod 对象可以正常启动，但错误引用的信息会以 InvalidVariableNames 事件记录于日志中。
ConfigMap 对象是名称空间级的资源，能够引用它的 Pod 对象必须位于同一名称空间。
Kubelet 仅支持那些由 API Server 管理的 Pod 资源来引用 ConfigMap 对象，因而那些由 kubelet 在节点上通过--manifest-url 或--config 选项加载配置清单创建的静态 Pod，以及由用户直接通过 kubelet 的 RESTful API 创建的 Pod 对象。
ConfigMap 无法替代配置文件，它仅在 Kubernetes 系统上代表对应用程序配置文件的引用，我们可以将它类比为在 Linux 主机上表示/etc 目录及内部文件的一种方法。
