作者 | 至天?阿里巴巴高級(jí)研發(fā)工程師

成都創(chuàng)新互聯(lián)技術(shù)團(tuán)隊(duì)十余年來(lái)致力于為客戶(hù)提供網(wǎng)站制作、網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計(jì)、營(yíng)銷(xiāo)型網(wǎng)站、搜索引擎SEO優(yōu)化等服務(wù)。經(jīng)過(guò)多年發(fā)展，公司擁有經(jīng)驗(yàn)豐富的技術(shù)團(tuán)隊(duì)，先后服務(wù)、推廣了千余家網(wǎng)站，包括各類(lèi)中小企業(yè)、企事單位、高校等機(jī)構(gòu)單位。

一、基本知識(shí)

存儲(chǔ)快照產(chǎn)生背景

在使用存儲(chǔ)時(shí)，為了提高數(shù)據(jù)操作的容錯(cuò)性，我們通常有需要對(duì)線上數(shù)據(jù)進(jìn)行 snapshot ，以及能快速 restore 的能力。另外，當(dāng)需要對(duì)線上數(shù)據(jù)進(jìn)行快速的復(fù)制以及遷移等動(dòng)作，如進(jìn)行環(huán)境的復(fù)制、數(shù)據(jù)開(kāi)發(fā)等功能時(shí)，都可以通過(guò)存儲(chǔ)快照來(lái)滿(mǎn)足需求，而 K8s 中通過(guò) CSI Snapshotter controller 來(lái)實(shí)現(xiàn)存儲(chǔ)快照的功能。

存儲(chǔ)快照用戶(hù)接口-Snapshot

我們知道，K8s 中通過(guò) pvc 以及 pv 的設(shè)計(jì)體系來(lái)簡(jiǎn)化用戶(hù)對(duì)存儲(chǔ)的使用，而存儲(chǔ)快照的設(shè)計(jì)其實(shí)是仿照? pvc & pv 體系的設(shè)計(jì)思想。當(dāng)用戶(hù)需要存儲(chǔ)快照的功能時(shí)，可以通過(guò) VolumeSnapshot 對(duì)象來(lái)聲明，并指定相應(yīng)的 VolumeSnapshotClass 對(duì)象，之后由集群中的相關(guān)組件動(dòng)態(tài)生成存儲(chǔ)快照以及存儲(chǔ)快照對(duì)應(yīng)的對(duì)象 VolumeSnapshotContent 。如下對(duì)比圖所示，動(dòng)態(tài)生成 VolumeSnapshotContent 和動(dòng)態(tài)生成 pv 的流程是非常相似的。

存儲(chǔ)快照用戶(hù)接口-Restore

有了存儲(chǔ)快照之后，如何將快照數(shù)據(jù)快速恢復(fù)過(guò)來(lái)呢？如下圖所示：

如上所示的流程，可以借助 PVC 對(duì)象將其的 dataSource 字段指定為 VolumeSnapshot 對(duì)象。這樣當(dāng) PVC 提交之后，會(huì)由集群中的相關(guān)組件找到 dataSource 所指向的存儲(chǔ)快照數(shù)據(jù)，然后新創(chuàng)建對(duì)應(yīng)的存儲(chǔ)以及 pv 對(duì)象，將存儲(chǔ)快照數(shù)據(jù)恢復(fù)到新的 pv 中，這樣數(shù)據(jù)就恢復(fù)回來(lái)了，這就是存儲(chǔ)快照的 restore 用法。

Topolopy-含義

首先了解一下拓?fù)涫鞘裁匆馑迹哼@里所說(shuō)的拓?fù)涫?K8s 集群中為管理的 nodes 劃分的一種“位置”關(guān)系，意思為：可以通過(guò)在 node 的 labels 信息里面填寫(xiě)某一個(gè) node 屬于某一個(gè)拓?fù)洹?lt;br />?<br />常見(jiàn)的有三種，這三種在使用時(shí)經(jīng)常會(huì)遇到的：

• 第一種，在使用云存儲(chǔ)服務(wù)的時(shí)候，經(jīng)常會(huì)遇到?region，也就是地區(qū)的概念，在 K8s 中常通過(guò) label?failure-domain.beta.kubernetes.io/region 來(lái)標(biāo)識(shí)。這個(gè)是為了標(biāo)識(shí)單個(gè) K8s 集群管理的跨 region 的 nodes 到底屬于哪個(gè)地區(qū)；

• 第二種，比較常用的是可用區(qū)，也就是?available?zone，在 K8s 中常通過(guò) label failure-domain.beta.kubernetes.io/zone 來(lái)標(biāo)識(shí)。這個(gè)是為了標(biāo)識(shí)單個(gè) K8s 集群管理的跨 zone 的 nodes 到底屬于哪個(gè)可用區(qū)；

