Kubernetes——配置资源管理

目录

一、Secret

1.定义

2.三种Secret类型

3.Pod使用Secret的方式

4.应用场景

5.Secret的实例

5.1使用kubectl create命令指定文件创建Secret

5.2内容使用base64编码创建Secret

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

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

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

5.5.1创建私有仓库的Secret资源

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

5.5.3注意

5.6案例

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

1.定义

2.用途

3.实例

3.1目录创建ConfigMap资源

3.2文件创建ConfigMap资源

3.3字面参数创建ConfigMap资源

3.4Pod中使用ConfigMap

3.5ConfigMap设置命令行参数

3.6通过数据卷插件使用ConfigMap

4.ConfigMap热更新

三、总结

1.Secret类型

2.创建Secret的方式

2.1陈述式

2.2挂载

3.ConfigMap 

3.1创建ConfigMap方式

3.2ConfigMap资源使用

---

一、Secret

1.定义

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

2.三种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才能访问它们。

3.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的配置中直接暴露这些认证信息。

4.应用场景

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

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

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

5.Secret的实例

5.1使用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 "cxk" > usrname.txt
echo -n "abc123" > password.txt

kubectl create secret generic cxksecret --from-file=usrname.txt --from-file=password.txt 
#首先创建了两个文本文件，一个包含用户名，另一个包含密码。然后，使用kubectl create secret generic命令创建了一个名为cxksecret的Secret，并指定了这两个文件作为数据源。

kubectl get secrets 

kubectl describe secrets cxksecret 

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

5.2内容使用base64编码创建Secret

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

echo -n "cxk" | base64
Y3hr

echo -n "abc123" | base64
YWJjMTIz


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

vim secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: cxksecret1
type: Opaque
data:
  username: Y3hr
  password: YWJjMTIz

kubectl create -f secret.yaml 

kubectl get secrets

kubectl describe secrets cxksecret1


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

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

5.3通过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: cxksecret

#创建了一个名为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资源。

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

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

kubectl describe secrets cxksecret1 

vim env-sc.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mypod1
spec:
  containers:
  - name: nginx
    image: nginx
    env:
      - name: TEST_USER
        valueFrom:
          secretKeyRef:
            name: cxksecret1
            key: username
      - name: TEST_PASSWORD
        valueFrom:
          secretKeyRef:
            name: cxksecret1
            key: password

kubectl apply -f env-sc.yaml

kubectl get pod

kubectl exec -it mypod1 bash

root@mypod1:/# echo $TEST_USER
cxk
root@mypod1:/# echo $TEST_PASSWORD
abc123
root@mypod1:/# env|grep TEST
TEST_USER=cxk
TEST_PASSWORD=abc123

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

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

5.5.1创建私有仓库的Secret资源

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

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

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

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

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

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

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

5.5.3注意

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

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

5.6案例

在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.实例

3.1目录创建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 

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

mkdir cxk
echo "cxk" > cxk/username
echo "he likes ctrl" > cxk/hobby

kubectl create configmap cxk-cm --from-file=cxk/

#kubectl get cm

kubectl describe cm cxk-cm 

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

kubectl create cm mycm --from-literal=name=wyb --from-literal=hobby=skateboarding

kubectl get cm

kubectl describe cm mycm 

3.4Pod中使用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: mypod1
spec:
  containers:
  - name: nginx
    image: nginx
    env:
      - name: USERNAME
        valueFrom:
          configMapKeyRef:
            name: cxk-cm
            key: username
      - name: HOBBY
        valueFrom:
          configMapKeyRef:
            name: cxk-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

3.5ConfigMap设置命令行参数

创建了一个名为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的行为。

3.6通过数据卷插件使用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 Genshin </h1>


kubectl create cm web-genshin --from-file=index.html 

kubectl get cm|grep genshin

kubectl describe cm web-genshin 

cp env-configmap.yaml env-volume-cofigmap.yaml
vim env-volume-cofigmap.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: mypod2
spec:
  volumes:
    - name: cm-genshin
      configMap:
        name: web-genshin
  containers:
  - name: mypod2
    image: soscscs/myapp:v1
    ports:
    - containerPort: 80
    volumeMounts:
    - name: cm-genshin
      mountPath: /usr/share/nginx/html

kubectl apply -f env-volume-cofigmap.yaml 

kubectl get pod -owide

curl 10.244.2.213

4.ConfigMap热更新

如何通过修改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

vim nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 1                   
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
          - name: config-volume
            mountPath: /etc/nginx/conf.d
      volumes:
        - name: config-volume
          configMap:
            name: nginxconf

kubectl apply -f nginx.yaml

kubectl get pod -o wide | grep nginx

curl 10.244.2.216:8000

kubectl exec -it my-nginx-6ff87878d7-vpm5z cat /etc/nginx/conf/nginx.conf

访问是8080端口发现失败，但从pod中查询nginx的配置文件，发现已经更改为8080。

上面现象说明configmap热更新已生效，但访问Pod的8080端口是无效的，这时就需要手动触发Pod滚动更新, 这样才能再次加载nginx的配置文件

kubectl patch deployments.apps my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20240602"}}}}}'

更新 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的方式

2.1陈述式

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

2.2挂载

Volume 定义类型Secret 的存储卷

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

2.3环境变量

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 作为容器中的环境变量名，value作为这个环境变量的值
• 用的最多的是挂载方式
• Volumes 定义类型为ConfigMap的存储卷
• VolumeMounts 把存储卷挂载到容器目录，cm资源数据中的键将以文件的形式，值为文件内容，如果把存储卷挂载到容器中的文件，SubPath指定的文件

3.3ConfigMap资源的更新

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