k8s資料儲存

目錄

• 一、引言
• 二、基本儲存
  • 1、EmptyDir
    • 1.1、示例
    • 1.2、建立資源清單
    • 1.3、建立Pod
    • 1.4、檢視Pod
    • 1.5、透過PodIP訪問nginx
    • 1.6、檢視容器的標準輸出
  • 2、HostPath
    • 2.1、建立資源清單
    • 2.2、.spec.volumes[*].hostPath.type
    • 2.3、建立Pod
    • 2.4、檢視Pod
    • 2.5、透過PodIP訪問nginx
    • 2.6、到host的/root/logs目錄下檢視儲存的檔案
    • 2.7、host下建立檔案觀察容器內部變化
    • 2.8、刪除Pod觀察host本地檔案是否存在
  • 3、NFS
    • 3.1、準備NFS伺服器
      • 3.1.1、master節點安裝nfs服務
      • 3.1.2、準備一個共享目錄
      • 3.1.3、將共享目錄以讀寫許可權暴露給同一網段中的所有主機
      • 3.1.4、啟動nfs服務
    • 3.2、每個節點安裝nfs
    • 3.3、編寫資源清單
    • 3.4、建立Pod
    • 3.5、檢視Pod
    • 3.6、透過PodIP訪問nginx
    • 3.7、檢視nfs伺服器的共享目錄
• 三、高階儲存
  • 1、引言
  • 2、PV
    • 2.1、資源清單
    • 2.2、欄位解釋
    • 2.3、核心概念
      • 2.3.1、訪問模式（accessModes）
      • 2.3.2、回收策略（persistentVolumeReclaimPolicy）
      • 2.3.3、狀態
    • 2.4、使用NFS作為儲存，演示PV的使用
      • 2.4.1、準備NFS環境
      • 2.4.2、編寫資源清單
      • 2.4.3、建立PV
      • 2.4.4、檢視PV
  • 3、PVC
    • 3.1、資源清單
    • 3.2、欄位解釋
    • 3.3、示例
      • 3.3.1、編寫PVC資源清單，申請PV
      • 3.3.2、建立PVC
      • 3.3.3、檢視PVC
      • 3.3.4、檢視PV
      • 3.3.5、編寫Pod資源清單，使用PVC
      • 3.3.6、建立Pod
      • 3.3.7、檢視Pod，PVC，PV
      • 3.3.8、檢視nfs中的檔案儲存
      • 3.3.9、刪除pod和pvc，檢視pv狀態
    • 3.4、生命週期
• 四、配置儲存
  • 1、ConfigMap
    • 1.1、資源清單
    • 1.2、欄位解釋
    • 1.3、使用場景
      • 1.3.1、作為環境變數
      • 1.3.2、掛載為檔案
      • 1.3.3、掛載為 Volume 中的檔案
    • 1.4、示例
      • 1.4.1、編寫configmap資源清單
      • 1.4.2、建立ConfigMap
      • 1.4.3、檢視ConfigMap詳細資訊
      • 1.4.4、編寫pod-configmap.yaml，將建立的configmap掛載進去
      • 1.4.5、建立Pod，並進入容器檢視
      • 1.4.6、線上修改configmap的內容，檢視容器中變化
  • 2、Secret
    • 2.1、Secret的型別
    • 2.2、示例
      • 2.2.1、使用base64對資料進行編碼
      • 2.2.2、編寫Secret資源清單並建立Secret
      • 2.2.3、檢視secret詳情
      • 2.2.4、建立Pod，將上面建立的Secret掛載上去
      • 2.2.5、進入容器檢視Secret資訊

一、引言

容器的生命週期可能很短，會被頻繁地建立和銷燬。容器在銷燬時，儲存在容器中的資料也會被清除。這種結果對使用者來說，在某些情況下是不樂意看到的。為了持久化儲存容器的資料，kubernetes引入了Volume的概念。

Volume是Pod中能夠被多個container訪問的共享目錄。它被定義在Pod上，然後被一個Pod裡的多個容器掛載到具體的檔案目錄下。Kubernetes透過Volume實現：