• 第三種，是?hostname，就是單機(jī)維度，是拓?fù)溆驗(yàn)?node 范圍，在 K8s 中常通過(guò) label?kubernetes.io/hostname 來(lái)標(biāo)識(shí)，這個(gè)在文章的最后講 local pv 的時(shí)候，會(huì)再詳細(xì)描述。

上面講到的三個(gè)拓?fù)涫潜容^常用的，而拓?fù)淦鋵?shí)是可以自己定義的。可以定義一個(gè)字符串來(lái)表示一個(gè)拓?fù)溆颍@個(gè) key 所對(duì)應(yīng)的值其實(shí)就是拓?fù)溆蛳虏煌耐負(fù)湮恢谩?/p>

舉個(gè)例子：可以用?rack，也就是機(jī)房中的機(jī)架這個(gè)緯度來(lái)做一個(gè)拓?fù)溆颉＿@樣就可以將不同機(jī)架 ( rack ) 上面的機(jī)器標(biāo)記為不同的拓?fù)湮恢茫簿褪钦f(shuō)可以將不同機(jī)架上機(jī)器的位置關(guān)系通過(guò) rack 這個(gè)緯度來(lái)標(biāo)識(shí)。屬于 rack1 上的機(jī)器，node label 中都添加 rack 的標(biāo)識(shí)，它的 value 就標(biāo)識(shí)成 rack1，即 rack=rack1；另外一組機(jī)架上的機(jī)器可以標(biāo)識(shí)為 rack=rack2，這樣就可以通過(guò)機(jī)架的緯度就來(lái)區(qū)分來(lái) K8s 中的 node 所處的位置。

接下來(lái)就一起來(lái)看看拓?fù)湓?K8s 存儲(chǔ)中的使用。

存儲(chǔ)拓?fù)湔{(diào)度產(chǎn)生背景

上一節(jié)課我們說(shuō)過(guò)，K8s 中通過(guò) PV 的 PVC 體系將存儲(chǔ)資源和計(jì)算資源分開(kāi)管理了。如果創(chuàng)建出來(lái)的 PV有"訪問(wèn)位置"的限制，也就是說(shuō)，它通過(guò) nodeAffinity 來(lái)指定哪些 node 可以訪問(wèn)這個(gè) PV。為什么會(huì)有這個(gè)訪問(wèn)位置的限制？

因?yàn)樵?K8s 中創(chuàng)建 pod 的流程和創(chuàng)建 PV 的流程，其實(shí)可以認(rèn)為是并行進(jìn)行的，這樣的話，就沒(méi)有辦法來(lái)保證 pod 最終運(yùn)行的 node 是能訪問(wèn)到 有位置限制的 PV 對(duì)應(yīng)的存儲(chǔ)，最終導(dǎo)致 pod 沒(méi)法正常運(yùn)行。這里來(lái)舉兩個(gè)經(jīng)典的例子：

首先來(lái)看一下?Local PV 的例子，Local PV 是將一個(gè) node 上的本地存儲(chǔ)封裝為 PV，通過(guò)使用 PV 的方式來(lái)訪問(wèn)本地存儲(chǔ)。為什么會(huì)有 Local PV 的需求呢？簡(jiǎn)單來(lái)說(shuō)，剛開(kāi)始使用 PV 或 PVC 體系的時(shí)候，主要是用來(lái)針對(duì)分布式存儲(chǔ)的，分布式存儲(chǔ)依賴(lài)于網(wǎng)絡(luò)，如果某些業(yè)務(wù)對(duì) I/O 的性能要求非常高，可能通過(guò)網(wǎng)絡(luò)訪問(wèn)分布式存儲(chǔ)沒(méi)辦法滿(mǎn)足它的性能需求。這個(gè)時(shí)候需要使用本地存儲(chǔ)，刨除了網(wǎng)絡(luò)的 overhead，性能往往會(huì)比較高。但是用本地存儲(chǔ)也是有壞處的！分布式存儲(chǔ)可以通過(guò)多副本來(lái)保證高可用，但本地存儲(chǔ)就需要業(yè)務(wù)自己用類(lèi)似 Raft 協(xié)議來(lái)實(shí)現(xiàn)多副本高可用。

接下來(lái)看一下 Local PV 場(chǎng)景可能如果沒(méi)有對(duì) PV 做“訪問(wèn)位置”的限制會(huì)遇到什么問(wèn)題？

當(dāng)用戶(hù)在提交完 PVC 的時(shí)候，K8s PV controller可能綁定的是 node2 上面的 PV。但是，真正使用這個(gè) PV 的 pod，在被調(diào)度的時(shí)候，有可能調(diào)度在 node1 上，最終導(dǎo)致這個(gè) pod 在起來(lái)的時(shí)候沒(méi)辦法去使用這塊存儲(chǔ)，因?yàn)?pod 真實(shí)情況是要使用 node2 上面的存儲(chǔ)。

第二個(gè)(如果不對(duì) PV 做“訪問(wèn)位置”的限制會(huì)出問(wèn)題的)場(chǎng)景：

