k8s Secret配置资源，ConfigMap 存储配置信资源管理详解

目录

一、Secret 概念

三种Secret类型

pod三种使用secret的方式

应用场景：凭据：

二、 示例

2.1、用kubectl create secret命令创建 Secret

创建Secret：

查看Secret列表：

描述Secret：

2.2、用 base64 编码，创建Secret

Base64编码：

创建YAML文件：

创建Secret：

查看Secret列表：

查看Secret详情：

2.3、以volume形式挂载到pod中

创建Pod定义文件：

创建Pod：

查看Pod状态：

进入Pod的容器：

查看挂载的Secret文件：

查看Secret文件内容：

2.4、导入到环境变量

创建Pod定义文件：

应用Pod定义：

查看Pod状态：

进入Pod的容器：

查看环境变量：

2.5、使用Secret配置可以实现免密交互拉取Harbor私有仓库镜像。

除此以外的案例

三、ConfigMap 存储配置信息的资源

ConfigMap的主要用途包括：

四、 示例

4.1、目录创建ConfigMap资源

创建目录：

创建配置文件：

使用kubectl创建ConfigMap：

查看ConfigMap列表：

查看ConfigMap详情：

4.2、文件创建ConfigMap资源

创建ConfigMap：

查看ConfigMap详情：

描述ConfigMap：

4.3、字面值参数创建 ConfigMap资源

创建ConfigMap：

查看ConfigMap详情：

删除所有ConfigMap和Pod：

4.5、Pod中使用ConfigMap

4.5.1、使用ConfigMap替代环境变量

创建ConfigMap：

查看ConfigMap列表：

4.5.2、创建Pod引用ConfigMap资源：

应用Pod定义：

查看Pod状态：

查看Pod日志：

4.6、ConfigMap 设置命令行参数

创建Pod定义文件：

创建Pod：

查看Pod状态：

查看Pod日志：

4.7、通过数据卷插件使用ConfigMap

创建Pod定义文件：

创建Pod：

查看Pod状态：

进入Pod的容器：

查看数据卷内容：

五、ConfigMap 的热更新

创建ConfigMap和Deployment：

应用ConfigMap和Deployment：

查看Pod状态：

查看ConfigMap的数据：

编辑ConfigMap：

等待ConfigMap更新：

再次查看ConfigMap的数据：

触发Pod的滚动更新：

查看新的Pod状态：

---

一、Secret 概念

在Kubernetes（k8s）中，Secret资源是一种用于存储敏感信息的方式，比如密码、OAuth令牌、SSH密钥等。这样做的好处是，可以在不直接在代码或者配置文件中硬编码这些敏感信息的情况下，安全地管理和分发它们。Secret资源可以被Pods访问，以便于在运行时使用这些敏感数据。

三种Secret类型

• kubernetes.io/service-account-token：这种类型的Secret是由Kubernetes系统自动创建和管理的。每个ServiceAccount都会关联一个这样的Secret，它包含了用于访问Kubernetes API的认证令牌。这些令牌通常被自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录下，以便Pod可以安全地与Kubernetes API进行通信。

• Opaque：这是默认的Secret类型，它存储的是base64编码的数据。可以在这种类型的Secret中存储任何形式的敏感数据，比如数据库密码、API密钥等。这些数据可以被Pod以环境变量或者文件的形式访问。

• kubernetes.io/dockerconfigjson：这种类型的Secret用于存储私有Docker Registry的认证信息。当需要从私有的Docker Registry拉取镜像时，可以创建一个包含registry认证信息的Secret，并将其挂载到Pod中。这样，Pod就可以在不暴露认证信息的情况下，安全地访问私有Registry。

使用Secret资源是Kubernetes安全实践的一个重要方面，它有助于保护集群免受不必要的安全风险。在配置和管理Secret时，应该遵循最小权限原则，确保只有需要访问这些敏感数据的Pod才能访问它们。

pod三种使用secret的方式

Pod 需要先引用才能使用某个 secret