1. 同一個Pod中不同容器之間的資料共享
2. 資料的持久化儲存。

Volume的生命週期不與Pod中單個container的生命週期相關聯。當container終止或重啟時，Volume中的資料也不會丟失。

Kubernetes的Volume支援多種型別，常見的有：

• 簡單儲存：EmptyDir、HostPath、NFS
• 高階儲存：PV、PVC
• 配置儲存：ConfigMap、Secret

二、基本儲存

1、EmptyDir

最基礎的Volume型別，一個EmptyDir就是Host上的一個空目錄。

EmptyDir是在Pod分配到Node時建立的，它的初始內容為空，並且無需指定宿主機上對應的目錄檔案，因為kubernetes會自動分配一個目錄。當Pod銷燬時，EmptyDir中的資料也會被永久刪除。EmptyDir用途為：

• 臨時空間，例如用於某些應用程式執行時所需的臨時目錄，且無需永久保留
• 一個容器需要從另一個容器中獲取資料的目錄（多容器共享目錄）
• 快取空間，例如基於磁碟的歸併排序。
• 為耗時較長的計算任務提供檢查點，以便任務能方便地從崩潰前狀態恢復執行。
• 在 Web 伺服器容器服務資料時，儲存內容管理器容器獲取的檔案。

1.1、示例

下面演示一個示例：在一個Pod中準備2個容器：nginx和busybox，然後宣告一個Volume分別掛在2個容器的目錄中。Nginx負責向Volume中寫日誌，busybox中透過命令將日誌內容讀到控制檯。

如下圖所示：

1.2、建立資源清單

volume-emptydir.yaml

apiVersion: v1
kind: Pod
metadata:
   name: volume-emptydir
   namespace: default
spec:
   containers:
   - name: nginx
     image: nginx:1.17.1
     ports:
     - containerPort: 80
     volumeMounts:
     - name: logs-volume
       mountPath: /var/log/nginx
   - name: busybox
     image: busybox:1.30
     command: ["/bin/sh", "-c", "tail -f /logs/access.log"]
     volumeMounts:
     - name: logs-volume
       mountPath: /logs
   volumes:
   - name: logs-volume
     emptyDir: {}

1.3、建立Pod

kubectl apply -f volume-emptydir.yaml

1.4、檢視Pod

kubectl get pods -o wide

1.5、透過PodIP訪問nginx

curl 10.244.2.10

1.6、檢視容器的標準輸出

kubectl logs -f volume-emptydir -n default -c busybox

2、HostPath

上面EmptyDir提到，EmptyDir中資料不會被持久化，它會隨著Pod的結束而銷燬，如果想簡單的將資料持久化到主機中，可以選擇HostPath。

HostPath就是將Node主機中一個實際目錄掛在到Pod中，以供容器使用，這樣的設計就可以保證Pod銷燬了，但是資料依據可以存在於Node主機上。

2.1、建立資源清單

volume-hostpath.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-hostpath
  namespace: default
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      ports:
        - containerPort: 80
      volumeMounts:
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      command: [ "/bin/sh","-c","tail -f /logs/access.log" ]
      volumeMounts:
        - name: logs-volume
          mountPath: /logs
  volumes:
    - name: logs-volume
      hostPath:
        path: /root/logs
        type: DirectoryOrCreate  # 目錄存在就使用，不存在就先建立後使用

2.2、.spec.volumes[*].hostPath.type

關於type型別的說明：

型別	說明
DirectoryOrCreate	目錄存在就使用，不存在就先建立
Directory	目錄必須存在
FileOrCreate	檔案存在就使用，不存在就先建立
File	檔案必須存在
Socket	unix套接字必須存在
CharDevice	字元裝置必須存在
BlockDevice	塊裝置必須存在

2.3、建立Pod

kubectl apply -f volume-hostpath.yaml

2.4、檢視Pod

kubectl get pods -n default -o wide

