非敏感数据，比如应用的配置信息，则可以用ConfigMap
创建configmap四种方式
（1）通过--from-literal：
kubectl create configmap myconfigmap --from-literal=config1=xxx --from-literal=config2=yyy
每个--from-literal对应一个信息条目
（2）通过--from-file：
[root@k8s-master ~]# echo -n xxx >./config1
[root@k8s-master ~]# echo -n yyy >./config2
[root@k8s-master ~]# kubectl create configmap myconfigmap2 --from-file=./config1 --from-file=./config2
configmap/myconfigmap2 created
[root@k8s-master ~]#
每个文件内容对应一个信息条目。
（3）通过--from-env-file：
[root@k8s-master ~]# cat << EOF >env.txt
> config1=xxx
> config2=yyy
> EOF
[root@k8s-master ~]# kubectl create configmap myconfigmap3 --from-env-file=env.txt
configmap/myconfigmap3 created
[root@k8s-master ~]#
文件env.txt中每行Key=Value对应一个信息条目。
（4）通过YAML配置文件（参考secret）
小结：
Secret和ConfigMap支持四种定义方法。Pod在使用它们时，可以选择
Volume方式或环境变量方式，不过只有Volume方式支持动态更新。
Helm（包管理工具）
Helm有两个重要的概念：chart和release。
chart是创建一个应用的信息集合，包括各种Kubernetes对象的配置模板、参数定义、依赖关系、文档说明等。
chart是应用部署的自包含逻辑单元。可以将chart想象成apt、yum中的软件安装包。
release是chart的运行实例，代表了一个正在运行的应用。
当chart被安装到Kubernetes集群，就生成一个release。
chart能够多次安装到同一个集群，每次安装都是一个release。
Helm包含两个组件：
Helm客户端和Tiller服务器
Pod是应用负载的组件
API 服务器是 Kubernetes 控制平面的组件
kube-scheduler 是控制平面的组件
三种控制器区别
-
Deployment：适用于无状态服务，可以实现滚动升级和回退，支持水平扩展和自动恢复。
-
StatefulSet：适用于有状态服务，可以保证Pod名称与Pod副本集之间的唯一性和稳定性，支持有序部署和扩展。
-
DaemonSet：用于在每个节点上运行一个Pod，例如日志收集、监控等任务。
简而言之，Deployment适合无状态应用程序，StatefulSet适合有状态应用程序，而DaemonSet适合在整个集群中运行特定类型的Pod。
案例：
以下是一些使用这些控制器的实际案例：
- Deployment
-部署 Web 应用程序，例如 WordPress 、 Ghost 等
﹣在 Kubernetes 上运行无状态微服务，如 APl Gateway 、数据库代理等
-自动扩展容器数量以适应流量波动，例如从100到1000
- StatefulSet
- MySQL 、 PostgreSQL 、 Elasticsearch 等有状态应用的部署
-使用有序扩展逐步更新集群中的 Pod ，例如逐步升级数据库版本
- DaemonSet
-运行每个节点上的 Fluentd 或 Logstash 等日志收集器（部署守护式的进程）
-运行每个节点上的监控代理，如 Prometheus Node Exporter 、 Zabbix Agent 等
﹣运行每个节点上的网络服务代理／负载均衡器，如 Nginx Ingress Controller 等
需要注意的是，这些案例只是参考，并不是绝对的。在实际应用中，我们需要根据具体需求来选择合适的控制器。