应用 subPath
有时,在单个 Pod 中共享卷以供多方应用是很有用的。 volumeMounts.subPath
属性可用于指定所援用的卷内的子门路,而不是其根门路。
上面是一个应用同一共享卷的、内含 LAMP 栈(Linux Apache Mysql PHP)的 Pod 的示例。 HTML 内容被映射到卷的 html
文件夹,数据库将被存储在卷的 mysql
文件夹中:
apiVersion: v1kind: Podmetadata: name: my-lamp-sitespec: 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
对下面的配置进行阐明:
volumeMounts
上面的name
, 就是调配给这个pod的volume的名字site-data
, mysql和php的html别离应用了它的子门路:mysql
和html
volumes
对于site-data
这个volume, 是通过PVC的模式提供的, PVC的name为:my-lamp-site-data
应用带有扩大环境变量的 subPath
FEATURE STATE: Kubernetes v1.15
feature-state-beta.txt
应用 subPathExpr
字段从 Downward API 环境变量结构 subPath
目录名。 在应用此个性之前,必须启用 VolumeSubpathEnvExpansion
性能开关。 subPath
和 subPathExpr
属性是互斥的。
在这个示例中,Pod 基于 Downward API 中的 Pod 名称,应用 subPathExpr
在 hostPath 卷 /var/log/pods
中创立目录 pod1
。 主机目录 /var/log/pods/pod1
挂载到了容器的 /logs
中。
apiVersion: v1kind: Podmetadata: name: pod1spec: containers: - name: container1 env: - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name image: busybox command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] volumeMounts: - name: workdir1 mountPath: /logs subPathExpr: $(POD_NAME) restartPolicy: Never volumes: - name: workdir1 hostPath: path: /var/log/pods
阐明:
- env中, 配置了
POD_NAME
这个环境变量, 这个变量的值来自于metadata.name
, 即pod1
subPathExpr: $(POD_NAME)
子门路为$(POD_NAME)
这个变量, 就是pod1
- volume用的是
hostPath
, 理论门路为:/var/log/pods
. 那么残缺的path就是/var/log/pods/pod1
总结
subPath 还是挺实用的, 是个小性能, 然而的确能提交效率. 比方我昨天搭建的禅道的容器. 就是典型的LAMP: Linux + Apache + Mysql + PHP.
这些组件中,
Apache
的www/html
须要挂载mysql
的数据库须要挂载php
的利用数据须要挂载
如果没用subPath, 那么我得这么操作: (以nfs为例)
- nfs下手动创立3个子目录:
html
mysql
php
- 创立3个PV, 别离为:
apache-volume
mysql-volume
php-volume
- 写3个PVC, 别离是:
apache-claim
mysql-claim
php-claim
. 而且2和3这两步最好一个pv+一个PVC来建. 防止bound乱了. - 再批改
Deployment
配置, 一个个挂载下来.
△ 算下来,10步.
用了subPath, 的确节俭了工作量: (还是以nfs为例)
- 创立1个PV, 为:
LAMP-volume
- 创立1个PVC, 为:
LAMP-claim
- 再批改
Deployment
配置, 挂载一个PVC, 用subPath辨别.
△ 算下来, 3步.