這篇文章給大家分享的是有關docker中k8s存儲卷的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
因為pod是有生命周期的，pod一重啟，里面的數據就沒了。所以我們需要數據持久化存儲。
在k8s中，存儲卷不屬于容器，而是屬于pod。也就是說同一個pod中的容器可以共享一個存儲卷。
存儲卷可以是宿主機上的目錄，也可以是掛載在宿主機上的外部設備。
emptyDIR存儲卷：pod一重啟，存儲卷也刪除，這叫emptyDir存儲卷。一般用于當做臨時空間或緩存關系
hostPath存儲卷：宿主機上目錄作為存儲卷，這種也不是真正意義實現了數據持久性。
SAN（iscsi）或NAS（nfs、cifs）：網絡存儲設備
分布式存儲（ceph,glusterfs,cephfs，rbd）：
云存儲（亞馬遜的EBS，Azure Disk，阿里云）：這種一般k8s也在云上部署的。
關鍵數據一定要有異地備份，否則數據一刪，多少個副本都沒用。
[root@master ingress]# kubectl explain pods.spec.volumes
功能：使用宿主機上目錄作為存儲卷，這種也不是真正意義實現了數據持久性。
[root@master ~]# kubectl explain pods.spec.volumes.hostPath.type KIND: Pod VERSION: v1 FIELD: type <string> DESCRIPTION: Type for HostPath Volume Defaults to "" More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath
查看幫助： https://kubernetes.io/docs/concepts/storage/volumes#hostpath
hostPath.type的類型說明：
DirectoryOrCreate：意思是我們要掛載的路徑在宿主機上是個已經存在的目錄，不存在就創建一個新的目錄。
Directory：宿主機上必須實現存在目錄，如果不存在就報錯
FileOrCreate：表示掛載的是文件，如果不存在就掛載一個文件。文件也可以當做存儲掛載的。
File：表示要掛載的文件必須事先存在，否則就報錯。
Socket：表示必須是一個Socket類型的文件。
CharDevice：表示是一個字符類型的設備文件。
BlockDevice：表示的是一個塊類型的設備文件。
例子：
[root@master volumes]# cat pod-hostpath-vol.yaml
apiVersion: v1 kind: Pod metadata: name: pod-vol-hostpath namespace: default spec: containers: - name: myapp image: ikubernetes/myapp:v1 volumeMounts: - name: html #存儲卷的名字叫html mountPath: /usr/share/nginx/html/ #掛載路徑 volumes: - name: html hostPath: path: /data/pod/volume1 type: DirectoryOrCreate
[root@master volumes]# kubectl apply -f pod-hostpath-vol.yaml pod/pod-vol-hostpath created
然后到node1節點上可以看到/data/pod/volume1目錄已經創建出來了。
[root@master volumes]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE client 0/1 Error 0 15d 10.244.2.4 node2 pod-vol-hostpath 1/1 Running 0 4m 10.244.1.105 node1
當node1節點宕機后，pod就飄到node2節點上，并使用node2節點上的/data/pod/volume1目錄。這就有問題了，因為node2節點上的目錄并沒有同步node1節點上目錄的數據，所以出現數據不一致。
解決這個問題的方法就是使用類似nfs方法，讓兩個node節點共享一個存儲。
我這里為了方便，把master節點當做nfs存儲。
[root@master ~]# yum -y install nfs-utils
[root@master ~]# mkdir /data/volumes
[root@master ~]# cat /etc/exports #no_root_squash：登入 NFS 主機使用分享目錄的使用者，如果是 root 的話，那么對于這個分享的目錄來說，他就具有 root 的權限！這個項目『極不安全』，不建議使用！ #root_squash：在登入 NFS 主機使用分享之目錄的使用者如果是 root 時，那么這個使用者的權限將被壓縮成為匿名使用者，通常他的 UID 與 GID 都會變成 nobody 那個系統賬號的身份； /data/volumes 172.16.0.0/16(rw,no_root_squash)
[root@master ~]# systemctl start nfs
在node1和node2上也安裝nfs-utils包
[root@node1 ~]# yum -y install nfs-utils
在node1和node2上掛載：
[root@node1 ~]# mount -t nfs 172.16.1.100:/data/volumes /mnt
在master上：
[root@master ~]# kubectl explain pods.spec.volumes.nfs
[root@master volumes]# cat pod-vol-nfs.yaml apiVersion: v1 kind: Pod metadata: name: pod-vol-nfs namespace: default spec: containers: - name: myapp image: ikubernetes/myapp:v1 volumeMounts: - name: html #存儲卷的名字叫html mountPath: /usr/share/nginx/html/ #掛載路徑，myapp容器里面的路徑 volumes: - name: html nfs: path: /data/volumes server: 172.16.1.100 #nfs server ip
[root@master volumes]# kubectl apply -f pod-vol-nfs.yaml
[root@master volumes]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE pod-vol-nfs 1/1 Running 0 1m 10.244.1.106 node1
[root@master volumes]# cat /data/volumes/index.html hello world
[root@master volumes]# curl 10.244.1.106 #容器的ip hello world
可見容器使用的是nfs提供的共享存儲。
不過，nfs自身沒有冗余能力，所以如果nfs宕機了，數據也丟了。因此，我們一般用glusterfs或者cephfs分布式存儲。
用戶只需要掛載pvc到容器中而不需要關注存儲卷采用何種技術實現。pvc和pv的關系與pod和node關系類似，前者消耗后者的資源。pvc可以向pv申請指定大小的存儲資源并設置訪問模式。
在定義pod時，我們只需要說明我們要一個多大的存儲卷就行了。pvc存儲卷必須與當前namespace的pvc建立直接綁定關系。pvc必須與pv建立綁定關系。而pv是真正的某個存儲設備上的空間。
[root@master volumes]# kubectl explain pods.spec.volumes.persistentVolumeClaim
[root@master volumes]# kubectl explain pvc
一個pvc和pv是一一對應關系，一旦一個pv被一個pvc綁定了，那么這個pv就不能被其他pvc綁定了。
一個pvc是可以被多個pod所訪問的。
在存儲機器上建立如下幾個目錄（這里我以master節點做存儲，生產中可以單獨拿出 一個機器做存儲）：
[root@master volumes]# mkdir v{1,2,3,4,5}[root@master volumes]# cat /etc/exports #no_root_squash：登入 NFS 主機使用分享目錄的使用者，如果是 root 的話，那么對于這個分享的目錄來說，他就具有 root 的權限！這個項目『極不安全』，不建議使用！ #root_squash：在登入 NFS 主機使用分享之目錄的使用者如果是 root 時，那么這個使用者的權限將被壓縮成為匿名使用者，通常他的 UID 與 GID 都會變成 nobody 那個系統賬號的身份； /data/volumes/v1 172.16.0.0/16(rw,no_root_squash) /data/volumes/v2 172.16.0.0/16(rw,no_root_squash) /data/volumes/v3 172.16.0.0/16(rw,no_root_squash) /data/volumes/v4 172.16.0.0/16(rw,no_root_squash) /data/volumes/v5 172.16.0.0/16(rw,no_root_squash)
[root@master volumes]# exportfs -arv #不用重啟nfs服務，配置文件就會生效 exporting 172.16.0.0/16:/data/volumes/v5 exporting 172.16.0.0/16:/data/volumes/v4 exporting 172.16.0.0/16:/data/volumes/v3 exporting 172.16.0.0/16:/data/volumes/v2 exporting 172.16.0.0/16:/data/volumes/v1
[root@master volumes]# showmount -e Export list for master: /data/volumes/v5 172.16.0.0/16 /data/volumes/v4 172.16.0.0/16 /data/volumes/v3 172.16.0.0/16 /data/volumes/v2 172.16.0.0/16 /data/volumes/v1 172.16.0.0/16
[root@master volumes]# kubectl explain pv.spec.nfs
[root@master ~]# kubectl explain pv.spec FIELDS: accessModes<[]string> AccessModes contains all ways the volume can be mounted. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes
訪問 https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes看幫助。
accessModes模式有：
ReadWriteOnce：單路讀寫，可以簡寫為RWO
ReadOnlyMany：多路只讀，可以簡寫為ROX
ReadWriteMany ：多路讀寫，可以簡寫為RWX
不同類型的存儲卷支持的accessModes也不同。
[root@master volumes]# cat pv-demo.yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv001 #注意，定義pv時一定不要加名稱空間，因為pv是屬于整個集群，而不是屬于某個名稱空間。但pvc是屬于某個名稱空間的 labels: name: pv001 spec: nfs: path: /data/volumes/v1 server: 172.16.1.100 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: #分配磁盤空間大小 storage: 1Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv002 #注意，定義pv時一定不要加名稱空間，因為pv是屬于整個集群，而不是屬于某個名稱空間。但pvc是屬于某個名稱空間的 labels: name: pv002 spec: nfs: path: /data/volumes/v2 server: 172.16.1.100 accessModes: ["ReadWriteOnce"] capacity: #分配磁盤空間大小 storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv003 #注意，定義pv時一定不要加名稱空間，因為pv是屬于整個集群，而不是屬于某個名稱空間。但pvc是屬于某個名稱空間的 labels: name: pv003 spec: nfs: path: /data/volumes/v3 server: 172.16.1.100 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: #分配磁盤空間大小 storage: 1Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv004 #注意，定義pv時一定不要加名稱空間，因為pv是屬于整個集群，而不是屬于某個名稱空間。但pvc是屬于某個名稱空間的 labels: name: pv004 spec: nfs: path: /data/volumes/v4 server: 172.16.1.100 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: #分配磁盤空間大小 storage: 1Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv005 #注意，定義pv時一定不要加名稱空間，因為pv是屬于整個集群，而不是屬于某個名稱空間。但pvc是屬于某個名稱空間的 labels: name: pv005 spec: nfs: path: /data/volumes/v5 server: 172.16.1.100 accessModes: ["ReadWriteMany","ReadWriteOnce"] capacity: #分配磁盤空間大小 storage: 1Gi
[root@master volumes]# kubectl apply -f pv-demo.yaml persistentvolume/pv001 created persistentvolume/pv002 created persistentvolume/pv003 created persistentvolume/pv004 created persistentvolume/pv005 created
[root@master volumes]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv001 1Gi RWO,RWX Retain Available 2m pv002 2Gi RWO Retain Available 2m pv003 1Gi RWO,RWX Retain Available 2m pv004 1Gi RWO,RWX Retain Available 2m pv005 1Gi RWO,RWX Retain Available 2m
回收策略：如果某個pvc在pv里面存數據了，后來pvc刪了，那么 pv里面的數據怎么處理呢。有如下幾種策略：
reclaim_policy：即pvc刪了，但是pv里面的數據不擅長，還保留著。
recycle：即pvc刪了，那么就把pv里面的數據也刪了。
delete：即pvc刪了，那么就把pv也刪了。
下面我們再創建pvc的清單文件。
[root@master ~]# kubectl explain pvc.spec
[root@master ~]# kubectl explain pods.spec.volumes.persistentVolumeClaim
[root@master volumes]# cat pod-vol-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim #簡稱pvc metadata: name: mypvc namespace: default #pvc和pod是在同一個名稱空間 spec: accessModes: ["ReadWriteMany"] #一定是pv策略的子集 resources: requests: storage: 1Gi #表示我要pvc 為1G的空間 --- apiVersion: v1 kind: Pod metadata: name: pod-vol-pvc namespace: default spec: containers: - name: myapp image: ikubernetes/myapp:v1 volumeMounts: - name: html #存儲卷的名字叫html mountPath: /usr/share/nginx/html/ #掛載路徑 volumes: - name: html persistentVolumeClaim: claimName: mypvc #表示我要使用哪個pvc
[root@master volumes]# kubectl apply -f pod-vol-pvc.yaml persistentvolumeclaim/mypvc created pod/pod-vol-pvc created
[root@master volumes]# kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv001 1Gi RWO,RWX Retain Available 7h pv002 2Gi RWO Retain Available 7h pv003 1Gi RWO,RWX Retain Available 7h pv004 1Gi RWO,RWX Retain Bound default/mypvc 7h pv005 1Gi RWO,RWX Retain Available 7h
上面看到pv004被default名稱空間的mypvc綁定了。
[root@master volumes]# kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE mypvc Bound pv004 1Gi RWO,RWX 33m
[root@master volumes]# kubectl get pods NAME READY STATUS RESTARTS AGE client 0/1 Error 0 16d pod-vol-pvc 1/1 Running 0 35m
生產上，pv并不屬于node節點，而是獨立于node節點的。所以，node節點壞了，pv里面的數據還在。另外，pod才是屬于node節點的。
在k8s 1.10之后，不能手工從底層刪除pv，這樣做很安全。
Kubernetes集群管理員通過提供不同的存儲類，可以滿足用戶不同的服務質量級別、備份策略和任意策略要求的存儲需求。動態存儲卷供應使用StorageClass進行實現，其允許存儲卷按需被創建。如果沒有動態存儲供應，Kubernetes集群的管理員將不得不通過手工的方式類創建新的存儲卷。通過動態存儲卷，Kubernetes將能夠按照用戶的需要，自動創建其需要的存儲。
storageclass底層可以是glusterfs，cephfs等不同的集群。
configmap和secret是兩種特殊的存儲卷，它們不是給pod提供存儲空間用的，而是給我們的管理員或者用戶提供了從外部向pod內部注入信息的方式。
configmap：把配置文件放在配置中心上，然后多個pod讀取配置中心的配置文件。不過，configmap中的配置信息都是明文的，所以不安全。
secret：功能和configmap一樣，只不過配置中心存儲的配置文件不是明文的。
configmap和secret也是專屬于某個名稱空間的。
[root@master ~]# kubectl explain configmap [root@master ~]# kubectl explain cm #簡寫 [root@master ~]# kubectl create configmap --help
簡單的我們可以用命令行來創建configmap。
[root@master ~]# kubectl create configmap nginx-config --from-literal=nginx_port=80 --from-literal=server_name=myapp.zhixin.com configmap/nginx-config created
[root@master ~]# kubectl get cm NAME DATA AGE nginx-config 2 3m
[root@master ~]# kubectl describe cm nginx-config Name: nginx-config Namespace: default Labels: <none> Annotations: <none> Data ==== nginx_port: ---- 80 server_name: ---- myapp.zhixin.com
下面我們用配置清單的方式來創建configmap：
[root@master configmap]# cat www.conf
server {
server_name myapp.zhixin.com;
listen 80;
root /data/web/html;
}[root@master configmap]# kubectl create configmap nginx-www --from-file=www.conf configmap/nginx-www created
[root@master configmap]# kubectl get cm NAME DATA AGE nginx-config 2 3m nginx-www 1 7s
[root@master configmap]# kubectl describe cm nginx-www
Name: nginx-www
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
www.conf:
----
server {
server_name myapp.zhixin.com;
listen 80;
root /data/web/html;
} 我們創建的configmap，可用ENV等方式注入到Pod中。
我們用ENV方式來把configmap注入到pod中去。
[root@master configmap]# cat pod-configmap.yaml apiVersion: v1 kind: Pod metadata: name: pod-cm-1 namespace: default labels: app: myapp #kv格式的，也可以用花括號表示 tier: frontend #定義所屬的層次 annotations: chenzx.com/created-by: "cluster-admin" #這是注解的鍵值對 spec: containers: - name: myapp #前面的-號表示這是一個列表格式的,也可以用中括號表示 image: tomcat ports: - name: http containerPort: 80 env: #這是一個容器的屬性 - name: NGINX_SERVER_PORT valueFrom: #kubectl explain pods.spec.containers.env.valueFrom configMapKeyRef: #表示我們要引用一個configmap來獲取數據 name: nginx-config #這是configmap的名字，也就是通過kubectl get cm獲取的名字 key: nginx_port #通過kubectl describe cm nginx-config的鍵 #下面開始引用第二個環境變量 - name: NGINX_SERVER_NAME valueFrom: configMapKeyRef: name: nginx-config key: server_name
[root@master configmap]# kubectl apply -f pod-configmap.yaml pod/pod-cm-1 created
這樣，我們就建立了一個pod-cm-1的pod，并且這個pod的配置文件來自于configmap。
[root@master configmap]# kubectl get pods NAME READY STATUS RESTARTS AGE pod-cm-1 0/1 Running 0 15m
[root@master configmap]# kubectl exec -it pod-cm-1 -- /bin/sh # printenv NGINX_SERVER_PORT=80 NGINX_SERVER_NAME=myapp.zhixin.com
[root@master configmap]# kubectl edit cm nginx-config configmap/nginx-config edited
通過edit方式編輯的配置文件，在Pod里面不會立即理解生效，需要重啟pod才能生效。
[root@master configmap]# kubectl delete -f pod-configmap.yaml pod "pod-cm-1" deleted
下面我們用配置mount存儲卷的方法把configmap注入到pod中。
[root@master configmap]# cat pod-configmap2.ymal apiVersion: v1 kind: Pod metadata: name: pod-cm-2 namespace: default labels: app: myapp #kv格式的，也可以用花括號表示 tier: frontend #定義所屬的層次 annotations: chenzx.com/created-by: "cluster-admin" #這是注解的鍵值對 spec: containers: - name: myapp #前面的-號表示這是一個列表格式的,也可以用中括號表示 image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 volumeMounts: - name: nginxconf mountPath: /etc/nginx/conf.d/ readOnly: true volumes: - name: nginxconf configMap: name: nginx-config
[root@master configmap]# kubectl apply -f pod-configmap2.ymal pod/pod-cm-2 created
[root@master configmap]# kubectl get pods NAME READY STATUS RESTARTS AGE pod-cm-2 1/1 Running 0 1m
[root@master configmap]# kubectl exec -it pod-cm-2 -- /bin/sh / # cd /etc/nginx/conf.d/ /etc/nginx/conf.d # ls nginx_port server_name /etc/nginx/conf.d # ls -l total 0 lrwxrwxrwx 1 root root 17 Sep 27 05:07 nginx_port -> ..data/nginx_port lrwxrwxrwx 1 root root 18 Sep 27 05:07 server_name -> ..data/server_name /etc/nginx/conf.d # cat nginx_port 8080
下面我們再把前面我們創建的www.conf文件注入到pod中：
[root@master configmap]# cat pod-configmap3.yaml apiVersion: v1 kind: Pod metadata: name: pod-cm-3 namespace: default labels: app: myapp #kv格式的，也可以用花括號表示 tier: frontend #定義所屬的層次 annotations: chenzx.com/created-by: "cluster-admin" #這是注解的鍵值對 spec: containers: - name: myapp #前面的-號表示這是一個列表格式的,也可以用中括號表示 image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 volumeMounts: - name: nginxconf mountPath: /etc/nginx/conf.d/ readOnly: true volumes: - name: nginxconf configMap: name: nginx-www
[root@master configmap]# kubectl apply -f pod-configmap3.yaml pod/pod-cm-3 created
[root@master configmap]# [root@master configmap]# kubectl get pods NAME READY STATUS RESTARTS AGE client 0/1 Error 0 16d pod-cm-3 1/1 Running 0 1m
[root@master configmap]# kubectl exec -it pod-cm-3 -- /bin/sh
/ # cd /etc/nginx/conf.d/
/etc/nginx/conf.d # ls
www.conf
/etc/nginx/conf.d # cat www.conf
server {
server_name myapp.zhixin.com;
listen 80;
root /data/web/html;
} 通過上面的例子，大家看到我們已經把
www.conf中的內容注入到了pod
myapp中。
[root@master configmap]# kubectl edit cm nginx-www
改個端口，然后再到pod里面，多等一會就會看到剛才修改的在pod里面生效了。
[root@master configmap]# kubectl exec -it pod-cm-3 -- /bin/sh
/ # cd /etc/nginx/conf.d/
/etc/nginx/conf.d # cat www.conf
server {
server_name myapp.zhixin.com;
listen 8081;
root /data/web/html;
[root@master configmap]# /etc/init.d/nginx reload #重載nginx使8081端口生效如果我們期望只注入部分，而非所有，該怎么做呢？
[root@master configmap]# kubectl explain pods.spec.volumes.configMap.items [root@master configmap]# kubectl create secret generic --help
通過items來注入部分，這里面就不演示了，請讀者自行解決。
功能和configmap一樣，只不過secret配置中心存儲的配置文件不是明文的。
[root@master configmap]# kubectl create secret --help generic：保存密碼用的類型 tls：保存證書用的類型 docker-registry：保存docker認證信息用的類型，比如從私有docker倉庫拉鏡像時，就用這個類型。 備注：k8s拖鏡像的進程是kublete
[root@master configmap]# kubectl explain pods.spec.imagePullSecrets 如果是從私有倉庫拉鏡像，就用imagePullSecrets存登錄驗證的信息
例子：
[root@master configmap]# kubectl create secret generic mysql-root-password --from-literal=password=123456 secret/mysql-root-password created
[root@master configmap]# kubectl get secret NAME TYPE DATA AGE default-token-5r85r kubernetes.io/service-account-token 3 19d mysql-root-password Opaque 1 40s tomcat-ingress-secret kubernetes.io/tls 2 2d
[root@master configmap]# kubectl describe secret mysql-root-password Name: mysql-root-password Namespace: default Labels: <none> Annotations: <none> Type: Opaque Data ==== password: 6 bytes
看到password的內容就是base64加密的形式了。
[root@master configmap]# kubectl get secret mysql-root-password -o yaml apiVersion: v1 data: password: MTIzNDU2 kind: Secret metadata: creationTimestamp: 2018-09-27T06:01:24Z name: mysql-root-password namespace: default resourceVersion: "2482795" selfLink: /api/v1/namespaces/default/secrets/mysql-root-password uid: c3d3e8ec-c21a-11e8-bb35-005056a24ecb type: Opaque
可以用命令base64命令進行明文解碼：
[root@master configmap]# echo MTIzNDU2 |base64 -d 123456
可見secret是防君子不防小人，是個偽加密，哈哈。
下面我們把secret通過env的方式注入到pod里面。
[root@master configmap]# cat pod-secret-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-secret-1 namespace: default labels: app: myapp #kv格式的，也可以用花括號表示 tier: frontend #定義所屬的層次 annotations: chenzx.com/created-by: "cluster-admin" #這是注解的鍵值對 spec: containers: - name: myapp #前面的-號表示這是一個列表格式的,也可以用中括號表示 image: tomcat ports: - name: http containerPort: 80 env: #這是一個容器的屬性 - name: MYSQL_ROOT_PASSWORD valueFrom: #kubectl explain pods.spec.containers.env.valueFrom secretKeyRef: #表示我們要引用一個configmap來獲取數據 name: mysql-root-password #這是configmap的名字，也就是通過kubectl get secret獲取的名字 key: password #通過kubectl describe secret mysql-root-password的鍵 #下面開始引用第二個環境變量 - name: NGINX_SERVER_NAME valueFrom: configMapKeyRef: name: nginx-config key: server_name
[root@master configmap]# kubectl apply -f pod-secret-1.yaml pod/pod-secret-1 created
[root@master configmap]# kubectl get pods NAME READY STATUS RESTARTS AGE pod-secret-1 1/1 Running 0 1m
[root@master configmap]# kubectl exec -it pod-secret-1 -- /bin/sh # printenv MYSQL_ROOT_PASSWORD=123456
感謝各位的閱讀！關于“docker中k8s存儲卷的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
