構(gòu)建 Kubernetes Operator 的原則

　　Kubernetes(簡(jiǎn)稱(chēng)K8s)上數(shù)據(jù)服務(wù)的自動(dòng)化越來(lái)越受歡迎。在K8s上運(yùn)行有狀態(tài)的工作負(fù)載意味著使用Operator。然而，它發(fā)展演化到今天已經(jīng)變得非常復(fù)雜，像Operator這樣的應(yīng)用模式和擴(kuò)展方式對(duì)于開(kāi)發(fā)者與運(yùn)維者而言愈發(fā)受到歡迎。

　　但工程師們經(jīng)常對(duì)編寫(xiě)K8s Operator的復(fù)雜性感到吃力，這會(huì)影響到最終用戶。據(jù)《2021年K8s數(shù)據(jù)報(bào)告》指出，K8s Operator的質(zhì)量阻礙了公司進(jìn)一步擴(kuò)大K8s占有率。

　　Anynines首席執(zhí)行官Julian Fischer已經(jīng)構(gòu)建自動(dòng)化工具近十年了，他非常了解在處理在云原生平臺(tái)和K8s等分布式基礎(chǔ)設(shè)施上做狀態(tài)管理的復(fù)雜性。

　　Julian首先分享了在構(gòu)建 Operator時(shí)應(yīng)該遵循的方法，他稱(chēng)之為運(yùn)營(yíng)模式，分為四個(gè)部分：

　　第1級(jí)：SysOp或DB要做什么

　　第2級(jí)：容器化，YAML + kubectl

　　第3級(jí)：編寫(xiě) Operator

　　第4級(jí)： Operator 生命周期管理

　　通過(guò)他的分享，可以了解數(shù)據(jù)服務(wù)自動(dòng)化中的常見(jiàn)陷阱以及如何避免，進(jìn)而從技術(shù)和方法學(xué)角度編寫(xiě)更好的K8s Operator。

　　數(shù)據(jù)服務(wù)自動(dòng)化

　　它在數(shù)據(jù)服務(wù)自動(dòng)化的一般主題和K8s之間有點(diǎn)跳躍。一般來(lái)說(shuō)，如果你談?wù)摂?shù)據(jù)服務(wù)自動(dòng)化，你必須做的第一件事就是明確范圍，即你所說(shuō)的數(shù)據(jù)服務(wù)自動(dòng)化真正指什么。對(duì)于我們來(lái)說(shuō)，任何時(shí)候都有一個(gè)使命，那就是將各種數(shù)據(jù)服務(wù)的整個(gè)生命周期完全自動(dòng)化，以便在跨基礎(chǔ)設(shè)施的云原生平臺(tái)上大規(guī)模運(yùn)行。

　　這里不是一些營(yíng)銷(xiāo)噱頭，它是如何對(duì)數(shù)據(jù)服務(wù)自動(dòng)化進(jìn)行范圍分析的一個(gè)例子。例如，為了使多個(gè)數(shù)據(jù)服務(wù)自動(dòng)化，你希望看到某些共享效果，比如你可以將Operatar SDK以外的數(shù)據(jù)服務(wù)納入自動(dòng)化框架。因此，任務(wù)的背景會(huì)產(chǎn)生很大影響。例如，一個(gè)簡(jiǎn)單的K8s集群，有一個(gè)小單位用來(lái)運(yùn)行他們的應(yīng)用程序。假設(shè)使用Postgres數(shù)據(jù)庫(kù)，Postgres一直是我最喜歡的例子。大家都知道，一個(gè)K8s集群對(duì)應(yīng)一個(gè)Operator一個(gè)服務(wù)實(shí)例，應(yīng)用程序?qū)⑦B接到那個(gè)數(shù)據(jù)庫(kù)。這與我們今天想在這里談?wù)摰墓适虏煌�。假設(shè)他們按需配置服務(wù)實(shí)例，Postgres數(shù)據(jù)庫(kù)被表示為有狀態(tài)集。Operator允許你創(chuàng)建多個(gè)實(shí)例。事情就會(huì)變得復(fù)雜，因?yàn)槟阌懈�多的�?shù)據(jù)服務(wù)實(shí)例，你必須處理好它。如果你隨后引入更多數(shù)據(jù)服務(wù)，例如，將RabbitMQ、MongoDB或任何其他數(shù)據(jù)庫(kù)添加到Operator的集合中，挑戰(zhàn)將變得更加大。

