目录
一、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 admin@qq.com
-
引用
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秒)才能同步更新。