2.5、透過PodIP訪問nginx

curl 10.244.1.9

2.6、到host的/root/logs目錄下檢視儲存的檔案

下面的操作需要到Pod所在的節點執行（案例中是k8s-node1）

tail -f /root/logs/access.log

2.7、host下建立檔案觀察容器內部變化

echo "hello HostPath" > test

在host本地建立檔案驗證同步

分別進入nginx和busybox容器檢視

2.8、刪除Pod觀察host本地檔案是否存在

kubectl delete pods volume-hostpath -n default

3、NFS

HostPath可以解決資料持久化的問題，但是一旦Node節點故障了，Pod如果轉移到了別的節點，又會出現問題了（會有新的hostpath volume在別的Node建立，但是原來的資料丟失了），此時需要準備單獨的網路儲存系統，比較常用的用NFS、CIFS。
NFS是一個網路檔案儲存系統，可以搭建一臺NFS伺服器，然後將Pod中的儲存直接連線到NFS系統上，這樣的話，無論Pod在節點上怎麼轉移，只要Node跟NFS的對接沒問題，資料就可以成功訪問。

3.1、準備NFS伺服器

3.1.1、master節點安裝nfs服務

master節點做nfs伺服器

yum install -y nfs-utils

3.1.2、準備一個共享目錄

mkdir -pv /root/data/nfs

3.1.3、將共享目錄以讀寫許可權暴露給同一網段中的所有主機

echo "/root/data/nfs 192.168.112.0/24(rw,sync,no_subtree_check)" >> /etc/exports

3.1.4、啟動nfs服務

systemctl start nfs && systemctl enable nfs

3.2、每個節點安裝nfs

不需要啟動

yum install -y nfs-utils

3.3、編寫資源清單

volume-nfs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: volume-nfs
  namespace: default
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      ports:
        - containerPort: 80
      volumeMounts:
        - name: logs-volume
          mountPath: /var/log/nginx
    - name: busybox
      image: busybox:1.30
      command: [ "/bin/sh","-c","tail -f /logs/access.log" ]
      volumeMounts:
        - name: logs-volume
          mountPath: /logs
  volumes:
    - name: logs-volume
      nfs:
        server: 192.168.112.10  #nfs伺服器地址
        path: /root/data/nfs #共享檔案路徑

3.4、建立Pod

kubectl apply -f volume-nfs.yaml

3.5、檢視Pod

kubectl get pods -o wide

3.6、透過PodIP訪問nginx

curl 10.244.2.3

3.7、檢視nfs伺服器的共享目錄

cd /root/data/nfs && ls

cat access.log

三、高階儲存

1、引言

為了能夠遮蔽底層儲存實現的細節，方便使用者使用，kubernetes引入了PV和PVC兩種資源物件。

持久卷（PersistentVolume，PV）是叢集中由管理員配置的一段網路儲存。它是叢集中的資源，就像節點是叢集資源一樣。一般情況下PV由kubernetes管理員進行建立和配置，它與底層具體的共享儲存技術有關。PV持久卷和普通的Volume一樣，也是使用卷外掛來實現的，只是它們擁有獨立於任何使用PV的Pod的生命週期。此API物件捕獲儲存實現的詳細資訊，包括NFS，iSCSI或特定於雲提供程式的儲存系統。

持久卷申領（PersistentVolumeClaim，PVC）表達的是使用者對儲存的請求。概念上與Pod類似。Pod會耗用節點資源，而PVC申領會耗用PV資源。Pod可以請求特定數量的資源（CPU 和記憶體）；同樣 PVC 申領也可以請求特定的大小和訪問模式 。

對於使用者來說，只提儲存需求（PVC），專業的具體儲存配置細節（PV）由管理員完成。

使用了PV和PVC後，工作可以進一步細分：

• 儲存：儲存工程師維護
• PV：kubernetes管理員維護
• PVC：kubernetes使用者維護

2、PV

PV是儲存資源的抽象

2.1、資源清單

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-storage
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /nfs/data
    server: nfs-server.example.com