　　現(xiàn)在我們協(xié)作的組織中，有時(shí)有數(shù)百或數(shù)千名員工，有數(shù)千名甚至一萬(wàn)名開(kāi)發(fā)人員，令人難以置信的是，他們擁有數(shù)量龐大的工程師，也同時(shí)擁有許多K8s集群。我們認(rèn)為，數(shù)以十計(jì)、數(shù)以百計(jì)的K8s集群對(duì)我們的經(jīng)驗(yàn)是個(gè)考驗(yàn)。例如，在基于虛擬機(jī)的數(shù)據(jù)服務(wù)自動(dòng)化中，它們通常有上千臺(tái)虛擬機(jī)運(yùn)行上千個(gè)服務(wù)實(shí)例，這取決于它們?nèi)绾谓M建集群。你可以假設(shè)有一個(gè)服務(wù)實(shí)例對(duì)應(yīng)三個(gè)pod，恰好正在運(yùn)行這樣一個(gè)小集群實(shí)例。在現(xiàn)有這個(gè)規(guī)模上，自動(dòng)化的需求經(jīng)常變更，對(duì)規(guī)模的影響很大。

　　如果你解決了制作“香腸”和分發(fā)“香腸”等簡(jiǎn)單任務(wù)，你可以想象，如果你要服務(wù)更大規(guī)模的用戶，堆棧技術(shù)解決方案要進(jìn)行調(diào)整。數(shù)據(jù)服務(wù)自動(dòng)化也幾乎一樣。因此，如果我們考慮那些大型應(yīng)用場(chǎng)景，擁有很多這樣的服務(wù)實(shí)例，每個(gè)數(shù)據(jù)服務(wù)實(shí)例對(duì)某些用戶都很重要。因此，自動(dòng)化需要符合一定的標(biāo)準(zhǔn)。如果該標(biāo)準(zhǔn)沒(méi)有達(dá)到自動(dòng)化水平，那么自動(dòng)化將用不起來(lái)，組織和技術(shù)的采用就不會(huì)發(fā)生。

　　使用K8s的數(shù)據(jù)服務(wù)

　　那么如何使用K8s的數(shù)據(jù)服務(wù)?首先，你如何實(shí)現(xiàn)一個(gè)Operator，如我認(rèn)為社區(qū)應(yīng)該知道的那樣?最簡(jiǎn)單的方法是使用K8s、CRD和自定義資源定義，傳輸給K8s新的數(shù)據(jù)結(jié)構(gòu)。例如，在描述你的Postgres實(shí)例時(shí)，要?jiǎng)?chuàng)建一個(gè)復(fù)數(shù)的Postgres實(shí)例，因?yàn)槲覀兪前葱枧渲�，有一個(gè)控制器負(fù)責(zé)管理實(shí)例。該控制器將按你指定的對(duì)象的規(guī)范，將其轉(zhuǎn)換為可運(yùn)行的程序。因此，基本上，Operator所做的是將具有Postgres 12.2版本的主對(duì)象(如Postgres實(shí)例)的規(guī)范轉(zhuǎn)換為輔助資源。據(jù)我所知，Operator SDK是構(gòu)建CRD、生成CRD并為控制器提供模板代碼的主流工具。這是討論K8s相關(guān)的數(shù)據(jù)服務(wù)自動(dòng)化時(shí)，我們想到了這兩件事。同時(shí)，還有KUDO。

　　如果你對(duì)此感興趣，我?guī)字芮白隽艘淮窝葜v，DoK社區(qū)會(huì)議關(guān)于數(shù)據(jù)服務(wù)自動(dòng)化的話題非常有趣，今天這里將無(wú)法更深入地討論原型。

　　在開(kāi)發(fā)階段，如果你開(kāi)發(fā)了一個(gè)Operator，挑戰(zhàn)之一是你想如何系統(tǒng)地處理這項(xiàng)工作。有一個(gè)簡(jiǎn)單的模型，我們稱(chēng)之為操作模型，分為四個(gè)級(jí)別，這有助于你處理數(shù)據(jù)服務(wù)自動(dòng)化，這是第一次提出。

