在k8s中创建ConfigMap的四种方式与初识helm包管理工具

非敏感数据，比如应用的配置信息，则可以用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 是控制平面的组件

三种控制器区别

1. Deployment：适用于无状态服务，可以实现滚动升级和回退，支持水平扩展和自动恢复。

2. StatefulSet：适用于有状态服务，可以保证Pod名称与Pod副本集之间的唯一性和稳定性，支持有序部署和扩展。

3. DaemonSet：用于在每个节点上运行一个Pod，例如日志收集、监控等任务。

简而言之，Deployment适合无状态应用程序，StatefulSet适合有状态应用程序，而DaemonSet适合在整个集群中运行特定类型的Pod。

案例：

以下是一些使用这些控制器的实际案例：

1. Deployment 

-部署 Web 应用程序，例如 WordPress 、 Ghost 等

﹣在 Kubernetes 上运行无状态微服务，如 APl Gateway 、数据库代理等

-自动扩展容器数量以适应流量波动，例如从100到1000

2. StatefulSet 

- MySQL 、 PostgreSQL 、 Elasticsearch 等有状态应用的部署

-使用有序扩展逐步更新集群中的 Pod ，例如逐步升级数据库版本

3. DaemonSet 

-运行每个节点上的 Fluentd 或 Logstash 等日志收集器（部署守护式的进程）

-运行每个节点上的监控代理，如 Prometheus Node Exporter 、 Zabbix Agent 等

﹣运行每个节点上的网络服务代理／负载均衡器，如 Nginx Ingress Controller 等

需要注意的是，这些案例只是参考，并不是绝对的。在实际应用中，我们需要根据具体需求来选择合适的控制器。