subpath的用法
一直没用过挂载的subpath参数。写了个资源文件测试了一下，发现自己之前的理解错的离谱。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| apiVersion: v1
metadata:
name: my-lamp-site-data
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
storageClassName: nfs-client
---
apiVersion: v1
kind: Pod
metadata:
name: my-lamp-site
spec:
containers:
- name: mysql
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "rootpasswd"
volumeMounts:
- mountPath: /var/lib/mysql
name: site-data
subPath: mysql
- name: php
image: php:7.0-apache
volumeMounts:
- mountPath: /var/www/html
name: site-data
subPath: html
volumes:
- name: site-data
persistentVolumeClaim:
claimName: my-lamp-site-data
|
创建一个pod。有两个容器，php和mysql。使用同一个volume。
特别注意mountPath和subPath的写法, 最后的path要保持一致。
这个volume是一个pvc。
创建好之后，进入php容器查看下
1
2
3
4
5
6
7
8
9
| [root@paas-m-k8s-master-1 ~]# kc exec -it my-lamp-site -c php -- /bin/sh
# pwd
/var/www/html
# touch a.txt
# ls
a.txt
# cat > a.txt << EOF
> asdhkljfga
> EOF
|
同样进入mysql容器，发现并没有a.txt
也创建一个b.txt
回到php容器，同样也是看不到的
去pv挂载的目录看看，我这里用的是nfs
1
2
3
4
5
6
7
8
9
| [root@paas-m-k8s-nfs default-my-lamp-site-data-pvc-33ac110d-d2b3-4b91-be84-b481f1a4bd0f]# ll
总用量 4
drwxrwxrwx 2 root root 19 12月 20 10:49 html
drwxrwxrwx 6 polkitd root 4096 12月 20 10:52 mysql
[root@paas-m-k8s-nfs default-my-lamp-site-data-pvc-33ac110d-d2b3-4b91-be84-b481f1a4bd0f]# ls html/
a.txt
[root@paas-m-k8s-nfs default-my-lamp-site-data-pvc-33ac110d-d2b3-4b91-be84-b481f1a4bd0f]# ls mysql/
auto.cnf binlog.000002 b.txt ca.pem ...
|
发现根本就是两个目录。
我以前的理解是完全错误的，subpath不是为了多个容器之间共享数据。而是为了使用一个volume，但是分目录来使用。
要使一个pod的多个容器能够共享数据，直接使用一个挂载就好
总之，什么时候应该使用 subpath
- 场景一: 一个共享卷, 挂载多个路径.
- 场景二: ConfigMap或Secret挂载到特定目录的特定路径, 而 该目录下已经有其他文件且不希望被覆盖
误删pvc的血泪教训
顺便测试下pv删除时的保留策略
查看pv的策略是Delete
删除pvc之后，服务器上的目录直接会被删除
pv的reclaim policy是继承自storage class
改一下storage class
不能直接改成Retain，因为storage class一旦创建就无法修改。
只能删除重新创建。
所以，我们最好是创建个新的storage class。不要动原来的东西。
新的storageclass
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| apiVersion: v1
items:
- allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
storageclass.kubernetes.io/is-default-class: "true"
storageclass.kubesphere.io/support-snapshot: "false"
storageclass.kubesphere.io/supported_access_modes: '["ReadWriteOnce","ReadOnlyMany","ReadWriteMany"]'
labels:
app: nfs-provisioner
chart: nfs-client-provisioner-1.1.2
heritage: Tiller
release: nfs-client-retain
name: nfs-client-retain
mountOptions:
- nfsvers=3
parameters:
archiveOnDelete: "false"
provisioner: cluster.local/nfs-client-nfs-client-provisioner
reclaimPolicy: Retain
volumeBindingMode: Immediate
kind: List
metadata:
resourceVersion: ""
selfLink: ""
|
1
2
| # kubectl apply -f storageClass-retain.yaml
storageclass.storage.k8s.io/nfs-client-retain created
|
1
2
3
4
5
| [root@paas-m-k8s-master-1 yaml]# kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
nfs-client cluster.local/nfs-client-nfs-client-provisioner Delete Immediate true 2y160d
nfs-client-reatain (default) cluster.local/nfs-client-nfs-client-provisioner Retain Immediate true 106s
rook-ceph-block (default) rook-ceph.rbd.csi.ceph.com Delete Immediate true 2y145d
|
多个我们新创建的nfs-client-reatain
使用nfs-client-retain再做测试
1
2
3
4
5
6
7
8
9
10
11
| kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: my-lamp-site-data
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
storageClassName: nfs-client-retain
|
删除pod和pvc之后。
可以看到目录还在
建议将storageclass的保留策略reclaimPolicy设置为Retain。
因为发生过误删除pvc的血泪教训。