　　給一點(diǎn)建設(shè)性的意見(jiàn)，要把你的注意力放在任務(wù)上。例如，我們建議在第一級(jí)實(shí)現(xiàn)Postgres的自動(dòng)化。你需要掌握的第一件事是助理或者DBA要做什么。特別是，這對(duì)應(yīng)用程序開(kāi)發(fā)人員有什么影響?他們到底想要什么?

　　例如，應(yīng)用程序開(kāi)發(fā)人員對(duì)Postgres的平均期望是什么?他們需要自動(dòng)故障轉(zhuǎn)移的集群實(shí)例嗎?在這種情況下，他們更喜歡同步復(fù)制還是異步復(fù)制?你想使用哪種故障轉(zhuǎn)移和集群管理器，還是使用首選倉(cāng)庫(kù)管理器，或者更確切地說(shuō)，使用Prometheus(普羅米修斯)?

　　而且，基本上你要搞清楚如何配置文件，對(duì)Postgres完成基本設(shè)置，這是操作模型一級(jí)。只需假設(shè)你有一臺(tái)虛擬機(jī)，你可以做任何你想做的事情，安裝軟件包，配置數(shù)據(jù)庫(kù)等等。因此，一旦你這樣做了，你知道配置文件應(yīng)該是什么樣子，所有的這些都是Operator可以做到的。你可以考慮容器化，它可以選擇現(xiàn)有的容器映像，并將其組裝到有狀態(tài)集服務(wù)的K8s規(guī)范中，并創(chuàng)建自有的模板，這是操作模型二級(jí)中的YAML部分。因此，在操作模型二級(jí)的最終操作中，無(wú)論你是選擇了現(xiàn)有的容器映像還是自己創(chuàng)建了它們，你都有K8s規(guī)范，可以與kubectl一起使用，以手動(dòng)創(chuàng)建自己的服務(wù)實(shí)例。一旦你這樣做了，你基本上可以創(chuàng)建你的Postgres實(shí)例，比如說(shuō)，用三個(gè)副本和同步流復(fù)制，假定你已經(jīng)知道如何手動(dòng)做到這一點(diǎn)，然后你可以通過(guò)思考問(wèn)題，如何編寫(xiě)gde，創(chuàng)建特定的有狀態(tài)設(shè)置的無(wú)頭服務(wù)來(lái)處理特定的保密數(shù)據(jù)，你可以更容易地實(shí)現(xiàn)這樣的一個(gè)Operator。

　　現(xiàn)在，假設(shè)我們提醒自己，我們正在談?wù)摰沫h(huán)境可能包含1000多個(gè)數(shù)據(jù)服務(wù)實(shí)例，跨越許多K8s集群的多個(gè)數(shù)據(jù)服務(wù)。在這種情況下，我們還需要接受Operator生命周期管理本身是我們工具鏈的重要組成部分。因此，我們還需要自動(dòng)化來(lái)管理Operator本身的生命周期。

　　無(wú)論是Operator生命周期管理器，還是其他技術(shù)在這一點(diǎn)上都無(wú)關(guān)緊要，最重要的是你需要知道，這是你整體數(shù)據(jù)服務(wù)自動(dòng)化挑戰(zhàn)的一部分�，F(xiàn)在，如果你想到K8s Operator，并且提到自定義資源定義，像這樣的YAML結(jié)構(gòu)描述了一種可以傳遞給K8s API的新數(shù)據(jù)類(lèi)型，然后K8s API將向你提供節(jié)點(diǎn)，并持久地將規(guī)范存儲(chǔ)在etcd中。這里格式不是很好。但你可以在這里看到特定資源定義的自定義資源會(huì)是什么樣子，我們教K8s如何創(chuàng)建這樣的對(duì)象。

　　然而，僅憑你的CRD不會(huì)有任何效果，因?yàn)槟阈枰�控制器，控制器通過(guò)代碼實(shí)現(xiàn)事件觀測(cè)，例如創(chuàng)建了一個(gè)對(duì)象。然后，控制器可以確認(rèn)這個(gè)特定的服務(wù)實(shí)例是否已經(jīng)存在，確認(rèn)輔助資源，需要一個(gè)服務(wù)密鑰訪問(wèn)，以及需要?jiǎng)?chuàng)建的有狀態(tài)集。因此，正如我之前所說(shuō)，K8s控制器基本上將主要資源轉(zhuǎn)換為次要資源的組合。在我們的示例中，到目前為止，這些資源一直是K8s的內(nèi)部資源，但實(shí)際情況不一定如此。我們稍后再討論。

