网站开发安卓开发,c 网站开发 pdf,建筑公司网站应该则么做,百度搜索网站提交目录 一、Secret 概念
三种Secret类型
pod三种使用secret的方式
应用场景#xff1a;凭据#xff1a;
二、 示例
2.1、用kubectl create secret命令创建 Secret
创建Secret#xff1a;
查看Secret列表#xff1a;
描述Secret#xff1a;
2.2、用 base64 编码凭据
二、 示例
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 概念
在Kubernetesk8s中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-fileusername.txt --from-filepassword.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
emhhbmdzYW4Kecho -n abc1234 | base64
YWJjMTIzNAo使用echo命令和管道|将用户名和密码通过base64命令进行编码。这样得到了可以安全传输的编码字符串。
创建YAML文件
vim secret.yaml
apiVersion: v1
kind: Secret
metadata:name: mysecret1
type: Opaque
data:username: emhhbmdzYW4Kpassword: 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/secretsreadOnly: 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 adminqq.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
enemiesaliens
lives3
enemies.cheattrue
enemies.cheat.levelnoGoodRotten
secret.code.passphraseUUDDLRLRBABAS
secret.code.allowedtrue
secret.code.lives30vim /opt/configmap/ui.properties
color.goodpurple
color.badyellow
allow.textmodetrue
how.nice.to.lookfairlyNicels /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-literalspecial.howvery --from-literalspecial.typegood使用kubectl create configmap special-config --from-literalspecial.howvery --from-literalspecial.typegood命令创建了一个名为special-config的ConfigMap并在其中设置了两个键值对special.howvery和special.typegood。
查看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文件其中定义了两个ConfigMapspecial-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秒才能同步更新。