如果搭建的 K8s 集群管理的 nodes 分布在單個(gè)區(qū)域多個(gè)可用區(qū)內(nèi)。在創(chuàng)建動(dòng)態(tài)存儲(chǔ)的時(shí)候，創(chuàng)建出來(lái)的存儲(chǔ)屬于可用區(qū) 2，但之后在提交使用該存儲(chǔ)的 pod，它可能會(huì)被調(diào)度到可用區(qū) 1 了，那就可能沒(méi)辦法使用這塊存儲(chǔ)。因此像阿里云的云盤(pán)，也就是塊存儲(chǔ)，當(dāng)前不能跨可用區(qū)使用，如果創(chuàng)建的存儲(chǔ)其實(shí)屬于可用區(qū) 2，但是 pod 運(yùn)行在可用區(qū) 1，就沒(méi)辦法使用這塊存儲(chǔ)，這是第二個(gè)常見(jiàn)的問(wèn)題場(chǎng)景。

接下來(lái)我們來(lái)看看 K8s 中如何通過(guò)存儲(chǔ)拓?fù)湔{(diào)度來(lái)解決上面的問(wèn)題的。

存儲(chǔ)拓?fù)湔{(diào)度

首先總結(jié)一下之前的兩個(gè)問(wèn)題，它們都是 PV 在給 PVC 綁定或者動(dòng)態(tài)生成 PV 的時(shí)候，我并不知道后面將使用它的 pod 將調(diào)度在哪些 node 上。但 PV 本身的使用，是對(duì) pod 所在的 node 有拓?fù)湮恢玫南拗频模?Local PV 場(chǎng)景是我要調(diào)度在指定的 node 上我才能使用那塊 PV，而對(duì)第二個(gè)問(wèn)題場(chǎng)景就是說(shuō)跨可用區(qū)的話，必須要在將使用該 PV 的 pod 調(diào)度到同一個(gè)可用區(qū)的 node 上才能使用阿里云云盤(pán)服務(wù)，那 K8s 中怎樣去解決這個(gè)問(wèn)題呢？

簡(jiǎn)單來(lái)說(shuō)，在 K8s 中將 PV 和 PVC 的 binding 操作和動(dòng)態(tài)創(chuàng)建 PV 的操作做了 delay，delay 到 pod 調(diào)度結(jié)果出來(lái)之后，再去做這兩個(gè)操作。這樣的話有什么好處？

• 首先，如果要是所要使用的 PV 是預(yù)分配的，如 Local PV，其實(shí)使用這塊 PV 的 pod 它對(duì)應(yīng)的 PVC 其實(shí)還沒(méi)有做綁定，就可以通過(guò)調(diào)度器在調(diào)度的過(guò)程中，結(jié)合 pod 的計(jì)算資源需求(如 cpu/mem) 以及 pod 的 PVC 需求，選擇的 node 既要滿(mǎn)足計(jì)算資源的需求又要 pod 使用的 pvc 要能 binding 的 pv 的 nodeaffinity 限制;
• 其次對(duì)動(dòng)態(tài)生成 PV 的場(chǎng)景其實(shí)就相當(dāng)于是如果知道 pod 運(yùn)行的 node 之后，就可以根據(jù) node 上記錄的拓?fù)湫畔?lái)動(dòng)態(tài)的創(chuàng)建這個(gè) PV，也就是保證新創(chuàng)建出來(lái)的 PV 的拓?fù)湮恢门c運(yùn)行的 node 所在的拓?fù)湮恢檬且恢碌模缟厦嫠龅陌⒗镌圃票P(pán)的例子，既然知道 pod 要運(yùn)行到可用區(qū) 1，那之后創(chuàng)建存儲(chǔ)時(shí)指定在可用區(qū) 1 創(chuàng)建即可。

為了實(shí)現(xiàn)上面所說(shuō)的延遲綁定和延遲創(chuàng)建 PV，需要在 K8s 中的改動(dòng)涉及到的相關(guān)組件有三個(gè)：

• PV Controller 也就是 persistent volume controller，它需要支持延遲 Binding 這個(gè)操作。
• 另一個(gè)是動(dòng)態(tài)生成 PV 的組件，如果 pod 調(diào)度結(jié)果出來(lái)之后，它要根據(jù) pod 的拓?fù)湫畔?lái)去動(dòng)態(tài)的創(chuàng)建 PV。
• 第三組件，也是最重要的一個(gè)改動(dòng)點(diǎn)就是 kube-scheduler。在為 pod 選擇 node 節(jié)點(diǎn)的時(shí)候，它不僅要考慮 pod 對(duì) CPU/MEM 的計(jì)算資源的需求，它還要考慮這個(gè) pod 對(duì)存儲(chǔ)的需求，也就是根據(jù)它的 PVC，它要先去看一下當(dāng)前要選擇的 node，能否滿(mǎn)足能和這個(gè) PVC 能匹配的 PV 的 nodeAffinity；或者是動(dòng)態(tài)生成 PV 的過(guò)程，它要根據(jù) StorageClass 中指定的拓?fù)湎拗苼?lái) check 當(dāng)前的 node 是不是滿(mǎn)足這個(gè)拓?fù)湎拗疲@樣就能保證調(diào)度器最終選擇出來(lái)的 node 就能滿(mǎn)足存儲(chǔ)本身對(duì)拓?fù)涞南拗啤?/li>