　　如果你還想在那里開(kāi)始編寫(xiě)Operator，Operator SDK會(huì)就Operator的成熟度級(jí)別提出建議，Operator分為五個(gè)不同的等級(jí)。我真的不確定你們是否都了解這些等級(jí)的區(qū)別。但如果從現(xiàn)在開(kāi)始，這絕對(duì)是一個(gè)好的開(kāi)端。學(xué)會(huì)正確提問(wèn)，這些問(wèn)題也在文檔中。如果你真的構(gòu)建Operator，你需要用到一些核心功能，例如在沒(méi)有備份的情況下更新補(bǔ)丁，以及備份和恢復(fù)功能。通常這些是必備的，但用戶可能會(huì)拒絕解決方案，或者他們沒(méi)有解決方案。但你知道，你早晚要這么做，因此這會(huì)對(duì)你有所幫助。所以請(qǐng)記住，常見(jiàn)的陷阱，由分布式系統(tǒng)的編程問(wèn)題引起的Bug，會(huì)有很多個(gè)，就看我們排除多少。

　　例如企業(yè)使用Git引發(fā)的問(wèn)題。根據(jù)我的經(jīng)驗(yàn)，總的來(lái)說(shuō)，數(shù)據(jù)服務(wù)自動(dòng)化最有可能的最大問(wèn)題是，人們低估了實(shí)現(xiàn)數(shù)據(jù)服務(wù)自動(dòng)化的復(fù)雜性和所需努力，表現(xiàn)形式包括基本生命周期操作的覆蓋范圍不足，以及魯棒性和可觀察性等質(zhì)量特性較低�；�于這點(diǎn)來(lái)說(shuō)，了解使用的門(mén)檻是有必要的，你需要知道，自動(dòng)化要做什么才能被目標(biāo)受眾接受。雖然這在很大程度上取決于目標(biāo)受眾本身，但現(xiàn)在我可以分享一些我學(xué)到的對(duì)我們大客戶很重要的事情，但說(shuō)不完，因?yàn)楝F(xiàn)在時(shí)間不夠多了，這有點(diǎn)耗時(shí)。

　　接受配置更新很重要，因?yàn)閼?yīng)用程序開(kāi)發(fā)人員能夠通過(guò)自動(dòng)化配置來(lái)使用數(shù)據(jù)庫(kù)和應(yīng)用程序。如果應(yīng)用程序有特殊要求，你需要稍微調(diào)整一下數(shù)據(jù)庫(kù)配置。這是真實(shí)的需求，要盡可能地利用資源。因此，你需要采訪目標(biāo)受眾，并了解這些配置選項(xiàng)是否已經(jīng)在自動(dòng)化文檔中。你需要善于根據(jù)特定需求調(diào)整自動(dòng)化。如果你知道組織內(nèi)有更多的開(kāi)發(fā)人員，所有的云原生需求都在那里，比如，友好的可觀測(cè)性，透明使用基礎(chǔ)設(shè)施。有了K8s，在某種程度上你已經(jīng)獲得了。但在備份的上下文中，當(dāng)你需要將備份存儲(chǔ)在某個(gè)地方時(shí)，你通常必須將備份寫(xiě)入對(duì)象存儲(chǔ)。這就是人們對(duì)S3 API的存在做出假設(shè)的地方，例如，你應(yīng)該選擇一些隱藏底層對(duì)象存儲(chǔ)的抽象庫(kù)。

　　服務(wù)實(shí)例的水平可擴(kuò)展性

　　例如，你需要一個(gè)服務(wù)實(shí)例，你可以考慮單個(gè)Postgres用一個(gè)pod，也可以考慮集群Postgres使用異步流復(fù)制。一旦你想進(jìn)行水平擴(kuò)展，將副本從一個(gè)擴(kuò)展到三個(gè)，就會(huì)在自動(dòng)化中引入許多復(fù)雜性。因?yàn)镻ostgres不是那么簡(jiǎn)單做自動(dòng)化服務(wù)，這讓人喜歡用它舉例。因此，你需要添加一個(gè)集群管理器來(lái)進(jìn)行故障檢測(cè)，你需要有一個(gè)主節(jié)點(diǎn)選舉和主節(jié)點(diǎn)晉升邏輯來(lái)幫助你實(shí)現(xiàn)。

