共計 3001 個字符，預計需要花費 8 分鐘才能閱讀完成。
這篇文章給大家介紹怎么在 Docker 和 Kubernetes 上運行 MongoDB 微服務，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
想嘗試在筆記本電腦上運行 MongoDB 么? 希望通過執行一個簡單的命令，然后就有一個輕量級、自組織的沙盒么? 并可再通過一條命令就可以移除所有的痕跡么?
需要在多個環境中運行相同的應用程序棧? 創建自己的容器鏡像，使得開發、測試、操作和支持團隊啟動一份完全相同的環境。
容器正在改變整個軟件生命周期; 它覆蓋了從最初的技術試驗到通過開發、測試、部署和支持的概念證明。
閱讀微服務：容器和編排白皮書(https://www.mongodb.com/collateral/microservices-containers-and-orchestration-explained)。
編排工具管理著多個容器如何創建、升級和高可用。編排同樣管理著容器如何連接，并利用多個微服務容器創建穩定的應用服務。
豐富的功能、簡單的工具、強大的 API 讓容器和編排得到 DevOps 團隊的青睞。DevOps 工程師將它們整合到持續集成 (CI) 和持續交付 (CD) 工作流中。
將探索在嘗試運行和編排 MongoDB 容器時遇到的問題，并描述如何克服這些問題。
對于 MongoDB 的思考
采用容器和編排運行 MongoDB 帶來了一些新的思考：
MongoDB 數據庫節點是有狀態的。若一個容器掛了，并且被重新編排，數據丟失是不能接受的 (雖然它可以從其他節點中恢復數據，但是很費時)。為解決這個問題，Kubernetes 中的卷抽象(Volume abstraction) 特性將用于映射 MongoDB 數據文件夾到一個持久化地址，避免容器的失敗或重編排。
同一組 MongoDB 數據庫備份節點之間需要通信，即使是在重編排之后。同一冗余備份集合的節點必須知道全部其他節點的地址，但是當某個容器重編排之后，它的 IP 地址會變化。例如，所有 Kubernetes 內的容器共享一個 IP 地址，當 pod 被重編排之后這個地址就會改變。在 Kubernetes 中，這個問題可以通過聯系 Kubernetes 服務與 MongoDB 節點來解決，采用 Kubernetes 的 DNS 服務提供主機名給重編排之后的服務。
一旦每個獨立的 MongoDB 節點 (每個節點在單獨容器中) 啟動起來，備份集合必須初始化，并把每個節點加入進來。這需要編排工具提供額外的邏輯。特別是備份集合中只有一個 MongoDB 節點時，必須執行 rs.initiate 和 rs.add 命令。
如果編排框架提供自動化重編排容器功能(如 Kubernetes 的特性)，那么這可以提高 MongoDB 的容災性，節點會在掛掉之后自動重新創建，恢復到完整冗余水平且不需要人工干預。
當編排框架掌控所有容器的狀態時，它并不管理容器內的應用或者備份數據。這就意味著采用一個有效的管理和備份方案很重要，如 MongoDB Cloud Manager，包括 MongoDB Enterprise Advanced 和 MongoDB Professional 兩部分。考慮到需要創建鏡像，可采用你傾向的 MongoDB 版本和 MongoDB Automation Agent。
利用 Docker 和 Kubernetes 實現 MongoDB 冗余備份
如前一節所述，MongoDB 這類分布式數據庫在利用編排框架 (如 Kubernetes) 進行部署時需要額外考慮。本節將對這部分細節進行分析，并介紹如何實現。
首先，我們在一個單獨的 Kubernetes 集群 (同一個數據中心內，并不存在物理上的冗余備份) 中創建整個 MongoDB 冗余集合。如果跨多個數據中心進行創建，其步驟也差異不大，后續將會介紹。
備份中的每個成員都運行在獨自的 pod 中，只暴露其 IP 地址和端口。固定的 IP 地址對于外部應用和其他冗余備份節點非常重要，它決定了哪些 pod 將被重新部署。
下圖展示了其中一個 pod 與關聯的冗余控制器和服務的關系。
深入這些配置中描述的資源，內容如下：
啟動核心節點 mongo-node1。該節點包括了一個叫做的 mongo 的鏡像，來源于 Docker Hub(https://hub.docker.com/_/mongo/)，其暴露 27107 端口。
Kubernetes 的卷特性用于映射 /data/db 文件夾到持久化目錄 mongo-persistent-storage1; 該目錄為 Google Cloud 上創建的目錄映射 mongodb-disk1，用于持久化 MongoDB 的數據。
容器由 pod 進行管理，標記為 mongo-node，同時對 rod 提供一個隨機生成的名字。
冗余控制器命名為 mongo-rc1，用于確保 mongo-node1 的實例一直處于運行中。
負載均衡服務命名為 mongo-svc- a 用 27017 暴露端口。該服務通過 pod 的標簽匹配正確的服務到對應的 pod 上，對外暴露的 ip 和端口給應用程序使用，同時用于冗余備份集合中各節點的通信。雖然每個容器擁有內部 ip，但是當容器被重啟或者移動之后它們會變更，因此不能用于冗余備份集合之間的通信。
下圖展示了冗余備份及中的另一個成員信息：
90% 的配置是相同的，只有幾處不同：
硬盤和卷的名字必須是 *** 的，于是采用 mongodb-disk2 和 mongo-persisitent-storage2
Pod 分配到 jane 實例，同時節點命名為 mongo-node2，用于區分新服務與圖 1 中的 Pod
冗余控制命名為 mongo-rc2
服務命名為 mongo-svc-b，并獲取一個不同的外部 IP 地址(本例子中，Kubernets 分配為 104.1.4.5)
第三個冗余備份成員的配置仿照上述的模式進行，下圖展示了完整的冗余配置集合：
注意，即使配置如圖 3 一樣，在一個三個或者多個節點的 Kubernetes 集群上，Kubernetes 可能會調度兩個或者多個 MongoDB 冗余備份成員在同一個宿主機上。這是因為 Kubernetes 將三個 pod 視為三個獨立的服務。
為了增加冗余，需要創建一個額外的 headless 服務。該服務不具備提供外部服務的能力，甚至沒有外部 IP 地址，但是它用于通知 Kubernetes 這三個 MongoDB Pod 是屬于同一個服務，于是 Kubernetes 會將它們調度在不同的節點上。
具體的配置文件和相關操作命令可以從《啟動微服務：容器 調度說明白皮書》中找到。其中包含了三個特殊的步驟確保合并三個 MongoDB 到一個功能中，即本文中描述的冗余備份。
多個可用區域 MongoDB 冗余集合
所有冗余部件均運行在同一個 GCE 集群上時具有很高的風險，在同一個 zone 的集群也一樣。如果發生一個重大事件導致可用 zone 離線，那么 MongoDB 冗余集合也就不可用。如果需要地理上的冗余備份，那么三個 pod 需要運行在不同的 zone 內。
只需要很少的改動就可以創建這樣一個冗余備份集合。每一個集群需要獨自的 Kubernetes YAML 文件來定義 pod、冗余控制器和服務。然后，就可以完成一個 zone 的集群創建、持久化存儲和 MongoDB 節點。
下圖展示了運行在不同 zone 上的冗余結合：
關于怎么在 Docker 和 Kubernetes 上運行 MongoDB 微服務就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
