☰

Kubernetes，具有唯一数据库服务器的 Pod 与一个共享数据库服务器

tag-icon • tag-icon docker database kubernetes
Kubernetes，具有唯一数据库服务器的 Pod 与一个共享数据库服务器

我正在开发一个作为云服务提供的应用程序，即n该应用程序的实例，每个实例彼此完全分离，并且每个分离的克隆都将数据存储在其自己的 pgsql 中database。

目前只有一个数据库服务器，我手动设置此应用程序的 docker 镜像，并将该镜像连接到公共数据库服务器上新创建的数据库。这个过程非常耗时耗力，所以我想用Kubernetes。

我设计了一个带有一个主服务器的结构，它将协调和自动创建节点，但出现的众多问题之一是，处理这种架构的数据存储的最佳方法是什么？

是否最好为每个服务器托管一个数据库服务器荚，或者我应该设置一个贮存整体单位节点和做豆荚连接到它？我想要实现的事情是否适合 Kubernetes？即自动部署单个码头工人图像将被复制为完全独立的实例，每个实例都有自己的数据库。

答案1

如果您确实有这么多单个应用程序实例，那么为每个实例设置单独的数据库实例Pod可能是一项非常繁琐的任务。当然，这些实例Pods不应该只是裸机Pods，而应该由某些控制器（例如Deployment或）管理Statefulset（这更适合数据库等有状态的应用程序）。无论它创建和管理的副本数量是否只有一个，您都应该使用控制器，因为它将Pod为您处理生命周期。

放置两者应用和数据库不建议单独使用Pod这种方法。根据微服务架构方法，你的申请的所有元素，如其前端部分，后端 API和数据库不应紧密耦合，即把所有这些元素放在一个单一的环境中Pod绝对不是推荐的方法。它仍然是可能的，技术上也是可行的，但有很多缺点。

如果应用程序的每个实例Deployment应该完全独立，那么最​​好将它们部署为单独的实例，而不是作为一组实例运行并由Pods一个实例管理Deployment。每个实例Pods都可以连接到由单独的实例管理的数据库实例StatefulSet。

当你已经设置好数据库服务器后，它也可以被你的Pods. 这仍然是可以接受的方法，因为容器通常不是运行的最佳选择有状态的应用程序在许多情况下，在裸机或虚拟机上运行它们可能会更好。

如果你的数据库服务器有其完全限定域名 (FQDN)，你可以简单地定义ExternalName Service指向该域名的类型：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

在查找主机 时my-service.prod.svc.cluster.local，集群 DNS 服务会返回CNAME值为 的记录 my.database.example.com。访问my-service方式与其他服务相同，但关键区别在于重定向发生在 DNS 级别，而不是通过代理或转发。如果您稍后决定将数据库移入集群，则可以启动其 Pod、添加适当的选择器或端点，并更改服务的type。

然后，您可以Service在应用程序中使用您的名称（在单个命名空间中工作时）来连接到其后面的数据库。这里你可以看到前端应用程序的一部分可以与其连接后端。如果您的应用程序支持配置文件，您可以在其中指定数据库 URL，您可以Pod通过配置图，无需更改您的代码并重建您的 docker 镜像。

我希望它能有所帮助并澄清一些可用的选项。

相关内容