如前一節所述，MongoDB這類分布式數據庫在利用編排框架(如Kubernetes)進行部署時需要額外考慮。本節將對這部分細節進行分析，並介紹如何實現。

首先，我們在一個單獨的Kubernetes集群(同一個數據中心內，並不存在物理上的冗余備份)中創建整個MongoDB冗余集合。如果跨多個數據中心進行創建，其步驟也差異不大，後續將會介紹。
備份中的每個成員都運行在獨自的pod中，只暴露其IP地址和端口。固定的IP地址對於外部應用和其他冗余備份節點非常重要，它決定了哪些pod將被重新部署。

下圖展示了其中一個pod與關聯的冗余控制器和服務的關系。

深入這些配置中描述的資源，內容如下：

啟動核心節點mongo-node1，該節點包括了一個叫做的mongo的鏡像，來源於Docker Hub，其暴露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到一個功能中，即本文中描述的冗余備份。