譯者 | 康少京

策劃 | 云昭

在眾多NoSQL存儲(chǔ)中，Cassandra 是廣受企業(yè)和開發(fā)者歡迎的選擇之一。它使用AmazonDynamo引入的架構(gòu)方面的特性來支持Big Table 數(shù)據(jù)模型，優(yōu)勢(shì)非常明顯:高度可擴(kuò)展性和高度可用性、沒有單點(diǎn)故障 NoSQL 列族實(shí)現(xiàn)、非常高的寫入吞吐量和良好的讀取吞吐量、二級(jí)索引支持搜索可調(diào)節(jié)的一致性和對(duì)復(fù)制的支持靈活的模式等。除此之外，它還實(shí)現(xiàn)了一個(gè)非常棘手的 Kubernetes 集群中運(yùn)行數(shù)據(jù)庫(kù)（或其他應(yīng)用程序）的難題，這里供大家參考。  全球應(yīng)用程序需要一個(gè)與它們服務(wù)的用戶一樣分布式的數(shù)據(jù)層，Apache Cassandra已經(jīng)很好的做到了這一點(diǎn)，目前為蘋果、Netflix和索尼等公司處理數(shù)據(jù)需求。傳統(tǒng)上，分布式應(yīng)用程序的數(shù)據(jù)層管理，由專門的團(tuán)隊(duì)來管理數(shù)千個(gè)節(jié)點(diǎn)的部署和操作（包括本地節(jié)點(diǎn)和云中的節(jié)點(diǎn)）。

為了減輕DevOps團(tuán)隊(duì)的大部分負(fù)擔(dān)，我們利用Kubernetes（K8s）提供的公共控制區(qū)域，在K8ssandra中開發(fā)了許多這樣的實(shí)踐和模式。不過，有一個(gè)問題是，如果沒有適當(dāng)?shù)淖⒁夂皖A(yù)先規(guī)劃，跨多個(gè)區(qū)域或K8s集群運(yùn)行數(shù)據(jù)庫(kù)（或任何應(yīng)用程序）是很棘手的。

在這里向您展示下是如何做到這一點(diǎn)的，我們先看看在一個(gè)單獨(dú)的K8s集群上運(yùn)行的單個(gè)區(qū)域K8ssandra部署。它是由六個(gè)Cassandra節(jié)點(diǎn)組成，分布在該區(qū)域內(nèi)的三個(gè)可用性區(qū)域中，每個(gè)可用性區(qū)域中有兩個(gè)Cassandra節(jié)點(diǎn)。在本例中，我們將使用谷歌云平臺(tái)（GCP）區(qū)域名稱。然而，這里的例子同樣適用于其他云，甚至是在線云。

這就是我們現(xiàn)在的處境：

云數(shù)據(jù)庫(kù)的現(xiàn)有部署

目標(biāo)是建立兩個(gè)區(qū)域，每個(gè)區(qū)域都有一個(gè) Cassandra 數(shù)據(jù)中心。 在我們這里的云管理 K8s 部署中，這就轉(zhuǎn)化為兩個(gè)K8s集群——每個(gè)集群都有一個(gè)單獨(dú)的控制平面，但使用一個(gè)公共的虛擬私有云 (VPC) 網(wǎng)絡(luò)。 通過 Cassandra 集群擴(kuò)展到多個(gè)數(shù)據(jù)中心，我們可以在區(qū)域中斷的情況下獲得冗余，并且在本地訪問數(shù)據(jù)的情況下改善客戶端應(yīng)用程序的響應(yīng)時(shí)間和延遲。

這就是我們的目標(biāo)：擁有兩個(gè)區(qū)域，每個(gè)區(qū)域都有自己的 Cassandra 數(shù)據(jù)中心。

表面上看，我們似乎可以通過簡(jiǎn)單地啟動(dòng)另一個(gè)部署相同 K8s YAML 的 K8s 集群來實(shí)現(xiàn)這一點(diǎn)。然后對(duì)可用區(qū)名稱添加一些調(diào)整，我們就可以完成了，對(duì)吧？最終，這些資源的形狀非常相似，都是 K8s 對(duì)象。那么，這不應(yīng)該有效嗎？也許。根據(jù)您的環(huán)境，這種方法可能會(huì)起作用。

如果沒有使用完全分布式數(shù)據(jù)庫(kù)部署，會(huì)避免很多問題。但不幸的是，事情很少那么簡(jiǎn)單。即使其中一些障礙很容易清除，還有許多其他無害的事情可能會(huì)出錯(cuò)并導(dǎo)致降級(jí)狀態(tài)。您選擇的云提供商、K8s 發(fā)行版、命令行標(biāo)志，是的，甚至是 DNS——這些都可能導(dǎo)致您進(jìn)入一條黑暗深淵。所以，我們來探討一些可能遇到的最常見問題來避免這種情況。

