Kubernetes——配置资源管理

目录

一、Secret

1、定义

2、四种Secret类型

3、Pod使用Secret的方式

●作为挂载到一个或多个容器上的卷 中的文件。

●作为容器的环境变量。

●由 kubelet 在为 Pod 拉取镜像时使用。

4、应用场景

5、Secret的实例

①使用kubectl的create命令来指定文件创建Secret

②内容使用base64编码创建Secret

③通过Volume挂载的方式创建Secret

④通过将Secret导出到环境变量

⑤使用Secret配置实现免密交互拉取Harbor私有仓库镜像

⑤-①创建私有仓库的Secret资源

⑤-②引用Secret资源拉取私有仓库镜像创建pod

⑤-③注意

⑥案例

⑥-①数据库凭证管理：

⑥-②API密钥和访问令牌：

⑥-③SSH密钥：

⑥-④TLS证书：

⑥-⑤配置文件加密：

二、ConfigMap——存储配置信息的资源

1、定义

2、用途

3、实例

①创建configmap资源

②文件创建configmap资源

③字面参数创建configmap资源

④pod中使用configmap

⑤configmap设置命令行参数

⑥通过数据卷插件使用configmap

4、configmap热更新

三、总结

1、secret的类型

2、创建secret的方式

①陈述式

②挂载

③环境变量

3、configmap

3.1创建configmap的方式

3.2configmap资源使用

3.3configmap资源的更新

---

一、Secret

1、定义

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

2、四种Secret类型

①opaque 通用类型(可以通过文件 目录、变量创建)默认类型

②kubernetes.io/service-account-token k8s自动创建的给 serviceaccount 服务账号(podza在k8s集群内部的专属服务用户)访问APiserver使用

③kubernetes.io/dockerconfigjson 给k8s 从harbor私有镜像仓库 去镜像认证使用

④kubernetes.io/tls 通过TLS 证书来认证的 (私有文件、秘钥)

3、Pod使用Secret的方式

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

●作为挂载到一个或多个容器上的卷 中的文件。

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

●作为容器的环境变量。

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

●由 kubelet 在为 Pod 拉取镜像时使用。

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

4、应用场景

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

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

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

5、Secret的实例

①使用kubectl的create命令来指定文件创建Secret

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

mkdir /opt/secrets
cd /opt/secrets/
 
echo -n "rmh" > usrname.txt
echo -n "zhenshuai123" > password.txt
 
kubectl create secret generic rmhsecret --from-file=usrname.txt --from-file=password.txt 
#首先创建了两个文本文件，一个包含用户名，另一个包含密码。然后，使用kubectl create secret generic命令创建了一个名为cxksecret的Secret，并指定了这两个文件作为数据源。
 
kubectl get secrets 
 
kubectl describe secrets rmhsecret 
 
#get或describe指令都不会展示secret的实际内容，这是出于对数据的保护的考虑

②内容使用base64编码创建Secret

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

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

[root@master01 secrets]]#vim secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: rmhsecret1
type: Opaque
data:
  username: cm1o
  password: emhlbnNodWFp

 
kubectl create -f secret.yaml 
 
kubectl get secrets
 
kubectl describe secrets rmhsecret1
 
 
#创建了一个名为secret.yaml的文件，其中包含了Secret的定义。在这个文件中，指定了Secret的名称cxksecret1，类型为Opaque，并提供了编码后的用户名和密码。

③通过Volume挂载的方式创建Secret

vim volume-sc.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: "/etc/secrets"
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: rmhsecret
 
#创建了一个名为volume-sc.yaml的YAML文件，定义了一个Pod，其中包含一个容器（使用nginx镜像）。在Pod的spec部分，指定了一个卷secrets，它引用了名为cxksecret的Secret，并将其挂载到容器的/etc/secrets目录。
 
kubectl exec -it mypod sh
 
cd /etc/secrets/
cat password.txt
cat username.txt
#可以查看password.txt和username.txt文件的内容。这些文件包含了在创建Secret时定义的用户名和密码。
 
#请注意，由于在Pod定义中设置了readOnly: true，这意味着Secret卷是以只读模式挂载的，不能修改这些文件。这是处理敏感数据时的一个安全最佳实践。如果需要修改Secret中的数据，应该在Kubernetes集群外部进行，然后更新Secret资源。

④通过将Secret导出到环境变量

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

kubectl describe secrets rmhsecret1 
 
