【发布时间】：2018-12-31 01:51:11
【问题描述】：
数据库旨在消耗所有可用的内存、CPU 和 IO。 Docker 不应该用于生产中的数据库是否有好/坏的原因？
这个问题可能适用于其他工具，如 MOM Apache Kafka、Apache ActiveMQ 等。
【问题讨论】：
标签： database docker kubernetes
【发布时间】：2018-12-31 01:51:11
【问题描述】：
Docker 不是一个完整的虚拟机（至少在 Linux 上运行时），这只是另一个进程，运行在与主机相同的内核上。此外，所有docker 容器进程都可以在具有ps aux 的主机中看到。
Docker 提供的唯一额外负载是在您的内核之上加载另一个操作系统，但实际上大多数容器都部署了极轻量级的东西，例如alpine Linux，所以我认为不必考虑它。
另一方面，在容器中拥有数据库（或任何其他高负载服务）可为您带来以下优势：
- 可扩展（使用
k8s等容器编排工具可以轻松地将容器分布在节点之间） - 易于部署（所有依赖项都在里面）
- 轻松升级（只需更换容器）
- 易于测试（无需在运行测试之前进行 db-cleaning 程序） 和其他人
所以今天部署容器化服务是正确的做法。
【讨论】：
-
总结您的答案，将应用程序（Spring、Python、NodeJS 等）部署为 docker 容器并通过 K8s 进行管理。但生产环境中裸机服务器上的 DB Server、MoM 等应用程序。
-
@BhanuHoysala 这是一个极具争议的话题。你可以使用 Persistent Volumes、Shared Storage Pools 和 Affinitly 规则来让 k8s “好”地处理数据库存储。这个想法是 - k8s 是您的 API 接口，用于与您的基础设施中的所有可能的应用程序进行交互，而不是为每个单独的事物提供一次性脚本
容器被设计成能够通过使用cgroups 来调节资源使用情况，因此只要我们能够预测使用情况，我们在容器中运行它（性能）应该没有问题。但是，除了资源使用之外，还有其他考虑因素。
在像 Kubernetes 这样的架构中，管理数据库部署变得更加复杂，部分原因是容器现在是短暂的。如果 pod 在给定节点上出现故障，则无法保证它会在同一节点上恢复，因此需要对有状态应用程序进行特殊考虑（pod 必须在重新启动时挂载到同一卷等） .这就是像StatefulSets 这样的构造的用武之地。所以，它有效，解决方案和非常经过深思熟虑，但还有一些操作性的障碍需要跳过。
还有像Operators 这样的东西可以处理建立和管理数据库或分布式消息队列等有状态应用程序的复杂需求。这些项目可以是quite green at times，但有很多行为很难在我们开箱即用的裸机上编排。
归根结底，在 Kubernetes（或其他容器编排器）上运行有状态的应用程序（如数据库或消息队列）是一个有争议的话题。与所有设计决策一样，需要权衡弹性、复杂性和可调试性。很多大公司都在生产中这样做，所以这绝不是不合理的。
【讨论】：