這就是存儲(chǔ)拓?fù)湔{(diào)度的相關(guān)知識(shí)。

二、用例解讀

接下來(lái)通過(guò) yaml 用例來(lái)解讀一下第一部分的基本知識(shí)。

Volume Snapshot/Restore示例

下面來(lái)看一下存儲(chǔ)快照如何使用：首先需要集群管理員，在集群中創(chuàng)建 VolumeSnapshotClass 對(duì)象，VolumeSnapshotClass 中一個(gè)重要字段就是 Snapshot，它是指定真正創(chuàng)建存儲(chǔ)快照所使用的卷插件，這個(gè)卷插件是需要提前部署的，稍后再說(shuō)這個(gè)卷插件。

接下來(lái)用戶(hù)他如果要做真正的存儲(chǔ)快照，需要聲明一個(gè) VolumeSnapshotClass ， VolumeSnapshotClass 首先它要指定的是 VolumeSnapshotClassName，接著它要指定的一個(gè)非常重要的字段就是 source，這個(gè) source 其實(shí)就是指定快照的數(shù)據(jù)源是啥。這個(gè)地方指定 name 為 disk-pvc，也就是說(shuō)通過(guò)這個(gè) pvc 對(duì)象來(lái)創(chuàng)建存儲(chǔ)快照。提交這個(gè) VolumeSnapshot 對(duì)象之后，集群中的相關(guān)組件它會(huì)找到這個(gè) PVC 對(duì)應(yīng)的 PV 存儲(chǔ)，對(duì)這個(gè) PV 存儲(chǔ)做一次快照。

有了存儲(chǔ)快照之后，那接下來(lái)怎么去用存儲(chǔ)快照恢復(fù)數(shù)據(jù)呢？這個(gè)其實(shí)也很簡(jiǎn)單，通過(guò)聲明一個(gè)新的 PVC 對(duì)象并在它的 spec 下面的 DataSource 中來(lái)聲明我的數(shù)據(jù)源來(lái)自于哪個(gè) VolumeSnapshot，這里指定的是 disk-snapshot 對(duì)象，當(dāng)我這個(gè) PVC 提交之后，集群中的相關(guān)組件，它會(huì)動(dòng)態(tài)生成新的 PV 存儲(chǔ)，這個(gè)新的 PV 存儲(chǔ)中的數(shù)據(jù)就來(lái)源于這個(gè) Snapshot 之前做的存儲(chǔ)快照。

Local PV 的示例

如下圖看一下 Local PV 的 yaml 示例：

Local PV 大部分使用的時(shí)候都是通過(guò)靜態(tài)創(chuàng)建的方式，也就是要先去聲明 PV 對(duì)象，既然 Local PV 只能是本地訪問(wèn)，就需要在聲明 PV 對(duì)象的，在 PV 對(duì)象中通過(guò) nodeAffinity 來(lái)限制我這個(gè) PV 只能在單 node 上訪問(wèn)，也就是給這個(gè) PV 加上拓?fù)湎拗啤Ｈ缟蠄D拓?fù)涞?key 用 kubernetes.io/hostname 來(lái)做標(biāo)記，也就是只能在 node1 訪問(wèn)。如果想用這個(gè) PV，你的 pod 必須要調(diào)度到 node1 上。

既然是靜態(tài)創(chuàng)建 PV 的方式，這里為什么還需要 storageClassname 呢？前面也說(shuō)了，在 Local PV 中，如果要想讓它正常工作，需要用到延遲綁定特性才行，那既然是延遲綁定，當(dāng)用戶(hù)在寫(xiě)完 PVC 提交之后，即使集群中有相關(guān)的 PV 能跟它匹配，它也暫時(shí)不能做匹配，也就是說(shuō) PV controller 不能馬上去做 binding，這個(gè)時(shí)候你就要通過(guò)一種手段來(lái)告訴 PV controller，什么情況下是不能立即做?binding。這里的 storageClass 就是為了起到這個(gè)副作用，我們可以看到 storageClass 里面的 provisioner 指定的是?no-provisioner，其實(shí)就是相當(dāng)于告訴 K8s 它不會(huì)去動(dòng)態(tài)創(chuàng)建 PV，它主要用到 storageclass 的VolumeBindingMode 字段，叫 WaitForFirstConsumer，可以先簡(jiǎn)單地認(rèn)為它是延遲綁定。

當(dāng)用戶(hù)開(kāi)始提交 PVC 的時(shí)候，pv controller 在看到這個(gè) pvc 的時(shí)候，它會(huì)找到相應(yīng)的 storageClass，發(fā)現(xiàn)這個(gè) BindingMode 是延遲綁定，它就不會(huì)做任何事情。

