【kubernetes】探索k8s集群的配置资源（secret和configma）

本文主要是介绍【kubernetes】探索k8s集群的配置资源（secret和configma），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目录

一、Secret

1.1Secret 有四种类型

1.2Pod 有 3 种方式来使用 secret

1.3应用场景：凭据

1.4创建 Secret

1.4.1用kubectl create secret命令创建Secret

1.4.2内容用 base64 编码，创建Secret

1.4.2.1Base64编码

1.4.2.2创建YAML文件

1.4.2.3创建Secret

1.4.2.4查看Secret列表

1.4.2.5查看Secret详情：

1.5Secret使用方式 

1.5.1将 Secret 挂载到 Volume 中，以 Volume 的形式挂载到 Pod 的某个目录下

1.5.2将 Secret 导出到环境变量中

二、ConfigMap

2.1ConfigMap的主要用途包括：

2.2创建 ConfigMap

2.2.1目录创建ConfigMap资源

2.2.2使用文件创建 

2.2.3使用字面值创建 

删除所有ConfigMap和Pod：

2.2.4导入配置文件方式

2.3Pod 中使用 ConfigMap 

2.3.1使用 ConfigMap 来替代环境变量

2.3.1.1Pod的创建

2.3.2用 ConfigMap 设置命令行参数 

2.3.2通过数据卷插件使用ConfigMap 

2.3.2.1编写index.html再使用挂载的方式调用

2.4ConfigMap 的热更新 

2.5ConfigMap 更新后滚动更新 Pod

三、温故而知新

3.1Secret的4种类型

3.2创建Secret的方式

3.2.1陈述式

3.3secret资源使用

3.4configMap cm

---

一、Secret

Secret 是用来保存密码、token、密钥等敏感数据的 k8s 资源，这类数据虽然也可以存放在 Pod 或者镜像中，但是放在 Secret 中是为了更方便的控制如何使用数据，并减少暴露的风险。

1.1Secret 有四种类型

• kubernetes.io/service-account-token：由 Kubernetes 自动创建，用来访问 APIServer 的 Secret，Pod 会默认使用这个 Secret 与 APIServer 通信， 并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中;
• Opaque ：base64 编码格式的 Secret，用来存储用户自定义的密码、密钥等，默认的 Secret 类型;
• kubernetes.io/dockerconfigjson ：用来存储私有 docker registry 的认证信息
• kubernetes.io/tls ：用来存储 TLS 证书和私钥信息。

1.2Pod 有 3 种方式来使用 secret

Pod 需要先引用才能使用某个 secret，Pod 有 3 种方式来使用 secret：

• 作为挂载到一个或多个容器上的卷 中的文件。
• 作为容器的环境变量。
• 由 kubelet 在为 Pod 拉取镜像时使用。

1.3应用场景：凭据

应用场景：凭据
https://kubernetes.io/docs/concepts/configuration/secret/

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

1.4创建 Secret

1.4.1用kubectl create secret命令创建Secret

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

echo -n "zzz" > username.txt
echo -n "123" > password.txtkubectl create secret generic mysecret --from-file=username.txt --from-file=password.txtkubectl get secretskubectl describe secrets mysecret

get或describe指令都不会展示secret的实际内容，这是出于对数据的保护的考虑

• kubectl create secret generic，它用于在Kubernetes中创建一个通用的密钥。在这个命令中，您创建了一个名为mysecret的密钥，其中包含两个键值对：username.txt和password.txt，这两个键的值将从相应的文件中读取。
• 在运行此命令之前，请确保username.txt和password.txt文件存在，并包含所需的值。

1.4.2内容用 base64 编码，创建Secret

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

echo -n nanjing |base64echo -n 123456|base64

上图只是测试下，下图正式开始

1.4.2.1Base64编码

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

1.4.2.2创建YAML文件

[root@master01 secret]#vim secret.yaml

apiVersion: v1
kind: Secret
metadata:name: mysecret2
type: Opaque
data:username: bmFuamluZw==password: MTIzNDU2

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

1.4.2.3创建Secret

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

kubectl create -f secret.yaml

1.4.2.4查看Secret列表

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

kubectl get secrets

1.4.2.5查看Secret详情：

kubectl get secret mysecret2 -o yaml

1.5Secret使用方式 

1.5.1将 Secret 挂载到 Volume 中，以 Volume 的形式挂载到 Pod 的某个目录下

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

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目录。

kubectl apply -f secret-test.yamlkubectl get podskubectl exec -it mypod sh

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

1.5.2将 Secret 导出到环境变量中

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

apiVersion: v1
kind: Pod
metadata:name: mypod1
spec:containers:- name: nginximage: nginxenv:- name: TEST_USERvalueFrom:secretKeyRef:name: mysecret2key: username- name: TEST_PASSWORDvalueFrom:secretKeyRef:name: mysecret2key: password

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

kubectl apply -f secret-test1.yaml kubectl get podskubectl exec -it mypod1 bash

