响应式手机网站怎么做,cnzz统计,百度搜索引擎网址格式,吉林东奥建设集团网站一、K8s 本地存储
K8s 支持多达 20 种类型的持久化存储#xff0c;如常见的 CephFS 、Glusterfs 等#xff0c;不过这些大都是分布式存储#xff0c;随着社区的发展#xff0c;越来越多的用户期望将 K8s 集群中工作节点上挂载的数据盘利用起来#xff0c;于是就有了 loca…一、K8s 本地存储
K8s 支持多达 20 种类型的持久化存储如常见的 CephFS 、Glusterfs 等不过这些大都是分布式存储随着社区的发展越来越多的用户期望将 K8s 集群中工作节点上挂载的数据盘利用起来于是就有了 local 类型持久卷的支持。可以把 local 类型持久卷称作Local Persistent Volume简称 LocalPV。LocalPV 所代表的是某个被挂载的本地工作节点存储设备例如磁盘、分区或者目录因此 LocalPV 并不能像分布式存储一样可靠但速度极快这也决定了 LocalPV 使用场景I/O 敏感度高且能够容忍小概率数据丢失现象。K8s 官方文档里有一个使用 LocalPV 的简单示例简单总结下 K8s LocalPV 的特点 只能用作静态创建的持久卷不支持动态供应也就是说必须通过手动的方式创建 PV 与 hostPath 卷相比LocalPV 能够以持久和可移植的方式使用而无需手动将 Pod 调度到节点。系统通过查看 PV 的节点亲和性nodeAffinity配置就能了解卷的节点约束。 如果想使用存储类来自动绑定 PVC 和 PV则必须将 StorageClass 配置成延迟绑定。 示例如下
apiVersion: storage.K8s.io/v1
kind: StorageClass
metadata:name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer其中 volumeBindingMode: WaitForFirstConsumer 属性即为延迟卷绑定它使得调度器在为 PVC 选择一个合适的 PV 时能考虑到所属 Pod 的调度限制。举个例子假设创建了两个 PV 分别为 PV1、PV2然后创建一个 Pod 并申明一个 PVC 叫 PVC1 PV1 和 PV2 同时满足 PVC1 的要求但此时存储类并不能马上将 PVC1 与 PV1 或 PV2 中任何一个 PV 进行绑定而是要考虑 Pod 的调度策略。如果 Pod 指定了节点亲和性必须要部署到 PV1 所在节点则 PVC1 就需要跟 PV1 进行绑定而不能与 PV2 进行绑定。可以发现当 Pod 需要使用 LocalPV 时PVC 与 PV 的绑定就需要考虑 Pod 的调度情况因此 LocalPV 的存储类无法支持立即绑定只能将绑定时机延迟到 Pod 调度时进行WaitForFirstConsumer。
二、OpenBES 本地存储
① OpenBES 简介
由于 K8s LocalPV 的使用限制无法满足生产需求因此就需要寻找替代方案好在已经有人实现了更强大的 LocalPV 存储方案OpenEBS LocalPV。OpenEBS 官网地址为OpenEBS 官网。OpenEBS 可以将 K8s 工作节点上的任何可用存储转换为本地或分布式也称为复制持久卷。OpenEBS 最初由 MayaData 构建并捐赠给 CNCF现在是 CNCF 沙盒项目。
② 卷类型
OpenEBS 支持两种卷类型本地卷、复制卷架构如下 本地卷能够直接将工作节点上插入的数据盘抽象为持久卷供当前节点上的 Pod 挂载使用。而复制卷则相对复杂一些OpenEBS 使用其内部的引擎为每个复制卷创建一个微服务在使用时有状态服务将数据写入 OpenEBS 引擎引擎将数据同步复制到集群中的多个节点从而实现了高可用。
③ 本地卷
由于本次 OpenEBS 的落地实践针对于本地持久化存储故主要分析 OpenEBS 本地卷的使用OpenEBS 本地卷支持多种类型Hostpath、Device、LVM、ZFS、Rawfile。每种类型各有特点都有自己的适用场景比如相较于 K8s 原生 HostpathOpenEBS 的 Hostpath 能够支持将外挂的数据盘目录作为 Hostpath 目录从而避免 Pod 可能将宿主机目录写满的问题。Device 能够将块设备用于 LocalPV 的使用速度极快。而借助 LVM 的能力则可以更灵活的使用 LocalPV它可以支持 PV 的动态扩缩容操作。OpenEBS 为其支持的每种类型都实现了一个单独的项目以使用块设备为例介绍 OpenEBS LocalPV 使用实践项目地址为device-localpv接下来以 Device-LocalPV 来指代它。
④ 实践
环境准备 使用 minikube 来搭建 K8s 集群环境OpenEBS 官方要求 K8s 版本为 1.20实测下来 1.19 版本也是没有问题的不过建议优先选用推荐版本 使用 VirtualBox 作为驱动启动两个 minikube 节点minikube、minikube-m02可以参考https://minikube.sigs.k8s.io/docs/drivers/virtualbox/ minikube 节点挂载一块 4GB 磁盘minikube-m02 节点分别挂载一块 4GB、一块 8GB 磁盘。 安装 Device-LocalPV 由于 OpenEBS Device-LocalPV 本身即为云原生而开发的应用因此安装起来非常简单只需要一条 kubectl apply 命令即可。
kubectl apply -f https://raw.githubusercontent.com/openebs/device-localpv/develop/deploy/device-operator.yaml执行以上命令后会得到如下几个相关 Pod
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system openebs-device-controller-0 2/2 Running 0 2m23s
kube-system openebs-device-node-4wld7 2/2 Running 0 2m23s
kube-system openebs-device-node-p2r6m 2/2 Running 0 2m23s确保这几个 Pod 全部处于 Running 状态就表示 Device-LocalPV 安装成功如果安装失败则需要根据 kubectl describe 命令的描述信息进行排查。 准备磁盘 Device-LocalPV 能够直接接管节点上的块设备有时候节点上可能同时插入多块数据盘而这些数据盘中也许某些数据盘我们不想当作 LocalPV 来使用为了能够区分哪些块设备可以供 Device-LocalPV 来使用需要在对应的块设备上创建一个~10MiBMeta 分区用于存储磁盘标识信息Meta 分区有如下要求 是块设备的第一个分区ID_PART_ENTRY_NUMBER1 不能被格式化成任何文件系统 不能设置 flags 分区标记。 操作命令如下
## 在 minikube 节点上执行如下命令
$ sudo parted /dev/sdb mklabel gpt
$ sudo parted /dev/sdb mkpart test-device 1MiB 10MiB## 在 minikube-m02 节点执行如下命令
$ sudo parted /dev/sdb mklabel gpt
$ sudo parted /dev/sdb mkpart test-device 1MiB 10MiB
$ sudo parted /dev/sdc mklabel gpt
$ sudo parted /dev/sdc mkpart test-device 1MiB 10MiB以上分别对 minikube、minikube-m02 两个节点上的块设备进行了 Meta 分区的操作其中 /dev/sdb、/dev/sdc 就是节点上挂载的块设备名需要根据自己实际情况来指定。其中三块盘的 Meta 分区名都叫 test-device 是有意而为之接下来创建存储类时会用到。 创建存储类 既然 Device-LocalPV 支持动态供应那么必然少不了创建存储类的步骤将以下 yaml 文件保存为 sc.yaml 然后通过 kubectl apply -f sc.yaml 创建存储类
apiVersion: storage.K8s.io/v1
kind: StorageClass
metadata:name: openebs-device-sc
allowVolumeExpansion: false
parameters:devname: test-device
provisioner: device.csi.openebs.io
volumeBindingMode: WaitForFirstConsumer存储类 parameters 字段需要指定 devname其值为上面在为块设备分区时指定的分区名称 test-device存储类在创建 PV 的时候正是根据这个分区名的匹配来找到哪些块设备是供 Device-LocalPV 来使用的。 创建 StatefulSet 来申请使用 LocalPV StatefulSet 以及相关资源定义如下
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: Noneselector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: hello
spec:selector:matchLabels:app: helloserviceName: nginxreplicas: 2template:metadata:labels:app: hellospec:terminationGracePeriodSeconds: 1containers:- name: htmlimage: busyboximagePullPolicy: IfNotPresentcommand:- sh- -c- while true; do echo date [hostname] Hello from OpenEBS Local PV. /mnt/store/index.html; sleep $(($RANDOM % 5 300)); donevolumeMounts:- mountPath: /mnt/storename: csi-devicepv- name: webimage: K8s.gcr.io/nginx-slim:0.8imagePullPolicy: IfNotPresentports:- containerPort: 80name: webvolumeMounts:- name: csi-devicepvmountPath: /usr/share/nginx/htmlvolumeClaimTemplates:- metadata:name: csi-devicepvspec:accessModes: [ReadWriteOnce]storageClassName: openebs-device-scresources:requests:storage: 1Gi创建一个 Service 和一个名叫 hello 的 StatefulSet重点关注 StatefulSet它启动两个副本并通过 volumeClaimTemplates 来申请 1Gi 大小的 PVC。通过 kubectl apply 命令安装以上文件资源后可以看到两个 Pod 分别被调度到了不同节点上
# 查看 Pod 调度情况
➜ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
hello-0 2/2 Running 0 4m13s 10.244.1.3 minikube-m02 none none
hello-1 2/2 Running 0 2m42s 10.244.0.3 minikube none none# 查看 PVC 资源
➜ kubectl get pvc -o wide
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE VOLUMEMODE
csi-devicepv-hello-0 Bound pvc-042661c8-c000-4dde-9950-2b6859d5f273 1Gi RWO openebs-device-sc 4m46s Filesystem
csi-devicepv-hello-1 Bound pvc-26f92829-e0d4-4520-86da-2d7741cd68c2 1Gi RWO openebs-device-sc 3m15s Filesystem# 查看 PV 资源
➜ kubectl get pv -o wide
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE VOLUMEMODE
pvc-042661c8-c000-4dde-9950-2b6859d5f273 1Gi RWO Delete Bound default/csi-devicepv-hello-0 openebs-device-sc 18m Filesystem
pvc-26f92829-e0d4-4520-86da-2d7741cd68c2 1Gi RWO Delete Bound default/csi-devicepv-hello-1 openebs-device-sc 17m Filesystem现在分别登录两台 minikube 主机节点使用 fdisk 命令查看两个节点磁盘使用情况 左侧为 minikube 节点右侧为 minikube-m02 节点可以看到 PV 创建成功后会在对应节点的块设备上创建与 PV 相同大小的分区来提供 LocalPV 的支持而这个分区的生命周期管理工作都是由 Device-LocalPV 来完成的它会随着 PV 的创建而创建随着 PV 的删除而销毁。 至此就完成了 OpenEBS Device-LocalPV 实践演练。正常来说通过上面的实践步骤应该能顺利的搭建并使用 OpenEBS Device-LocalPV。但也许会遇到一些奇怪的问题接下来就分析几个在 OpenEBS Device-LocalPV 落地实践过程可能会遇到的坑。
⑤ 问题分析
parted 命令版本问题 根据经验parted 命令不同版本表现可能不一致。如下所示使用两个不同版本的 parted 工具执行相同命令来对块设备进行 Meta 分区操作得到的结果却不一样 可以发现截图中 3.3 版本 parted 命令分区会产生 flagmsftdata下面 3.1 版本的 parted 命令分区则没有产生 flag。OpenEBS Device-LocalPV 规定 Meta 分区不能有 flag如果产生 flag 则 Device-LocalPV 会将这个块设备忽略不进行使用。 为了保证执行 parted 命令对磁盘进行分区时得到预期结果可以总是进入 OpenEBS Daemonset 的容器内部来使用 OpenEBS 提供的 parted 命令进行分区。这样就保证了与 Device-LocalPV 工作时内部使用的 parted 命令版本一致不会出现一些意料之外的问题。Daemonset 所对应的 Pod 即为上面的 openebs-device-node-4wld7、openebs-device-node-p2r6m 两个 PodOpenEBS 启动时会在每个节点上启动一个 Daemonset 工作负载用来操作节点块设备提供 LocalPV 支持。 PV 动态扩容问题OpenEBS Device-LocalPV 目前还不支持扩容操作因此在创建存储类时需要指定 allowVolumeExpansion 属性值为 false以此来标记这个存储类所创建出来的 PV 不支持动态扩容操作。PV 可能无法创建成功问题 可能会遇到 PVC 所申请的容量刚好等于块设备剩余容量时PV 无法创建成功PVC 一直处于 Pending 状态的问题。 假设现在只有一个节点节点上也仅仅只有一个块设备供 Device-LocalPV 使用其容量为 10Gi。如果连续申请 4 个 PVC其容量依次为 1G、3G、3G、1G分别对应如下截图fdisk 命令显示结果中 sdb2、sdb3、sdb4、sdb5 4 个分区。 现在如果删除第一个容量为 3G 的 PVCDevice-LocalPV 则会自动删除 /dev/sdb3 这个分区。可是此时如果尝试再次创建一个 3G 的 PVC这个 PVC 将永远无法创建成功一直处于 Pending 状态。当每创建一个 PVC 时存储类都会通过 Device-LocalPV 在节点的块设备上新创建一个和 PVC 中申请的容量相等的一个磁盘分区出来从截图中可以看出这个分区的 Start 、End 是从小到大且连续的。新创建的 3G 的 PVC 容量等于 /dev/sdb3 分区容量理论上应该是可以创建成功的。 分析 Device-LocalPV 源码可以发现在计算节点上块设备剩余可用容量是否满足 PVC 申请的容量大小时Device-LocalPV 通过 if tmp.SizeMiB partSize 这条语句来进行判断其中 tmp.SizeMiB 为块设备剩余可用容量partSize 为 PVC 申请容量只有块设备剩余容量大于 PVC 申请容量时才会进行分区操作如果没有满足 PVC 申请容量的可用分区PVC 就会一直处于 Pending 状态。 由此可见将 if tmp.SizeMiB partSize 改成 if tmp.SizeMiB partSize 即可解决这个问题另外在阅读源码的过程中还可以发现 Device-LocalPV 在计算块设备可用分区时对于分区大小的计算会涉及从 Bytes 到 Mib 的单位转换操作 beginBytes 、endBytes 对应的就是上面 fdisk 命令截图中的 Start 、End此时如果分区没有对齐则会出现浮点数计算精度丢失问题其中 beginMib 会被 math.Ceil 向上取整endMib 会被 math.Floor 向下取整最终得到的 sizeMib 有可能小于实际剩余可用空间这样就导致可能会出现磁盘剩余容量满足 PVC 申请容量而 PVC 却无法创建成功现象因此在创建 PVC 时应尽量申请 1024 整数倍大小的容量。
三、CSI
在 K8s 中如果 K8s 内置的存储功能不满足我们的生产需求则可以通过一种叫作 CSI 的插件机制来对其进行扩展而 Device-LocalPV 正是采用这种机制来实现的。CSI 是 Container Storage Interface 的简称是 K8s 官方定义的容器存储接口规范它试图定义一个统一的业界标准专门用来扩展容器编排系统的存储能力。
① 基础架构
一个 CSI 插件包含两个主体部分 External Components 和 Custom Components其中 External Components 由 K8s 官方提供而 Custom Components 则由编写插件的作者来提供。这两个 Components 又各自包含 3 个组件一起协同工作。CSI 基本架构如下 ② 工作流程
首先在 CSI 插件启动时External Components 中的 Driver Registrar 组件最先开始工作它通过与 Custom Components 中的 Identity 组件进行通信获取到 CSI 插件的基本信息并将其注册到 kubelet 中。而 External Components 中的 Provisioner 组件则通过 Watch 机制监听了 APIServer 中 PVC 对象的创建一旦有新的 PVC 被创建Provisioner 就会与 Custom Components 中的 Controller 组件进行通信让其创建 PV 相关资源。创建完 PV下一步就到了 Attach 阶段而 Attach 操作正对应了 External Components 中的 Attacher 组件它同样会与 Custom Components 中的 Controller 组件进行通信协同完成 Attach 操作。而最后一步 Mount 操作则由 Node 节点上的 kubelet 直接调用 External Components 中的 Node 组件来完成。至此Pod 内部应用就可以使用主机节点上挂载的 LocalPV 了。
四、Device-LocalPV
① 部署
要分析一个程序的执行流程当然要从程序启动入口开始而 OpenEBS 是一个面向云原生的应用那么首先要看的就是项目的部署方式OpenEBS Device-LocalPV 项目部署 yaml 文件也在其项目的 git 仓库中。可以看到部署文件中最重要的两个资源分别是一个名为 openebs-device-controller 的 StatefulSet和一个名为 openebs-device-node 的 DaemonSet。在 StatefulSet 中启动了两个容器分别是 K8s 官方提供的 External Provisioner 组件和由 OpenEBS 开发的 Custom Controller 组件这两个组件被放在一个 Pod 中协同工作。而在 DaemonSet 中同样也启动了两个容器分别是 K8s 官方提供的 External Driver Registrar 组件和由 OpenEBS 开发的 Custom Node 组件。那么CSI 机制中的 External Attacher 组件去哪里了实际上 LocalPV 并没有 Attach 操作创建出来后只需要一步 Mount 操作即可使用所以也就没有必要部署这个组件了。可能我们会好奇 External 组件和 Custom 对应组件之间如何来进行通信根据上面提供的 Device-LocalPV 项目部署 yaml 文件中的内容就不难发现里面有 unix:///xxx/csi.sock 字样实际上它们之间的通信都是依靠基于 Unix socket 的 gRPC 来进行的这样即实现了组件间的解耦又能高效进行通信。
② 组件
知道 OpenEBS Device-LocalPV 项目都部署了哪些组件接下来通过阅读源码来分析程序执行流程。无论是 StatefulSet 还是 DaemonSetDevice-LocalPV 程序启动入口文件都是同一个程序启动后在 main 函数里会调用 run 函数run 函数定义如下
func run(config *config.Config) {if config.Version {config.Version version.Current()}klog.Infof(Device Driver Version :- %s - commit :- %s, version.Current(), version.GetGitCommit())klog.Infof(DriverName: %s Plugin: %s EndPoint: %s NodeID: %s,config.DriverName,config.PluginType,config.Endpoint,config.NodeID,)if len(config.IgnoreBlockDevicesRegex) 0 {device.DeviceConfiguration.IgnoreBlockDevicesRegex regexp.MustCompile(config.IgnoreBlockDevicesRegex)}err : driver.New(config).Run()if err ! nil {log.Fatalln(err)}os.Exit(0)
}值得注意的是 err : driver.New(config).Run() 这句代码通过 config 参数启动了一个 Driver 并执行 Run 方法可以跟踪到 New 函数内部来查看其实现
func New(config *config.Config) *CSIDriver {driver : CSIDriver{config: config,cap: GetVolumeCapabilityAccessModes(),}switch config.PluginType {case controller:driver.cs NewController(driver)case agent:driver.ns NewNode(driver)}driver.ids NewIdentity(driver)return driver
}可以发现New 函数内部会通过 config 创建一个 CSIDriver 对象这个对象会根据配置参数注册 Controller 组件或 Node 组件在 Device-LocalPV 项目中 agent 和 Node 等价而这两个组件分别对应的就是 StatefulSet 和 DaemonSet也就是说Controller 组件会以 StatefulSet 的方式启动Node 组件则会以 DaemonSet 方式启动。** Identity 组件** 根据上面的源码可以发现不管启动 Controller 或 Node 中的哪个组件Identity 组件都会被注册进来driver.ids NewIdentity(driver)因为将 Device-LocalPV 实现的 CSI 插件分开成两个工作负载来部署而它们都需要注册给 K8sIdentity 组件正是干这件事情的。 Identity 实现如下定义了 3 个方法分别是 GetPluginInfo 、Probe 、GetPluginCapabilities
package driverimport (github.com/container-storage-interface/spec/lib/go/csigithub.com/openebs/device-localpv/pkg/versiongolang.org/x/net/contextgoogle.golang.org/grpc/codesgoogle.golang.org/grpc/status
)// identity is the server implementation
// for CSI IdentityServer
type identity struct {driver *CSIDriver
}// NewIdentity returns a new instance of CSI
// IdentityServer
func NewIdentity(d *CSIDriver) csi.IdentityServer {return identity{driver: d,}
}// GetPluginInfo returns the version and name of
// this service
//
// This implements csi.IdentityServer
func (id *identity) GetPluginInfo(ctx context.Context,req *csi.GetPluginInfoRequest,
) (*csi.GetPluginInfoResponse, error) {if id.driver.config.DriverName {return nil, status.Error(codes.Unavailable, missing driver name)}if id.driver.config.Version {return nil, status.Error(codes.Unavailable, missing driver version)}return csi.GetPluginInfoResponse{Name: id.driver.config.DriverName,// TODO// verify which version needs to be used:// config.version or version.Current()VendorVersion: version.Current(),}, nil
}// TODO
// Need to implement this
//
// # Probe checks if the plugin is running or not
//
// This implements csi.IdentityServer
func (id *identity) Probe(ctx context.Context,req *csi.ProbeRequest,
) (*csi.ProbeResponse, error) {return csi.ProbeResponse{}, nil
}// GetPluginCapabilities returns supported capabilities
// of this plugin
//
// Currently it reports whether this plugin can serve
// the Controller interface. Controller interface methods
// are called dependant on this
//
// This implements csi.IdentityServer
func (id *identity) GetPluginCapabilities(ctx context.Context,req *csi.GetPluginCapabilitiesRequest,
) (*csi.GetPluginCapabilitiesResponse, error) {return csi.GetPluginCapabilitiesResponse{Capabilities: []*csi.PluginCapability{{Type: csi.PluginCapability_Service_{Service: csi.PluginCapability_Service{Type: csi.PluginCapability_Service_CONTROLLER_SERVICE,},},},{Type: csi.PluginCapability_Service_{Service: csi.PluginCapability_Service{Type: csi.PluginCapability_Service_VOLUME_ACCESSIBILITY_CONSTRAINTS,},},},},}, nil
}其中 GetPluginInfo 方法返回插件的名称和版本号Probe 顾名思义是一个探针程序K8s 可以根据这个探针检查插件是否正常工作。 而 GetPluginCapabilities 方法返回当前插件的能力用告诉 K8s 这个 CSI 插件实现了哪些功能比如 Device-LocalPV 项目没有实现 Attach 功能当我们在创建 PVC 时指定了这个 CSI 插件作为存储类的 provisioner 时K8s 就会自动跳过 Attach 阶段直接进入 Mount 阶段。 细心的读者可能已经发现每个方法上都有一行 // This implements csi.ControllerServer 注释实际上这些方法的名称都是固定的已经被 CSI 规范所定义而编写 CSI 插件的作者只需要按照规范实现对应方法即可。 Controller 组件 上面分析 CSI 基本架构的时候讲到 External Provisioner 组件通过 Watch 机制监听 APIServer 中 PVC 对象的创建一旦有新的 PVC 被创建Provisioner 组件就会与 Custom Controller 组件进行通信让其创建 PV 相关资源。这里我说的是创建 PV 相关资源而不是创建 PV。所谓的 PV 相关资源则是一个 CRD是编写 CSI 组件的开发人员自定义的一种资源类型一个 CRD 会与一个 PV 对应其生命周期也基本相同。这么做的原因是 PV 属于 K8s 内部资源而 CSI 是一个通用规范不止适用于 K8s还适用于任何容器编排系统因此 CSI 插件应该自己定义一种资源类型来与 PV 进行对应。 而这个与 PV 相对应的 CRD 叫作 devicevolumes.local.openebs.io它定义在 Device-LocalPV 项目部署文件中相当于 Device-LocalPV 自己管理的 PV 资源。一个典型的 devicevolumes.local.openebs.io 资源定义如下
apiVersion: v1
items:
- apiVersion: local.openebs.io/v1alpha1kind: DeviceVolumemetadata:creationTimestamp: 2022-08-01T08:45:51Zfinalizers:- device.openebs.io/finalizergeneration: 3labels:kubernetes.io/nodename: minikube-m02name: pvc-8e659633-e052-439a-85eb-30a6d385a12bnamespace: openebsresourceVersion: 1715uid: 540aa699-4f6f-487c-b38b-38f8b414bd7cspec:capacity: 1073741824devname: device-localpvownerNodeID: minikubestatus:state: Ready
kind: List
metadata:resourceVersion: 为了方便对节点块设备进行管理Device-LocalPV 还定义了一个叫 devicenodes.local.openebs.io 的 CRD这个 CRD 对应的是 K8s 工作节点有几个供 Device-LocalPV 使用的节点就有几个 devicenodes.local.openebs.io 资源这个 CRD 中记录了当前节点上所有可用块设备。那么 devicevolumes.local.openebs.io 是在什么时候创建的呢在 Custom Controller 组件中有一个关键方法叫 Createvolume正是这个方法负责 PV 相关 CRD 的创建。 External Provisioner 组件监听到有新的 PVC 创建就会执行组件内部的 Provision 方法而在 Provision 方法内部会通过 gRPC 的方式调用 Custom Controller 组件的 Createvolume 方法来创建 CRDCRD 创建完成后会由 Provisioner 来创建 PV 对象。相关代码实现如下 Agent 组件 Device-LocalPV 组件是 Agent它实际上就是 CSI 插件中的 Node 组件从这个名称不难猜测所有在节点宿主机上的操作都会通过这个组件来完成。 当 Provisioner 组件和 Controller 组件分别创建好 PV 和 CRD 以后那么还剩下 2 个步骤分别是在块设备上创建分区和将分区 Mount 到容器内部这两个操作正是 Agent 组件的职责。 Agent 组件其构造函数如下
// NewNode returns a new instance
// of CSI NodeServer
func NewNode(d *CSIDriver) csi.NodeServer {var ControllerMutex sync.RWMutex{}// set up signals so we handle the first shutdown signal gracefullystopCh : signals.SetupSignalHandler()// start the device node resource watchergo func() {err : devicenode.Start(ControllerMutex, stopCh)if err ! nil {klog.Fatalf(Failed to start Device node controller: %s, err.Error())}}()// start the device volume watchergo func() {err : volume.Start(ControllerMutex, stopCh)if err ! nil {klog.Fatalf(Failed to start Device volume management controller: %s, err.Error())}}()if d.config.ListenAddress ! {exposeMetrics(d.config, stopCh)}return node{driver: d,}
}可以发现在 Agent 组件内部启动了两个 Goroutine它们分别用来监听 devicenodes.local.openebs.io 和 devicevolumes.local.openebs.io 这两个 CRD其内部都实现了 syncHandler 方法根据 CRD 状态进行相应操作。 volume 的 syncHandler 主要逻辑如下
func (c *VolController) syncHandler(key string) error {...// Get the Vol resource with this namespace/nameVol, err : c.VolLister.DeviceVolumes(namespace).Get(name)if K8serror.IsNotFound(err) {runtime.HandleError(fmt.Errorf(devicevolume %s has been deleted, key))return nil}if err ! nil {return err}VolCopy : Vol.DeepCopy()err c.syncVol(VolCopy)return err
}func (c *VolController) syncVol(vol *apis.DeviceVolume) error {...// if the status Pending means we will try to create the volumeif vol.Status.State device.DeviceStatusPending {err device.CreateVolume(vol)if err nil {err device.UpdateVolInfo(vol, device.DeviceStatusReady)} else if custError, ok : err.(*apis.VolumeError); ok custError.Code apis.InsufficientCapacity {vol.Status.Error custErrorreturn device.UpdateVolInfo(vol, device.DeviceStatusFailed)}}return err
}可以看到syncHandler 方法会将查询到的 devicevolumes.local.openebs.io 信息传递给 syncVol 方法而这个方法中有一行非常关键的代码 device.CreateVolume(vol)调用此方法的作用正是根据 CRD 的信息在块设备上创建出真正的分区。 分区一旦被成功创建那么就只剩下最后一个步骤 Mount 操作了Mount 操作由 PV 所在节点的 kubelet 直接调用 Agent 组件的 NodePublishVolume 方法来完成。值得注意的是在部署 Device-LocalPV 项目的 yaml 文件中Agent 组件所在容器的 volumeMounts 属性中有一个 mountPropagation: “Bidirectional” 配置其作用是为了使在容器内部执行的 Mount 命令能够向上传播到宿主机上。所以尽管Agent 组件运行在容器中但在其内部执行的 Mount 命令依然能够在节点上生效。
③ 调度策略
Device-LocalPV 提供了两种调度策略CapacityWeighted、VolumeWeighted可以在存储类中通过参数指定调度策略
parameters:scheduler: VolumeWeighteddevname: test-deviceCapacityWeighted CapacityWeighted 为默认调度策略即根据使用容量调度它会查找已部署了 OpenEBS 的节点按节点上块设备已使用容量进行打分优先调度到已使用容量较小的节点。 如下所示的图中Node1 节点上已经存在 3 个 PVNode2 节点上存在 2 个 PVNode3 节点上没有部署 OpenEBS如果此时新创建一个 PVC那么 PV 会如何调度呢 根据 CapacityWeighted 调度策略来看Node3 节点第一个被排除尽管 Node1 节点上已经存在的 PV 数量比 Node2 节点上的多但已使用容量较少故根据已使用容量来排序显然这个新创建的 PV 将会被调度到 Node1 节点。 VolumeWeighted VolumeWeighted 调度策略则根据使用卷数量来进行调度查找已部署了 OpenEBS 的节点按节点上块设备已分配卷数量进行打分优先调度到已使用卷数量较小的节点。 那么分析下来在跟上图中同样的情况下使用 VolumeWeighted 调度策略后新创建的 PV 将会被调度到 Node2 节点 自定义调度策略 如果事情按照理想化方向发展那么上面两种 Device-LocalPV 提供的调度策略没有任何问题但真实场景中也许会遇到如下情况 现在部署了 OpenEBS 的节点从 2 个扩展成 3 个但是 Node3 上仅仅部署了 OpenEBS还没有插入块设备供 OpenEBS 使用。 在这种情况下如果新创建 PVC那么这个 PVC 将一直处于 Pending 状态PV 无法完成创建。因为无论是哪种调度策略Device-LocalPV 在为节点打分阶段总是会将使块设备用量为 0 的节点排序在最前面所以两种策略最终都会将 PV 调度到 Node3 节点而又因为 Node3 节点上没有供 OpenEBS 使用的块设备无法进行磁盘分区PV 也就无法成功创建。
④ 故障处理
节点故障 如果某个正在被 LocalPV 使用的节点出现故障可以通过迁移块设备来让 LocalPV 恢复使用具体步骤如下 将数据盘移动到新节点上 如果新节点没有部署 OpenEBS 则需要先部署 Device-LocalPV 的 DaemonSet 到新节点上 修改 CRD 资源 devicevolumes.local.openebs.io 所属的节点即修改 spec.ownerNodeID 属性到新的节点 修改 PV 的节点信息即修改 spec.nodeAffinity 属性到新的节点 删除使用 PV 的 Pod 让其自动重启并调度到 PV 所指定的新节点上。 磁盘故障如果某个正在被 LocalPV 使用的块设备出现故障则会造成数据丢失。 需要注意的是当某个 PV 所使用的磁盘分区出现故障时PV 无法感知只有部署在 Pod 内的程序可以感知到可以尝试在出现故障的 Pod 容器内部执行读写操作会得到如下错误
/mnt/store # echo abc a.txt
sh: cant create a.txt: Input/output error因此使用 LocalPV 的程序要有比较完善的异常处理机制以应对可能出现的故障问题。
