在Kubernetes支持多种类型的卷,而Pod可以同时使用各种类型和任意数量的存储卷。在Pod中通过指定下面的字段来使用存储卷:
spec.volumes:通过此字段提供指定的存储卷
spec.containers.volumeMounts:通过此字段将存储卷挂接到容器中
当前Kubernetes支持如下所列这些存储卷类型,并以hostPath、nfs和persistentVolumeClaim类型的存储卷为例,介绍如何定义存储卷,以及如何在Pod中被使用。
awsElasticBlockStore
azureDisk
azureFile
cephfs
configMap
csi
downwardAPI
emptyDir
fc (fibre channel)
flocker
gcePersistentDisk
gitRepo
glusterfs
hostPath
iscsi
local
nfs
persistentVolumeClaim
projected
portworxVolume
quobyte
rbd
scaleIO
secret
storageos
vsphereVolume
2.1 hostPath
hostPath类型的存储卷用于将宿主机的文件系统的文件或目录挂接到Pod中,除了需要指定path字段之外,在使用hostPath类型的存储卷时,也可以设置type,type支持的枚举值由下表。另外在使用hostPath时,需要注意下面的事项:
具有相同配置的Pod(例如:从同一个podTemplate创建的),可能会由于Node的文件不同,而行为不同。
在宿主机上创建的文件或目录,只有root用户具写入的权限。您要么在容器中以root身份运行进程,要么在主机上修改的文件或目录的权限,以便具备写入内容到hostPath的存储卷中。
https://www.kubernetes.org.cn/4075.html
是的,通过workingDir字段。下面是一个nginx容器的例子,workingDir设置为`/workdir’。
apiVersion: v1 kind: ReplicationController metadata: name: nginx spec: replicas: 1 template: metadata: labels: name: nginx spec: containers: - name: nginx image: mynginximage workingDir: /workdir
DOCKER-LINUX的用户映射# 在这个BUG的基础上做个简单的测试,当文件系统某个目录只能允许ROOT操作的时候,启动一个运行用户为ROOT的容器,使他来操作该目录,结果是成功的。
作者通过例子验证得到了几个结论:
1.linux主机通过uid和gid来控制用户对目录的操作权限,docker容器中也是如此。
2.当docker容器中的操作用户为root时,他相当于宿主机上的root
3.当docker容器中的操作用户为非root时,根据其uid在宿主机上的权限限制获取对应权限
2.1 hostPath hostPath类型的存储卷用于将宿主机的文件系统的文件或目录挂接到Pod中,除了需要指定path字段之外,在使用hostPath类型的存储卷时,也可以设置type,type支持的枚举值由下表。另外在使用hostPath时,需要注意下面的事项:
具有相同配置的Pod(例如:从同一个podTemplate创建的),可能会由于Node的文件不同,而行为不同。 在宿主机上创建的文件或目录,只有root用户具写入的权限。您要么在容器中以root身份运行进程,要么在主机上修改的文件或目录的权限,以便具备写入内容到hostPath的存储卷中。
USER 指定当前用户