【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 中使用 Con?gMap?

2.3.1使用 Con?gMap 來替代環境變量

2.3.1.1Pod的創建

2.3.2用 Con?gMap 設置命令行參數?

2.3.2通過數據卷插件使用Con?gMap?

2.3.2.1編寫index.html再使用掛載的方式調用

2.4Con?gMap 的熱更新?

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

ConfigMap簡稱CM?

與Secret類似，區別在于ConfigMap保存的是不需要加密配置的信息。
ConfigMap 功能在 Kubernetes1.2 版本中引入，許多應用程序會從配置文件、命令行參數或環境變量中讀取配置信息。Con?gMap API 給我們提供了向容器中注入配置信息的機制，Con?gMap 可以被用來保存單個屬性，也可以用來保存整個配置文件或者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 指定在目錄下的所有文件都會被用在 Con?gMap 里面創建一個鍵值對，鍵的名字就是文件名，值就是文件的內容

使用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使用文件創建?

只要指定為一個文件就可以從單個文件中創建 Con?gMap
--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

只要指定為一個文件就可以從單個文件中創建 Con?gMap

使用單個文件創建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 中使用 Con?gMap?

2.3.1使用 Con?gMap 來替代環境變量

創建了兩個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用 Con?gMap 設置命令行參數?

創建了一個名為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通過數據卷插件使用Con?gMap?

在數據卷里面使用 Con?gMap，就是將文件填入數據卷，在這個文件中，鍵就是文件名，鍵值就是文件內容

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.4Con?gMap 的熱更新?

演示了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.4 ConfigMap簡稱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概念

保存配置文件，環境變量，命令行參數之類的不需要加密的信息，查看時是以明文的顯示內容，他們的數據都是以鍵值對的方式保存