Kubernetes 最佳实践：映射外部服务

文 / 开发技术推广工程师 Sandeep Dinesh

大多数 Kubernetes 用户都有可能用到集群外部的服务。例如，您可能使用 Twillio API 发送短信，或使用 Google Cloud Vision API 进行图像分析。

如果位于不同环境中的应用连接相同的外部端点，并且您不打算将外部服务引入 Kubernetes 集群，那么在代码中直接使用外部服务端点是完全可以的。然而，很多时候情况并非如此。

数据库就是一个很好的例子。虽然一些云原生数据库（如 Cloud Firestore 或 Cloud Spanner）对所有访问均使用一个端点，但大多数数据库对不同实例都有单独的端点。

说到这里，您可能会认为，就查找端点而言，ConfigMap 是个不错的解决方案。只需将端点地址存储在 ConfigMap 中，并将其作为环境变量用于代码中。此解决方案的确有效，但也存在一些缺点。您需要修改部署以包含 ConfigMap 并编写额外的代码以从环境变量中读取。但最重要的是，如果端点地址发生变化，您可能需要重启所有正在运行的容器以获取更新后的端点地址。

在本集的 “Kubernetes 最佳实践” 中，我们会学习如何将 Kubernetes 内置服务发现机制运用于集群外部运行的服务，像使用集群内的服务一样使用外部服务！通过这种方式，您可以在开发环境和生产环境中实现相同的功能，如果您最终将服务移入集群内，则不需要更改任何代码。

场景 1：具有 IP 地址的集群外数据库

其中一个常见场景是在集群外部托管自己的数据库，例如在 Google 计算引擎实例中。如果您在 Kubernetes 内部和外部分别运行一些服务，或者需要在 Kubernetes 允许的基础上获得更多定制或控制，通常可采用上述这种方式。

希望未来某个时候您可以将所有服务都移入集群内，但在此之前将是“内外混用”的状态。幸运的是，您可以使用静态 Kubernetes 服务来缓解上述痛点。

在本例中，我使用 Cloud Launcher 创建了一个 MongoDB 服务器。由于此服务器在与 Kubernetes 集群相同的网络（或 VPC）中创建，因此可以使用高性能的内部 IP 地址访问。在 Google Cloud 中，这是默认设置，因此无需进行任何特殊配置。

现在我们有了 IP 地址，那么第一步就是创建服务：

kind: Service

apiVersion: v1

metadata:

 name: mongo