　　此外，如果你恰好有多個(gè)可用區(qū)域的數(shù)據(jù)中心，可以分發(fā)你的pod來(lái)使用它們，這樣不會(huì)出現(xiàn)單個(gè)K8s節(jié)點(diǎn)。只要是可用區(qū)域，并建立了K8s集群，那么幾乎會(huì)100%這樣使用。一般來(lái)說(shuō)，在整個(gè)生命周期中會(huì)重建狀態(tài)集很多次，比如計(jì)劃、切換、升級(jí)，或者垂直擴(kuò)展使pod變大，數(shù)據(jù)被合并。我們將再次討論備份和恢復(fù)的問(wèn)題，這顯然非常重要，因?yàn)閼?yīng)用程序開(kāi)發(fā)人員無(wú)需等待平臺(tái)運(yùn)營(yíng)商的手動(dòng)干預(yù)即可恢復(fù)應(yīng)用程序，這通常是最后的措施。

　　因此，這一切都與按需自助服務(wù)有關(guān)，到目前為止，應(yīng)用程序開(kāi)發(fā)人員可以自助服務(wù)，創(chuàng)建服務(wù)實(shí)例，然后修改它們，重新配置它們，如果服務(wù)實(shí)例碰巧出現(xiàn)異常，或者數(shù)據(jù)被意外刪除，他們需要按應(yīng)用程序的要求恢復(fù)數(shù)據(jù)，防止?jié)撛跀?shù)據(jù)丟失。

　　有一個(gè)需求不太明顯，有時(shí)要提供最新的數(shù)據(jù)服務(wù)版本。假設(shè)Postgres的最新版本是不錯(cuò)的，活躍用戶自然會(huì)喜歡。但對(duì)于某個(gè)組織來(lái)說(shuō)，有些應(yīng)用程序可能處于長(zhǎng)期維護(hù)狀態(tài)，它們不會(huì)立即使用新版本，因此，應(yīng)用程序開(kāi)發(fā)人員需要能夠選擇數(shù)據(jù)服務(wù)版本，可以使用版本號(hào)管理Operator，以支持所有自動(dòng)化版本的啟用和退出。這是你必須為自動(dòng)化制定的政策。如果你提供太多的版本，這也會(huì)給團(tuán)隊(duì)提供很多的支持。但是，文檔也可能會(huì)減少對(duì)你的支持。

　　安全性也很重要，通常要求具備加密存儲(chǔ)、傳輸加密。例如，你希望被加密的磁盤(pán)上的數(shù)據(jù)沒(méi)有被讀取使用，從客戶端發(fā)送到數(shù)據(jù)服務(wù)實(shí)例的數(shù)據(jù)也是如此，有狀態(tài)集中的端口都應(yīng)該加密。

　　服務(wù)綁定

　　請(qǐng)注意，這些服務(wù)實(shí)例不會(huì)很快消失。情況可能如此，但對(duì)于一些使用周期長(zhǎng)的應(yīng)用程序，服務(wù)實(shí)例可能會(huì)存活數(shù)年。如果你考慮生命周期用例和服務(wù)實(shí)例發(fā)生的事情，你將獲得一個(gè)很長(zhǎng)的列表，比這個(gè)列表長(zhǎng)得多。但這給了你對(duì)可能發(fā)生的事情的第一印象，比如縮小規(guī)模和擴(kuò)大規(guī)模。經(jīng)歷各種版本升級(jí)，將應(yīng)用程序綁定到服務(wù)實(shí)例，我在這里稱(chēng)之為服務(wù)綁定。但也處理網(wǎng)絡(luò)分區(qū)以及網(wǎng)絡(luò)帶寬和延遲的波動(dòng)。

　　你必須考慮的所有這些服務(wù)綁定，它們表示應(yīng)用程序與數(shù)據(jù)服務(wù)實(shí)例的連接。例如，對(duì)不同應(yīng)用程序的微服務(wù)，連接到同一個(gè)服務(wù)實(shí)例，最好每個(gè)應(yīng)用程序都可以訪問(wèn)數(shù)據(jù)服務(wù)實(shí)例，比如Postgres有一個(gè)專(zhuān)用的Postgres用戶，這樣密鑰是唯一的。