之后當(dāng)真正使用這個(gè) pvc 的 pod，在調(diào)度的時(shí)候，當(dāng)它恰好調(diào)度在符合 pv nodeaffinity 的 node 的上面后，這個(gè) pod 里面所使用的 PVC 才會(huì)真正地與 PV 做綁定，這樣就保證我 pod 調(diào)度到這臺(tái) node 上之后，這個(gè) PVC 才與這個(gè) PV 綁定，最終保證的是創(chuàng)建出來(lái)的 pod 能訪問(wèn)這塊 Local PV，也就是靜態(tài) Provisioning 場(chǎng)景下怎么去滿(mǎn)足 PV 的拓?fù)湎拗啤?/p>

限制 Dynamic Provisioning PV 拓?fù)涫纠?/h4>

再看一下動(dòng)態(tài) Provisioning PV 的時(shí)候，怎么去做拓?fù)湎拗频模?/p>

動(dòng)態(tài)就是指動(dòng)態(tài)創(chuàng)建 PV 就有拓?fù)湮恢玫南拗疲窃趺慈ブ付ǎ?/p>

首先在 storageclass 還是需要指定 BindingMode，就是 WaitForFirstConsumer，就是延遲綁定。

其次特別重要的一個(gè)字段就是?allowedTopologies，限制就在這個(gè)地方。上圖中可以看到拓?fù)湎拗剖强捎脜^(qū)的級(jí)別，這里其實(shí)有兩層意思：

1. 第一層意思就是說(shuō)我在動(dòng)態(tài)創(chuàng)建 PV 的時(shí)候，創(chuàng)建出來(lái)的 PV 必須是在這個(gè)可用區(qū)可以訪問(wèn)的;
2. 第二層含義是因?yàn)槁暶鞯氖茄舆t綁定，那調(diào)度器在發(fā)現(xiàn)使用它的 PVC 正好對(duì)應(yīng)的是該 storageclass 的時(shí)候，調(diào)度 pod 就要選擇位于該可用區(qū)的 nodes。

總之，就是要從兩方面保證，一是動(dòng)態(tài)創(chuàng)建出來(lái)的存儲(chǔ)時(shí)要能被這個(gè)可用區(qū)訪問(wèn)的，二是我調(diào)度器在選擇 node 的時(shí)候，要落在這個(gè)可用區(qū)內(nèi)的，這樣的話就保證我的存儲(chǔ)和我要使用存儲(chǔ)的這個(gè) pod 它所對(duì)應(yīng)的 node，它們之間的拓?fù)溆蚴窃谕粋€(gè)拓?fù)溆颍脩?hù)在寫(xiě) PVC 文件的時(shí)候，寫(xiě)法是跟以前的寫(xiě)法是一樣的，主要是在 storageclass 中要做一些拓?fù)湎拗啤?/p>

三、操作演示

本節(jié)將在線上環(huán)境來(lái)演示一下前面講解的內(nèi)容。

首先來(lái)看一下我的阿里云服務(wù)器上搭建的 K8s 服務(wù)。總共有 3 個(gè) node 節(jié)點(diǎn)。一個(gè) master 節(jié)點(diǎn)，兩個(gè) node。其中 master 節(jié)點(diǎn)是不能調(diào)度 pod 的。

再看一下，我已經(jīng)提前把我需要的插件已經(jīng)布好了，一個(gè)是 snapshot 插件? ( csi-external-snapshot ) ，一個(gè)是動(dòng)態(tài)云盤(pán)的插件? ( csi-disk ) 。

現(xiàn)在開(kāi)始 snapshot 的演示。首先去動(dòng)態(tài)創(chuàng)建云盤(pán)，然后才能做 snapshot。動(dòng)態(tài)創(chuàng)建云盤(pán)需要先創(chuàng)建? storageclass，然后去根據(jù) PVC 動(dòng)態(tài)創(chuàng)建 PV，然后再創(chuàng)建一個(gè)使用它的 pod 了。

有個(gè)以上對(duì)象，現(xiàn)在就可以做 snapshot 了，首先看一下做 snapshot 需要的第一個(gè)配置文件：snapshotclass.yaml。

其實(shí)里面就是指定了在做存儲(chǔ)快照的時(shí)候需要使用的插件，這個(gè)插件剛才演示了已經(jīng)部署好了，就是 csi-external-snapshot-0 這個(gè)插件。

接下來(lái)創(chuàng)建 volume-snapshotclass 文件，創(chuàng)建完之后就開(kāi)始了 snapshot。

然后看 snapshot.yaml，Volumesnapshot 聲明創(chuàng)建存儲(chǔ)快照了，這個(gè)地方就指定剛才創(chuàng)建的那個(gè) PVC 來(lái)做的數(shù)據(jù)源來(lái)做 snapshot，那我們開(kāi)始創(chuàng)建。

