K8s: node.js应用程序的dbs部署模式

Question

嗨!

我的问题与通过node.js部署k8s、架构模式并将它们与DB连接在一起有关。

 alpha | beta | gamma1 | gamma2

我有下面的node.js应用程序服务，其中一些是通过应用实例(比如gamma)来扩展的，另一些是单独的，所有这些服务都是在一个带有.Dockefile的接口映像中构建并运行的。

我也有一个非云DBs，比如弹性和蒙戈在容器中使用.env：mongo | elastic运行。

现在，我的docker-compose.yml就像一个典型的node.js示例应用程序，但是具有公共卷和桥接网络(除了我有一个以上的node.js应用程序之外)：

version: '3'
services:
  node:
    restart: always
    build: .
    ports:
      - 80:3000
    volumes:
      - ./:/code
  mongo:
    image: mongo
    ports:
      - 27017:27017
    volumes:
      - mongodb:/data/db
volumes:
 mongodb:

networks:
  test-network:
    driver: bridge

目前的部署：

所有这些东西都是运行在一个单一的重VPS (X CPU核心，Y RAM，Z，所有加载70%)从单个docker-compose.yml文件。

我想要的是：

由于一个VPS还不够，我想开始在牧场主中使用k8s。因此，问题在于正确的部署：

例如，我在一个专用网络中连接了N VPSs，每个VPS是一个连接在一个集群中的工作人员(当然，其中有一个是主节点)，它为我提供了X核、Y RAM和其他共享资源。

1. 我是否需要另一个单独的集群(或者是专用网络中的VPS机器，而不是集群的一部分)，并在其中运行DB？或者我可以在同一个集群中部署DB？如果集群中的每个VPS (worker)只有40 DB的卷，而DB将比这个卷增长得更多，那该怎么办？来自员工的共享资源是否包括共享卷空间？
2. 有一个映像可以启动我所有的应用程序，或者在k8s的例子中，我应该为每个服务都有一个单独的停靠映像，这是正确的吗？因此，如果我有5个node.js应用程序在一个单一回购，我应该有5个单独的对接图像，而不是一个常见的？

我会明白，我的问题可能有一个复杂的答案，所以我将高兴地看到，不仅是答案，但链接或任何与问题有关的东西。如果你知道和怎么问的话，找到或者用谷歌搜索东西要容易得多。

Answer 1

一个纯粹的答案：

您的五个服务都应该有自己的映像和自己的数据库。只要您有办法备份数据库、运行迁移以及执行其他数据库操作，数据库就可以在同一个集群中运行。如果您的云提供商提供这些数据库的托管版本，那么将数据存储在集群之外也是可以的，并且可以帮助解决您引用的一些磁盘空间问题。

我倾向于将掌舵用于实际的部署机制，作为在部署时注入主机名和其他设置的一种方式。每个服务都有自己的Dockerfile、自己的Helm图表、自己的package.json等等。您的CI系统将分别构建和部署每个服务。

一个实用的答案：

从技术上讲，在同一个映像上运行多个容器做不同的工作没有什么问题。如果您现在有一个单独的存储库和一个构建系统，并且不介意对一个服务进行更改，导致所有这些服务重新部署，那么这种方法将很好地工作。

不管您的存储库现在有什么构建系统，如果您采用这种方法，我会在存储库根目录中放置一个Dockerfile，并且可能有一个Helm图表来部署它。在Helm图表部署规范中，您可以重写命令以运行如下

# This fragment appears under containers: in a Deployment's Pod spec
# (this is Helm chart, Go text/template templated, YAML syntax)
image: {{ .Values.repository }}/{{ .Values.image }}:{{ .Values.tag }}
command: node service3/index.js

Kubernetes在这里的术语与Docker略有不同，特别是如果您使用入口点包装器脚本。Kubernetes command:覆盖Dockerfile ENTRYPOINT，Kubernetes args:重写CMD。

两种情况下的：

Kubernetes中的许多东西动态地分配基础设施。例如，您可以设置水平结荚自动分配器来设置基于load的部署的副本计数，或者在需要时设置更多(云)实例来运行Pods。如果您有一个持久的卷提供程序，那么一个Kubernetes PersistentVolumeClaim对象可以由动态分配的存储(例如，在AWS上，它创建了一个EBS卷)来支持，并且您将不局限于单个节点的存储空间。您通常可以为数据库找到预先构建的Helm图表；如果没有，请使用StatefulSet让Kubernetes为您创建PVC。

确保您的CI系统生成带有唯一标记的映像，可能基于时间戳或源代码管理提交ID。不要使用...:latest或其他固定字符串:除非image:字符串的文本发生更改，否则image:不会在更新时重新部署。

多个集群在很多方面都是棘手的。在我的日常工作中，每个环境(开发、预生产、生产)都有单独的集群，但是应用程序本身运行在一个集群中，集群之间没有通信。如果您可以管理存储，那么在同一个集群中运行数据库就可以了。

几个组合选项并不能很好地转化为Kubernetes。我特别建议在执行任何特定于Kubernetes的操作之前，删除绑定到容器中的代码并验证映像是否正确运行的volumes:。如果要替换映像中的整个源树，那么实际上并不是在运行映像，而且在本地调试也要容易得多。在Kubernetes中，您也几乎没有对networks:的控制，但是它们也不是真正需要的。

Answer 2

我不能回答你问题中关于VPS机器设置的部分，但是我可以对图像设置提出一些建议。

实际上，虽然您已经问过这个关于节点应用程序的问题，但它实际上并不仅仅适用于节点。

关于码头形象，并有一个共同的形象或单独的形象；一般是由你和/或你的公司决定你是否有一个共同的形象或单独的形象。

这两种方法各有优缺点：

您可以将代码“烘焙”到映像中，并且每个应用程序都有不同的图像，但是如果您遇到任何安全漏洞，则必须修补、重建和重新部署所有图像。如果您有5个应用程序都使用相同的库，但该库不在基本映像中，那么您必须对其进行5次修补，每次修复一次，重建映像并重新部署。

或者您只需使用包含所需库的单个基本映像，并将代码基装入其中(例如，作为configmap)，并且该基本映像永远不需要更改，除非您必须在底层操作系统中进行修补。以上段落中提到的相同漏洞，只需要在基本映像中修补，受影响的豆荚就可以重新填充(不需要重新部署)。