Kubernetes上的过程激活剂

我们有一个微服务/ish体系结构，我们目前在一个VM上。我们的每个应用程序都部署为DLL，没有可执行文件。为了运行它们，我们生成了激活器的一个新实例，将应用程序的路径作为参数传递。process activator通过DI在应用程序上注入行为，例如代理和服务发现逻辑

这样做的好处是，应用程序和process activator可以彼此独立地开发、管理和部署。如果我们有激活器的更新，我们只需要部署它并重新启动所有应用程序，我们的更改就可以生效；无需重新部署应用程序，更不用说重新构建它了

然而，当我们正在制定一项计划，将我们的体系结构迁移到Kubernetes时，我们遇到了一个障碍，因为这种设计。我们还没有找到一种方法来复制这个。我们考虑将两者部署在一起，并将activator设置为入口点；然而，这意味着无论何时更新activator，所有应用程序的映像都必须更新，这完全违背了此设计的目的

我们还考虑将它们部署为两个不同的容器，并以某种方式使activator读取应用程序容器的内容，然后加载其DLL，但我们不知道一个容器是否可以读取另一个容器的内容

---

最后，有没有办法让这个设计在Kubernetes中发挥作用？

如果设计需要以下内容：

• 将文件注入主容器以更改其行为

然后一个可行的选择是使用init容器。Init容器可以在主容器启动之前执行操作，例如，它们可以复制一些文件供主容器使用

您可以将此activator作为主容器，所有不同的应用程序都是一个不同的init容器，其中包含该应用程序的DLL

当init容器启动时，它会将该应用程序的DLL复制到临时卷（aka

emptyDir

）上，以使其可用于主容器。然后activator容器启动并在路径中找到DLL，并可以对它们执行任何操作

这样：

• 如果需要更新激活器，则需要更新主容器映像（凹凸其标记），然后更新所有部署/状态集的定义以使用新映像
• 如果需要更新其中一个应用程序，则需要更新其单个init容器映像（凹凸其标记），然后更新该特定应用程序的部署/状态集的定义

如果您认为仍然需要定义集群中的所有应用程序，那么这个策略非常有效（我认为）。如果您有3个应用程序，A、B和C，则需要定义3个使用正确init容器的部署（如果应用程序出于某些原因是有状态的，则需要定义状态集）

如果应用程序基本相同，并且只有很少的变化。。就像只将DLL注入activator一样，您可以考虑使用HELM来定义集群上的资源，因为它使您能够以很少的开销对资源进行模板化和个性化

---

一些文件：

初始化容器：

在Init容器和主容器之间制作文件副本的示例：

舵手：