　　為了這樣的服務(wù)綁定，你必須做兩件事，首先在存儲(chǔ)憑據(jù)區(qū)創(chuàng)建一個(gè)密鑰，然后創(chuàng)建實(shí)際的數(shù)據(jù)服務(wù)用戶。

　　這有一些復(fù)雜性，我們稍后再討論。在我看來(lái)，數(shù)據(jù)服務(wù)自動(dòng)化的一個(gè)類(lèi)似方面應(yīng)該表示為CRD， K8s是備份和備份計(jì)劃。因此，如果你想為特定服務(wù)實(shí)例創(chuàng)建備份，請(qǐng)將其描述為CRD。與作業(yè)和cron作業(yè)類(lèi)似，備份計(jì)劃描述了如何定期創(chuàng)建這些備份。

　　現(xiàn)在，從方法論的角度來(lái)看，數(shù)據(jù)服務(wù)自動(dòng)化有一些原則，如果你堅(jiān)持下去，你可能會(huì)從中受益。因此，在我們回到技術(shù)要點(diǎn)之前，你可能想考慮的原則，正如我們之前所看到的，了解你的受眾，要求和期望的品質(zhì)至關(guān)重要，你需要了解你是否做了一些事情，比如團(tuán)隊(duì)是否高度依賴(lài)特定數(shù)據(jù)源。

　　我見(jiàn)過(guò)整個(gè)公司圍繞單個(gè)MongoDB實(shí)例或其中幾個(gè)實(shí)例發(fā)展的公司。因此，為該案例構(gòu)建Operator將與我之前介紹的上下文不同。因此，請(qǐng)注意，上下文是良好的數(shù)據(jù)服務(wù)自動(dòng)化的核心要素之一。明智地選擇數(shù)據(jù)服務(wù)也是一件好事。正如我之前提到的，比如自動(dòng)化Postgres，你需要做許多工作。對(duì)于其他數(shù)據(jù)服務(wù)，你可能會(huì)遇到許可證問(wèn)題，因?yàn)樗鼈冇袝r(shí)會(huì)更改許可證，有些甚至?xí)�遠(yuǎn)離開(kāi)源，你也必須處理好這一點(diǎn)。因此，通常情況下，一個(gè)具有開(kāi)源許可證的單一供應(yīng)商支持的數(shù)據(jù)服務(wù)，例如，你按需配置，每當(dāng)你更改有工具集時(shí)，都很可能會(huì)重新創(chuàng)建。因此，這就是通過(guò)重建失敗的實(shí)例而不是修復(fù)它們來(lái)解決的問(wèn)題。

　　你可以將已知狀態(tài)的重建用作幫助你解決問(wèn)題的工具，在某些情況下，首先使用操作模型是我之前解釋的，在開(kāi)始自動(dòng)化工作前先了解數(shù)據(jù)服務(wù)，成為備份和恢復(fù)的救火員是必要和重要的，因?yàn)檫@是運(yùn)維電話、平臺(tái)運(yùn)營(yíng)商電話鈴響起之前的最后手段，這可以避免。

　　因此，如果你碰巧自動(dòng)化了多個(gè)數(shù)據(jù)服務(wù)，它們之間有很多協(xié)同關(guān)聯(lián)。這應(yīng)該納入同一個(gè)框架。這個(gè)框架可能有代碼庫(kù)可以在控制器之間共享，但也可能在容器映像擁有的腳本，或者類(lèi)似測(cè)試之類(lèi)的配置都很重要，因?yàn)橛辛俗詣?dòng)化，你基本上會(huì)寫(xiě)一些代碼，代碼將分發(fā)到許多環(huán)境，從這些環(huán)境中，你將創(chuàng)建許多服務(wù)實(shí)例。

　　對(duì)代碼以及生成的服務(wù)實(shí)例都有良好的測(cè)試覆蓋率，并通過(guò)集成測(cè)試指導(dǎo)他們完成用例，無(wú)論你怎么稱(chēng)呼它，都非常有趣。我的建議也有測(cè)試用例，對(duì)于那些場(chǎng)景，如果你知道你的自動(dòng)化仍然存在弱點(diǎn)，請(qǐng)與你的客戶分享測(cè)試案例的測(cè)試庫(kù)，并告訴他們并允許他們?cè)诒镜丨h(huán)境中運(yùn)行這些測(cè)試。因?yàn)檫@會(huì)產(chǎn)生信任。而且，這也讓他們有機(jī)會(huì)更好地了解他們可以監(jiān)控哪些情況，以避免遇到問(wèn)題。

