K8s Secrets 与 ConfigMaps 管理：安全存储配置信息

好的，各位观众老爷们，今天咱们就来聊聊 Kubernetes 里保管秘密的那些事儿——Secrets 和 ConfigMaps！ 这俩哥们儿，在 Kubernetes 这个舞台上，一个负责藏宝贝（敏感信息），一个负责摆道具（配置信息）。 别看名字挺唬人，其实理解起来一点都不难。 咱们争取用最通俗易懂的方式，把这俩活宝的功能、用法、注意事项，给您安排得明明白白！

开场白：秘密的诱惑与配置的烦恼

话说，咱们写程序，总免不了要用到一些秘密武器：数据库的密码、API Key、TLS 证书…… 这些东西，要是明晃晃地写在代码里，那简直就是敞开大门，欢迎黑客来做客！ 想象一下，你辛辛苦苦写的代码，结果因为一个简单的密码泄露，就被别人给控制了，那感觉，简直比失恋还难受！💔

除了秘密，还有各种各样的配置信息。 比如，程序的端口号、数据库连接地址、日志级别等等。 这些配置，就像程序的调味料，不同的环境需要不同的配方。 如果你把这些配置硬编码在程序里，那每次换个环境，就得重新编译一遍，简直就是噩梦！ 🤯

还好，Kubernetes 为我们准备了 Secrets 和 ConfigMaps 这两把利剑，帮我们斩断这些烦恼！

第一幕：揭开 Secrets 的神秘面纱

Secrets，顾名思义，就是用来存储敏感信息的。 它就像一个保险箱，可以安全地存放你的密码、密钥、证书等等。 Kubernetes 会对 Secrets 进行加密存储，并且严格控制访问权限，确保你的秘密不会轻易泄露。

Secrets 的类型

Secrets 可不是只有一种类型，它有很多不同的口味，可以满足你不同的需求：

类型	描述	常用场景
Opaque	默认类型，用于存储任意类型的键值对。	存储数据库密码、API Key 等。
kubernetes.io/service-account-token	用于存储 Service Account 的 Token，Kubernetes 会自动创建和管理。	Pod 访问 Kubernetes API Server。
kubernetes.io/dockerconfigjson	用于存储 Docker Registry 的认证信息，让 Pod 可以拉取私有镜像。	从私有 Docker Registry 拉取镜像。
kubernetes.io/tls	用于存储 TLS 证书和私钥，用于 HTTPS 通信。	配置 HTTPS 服务。
bootstrap.kubernetes.io/token	用于新节点加入 Kubernetes 集群时的身份验证。	Kubernetes 集群的节点加入。

Secrets 的用法

创建 Secrets 的方法有很多种，最常用的就是使用 kubectl 命令行工具。 比如，我们可以使用以下命令创建一个存储数据库密码的 Secrets：

kubectl create secret generic db-password 
  --from-literal=username=admin 
  --from-literal=password=s3cr3t

这条命令会创建一个名为 db-password 的 Secrets，其中包含两个键值对：

• username: admin
• password: s3cr3t

创建好 Secrets 之后，我们就可以在 Pod 中使用它了。 有两种常用的方式：

1. 作为环境变量

   我们可以将 Secrets 中的值注入到 Pod 的环境变量中。 这样，程序就可以通过环境变量来获取密码等敏感信息。

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   spec:
     containers:
     - name: my-container
       image: my-image
       env:
       - name: DB_USERNAME
         valueFrom:
           secretKeyRef:
             name: db-password
             key: username
       - name: DB_PASSWORD
         valueFrom:
           secretKeyRef:
             name: db-password
             key: password

   在这个例子中，我们将 db-password Secrets 中的 username 和 password 分别注入到 DB_USERNAME 和 DB_PASSWORD 环境变量中。

2. 作为 Volume Mount

   我们可以将 Secrets 挂载到 Pod 的文件系统中。 这样，程序就可以像读取普通文件一样，读取 Secrets 中的值。

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   spec:
     containers:
     - name: my-container
       image: my-image
       volumeMounts:
       - name: db-credentials
         mountPath: /etc/db-credentials
         readOnly: true
     volumes:
     - name: db-credentials
       secret:
         secretName: db-password

   在这个例子中，我们将 db-password Secrets 挂载到 /etc/db-credentials 目录下。 程序可以通过读取 /etc/db-credentials/username 和 /etc/db-credentials/password 文件来获取用户名和密码。

Secrets 的注意事项

• 不要把 Secrets 提交到代码仓库！ 这简直就是自杀行为！ 🙅‍♀️
• 定期轮换 Secrets。 定期更换密码可以降低泄露风险。 🔄
• 使用 RBAC 控制 Secrets 的访问权限。 确保只有授权的用户和 Pod 才能访问 Secrets。 👮
• 考虑使用 Secret Management 工具。 像 HashiCorp Vault 这样的工具可以提供更高级的 Secrets 管理功能。 🔑