vim env-sc.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: mypod1
spec:
  containers:
  - name: nginx
    image: nginx
    env:
      - name: TEST_USER
        valueFrom:
          secretKeyRef:
            name: rmhsecret1
            key: username
      - name: TEST_PASSWORD
        valueFrom:
          secretKeyRef:
            name: rmhsecret1
            key: password
 
kubectl apply -f env-sc.yaml
 
kubectl get pod
 
kubectl exec -it mypod1 bash
 
root@mypod1:/# echo $TEST_USER
rmh
root@mypod1:/# echo $TEST_PASSWORD
zhenshuai123
root@mypod1:/# env|grep TEST
TEST_USER=rmh
TEST_PASSWORD=zhenshuai123

⑤使用Secret配置实现免密交互拉取Harbor私有仓库镜像

⑤-①创建私有仓库的Secret资源

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

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

kubectl create secret docker-registry myharbor --docker-server 192.168.170.111 \
--docker-username admin --docker-password Harbor12345 --docker-email admin@qq.com

⑤-②引用Secret资源拉取私有仓库镜像创建pod

在创建pod时，你需要在pod的配置中引用上面创建的Secret的名称

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

⑤-③注意

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

如果只是在Pod中指定节点进行测试，可以在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——存储配置信息的资源

1、定义

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

2、用途

• 提供配置信息给Pods，这些信息可以作为环境变量注入到容器中，或者作为文件挂载到容器的文件系统中。
• 存储配置文件，如JSON、YAML、.properties文件等，这些文件可以被容器内的应用程序读取。
• 作为应用程序启动时的参数传递。

3、实例

①创建configmap资源

mkdir /opt/configmap
cd /opt/configmap/
 
vim game.properties
 
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
 
vim ui.properties
 
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
 
ls /opt/configmap/
game.properties
ui.properties
 
kubectl create configmap game-config --from-file=/opt/configmap/
#--from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就是文件的内容
#根据指定目录中的文件创建了ConfigMap。--from-file标志告诉kubectl命令行工具将目录下的所有文件作为ConfigMap中的键值对。每个文件名成为ConfigMap中的一个键，文件内容成为对应的值。
 
 
kubectl get cm
#查看了当前命名空间下的ConfigMap列表。可以看到game-config已经创建。
 
kubectl get cm game-config -o yaml
#以YAML格式查看了game-config的详细信息。这个命令输出了ConfigMap的数据内容，包括game.properties和ui.properties文件的内容。

#使用目录创建Nginx
 
vim nginx.conf
 
kubectl create configmap nginx-config --from-file=nginx.conf
 
kubectl get cm
 
kubectl describe cm nginx-config 

②文件创建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是管理应用配置的一种非常有效的方式，它允许在不修改应用代码的情况下，动态地调整应用的配置。

mkdir rmh
echo "rmh" > rmh/username
echo "he likes money" > rmh/hobby
 
kubectl create configmap rmh-cm --from-file=rmh/
 
#kubectl get cm
 
kubectl describe cm rmh-cm 

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

kubectl create cm mycm --from-literal=name=rmh --from-literal=hobby=skateboarding
 
kubectl get cm
 
kubectl describe cm mycm 

④pod中使用configmap

使用configmap代替环境变量

vim env.yaml
 
apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: good
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config
  namespace: default
data:
  log_level: INFO
 
#创建了一个名为env.yaml的YAML文件，其中定义了两个ConfigMap：special-config和env-config。special-config包含两个键值对，env-config包含一个键值对。然后，使用kubectl create -f env.yaml命令创建了这两个ConfigMap。
 
 
 
 
kubectl create -f env.yaml 
 
 
 
#查看ConfigMap列表
kubectl get cm
 
#通过kubectl get cm命令，查看了当前命名空间下的ConfigMap列表。可以看到env-config和special-config都已经创建

#创建Pod引用ConfigMap资源
 
vim test-pod.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    command: [ "/bin/sh", "-c", "env" ]
    env:
      - name: SPECIAL_HOW_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.how
      - name: SPECIAL_TYPE_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.type
    envFrom:
      - configMapRef:
          name: env-config
  restartPolicy: 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
 
 
kubectl get pods
 
#可以看到test-pod已经运行完成（状态为Completed），因为Pod中的命令/bin/sh -c "env"执行完毕后没有其他操作，所以Pod完成了。

kubectl logs test-pod
 
 
#使用kubectl logs pod-test命令，查看了Pod的日志输出。在日志中，可以看到从ConfigMap中引用的环境变量已经被正确地设置，并且它们的值与ConfigMap中定义的值相匹配。
 