常見障礙

即使您的某些部署一開始起來運(yùn)行得很好，但當(dāng)您發(fā)展到多云環(huán)境、升級(jí)到另一個(gè) K8s 版本或開始使用不同的發(fā)行版和免費(fèi)工具時(shí)，您可能會(huì)遇到一兩個(gè)障礙。當(dāng)涉及到分布式數(shù)據(jù)庫(kù)時(shí)，它有更多的底層功能。了解 K8s是如何在一系列硬件中運(yùn)行容器的，將有助于開發(fā)高級(jí)解決方案--最終它將滿足您的確切需求。

Cassandra 節(jié)點(diǎn)需要唯一 IP 地址

您可能遇到的第一個(gè)障礙涉及基本網(wǎng)絡(luò)。回到我們的第一個(gè)集群，讓我們看一下所涉及的網(wǎng)絡(luò)層。

在下面顯示的 VPC 中，我們有一個(gè)無分類域間路由 (CIDR) 范圍，代表 K8s工作實(shí)例的地址。在 K8s 集群范圍內(nèi)，有一個(gè)單獨(dú)的地址空間，用于操作 pods 和容器運(yùn)行。Pod 是共享了某些資源的容器集合，例如存儲(chǔ)、網(wǎng)絡(luò)和進(jìn)程空間。  在某些云環(huán)境中，這些子網(wǎng)被綁定到特定的可用區(qū)域。因此，K8s工作器所啟動(dòng)的每個(gè)子網(wǎng)可能都有一個(gè)CIDR范圍。 VPC 中可能還有其他虛擬機(jī)，但在本例中，我們將堅(jiān)持使用 K8s 作為唯一租戶。

具有K8s層的VPC使用的CIDR范圍

在我們的例子中，有 10.100.x.x 用于節(jié)點(diǎn)，10.200.x.x 用于 K8s 級(jí)別。 每個(gè)K8s工作者都會(huì)獲得10.200.x.x 的一部分，在該單個(gè)實(shí)例上運(yùn)行Pod 的CIDR范圍。

回想一下我們的目標(biāo)結(jié)構(gòu)，如果兩個(gè)集群使用相同或重疊的CIDR地址范圍會(huì)發(fā)生什么？ 當(dāng)你第一次接觸網(wǎng)絡(luò)時(shí)，您可能還記得這些錯(cuò)誤信息：

嘗試連接兩個(gè)網(wǎng)絡(luò)時(shí)的常見錯(cuò)誤消息

K8s 的錯(cuò)誤看起來不像這樣。不會(huì)彈出集群無法有效溝通的警告。

如果您有一個(gè)具有 IP 空間的集群，而另一個(gè)集群有相同的IP空間或重疊的位置，那么每個(gè)集群如何知道特定數(shù)據(jù)包何時(shí)需要離開自己的地址空間，并且通過 VPC 網(wǎng)絡(luò)路由到另一個(gè)集群，然后進(jìn)入該集群的網(wǎng)絡(luò)？

正常情況下，這里沒有任何提示。有一些方法可以解決這個(gè)問題；但從更高的層面來看，如果你有重疊，那就是自找麻煩。這里的重點(diǎn)是，您需要了解每個(gè)集群的地址空間，然后仔細(xì)規(guī)劃這些 IP 的分配和使用。這允許 Linux 內(nèi)核（K8s 路由發(fā)生的地方）和 VPC 網(wǎng)絡(luò)層根據(jù)需要轉(zhuǎn)發(fā)和路由數(shù)據(jù)包。

但是，如果您沒有足夠的 IP怎么辦？在某些情況下，您不能給每 pod提供自己的 IP 地址。因此，在這種情況下，您需要退后一步，確定哪些服務(wù)絕對(duì)必須具有唯一地址，以及哪些服務(wù)可以在同一地址空間中一起運(yùn)行。例如，如果您的數(shù)據(jù)庫(kù)需要能夠與每個(gè)其他pod通信，那么它可能需要自己的唯一地址。但是，如果在東海岸和西海岸的應(yīng)用程序?qū)又皇桥c他們的本地?cái)?shù)據(jù)層通信，它們可以擁有自己的專用 K8s 集群，地址范圍相同，避免沖突。

扁平化網(wǎng)絡(luò)