2.2、欄位解釋

• apiVersion: Kubernetes API 版本，這裡是 v1。
• kind: 資源型別，這裡是 PersistentVolume。
• metadata: PV 的後設資料，包括名稱。
• spec: PV 的具體規格。
  • capacity: PV 的容量大小。
  • volumeMode: PV 的模式，這裡為 Filesystem 表示這是一個檔案系統型別的 PV。
  • accessModes: PV 的訪問模式列表。
  • persistentVolumeReclaimPolicy: 當 PV 不再被任何 PVC 使用時的回收策略。
  • storageClassName: PV 所屬的儲存類名稱，可以為空表示無類。
  • mountOptions: NFS 掛載選項。
  • nfs: NFS 具體配置。
  • path: 在 NFS 伺服器上的路徑。
  • server: NFS 伺服器的地址

2.3、核心概念

2.3.1、訪問模式（accessModes）

用於描述使用者應用對儲存資源的訪問許可權，訪問許可權包括

• ReadWriteOnce（RWO）：只僅允許單個節點以讀寫方式掛載
• ReadOnlyMany（ROX）：可以被許多節點以只讀方式掛載
• ReadWriteMany（RWX）：可以被許多節點以只讀方式掛載
• ReadWriteOncePod（RWOP k8s v1.29）：卷可以被單個 Pod 以讀寫方式掛載。

2.3.2、回收策略（persistentVolumeReclaimPolicy）

• Retain：保留，該策略允許手動回收資源，當刪除PVC時，PV仍然存在，PV被視為已釋放，管理員可以手動回收卷。
• Delete：刪除，如果Volume外掛支援，刪除PVC時會同時刪除PV，動態卷預設為Delete，目前支援Delete的儲存後端包括AWS EBS，GCE PD，Azure Disk，OpenStack Cinder等。
• Recycle：回收，如果Volume外掛支援，Recycle策略會對卷執行rm -rf清理該PV，並使其可用於下一個新的PVC，但是本策略將來會被棄用，目前只有NFS和HostPath支援該策略。

2.3.3、狀態

• Available，表示pv已經建立正常，處於可用狀態；
• Bound，表示pv已經被某個pvc繫結，注意，一個pv一旦被某個pvc繫結，那麼該pvc就獨佔該pv，其他pvc不能再與該pv繫結；
• Released，表示pvc被刪除了，pv狀態就會變成已釋放；
• Failed，表示pv的自動回收失敗；

2.4、使用NFS作為儲存，演示PV的使用

2.4.1、準備NFS環境

• 建立目錄

mkdir -pv /root/data/pv{1..3}

• 暴露服務

echo -e "/root/data/pv1\t192.168.112.0/24(rw,no_root_squash)\n/root/data/pv2\t192.168.112.0/24(rw,no_root_squash)\n/root/data/pv3\t192.168.112.0/24(rw,no_root_squash)" > /root/data/nfs_exports

• 重啟nfs服務

systemctl restart nfs

2.4.2、編寫資源清單

pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv1
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv1
    server: 192.168.112.10

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv2
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv2
    server: 192.168.112.10

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name:  pv3
spec:
  capacity:
    storage: 3Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /root/data/pv3
    server: 192.168.112.10

2.4.3、建立PV

kubectl apply -f pv.yaml

2.4.4、檢視PV

kubectl get pv -o wide

3、PVC

PVC作為使用者對儲存資源的需求申請,主要包括儲存空間請求、訪問模式、PV選擇條件和儲存類別等資訊的設定。

3.1、資源清單

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

3.2、欄位解釋

• apiVersion: Kubernetes API 版本，這裡是 v1。

• kind: 資源型別，這裡是 PersistentVolumeClaim。

• metadata:

  • name: PVC 的名稱，這裡是 myclaim。

