kubernetes 的pv/pvc存储

kubernetes 的pv/pvc存储

标签(空格分隔): kubernetes系列


  • 一: kubernetes的PV/PVC存储

一: kubernetes的PV/PVC存储

1.1 pv

PersistentVolume (PV)

是由管理员设置的存储,它是群集的一部分。就像节点是集群中的资源一样,PV 也是集群中的资源。 PV 是
Volume 之类的卷插件,但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节,即 NFS、
iSCSI 或特定于云供应商的存储系统

1.2 pvc


PersistentVolumeClaim (PVC)

是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源,PVC 消耗 PV 资源。Pod 可以请求特定级别的资源
(CPU 和内存)。声明可以请求特定的大小和访问模式(例如,可以以读/写一次或 只读多次模式挂载)


1.3 静态 pv

集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中,可用
于消费

1.4 动态

当管理员创建的静态 PV 都不匹配用户的  PersistentVolumeClaim 时,集群可能会尝试动态地为 PVC 创建卷。此
配置基于  StorageClasses :PVC 必须请求 [存储类],并且管理员必须创建并配置该类才能进行动态创建。声明该
类为  "" 可以有效地禁用其动态配置
要启用基于存储级别的动态存储配置,集群管理员需要启用 API server 上的  DefaultStorageClass [准入控制器]
。例如,通过确保  DefaultStorageClass 位于 API server 组件的  --admission-control 标志,使用逗号分隔的
有序值列表中,可以完成此操作

1.5 绑定

master 中的控制环路监视新的 PVC,寻找匹配的 PV(如果可能),并将它们绑定在一起。如果为新的 PVC 动态
调配 PV,则该环路将始终将该 PV 绑定到 PVC。否则,用户总会得到他们所请求的存储,但是容量可能超出要求
的数量。一旦 PV 和 PVC 绑定后, PersistentVolumeClaim 绑定是排他性的,不管它们是如何绑定的。 PVC 跟
PV 绑定是一对一的映射

二 持久化卷声明的保护

PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除,因为如果被移除的话可能会导致数据丢失
当启用PVC 保护 alpha 功能时,如果用户删除了一个 pod 正在使用的 PVC,则该 PVC 不会被立即删除。PVC 的
删除将被推迟,直到 PVC 不再被任何 pod 使用

2.1 持久化卷类型

PersistentVolume 类型以插件形式实现。Kubernetes 目前支持以下插件类型:
GCEPersistentDisk AWSElasticBlockStore AzureFile AzureDisk FC (Fibre Channel)
FlexVolume Flocker NFS iSCSI RBD (Ceph Block Device) CephFS
Cinder (OpenStack block storage) Glusterfs VsphereVolume Quobyte Volumes
HostPath VMware Photon Portworx Volumes ScaleIO Volumes StorageOS

2.2 持久卷演示代码

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

2.3 PV 访问模式

PersistentVolume 可以以资源提供者支持的任何方式挂载到主机上。如下表所示,供应商具有不同的功能,每个
PV 的访问模式都将被设置为该卷支持的特定模式。例如,NFS 可以支持多个读/写客户端,但特定的 NFS PV 可能
以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式

ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
ReadOnlyMany——该卷可以被多个节点以只读模式挂载
ReadWriteMany——该卷可以被多个节点以读/写模式挂载在命

在命令行中,访问模式缩写为:
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany


2.4 回收策略