在我們的參考部署中，我們將 K8s 集群中的非重疊范圍專用于基礎(chǔ)設(shè)施層，這些基礎(chǔ)設(shè)施必須是唯一的，并且服務(wù)不會(huì)通信的重疊 CIDR 范圍。最終，我們?cè)谶@里所做的是扁平化網(wǎng)絡(luò)。

有了不重疊的 IP 范圍，現(xiàn)在可以繼續(xù)將數(shù)據(jù)包路由到每個(gè)集群中的 pod。在上圖中，您可以看到西海岸為 10.100，東海岸為 10.150，K8s pod 接收來自這些范圍的 IP。K8s 集群有自己的 IP 空間，200 對(duì) 250，并且 pod 像以前一樣被分割。

如何處理 Cassandra 數(shù)據(jù)中心之間的路由

我們有一堆 IP 地址，并且我們對(duì)這些地址具有唯一性。現(xiàn)在，我們?nèi)绾翁幚磉@些數(shù)據(jù)的路由以及所有這些的通信和發(fā)現(xiàn)？發(fā)往集群 A 的數(shù)據(jù)包無法知道它們需要如何路由到集群 B。當(dāng)我們嘗試跨集群邊界發(fā)送數(shù)據(jù)包時(shí)，本地Linux網(wǎng)絡(luò)堆棧會(huì)發(fā)現(xiàn)這不是該主機(jī)或本地K8s群集內(nèi)的任何主機(jī)的本地?cái)?shù)據(jù)包，然后將數(shù)據(jù)包轉(zhuǎn)發(fā)到 VPC 網(wǎng)絡(luò)。從這里開始，我們的云提供商必須有一個(gè)路由表?xiàng)l目來了解這個(gè)數(shù)據(jù)包需要去哪里。

在某些情況下，這是開箱即用。 VPC 路由表使用 pod 和服務(wù) CIDR 范圍進(jìn)行更新，告知應(yīng)路由哪些主機(jī)數(shù)據(jù)包。在其他環(huán)境中，包括混合環(huán)境和本地環(huán)境，這可能采取通過 BGP向網(wǎng)絡(luò)層通告路由的形式。雅虎！日本有一篇很棒的文章介紹了這種確切的部署方法。

但是，這些選項(xiàng)可能并不總是最好的答案，這取決于您的多集群架構(gòu)在單個(gè)云提供商中的樣子。它是混合云還是多云，結(jié)合了本地和兩個(gè)不同的云提供商？雖然您當(dāng)然可以在所有這些不同的環(huán)境中檢測(cè)這些，但您可以指望它需要大量的時(shí)間和維護(hù)。

要考慮的一些解決方案

覆蓋網(wǎng)絡(luò)

一個(gè)更簡(jiǎn)單的答案是使用覆蓋網(wǎng)絡(luò)，在其中為您的應(yīng)用程序構(gòu)建一個(gè)單獨(dú)的 IP 地址空間——在這種情況下，它是一個(gè) Cassandra 數(shù)據(jù)庫(kù)。然后，您可以利用代理、 sidecars和網(wǎng)關(guān)在現(xiàn)有的Kube網(wǎng)絡(luò)上運(yùn)行它。在這篇文章中，我們不會(huì)深入探討這一點(diǎn)，但我們有一些關(guān)于如何跨 K8s 集群連接有狀態(tài)工作負(fù)載的很棒的內(nèi)容，這些內(nèi)容將向您展示如何從高層次上做到這一點(diǎn)。

所以，接下來是什么？數(shù)據(jù)包在流動(dòng)，但現(xiàn)在有一些新的 K8s詭計(jì)要處理。假設(shè)您已經(jīng)準(zhǔn)備好了網(wǎng)絡(luò)并擁有了所有適當(dāng)?shù)穆酚桑敲催@些集群之間至少在 IP層存在一些連接。您擁有 IP 連接 Pod，并且Cluster 1 可以與 Pods 和Cluster 2 通信，但您現(xiàn)在還需要考慮一些新的事情。  

服務(wù)發(fā)現(xiàn)

在K8s 網(wǎng)絡(luò)中，身份是暫時(shí)的。由于集群事件，Pod可能被重新安排并接收新的網(wǎng)絡(luò)地址。在某些應(yīng)用中，這不是問題。在其他情況下，比如數(shù)據(jù)庫(kù)，網(wǎng)絡(luò)地址就是身份——這可能導(dǎo)致意外行為。盡管 IP 地址可能會(huì)發(fā)生變化，但隨著時(shí)間的推移，我們的存儲(chǔ)以及每個(gè) pod 所代表的數(shù)據(jù)都會(huì)保持不變。我們必須有一種方法來維護(hù)地址到應(yīng)用程序的映射。這就是服務(wù)發(fā)現(xiàn)的切入點(diǎn)。

