本文转载自微信公众号「黑客下昼茶」，作家为少。转载本文请接洽黑客下昼茶公众号。
系列Longhorn 是什么?
目次 1. 联想 1.1. Longhorn Manager 和 Longhorn Engine 1.2. 基于微处事的联想的上风 1.3. CSI Driver 1.4. CSI Plugin 1.5. Longhorn UI 2. Longhorn 卷和主存储 2.4.1. 快照的职责旨趣 2.4.2. 依期快照 2.4.3. 删除快照 2.4.4. 存储快照 2.4.5. 崩溃一致性 2.3.1. 副本读写操作的职责旨趣 2.3.2. 如何添加新副本 2.3.3. 如何重建有故障的副本 2.1. 精简设立和卷大小 2.2. 在关心模式下归附卷 2.3. 副本 2.4. 快照 3. 备份和扶持存储 3.1. 备份的职责旨趣 3.2. 依期备份 3.3. 恶运归附卷 3.4. 备份存储更新断绝、RTO 和 RPO 附录：抓久性存储在 Kubernetes 中的职责旨趣 现存存储设立 动态存储设立 Kubernetes 职责负载如何使用新的和现存的抓久存储 具有抓久存储的 Kubernetes Workloads 的水平彭胀 1. 联想Longhorn 联想有两层：数据平面(data plane)和抵制平面(control plane)。Longhorn Engine 是存储抵制器对应数据平面，Longhorn Manager 对应抵制平面。
1.1. Longhorn Manager 和 Longhorn EngineLonghorn Manager Pod 当作 Kubernetes DaemonSet 在 Longhorn 集群中的每个节点上运行。它崇拜在 Kubernetes 集群中创建和不停卷，并处理来自 UI 或 Kubernetes 卷插件的 API 调用。它除名 Kubernetes controller pattern，有时也称为 operator pattern。
Longhorn Manager 与 Kubernetes API 处事器通讯以创建新的 Longhorn 卷 CRD。然后 Longhorn Manager 不雅察 API 处事器的响应，当看到 Kubernetes API 处事器创建了一个新的 Longhorn volume CRD 时，Longhorn Manager 就创建了一个新的卷。
当 Longhorn Manager 被要求创建一个卷时，它会在该卷所诱惑的节点上创建一个 Longhorn Engine 实例，并在每个将摈弃副本的节点上创建一个副本。副本应摈弃在不同的主机上以确保最大的可用性。
副本的多条数据旅途确保了 Longhorn 卷的高可用性。即使某个副本或引擎出现问题，问题也不会影响悉数副本或 Pod 对卷的探望。Pod 仍将正常运行。
Longhorn Engine 恒久在与使用 Longhorn volume 的 Pod 同样的节点中运行。它跨存储在多个节点上的多个副本同步复制卷。
引擎(Engine)和副本(replicas)使用 Kubernetes 进行编排。
不才图中，
皇冠hg86a
Longhorn volumes 有三个实例。 每个卷都有一个专用抵制器，称为 Longhorn Engine 并当作 Linux 进度运行。 每个 Longhorn 卷有两个副本(replica)，每个副本是一个 Linux 进度。 图中的箭头暗示卷(volume)、抵制器实例(controller instance)、副本实例(replica instances)和磁盘之间的读/写数据流。 通过为每个卷创建单独的 Longhorn Engine，若是一个抵制器出现故障，其他卷的功能不会受到影响。图 1. 卷、Longhorn 引擎、副本实例和磁盘之间的读/写数据流
在 Longhorn 中，每个 Engine 只需要处事一个卷，简化了存储抵制器的联想。由于抵制器软件的故障域与单个卷遮挡，因此抵制器崩溃只会影响一个卷。
Longhorn Engine 填塞浮浅和轻佻，因此咱们不错创建多达 100,000 个孤独的引擎。 Kubernetes 退换这些孤独的引擎，从一组分享的磁盘中索取资源，并与 Longhorn 相助变成一个弹性的散布式块存储系统。
因为每个卷都有我方的抵制器，是以每个卷的抵制器和副本实例也不错升级，而不会导致 IO 操作赫然中断。
Longhorn 不错创建一个永劫期运行的功课(long-running job)来谐和悉数及时卷的升级，而不会中断系统的抓续运行。为确保升级不会导致不可意象的问题，Longhorn 不错继承升级一小部分卷，并在升级过程中出现问题时回滚到旧版块。
1.3. CSI DriverLonghorn CSI driver 得到块成立(block device)，对其进行模式化，然后将其挂载到节点上。然后 kubelet 将成立绑定挂载到 Kubernetes Pod 中。这允许 Pod 探望 Longhorn volume。
所需的 Kubernetes CSI 驱动步调镜像将由 longhorn driver deployer 自动部署。
1.4. CSI PluginLonghorn 通过 CSI Plugin 在 Kubernetes 中进行不停。这允许自便装置 Longhorn 插件。
Kubernetes CSI plugin 调用 Longhorn 创建卷，为 Kubernetes 职责负载创建抓久数据(persistent data)。 CSI plugin 使您巧合创建(create)、删除(delete)、附加(attach)、分离(detach)、挂载(mount)卷，并对卷进行快照。Longhorn 提供的悉数其他功能都是通过 Longhorn UI 结束的。
Kubernetes 集群里面使用 CSI interface 与 Longhorn CSI plugin 进行通讯。Longhorn CSI plugin 使用 Longhorn API 与 Longhorn Manager 通讯。
Longhorn 照实利用了 iSCSI，因此可能需要对节点进行荒芜设立。这可能包括把柄刊行版装置 open-iscsi 或 iscsiadm。
1.5. Longhorn UILonghorn UI 通过 Longhorn API 与 Longhorn Manager 进行交互，并当作 Kubernetes 的补充。通过 Longhorn 界面不错不停快照(snapshots)、备份(backups)、节点(nodes)和磁盘(disks)。
此外，集群职责节点的空间使用情况由 Longhorn UI 采集和流露。干系详服气息，请参见此处。
历史 2. Longhorn 卷和主存储创建 volume 时，Longhorn Manager 将为每个 volume 创建 Longhorn Engine 微处事和副本当作微处事。这些微处事通盘组成了一个 Longhorn volume。每个复制副本应摈弃在不同的节点或不同的磁盘上。
Longhorn Manager 创建 Longhorn Engine 后，它将诱惑到副本(replicas)。引擎在 Pod 运行的节点上线路块成立(block device)。
kubectl 救助创建 Longhorn 卷。
2.1. 精简设立和卷大小Longhorn 是一个精简设立(thin-provisioned)的存储系统。这意味着 Longhorn volume 只会占用它咫尺需要的空间。举例，若是您分配了 20 GB 的卷，但只使用了其中的 1 GB，则磁盘上的践诺数据大小将为 1 GB。您不错在 UI 的卷详服气息中检察践诺数据大小。
若是您从卷中删除了内容，则 Longhorn 卷自身的大小不会松开。举例，若是您创建了一个 20 GB 的卷，使用了 10 GB，然后删除了 9 GB 的内容，则磁盘上的践诺大小仍然是 10 GB 而不是 1 GB。发生这种情况是因为 Longhorn 在块级别(block level)而不是文献系统级别(filesystem level)上运行， 因此 Longhorn 不知说念内容是否已被用户删除。该信息主要保存在文献系统级别。
2.2. 在关心模式下归附卷从 Longhorn UI 附加卷时，会有一个关心模式复选框。它主要用于从快照归附卷。
美高梅进8844vip送18该选项将导致在不启用前端(块成立或 iSCSI)的情况下附加卷，以确保在附加卷时莫得东说念主不错探望卷数据。
v0.6.0 之后，快照归附操作要求卷处于关心模式。这是因为若是在挂载或使用卷时修改了块成立的内容，则会导致文献系统损坏。
查验卷气象而无谓操心数据被不测探望也很有用。
2.3. 副本每个副本都包含 Longhorn 卷的一系列快照。快照就像镜像(image)的一层，最旧的快照用作基础层，较新的快照在顶部。若是数据遮蔽旧快照中的数据，则数据仅包含在新快照中。一系列快照通盘夸耀了数据确刻下气象。
关于每个 Longhorn 卷，该卷的多个副本应该在 Kubernetes 集群中运行，每个副本位于单独的节点上。悉数副本都被同等对待，Longhorn Engine 恒久运行在与 pod 同样的节点上，pod 亦然卷的消费者。通过这种面目，咱们不错确保即使 Pod 宕机，引擎也不错被蜕变到另一个 Pod，您的处事将不会中断。
默许的副本数(replica count)不错在 settings 中调动。当附加一个卷时，不错在 UI 中调动卷的副本计数。
若是刻下运行高超的副本计数小于指定的副本计数，Longhorn 将运行从头生成新的副本。
若是刻下正常的副本计数大于指定的副本计数，Longhorn 将子虚施任何操作。在这种情况下，若是副本失败或被删除，Longhorn 将不会运行从头构建新的副本，除非健康的副本计数低于指定的副本计数。
Longhorn 副本使用救助精简设立的 Linux sparse files 构建。
2.3.1. 副本读写操作的职责旨趣
从卷的副本读取数据时，若是不错在及时数据中找到数据，则使用该数据。若是莫得，将读取最新的快照。若是在最新的快照中找不到数据，则读取次早的快照，以此类推，直到读取最旧的快照。
在创建快照时，会创建一个各别(differencing)磁盘。跟着快照数目的增多，各别磁盘链(也称为快照链)可能会变得很长。因此，为了晋升读取性能，Longhorn 关心了一个读取索引，该索引记载哪个各别磁盘为每个 4K 存储块保存有用数据。
不才图中，卷有八个块。读取索引(read index)有八个条件，而况在读取操作发生时被惰性填充。
写操作重置读索引，使其指向及时数据。及时数据由某些索引上的数据和其他索引上的空缺空间组成。
除了读取索引以外，咱们咫尺莫得关心荒芜的元数据来指导使用了哪些块。
上海市第八人民医院是一所集医疗、教学、科研、预防、康复、健康管理为一体的综合性医院，老年科则是医院的重点学科。陈锐已在临床一线工作30年了，她一直秉承以“病人为中心”的服务理念，致力于为老年人提供更安全、便捷、有温度的医疗服务。
图 2. 读取索引如何追踪保存最新数据的快照
上图用热情编码(color-coded)，把柄读取索引夸耀哪些块包含最新的数据，最新数据的开首也列不才表中：
Read Index Source of the latest data 0 最新快照 1 及时数据 2 最旧的快照 3 最旧的快照 4 最旧的快照 5 及时数据 6 及时数据 7 及时数据请属目，如上图绿色箭头所示，读取索引的 Index 5 之前指向第二个最旧的快照当作最近数据的开首，然后在 4K 块时调动为指向及时数据 Index 5 的存储被及时数据遮蔽。
读取索引保存在内存中，每个 4K 块阔绰一个字节。字节大小的读取索引意味着您不错为每个卷创建多达 254 个快照。
读取索引为每个副本阔绰一定数目的内存数据结构。举例，一个 1 TB 的卷阔绰 256 MB 的内存读取索引。
2.3.2 如何添加新副本
添加新副本时，现存副本将同步到新副本。第一个副本是通过从及时数据中得到新快照来创建的。
以下方法夸耀了 Longhorn 如何添加新副本的更详确细分：
Longhorn Engine 暂停。 假定副本中的快照链由及时数据和快照组成。创建新副本后，及时数据将成为最新(第二个)快照，并创建新的空缺版块的及时数据。 新副本以 WO(只写)模式创建。 Longhorn Engine 取消暂停。 悉数快照均已同步。 新副本诞生为 RW(读写)模式。2.3.3. 如何重建有故障的副本
Longhorn 将恒久尝试为每个卷关心至少给定数目的健康副本。
博彩网站提现当抵制器在其副本之一中检测到故障时，它会将副本记号为处于舛错气象(error state)。Longhorn Manager 崇拜启动和谐和重建故障副本的过程。
为了重建故障副本，Longhorn Manager 创建一个空缺副本并调用 Longhorn Engine 将空缺副本添加到卷的副本皆集。
为了添加空缺副本，Engine 实施以下操作：
暂停悉数读取和写入操作。 以 WO(只写)模式添加空缺副本。 创建悉数现存副本的快照，当今它的头部有一个空缺的各别磁盘(differencing disk)。 取消暂停悉数读取写入操作。只须写操作会被分配到新添加的副本。 启动后台进度以将除最近的各别磁盘以外的悉数磁盘从高超副本同步到空缺副本。 同步完成后，悉数副本当今都领有一致的数据，卷不停器将新副本诞生为 RW (读写)模式。临了，Longhorn Manager 调用 Longhorn Engine 从其副本皆集移除故障副本。
2.4. 快照快照功能使卷巧合归附到历史中的某个点。扶持存储中的备份也不错从快照构建。
从快照还原卷时，它会反应创建快照时卷的气象。
快照功能亦然 Longhorn 重建过程的一部分。每次 Longhorn 检测到一个副本宕机时，它会自动创建(系统)快照并运行在另一个节点上重建它。
2.4.1. 快照的职责旨趣
快照就像镜像(image)的一层，最旧的快照用作基础层，较新的快照在顶部。若是数据遮蔽旧快照中的数据，则数据仅包含在新快照中。一系列快照通盘夸耀了数据确刻下气象。
快照在创建后无法调动，除非快照被删除，在这种情况下，其调动会与下一个最近的快照合并。新数据恒久写入及时版块。新快照恒久从及时数据创建。
要创建新快照，及时数据将成为最新的快照。然后创建一个新的空缺版块的及时数据，取代旧的及时数据。
2.4.2. 依期快照
为了减少快照占用的空间，用户不错安排一个依期快照(recurring snapshot)或备份(backup)，保留多个快照，这将自动按贪图创建一个新的快照/备份，然后清算任何过多的快照/备份。
2.4.3. 删除快照
不需要的快照不错通过界面手动删除。当系统生成的快照被触发删除时，系统会自动将其记号为删除。
在 Longhorn 中，不成删除最新的快照。这是因为不管何时删除快照，Longhorn 都会将其内容与下一个快照合并，以便下一个和以后的快照保留正确的内容。
但 Longhorn 无法对最新快照实施此操作，因为莫得更多最近的快照不错与已删除的快照合并。最新快照的下一个“快照”是及时卷(volume-head)，欧博博彩网址此时用户正在读/写，因此不会发生合并过程。
相背，最新的快照将被记号为已删除，而况在可能的情况下，将不才次对其进行清算。
要清算最新快照，不错创建一个新快照，然后删除畴昔的“最新”快照。
2.4.4. 存储快照
快照存储在腹地，当作卷的每个副本的一部分。它们存储在 Kubernetes 集群中节点的磁盘上。快照与主机物理磁盘上的卷数据存储在并吞位置。
2.4.5. 崩溃一致性
Longhorn 是崩溃一致(crash-consistent)的块存储处分有推敲。
皇冠平台操作系统在写入块层(block layer)之前将内容保留在缓存中是正常的。这意味着若是悉数副本都关闭，那么 Longhorn 可能不包含关闭前立即发生的调动，因为内容保存在操作系统级缓存中，尚未传输到 Longhorn 系统。
此问题雷同于台式计较机因停电而关闭时可能发生的问题。归附供电后，您可能会发现硬盘驱动器中有一些损坏的文献。
要在职何给定本事强制将数据写入块层(block layer)，不错在节点上手动运行同步大呼，或者不错卸载磁盘。在职一情况下，操作系统都会将内容从缓存写入块层(block layer)。
Longhorn 在创建快照之前自动运行同步大呼。
3. 备份和扶持存储备份是备份存储(backupstore)中的一个对象，它是 Kubernetes 集群外部的 NFS 或 S3 兼容对象存储。备份提供了一种二级(secondary)存储体式，因此即使您的 Kubernetes 集群变得不可用，您的数据仍然不错被检索。
由于卷复制(volume replication)是同步的，而且由于采集蔓延(network latency)，很难进行跨地域复制。备份存储(backupstore)也用作处分此问题的绪论。
在 Longhorn 诞生中设立备份方针后，Longhorn 不错诱惑到备份存储并在 Longhorn UI 中向您夸耀现存备份列表。
若是 Longhorn 在第二个 Kubernetes 集群中运行，它还不错将恶运归附卷同步到二级存储(secondary storage)中的备份， 以便您的数据不错在第二个 Kubernetes 集群中更快地归附。
3.1. 备份的职责旨趣
使用一个快照当作源创建备份，以便它反应创建快照时卷数据的气象。
皇冠博彩与快照比较，备份不错被合计是一系列快照的扁平化版块。与将分层镜像(layered image)周折为平面镜像(flat image)时信息丢失的面目雷同，当一系列快照周折为备份时，数据也会丢失。在这两种周折中，任何被遮蔽的数据都将丢失。
皇冠客服飞机：@seo3687由于备份不包含快照，因此它们不包含卷数据调动的历史记载。从备份还原卷后，该卷领先包含一个快照。此快照是原始链中悉数快照的合并版块，它反应了创建备份时卷的及时数据。
固然快照不错达到 TB(terabytes)，但备份由 2 MB 文献组成。
并吞原始卷的每个新备份都是增量的，检测并在快照之间传输调动的块。这是一项相对容易的任务， 因为每个快照都是一个各别(differencing)文献，而况只存储上一个快照的调动。
为了幸免存储多数的小存储块，Longhorn 使用 2 MB 块实施备份操作。这意味着，若是 2MB 限度中的任何 4K 块发生调动，Longhorn 将备份整个 2MB 块。这提供了可不停性和后果之间的正确均衡。
图 3. 二级存储中的备份与主存储中的快照之间的关系
上图样子了如何从 Longhorn 中的快照创建备份：
亚博正网 图表的主存储一侧夸耀了 Kubernetes 集群中 Longhorn 卷的一个副本。副本由四个快照链组成。按照再行到旧的规则，快照是 Live Data、snap3、snap2 和 snap1。 图表的二级存储侧夸耀了外部对象存储处事(如 S3)中的两个备份。 在二级存储中，backup-from-snap2 的热情编码夸耀它包括来自 snap1 的蓝色变化和来自 snap2 的绿色变化。snap2 中的任何调动都莫得遮蔽 snap1 中的数据，因此 snap1 和 snap2 中的调动都包含在 backup-from-snap2 中。
名为 backup-from-snap3 的备份反应了创建 snap3 时卷数据的气象。热情编码和箭头暗示 backup-from-snap3 包含来自 snap3 的悉数深红色调动，但仅包含来自 snap2 的绿色调动之一。这是因为 snap3 中的一项红色调动遮蔽了 snap2 中的一项绿色调动。这流露了备份如何不包括调动的好意思满历史记载，因为它们将快照与其之前的快照视并吞律。
每个备份关心我方的一组 2 MB 块。每个 2 MB 块仅备份一次。两个备份分享一个绿色块和一个蓝色块。当备份从二级存储中删除时，Longhorn 不会删除它使用的悉数块。相背，它会依期实施垃圾采集以撤废扶持存储中未使用的块。
属于并吞卷的悉数备份的 2 MB 块存储在一个群众目次下，因此不错跨多个备份分享。
为了从简空间，备份之间莫得变化的 2 MB 块不错重迭用于在二级存储中分享同样备份卷的多个备份。由于校验(checksums)和用于寻址 2 MB 块，因此咱们对并吞卷中的 2 MB 块结束了某种程度的重迭数据删除。
卷级元数据(Volume-level metadata)存储在 volume.cfg 中。每个备份的元数据文献(举例 snap2.cfg)相对较小， 因为它们仅包含备份中悉数 2 MB 块的offsets和checksums。
压缩每个 2 MB 块(.blk 文献)。
3.2. 依期备份不错使用依期快照(recurring snapshot)和备份功能来安排备份操作，但也不错把柄需要进行。
漠视为您的卷安排依期备份。若是备份存储(backupstore)不可用，漠视改为安排依期快照。
一次备战欧洲杯中，法国球星姆巴佩突然伤膝盖，引发担忧。不过，据医生透露，伤势并严重，开始恢复。创建备份波及通过采集复制数据，因此需要时间。
3.3. 恶运归附卷恶运归附 (DR) 卷是一种极端卷，可在整个主集群出现故障时将数据存储在备份集群中。DR 卷用于晋升 Longhorn 卷的弹性。
由于 DR 卷的主要用途是从备份中归附数据，因此此类卷在激活之前不救助以下操作：
创建、删除和归附快照 创建备份 创建抓久卷 创建抓久卷声明不错从备份存储中的卷备份创建 DR 卷。创建 DR 卷后，Longhorn 将监控其原始备份卷并从最新备份增量归附。备份卷是备份存储中包含并吞卷的多个备份的对象。
若是主集群中的原始卷宕机，不错立即激活备份集群中的 DR 卷，这么不错大大减少将数据从备份存储归附到备份集群中的卷所需的时间。
当 DR 卷被激活时，Longhorn 将查验原始卷的临了备份。若是该备份尚未归附，则将运行归附，而况激活操作将失败。用户需要恭候归附完成后再重试。
若是存在职何 DR 卷，则无法更新 Longhorn 诞生中的备份方针。
DR 卷被激活后，它会变成一个平素的 Longhorn 卷而况不成被停用。
3.4. 备份存储更新断绝、RTO 和 RPO每每增量归附由依期备份存储更新触发。用户不错在诞生(Setting)-通用(General)-备份(Backupstore)存储轮询断绝中诞生备份存储更新断绝。
请属目，此断绝可能会影响归附时间方针 (RTO)。若是时间过长，容灾卷归附的数据量可能比较大，时间会比较长。
皇冠信用盘口至于归附点方针 (RPO)，它由备份卷的依期备份贪图笃定。若是正常卷 A 的依期备份贪图每小时创建一个备份，则 RPO 为一小时。您不错在此处检察如安在 Longhorn 中诞生依期备份。
以下分析假定该卷每小时创建一个备份，而况从一个备份中增量归附数据需要五分钟：
若是 Backupstore 轮询断绝为 30 分钟，则自前次归附以来最多有一个备份数据。归附一份备份的时间为五分钟，因此 RTO 为五分钟。
若是 Backupstore 轮询断绝为 12 小时，则自前次归附以来最多有 12 个数据备份。归附备份的时间为 5 * 12 = 60 分钟，因此 RTO 为 60 分钟。
附录：抓久性存储在 Kubernetes 中的职责旨趣要了解 Kubernetes 中的抓久存储，紧迫的是要了解 Volumes、PersistentVolumes、PersistentVolumeClaims 和 StorageClasses，以及它们如何协同职责。
Kubernetes Volume 的一个紧迫属性是它与它所属的 Pod 具有同样的生命周期。若是 Pod 不见了，Volume 就会丢失。比较之下，PersistentVolume 不息存在于系统中，直到用户将其删除。卷也可用于在并吞个 Pod 内的容器之间分享数据，但这不是主要用例，因为用户每每每个 Pod 只须一个容器。
PersistentVolume (PV) 是 Kubernetes 集群中的一块抓久存储， 而 PersistentVolumeClaim (PVC) 是一个存储肯求。 StorageClasses 允许把柄需要为职责负载动态设立新存储。
Kubernetes 职责负载如何使用新的和现存的抓久存储
从广义上讲，在 Kubernetes 中使用抓久化存储主要有两种面目：
使用现存的抓久卷 动态设立新的抓久卷现存存储设立
要使用现存 PV，您的应用步调需要使用绑定到 PV 的 PVC，而况 PV 应包含 PVC 所需的最少资源。
换句话说，在 Kubernetes 中诞生现存存储的典型职责经过如下：
在您有权探望的物理或捏造存储的兴味上诞生抓久存储卷。 添加援用抓久存储的 PV。 添加援用 PV 的 PVC。 在您的职责负载中将 PVC 挂载为卷。当 PVC 肯求一块存储时，Kubernetes API 处事器将尝试将该 PVC 与事先分配的 PV 匹配，因为匹配的卷可用。若是不错找到匹配项，则 PVC 将绑定到 PV，而况用户将运诳骗用该事先分配的存储块。
若是不存在匹配的卷，则 PersistentVolumeClaims 将无穷期地保抓未绑定气象。举例，设立了很多 50 Gi PV 的集群与肯求 100 Gi 的 PVC 不匹配。将 100 Gi PV 添加到集群后，不错绑定 PVC。
换句话说，您不错创建无穷的 PVC，但只须当 Kubernetes 主节点不错找到填塞的 PV 且至少具有 PVC 所需的磁盘空间量时，它们才会绑定到 PV。
动态存储设立
关于动态存储设立，您的应用步调需要使用绑定到 StorageClass 的 PVC。 StorageClass 包含提供新抓久卷的授权。
在 Kubernetes 中动态设立新存储的整个职责经过波及一个 StorageClass 资源：
添加 StorageClass 并将其设立为从您有权探望的存储中自动设立新存储。 添加援用 StorageClass 的 PVC。 将 PVC 挂载为职责负载的卷。Kubernetes 集群不停员不错使用 Kubernetes StorageClass 来样子他们提供的存储“类(“classes”)”。 StorageClasses 不错有不同的容量限定、不同的 IOPS 或供应商救助的任何其他参数。存储供应商特定的 provisioner 与 StorageClass 通盘使用，以按照 StorageClass 对象中诞生的参数自动分配 PV。此外，provisioner 当今巧合为用户强制实施资源配额和权限要求。在这种联想中，不停员不错从展望 PV 需乞降分配 PV 的无谓要职责中目田出来。
当使用 StorageClass 时，Kubernetes 不停员不崇拜分配每一块存储。不停员只需要授予用户探望某个存储池的权限，并决定用户的配额即可。然后用户不错从存储池中挖掘出所需的存储部分。
也不错使用 StorageClass，而不需要在 Kubernetes 中显式创建 StorageClass 对象。由于 StorageClass 亦然一个用于匹配带有 PV 的 PVC 的字段，因此不错使用自界说存储类称号手动创建 PV， 然后不错创建一个要求带有该 StorageClass 称号的 PV 的 PVC。然后，Kubernetes 不错使用指定的 StorageClass 称号将 PVC 绑定到 PV，即使 StorageClass 对象并不当作 Kubernetes 资源存在。
Longhorn 引入了一个 Longhorn StorageClass，这么 Kubernetes 职责负载就不错把柄需要别离抓久性存储。
具有抓久存储的 Kubernetes Workloads 的水平彭胀
VolumeClaimTemplate 是一个 StatefulSet spec 属性，它为块存储处分有推敲提供了一种方法来水平彭胀 Kubernetes 职责负载。
此属性可用于为由 StatefulSet 创建的 pod 创建匹配的 pv 和 pvc。
这些 PVC 是使用 StorageClass 创建的，因此不错在 StatefulSet 彭胀时自动诞生它们。
当 StatefulSet 松开时，荒芜的 PV/PVC 会保留在集群中，当 StatefulSet 再次放大时，它们会被重用。
VolumeClaimTemplate 关于 EBS 和 Longhorn 等块存储处分有推敲很紧迫。因为这些处分有推敲本色上是 ReadWriteOnce，是以它们不成在 Pod 之间分享。
若是您有多个 Pod 运行抓久性数据(persistent storage)，那么部署(Deployment)不成很好地与抓久性存储(persistent storage)配合使用。关于多个 pod，应该使用 StatefulSet。
宝马会色碟