在Kubernetes中，Secret资源提供了一种安全的方式来存储和管理敏感信息，如密码、OAuth令牌、SSH密钥等。Pod可以通过以下三种方式使用Secret：

• 作为挂载到容器的卷中的文件：

• 当你想要在Pod的容器中访问Secret中的数据时，可以将Secret挂载为一个卷。这样，Secret中的数据就会以文件的形式出现在容器的文件系统中。例如，你可以将数据库密码挂载到容器的某个目录下，容器内的应用程序就可以通过读取这些文件来获取所需的凭据。

• 作为容器的环境变量：

• 你可以将Secret中的数据设置为容器的环境变量。这样，容器内的应用程序就可以通过环境变量来访问这些敏感信息。这种方法适用于那些需要在启动时读取敏感数据的场景，例如，用于配置数据库连接的环境变量。

• 由kubelet在为Pod拉取镜像时使用：

• 如果你的Pod需要从私有Docker Registry拉取镜像，你可以创建一个包含registry认证信息的Secret。这个Secret会被kubelet用来在拉取镜像时进行认证，而不需要在Pod的配置中直接暴露这些认证信息。

应用场景：凭据：

Secrets

• 在实际应用中，Secret常用于存储和管理各种凭据，比如数据库访问密码、API服务的访问令牌、SSH密钥等。这些凭据通常不应该直接硬编码在应用程序代码中，也不应该存储在容器镜像或者配置文件中。使用Secret可以确保这些敏感信息的安全性，并且便于管理和更新。

例如，可能有一个Web应用程序，它需要连接到一个后端数据库。可以创建一个包含数据库用户名和密码的Secret，然后在Pod的配置中引用这个Secret，将其作为环境变量或者文件挂载到容器中。这样，应用程序就可以在运行时安全地访问这些凭据，而无需在代码中直接处理敏感信息。

为了确保Secret的安全性，Kubernetes还提供了一些额外的保护措施，比如限制对Secret的访问，以及在Pod被删除后自动清除其在节点上的Secret副本。此外，Kubernetes还支持将Secret标记为不可变的（immutable），以防止意外或不必要的更新导致应用程序中断。

二、 示例

2.1、用kubectl create secret命令创建 Secret

创建了一个名为mysecret的Secret，并且包含了两个文件：username.txt和password.txt。这些文件分别包含了用户名和密码。在Kubernetes中，Secret的内容是加密存储的，以确保敏感信息的安全。因此，即使使用kubectl get secret或kubectl describe secret命令，也不会显示Secret的实际内容。

创建Secret：

echo -n 'zhangsan' > username.txt
echo -n 'abc1234' > password.txt
kubectl create secret generic mysecret --from-file=username.txt --from-file=password.txt

首先创建了两个文本文件，一个包含用户名，另一个包含密码。然后，使用kubectl create secret generic命令创建了一个名为mysecret的Secret，并指定了这两个文件作为数据源。

查看Secret列表：

kubectl get secrets

通过kubectl get secrets命令，查看了当前命名空间下的Secret列表。可以看到mysecret已经创建，并且显示了它包含的数据项数量（在这个例子中是2个）。

描述Secret：

kubectl describe secret mysecret

使用kubectl describe secret mysecret命令，获取了mysecret的详细信息。虽然这个命令提供了Secret的元数据，如类型（在这个例子中是Opaque），但它并没有显示Secret的实际内容，这是为了保护敏感数据。

2.2、用 base64 编码，创建Secret

使用base64编码创建了一个新的Secret资源mysecret1。在这个过程中，首先将用户名和密码转换为base64编码的字符串，然后将这些编码后的数据直接写入到一个YAML文件secret.yaml中，最后使用kubectl create -f secret.yaml命令创建了Secret。

Base64编码：

echo -n zhangsan | base64
emhhbmdzYW4K=echo -n abc1234 | base64
YWJjMTIzNAo==

使用echo命令和管道|将用户名和密码通过base64命令进行编码。这样，得到了可以安全传输的编码字符串。