在大多數(shù)情況下，服務(wù)發(fā)現(xiàn)是在 K8s內(nèi)通過DNS 實(shí)現(xiàn)的。即使 pod 的 IP 地址可能發(fā)生變化，它也可以具有基于 DNS 的持久身份，該身份會(huì)在集群時(shí)間發(fā)生時(shí)被更新。這聽起來很不錯(cuò)，但是當(dāng)我們進(jìn)入多集群的世界時(shí)，我們必須確保我們的服務(wù)可以跨集群邊界被發(fā)現(xiàn)。作為Cluster  1 中的 pod，我應(yīng)該能夠獲取Cluster  2 中的 pod 的地址。

DNS 存根

解決這個(gè)難題的一種方法是 DNS 存根。在這個(gè)配置中，我們配置 K8s DNS 服務(wù)，將特定域后綴的請(qǐng)求路由到遠(yuǎn)程集群。有了完全限定的域名，我們就可以將 DNS 查找請(qǐng)求轉(zhuǎn)發(fā)到適當(dāng)?shù)募哼M(jìn)行解析并最終路由。

這里的問題是，每個(gè)集群都需要通過 kubelet 標(biāo)志設(shè)置單獨(dú)的 DNS 后綴，這在所有 K8s 中都不是一個(gè)選項(xiàng)。一些用戶通過使用命名空間名稱作為 FQDN 的一部分來配置存根解決此問題。這是可行的，但有點(diǎn)像黑客，不是正確設(shè)置集群后綴。

托管 DNS

另一種類似于 DNS 存根的解決方案是使用托管 DNS 產(chǎn)品。 在 GCP 的情況下，有  Cloud DNS 產(chǎn)品，可以將本地 DNS 表項(xiàng)復(fù)制到 VPC 級(jí)別，供外部集群甚至同一 VPC 內(nèi)的虛擬機(jī)進(jìn)行解析。 此選項(xiàng)提供了很多好處，包括：

消除管理集群托管 DNS 服務(wù)器的開銷——云 DNS 不需要擴(kuò)展、監(jiān)控或管理 DNS 實(shí)例，因?yàn)樗峭泄艿?Google 服務(wù)。

每個(gè)Google K8s引擎（GKE）節(jié)點(diǎn)上DNS查詢的本地解析——與NodeLocal DNSCache類似，云DNS將DNS響應(yīng)存到本地，提供低延遲和高可擴(kuò)展性DNS解析。

與 Google Cloud 的操作套件集成——提供了 DNS 監(jiān)控和日志記錄。

VPC 范圍DNS——提供多集群、多環(huán)境和 VPC 范圍的 K8s 業(yè)務(wù)解析。

用于多集群服務(wù)發(fā)現(xiàn)的復(fù)制托管 DNS

Cloud DNS 抽象了許多傳統(tǒng)的開銷。 云提供商將管理伸縮性、監(jiān)控和安全補(bǔ)丁，以及您期望從托管產(chǎn)品中獲得的所有其他方面。 對(duì)于一些提供商來說，GKE還提供了一個(gè)節(jié)點(diǎn)本地 DNS 緩存，它通過在較低級(jí)別運(yùn)行 DNS 緩存來減少延遲，這樣您就不用等待 DNS 響應(yīng)。

從長(zhǎng)遠(yuǎn)來看，如果您只在單個(gè)云中，專門用于DNS的托管服務(wù)將可以正常工作。 但是，如果您跨越多個(gè)云提供商和本地環(huán)境的集群，托管產(chǎn)品可能只是解決方案的一部分。

云本地計(jì)算基金會(huì)https://www.cncf.io/(CNCF) 提供了多種選擇，并且有大量開源項(xiàng)目缺思在幫助緩解這些痛點(diǎn)方面取得了很大的發(fā)展，尤其是在跨云、多云、 或混合云類型的場(chǎng)景。

譯者介紹

康少京，51CTO社區(qū)編輯，目前從事通訊類行業(yè)，底層驅(qū)動(dòng)開發(fā)崗位，研究過數(shù)據(jù)結(jié)構(gòu)，Python，現(xiàn)對(duì)操作系統(tǒng)和數(shù)據(jù)庫(kù)等相關(guān)領(lǐng)域感興趣。  

原文標(biāo)題：Taking Your Database Beyond a Single Kubernetes Cluster，作者：Christopher Bradford

鏈接：https://dzone.com/articles/taking-your-database-beyond-a-single-kubernetes-cl