我們看一下 Snapshot 有沒(méi)有創(chuàng)建好，如下圖所示，content 已經(jīng)在 11 秒之前創(chuàng)建好了。

可以看一下它里面的內(nèi)容，主要看 volumesnapshotcontent 記錄的一些信息，這個(gè)是我 snapshot 出來(lái)之后，它記錄的就是云存儲(chǔ)廠商那邊返回給我的 snapshot 的 ID。然后是這個(gè) snapshot 數(shù)據(jù)源，也就是剛才指定的 PVC，可以通過(guò)它會(huì)找到對(duì)應(yīng)的 PV。

snapshot 的演示大概就是這樣，把剛才創(chuàng)建的 snapshot 刪掉，還是通過(guò) volumesnapshot 來(lái)刪掉。然后看一下，動(dòng)態(tài)創(chuàng)建的這個(gè) volumesnapshotcontent 也被刪掉。

接下來(lái)看一下動(dòng)態(tài) PV 創(chuàng)建的過(guò)程加上一些拓?fù)湎拗疲紫葘⒌?storageclass 創(chuàng)建出來(lái)，然后再看一下 storageclass 里面做的限制，storageclass 首先還是指定它的 BindingMode 為 WaitForFirstConsumer，也就是做延遲綁定，然后是對(duì)它的拓?fù)湎拗疲疫@里面在 allowedTopologies 字段中配置了一個(gè)可用區(qū)級(jí)別的限制。

來(lái)嘗試創(chuàng)建一下的 PVC，PVC 創(chuàng)建出來(lái)之后，理論上它應(yīng)該處在 pending 狀態(tài)。看一下，它現(xiàn)在因?yàn)樗鲅舆t綁定，由于現(xiàn)在沒(méi)有使用它的 pod，暫時(shí)沒(méi)辦法去做綁定，也沒(méi)辦法去動(dòng)態(tài)創(chuàng)建新的 PV。

接下來(lái)創(chuàng)建使用該 pvc 的 pod 看會(huì)有什么效果，看一下 pod，pod 也處在 pending了。

那來(lái)看一下 pod 為啥處在 pending 狀態(tài)，可以看一下是調(diào)度失敗了，調(diào)度失敗原因：一個(gè) node 由于 taint 不能調(diào)度，這個(gè)其實(shí)是 master，另外兩個(gè) node 也是沒(méi)有說(shuō)是可綁定的 PV。

為什么會(huì)有兩個(gè) node 出現(xiàn)沒(méi)有可綁定的 pv 的錯(cuò)誤？不是動(dòng)態(tài)創(chuàng)建么？

我們來(lái)仔細(xì)看看 storageclass 中的拓?fù)湎拗疲ㄟ^(guò)上面的講解我們知道，這里限制使用該 storageclass 創(chuàng)建的 PV 存儲(chǔ)必須在可用區(qū) cn-hangzhou-d 可訪問(wèn)的，而使用該存儲(chǔ)的 pod 也必須調(diào)度到?cn-hangzhou-d 的 node 上。

那就來(lái)看一下 node 節(jié)點(diǎn)上有沒(méi)有這個(gè)拓?fù)湫畔ⅲ绻鼪](méi)有當(dāng)然是不行了。

看一下第一個(gè) node 的全量信息吧，主要找它的 labels 里面的信息，看 lables 里面的確有一個(gè)這樣的 key。也就是說(shuō)有一個(gè)這樣的拓?fù)洌沁@指定是?cn-hangzhou-b，剛才 storageclass 里面指定的是?cn-hangzhou-d。

那看一下另外的一個(gè) node 上的這個(gè)拓?fù)湫畔?xiě)的也是 hangzhou-b，但是我們那個(gè) storageclass 里面限制是 d。

這就導(dǎo)致最終沒(méi)辦法將 pod 調(diào)度在這兩個(gè) node 上。現(xiàn)在我們修改一下 storageclass 中的拓?fù)湎拗疲瑢?cn-hangzhou-d 改為 cn-hangzhou-b。

改完之后再看一下，其實(shí)就是說(shuō)我動(dòng)態(tài)創(chuàng)建出來(lái)的 PV 要能被 hangzhou-b 這個(gè)可用區(qū)訪問(wèn)的，使用該存儲(chǔ)的 pod 要調(diào)度到該可用區(qū)的 node 上。把之前的 pod 刪掉，讓它重新被調(diào)度看一下有什么結(jié)果，好，現(xiàn)在這個(gè)已經(jīng)調(diào)度成功了，就是已經(jīng)在啟動(dòng)容器階段。

說(shuō)明剛才把 storageclass 它里面的對(duì)可用區(qū)的限制從 hangzhou-d 改為 hangzhou-b 之后，集群中就有兩個(gè) node，它的拓?fù)潢P(guān)系是和 storageclass 里要求的拓?fù)潢P(guān)系是相匹配的，這樣的話它就能保證它的 pod 是有 node 節(jié)點(diǎn)可調(diào)度的。上圖中最后一點(diǎn) Pod 已經(jīng) Running 了，說(shuō)明剛才的拓?fù)湎拗聘膭?dòng)之后可以 work 了。