Retain(保留)——手动回收
Recycle(回收)——基本擦除( rm -rf /thevolume/* )
Delete(删除)——关联的存储资产(例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷)
将被删除
当前,只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略

2.5 状态

卷可以处于以下的某种状态:
Available(可用)——一块空闲资源还没有被任何声明绑定
Bound(已绑定)——卷已经被声明绑定
Released(已释放)——声明被删除,但是资源还未被集群重新声明
Failed(失败)——该卷的自动回收失败
命令行会显示绑定到 PV 的 PVC 的名称

2.6 持久化nfs 部署 配置

login node04.flyfish 配置nfs 服务
----

yum install -y nfs* nfs-utils rpcbind

mkdir /nfs

chmod 777 /nfs

chown nfsnobody /nfs

cat /etc/exports

/nfs *(rw,no_root_squash,no_all_squash,sync)

systemctl start rpcbind

systemctl start nfs


k8s 所有节点安装nfs 客户端的挂载包

login : node01.flyfish

yum install rpcbind nfs-utils 

mkdir /test
showmount -e 192.168.100.14 

mount -t nfs 192.168.100.14:/nfs /test


配置pv
vim pv.yaml
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
   path: /nfs
   server: 192.168.100.14
---

kubectl apply -f pv.yaml
kubectl get pv 


多创建几个nfs pv
----
login: node04.flyfish

mkdir /nfs1 /nfs2 /nfs3

chmod 777 /nfs1 /nfs2 /nfs3

vim /etc/exportfs
---
/nfs     *(rw,no_root_squash,no_all_squash,sync)
/nfs1    *(rw,no_root_squash,no_all_squash,sync)
/nfs2    *(rw,no_root_squash,no_all_squash,sync)
/nfs3    *(rw,no_root_squash,no_all_squash,sync)
---

service rpcbind restart
service nfs restart
exportfs -V



vim pv1.yaml
------
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv2
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
   path: /nfs1
   server: 192.168.100.14
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv3
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  nfs:
   path: /nfs2
   server: 192.168.100.14
---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv4
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
   path: /nfs3
   server: 192.168.100.14
-----

kubectl apply -f pv1.yaml

kubectl get pv



创建PVC 应用
------
vim pvc.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

---

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: wangyanglinux/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
          - name: www
            mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs"
      resources:
        requests:
          storage: 1Gi
---
kubectl apply -f pvc.yaml
---------
kubectl get pod
kubectl get pv
kubectl get pvc


以上可以看出 这个 pvc 的pod 并没用创建 成功  要求的 副本数是3个 只创建了一个 pod, 因为 如果要在 创建pod 必须满足  accessModes: [ "ReadWriteOnce" ]  与 storageClassName: "nfs"  这两个条件 ,但是 所创建的 pv 只有 nfsv1 同时满足 这样的条件 所以 就 只能创建 一个 pod 

kubectl get pod  

kubectl describe pod web-1


如果想 创建成功 必须给 改变pv的类型 与控制权限
首先删掉nfspv3 与nfspv4

kubectl delete pv nfspv3

kubectl delete pv nfspv4


vim pv2.yaml
------
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv3
spec:
  capacity:
    storage: 30Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
   path: /nfs2
   server: 192.168.100.14
---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv4
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
   path: /nfs3
   server: 192.168.100.14
------
kubectl apply -f pv2.yaml

kubectl get pv

kubectl get pod 

kubectl get pv 

kubectl get pvc 


kubectl describe pv nfspv1
kubectl describe pv nfspv2
kubectl descirbe pv nfspv3
kubectl descirbe pv nfspv4




kubectl get pv
kubectl get pod -o wide

login node04.flyfish

cd /nfs

echo aaaaa > index.html

cd /nfs2 

echo bbbb >> index.html

cd /nfs3 

echo "web2 web2" >> index.html

curl 10.244.1.6
curl 10.244.2.8
curl 10.244.2.7


kubectl delete pod web-0


三 关于 StatefulSet

3.1 StatfulSet的理解

3.1匹配 Pod name ( 网络标识 ) 的模式为:$(statefulset名称)-$(序号),比如上面的示例:web-0,web-1,
web-2

3.2 StatefulSet 为每个 Pod 副本创建了一个 DNS 域名,这个域名的格式为: $(podname).(headless server
name),也就意味着服务间是通过Pod域名来通信而非 Pod IP,因为当Pod所在Node发生故障时, Pod 会
被飘移到其它 Node 上,Pod IP 会发生变化,但是 Pod 域名不会有变化

3.3 StatefulSet 使用 Headless 服务来控制 Pod 的域名,这个域名的 FQDN 为:$(service
name).$(namespace).svc.cluster.local,其中,“cluster.local” 指的是集群的域名

3.4 根据 volumeClaimTemplates,为每个 Pod 创建一个 pvc,pvc 的命名规则匹配模式:
(volumeClaimTemplates.name)-(pod_name),比如上面的 volumeMounts.name=www, Pod
name=web-[0-2],因此创建出来的 PVC 是 www-web-0、www-web-1、www-web-2

3.5删除 Pod 不会删除其 pvc,手动删除 pvc 将自动释放 pv

3.2 statfulset

有序部署:部署StatefulSet时,如果有多个Pod副本,它们会被顺序地创建(从0到N-1)并且,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态。

有序删除:当Pod被删除时,它们被终止的顺序是从N-1到0。

有序扩展:当对Pod执行扩展操作时,与部署一样,它前面的Pod必须都处于Running和Ready状态。
有序删除:


3.3 StatefulSet使用场景:

1.稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于 PVC 来实现。

2.稳定的网络标识符,即 Pod 重新调度后其 PodName 和 HostName 不变。
有序部署,有序扩展,基于 init containers 来实现。

3.有序收缩。

3.4 statefulset 整体删除步骤

先删除 pod 

kubectl delete pod --all 

在删除svc 

kubectl delete svc --all

在删除deployment

kubectl delete deploy --all

在删除statefulset 

kubectl delete statefulset --all

在删除 pvc 

kubectl delete pvc --all 

删除 pv 

kubectl delete pv --all

然后 在删掉 nfs挂载里面的文件



kubernetes 的pv/pvc存储

原文地址:https://blog.51cto.com/flyfish225/2481950

时间: 03-26

kubernetes 的pv/pvc存储的相关文章

使用Ceph集群作为Kubernetes的动态分配持久化存储

使用Docker快速部署Ceph集群 , 然后使用这个Ceph集群作为Kubernetes的动态分配持久化存储. Kubernetes集群要使用Ceph集群需要在每个Kubernetes节点上安装ceph-common

Kubernetes基础概念总结

1.基础架构 1.1 Master Master节点上面主要由四个模块组成:APIServer.scheduler.controller manager.etcd. APIServer.APIServer负责对外提供RESTful的Kubernetes API服务,它是系统管理指令的统一入口,任何对资源进行增删改查的操作都要交给APIServer处理后再提交给etcd.如架构图中所示,kubectl(Kubernetes提供的客户端工具,该工具内部就是对Kubernetes API的调用)是直接

深入理解开源数据库中间件 Vitess:核心特性以及如何进行数据存储的堆叠

概述 Vitess 是一个用于 MySql 扩展的数据库解决方案.它以能够像运行在专用硬件上那样有效地运行在云体系为目标进行架构.它集 MySql 数据库的很多重要特性和 NoSQL 数据库的可扩展性于一体.Vitess 已经成功侍服了 2011 年以来所有的 YouTube 数据库流量. Kubernetes 上的 Vitess Kubernetes 是 Google 开源的 Docker 容器集群管理系统,Vitess 是 Kubernetes 用户的逻辑存储引擎的一个可选项.Kuberne

k8s1.5.4挂载volume之glusterfs

volume的例子集合 https://github.com/kubernetes/kubernetes/tree/master/examples/volumes http://www.dockerinfo.net/2926.html http://dockone.io/article/2087 https://www.kubernetes.org.cn/1146.html https://kubernetes.io/docs/user-guide/volumes/ k8s集群安装部署 http

+++++++lvm2基本应用,扩展及缩减实现

LVM2 逻辑卷管理器第二版,Logical Volume Manager Version 2,将多个底层设备组织成一个单一的逻辑设备. 1.纯软件实现的虚拟层次上的软设备lvm2 2.磁盘损坏时,数据恢复困难.人为损坏数据,恢复困难. 一.LVM原理 PV(物理卷):在任何块设备(分区.RAID.磁盘)之上,附加一层元数据. **在删除PV前,先将要移除PV上的数据移动至其他PV之上** VG(卷组):在PV的存储空间中,更低层次上划分多个相同大小的PE,将所有PE组合成一个逻辑上的层次VG.

virtual 修饰符与继承对析构函数的影响(C++)

以前,知道了虚函数表的低效性之后,一直尽量避免使用之.所以,在最近的工程中,所有的析构函数都不是虚函数.今天趁着还书的机会到图书馆,还书之后在 TP 分类下闲逛,偶然读到一本游戏编程书,里面说建议将存在派生的类的析构函数都设置为 virtual.例如 ParentClass 和 ChildClass(派生自 ParentClass),如果 ParentClass 的 ~ParentClass() 不是 virtual 的话,以下代码会产生潜在的问题: 1 ParentClass *pClass

Rancher Labs亮相SCALE15x:三大演讲福利放送

为期四天的第15届SCALE(The Southern California Linux Expo)已落下帷幕,这是美国规模最大的开源软件和Linux用户的盛会之一. Rancher Labs的工程师们受组委会之邀进行了三个主题演讲: 重构到微服务:实践案例分享 如何为容器运行构建CNI插件 管理大规模Kubernetes面临的挑战及经验教训 演讲内容及PPT请文内自取! SCALE(The Southern California Linux Expo,南加州Linux博览会)是美国规模最大的开

逻辑卷管理器(LVM2)的使用(CentOS6)和快照功能

LVM2: LVM:Logical Volume Manager,Version2 使用纯软件来组织一个或多个底层硬件设备为一个抽象的逻辑设备. dm:device mapper(设备映射组建):将一个或多个底层块设备组织称一个逻辑设备的模块. LVM机制: 将底层块设备的磁盘分区创建成物理卷PV,将PV合并成更高层的VG卷组,能将一个以上的物理硬盘分区加入进去组成成逻辑设备,类似于扩展分区,没有办法直接使用,所以要在VG之上创建LV,这才是真正的逻辑卷,每个LV都是一个独立的文件系统,可以将它

简述LVM原理及其实现

LVM的全称是:Logical Volume Manager(逻辑卷管理器),由内核中的DM模块提供此项功能, LVM的组成结构,如下图所示 LV可以把一个或多个任意(包括RAID)的块设备做成物理卷(PV),将他们组合起来,并把一块或多块PV的存储能力抽象成一个一个的物理盘区(PE),这些PV的集合称为为一个卷组(VG).其中PE的大小为2^n.PV的大小是块设备的大小,VG的大小是左右PV的大小之和,LV的大小最大可以达到VG的大小.并且可以对LV执行mke2fs命令对其创建文件系统并挂载至

pv和pvc状态

原文地址:https://kubernetes.cn/topics/46 API Server 和 PVController API Server: 这个组件提供对API的支持,响应REST操作,验证API模型和更新etcd中的相应对象 PVController: 是ontroller.volume.persistentvolume.PersistentVolumeController的简称,负责监听PV和PVC资源的改动Event,取得最新的PV和PVC并维护它们之间的绑定关系. 通常情况下A