#这种方式允许在Pod中动态地使用配置信息，而无需在Pod的镜像中硬编码这些信息。这对于配置管理非常有用，尤其是在需要频繁更改配置的场景中。通过ConfigMap，可以轻松地更新配置，而无需重新创建Pod。

cp ../secrets/env-sc.yaml ./
mv env-sc.yaml env-configmap.yaml
vim env-configmap.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: mypod2
spec:
  containers:
  - name: nginx
    image: nginx
    env:
      - name: USERNAME
        valueFrom:
          configMapKeyRef:
            name: rmh-cm
            key: username
      - name: HOBBY
        valueFrom:
          configMapKeyRef:
            name: rmh-cm
            key: hobby
 
kubectl apply -f env-configmap.yaml
 
 
kubectl get pod
 
kubectl exec -it mypod1 bash
 
root@mypod1:/# env|grep cxk
USERNAME=cxk
root@mypod1:/# env|grep ctrl 
HOBBY=he likes ctrl
 

⑤configmap设置命令行参数

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

#创建Pod定义文件
 
vim test-pod2.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: test-pod2
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    command: 
    - /bin/sh
    - -c
    - echo "$(SPECIAL_HOW_KEY) $(SPECIAL_TYPE_KEY)"
    env:
      - name: SPECIAL_HOW_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.how
      - name: SPECIAL_TYPE_KEY
        valueFrom:
          configMapKeyRef:
            name: special-config
            key: special.type
    envFrom:
      - configMapRef:
          name: env-config
  restartPolicy: 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
#可以看到test-pod2已经运行完成（状态为Completed），因为Pod中的命令执行完毕后没有其他操作，所以Pod完成了。
 
 
kubectl logs test-pod2
#在日志中，可以看到echo命令打印出了从ConfigMap中获取的环境变量的值，即very good。

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

⑥通过数据卷插件使用configmap

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

#创建Pod定义文件
 
vim test-pod3.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: test-pod3
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    command: [ "/bin/sh", "-c", "sleep 36000" ]
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never
 
 
#创建了一个名为test-pod3.yaml的YAML文件，定义了一个Pod，其中包含一个容器（使用BusyBox镜像）。在Pod的spec部分，配置了一个名为config-volume的数据卷，该数据卷引用了special-config ConfigMap。容器的command字段设置为执行一个sleep命令，以保持Pod运行状态，以便查看数据卷的内容。
 
 
 
kubectl create -f test-pod3.yaml 
 
 
kubectl get pods
 
 
kubectl exec -it test-pod3 sh
 
 
cd /etc/config/
ls
special.how   special.type
cat special.how 
cat special.type 
 
#在容器内部，使用cd /etc/config/命令切换到挂载的数据卷目录，并使用ls命令列出了目录内容。看到了special.how和special.type两个文件，这些文件名对应于ConfigMap中的键。然后，查看这些文件的内容，它们将显示ConfigMap中对应的值。

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

kubectl get cm
 
 
vim index.html
 
<h1> This is rmh </h1>
 
 
kubectl create cm web-rmh --from-file=index.html 
 
kubectl get cm|grep rmh
 
kubectl describe cm web-rmh

cp env-configmap.yaml env-volume-cofigmap.yaml
vim env-volume-cofigmap.yaml 
 
apiVersion: v1
kind: Pod
metadata:
  name: mypod3
spec:
  volumes:
    - name: cm-rmh
      configMap:
        name: web-genshin
  containers:
  - name: mypod3
    image: soscscs/myapp:v1
    ports:
    - containerPort: 80
    volumeMounts:
    - name: cm-rmh
      mountPath: /usr/share/nginx/html
 
kubectl apply -f env-volume-cofigmap.yaml 
 
kubectl get pod -owide
 
curl 10.244.2.213

4、configmap热更新

//ConfigMap 的热更新 
vim test-pod4.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: log-config
  namespace: default
data:
  log_level: INFO
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: log-config


kubectl apply -f test-pod5.yaml

kubectl get pods 
NAME                        READY   STATUS    RESTARTS   AGE
my-nginx-76b6489f44-6dwxh   1/1     Running   0          46s

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

kubectl edit configmap log-config
apiVersion: v1
data:
  log_level: DEBUG		#INFO 修改成 DEBUG
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"log_level":"DEBUG"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"log-config","namespace":"default"}}			#INFO 修改成 DEBUG
  creationTimestamp: 2021-05-25T07:59:18Z
  name: log-config
  namespace: default
  resourceVersion: "93616"
  selfLink: /api/v1/namespaces/default/configmaps/log-config
  uid: 1b8115de-bd2f-11eb-acba-000c29d88bba
  