• spec: PVC 的具體規格。

  • accessModes: PVC 請求的訪問模式列表。這裡請求的是 ReadWriteOnce，意味著 PVC 只能被單個節點以讀寫方式掛

  • volumeMode: PVC 請求的 PV 的模式，這裡為 Filesystem 表示這是一個檔案系統型別的 PV。

  • resources:

    • requests: PVC 請求的資源量，這裡是 storage: 8Gi，即請求 8GiB 的儲存空間。

  • storageClassName: PVC 請求的儲存類名稱，這裡是 slow。如果未指定，則使用預設儲存類。

  • selector: PVC 可以選擇特定的 PV。如果指定，PVC 只能繫結到符合這些選擇器條件的 PV。

    • matchLabels: 標籤選擇器。這裡的 PVC 將僅繫結到帶有標籤 release: stable 的 PV。
    • matchExpressions: 表示式選擇器。這裡的 PVC 將僅繫結到帶有標籤 environment 並且值為 dev 的 PV。

3.3、示例

3.3.1、編寫PVC資源清單，申請PV

pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc2
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 3Gi

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc3
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

3.3.2、建立PVC

kubectl applpy -f pvc.yaml

3.3.3、檢視PVC

kubectl get pvc -o wide

3.3.4、檢視PV

kubectl get pv -o wide

3.3.5、編寫Pod資源清單，使用PVC

pods.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  namespace: default
spec:
  containers:
    - name: busybox
      image: busybox:1.30
      command: [ "/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;" ]
      volumeMounts:
        - name: volume
          mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc1
        readOnly: false
---
apiVersion: v1
kind: Pod
metadata:
  name: pod2
  namespace: default
spec:
  containers:
    - name: busybox
      image: busybox:1.30
      command: [ "/bin/sh","-c","while true;do echo pod2 >> /root/out.txt; sleep 10; done;" ]
      volumeMounts:
        - name: volume
          mountPath: /root/
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: pvc2
        readOnly: false

3.3.6、建立Pod

kubectl apply -f pods.yaml

3.3.7、檢視Pod，PVC，PV

kubectl get pods，pvc,pv -o wide

3.3.8、檢視nfs中的檔案儲存

cat /root/data/pv1/out.txt
cat /root/data/pv2/out.txt
cat /root/data/pv3/out.txt

/root/data/pv1/out.txt

/root/data/pv2/out.txt

/root/data/pv3/out.txt

Pod1 使用了 PVC1，PVC1 繫結了 PV1。因此，Pod1 寫入的檔案位於 /root/data/pv1/out.txt。
Pod2 使用了 PVC2，PVC2 繫結了 PV3。因此，Pod2 寫入的檔案位於 /root/data/pv3/out.txt。
PV2 未被使用，因此 /root/data/pv2/out.txt 檔案不存在。

3.3.9、刪除pod和pvc，檢視pv狀態

kubectl delete -f pods.yaml

kubectl delete -f pvc.yaml

kubectl get pv -o wide

3.4、生命週期

PVC和PV是一一對應的，PV和PVC之間的相互作用遵循以下生命週期

1、資源供應：管理員手動建立底層儲存和PV

2、資源繫結：使用者建立PVC，kubernetes負責根據PVC的宣告去尋找PV，並繫結在使用者定義好PVC之後，系統將根據PVC對儲存資源的請求在已存在的PV中選擇一個滿足條件的

• 一旦找到，就將該PV與使用者定義的PVC進行繫結，使用者的應用就可以使用這個PVC了。PV一旦繫結到某個PVC上，就會被這個PVC獨佔，不能再與其他PVC進行繫結了

• 如果找不到，PVC則會無限期處於Pending狀態，直到等到系統管理員建立了一個符合其要求的PV

3、資源使用：使用者可在pod中像volume一樣使用pvc

Pod使用Volume的定義，將PVC掛載到容器內的某個路徑進行使用。

4、資源釋放：使用者刪除pvc來釋放pv

當儲存資源使用完畢後，使用者可以刪除PVC，與該PVC繫結的PV將會被標記為“已釋放”，但還不能立刻與其他PVC進行繫結。透過之前PVC寫入的資料可能還被留在儲存裝置上，只有在清除之後該PV才能再次使用。