创建YAML文件：

vim secret.yaml
apiVersion: v1
kind: Secret
metadata:name: mysecret1
type: Opaque
data:username: emhhbmdzYW4K=password: YWJjMTIzNAo==

创建了一个名为secret.yaml的文件，其中包含了Secret的定义。在这个文件中，指定了Secret的名称mysecret1，类型为Opaque，并提供了编码后的用户名和密码。

创建Secret：

kubectl create -f secret.yaml 

使用kubectl create -f secret.yaml命令，根据YAML文件中的定义创建了Secret。这个命令会将YAML文件中的数据发送到Kubernetes API服务器，从而创建了Secret资源。

查看Secret列表：

kubectl get secrets

通过kubectl get secrets命令，查看了当前命名空间下的Secret列表。可以看到mysecret1已经创建，并且显示了它包含的数据项数量（在这个例子中是2个）。

查看Secret详情：

kubectl get secret mysecret1 -o yaml

使用kubectl get secret mysecret1 -o yaml命令，以YAML格式查看了mysecret1的详细信息。这个命令输出了Secret的API版本、数据（包括编码后的用户名和密码）、类型、元数据等信息。

请注意，即使在YAML文件中，Secret的数据也是以base64编码的形式存储的。这是Kubernetes保护敏感信息的一种方式。在实际使用中，可以通过Pod的定义来引用这个Secret，并将其作为环境变量或卷挂载到容器中，以便容器内的应用程序可以安全地访问这些凭据。

2.3、以volume形式挂载到pod中

创建了一个名为mypod的Pod，并将之前创建的mysecret Secret挂载为一个名为secrets的卷。这个卷被挂载到Pod中的/etc/secrets目录下。现在，可以在Pod内部访问这些Secret文件。

创建Pod定义文件：

vim secret-test.yaml
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: nginximage: nginxvolumeMounts:- name: secretsmountPath: "/etc/secrets"readOnly: truevolumes:- name: secretssecret:secretName: mysecret

创建了一个名为secret-test.yaml的YAML文件，定义了一个Pod，其中包含一个容器（使用Nginx镜像）。在Pod的spec部分，指定了一个卷secrets，它引用了名为mysecret的Secret，并将其挂载到容器的/etc/secrets目录。

创建Pod：

kubectl create -f secret-test.yaml

使用kubectl create -f secret-test.yaml命令，根据YAML文件中的定义创建了Pod。

查看Pod状态：

kubectl get pods

通过kubectl get pods命令，查看了Pod的状态。可以看到mypod已经运行起来。

进入Pod的容器：

kubectl exec -it seret-test bash

使用kubectl exec -it mypod bash命令，进入了Pod的容器内部。

查看挂载的Secret文件：

cd /etc/secrets/
ls
password.txt  username.txt

在容器内部，使用cd /etc/secrets/命令切换到挂载的卷目录，并使用ls命令列出了目录内容。看到了password.txt和username.txt两个文件，这些文件包含了之前创建的Secret的内容。

查看Secret文件内容：

vim password.txt 
vim username.txt 

可以查看password.txt和username.txt文件的内容。这些文件包含了在创建Secret时定义的用户名和密码。

请注意，由于在Pod定义中设置了readOnly: true，这意味着Secret卷是以只读模式挂载的，不能修改这些文件。这是处理敏感数据时的一个安全最佳实践。如果需要修改Secret中的数据，应该在Kubernetes集群外部进行，然后更新Secret资源。

2.4、导入到环境变量

创建了一个名为mypod1的Pod，并将mysecret1 Secret中的特定键（username和password）导出为环境变量。这样，Pod中的容器就可以通过环境变量访问这些敏感信息。

创建Pod定义文件：

vim secret-test1.yaml
apiVersion: v1
kind: Pod
metadata:name: mypod1
spec:containers:- name: nginximage: nginxenv:- name: TEST_USERvalueFrom:secretKeyRef:name: mysecret1key: username- name: TEST_PASSWORDvalueFrom:secretKeyRef:name: mysecret1key: password

