談?wù)?Kubernetes list/watch 的設(shè)計(jì)原理

kubernetes 的設(shè)計(jì)里面大致上分為 3 部分：

• API 驅(qū)動(dòng)型的特點(diǎn) (API-driven)
• 控制循環(huán)（control loops）與 條件觸發(fā) （Level Trigger）
• API 的可延伸性

而正因?yàn)檫@些設(shè)計(jì)特性，才使得 kubernetes 工作非常穩(wěn)定。

Level Trigger 與 Edge trigger

看到網(wǎng)上有資料是這么解釋兩個(gè)屬于的：

• 條件觸發(fā)(level-trigger，也被稱為水平觸發(fā))LT 指： 只要滿足條件，就觸發(fā)一個(gè)事件(只要有數(shù)據(jù)沒有被獲取，就不斷通知)。
• 邊緣觸發(fā)(edge-trigger)ET: 每當(dāng)狀態(tài)變化時(shí)，觸發(fā)一個(gè)事件。

通過查詢了一些資料，實(shí)際上也不明白這些究竟屬于哪門科學(xué)中的理論，但是具體解釋起來看得很明白。

LEVEL TRIGGERING：電流有兩個(gè)級(jí)別，VH 和 VL。代表了兩個(gè)觸發(fā)事件的級(jí)別。如果將 VH 設(shè)置為 LED 在正時(shí)鐘。當(dāng)電壓為 VH 時(shí)，LED 可以在該時(shí)間線任何時(shí)刻點(diǎn)亮。這稱為 LEVEL TRIGGERING，每當(dāng)遇到 VH 時(shí)間線就會(huì)觸發(fā)事件。事件是在時(shí)間內(nèi)的任何時(shí)刻開始，直到滿足條件。

Edge TRIGGERING: 如圖所示，會(huì)看到上升線與下降線，當(dāng)事件在上升/下降邊緣觸發(fā)時(shí)（兩個(gè)狀態(tài)的交點(diǎn)），稱為邊緣觸發(fā)（Edge TRIGGERING）。

如果需要打開 LED 燈，則當(dāng)時(shí)鐘從 VL 轉(zhuǎn)換到 VH 時(shí)才會(huì)亮起，而不是一家處在對(duì)應(yīng)的時(shí)鐘線上，僅僅是在過渡時(shí)亮起。

為什么 kubernetes 使用 Level Trigger 而不使用 Edge trigger

如圖所述，兩種不同的設(shè)計(jì)模式，隨著時(shí)間形狀進(jìn)行響應(yīng)，當(dāng)系統(tǒng)在由高轉(zhuǎn)低，或由低轉(zhuǎn)高時(shí)，系統(tǒng)處在關(guān)閉或者不可控的異常狀態(tài)下，應(yīng)如何觸發(fā)對(duì)應(yīng)的事件呢。

換一種方式來來解釋，比如說通過 加法運(yùn)算，如下，i=3，當(dāng)給 I+4 作為一個(gè)操作觸發(fā)事件。

#?let?i=3
#?let?i+=4
#?let?i
#?echo?$i
7