5、資源回收：kubernetes根據pv設定的回收策略進行資源的回收

對於PV，管理員可以設定回收策略，用於設定與之繫結的PVC釋放資源之後如何處理遺留資料的問題。只有PV的儲存空間完成回收，才能供新的PVC繫結和使用

四、配置儲存

1、ConfigMap

ConfigMap 是 Kubernetes 中的一種 API 物件，用於儲存非敏感的配置資料。它允許開發者將配置資料與應用程式容器分離，從而使得配置可以在不重新構建容器映象的情況下進行更改。ConfigMap 可以儲存簡單的鍵值對或者一組檔案，並且可以透過多種方式被應用程式容器訪問。

1.1、資源清單

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # 類屬性鍵；每一個鍵都對映到一個簡單的值
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

  # 類檔案鍵
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true    

1.2、欄位解釋

apiVersion: v1

• 說明: 指定 ConfigMap 的 API 版本。在這個例子中，我們使用的是 Kubernetes API 的第一個版本。

kind: ConfigMap

• 說明: 指定此資源的型別為 ConfigMap。

metadata:

• 說明: 包含後設資料資訊，比如名稱。
  • name: game-demo
    • 說明: ConfigMap 的名稱。在同一個名稱空間內必須唯一。

data:

• 說明: 儲存配置資料的部分，支援鍵值對的形式。
  • player_initial_lives: "3"
    • 說明: 一個鍵值對，鍵為 player_initial_lives，值為 "3"。這個鍵值對錶示玩家初始的生命值為 3。
  • ui_properties_file_name: "user-interface.properties"
    • 說明: 一個鍵值對，鍵為 ui_properties_file_name，值為 "user-interface.properties"。這個鍵值對錶示 UI 屬性檔案的名稱。
  • game.properties: |
    • 說明: 一個多行配置檔案的示例。這裡使用了 YAML 的|符號來表示一個塊文字（block text），允許你直接嵌入多行文字而不必使用換行符。
      • enemy.types=aliens,monsters
        • 說明: 表示敵人型別為外星人和怪物。
      • player.maximum-lives=5
        • 說明: 表示玩家的最大生命值為 5。
  • user-interface.properties: |
    • 說明: 另一個多行配置檔案的示例。
      • color.good=purple
        • 說明: 表示好的顏色為紫色。
      • color.bad=yellow
        • 說明: 表示壞的顏色為黃色。
      • allow.textmode=true
        • 說明: 表示是否允許文字模式。

1.3、使用場景

官方示例的 ConfigMap 可以透過多種方式被 Pod 使用

1.3.1、作為環境變數

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: PLAYER_INITIAL_LIVES
      valueFrom:
        configMapKeyRef:
          name: game-demo
          key: player_initial_lives
    - name: UI_PROPERTIES_FILE_NAME
      valueFrom:
        configMapKeyRef:
          name: game-demo
          key: ui_properties_file_name

1.3.2、掛載為檔案

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: config-volume
      mountPath: /etc/game-demo
    volumes:
    - name: config-volume
      configMap:
        name: game-demo

1.3.3、掛載為 Volume 中的檔案

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    volumeMounts:
    - name: config-volume
      mountPath: /etc/game-demo
    volumes:
    - name: config-volume
      configMap:
        name: game-demo
        items:
        - key: player_initial_lives
          path: player_initial_lives.properties
        - key: ui_properties_file_name
          path: ui_properties_file_name.properties
        - key: game.properties
          path: game.properties
        - key: user-interface.properties
          path: user-interface.properties

1.4、示例

1.4.1、編寫configmap資源清單

apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap
  namespace: default
data: # info是key，後面的都是value
  info: | # | 代表保留換行符
    username:admin
    password:123456

1.4.2、建立ConfigMap

kubectl apply -f configmap.yaml

1.4.3、檢視ConfigMap詳細資訊

kubectl describe configmap configmap

1.4.4、編寫pod-configmap.yaml，將建立的configmap掛載進去

