一、ConfigMap
1,介紹
ConfigMap 功能在 Kuberbetes 1.2 版本中引入,許多應用程序會從配置文件、命令行參數或環境變量中讀取配置信息。ConfigMap API 給我們提供了向容器中注入配置信息的機制,ConfigMap 可以被用來保存單個屬性,也可以用來保存整個配置文件或者 json 二進制大對象。
2,創建方式
a)使用目錄創建
vim file1.properties name=zhansan age=24 gender=man vim file2.properties color=yellow num=20
#/usr/local/demo/configmap爲存儲file1.properties和file2.properties的路徑 kubectl create configmap cm-by-dir --from-file=/usr/local/demo/configmap kubectl get cm #查看cm的描述 kubectl describe cm cm-by-dir 查看cm的yaml文件內容 kubectl get cm cm-by-dir -o yaml
由此可得出:目錄下的所有文件都會被用在 ConfigMap 裏面創建一個鍵值對,鍵就是文件的名字,值就是文件的內容。
b)使用文件創建
#繼續使用a)中的文件 kubectl create configmap cm-by-file --from-file=/usr/local/demo/configmap/file1.properties kubectl get cm
c)使用字面值創建
#使用 --from-literal 參數傳遞配置信息 kubectl create configmap cm-by-literal --from-literal=name=zhangsan --from-literal=age=18 kubectl get cm
d)使用yaml創建(special.yaml)
apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charm
kubectl apply -f special.yaml
3,Pod中使用ConfigMap
special-config.yaml:
apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charm
log-level-config.yaml:
apiVersion: v1 kind: ConfigMap metadata: name: log-level-config namespace: default data: log_level: INFO
編寫 Pod 資源清單(cm-env-pod.yaml):
apiVersion: v1 kind: Pod metadata: name: cm-env-pod namespace: default spec: restartPolicy: Never containers: - name: nginx-container image: hub.xcc.com/my-xcc/my-nginx:v1 command: ['sh', '-c', 'env'] #輸出容器的環境變量 envFrom: #指定configMap,並使用configMap的key和value作爲環境變量的key和value - configMapRef: name: log-level-config #引用的configMap名稱 env: - name: SPECIAL_HOW_STR #環境變量key valueFrom: configMapKeyRef: name: special-config #引用的configMap名稱 key: special.how #環境變量值爲special-config中的special.how的值 - name: SPECIAL_TYPE_STR valueFrom: configMapKeyRef: name: special-config key: special.type
執行命令
kubectl apply -f log-level-config.yaml kubectl apply -f special-config.yaml kubectl apply -f cm-env-pod.yaml kubectl get pod #查看環境變量輸出 kubectl log cm-env-pod
4,數據卷掛載
apiVersion: v1 kind: Pod metadata: name: volume-config-pod namespace: default spec: restartPolicy: Never containers: - name: nginx-container image: hub.xcc.com/my-xcc/my-nginx:v1 command: ['sh', '-c', 'sleep 3600'] volumeMounts: - name: config-volume #數據卷名稱 mountPath: /etc/config #數據卷容器內的路徑 volumes: - name: config-volume #數據卷關聯的configMap名稱 configMap: name: special-config
執行命令
[root@k8s-master01 ~]# kubectl apply -f volume-config-pod.yaml pod/volume-config-pod created [root@master01 ~]# kubectl get pod NAME READY STATUS RESTARTS AGE volume-config-pod 1/1 Running 0 3s [root@master01 ~]# kubectl exec volume-config-pod -it /bin/bash root@volume-config-pod:/# cd /etc/config root@volume-config-pod:/etc/config# ls special.how special.type root@volume-config-pod:/etc/config# cat special.how very root@volume-config-pod:/etc/config# cat special.type charm
在掛載數據卷後,容器內部將 configMap 的 key 作爲文件名,value 作爲文件內容,創建成一個個的文件。
二、Secret
Secret 是一種包含少量敏感信息例如密碼、token 或 key 的對象。這樣的信息可能會被放在 Pod spec 中或者鏡像中;將其放在一個 secret 對象中可以更好地控制它的用途,並降低意外暴露的風險。
Pod可以通過三種方式使用Secret:作爲 volume 中的文件被掛載到 pod 中的一個或者多個容器裏;作爲環境變量注入;或者當 kubelet 爲 pod 拉取鏡像時使用。
1,secret的分類
-
kubernetes.io/service-account-token
:這是 Service Account 使用 API 憑證自動創建和附加 secret。Kubernetes 自動創建包含訪問 API 憑據的 secret,並自動修改您的 pod 以使用此類型的 secret。如果需要,可以禁用或覆蓋自動創建和使用API憑據。但是,如果您需要的只是安全地訪問 apiserver,我們推薦這樣的工作流程。
-
kubernetes.io/dockerconfigjson
:用來存儲私有 docker registry 的認證信息。使用imagePullSecrets
策略指定 Secret。 -
Opaque
:base64 編碼格式的 Secret,用來存儲密碼、密鑰等;但數據也可以通過 base64 –decode 解碼得到原始數據,所有加密性很弱。
2,Opaque Secret
假設有些 pod 需要訪問數據庫。這些 pod 需要使用的用戶名和密碼在您本地機器的 ./username.txt
和 ./password.txt
文件裏。
a)使用文件創建
echo -n 'admin' > ./username.txt echo -n '123456' > ./password.txt kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt kubectl get secret kubectl get secret db-user-pass -o yaml
b)使用yaml清單創建
echo -n "admin" | base64 # YWRtaW4= echo -n "123456" | base64 # MTIzNDU2
創建mysecret.yaml
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: MTIzNDU2
執行命令
kubectl apply -f mysecret.yaml kubectl get secret #查看 Secret 依然是 base64 編碼格式保存的內容 kubectl get secret mysecret -o yaml
c)解碼
[root@master01 secret]# kubectl get secret NAME TYPE DATA AGE ... [root@k8s-master01 secret]# kubectl get secret mysecret -o yaml apiVersion: v1 data: password: MTIzNDU2 username: YWRtaW4= ...... [root@master01 secret]# echo -n "MTIzNDU2" | base64 -d 123456 [root@master01 secret]# echo -n "YWRtaW4=" | base64 -d admin
d)編輯Secret
kubectl edit secrets mysecret
e)使用Secret
作爲volume使用:
Secret可以作爲數據卷被掛載,或作爲環境變量暴露出來以供Pod中的容器使用。
- 創建一個 secret 或者使用已有的 secret。多個 pod 可以引用同一個 secret。
- 修改 pod 的定義在
spec.volumes[]
下增加一個 volume。可以給這個 volume 隨意命名,它的spec.volumes[].secret.secretName
必須等於 secret 對象的名字。 - 將
spec.containers[].volumeMounts[]
加到需要用到該 secret 的容器中。指定spec.containers[].volumeMounts[].readOnly = true
和spec.containers[].volumeMounts[].mountPath
爲您想要該 secret 出現的尚未使用的目錄。 - 修改您的鏡像並且/或者命令行讓程序從該目錄下尋找文件。Secret 的
data
映射中的每一個鍵都成爲了mountPath
下的一個文件名。
示例:
apiVersion: v1 kind: Pod metadata: name: mypod spec: volumes: - name: foo secret: secretName: mysecret containers: - name: mypod image: hub.xcc.com/my-xcc/my-nginx:v1 volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true
向特此那個路徑映射secret::
apiVersion: v1 kind: Pod metadata: name: mypod spec: volumes: - name: foo secret: secretName: mysecret items: - key: username path: my-group/my-username #secret存儲的路徑爲/etc/foo/my-group/my-username containers: - name: mypod image: hub.xcc.com/my-xcc/my-nginx:v1 volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true
作爲環境變量使用
將 secret 作爲 pod 中的環境變量使用:
- 創建一個 secret 或者使用一個已存在的 secret。多個 pod 可以引用同一個 secret。
- 修改 Pod 定義,爲每個要使用 secret 的容器添加對應 secret key 的環境變量。消費 secret key 的環境變量應填充 secret 的名稱,並鍵入
env[x].valueFrom.secretKeyRef
。 - 修改鏡像並/或者命令行,以便程序在指定的環境變量中查找值。
示例:
apiVersion: v1 kind: Pod metadata: name: secret-env-pod spec: containers: - name: mycontainer image: hub.xcc.com/my-xcc/my-nginx:v1 env: - name: SECRET_USERNAME valueFrom: secretKeyRef: name: mysecret key: username - name: SECRET_PASSWORD valueFrom: secretKeyRef: name: mysecret key: password restartPolicy: Never
執行命令:
kubectl apply -f secret-env.yaml kubectl get pod kubectl exec secret-env-pod -it /bin/sh echo $SECRET_USERNAME echo $SECRET_PASSWORD
3,ImagePullSecret
假如我們創建 Pod 時,Pod 裏面所使用的鏡像是私有的,需要進行身份認證才能夠拉取,那麼我們可以創建一個具有該私有倉庫認證信息的 Secret,然後使用 ImagePullSecrets 指定。
下面我們使用 harbor 私有倉庫進行舉例。在 harbor 中創建一個私有項目 tom,並向該項目中 push 一個鏡像 hub.xcc.com/my/nginx:v1
。然後將集羣中的所有節點都退出 harbor 的登錄,並刪除所有節點中的 hub.xcc.com/my/nginx:v1 鏡像。
#鏡像拉取錯誤 rpc error: code = Unknown desc = Error response from daemon: pull access denied for hub.xcc.com/my/nginx, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
解決步驟:
創建認證信息Secret
kubectl create secret docker-registry my-registry-secret --docker-server=hub.xcc.com --docker-username=admin --docker-password=Harbor12345 --docker-email=[email protected]
my-registry-secret:被創建的secret名稱
yaml文件
apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: nginx-container image: hub.xcc.com/my/nginx:v1 imagePullSecrets: - name: my-registry-secret
三、Volume
1,介紹
容器中的文件在磁盤上是臨時存放的,這給容器中運行的特殊應用程序帶來一些問題。 首先,當容器崩潰時,kubelet 將重新啓動容器,容器中的文件將會丟失——因爲容器會以乾淨的狀態重建(這和 docker 容器的重啓不一樣,docker 容器重啓不會丟失數據)。其次,當在一個 Pod 中同時運行多個容器時,常常需要在這些容器之間共享文件。 Kubernetes 抽象出 Volume
對象來解決這兩個問題。
2,分類
- awsElasticBlockStore
- azureDisk
- azureFile
- cephfs
- cinder
- configMap
- csi
- downwardAPI
- emptyDir
- fc (fibre channel)
- flexVolume
- flocker
- gcePersistentDisk
- gitRepo (deprecated)
- glusterfs
- hostPath
- iscsi
- local
- nfs
- persistentVolumeClaim
- projected
- portworxVolume
- quobyte
- rbd
- scaleIO
- secret
- storageos
- vsphereVolume
3,emptyDir
當 Pod 指定到某個節點上時,首先創建的是一個 emptyDir
卷,並且只要 Pod 在該節點上運行,卷就一直存在。 就像它的名稱表示的那樣,卷最初是空的。 儘管 Pod 中的容器掛載 emptyDir
卷的路徑可能相同也可能不同,但是這些容器都可以讀寫 emptyDir
卷中相同的文件。 當 Pod 因爲某些原因被從節點上刪除時,emptyDir
卷中的數據也會永久刪除。
說明: 容器崩潰並不會導致 Pod 被從節點上移除,因此容器崩潰時emptyDir
卷中的數據是安全的。
emptyDir
的一些用途:
- 緩存空間,例如基於磁盤的歸併排序。
- 爲耗時較長的計算任務提供檢查點,以便任務能方便地從崩潰前狀態恢復執行。
- 在 Web 服務器容器服務數據時,保存內容管理器容器獲取的文件。
默認情況下, emptyDir
卷存儲在支持該節點所使用的介質上;這里的介質可以是磁盤或 SSD 或網絡存儲,這取決於您的環境。 但是,您可以將 emptyDir.medium
字段設置爲 "Memory"
,以告訴 Kubernetes 爲您安裝 tmpfs(基於 RAM 的文件系統)。 雖然 tmpfs 速度非常快,但是要注意它與磁盤不同。 tmpfs 在節點重啓時會被清除,並且您所寫入的所有文件都會計入容器的內存消耗,受容器內存限制約束。
創建volume-emptydir-pod.yaml
apiVersion: v1 kind: Pod metadata: name: volume-emptydir-pod spec: containers: - name: nginx-container #initc容器1 image: hub.xcc.com/my-xcc/my-nginx:v1 volumeMounts: #nginx-container 容器將 volume 掛載到了容器中的 /nginx-cache 目錄下 - mountPath: /nginx-cache name: cache-volume #使用volume - name: busybox-container image: hub.xcc.com/my-xcc/my-busybox:v1 command: ['sh', '-c', 'sleep 3600s'] volumeMounts: #busybox-container 容器將 volume 掛載到了容器中的 /busybox-cache 目錄下 - mountPath: /busybox-cache name: cache-volume volumes: #定義volume - name: cache-volume emptyDir: {}
執行命令
kubectl apply -f volume-emptydir-pod.yaml kubectl get pod #進入initc容器nginx-container kubectl exec volume-emptydir-pod -c nginx-container -it -- bin/bash ls /nginx-cache #進入initc容器busybox-container kubectl exec volume-emptydir-pod -c busybox-container -it -- bin/bash ls /busybox-cache #在nginx-container中 echo "this's nginx-container add content" > /nginx-cache/a.txt #在busybox-container中 cat /busybox-cache/a.txt
4,hostPath
hostPath
卷能將主機節點文件系統上的文件或目錄掛載到您的 Pod 中。 雖然這不是大多數 Pod 需要的,但是它爲一些應用程序提供了強大的逃生艙。
例如,hostPath
的一些用法有:
- 運行一個需要訪問 Docker 引擎內部機制的容器;請使用
hostPath
掛載/var/lib/docker
路徑。 - 在容器中運行 cAdvisor 時,以
hostPath
方式掛載/sys
。 - 允許 Pod 指定給定的
hostPath
在運行 Pod 之前是否應該存在,是否應該創建以及應該以什麼方式存在。
除了必需的 path
屬性之外,用戶可以選擇性地爲 hostPath
卷指定 type
。
支持的 type
值如下:
取值 | 行爲 |
---|---|
空字符串(默認)用於向後兼容,這意味着在安裝 hostPath 卷之前不會執行任何檢查。 | |
DirectoryOrCreate |
如果在給定路徑上什麼都不存在,那麼將根據需要創建空目錄,權限設置爲 0755,具有與 Kubelet 相同的組和所有權。 |
Directory |
在給定路徑上必須存在的目錄。 |
FileOrCreate |
如果在給定路徑上什麼都不存在,那麼將在那裏根據需要創建空文件,權限設置爲 0644,具有與 Kubelet 相同的組和所有權。 |
File |
在給定路徑上必須存在的文件。 |
Socket |
在給定路徑上必須存在的 UNIX 套接字。 |
CharDevice |
在給定路徑上必須存在的字符設備。 |
BlockDevice |
在給定路徑上必須存在的塊設備。 |
當使用這種類型的卷時要小心,因爲:
- 具有相同配置(例如從 podTemplate 創建)的多個 Pod 會由於節點上文件的不同而在不同節點上有不同的行爲。
- 當 Kubernetes 按照計劃添加資源感知的調度時,這類調度機制將無法考慮由
hostPath
使用的資源。 - 基礎主機上創建的文件或目錄只能由 root 用戶寫入。您需要在 特權容器 中以 root 身份運行進程,或者修改主機上的文件權限以便容器能夠寫入
hostPath
卷。
Pod 示例
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: # directory location on host path: /data # this field is optional type: Directory
注意: 應當注意,FileOrCreate
類型不會負責創建文件的父目錄。 如果掛載掛載文件的父目錄不存在,pod 啓動會失敗。 爲了確保這種type
能夠工作,可以嘗試把文件和它對應的目錄分開掛載,如下所示:
FileOrCreate pod 示例
apiVersion: v1 kind: Pod metadata: name: test-webserver spec: containers: - name: test-webserver image: k8s.gcr.io/test-webserver:latest volumeMounts: - mountPath: /var/local/aaa name: mydir - mountPath: /var/local/aaa/1.txt name: myfile volumes: - name: mydir hostPath: # 確保文件所在目錄成功創建。 path: /var/local/aaa type: DirectoryOrCreate - name: myfile hostPath: path: /var/local/aaa/1.txt type: FileOrCreate
四、PV和PVC
1,概念
持久卷(PersistentVolume,PV)是集羣中的一塊存儲,可以由管理員事先供應,或者 使用存儲類(Storage Class)來動態供應。 持久卷是集羣資源,就像節點也是集羣資源一樣。PV 持久卷和普通的 Volume 一樣,也是使用 卷插件來實現的,只是它們擁有獨立於任何使用 PV 的 Pod 的生命週期。 此 API 對象中記述了存儲的實現細節,無論其背後是 NFS、iSCSI 還是特定於雲平臺的存儲系統。
持久卷申領(PersistentVolumeClaim,PVC)表達的是用戶對存儲的請求。概念上與 Pod 類似。 Pod 會耗用節點資源,而 PVC 申領會耗用 PV 資源。Pod 可以請求特定數量的資源(CPU 和內存);同樣 PVC 申領也可以請求特定的大小和訪問模式 (例如,可以要求 PV 卷能夠以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一來掛載,參見訪問模式)。
2,生命週期
3,PV類型
-
GCEPersistentDisk
、AWSElasticBlockStore
、AzureFile
、AzureDisk
、CSI
、FC (Fibre Channel)
-
FlexVolume
、Flocker
、NFS
、iSCSI
、RBD (Ceph Block Device)
、CephFS
、Cinder (OpenStack block storage)
-
Glusterfs
、VsphereVolume
、Quobyte Volumes
、Portworx Volumes
、ScaleIO Volumes
、StorageOS
-
HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
4,PV示例
apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 spec: capacity: storage: 500Mb #指定PV容量大小 volumeMode: Filesystem #文件系統類型,有兩種類型:Filesystem(在創建 Pod 時會將掛載的卷嵌入到 Pod 的文件目錄中) 和 Block(Pod 和卷之間沒有任何文件系統層)。這是一個可選的參數,默認爲 Filesystem。 accessModes: - ReadWriteOnce #ReadWriteOnce – 只能在一個節點中掛載,能夠讀寫;ReadOnlyMany – 能夠在多個節點掛載,只能讀;ReadWriteMany – 能夠在多個節點掛載,能夠讀寫。 persistentVolumeReclaimPolicy: Recycle #回收策略。Retain(保留。手動回收);Recycle(回收,基本擦除rm -rf /thevolume/*);Delete(刪除。關聯的存儲資產,如:AWS EBS、GCE PD等也將被刪除)。 storageClassName: slow #爲PV生命一個類名。PVC 的 storageClassName 必須和這個一致。但是 PV 和 PVC 都可以不設置這個值而使用默認的類名。Recycle:回收。不推薦使用此策略。相反,推薦的方法是使用動態配置。 mountOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 172.17.0.2
5,PVC示例
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce #必須和PV的accessModes一樣或者是PV的子集 volumeMode: Filesystem #必須和PV的volumeMode一樣 resources: #聲明(如Pod)可以請求的資源大小。PVC會自動去尋找合適大小的PV匹配 requests: storage: 800Mb storageClassName: slow #與PV一致 selector: #通過指定標籤進一步過濾PV。 matchLabels: #matchLabels PV中必須帶有這個標籤和值; release: "stable" matchExpressions: #matchExpressions 通過指定運算符:In,NotIn,Exists和DoesNotExist等
- {key: environment, operator: In, values: [dev]}
6,NFS示例
a)安裝NFS
# 在harbor上192.168.232.90 #安裝 nfs 服務及相關工具 yum install -y nfs-common nfs-utils rpcbind # 創建4個共享文件夾 mkdir /nfs1 /nfs2 /nfs3 /nfs4 chmod 777 /nfs1 /nfs2 /nfs3 /nfs4 chown nfsnobody /nfs1 /nfs2 /nfs3 /nfs4 #添加exports vim /etc/exports /nfs1 *(rw,no_root_squash,no_all_squash,sync) /nfs2 *(rw,no_root_squash,no_all_squash,sync) /nfs3 *(rw,no_root_squash,no_all_squash,sync) /nfs4 *(rw,no_root_squash,no_all_squash,sync) #重啓綁定和nfs systemctl start rpcbind && systemctl start nfs #在集羣中所有節點安裝 yum install -y nfs-utils rpcbind
在集羣任一節點測試掛載 nfs 文件系統:
# 測試連接 nfs,結果顯示了 nfs 服務器的可掛載目錄 [root@master01 testnfs]# showmount -e 192.168.232.90 Export list for 192.168.232.90: /nfs4 * /nfs3 * /nfs2 * /nfs1 * [root@master01 ~]# pwd /root [root@master01 ~]# mkdir nfs2 # 將本地 /root/nfs2/ 目錄掛載到 nfs2 服務器目錄 [root@master01 nfs2]# mount -t nfs 192.168.232.90:/nfs2 /root/nfs2/
[root@master01 ~]# cd nfs2/ [root@master01 nfs2]# touch test.txt
[root@master01 nfs2]# ls
test.txt # 此時 192.168.232.90 機器上的 /nfs2 目錄可以看到 test.txt 這個文件 # 退出連接 [root@k8s-master01 testnfs]# umount -l /root/nfs2/
錯誤排查:如果執行命令 showmount -e 192.168.232.90
提示: clnt_create: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host),可以關掉 nfs 服務器的防火牆(systemctl status firewalld),或者開啓某些端口(自行網上搜索下)。
b)創建PV
nfs1-pv.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: nfs1-pv spec: capacity: storage: 100Mb accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: "nfs" nfs: path: /nfs1 server: 192.168.232.90
nfs2-pv.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: nfs2-pv spec: capacity: storage: 400Mb accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: "nfs" nfs: path: /nfs2 server: 192.168.232.90
nfs3-pv.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: nfs3-pv spec: capacity: storage: 700Mb accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: "nfs" nfs: path: /nfs3 server: 192.168.232.90
nfs4-pv.yaml
apiVersion: v1 kind: PersistentVolume metadata: name: nfs4-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: "nfs" nfs: path: /nfs4 server: 192.168.232.90
執行命令
kubectl apply -f nfs1-pv.yaml kubectl apply -f nfs2-pv.yaml kubectl apply -f nfs3-pv.yaml kubectl apply -f nfs4-pv.yaml #可看到 VOLUMEMODE 是 Filesystem 其中PV 都是 Available 的,即未綁定狀態 kubectl get pv -o wide
c)創建PVC和Pod
nfs-pvc-pod.yaml
apiVersion: v1 kind: Service metadata: name: nginx-svc labels: app: nginx-app spec: ports: - port: 80 name: web clusterIP: "None" selector: app: nginx-app --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: replicas: 1 serviceName: "nginx-app" selector: matchLabels: app: nginx-app template: metadata: labels: app: nginx-app spec: containers: - name: nginx-container image: hub.xcc.com/my-xcc/my-nginx:v1 ports: - containerPort: 80 name: web volumeMounts: - name: pvc-volume mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: pvc-volume spec: accessModes: ["ReadWriteOnce"] storageClassName: "nfs" resources: requests: storage: 600Mb
執行命令
kubectl apply -f nfs-pvc-pod.yaml kubectl get pvc #查看綁定情況 kubectl get pv kubectl get pod #我們將 statefulSet 擴容到 2 個 Pod,然後查看 pvc 的綁定情況 kubectl scale statefulSet web --replicas 2 kubectl get statefulSet kubectl get pod kubectl get pvc kubectl get pv