这篇文章主要介绍Kubernetes volumes有什么用,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!
成都创新互联响应式网站特点就是不管在电脑、平板还是手机上,H5建站都会根据屏幕尺寸自动调节大小、图片分辨率,并且融入一定的动画特效,让网站看起来非常的美观大方。从网站需求对接到网站制作设计、从代码编写到项目上线运维,技术人员全程跟踪,快速响应
容器中的磁盘文件生命周期比较短暂,在一些比较复杂的容器应用中会产生一些问题。一、容器crash后,kubelet会重启该容器,但这些文件会丢失掉。二、pod中的多个容器经常需要共享文件。因此,Kubernetes的Volume应然而生,用于解决这些问题。
在Docker中,也有volumes这个概念,volume只是磁盘上一个简单的目录,或者其他容器中的volume。生命周期也不受管理,并且直到最近他们都是基于本地后端存储的。Docker现在也提供了volume driver,但是现在来说功能也较弱(比如官网提到的Ceph volume driver,现在已经没有维护了)。
Kubernetes的volume,有着明显的生命周期——和使用它的pod生命周期一致。因此,volume生命周期就比运行在pod中的容器要长久,即使容器重启,volume上的数据依然保存着。当然,pod不再存在时,volume也就消失了。更重要的是,Kubernetes支持多种类型的volume,并且pod可以同时使用多种类型的volume。
内部实现中,volume只是一个目录,目录中可能有一些数据,pod的容器可以访问这些数据。这个目录是如何产生的,它后端基于什么存储介质,其中的数据内容是什么,这些都由使用的特定volume类型来决定。
要使用volume,pod需要指定volume的类型和内容(spec.volumes
字段),和映射到容器的位置(spec.containers.volumeMounts
字段)。
容器中的进程可以看到Docker image和volumes组成的文件系统。Docker image处于文件系统架构的root,任何volume都映射在镜像的特定路径上。Volume不能映射到其他volume上,或者硬链接到其他volume。容器中的每个容器必须堵路地指定他们要映射的volume。
Kubernetes支持很多种类的volume,包括:emptyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs、iscsi、flocker、glusterfs、rbd、cephfs、gitRepo、secret、persistentVolumeClaim、downwardAPI、azureFileVolume、azuredisk、vsphereVolume、Quobyte、PortworxVolume、ScaleIO。
当Pod被分配到一个Node上时,emptyDir
volume就第一次被创建,只要Pod还运行在该Node上,该volume就一直存在。就像它名字里介绍的一样,它初始化时是空的。pod中的容器都能够完全读写emptyDir
volume中相同文件,即使volume可能被映射到每个容器中不同的路径下。任何情况下,一旦pod从该Node上移除了,emptyDir
volume中的数据就被永久删除了。注意:容器crash并不会在Node上删除pod,因此emptyDir
volume中的数据依然是安全的。
emptyDir
volume的使用场景有:
1) 临时空间,如基于磁盘的排序场景等;
2) 从crash中通过checkpointing做长时间的计算恢复;
默认的,emptyDir
volume可以存储在任何后端介质之上——普通磁盘、ssd或网络存储,这都取决于你的环境。然而,你也可以设置emptyDir.medium
字段为Memory
,告诉Kubernetes映射tmpfs(基于RAM的文件系统)。tmpfs速度非常快,但要小心它和磁盘不同,一旦机器重启,tmpfs就会被清空,并且,tmpfs上写文件会受到容器内存的限制。
pod示例:
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: gcr.io/google_containers/test-webserver name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {}
hostPath
volume映射node文件系统中的文件或者目录到pod里。大多数Pod都不需要这个功能,但对于一些特定的场景,该特性还是很有作用的。这些场景包括:
1) 运行的容器需要访问Docker内部结构:使用hostPath
映射/var/lib/docker
2) 在容器中运行cAdvisor,使用hostPath
映射/dev/cgroups
不过,使用这种volume要小心,因为:
1) 配置相同的pod(如通过podTemplate创建),可能在不同的Node上表现不同,因为不同节点上映射的文件内容不同
2) 当Kubernetes增加了资源敏感的调度程序,hostPath
使用的资源不会被计算在内
3) 宿主机下创建的目录只有root有写权限。你需要让你的程序运行在privileged container上,或者修改宿主机上的文件权限。
pod示例:
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: gcr.io/google_containers/test-webserver name: test-container volumeMounts: - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: # directory location on host path: /data
rbd
卷可以将Rados Block Device设备映射到pod中。当Pod被移除时,emptyDir
卷的内容会被清空,和emptyDir
不同,rbd
卷的内容还存在着,仅仅是卷被卸载掉而已。也就是说,rbd
卷可以其上的数据一起,再次被映射,数据也可以在pod之间传递。
重要:在使用rbd
卷之前,你必须先安装Ceph环境。
RBD的一个特性就是能够以只读的方式同时映射给多个用户使用。不幸的是,rbd
卷只能被一个用户已可读写的模式映射——不能同时允许多个可写的用户使用。
查看RBD example获取更多细节。
cephfs
卷可以将已经存在的CephFS卷映射到pod中。与rbd
卷相同,当pod被移除时,cephfs
卷的内容还存在着,仅仅是卷被卸载掉而已。另外一点不同的是,CephFS可以同时以可读写的方式映射给多个用户。
查看CephFS example获取更多细节。
有时,可以在一个pod中,将同一个卷共享,使其有多个用处。volumeMounts.subPath
特性可以用来指定卷中的一个子目录,而不是直接使用卷的根目录。
这里有一个使用LAMP栈(Linux Apache MySQL PHP)的pod示例,该pod使用了一个共享的卷。HTML内容映射在它的html
子目录,而数据库则保存在它的mysql
目录。
apiVersion: v1 kind: Pod metadata: name: my-lamp-site spec: containers: - name: mysql image: mysql volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php image: php volumeMounts: - mountPath: /var/www/html name: site-data subPath: html volumes: - name: site-data persistentVolumeClaim: claimName: my-lamp-site-data
emptyDir
或者hostPath
卷的存储介质(磁盘,SSD等)取决于kubelet根目录(如/var/lib/kubelet
)所处文件系统的存储介质。现在没有限制emptyDir
或者hostPath
卷能使用的空间大小,也没有对容器或者pod的资源隔离。
未来,我们期望emptyDir
或者hostPath
卷能够通过resource属性,来请求指定大小的空间,并且选择存储介质类型。
以上是“Kubernetes volumes有什么用”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注创新互联行业资讯频道!