apiVersion: v1
kind: Pod
metadata:
  name: pod-configmap
  namespace: default
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    volumeMounts: # 將configmap掛載到目錄
    - name: config
      mountPath: /configmap/config
  volumes: # 引用configmap
  - name: config
    configMap:
      name: configmap # 注意這裡的name就是上面建立好的configmap

1.4.5、建立Pod，並進入容器檢視

kubectl apply -f pod-configmap.yaml

kubectl exec -it pod-configmap -c nginx /bin/bash

cd configmap/config/ && ls && cat info

可以看到對映已經成功，每個configmap都對映成了一個目錄

key--->檔案 value---->檔案中的內容

1.4.6、線上修改configmap的內容，檢視容器中變化

kubectl edit configmap configmap

kubectl exec -it pod-configmap -c nginx /bin/bash

cd configmap/config/ && ls && cat change info

kubectl edit 線上修改ConfigMap

進入到容器檢視內容變化

2、Secret

在kubernetes中，還存在一種和ConfigMap非常類似的物件，稱為Secret物件。用於儲存敏感資訊，如密碼、金鑰和其他機密資料。Secret 的設計目的是為了安全地管理這些敏感資訊，避免它們被硬編碼到配置檔案或原始碼中。

2.1、Secret的型別

建立 Secret 時，你可以使用 Secret 資源的 type 欄位，或者與其等價的 kubectl 命令列引數（如果有的話）為其設定型別。 Secret 型別有助於對 Secret 資料進行程式設計處理。

Kubernetes 提供若干種內建的型別，用於一些常見的使用場景。 針對這些型別，Kubernetes 所執行的合法性檢查操作以及對其所實施的限制各不相同。

內建型別	用法
Opaque	使用者定義的任意資料
kubernetes.io/service-account-token	服務賬號令牌
kubernetes.io/dockercfg	~/.dockercfg 檔案的序列化形式
kubernetes.io/dockerconfigjson	~/.docker/config.json 檔案的序列化形式
kubernetes.io/basic-auth	用於基本身份認證的憑據
kubernetes.io/ssh-auth	用於 SSH 身份認證的憑據
kubernetes.io/tls	用於 TLS 客戶端或者伺服器端的資料
bootstrap.kubernetes.io/token	啟動引導令牌資料

透過為 Secret 物件的 type 欄位設定一個非空的字串值，你也可以定義並使用自己 Secret 型別（如果 type 值為空字串，則被視為 Opaque 型別）。

Kubernetes 並不對型別的名稱作任何限制。不過，如果你要使用內建型別之一， 則你必須滿足為該型別所定義的所有要求。

如果你要定義一種公開使用的 Secret 型別，請遵守 Secret 型別的約定和結構， 在型別名前面新增域名，並用 / 隔開。 例如：cloud-hosting.example.net/cloud-api-credentials。

2.2、示例

2.2.1、使用base64對資料進行編碼

echo -n 'root' | base64

echo -n 'zhangsan' | base64

在建立 Kubernetes Secret 時，使用 -n 引數可以確保 base64 編碼的字串不會包含不必要的換行符，因為換行符可能會導致 base64 編碼的結果不正確。

2.2.2、編寫Secret資源清單並建立Secret

secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: default
type: Opaque
data:
  username: cm9vdA==
  password: emhhbmdzYW4=

kubectl apply -f secret.yaml

2.2.3、檢視secret詳情

kubectl get secret secret -o yaml

2.2.4、建立Pod，將上面建立的Secret掛載上去

pod-secret.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-secret
  namespace: default
spec:
  containers:
    - name: nginx
      image: nginx:1.17.1
      volumeMounts: # 將secret掛載到目錄
        - name: config
          mountPath: /secret/config
  volumes:
    - name: config
      secret:
        secretName: secret

kubectl apply -f pod-secret.yaml

kubectl get pods -o wide

2.2.5、進入容器檢視Secret資訊

kubectl exec -it pod-secret -- bash