负载均衡服务命名为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上的冗余结合：
