Kubernetes学习笔记-ConfigMap和Secret：配置应用程序（1）20220501

一、配置容器化应用程序

常见的三种参数传递方式：
1）配置嵌入应用本身，以命令行参数形式配置应用；
2）配置选项多了，将配置文件化；
3）借助环境变量，应用程序主动查找某一特定环境变量的值，而非读取配置文件或解析命令行参数
容器环境下环境变量方法比较常见，因为直接在docker容器中采用配置文件的方式有些许困难，往往需要将配置文件打入容器镜像，抑或是挂载包含该文件的卷。前者类似于在应用程序源代码中硬编码配置，每次修改完配置后需要重新构建镜像，除此之外，任何拥有镜像访问权限的人可以看到配置文件包含的敏感信息，如证书和密钥。相比之下，挂载卷的方式更好，但是中容器启动之前需要确保配置文件已写入相应的卷中。
有一种更加简便的方法能将配置数据置于kubernetes的顶级资源对象中，并可与其他资源定义存入同一git仓库或基于文件的存储系统中。用以存储配置数据的kubernetes资源称为ConfigMap
总结：无论是否使用ConfigMap存储配置数据，以下方法均可用作配置你的应用程序：
1）向容器传递命令行参数
2）为每个容器设置自定义环境变量
3）通过特殊类型的卷将配置文件挂载到容器
 

二、向容器传递命令行参数

1）在docker中定义命令与参数
容器中运行的完整指令由两部分组成：命令和参数
dockerfile中的两种指令分别定义命令和参数这两个部分：
ENTRYPOINT定义容器启动时被调用的可执行程序
CMD指定传递给ENTRYPOINT的参数
尽管可以直接使用cmd 指令指定镜像运行时想要执行的命令，正确的做法依旧是借助Entrypoint指令，仅仅用cmd指定所需的默认参数。这样镜像可以直接运行，无须添加任何参数
了解shell和exec形式的区别：
shell形式—-如ENTRYPOINT node.is
exec形式—-如ENTRYPOINT [“node”,”app.js”]
两者的区别在于指定的命令是否在shell中被调用

三、为容器设置环境变量

容器化应用可以使用环境变量作为配置源。kubernetes允许为pod中的每一个容器都指定自定义的环境变量集合
注意：与容器的命令和参数设置相同，环境变量列表无法在pod创建后被修改
1）可以在容器定义（yaml文件）中指定环境变量
说明：环境变量被设置在pod的容器定义中，并非是pod级别
2）在环境变量值中引用其他环境变量
环境变量的值是固定的，可以采用$（VAR）语法在环境变量值中引用其他的环境变量。假设定义了两个环境变量，第二个变量中可以包含第一个环境变量的值，如下：
env:
-name:FIRST_VAR
value:”foo”
-name:SECOND_VAR
value:”$（FIRST_VAR）bar”
3）硬编码环境变量的不足之处
pod定义硬编码意味着需要有效区分生产环境与开发过程中的pod定义。为了能在多个环境下复用pod定义，需要将配置从pod定义描述中解耦出来。可以通过一种叫做ConfigMap的资源对象完成解耦，用valueFrom字段替代value字段使ConfigMap成为环境变量值的来源