创建了一个名为secret-test1.yaml的YAML文件，定义了一个Pod，其中包含一个容器（使用Nginx镜像）。在Pod的spec部分的containers下，定义了两个环境变量TEST_USER和TEST_PASSWORD，它们分别从mysecret1 Secret中引用了username和password键的值。

应用Pod定义：

kubectl apply -f secret-test1.yaml 

使用kubectl apply -f secret-test1.yaml命令，根据YAML文件中的定义创建了Pod。

查看Pod状态：

kubectl get pods

通过kubectl get pods命令，查看了Pod的状态。可以看到mypod1已经运行起来。

进入Pod的容器：

kubectl exec -it mypod bash

使用kubectl exec -it mypod1 bash命令，进入了Pod的容器内部。

查看环境变量：

 echo $TEST_USER
zhangsanecho $TEST_PASSWORD
abc1234

在容器内部，使用echo命令打印了TEST_USER和TEST_PASSWORD环境变量的值。这些值正是在创建mysecret1 Secret时定义的用户名和密码。

这种方式允许在Pod的容器内部以环境变量的形式安全地访问Secret中的数据，而无需直接在代码或配置文件中硬编码这些敏感信息。这对于保护应用程序的安全性和简化配置管理非常有用。

2.5、使用Secret配置可以实现免密交互拉取Harbor私有仓库镜像。

• 创建私有仓库的Secret资源：

• 首先，你需要创建一个Secret资源，这个资源将包含访问Harbor私有仓库所需的认证信息，如用户名和密码。

• 使用kubectl命令创建一个名为myharbor的Secret资源，指定Docker Registry服务器地址、用户名、密码和邮箱。

kubectl create secret docker-registry myharbor --docker-server 192.168.41.31 \
--docker-username admin --docker-password Harbor12345 --docker-email [e-mail]

• 引用Secret资源拉取私有仓库镜像创建Pod：

• 在创建Pod时，你需要在Pod的配置中引用上面创建的Secret资源。

• 在Pod的spec部分，添加imagePullSecrets字段，并指定Secret的名称。

nodeName: node02
imagePullSecrets:- name: myharbor
image: /test/nginx-test:v1
dnsPolicy: ClusterFirst
restartPolicy: Always

• 注意：

• 确保Harbor仓库的默认配置为HTTPS，因为Kubernetes默认使用HTTPS与Docker Registry通信。

• 如果只是在Pod中指定节点进行测试，可以在Pod的配置中指定节点，但通常建议所有节点都进行相应的配置。

通过这种方式，Kubernetes集群中的Pod可以在不需要在命令行中暴露用户名和密码的情况下，安全地从私有仓库拉取镜像。这减少了敏感信息泄露的风险，并简化了私有仓库镜像的拉取过程。

除此以外的案例

在Kubernetes中，除了使用Secret资源来安全地访问私有Docker Registry之外，还有其他类似的案例和应用场景，这些场景通常涉及到敏感信息的管理，如数据库凭证、API密钥等。以下是一些常见的案例：

• 数据库凭证管理：

• 在部署数据库客户端应用时，可以使用Secret来存储数据库的连接字符串，包括用户名、密码、主机和端口等信息。

• 应用在启动时，可以从Secret中读取这些信息，而不是在代码或配置文件中硬编码。

• API密钥和访问令牌：

• 对于需要与外部服务（如第三方API）交互的应用，可以使用Secret来存储访问令牌或API密钥。

• 应用可以通过环境变量或配置文件的方式，从Secret中读取这些密钥，以实现安全的API调用。

• SSH密钥：

• 在需要SSH到其他服务器或服务的场景中，可以使用Secret来存储SSH私钥。

• 这样，Pod可以在不需要暴露私钥的情况下，安全地执行SSH操作。

• TLS证书：

• 对于需要TLS/SSL加密通信的服务，可以使用Secret来存储TLS证书和私钥。

