譯者 | 康少京

策劃 | 云昭

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

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

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

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

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

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

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

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

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

常見障礙

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

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

您可能遇到的第一個障礙涉及基本網(wǎng)絡(luò)?；氐轿覀兊牡谝粋€集群，讓我們看一下所涉及的網(wǎng)絡(luò)層。

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

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

在我們的例子中，有 10.100.x.x 用于節(jié)點，10.200.x.x 用于 K8s 級別。 每個K8s工作者都會獲得10.200.x.x 的一部分，在該單個實例上運行Pod 的CIDR范圍。

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

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

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

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

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

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

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

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

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

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

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

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

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

要考慮的一些解決方案

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

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

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

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

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

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

DNS 存根

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

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

托管 DNS

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

消除管理集群托管 DNS 服務(wù)器的開銷——云 DNS 不需要擴展、監(jiān)控或管理 DNS 實例，因為它是托管的 Google 服務(wù)。

每個Google K8s引擎（GKE）節(jié)點上DNS查詢的本地解析——與NodeLocal DNSCache類似，云DNS將DNS響應(yīng)存到本地，提供低延遲和高可擴展性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)控和安全補丁，以及您期望從托管產(chǎn)品中獲得的所有其他方面。 對于一些提供商來說，GKE還提供了一個節(jié)點本地 DNS 緩存，它通過在較低級別運行 DNS 緩存來減少延遲，這樣您就不用等待 DNS 響應(yīng)。

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

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

譯者介紹

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

原文標題：Taking Your Database Beyond a Single Kubernetes Cluster，作者：Christopher Bradford

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