深入玩转K8S之存储资源管理

本篇我们来看下K8S中的存储资源管理,说到K8S的存储资源管理分为几个概念:Vloume、PV、PVC等,本篇我们主要侧重于PV和PVC。

下面简单说下几个概念:

Volume 的生命周期独立于容器,Pod 中的容器可能被销毁和重建,但 Volume 会被保留。Kubernetes Volume 实际上就是一个目录,这一点与 Docker Volume 类似。当 Volume 被 mount 到 Pod,Pod 中的所有容器都可以访问这个 Volume。Kubernetes Volume 也支持多种 backend 类型,包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等,完整列表可参考 https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

Volume 提供了非常好的数据持久化方案,不过在可管理性上还有不足。

拿前面 AWS EBS 的例子来说,要使用 Volume,Pod 必须事先知道如下信息:

1.     当前 Volume 来自 AWS EBS。

2.     EBS Volume 已经提前创建,并且知道确切的 volume-id。

Pod 通常是由应用的开发人员维护,而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息:

1.     要么询问管理员。

2.     要么自己就是管理员。

这样就带来一个管理上的问题:应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大,特别是对于生成环境,考虑到效率和安全性,这就成了必须要解决的问题。

Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。

PersistentVolume (PV) 是外部存储系统中的一块存储空间,由管理员创建和维护。与 Volume 一样,PV 具有持久性,生命周期独立于 Pod。

PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时,用户可以创建一个 PVC,指明存储资源的容量大小和访问模式(比如只读)等信息,Kubernetes 会查找并提供满足条件的 PV。

有了 PersistentVolumeClaim,用户只需要告诉 Kubernetes 需要什么样的存储资源,而不必关心真正的空间从哪里分配,如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理,只有管理员才应该关心创建 PersistentVolume 的细节信息。

Kubernetes 支持多种类型的 PersistentVolume,比如 AWS EBS、Ceph、NFS 等,完整列表请参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

下面我们用 NFS 来看下PersistentVolume 的使用方法。

首先在各个节点安装nfs-utils以及rpcbind,不然后续会报错。

yum install –y nfs-utils rpcbind

安装完之后设置共享目录以及权限。

vi /etc/exports
/mnt * (rw,no_root_squash,no_all_squash,sync)
 
systemctl restart nfs

systemctl restart rpcbind

完事之后重启nfs和各节点的rpcbind服务,使用showmount –e来检查是否成功。

下面创建一个 PV mypv1,配置文件 nfs-pv1.yml 如下:

kubectl apply -f nfs-pv1.yml

文件解释:

① capacity 指定 PV 的容量为 1G。

② accessModes 指定访问模式为 ReadWriteOnce,支持的访问模式有:
ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。