• 在Ingress资源或Pod的配置中引用这些Secret，以实现安全的HTTPS连接。

• 配置文件加密：

• 对于包含敏感信息的配置文件，可以使用Secret来存储加密后的配置内容。

• 应用在启动时，可以解密这些配置内容，以获取必要的敏感数据。

在所有这些案例中，Secret资源提供了一种机制，使得敏感信息可以在Kubernetes集群中安全地存储和访问。通过将这些信息与应用代码分离，可以提高安全性，简化部署和管理。

---

三、ConfigMap 存储配置信息的资源

ConfigMap是Kubernetes中用于存储配置信息的资源，它允许你将配置数据以键值对的形式存储，并且可以被Pods以多种方式使用。与Secret不同，ConfigMap通常用于存储不需要加密的非敏感配置信息，例如应用的配置参数、数据库连接信息等。

ConfigMap的主要用途包括：

• 提供配置信息给Pods，这些信息可以作为环境变量注入到容器中，或者作为文件挂载到容器的文件系统中。

• 存储配置文件，如JSON、YAML、.properties文件等，这些文件可以被容器内的应用程序读取。

• 作为应用程序启动时的参数传递。

四、 示例

4.1、目录创建ConfigMap资源

创建了一个名为game-config的ConfigMap，并且使用了目录中的文件来填充ConfigMap的内容。

创建目录：

mkdir /opt/configmap/

创建了一个名为/opt/configmap/的目录，用于存放配置文件。

创建配置文件：

vim /opt/configmap/game.properties
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30vim /opt/configmap/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNicels /opt/configmap/
game.properties
ui.properties

在该目录下，创建了两个配置文件game.properties和ui.properties，它们包含了一些属性和值。

使用kubectl创建ConfigMap：

kubectl create configmap game-config --from-file=/opt/configmap/
//--from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容

使用kubectl create configmap game-config --from-file=/opt/configmap/命令，根据指定目录中的文件创建了ConfigMap。--from-file标志告诉kubectl命令行工具将目录下的所有文件作为ConfigMap中的键值对。每个文件名成为ConfigMap中的一个键，文件内容成为对应的值。

查看ConfigMap列表：

kubectl get cm
NAME          DATA   AGE
game-config   2      9s

通过kubectl get cm命令，查看了当前命名空间下的ConfigMap列表。可以看到game-config已经创建。

查看ConfigMap详情：

kubectl get cm game-config -o yaml

使用kubectl get cm game-config -o yaml命令，以YAML格式查看了game-config的详细信息。这个命令输出了ConfigMap的数据内容，包括game.properties和ui.properties文件的内容。

4.2、文件创建ConfigMap资源

只要指定为一个文件就可以从单个文件中创建 ConfigMap

使用单个文件创建ConfigMap，并且知道--from-file参数可以多次使用来指定多个文件。现在，将创建一个新的ConfigMap，名为game-config-2，它将包含两个特定的配置文件：game.properties和ui.properties。

创建ConfigMap：

kubectl create configmap game-config-2 --from-file=/opt/configmap/game.properties --from-file=/opt/configmap/ui.properties

使用kubectl create configmap game-config-2 --from-file=/opt/configmap/game.properties --from-file=/opt/configmap/ui.properties命令，将创建一个新的ConfigMap，它将包含指定的两个文件。

查看ConfigMap详情：

kubectl get configmaps game-config-2 -o yaml

使用kubectl get configmaps game-config-2 -o yaml命令，将以YAML格式查看新创建的game-config-2 ConfigMap的详细信息。这个命令将输出ConfigMap中的数据内容，包括game.properties和ui.properties文件的内容。

描述ConfigMap：

kubectl describe cm game-config-2

使用kubectl describe cm game-config-2命令，将获取game-config-2 ConfigMap的详细描述，包括其元数据、数据、标签、注解等信息。

这些步骤将帮助理解如何从单个或多个文件创建ConfigMap，并且如何查看和管理这些ConfigMap。在Kubernetes中，ConfigMap是管理应用配置的一种非常有效的方式，它允许在不修改应用代码的情况下，动态地调整应用的配置。