當(dāng)為 Edge trigger 時(shí)操作的情況下，將看到 i+4 ,而在 level trigger 時(shí)看到的是 i=7。這里將會(huì)從 ``i+4` 一直到下一個(gè)信號(hào)的觸發(fā)。

信號(hào)的干擾

通常情況下，兩者是沒有區(qū)別的，但在大規(guī)模分布式網(wǎng)絡(luò)環(huán)境中，有很多因素的影響下，任何都是不可靠的，在這種情況下會(huì)改變了我們對(duì)事件信號(hào)的感知。

如圖所示，圖為 Level Trigger 與 Edge trigger 的信號(hào)發(fā)生模擬，在理想情況下，兩者間并沒有什么不同。

一次中斷場(chǎng)景

由圖可知，Edge trigger 當(dāng)在恰當(dāng)?shù)臅r(shí)間點(diǎn)發(fā)生信號(hào)中斷，會(huì)對(duì)整個(gè)流產(chǎn)生很大的影響，甚至改變了整個(gè)狀態(tài)，對(duì)于較少的干擾并不會(huì)對(duì)有更好的結(jié)果，而單次的中斷，使 Edge trigger 錯(cuò)過了從高到低的變化，而 level trigger 基本上保證了整個(gè)信號(hào)量的所有改變狀態(tài)。

兩次中斷的場(chǎng)景下

由圖可看到，信號(hào)的上升和下降中如果存在了中斷，Edge trigger 丟失了上升的信號(hào)，但最終狀態(tài)是正確的。

在信號(hào)狀態(tài)的兩次變化時(shí)發(fā)生了兩次中斷，Level Trigger 與 Edge trigger 之間的區(qū)別很明顯，Edge trigger 的信號(hào)錯(cuò)過了第一次上升，而 Level Trigger 保持了最后觀察到的狀態(tài)，直到拿到了其他狀態(tài)，這種模式保證了得到的信號(hào)基本的正確性，但是發(fā)生延遲到中斷恢復(fù)后。

通過運(yùn)算來表示兩種模式的變化情況

完整的信號(hào)

#?let?i=2

#?let?i+1
#?let?i-=1
#?let?i+1

#?echo?$i
3

Edge trigger

#?let?i=2

#?let?i+1??
(#?let?i-=1)?miss?this
#?let?i+1

#?echo?$i
4

如何使理想狀態(tài)和實(shí)際狀態(tài)一樣呢？

在 Kubernetes 中，不僅僅是觀察對(duì)象的一個(gè)信號(hào)，還觀察了其他兩個(gè)信號(hào)，集群的期待狀態(tài)與實(shí)際狀態(tài)，期望的狀態(tài)是用戶期望集群所處的狀態(tài)，如我運(yùn)行了 2 個(gè)實(shí)例（pod）。在最理想的場(chǎng)景下，集群的實(shí)際狀態(tài)與期待狀態(tài)是相同的，但這個(gè)過程會(huì)受到任意的外界因素干擾被影響下，實(shí)際狀態(tài)與理想狀態(tài)發(fā)生偏差。

Kubernetes 必須接受實(shí)際狀態(tài)，并將其與所需狀態(tài)調(diào)和。不斷地這樣做，采取兩種狀態(tài)，確定其之間的差異，并糾正其不斷更改，以使實(shí)際狀態(tài)達(dá)到理想狀態(tài)。

如圖所示，在一個(gè) Edge trigger 中，最終的結(jié)果很可能會(huì)與理想中的結(jié)果發(fā)生偏差。

當(dāng)初始實(shí)例為 1 時(shí)，并希望擴(kuò)展為 5 個(gè)副本，然后再向下縮容到 2 個(gè)副本，則 Edge trigger 環(huán)境下將看到以下狀態(tài)：系統(tǒng)的實(shí)際狀態(tài)不能立即對(duì)這些命令作出反應(yīng)。正如圖所述，當(dāng)只有 3 個(gè)副本在運(yùn)行時(shí)，它可能會(huì)終止 3 個(gè)副本。這就給我們留下了 0 個(gè)副本，而不是所需的 2 個(gè)副本。

#?let?replicas=1
#?let?replicas?+=?4?#?此時(shí)副本數(shù)為5，但是這個(gè)過程需要時(shí)間而不是立即完成至理想狀態(tài)
#?let?replicas?-=?3?#?當(dāng)未完成時(shí)又接到信號(hào)的變化，此時(shí)副本數(shù)為3，減去3，很可能實(shí)際狀態(tài)為0，與理想狀態(tài)2發(fā)生了偏差

而使用 Level Trigger 時(shí)，會(huì)總是比較完整的期望狀態(tài)和實(shí)際狀態(tài)，直到實(shí)際狀態(tài)與期望狀態(tài)相同。這大大減少了狀態(tài)同步間（錯(cuò)誤）的產(chǎn)生。

總結(jié)

每一種觸發(fā)器的產(chǎn)生一定有其道理，Edge trigger 本身并不是很差，只是應(yīng)用場(chǎng)景的不同，而使用的模式也不同，比如 nginx 的高性能就是使用了 Edge trigger 模型，如 nginx 使用了 Level trigger 在大并發(fā)下，當(dāng)發(fā)生了變更信號(hào)等待返回時(shí)，發(fā)生大量客戶端連接在偵聽隊(duì)列，而 Edge trigger 模型則不會(huì)出現(xiàn)這種情況。

綜上所述，kubernetes 在設(shè)計(jì)時(shí)，各個(gè)組件需要感知數(shù)據(jù)的最終理想狀態(tài)，無需擔(dān)心錯(cuò)過數(shù)據(jù)變化的過程。而設(shè)計(jì) kubernentes 系統(tǒng)消息通知機(jī)制（或數(shù)據(jù)實(shí)時(shí)通知機(jī)制），也應(yīng)滿足以下要求：

• 實(shí)時(shí)性（即數(shù)據(jù)變化時(shí)，相關(guān)組件感覺越快越好）。消息必須是實(shí)時(shí)的。在 list/watch 機(jī)制下，每當(dāng) apiserver 資源有狀態(tài)變化事件時(shí)，都會(huì)及時(shí)將事件推送到客戶端，以保證消息的實(shí)時(shí)性。
• 消息序列：消息的順序也很重要。在并發(fā)場(chǎng)景下，客戶端可能會(huì)在短時(shí)間內(nèi)收到同一資源的多個(gè)事件。對(duì)于關(guān)注最終一致性的 kubernetes 來說，它需要知道哪個(gè)是最新的事件，并保證資源的最終狀態(tài)與最新事件所表達(dá)的一致。kubernetes 在每個(gè)資源事件中都攜帶一個(gè) resourceVersion 標(biāo)簽，這個(gè)標(biāo)簽是遞增的。因此，客戶端在并發(fā)處理同一資源的事件時(shí)，可以比較 resourceVersion，以確保最終狀態(tài)與最新事件的預(yù)期狀態(tài)一致。
• 消息的可靠性，保證消息不丟失或者有可靠的重新獲取的機(jī)制（比如 kubelet 和 kube-apisever 之間的網(wǎng)絡(luò)波動(dòng)（network flashover ）需要保證 kubelet 在網(wǎng)絡(luò)恢復(fù)后可以接收到網(wǎng)絡(luò)故障時(shí)產(chǎn)生的消息）。

正是因?yàn)?Kubernetes 使用了 Level trigger 才讓集群更加可靠。

參考資料

• https://levelup.gitconnected.com/nginx-event-driven-architecture-demonstrated-in-code-51bf0061cad9
• https://www.quora.com/What-is-meant-by-edge-triggering-and-level-triggering

原文鏈接：https://www.cnblogs.com/Cylon/p/15681121.html