env也可以查看哦

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

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

查看帮助

kubectl explain pod.spec.containers.env

二、ConfigMap

与Secret类似，区别在于ConfigMap保存的是不需要加密配置的信息。
ConfigMap 功能在 Kubernetes1.2 版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制的对象。

应用场景：如应用的配置参数、数据库连接信息等

2.1ConfigMap的主要用途包括：

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

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

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

2.2创建 ConfigMap

2.2.1目录创建ConfigMap资源

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

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

在该目录下，创建了两个配置文件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中的一个键，文件内容成为对应的值

kubectl get cm

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

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

2.2.2使用文件创建 

只要指定为一个文件就可以从单个文件中创建 ConfigMap
--from-file 这个参数可以使用多次，即可以使用两次分别指定上个实例中的那两个配置文件，效果就跟指定整个目录是一样的

kubectl create configmap game-config-2 --from-file=/opt/configmap/game.properties --from-file=/opt/configmap/ui.propertieskubectl get configmaps game-config-2 -o yamlkubectl describe cm game-config-2

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

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

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

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

2.2.3使用字面值创建 

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

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=good#创建了一个名为special-config的ConfigMap，并在其中设置了两个键值对：special.how=very和special.type=good。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中常用的资源管理操作，它们允许快速地清理和重新设置集群的状态。在开发和测试环境中，这可以帮助保持一个干净的状态，以便进行新的部署和测试。在生产环境中，这些命令也应该谨慎使用，以避免意外删除重要的资源。

2.2.4导入配置文件方式

导入nginx.conf配置文件

导入nginx.conf配置文件kubectl create configmap nginx-config --from-file=nginx.conf取的名字                  配置文件kubectl get cmkubectl describe cm nginx-config   查看nginx-config的详细信息

kubectl create configmap nginx-config -h（不会后面的参数可以使用-h）查看帮助

2.3Pod 中使用 ConfigMap 

2.3.1使用 ConfigMap 来替代环境变量

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

vim env.yamlapiVersion: 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: INFO  #记录信息level(正常级别)日志#创建了一个名为env.yaml的YAML文件，其中定义了两个ConfigMap：special-config和env-config。special-config包含两个键值对，env-config包含一个键值对。然后，使用kubectl create -f env.yaml命令创建了这两个ConfigMap
-----------------------------------------------------------------------------------------kubectl create -f env.yaml   #使用kubectl create -f env.yaml命令创建了这两个ConfigMapkubectl get cm#查看了当前命名空间下的ConfigMap列表。可以看到env-config和special-config都已经创建

2.3.1.1Pod的创建

创建Pod引用ConfigMap资源：

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中的所有环境变量。

kubectl create -f test-pod.yaml
#根据YAML文件中的定义创建了Podkubectl get pods
#查看了Pod的状态kubectl logs test-pod
#查看了Pod的日志输出

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

kubectl logs test-pod

2.3.2用 ConfigMap 设置命令行参数 

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

[root@master01 configmap]#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命令，该命令将打印出这些环境变量的值。

kubectl create -f test-pod2.yaml

kubectl get pods

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

kubectl logs test-pod2

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

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

2.3.2通过数据卷插件使用ConfigMap 

在数据卷里面使用 ConfigMap，就是将文件填入数据卷，在这个文件中，键就是文件名，键值就是文件内容

vim test-pod3.yaml

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

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运行状态，以便查看数据卷的内容。

kubectl apply -f test-pod3.yaml

kubectl get pod|grep test-pod  #过滤查看

查看了Pod的状态。可以看到test-pod3正在运行（状态为Runninv

kubectl exec -it test-pod3 sh

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

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

示例2：

2.3.2.1编写index.html再使用挂载的方式调用

vim index.html
<h1> 端午想去哪里游在知识的海洋里遨游</h1>   #<h1>加大字体kubectl create cm duanwu --from-file=index.htmlkubectl get cm

kubectl describe cm duanwu   #查看详细信息,这里duanwu是自定义的名字

挂载的方式进行调用

vim duanwu.yaml

apiVersion: v1
kind: Pod
metadata:name: mypod-cm-weblabels:run: myapp-cm-web
spec:volumes:- name: web-cmconfigMap:name: duanwucontainers:- name: myapp-cm-webimage: soscscs/myapp:v1ports:- containerPort: 80volumeMounts:- name: web-cmmountPath: /usr/share/nginx/html

kubectl apply -f duanwu.yamlkubectl get pod -owidecurl 10.244.1.9

2.4ConfigMap 的热更新 

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

vim test-pod4.yaml

apiVersion: v1
kind: ConfigMap
metadata:name: log-confignamespace: default
data:log_level: INFO
---
apiVersion: apps/v1
kind: Deployment
metadata:name: my-nginx
spec:replicas: 1selector:matchLabels:app: my-nginxtemplate:metadata:labels:app: my-nginxspec:containers:- name: my-nginximage: nginxports:- containerPort: 80volumeMounts:- name: config-volumemountPath: /etc/configvolumes:- name: config-volumeconfigMap:name: log-config