③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle,支持的策略有:
Retain – 需要管理员手工回收。
Recycle – 清除 PV 中的数据,效果相当于执行 rm -rf /thevolume/*。
Delete – 删除 Storage Provider 上的对应存储资源,例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类,PVC 可以指定 class 申请相应 class 的 PV。

⑤ 指定 PV 在 NFS 服务器上对应的目录。

接下来创建 PVC mypvc1,配置文件 nfs-pvc1.yml 如下:

kubectl apply -f nfs-pvc.yml

PVC 就很简单了,只需要指定 PV 的容量,访问模式和 class。

从 kubectl get pvc 和 kubectl get pv 的输出可以看到 mypvc1 已经 Bound 到 mypv1,申请成功。

接下来就可以在 Pod 中使用存储了,Pod 配置文件 pod1.yml 如下:

kubectl apply -f pod1.yml

下面来验证下PV是否可用:

OK,到这里本章就结束了,可以看到,在 Pod 中创建的文件 /mydata/devin 已经保存到了 NFS 服务器目录 /mnt/k8s/pv1 中。

本文参考链接:

http://blog.51cto.com/goome/2133827

https://www.cnblogs.com/DaweiJ/articles/8618317.html

原文地址:http://blog.51cto.com/devingeng/2151028

时间: 2024-11-10 15:40:03

深入玩转K8S之存储资源管理的相关文章

深入玩转K8S之利用Label控制Pod位置

首先介绍下什么是Label? Label是Kubernetes系列中一个核心概念.是一组绑定到K8s资源对象上的key/value对.同一个对象的labels属性的key必须唯一.label可以附加到各种资源对象上,如Node,Pod,Service,RC等. 通过给指定的资源对象捆绑一个或多个不用的label来实现多维度的资源分组管理功能,以便于灵活,方便地进行资源分配,调度,配置,部署等管理工作. 默认配置下,Scheduler 会将 Pod 调度到所有可用的 Node.不过有些实际情况我们

深入玩转K8S之智能化的业务弹性伸缩和滚动更新操作

在上篇我们讲到了较为傻瓜初级的弹性伸缩和滚动更新,那么接下来我们来看看较为高级的智能的滚动更新.本节的知识点呢是K8S的liveness和readiness探测,也就是说利用健康检查来做更为智能化的弹性扩容和滚动更新. 那为什么说是比较智能化呢,因为在实际生产环境中会遇到这样那样的问题,比如:容器里面应用挂了或者说新启动的容器里面应用还没有就绪等等,所以说就需要进行探测来检验容器是否满足需求. 那么一般的检测分为几种,比如:进程检测.业务检测. 进程检测呢很好理解,也就是说通过检测容器进程来验证

k8s之存储卷及pvc

1.存储卷概述 因为pod是有生命周期的,pod一重启,里面的数据就没了,所以我们需要数据持久化存储,在k8s中,存储卷不属于容器,而是属于pod,也就是说同一个pod中的容器可以共享一个存储卷,存储卷可以是宿主机上的目录,也可以是挂载在宿主机上的外部设备. 存储卷类型: emptyDIR存储卷:pod一重启,存储卷也删除,这叫emptyDir存储卷,一般用于当做临时空间或缓存关系; hostPath存储卷:宿主机上目录作为存储卷,这种也不是真正意义实现了数据持久性; SAN(iscsi)或NA

从零开始入门 K8s | 应用存储和持久化数据卷:核心知识

作者 | 至天 阿里巴巴高级研发工程师 一.Volumes 介绍 Pod Volumes 首先来看一下 Pod Volumes 的使用场景: 场景一:如果 pod 中的某一个容器在运行时异常退出,被 kubelet 重新拉起之后,如何保证之前容器产生的重要数据没有丢失? 场景二:如果同一个 pod 中的多个容器想要共享数据,应该如何去做? 以上两个场景,其实都可以借助 Volumes 来很好地解决,接下来首先看一下 Pod Volumes 的常见类型: 本地存储,常用的有 emptydir/ho

从零开始入门 K8s | Kubernetes 存储架构及插件使用

本文整理自<CNCF x Alibaba 云原生技术公开课>第 21 讲. 导读:容器存储是 Kubernetes 系统中提供数据持久化的基础组件,是实现有状态服务的重要保证.Kubernetes 默认提供了主流的存储卷接入方案(In-Tree),同时也提供了插件机制(Out-Of-Tree),允许其他类型的存储服务接入 Kubernetes 系统服务.本文将从 Kubernetes 存储架构.存储插件原理.实现等方面进行讲解,希望大家有所收获. 一.Kubernetes 存储体系架构 引例:

一文读懂 K8s 持久化存储流程

作者 | 孙志恒(惠志)? 阿里巴巴开发工程师<br /> 导读:众所周知,K8s 的持久化存储(Persistent Storage)保证了应用数据独立于应用生命周期而存在,但其内部实现却少有人提及.K8s?内部的存储流程到底是怎样的?PV.PVC.StorageClass.Kubelet.CSI 插件等之间的调用关系又如何,这些谜底将在本文中一一揭晓. K8s 持久化存储基础 在进行 K8s 存储流程讲解之前,先回顾一下 K8s 中持久化存储的基础概念. 1. 名词解释 in-tree:代

k8s的存储Volume

1.Volume简介 我们经常会说:容器和 Pod 是短暂的.其含义是它们的生命周期可能很短,会被频繁地销毁和创建.容器销毁时,保存在容器内部文件系统中的数据都会被清除. 为了持久化保存容器的数据,可以使用 Kubernetes Volume. Volume 的生命周期独立于容器,Pod 中的容器可能被销毁和重建,但 Volume 会被保留. 本质上,Kubernetes Volume 是一个目录,这一点与 Docker Volume 类似.当 Volume 被 mount 到 Pod,Pod

Rancher(2),K8S持久性存储Ceph RBD搭建及配置

1.配置host,安装ntp(非必须)2.配置免密ssh3.配置ceph,yum源 vim /etc/yum.repo.d/ceph.cepo [ceph] name=ceph baseurl=http://mirrors.cloud.tencent.com/ceph/rpm-luminous/el7/x86_64/ gpgcheck=0 priority=1 [ceph-noarch] name=cephnoarch baseurl=http://mirrors.cloud.tencent.c

玩转Windows Azure存储服务——高级存储

在上一篇中我们中,我们把Windows Azure的存储服务用作网盘,本篇我们继续挖掘Windows Azure的存储服务——高级存储.高级存储自然要比普通存储高大上的,因为高级存储是SSD存储!其吞吐量和IOPS自然是普通存储没法比的.在高级存储功服务推出之前,用户为了提升磁盘性能,通常需要挂载多个持久盘做成RAID 0来使用.一个最大号的虚拟机,最多可以挂载16个持久盘,若将这16个磁盘组成RAID 0,理论上其整体磁盘性能可以提高16倍——当然这个只是理论值,因为是软RAID,总是要消耗一