四、處理流程

kubernetes 對(duì) Volume Snapshot/Restore 處理流程

接下來(lái)看一下 K8s 中對(duì)存儲(chǔ)快照與拓?fù)湔{(diào)度的具體處理流程。如下圖所示：

首先來(lái)看一下存儲(chǔ)快照的處理流程，這里來(lái)首先解釋一下 csi 部分。K8s 中對(duì)存儲(chǔ)的擴(kuò)展功能都是推薦通過(guò) csi out-of-tree 的方式來(lái)實(shí)現(xiàn)的。

csi 實(shí)現(xiàn)存儲(chǔ)擴(kuò)展主要包含兩部分：

• 第一部分是由 K8s 社區(qū)推動(dòng)實(shí)現(xiàn)的 csi controller 部分，也就是這里的 csi-snapshottor controller 以及 csi-provisioner controller，這些主要是通用的 controller 部分;
• 另外一部分是由特定的云存儲(chǔ)廠商用自身 OpenAPI 實(shí)現(xiàn)的不同的 csi-plugin 部分，也叫存儲(chǔ)的 driver 部分。

兩部分部件通過(guò) unix domain socket 通信連接到一起。有這兩部分，才能形成一個(gè)真正的存儲(chǔ)擴(kuò)展功能。

如上圖所示，當(dāng)用戶(hù)提交 VolumeSnapshot 對(duì)象之后，會(huì)被 csi-snapshottor controller watch 到。之后它會(huì)通過(guò) GPPC 調(diào)用到 csi-plugin，csi-plugin 通過(guò) OpenAPI 來(lái)真正實(shí)現(xiàn)存儲(chǔ)快照的動(dòng)作，等存儲(chǔ)快照已經(jīng)生成之后，會(huì)返回到 csi-snapshottor controller 中，csi-snapshottor controller 會(huì)將存儲(chǔ)快照生成的相關(guān)信息放到 VolumeSnapshotContent 對(duì)象中并將用戶(hù)提交的 VolumeSnapshot 做 bound。這個(gè) bound 其實(shí)就有點(diǎn)類(lèi)似 PV 和 PVC 的 bound 一樣。

有了存儲(chǔ)快照，如何去使用存儲(chǔ)快照恢復(fù)之前的數(shù)據(jù)呢？前面也說(shuō)過(guò)，通過(guò)聲明一個(gè)新的 PVC 對(duì)象，并且指定他的 dataSource 為 Snapshot 對(duì)象，當(dāng)提交 PVC 的時(shí)候會(huì)被 csi-provisioner watch 到，之后會(huì)通過(guò) GRPC 去創(chuàng)建存儲(chǔ)。這里創(chuàng)建存儲(chǔ)跟之前講解的 csi-provisioner 有一個(gè)不太一樣的地方，就是它里面還指定了 Snapshot 的 ID，當(dāng)去云廠商創(chuàng)建存儲(chǔ)時(shí)，需要多做一步操作，即將之前的快照數(shù)據(jù)恢復(fù)到新創(chuàng)建的存儲(chǔ)中。之后流程返回到 csi-provisioner，它會(huì)將新創(chuàng)建的存儲(chǔ)的相關(guān)信息寫(xiě)到一個(gè)新的 PV 對(duì)象中，新的 PV 對(duì)象被 PV controller watch 到它會(huì)將用戶(hù)提交的 PVC 與 PV 做一個(gè) bound，之后 pod 就可以通過(guò) PVC 來(lái)使用 Restore 出來(lái)的數(shù)據(jù)了。這是 K8s 中對(duì)存儲(chǔ)快照的處理流程。

kubernetes 對(duì) Volume Topology-aware Scheduling 處理流程

接下來(lái)看一下存儲(chǔ)拓?fù)湔{(diào)度的處理流程：

第一個(gè)步驟其實(shí)就是要去聲明延遲綁定，這個(gè)通過(guò) StorageClass 來(lái)做的，上面已經(jīng)闡述過(guò)，這里就不做詳細(xì)描述了。

接下來(lái)看一下調(diào)度器，上圖中紅色部分就是調(diào)度器新加的存儲(chǔ)拓?fù)湔{(diào)度邏輯，我們先來(lái)看一下不加紅色部分時(shí)調(diào)度器的為一個(gè) pod 選擇 node 時(shí)，它的大概流程：

• 首先用戶(hù)提交完 pod 之后，會(huì)被調(diào)度器 watch 到，它就會(huì)去首先做預(yù)選，預(yù)選就是說(shuō)它會(huì)將集群中的所有 node 都來(lái)與這個(gè) pod 它需要的資源做匹配；
• 如果匹配上，就相當(dāng)于這個(gè) node 可以使用，當(dāng)然可能不止一個(gè) node 可以使用，最終會(huì)選出來(lái)一批 node；
• 然后再經(jīng)過(guò)第二個(gè)階段優(yōu)選，優(yōu)選就相當(dāng)于我要對(duì)這些 node 做一個(gè)打分的過(guò)程，通過(guò)打分找到最匹配的一個(gè) node；
• 之后調(diào)度器將調(diào)度結(jié)果寫(xiě)到 pod 里面的 spec.nodeName 字段里面，然后會(huì)被相應(yīng)的 node 上面的 kubelet watch 到，最后就開(kāi)始創(chuàng)建 pod 的整個(gè)流程。

那現(xiàn)在看一下加上卷相關(guān)的調(diào)度的時(shí)候，篩選 node(第二個(gè)步驟)又是怎么做的？

• 先就要找到 pod 中使用的所有 PVC，找到已經(jīng) bound 的 PVC，以及需要延遲綁定的這些 PVC；
• 對(duì)于已經(jīng) bound 的 PVC，要 check 一下它對(duì)應(yīng)的 PV 里面的 nodeAffinity 與當(dāng)前 node 的拓?fù)涫欠衿ヅ?。如果不匹配， 就說(shuō)明這個(gè) node 不能被調(diào)度。如果匹配，繼續(xù)往下走，就要去看一下需要延遲綁定的 PVC；
• 對(duì)于需要延遲綁定的 PVC。先去獲取集群中存量的 PV，滿(mǎn)足 PVC 需求的，先把它全部撈出來(lái)，然后再將它們一一與當(dāng)前的 node labels 上的拓?fù)渥銎ヅ洌绻鼈?存量的 PV)都不匹配，那就說(shuō)明當(dāng)前的存量的 PV 不能滿(mǎn)足需求，就要進(jìn)一步去看一下如果要?jiǎng)討B(tài)創(chuàng)建 PV 當(dāng)前 node 是否滿(mǎn)足拓?fù)湎拗疲簿褪沁€要進(jìn)一步去 check StorageClass 中的拓?fù)湎拗疲绻?StorageClass 中聲明的拓?fù)湎拗婆c當(dāng)前的 node 上面已經(jīng)有的 labels 里面的拓?fù)涫窍嗥ヅ涞模瞧鋵?shí)這個(gè) node 就可以使用，如果不匹配，說(shuō)明該 node 就不能被調(diào)度。