这段YAML文件描述了一个Kubernetes配置，其中包含一个ConfigMap和一个Deployment。

• ConfigMap部分定义了一个名为"log-config"的ConfigMap，它位于"default"命名空间中，并包含一个名为"log_level"的数据项，其值为"INFO"。ConfigMap用于存储应用程序的配置信息，可以在容器中挂载并使用。
• Deployment部分定义了一个名为"my-nginx"的Deployment，它使用了Nginx镜像，并指定了一个副本。在Deployment的Pod模板中，容器名为"my-nginx"，映射了容器端口80，并且挂载了一个名为"config-volume"的卷到容器的"/etc/config"路径下。这个卷使用了之前定义的"log-config" ConfigMap。

这样，当Deployment创建Pod时，Pod中的Nginx容器将挂载ConfigMap中的"log-config"配置到容器的"/etc/config"路径下，使得Nginx容器可以读取并使用"log_level"配置项的值。

kubectl apply -f test-pod4.yaml

kubectl get pods

kubectl exec -it my-nginx-c6df7db54-b7nlp -- cat /etc/config/log_level#查看了Pod中挂载的ConfigMap数据卷的内容。初始时，log_level的值为INFO。

kubectl edit configmaps log-config

将ConfigMap中的log_level值从INFO修改为DEBUG

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

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

kubectl exec -it my-nginx-c6df7db54-b7nlp -- cat /etc/config/log_level#等待了大约10秒，以便ConfigMap的更新能够同步到挂载的数据卷中

查看了Pod中挂载的ConfigMap数据卷的内容。现在，log_level的值已经更新为DEBUG

2.5ConfigMap 更新后滚动更新 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被终止。​

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

kubectl get pods 

查看了新Pod的状态，新的Pod已经创建并正在运行

😎😎😎

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

更新 ConfigMap 后：😎😎😎

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

三、温故而知新

3.1Secret的4种类型

• Opaque：通用类型（可以通过文件、目录、变量创建）默认类型
• Kubernetes.io/service-account-token：K8S自动创建的给serviceaccount 服务账号（Pod在K8S集群内部的专属服务用户）访问APIServer使用
• Kubernetes.io/dockerconfigjson：给K8S 从Harbor私有镜像仓库，去镜像认证使用的
• Kubernetes.io/tls：通过TLS证书来认证的（私钥文件/密钥）

3.2创建Secret的方式

3.2.1陈述式

Kubectl create Secret generic --from-file =文件  指定文件名 

#还可以多次使用，也可以指定多个文件或目录（把目录下所有的文件引用进去）

kubectl create Secret generic  --from-file=键值对（key-value）引用一个键值对，也可以多次使用

3.3secret资源使用

• 挂载的方式

Volume 定义类型Secret 的存储卷

VolumeMounts 把存储卷挂载到容器目录，Secret资源数据中的键，将以文件名的形式显示，值是文件里的内容

• 容器的环境量的方式

env 定义容器的环境变量名

使用valueFrom.SecretKeyRef.name 指定Secret资源的名称

valueFrom.SecretKeyRef.name指定这个Secret资源数据的键名，从而确定引用哪个键的值

• K8S从Harbor私有仓库拉取镜像时使用

imagePullSecret指定Kubernetes.io/dockerconfigjson类型的Secret来作为连接私有仓库的认证信息

3.4configMap cm

（1）创建 cm 资源

kubectl create cm --from-flie=文件/目录--from-literal=KEY=VALUE#查看资源中的数据都是以明文的格式显示key的值
kubectl describe cm 或者kubectl get cm -o yaml

（2）cm资源使用

容器环境变量的方式

env：需要另外自定义环境变量名，通过指定的cm资源名称和key，名称来给这个变量来赋值

envFrom：不需要另外自定义环境变量名，直接是要cm资源的key作为容器中的环境变量名，value作为这个环境变量的值

（3）挂载的方式

volume 定义类型，configMap的存储卷

volumeMounts：把存储卷挂载到容器目录，cm资源数据中的键将以文件名的形式显示，值为文件内容，如果把存储卷挂载成容器中的文件，subPath指定文件名

（4）cm资源热更新

更新，资源的数据，可以同步更新，通过volume挂载的使用cm配置的pod资源中的配置，如果使用env或envFrom方式引用cm资源，则不会同步更新pod资源中的配置

（5）secret概念

保存密码，密钥文件，token字符串之类的敏感数据

通过kubectl describe 或者kubectl get -oyaml查看是看不到实际的内容，内容是通过bases 64编码格式

（6）configMap概念

保存配置文件，环境变量，命令行参数之类的不需要加密的信息，查看时是以明文的显示内容，他们的数据都是以 键值对 的方式保存

这篇关于【kubernetes】探索k8s集群的配置资源（secret和configma）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---