4.3、字面值参数创建 ConfigMap资源

使用文字值创建，利用 --from-literal 参数传递配置信息，该参数可以使用多次，

使用字面值创建ConfigMap。这种方法允许直接在命令行中指定键值对，而不是从文件中读取。这在需要快速创建一个简单的ConfigMap时非常有用。

创建ConfigMap：

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=good

使用kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=good命令，创建了一个名为special-config的ConfigMap，并在其中设置了两个键值对：special.how=very和special.type=good。

查看ConfigMap详情：

kubectl get configmaps special-config -o yaml

使用kubectl get configmaps special-config -o yaml命令，以YAML格式查看了special-config ConfigMap的详细信息。这个命令输出了ConfigMap的数据内容，包括刚刚创建的键值对。

删除所有ConfigMap和Pod：

kubectl delete cm --all
kubectl delete pod --all

使用kubectl delete cm --all命令，删除了当前命名空间中的所有ConfigMap。接着，使用kubectl delete pod --all命令，删除了当前命名空间中的所有Pod。

这些命令是Kubernetes中常用的资源管理操作，它们允许快速地清理和重新设置集群的状态。在开发和测试环境中，这可以帮助保持一个干净的状态，以便进行新的部署和测试。在生产环境中，这些命令也应该谨慎使用，以避免意外删除重要的资源。

4.5、Pod中使用ConfigMap

4.5.1、使用ConfigMap替代环境变量

创建了两个ConfigMap资源，并将它们用于Pod的环境变量配置。

创建ConfigMap：

vim env.yaml
apiVersion: v1
kind: ConfigMap
metadata:name: special-confignamespace: default
data:special.how: veryspecial.type: good
---
apiVersion: v1
kind: ConfigMap
metadata:name: env-confignamespace: default
data:log_level: INFOkubectl create -f env.yaml 

创建了一个名为env.yaml的YAML文件，其中定义了两个ConfigMap：special-config和env-config。special-config包含两个键值对，env-config包含一个键值对。然后，使用kubectl create -f env.yaml命令创建了这两个ConfigMap。

查看ConfigMap列表：

kubectl get cmNAME             DATA   AGE
env-config       1      6s
special-config   2      6s

通过kubectl get cm命令，查看了当前命名空间下的ConfigMap列表。可以看到env-config和special-config都已经创建。

4.5.2、创建Pod引用ConfigMap资源：

vim test-pod.yaml
apiVersion: v1
kind: Pod
metadata:name: test-pod
spec:containers:- name: busyboximage: busybox:1.28.4command: [ "/bin/sh", "-c", "env" ]env:- name: SPECIAL_HOW_KEYvalueFrom:configMapKeyRef:name: special-configkey: special.how- name: SPECIAL_TYPE_KEYvalueFrom:configMapKeyRef:name: special-configkey: special.typeenvFrom:- configMapRef:name: env-configrestartPolicy: Never

创建了一个名为test-pod.yaml的YAML文件，定义了一个Pod，其中包含一个容器（使用BusyBox镜像）。在Pod的spec部分，配置了环境变量，其中两个环境变量SPECIAL_HOW_KEY和SPECIAL_TYPE_KEY通过configMapKeyRef引用了special-config ConfigMap中的键。另外，还使用了envFrom字段来引入env-config ConfigMap中的所有环境变量。

应用Pod定义：

kubectl create -f test-pod.yaml

使用kubectl create -f test-pod.yaml命令，根据YAML文件中的定义创建了Pod。

查看Pod状态：

kubectl get pods
NAME         READY   STATUS      RESTARTS   AGE
pod-test     0/1     Completed   0          30s

通过kubectl get pods命令，查看了Pod的状态。可以看到test-pod已经运行完成（状态为Completed），因为Pod中的命令/bin/sh -c "env"执行完毕后没有其他操作，所以Pod完成了。

查看Pod日志：

kubectl logs pod-test