經(jīng)過(guò)這上面步驟之后，就找到了所有即滿(mǎn)足 pod 計(jì)算資源需求又滿(mǎn)足 pod 存儲(chǔ)資源需求的所有 nodes。<br />?<br />當(dāng) node 選出來(lái)之后，第三個(gè)步驟就是調(diào)度器內(nèi)部做的一個(gè)優(yōu)化。這里簡(jiǎn)單過(guò)一下，就是更新經(jīng)過(guò)預(yù)選和優(yōu)選之后，pod 的 node 信息，以及 PV 和 PVC 在 scheduler 中做的一些 cache 信息。

第四個(gè)步驟也是重要的一步，已經(jīng)選擇出來(lái) node 的 Pod，不管其使用的 PVC 是要 binding 已經(jīng)存在的 PV，還是要做動(dòng)態(tài)創(chuàng)建 PV，這時(shí)就可以開(kāi)始做。由調(diào)度器來(lái)觸發(fā)，調(diào)度器它就會(huì)去更新 PVC 對(duì)象和 PV 對(duì)象里面的相關(guān)信息，然后去觸發(fā) PV controller 去做 binding 操作，或者是由 csi-provisioner 去做動(dòng)態(tài)創(chuàng)建流程。

總結(jié)

1. 通過(guò)對(duì)比 PVC&PV 體系講解了存儲(chǔ)快照的相關(guān) K8s 資源對(duì)象以及使用方法；
2. 通過(guò)兩個(gè)實(shí)際場(chǎng)景遇到的問(wèn)題引出存儲(chǔ)拓?fù)湔{(diào)度功能必要性，以及 K8s 中如何通過(guò)拓?fù)湔{(diào)度來(lái)解決這些問(wèn)題；
3. 通過(guò)剖析 K8s 中存儲(chǔ)快照和存儲(chǔ)拓?fù)湔{(diào)度內(nèi)部運(yùn)行機(jī)制，深入理解該部分功能的工作原理。

阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)公眾號(hào)。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性?xún)r(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專(zhuān)為企業(yè)上云打造定制，能夠滿(mǎn)足用戶(hù)豐富、多元化的應(yīng)用場(chǎng)景需求。

分享文章：從零開(kāi)始入門(mén)K8s|應(yīng)用存儲(chǔ)和持久化數(shù)據(jù)卷：存儲(chǔ)快照與拓?fù)湔{(diào)度-創(chuàng)新互聯(lián)
URL分享：http://chinadenli.net/article48/gdcep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、定制開(kāi)發(fā)、企業(yè)建站、建站公司、網(wǎng)站策劃、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)