//等大概10秒左右，使用该 ConfigMap 挂载的 Volume 中的数据同步更新 
kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level
DEBUG

//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" }}}}}'

kubectl get pods 
NAME                        READY   STATUS              RESTARTS   AGE
my-nginx-665dd4dc8c-j4k9t   0/1     ContainerCreating   0          4s
my-nginx-76b6489f44-6dwxh   0/1     Terminating         0          10m

kubectl get pods 
NAME                        READY   STATUS    RESTARTS   AGE
my-nginx-665dd4dc8c-j4k9t   1/1     Running   0          74s


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

如何通过修改Deployment的注解来触发Pod的滚动更新。

#编辑nginx的配置文件，修改端口为8080
 
vim nginx.conf
 
server {
    listen       8080;
    server_name  _;
 
    location / {
        root /usr/share/nginx/html;
        index  index.html index.htm;
    }
}

#通过文件创建configmap，创建的名为nginxconf 的configmap，将刚才创建的nginx.conf作为其内容
kubectl create configmap nginxconf --from-file=nginx.conf
 
kubectl describe cm nginxconf

[root@master01 secrets]]#vim test-pod4.yaml

 
apiVersion: v1
kind: ConfigMap
metadata:
  name: log-config
  namespace: default
data:
  log_level: INFO
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: my-nginx
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: log-config


 
kubectl apply -f nginx.yaml
 
[root@master01 secrets]]#kubectl get pods
[root@master01 secrets]]#kubectl exec -it my-nginx-7b8755d996-n2772 -- cat /etc/config/log_level

kubectl edit configmap log-config
apiVersion: v1
data:
  log_level: DEBUG		#INFO 修改成 DEBUG
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"log_level":"DEBUG"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"log-config","namespace":"default"}}			#INFO 修改成 DEBUG
  creationTimestamp: 2021-05-25T07:59:18Z
  name: log-config
  namespace: default
  resourceVersion: "93616"
  selfLink: /api/v1/namespaces/default/configmaps/log-config
  uid: 1b8115de-bd2f-11eb-acba-000c29d88bba

//等大概10秒左右，使用该 ConfigMap 挂载的 Volume 中的数据同步更新 
kubectl exec -it my-nginx-76b6489f44-6dwxh -- cat /etc/config/log_level
DEBUG

/ConfigMap 更新后滚动更新 Pod

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

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

更新 ConfigMap 后：

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

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

三、总结

1、secret的类型

①Opaque：通用类型（可以通过文件、目录、变量创建）默认类型

②Kubernetes.io/service-account-token：K8S自动创建的给serviceaccount 服务账号（Pod在K8S集群内部的专属服务用户）访问APIServer使用

③Kubernetes.io/dockerconfigjson：给K8S 从Harbor私有镜像仓库，去镜像认证使用的

④Kubernetes.io/tls：通过TLS证书来认证的（私钥文件/密钥）

2、创建secret的方式

①陈述式

Kubectl create Secret generic --from-file =文件 ：指定文件，还可以多次使用，也可以指定多个文件或目录（把目录下所有的文件引用进去）

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

②挂载

volume定义类型secret的存储卷

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

③环境变量

env定义容器的环境变量名

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

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

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

3、configmap

3.1创建configmap的方式

①Kubectl create cm --from-file=文件/目录

②kubectl create cm --from-literal-键值对（key-value）引用

③kubectl describe cm 和 kubectl get cm -o yaml 查看资源中的数据是以明文的格式去显示key的值

3.2configmap资源使用

①容器环境变量的方式

env 需要另外自定义环境变量名，然后通过cm 资源名称 和 key名称来给这个变量赋值
envFrom 不需要另外自定义环境变量名，直接使用cm资源的key 作为容器中的环境变量名，valu作为这个环境变量的值

②用的最多的是挂载方式

Volumes 定义类型为ConfigMap的存储卷
VolumeMounts 把存储卷挂载到容器目录，cm资源数据中的键将以文件的形式，值为文件内容，如果把存储卷挂载到容器中的文件，SubPath指定的文件

3.3configmap资源的更新

• 可以根据ConfigMap挂载的Volume中的数据同步更新，修改当中的配置，会更新策略
• 根据kubectl patch deployment demo-myapp --patch 对应层级和列表的方式来完成热更新