使用kubectl logs pod-test命令，查看了Pod的日志输出。在日志中，可以看到从ConfigMap中引用的环境变量已经被正确地设置，并且它们的值与ConfigMap中定义的值相匹配。

这种方式允许在Pod中动态地使用配置信息，而无需在Pod的镜像中硬编码这些信息。这对于配置管理非常有用，尤其是在需要频繁更改配置的场景中。通过ConfigMap，可以轻松地更新配置，而无需重新创建Pod。

---

4.6、ConfigMap 设置命令行参数

创建了一个名为test-pod2的Pod，该Pod使用ConfigMap中的值作为环境变量，并在容器启动时执行了一个命令来打印这些值。

创建Pod定义文件：

vim test-pod2.yaml
apiVersion: v1
kind: Pod
metadata:name: test-pod2
spec:containers:- name: busyboximage: busybox:1.28.4command: - /bin/sh- -c- echo "$(SPECIAL_HOW_KEY) $(SPECIAL_TYPE_KEY)"env:- name: SPECIAL_HOW_KEYvalueFrom:configMapKeyRef:name: special-configkey: special.how- name: SPECIAL_TYPE_KEYvalueFrom:configMapKeyRef:name: special-configkey: special.typeenvFrom:- configMapRef:name: env-configrestartPolicy: Never

创建了一个名为test-pod2.yaml的YAML文件，定义了一个Pod，其中包含一个容器（使用BusyBox镜像）。在Pod的spec部分，配置了环境变量SPECIAL_HOW_KEY和SPECIAL_TYPE_KEY，它们通过configMapKeyRef引用了special-config ConfigMap中的键。此外，还使用了envFrom字段来引入env-config ConfigMap中的所有环境变量。容器的command字段设置为执行一个echo命令，该命令将打印出这些环境变量的值。

创建Pod：

kubectl create -f test-pod2.yaml

使用kubectl create -f test-pod2.yaml命令，根据YAML文件中的定义创建了Pod。

查看Pod状态：

kubectl get pods

通过kubectl get pods命令，查看了Pod的状态。可以看到test-pod2已经运行完成（状态为Completed），因为Pod中的命令执行完毕后没有其他操作，所以Pod完成了。

查看Pod日志：

kubectl logs test-pod2

使用kubectl logs test-pod2命令，查看了Pod的日志输出。在日志中，可以看到echo命令打印出了从ConfigMap中获取的环境变量的值，即very good。

这种方式展示了如何将ConfigMap用作Pod中命令行参数的来源，这在需要根据配置文件动态执行命令的场景中非常有用。通过这种方式，可以在不修改容器镜像的情况下，灵活地调整Pod的行为。

---

4.7、通过数据卷插件使用ConfigMap

创建一个名为test-pod3的Pod，该Pod使用ConfigMapspecial-config作为数据卷，并将ConfigMap中的键值对作为文件内容挂载到容器的文件系统中。

创建Pod定义文件：

vim test-pod3.yaml
apiVersion: v1
kind: Pod
metadata:name: test-pod3
spec:containers:- name: busyboximage: busybox:1.28.4command: [ "/bin/sh", "-c", "sleep 36000" ]volumeMounts:- name: config-volumemountPath: /etc/configvolumes:- name: config-volumeconfigMap:name: special-configrestartPolicy: Never

创建了一个名为test-pod3.yaml的YAML文件，定义了一个Pod，其中包含一个容器（使用BusyBox镜像）。在Pod的spec部分，配置了一个名为config-volume的数据卷，该数据卷引用了special-config ConfigMap。容器的command字段设置为执行一个sleep命令，以保持Pod运行状态，以便查看数据卷的内容。

创建Pod：

kubectl create -f test-pod3.yaml 

使用kubectl create -f test-pod3.yaml命令，根据YAML文件中的定义创建了Pod。

查看Pod状态：

kubectl get pods

通过kubectl get pods命令，查看了Pod的状态。可以看到test-pod3正在运行（状态为Running）。