　　不要修補(bǔ)上游源代碼是我們使用的原則，因?yàn)槲覀冇羞@么多不同的數(shù)據(jù)服務(wù)，我們做分叉，并允許拉取請(qǐng)求、熱修復(fù)和臨時(shí)熱修復(fù)。主發(fā)布管理意味著從Postgres發(fā)布之日起到你的自動(dòng)化發(fā)布當(dāng)天，延遲應(yīng)該很短。一旦你啟用了自動(dòng)化，你希望將該版本快速交付到目標(biāo)環(huán)境中，因?yàn)橹挥羞@樣，應(yīng)用程序開(kāi)發(fā)人員才能升級(jí)他們的實(shí)例。

　　示例

　　關(guān)于技術(shù)的話不多說(shuō)了，因?yàn)闀r(shí)間不多了。在編寫(xiě)控制器時(shí)，如果你是第一次調(diào)用外部資源，這會(huì)有點(diǎn)棘手。在服務(wù)綁定示例中，你需要?jiǎng)?chuàng)建一個(gè)密鑰，同時(shí)也需要?jiǎng)?chuàng)建一個(gè)Postgres數(shù)據(jù)庫(kù)用戶。

　　現(xiàn)在，有幾種方法可以做到這一點(diǎn)。但總的來(lái)說(shuō)，挑戰(zhàn)在于，你如何確保這兩種資源的一致性?答案是采用兩級(jí)方法，例如，你也可以將Postgres用戶表示為自定義資源，并為此有一個(gè)控制器，設(shè)置控制器只有一個(gè)目的，即協(xié)調(diào)這些Postgres用戶，這使他們?cè)谀銊?chuàng)建密鑰時(shí)降低了服務(wù)綁定控制器的復(fù)雜性，該密鑰是K8s和Postgres用戶已經(jīng)知道的次要資源。如果你已經(jīng)擁有它，作為CRD，也是你的K8s集群已知的資源。作為要點(diǎn)之一，沒(méi)有原子性保證，這里沒(méi)有事務(wù)。因此，使用聲明性方法更貼近習(xí)慣，在K8s中，允許數(shù)據(jù)狀態(tài)不一致，因?yàn)槟阕罱K與K8s保持一致。它應(yīng)該能夠被周知，如果Postgres用戶無(wú)法創(chuàng)建，我們將嘗試進(jìn)行協(xié)調(diào)。

　　保持操作的冪等性，這樣如果循環(huán)再次調(diào)用相同規(guī)格的服務(wù)，應(yīng)該是可能的，這樣你就不會(huì)卡住，也不會(huì)在這里進(jìn)入錯(cuò)誤狀態(tài)。因此，與其創(chuàng)建用戶，創(chuàng)建不存在的用戶，我們可以做得更多。上例只是一個(gè)值得思考的簡(jiǎn)單例子。

　　最后要分享一件事，緩存。如果你修改控制器中的資源，基本上是在使用K8s API對(duì)其進(jìn)行修改，你的本地緩存可能不會(huì)直接和立即反映更改，這有時(shí)可能導(dǎo)致奇怪的行為。因此，請(qǐng)注意，本地緩存的更新與K8s API中對(duì)象的更新之間可能存在滯后，特別是與具有層次結(jié)構(gòu)的控制器打交道。

　　總結(jié)一下，這次演講的技術(shù)部分有點(diǎn)簡(jiǎn)短，我們圍繞數(shù)據(jù)服務(wù)自動(dòng)化的一般挑戰(zhàn)以及了解目標(biāo)受眾的重要性進(jìn)行了大量討論。以及上下文如何影響你在編寫(xiě)特定Operator時(shí)的任務(wù)。我提出了一些通常要求的想法。也許這是一個(gè)好的開(kāi)始，如果你寫(xiě)自己的Operator，問(wèn)問(wèn)自己，這是不是我們的應(yīng)用程序開(kāi)發(fā)人員所需要的?如果不是，就和他們談?wù)�，試著了解他們的想法。然后，試著邁出第一步。

　　譯者介紹

　　張業(yè)貴，51CTO社區(qū)編輯，從事企業(yè)信息化建設(shè)多年，致力于信息集成、數(shù)據(jù)治理和人工智能應(yīng)用等。