下载掌阅APP，畅读海量书库
立即打开
Kubernetes允许你通过原生的ConfigMap或Secret为应用提供配置。两者之间的主要区别在于Pod和etcd对它们有着不同的存储方式。
让应用通过某种机制（如命令行参数、环境变量或系统可用的文件）来使用配置信息是很常见的，而且容器允许应用与配置解耦，这样就可以真正地实现应用的可移植性。ConfigMap API可以注入用户提供的配置信息，能够满足应用的不同需求，并且支持不同的配置数据类型，包括键值对或复杂的大块数据（如JSON、XML或某些专用配置）。
ConfigMap不仅可以为Pod提供配置信息，还可以为复杂的系统服务提供配置，如控制器、CRD、Operator等。如前文所述，ConfigMap API更多地用于存放字符串等非敏感的数据，如果应用需要敏感数据，Secret API会更合适。
应用程序要使用ConfigMap的数据，可以将其作为卷挂载到Pod中，或者将其作为环境变量注入。
使用ConfigMap的很多属性原因也适用于Secret。ConfigMap和Secret的主要区别在于Secret的性质，Secret中的数据应该以容易隐藏的方式进行存储和处理，并尽可能地进行静态加密。Secret数据是以base64编码的方式展现的，它们并没有被加密，理解这一点至关重要。Secret一旦被注入Pod中，Pod便可以以明文的方式查看机密数据。
Secret应该只存储少量数据，默认情况下，Kubernetes限制了base64编码之后的数据最多不超过1MB，考虑到编码的额外开销，请确保实际的机密数据不超过750KB。Kubernetes中有3种类型的Secret：
这通常是通过文件、目录或者使用-from-literal=参数从字符串文字创建的键值对，如下所示：
这种类型用在Pod模板中的imagePullsecret字段，kubelet用其作为访问私有
Docker容器镜像仓库的凭证：
从有效的公/私密钥对创建的TLS（Transport Layer Security，传输层安全）Secret。只要证书符合PEM格式，密钥就会被编码为Secret，并且可以传递给Pod用于SSL/TLS：
只有节点中有Pod需要用到某个Secret时，Secret才会被挂载到该节点的tmpfs中，并且如果此Pod被删除了，该挂载也会被删除。这样可以防止Secret被遗留在节点的磁盘上。尽管这看起来很安全，但默认情况下，Secret以明文形式存储在Kubernetes的etcd数据存储中，这就要求系统管理员或云服务提供商务必确保etcd环境的安全性，可以采取的措施包括在etcd节点之间启用mTLS和启用etcd数据的静态加密。较新版本的Kubernetes使用etcd3，并且原生支持etcd加密。但是，这需要手动操作，必须在API Server的配置中指定提供程序和适当的密钥媒介，从而正确地加密保存在etcd中的机密数据。从Kubernetes v1.10版本（在v1.12中已经提升为beta版）开始，我们有了KMS提供程序，它可以使用第三方KMS系统来保存密钥，提供更安全的密钥流程。