进入Pod的容器：

kubectl exec -it test-pod3 sh

使用kubectl exec -it test-pod3 sh命令，进入了Pod的容器内部。

查看数据卷内容：

cd /etc/config/
ls
special.how   special.type
vim special.how 
vim special.type 

在容器内部，使用cd /etc/config/命令切换到挂载的数据卷目录，并使用ls命令列出了目录内容。看到了special.how和special.type两个文件，这些文件名对应于ConfigMap中的键。然后，查看这些文件的内容，它们将显示ConfigMap中对应的值。

通过这种方式，可以将ConfigMap用作容器内部的配置文件，这对于需要在容器启动时读取配置文件的应用非常有用。这种方法允许在不修改容器镜像的情况下，灵活地调整容器的配置。

---

五、ConfigMap 的热更新

演示了ConfigMap的热更新（Hot Update）功能，以及如何通过修改Deployment的注解来触发Pod的滚动更新。

创建ConfigMap和Deployment：

vim test-pod4.yaml
apiVersion: v1
kind: ConfigMap
metadata:name: log-confignamespace: default
data:log_level: INFO
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:name: my-nginx
spec:replicas: 1template:metadata:labels:run: my-nginxspec:containers:- name: my-nginximage: nginxports:- containerPort: 80volumeMounts:- name: config-volumemountPath: /etc/configvolumes:- name: config-volumeconfigMap:name: log-config

创建了一个名为test-pod5.yaml的YAML文件，其中定义了一个ConfigMaplog-config和一个Deploymentmy-nginx。ConfigMap包含一个键值对log_level: INFO，而Deployment定义了一个Nginx容器，该容器挂载了ConfigMap作为数据卷。

应用ConfigMap和Deployment：

kubectl apply -f test-pod5.yaml

使用kubectl apply -f test-pod5.yaml命令，创建了ConfigMap和Deployment。

查看Pod状态：

kubectl get pods 

通过kubectl get pods命令，查看了Pod的状态。可以看到my-nginx的Pod正在运行。

查看ConfigMap的数据：

kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level

使用kubectl exec命令，查看了Pod中挂载的ConfigMap数据卷的内容。初始时，log_level的值为INFO。

编辑ConfigMap：

kubectl edit configmap log-config

使用kubectl edit configmap log-config命令，将ConfigMap中的log_level值从INFO修改为DEBUG。

等待ConfigMap更新：

等大概10秒左右，使用该 ConfigMap 挂载的 Volume 中的数据同步更新 

等待了大约10秒，以便ConfigMap的更新能够同步到挂载的数据卷中。

再次查看ConfigMap的数据：

kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level

再次使用kubectl exec命令，查看了Pod中挂载的ConfigMap数据卷的内容。现在，log_level的值已经更新为DEBUG。

触发Pod的滚动更新：

ConfigMap 更新后滚动更新 Pod
更新 ConfigMap 目前并不会触发相关 Pod 的滚动更新，可以通过在 .spec.template.metadata.annotations 中添加 version/config ，每次通过修改 version/config 来触发滚动更新

kubectl patch deployment my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20210525" }}}}}'

由于直接更新ConfigMap不会自动触发Pod的滚动更新，通过kubectl patch命令修改了Deployment的注解version/config。这导致了Deployment创建了一个新的Pod实例，而旧的Pod被终止。

查看新的Pod状态：

kubectl get pods 

通过再次运行kubectl get pods命令，查看了新Pod的状态。新的Pod已经创建并正在运行。

请注意，ConfigMap的热更新只适用于通过数据卷挂载的配置。如果ConfigMap用于环境变量，那么环境变量的值不会自动更新，因为环境变量在容器启动时就已经被设置。 若要更新环境变量，需要重新启动Pod。通过修改Deployment的注解来触发滚动更新是一种常见的做法，以确保新的配置能够应用到所有Pod实例。 注意：

• 使用该 ConfigMap 挂载的 Env 不会同步更新

• 使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间（实测大概10秒）才能同步更新。