mongodb服务配置
1、如上节所述，分布式数据库（如 MongoDB）在使用编排框架（如 Kubernetes）进行部署时，需要稍加注意。本节将介绍详细介绍如何实现。
2、我们首先在单个 Kubernetes 集群中创建整个 MongoDB 副本集（通常在一个数据中心内，这显然不能提供地理冗余）。实际上，很少有必要改变成跨多个集群运行，这些步骤将在后面描述。
3、副本集的每个成员将作为自己的 pod 运行，并提供一个公开 IP 地址和端口的服务。这个“固定”的 IP 地址非常重要，因为外部应用程序和其他副本集成员都可以依赖于它在重新编排 pod 的情况下保持不变。
4、下图说明了其中一个 pod 以及相关的复制控制器和服务。
5、逐步介绍该配置中描述的资源：
从核心开始，有一个名为 mongo-node1 的容器。mongo-node1 包含一个名为 mongo 的镜像，这是一个在 Docker Hub 上托管的一个公开可用的 MongoDB 容器镜像。容器在集群中暴露端口 27107。Kubernetes 的数据卷功能用于将连接器中的 /data/db 目录映射到名为 mongo-persistent-storage1 的永久存储上，这又被映射到在 Google Cloud 中创建的名为 mongodb-disk1 的磁盘中。这是 MongoDB 存储其数据的地方，这样它可以在容器重新编排后保留。
6、容器保存在一个 pod 中，该 pod 中有标签命名为 mongo-node，并提供一个名为 rod 的（任意）示例。配置 mongo-node1 复制控制器以确保 mongo-node1 pod 的单个实例始终运行。名为 mongo-svc-a 的 负载均衡 服务给外部开放了一个 IP 地址以及 27017 端口，它被映射到容器相同的端口号上。该服务使用选择器来匹配 pod 标签来确定正确的 pod。外部 IP 地址和端口将用于应用程序以及副本集成员之间的通信。每个容器也有本地 IP 地址，但是当容器移动或重新启动时，这些 IP 地址会变化，因此不会用于副本集。
7、下一个图显示了副本集的第二个成员的配置。
8、 的配置是一样的，只有这些变化：
磁盘和卷名必须是唯一的，因此使用的是 mongodb-disk2 和 mongo-persistent-storage2Pod 被分配了一个 instance: jane 和 name: mongo-node2 的标签，以便新的服务可以使用选择器与图 1 所示的 rod Pod 相区分。复制控制器命名为 mongo-rc2
9、该服务名为mongo-svc-b，并获得了一个唯一的外部 IP 地址（在这种情况下，Kubernetes 分配了 104.1.4.5）第三个副本成员的配置遵循相同的模式，下图展示了完整的副本集：
10、请注意，即使在三个或更多节点的 Kubernetes 群集上运行图 3 所示的配置，Kubernetes 可能（并且经常会）在同一主机上编排两个或多个 MongoDB 副本集成员。这是因为 Kubernetes 将三个 pod 视为属于三个独立的服务。
11、为了在区域内增加冗余，可以创建一个附加的 headless 服务。新服务不向外界提供任何功能（甚至不会有 IP 地址），但是它可以让 Kubernetes 通知三个 MongoDB pod 形成一个服务，所以 Kubernetes 会尝试在不同的节点上编排它们
12、配置和启动 MongoDB 副本集所需的实际配置文件和命令可以在白皮书《启用微服务：阐述容器和编排》中找到。特别的是，需要一些本文中描述的特殊步骤来将三个 MongoDB 实例组合成具备功能的、健壮的副本集。
1、上面创建的副本集存在风险，因为所有内容都在相同的 GCE 集群中运行，因此都在相同的可用区availability zone中。如果有一个重大事件使可用区离线，那么 MongoDB 副本集将不可用。如果需要地理冗余，则三个 pod 应该在三个不同的可用区或地区中运行。
2、令人惊奇的是，为了创建在三个区域之间分割的类似的副本集（需要三个集群），几乎不需要改变。每个集群都需要自己的 Kubernetes YAML 文件，该文件仅为该副本集中的一个成员定义了 pod、复制控制器和服务。那么为每个区域创建一个集群，永久存储和 MongoDB 节点是一件很简单的事情。
3、下一步要了解有关容器和编排的更多信息 - 所涉及的技术和所提供的业务优势 - 请阅读白皮书《启用微服务：阐述容器和编排》。该文件提供了获取本文中描述的副本集，并在 Google Container Engine 中的 Docker 和 Kubernetes 上运行的完整的说明。