淄博企业网站建设,做美图 网站有哪些东西,wordpress 定制主题,商务咨询网站源码Volume 卷
容器中的文件在磁盘上是临时存放的#xff0c;这给容器中运行的特殊应用带来了一些问题。首先#xff0c;当容器崩溃时#xff0c;kubectl将重新启动容器#xff0c;容器中的文件将会丢失--应为容器会以干净的状态重建。其次#xff0c;当在一个Pod中运行多个容…Volume 卷
容器中的文件在磁盘上是临时存放的这给容器中运行的特殊应用带来了一些问题。首先当容器崩溃时kubectl将重新启动容器容器中的文件将会丢失--应为容器会以干净的状态重建。其次当在一个Pod中运行多个容器是常常需要在这些容器之间共享文件。Kubernetes抽象出Volume对象来解决这2个问题。
Docker也有Volume的概念但对它是有少量且松散的管理。在Docker中Volume是磁盘上或者另外一个容器内的一个目录。直到最近Docker才支持对基于本地磁盘的Volume的生存期进行管理。虽然Docker现在也能提供Volume驱动程序但是目前功能还非常有限例如截止Docker 1.7每个容器只允许有一个Volume驱动程序并且无法将参数传递给卷。
另一方面Kubernetes卷具有明确的生命周期--与包裹它的pod相同。因此卷比Pod中运行的任何容器的存活周期都长在容器重新启动时数据也会得到保留。当然当一个Pod不再存在时卷也将不再存在。更重要的是Kubernetes支持许多类型的卷Pod也能同时使用任意数量的卷。
卷的核心是包含一些数据的目录Pod中的容器可以访问该目录特定的卷类型可以决定这个目录如何形成的并能决定它支持何种介质以及目录中存放什么内容。
使用卷时Pod声明中需要提供卷的类型 spec.volumes字段和卷挂载的位置spec.containers.volumeMounts字段
Kubernetes提供了众多的volume类型包括emptyDir、hostPath、nfs、glusterfs、cephfs、ceph
emptyDir
当Pod指定到某个节点上时首先创建的是一个emptyDir卷并且只要Pod在该节点上运行卷就一直存在。就像它的名称一样卷最初是空的。尽管Pod中的容器挂载emptyDir卷的路径可能相同也可能不同但是这些容器都可以读写emptyDir卷中相同的文件。当Pod从节点上删除时emptyDir卷中的数据也会永久删除。
容器崩溃并不会导致Pod从节点上移除因此容器崩溃时emptyDir卷中的数据是安全的。
emptyDir的用途
缓存空间例如基于磁盘的归并排序为耗时较长的计算任务提供检查点以便任务能方便地从崩溃状态恢复执行在web服务器容器服务数据时保存这些文件
hostPath
hostPath卷能将主机节点文件系统上的文件或目录挂载到Pod中。虽然这不是大多数pod需要的但是它为一些应用提供强大的持久化能力。
apiVersion: v1
kind: Pod
metadata:name: myapplabels:name: myapp
spec:containers:- name: myappimage: nginxvolumeMounts:- mountPath: /test-nginxname: hostpathvolumeresources:limits:memory: 128Micpu: 500mports:- containerPort: 80volumes:- name: hostpathvolumehostPath:path: /tmp/nginxtype: DirectoryOrCreate
NFS卷
很多应用需要在集群内部有一个统一的地方存储文件比如图片日志等而使用hostPath方式并不灵活应为需要指定host的地址
挂载NFS卷
1、安装nfs服务
yum install -y nfs-utils
2、修改配置
vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
3、在master节点启动nfs
systemctl enable --now rpcbind
systemctl enable --now nfs
4、创建Pod挂载nfs卷
apiVersion: v1
kind: Pod
metadata:name: myapplabels:name: myapp
spec:containers:- name: myappimage: nginxvolumeMounts:- mountPath: /usr/share/nginx/htmlname: nfsresources:limits:memory: 128Micpu: 500mports:- containerPort: 80volumes:- name: nfsnfs:server: masterpath: /nfsdata
PersistantVolume持久化存储
存储的管理是一个与计算实例的管理完全不同的问题。PersistantVolume子系统为用户和管理员提供了一组API将存储如果供应的细节从其如何被使用中抽象出来。为了实现这点我们引入了两个新的API资源PersistantVolume和PersistantVolumeClaim。
持久卷PersistantVolume PV是集群中的一块存储可以由管理员事先提供或者使用存储类来动态提供。持久卷是集群资源就像节点也是集群资源一样PV持久卷和普通Volume一样也是使用卷插件来实现的只是他们拥有独立于任何使用PV的Pod的生命周期。此API对象中记录了存储的实现细节无论背后是nfs、iSCSI还是特定于云平台的存储系统。
持久卷申领PersistantVolumeClain PVC表达的是用户对存储的请求。概念上与Pod类似。Pod会耗节点资源而PVC申领会耗用PV资源。Pod可以请求特定数量的资源cpu、内存同样PVC申领也可以请求特定大小和访问模式
尽管PVC允许用户消耗抽象的存储资源常见的情况是针对不同的用户需要具有不同属性的PV卷。集群管理员需要能够提供不同性质的PV并且这些PV卷之间的差别仅限于卷大小和访问模式同时又不能将卷是如何实现的这些细节暴露给用户。为了满足这类需求就有了存储类StorageClass资源
示例pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:name: pv-demolabels:name: pv-demo
spec:capacity:storage: 5GiaccessModes:- ReadWriteOncepersistentVolumeReclaimPolicy: Recyclenfs:path: /nfsdataserver: master
[rootmaster k8s]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-demo 5Gi RWO Recycle Available 29s
[rootmaster k8s]#
PersistantVolumeClain
访问模式
Claim在请求具有特定访问模式的存储时使用与卷相同的访问模式约定
卷模式
Claim使用与卷相同的约定来表明是将卷作为文件系统还是块设备来使用
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvc-demolabels:name: pvc-demo
spec:accessModes:- ReadWriteOnceresources:requests:storage: 2Gi
[rootmaster k8s]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-demo Bound pv-demo 5Gi RWO 5s
[rootmaster k8s]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-demo 5Gi RWO Recycle Bound default/pvc-demo 8m32s
[rootmaster k8s]#
StorageClass
Kubernetes提供了一套可以自动创建PV的机制Dynamic Provisioning这个机制单独核心就是StorageClass这个API对象
StorageClass对象定义了以下两部分内容
1.PV的属性比如存储类型、Volume大小等
2.创建这种PV需要用到的存储插件
为什么需要StorageClass
在一个大规模的Kubernetes集群里可以有成千上万个PVC这就意味着运维人员必须实现创建出多个PV。此外随着项目的需要会有新的PVC不断被提交那么运维人员就需要不断的添加新的PV否则新Pod就会因为PVC绑定不到PV从而导致创建失败。而且通过PVC请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求。
而且不同的应用对于存储性能的要求也不尽相同比如读写速度、并发性能等为了解决这一问题Kubernetes引入了一个新的资源对象StorageClass通过StorageClass的定义管理员可以将存储资源定义为某种资源类型比如快速存储、慢性存储等用户根据StorageClass的描述就可以非常直观的知道各种存储资源的具体特性了这样就可以根据应用特性去申请合适的存储资源了。
StorageClass对象的命名很重要用户使用这个命名请求生成一个特定的类当创建StorageClass对象时管理员设置StorageClass对象的命名和其他参数一旦创建了对象就不能再对其更新。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: managed-nfs-storage
provisioner: qgg-nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:archiveOnDelete: false 示例PVCStorage挂载NFS
1、创建Persistent Volume Provisioner
nfs-provisioner.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-client-provisionerlabels:app: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default #与RBAC文件中的namespace保持一致
spec:replicas: 1strategy:type: Recreateselector:matchLabels:app: nfs-client-provisionertemplate:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisionercontainers:- name: nfs-client-provisionerimage: registry.cn-beijing.aliyuncs.com/qingfeng666/nfs-client-provisioner:v3.1.0volumeMounts:- name: nfs-client-rootmountPath: /persistentvolumesenv:- name: PROVISIONER_NAMEvalue: qgg-nfs-storage #provisioner名称,请确保该名称与 nfs-StorageClass.yaml文件中的provisioner名称保持一致- name: NFS_SERVERvalue: master #NFS Server IP地址- name: NFS_PATHvalue: /nfsdata #NFS挂载卷volumes:- name: nfs-client-rootnfs:server: master #NFS Server IP地址path: /nfsdata #NFS 挂载卷
2、创建用户和角色RBAC
rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default #根据实际环境设定namespace,下面类同
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: nfs-client-provisioner-runner
rules:- apiGroups: []resources: [persistentvolumes]verbs: [get, list, watch, create, delete]- apiGroups: []resources: [persistentvolumeclaims]verbs: [get, list, watch, update]- apiGroups: [storage.k8s.io]resources: [storageclasses]verbs: [get, list, watch]- apiGroups: []resources: [events]verbs: [create, update, patch]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: run-nfs-client-provisioner
subjects:- kind: ServiceAccountname: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
roleRef:kind: ClusterRolename: nfs-client-provisioner-runnerapiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: leader-locking-nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
rules:- apiGroups: []resources: [endpoints]verbs: [get, list, watch, create, update, patch]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: leader-locking-nfs-client-provisioner
subjects:- kind: ServiceAccountname: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
roleRef:kind: Rolename: leader-locking-nfs-client-provisionerapiGroup: rbac.authorization.k8s.io
3、创建storage-class
storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: managed-nfs-storage
provisioner: qgg-nfs-storage #这里的名称要和provisioner配置文件中的环境变量PROVISIONER_NAME保持一致
parameters:archiveOnDelete: false
4、创建PVC
pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: test-claimannotations:volume.beta.kubernetes.io/storage-class: managed-nfs-storage #与nfs-StorageClass.yaml metadata.name保持一致
spec:accessModes:- ReadWriteManyresources:requests:storage: 1Mi
5、创建Pod引用Storage Class
pod.yaml
kind: Pod
apiVersion: v1
metadata:name: test-pod
spec:containers:- name: test-podimage: nginxcommand:- /bin/shargs:- -c- touch /mnt/SUCCESS exit 0 || exit 1volumeMounts:- name: nfs-pvcmountPath: /mntrestartPolicy: Nevervolumes:- name: nfs-pvcpersistentVolumeClaim:claimName: test-claim #与PVC名称保持一致
