k8s中的volume
Volume(存储卷)是Pod中能够被多个容器访问的共享目录。Kubermetes的Volume概念、用途和目的与Docker的Volume比较类似,但两者不能等价。 K8s中的Volume被定义在Pod上,然后被一个Pod里的多个容器挂载到具体的文件目录下(即每个容器共享一个卷但挂载目录不同)。 K8s中的Volume与Pod的生命周期相同,但与容器的生命周期不相关,当容器终止或者重启时,Volume中的数据也不会丢失。
为什么要用volume
容器中的文件在磁盘上是临时存放的,这给容器中运行的特殊应用程序带来一些问题。首先,当容器崩溃时,kubelet 将重新启动容器,容器中的文件将会丢失,因为容器会以干净的状态重建。其次,当在一个 Pod 中同时运行多个容器时,常常需要在这些容器之间共享文件。 因此K8s 抽象出 Volume 对象来解决这两个问题。
volume特点
K8s卷具有明确的生命周期,与包裹它的 Pod 相同。 卷比Pod中运行的任何容器的存活期都长,在容器重新启动时数据也会得到保留。 当一个 Pod 不再存在时,卷也将不再存在。 K8s 可以支持许多类型的卷,Pod 也能同时使用任意数量的卷。 卷不能挂载到其他卷,也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置。
K8s支持多种类型的Volume
Kubernetes 支持下列类型的卷:
- awsElasticBlockStore 、azureDisk、azureFile、cephfs、cinder、configMap、csi
- downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker
- gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、
- nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd
- scaleIO、secret、storageos、vsphereVolume
官方文档可点击查看。
演示环境
server1:172.25.38.1 harbor仓库端
server2:172.25.38.2 k8s master端
server3:172.25.38.3 k8s node端
server4:172.25.38.4 k8s node端
emptyDir卷
当 Pod 指定到某个节点上时,首先创建的是一个 emptyDir 卷,并且只要 Pod 在该节点上运行,卷就一直存在。 就像它的名称表示的那样,卷最初是空的,并且无须指定宿主机上对应的目录文件,因为这是Kubernetes自动分配的一个 目录,当Pod从Node上移除时,emptyDir中的数据也会被永久删除。
emptyDir的一些用途如下:
- 临时空间,例如用于某些应用程序运行时所需的临时目录,且无须永久保留。
- 长时间任务的中间过程CheckPoint的临时保存目录。
- 一个容器需要从另一个容器中获取数据的目录(多容器共享目录)。
目前,用户无法控制emptyDir使用的介质种类。如果kubelet的配置是使用硬盘,那么所有emptyDir都将被创建在该硬盘上。Pod在将来可以设置emptyDir是位于硬盘、固态硬盘上还是基于内存的tmpfs上。
多容器共享卷
创建一个卷的目录,在里面编写卷相关的yaml配置文件。 vol1.yaml文件内容如下:
apiVersion: v1
kind: Pod
metadata:
name: vol1
spec:
containers:
- image: busyboxplus
name: vm1
command: ["sleep", "300"]
volumeMounts:
- mountPath: /cache
name: cache-volume
- name: vm2
image: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: cache-volume
volumes:
- name: cache-volume
emptyDir:
medium: Memory
sizeLimit: 100Mi
进入第一个容器挂载目录下写入文件 进入另一个容器的挂载目录,可以看到我们在vm1容器里写入的文件,说明卷是共享的
emptyDir卷缺点
不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出,但是这个时间内,其实对node还是有风险的。 影响kubernetes调度,因为empty dir并不涉及node的resources,这样会造成Pod“偷偷”使用了node的内存,但是调度器并不知晓;用户不能及时感知到内存不可用。
示例:配置文件里限制卷大小为100M,生成一个200M的空文件,卷被“撑爆”,容器停止运行。 文件超过sizeLimit,则一段时间后(1-2分钟)会被kubelet evict掉。之所以不是“立即”被evict,是因为kubelet是定期进行检查的,这里会有一个时间差。
hostPath 卷
hostPath卷应用场景
hostPath为在Pod上挂载宿主机上的文件或目录,它通常可以用于以下几方面: 1、容器应用程序生成的日志文件需要永久保存时,可以使用宿主机的高速文件系统进行存储。 2、需要访问宿主机上Docker引擎内部数据结构的容器应用时,可以通过定义hostPath为宿主机/var/lib/docker目录,使容器内部应用可以直接访问Docker的文件系统。
使用hostPath卷时,需要注意的点:
1、在不同的Node上具有相同配置的Pod,可能会因为宿主机上的目录和文件不同而导致对Volume上目录和文件的访问结果不一致。 2、如果使用了资源配额管理,则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理。 3、基础主机上创建的文件或目录只能由 root 用户写入。您需要在 特权容器 中以 root 身份运行进程,或者修改主机上的文件权限以便容?能够写入 hostPath 卷。
hostPath 卷的 type
除了必需的 path 属性之外,用户可以选择性地为 hostPath 卷指定 type。
创建hostPath 卷
编写yaml配置文件,内容如下
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: nginx
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
path: /data
type: DirectoryOrCreate
应用配置文件 server3上原本没有这个目录,现在自动创建了 在server2里写入文件,在server3/data目录下也能看到
NFS共享文件
在server1、2、3、4都下载nfs组件 都启动nfs 更改server1的配置文件,/etc/exports文件内容如下
/mnt/nfs *(rw,no_root_squash)
server2访问server1的nfs成功! 编写配置文件nfs.yaml来共享server1的文件系统,内容如下
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: nginx
name: test-container
volumeMounts:
- mountPath: /usr/share/nginx/html
name: test-volume
volumes:
- name: test-volume
nfs:
server: 172.25.38.1
path: /mnt/nfs
应用配置文件,查看pod的详细信息,共享成功 在server1的nfs数据目录下写入文件 在server2进入pod挂载目录也可以看到
PersistentVolume持久卷(PV)
什么是PV
PersistentVolume(持久卷,简称PV)是集群内,由管理员提供的网络存储的一部分。就像集群中的节点一样,PV也是集群中的一种资源。它也像Volume一样,是一种volume插件,但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象,捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。
什么是PVC
PersistentVolumeClaim(持久卷声明,简称PVC)是用户的一种存储请求。它和Pod类似,Pod消耗Node资源,而PVC消耗PV资源。Pod能够请求特定的资源(如CPU和内存)。PVC能够请求指定的大小和访问的模式(可以被映射为一次读写或者多次只读)。
PV与PVC的关系
PVC与PV的绑定是一对一的映射。没找到匹配的PV,那么PVC会无限期得处于unbound未绑定状态。
PV的使用、释放、回收
-
使用 Pod使用PVC就像使用volume一样。集群检查PVC,查找绑定的PV,并映射PV给Pod。对于支持多种访问模式的PV,用户可以指定想用的模式。一旦用户拥有了一个PVC,并且PVC被绑定,那么只要用户还需要,PV就一直属于这个用户。用户调度Pod,通过在Pod的volume块中包含PVC来访问PV。 -
释放 当用户使用PV完毕后,他们可以通过API来删除PVC对象。当PVC被删除后,对应的PV就被认为是已经是“released”了,但还不能再给另外一个PVC使用。前一个PVC的属于还存在于该PV中,必须根据策略来处理掉。 -
回收 PV的回收策略告诉集群,在PV被释放之后集群应该如何处理该PV。当前,PV可以被Retained(保留)、 Recycled(再利用)或者Deleted(删除)。保留允许手动地再次声明资源。对于支持删除操作的PV卷,删除操作会从Kubernetes中移除PV对象,还有对应的外部存储(如AWS EBS,GCE PD,Azure Disk,或者Cinder volume)。动态供给的卷总是会被删除。
参数解释
-
访问模式 ReadWriteOnce – 该volume只能被单个节点以读写的方式映射 ReadOnlyMany – 该volume可以被多个节点以只读方式映射 ReadWriteMany – 该volume可以被多个节点以读写的方式映射 -
在命令行中,访问模式可以简写为: RWO - ReadWriteOnce ROX - ReadOnlyMany RWX - ReadWriteMany -
回收策略 Retain:保留,需要手动回收 Recycle:回收,自动删除卷中数据 Delete:删除,相关联的存储资产,如AWS EBS,GCE PD,Azure Disk,or OpenStack Cinder卷都会被删除
当前,只有NFS和HostPath支持回收利用,AWS EBS,GCE PD,Azure Disk,or OpenStack Cinder卷支持删除操作。
- 状态:
Available:空闲的资源,未绑定给PVC Bound:绑定给了某个PVC Released:PVC已经删除了,但是PV还没有被集群回收 Failed:PV在自动回收中失败了 命令行可以显示PV绑定的PVC名称。
创建静态PV
静态PV:集群管理员创建多个PV,它们携带着真实存储的详细信息,这些存储对于集群用户是可用的。它们存在于Kubernetes API中,并可用于存储使用。
编写yaml配置文件,内容如下,共享nfs的资源创建
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /mnt/nfs
server: 172.25.38.1
应用文件,创建出pv,查看详细信息目前还是可用状态,共享server1的文件系统 创建pvc,配置文件内容如下
vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
storageClassName: nfs
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
查看pvc和pv已互相绑定 创建pod,将pvc挂载到指定目录
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: nginx
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: pv1
volumes:
- name: pv1
persistentVolumeClaim:
claimName: pvc1
在nfs端写入文件,进入pod内挂载点可看到是同步的 进入pod内挂载点写入东西,在nfs端同样可以同步 看下ip,访问也没有问题
创建动态PV
动态PV:当管理员创建的静态PV都不匹配用户的PVC时,集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。
StorageClass
StorageClass提供了一种描述存储类(class)的方法,不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。
每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段, 这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。
StorageClass的属性 Provisioner(存储分配器):用来决定使用哪个卷插件分配 PV,该字段必须指定。可以指定内部分配器,也可以指定外部分配器。外部分配器的代码地址为: kubernetes-incubator/external-storage,其中包括NFS和Ceph等。
Reclaim Policy(回收策略):通过reclaimPolicy字段指定创建的Persistent Volume的回收策略,回收策略包括:Delete 或者 Retain,没有指定默认为Delete。
更多属性查看:https://kubernetes.io/zh/docs/concepts/storage/storage-classes/
创建新目录,写创建sc的yaml配置文件 内容如下:
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
namespace: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-provisioner-runner
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
- 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: ServiceAccount
name: nfs-client-provisioner
namespace: nfs-client-provisioner
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
namespace: nfs-client-provisioner
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
namespace: nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: nfs-client-provisioner
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
namespace: nfs-client-provisioner
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: nfs-subdir-external-provisioner:v4.0.0
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: westos.org/nfs
- name: NFS_SERVER
value: 172.25.38.1
- name: NFS_PATH
value: /mnt/nfs
volumes:
- name: nfs-client-root
nfs:
server: 172.25.38.1
path: /mnt/nfs
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
provisioner: westos.org/nfs
parameters:
archiveOnDelete: "true"
创建一个namespace 应用配置文件 已经有了sc 编写创建pvc的配置文件,内容如下:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: nfs-pv1
annotations:
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
创建pvc,根据sc设置的规则分配绑定pv 在nfs端可以看到已经自动创建了卷目录 删掉pvc 再看nfs端目录名已变,自动回收了 再重新创建pvc,然后写创建pod的文件,将pvc挂载,文件内容如下
kind: Pod
apiVersion: v1
metadata:
name: test-pod-2
spec:
containers:
- name: test-pod
image: nginx
volumeMounts:
- name: nfs-pvc
mountPath: "/usr/share/nginx/html"
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: nfs-pv1
创建pod后访问出现403错误,因为没有发布页面 在nfs端写个发布页面 再回来访问,成功!说明因为挂载了pvc,所以是同步的 删除pod,删除pvc 将sc配置文件里的自动回收true改为false关闭 重新应用sc的yaml配置文件 重新创建pvc,同之前一样,自动绑定pv 在nfs端可以看到自动创建的目录
关闭自动同步
删掉pvc和pv 再看目录没了,因为没开自动回收
手动指定sc
默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims 配置存储(只能有一个默认StorageClass)。 如果没有默认StorageClass,PVC 也没有指定storageClassName 的值,那么意味着它只能够跟 storageClassName 也是“”的 PV 进行绑定。
示例: 将创建pvc的配置文件里说明sc的注释掉 重新应用,可以看到没有策略,创建的pvc没有绑定pv 手动补丁加上sc 删除pvc再重新创建,可以看到pv绑定成功
StatefulSet控制器控制pod
StatefulSet将应用状态抽象成了两种情况: 1、拓扑状态:应用实例必须按照某种顺序启动。新创建的Pod必须和原来Pod的网络标识一样。 2、存储状态:应用的多个实例分别绑定了不同存储数据。
StatefulSet给所有的Pod进行了编号,编号规则是:$(statefulset名称)-$(序号) ,从0开始。
Pod被删除后重建,重建Pod的网络标识也不会改变,Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来,并且为每个Pod提供了一个固定且唯一的访问入口,即Pod对应的DNS记录。
示例: 编写创建svc的配置文件,内容如下
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
创建svc,查看详细信息没有后端 编写创建StatefulSet控制器的配置文件,内容如下
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx-svc"
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
创建StatefulSet控制器 再查看服务已有后端 将StatefulSet控制器配置文件里的副本数改为6个 查看创建过程,是按序创建的(之前都是一起创建,是无序的) 将StatefulSet控制器配置文件里的副本数改为0个 相当于删除控制器,可以看到也是按序删除的 将StatefulSet控制器配置文件里的副本数改为3个 重新应用文件 运行一个pod,进入查看解析如下,curl访问没有问题 换个镜像试试 进入pod查看解析,访问也没有问题
实现负载均衡
到nfs端可以看到自动创建的卷目录 分别写入发布页面 直接访问服务,实现了负载均衡
|