第二幕：ConfigMaps 的妙用

ConfigMaps，顾名思义，就是用来存储配置信息的。 它就像一个配置文件，可以集中管理你的应用程序的各种配置参数。 比如，数据库连接地址、日志级别、程序端口号等等。

ConfigMaps 的类型

ConfigMaps 的类型比较简单，只有一种，就是键值对。 你可以把任何类型的配置信息都存储在 ConfigMaps 中。

ConfigMaps 的用法

创建 ConfigMaps 的方法和创建 Secrets 类似，也可以使用 kubectl 命令行工具。 比如，我们可以使用以下命令创建一个存储数据库连接信息的 ConfigMaps：

kubectl create configmap db-config 
  --from-literal=db_host=mydb.example.com 
  --from-literal=db_port=5432

这条命令会创建一个名为 db-config 的 ConfigMaps，其中包含两个键值对：

• db_host: mydb.example.com
• db_port: 5432

创建好 ConfigMaps 之后，我们也可以在 Pod 中使用它。 同样有两种常用的方式：

1. 作为环境变量

   我们可以将 ConfigMaps 中的值注入到 Pod 的环境变量中。

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   spec:
     containers:
     - name: my-container
       image: my-image
       env:
       - name: DB_HOST
         valueFrom:
           configMapKeyRef:
             name: db-config
             key: db_host
       - name: DB_PORT
         valueFrom:
           configMapKeyRef:
             name: db-config
             key: db_port

   在这个例子中，我们将 db-config ConfigMaps 中的 db_host 和 db_port 分别注入到 DB_HOST 和 DB_PORT 环境变量中。

2. 作为 Volume Mount

   我们可以将 ConfigMaps 挂载到 Pod 的文件系统中。

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   spec:
     containers:
     - name: my-container
       image: my-image
       volumeMounts:
       - name: db-config
         mountPath: /etc/db-config
         readOnly: true
     volumes:
     - name: db-config
       configMap:
         name: db-config

   在这个例子中，我们将 db-config ConfigMaps 挂载到 /etc/db-config 目录下。 程序可以通过读取 /etc/db-config/db_host 和 /etc/db-config/db_port 文件来获取数据库连接信息。

ConfigMaps 的注意事项

• ConfigMaps 存储的是明文数据！ 不要把敏感信息存储在 ConfigMaps 中！ 🙅‍♀️
• ConfigMaps 的大小有限制。 默认情况下，ConfigMaps 的大小不能超过 1MB。 如果你的配置信息太多，可以考虑拆分成多个 ConfigMaps。 ✂️
• 使用 ConfigMaps 可以实现配置的热更新。 当 ConfigMaps 的内容发生变化时，Kubernetes 会自动更新 Pod 中的配置。 🔥

第三幕：Secrets 和 ConfigMaps 的爱恨情仇

虽然 Secrets 和 ConfigMaps 都是用来存储数据的，但它们的应用场景却截然不同。 Secrets 用于存储敏感信息，ConfigMaps 用于存储配置信息。 它们就像一对欢喜冤家，一个负责保护秘密，一个负责管理配置，共同守护着你的应用程序。

Secrets 和 ConfigMaps 的区别

特性	Secrets	ConfigMaps
存储内容	敏感信息（密码、密钥、证书等）	配置信息（数据库连接地址、日志级别等）
存储方式	加密存储	明文存储
安全性	高	低
应用场景	存储敏感信息	存储配置信息

Secrets 和 ConfigMaps 的最佳实践

• 永远不要把敏感信息存储在 ConfigMaps 中！ 这是铁律！ 🚫
• 使用 Secrets 存储密码、密钥、证书等敏感信息。
• 使用 ConfigMaps 存储配置信息，例如数据库连接地址、日志级别等。
• 结合使用 Secrets 和 ConfigMaps，可以更好地管理你的应用程序的配置。
• 使用 Secret Management 工具可以提供更高级的 Secrets 管理功能。

终场谢幕：安全配置，一路护航

好了，各位观众老爷们，今天的 Kubernetes Secrets 和 ConfigMaps 之旅就到这里了。 希望通过今天的讲解，大家对这两个活宝有了更深入的了解。 记住，安全配置是应用程序安全的第一道防线。 只有把秘密藏好，把配置管好，才能让你的应用程序在 Kubernetes 的世界里安全稳定地运行！ 🚀

希望这篇文章能帮助您更好地理解和使用 Kubernetes 的 Secrets 和 ConfigMaps。 祝您编程愉快！ 😊