如何在容器化世界中独特地解决“过程”？

Question

这是一个普遍的问题，但是出于论证的缘故，您可以并假设我们有一个通过AMQP和HTTP组合进行html" target="_blank">通信的进程集合。有两种情况需要考虑。

简单的一个：

• 问）如果A向B发送消息，B如何识别A的位置以发送答复。
• A）A必须告诉B以某种方式将其发送到哪里（交换AMQP，URL URL）

较难的：

• 问）监视过程如何向A发送消息（其他原因促使了这种愿望-例如B说A向我发送了错误的请求）
• 问）监视过程如何终止或重新启动A。

这可能像杀死主机+ pid或pod或pod + container

您可能希望重新启动整个服务或提供该服务的过程的某些子集。

现在，您可以自己分配一个UUID，但是需要一个表来映射它。它可能有多个列，但有时单个URI（或类似URI的东西）很有用，例如，作为“起源于/回复到”地址。

查看此问题的另一种方法。在过去，很容易确定一个过程。

主机名（或IP地址）+ PID

然后进行虚拟化，IP地址标识分配给VM的虚拟网络端口，而PID标识其中的进程。主机名和IP地址仍然足够。有时您也需要虚拟主机（尽管我从来不知道为什么）

现在，将容器添加到混合物中，容器不一定具有自己的IP地址。一个主机+PID可识别的容器
，但你可能不知道的主机，如果你正在运行kubernetes或码头群。

现在，我们不再谈论流程，而是谈论服务。过去足以使用主机名（或IP地址）和端口来标识服务（YMMV-
IP地址和端口号可以一起唯一地标识进程ID吗？。

现在，我们有了负载平衡器和其他技巧（例如，缓存代理），可以将消息重定向到实际提供服务的其他内容。

包含多个容器的容器或容器可能会提供服务，在这种情况下，您可能需要处理容器或容器。例如查看kubernetes在pod中重新启动容器看起来每个docker实例的容器名称都是唯一的，但除此之外没有。

因此，您可能想通过几种不同的方式来处理消息。有一个好的标准方法吗？

在我看来，要使用的显而易见的东西是URI（但是我可能错了）。是否有推荐的URI形式来处理 所有 可能的情况？（显然，对于简单的情况，我们有
procotocl ：// host ： port /）

Answer 1

经过一番考虑，我相信host + pid仍然足以（但不一定是最好的方式）来标识一个进程，只要您注意以下几点：

• 您的PID可能含义不明确。它可以是容器名称空间或主机的PID。

• 如果要从容器外部引用进程，则需要使用主机的PID，而不要使用容器中出现的PID，因为它位于单独的进程名称空间中。例如，请参见“ 好奇的情况下，pid名称空间”

• 容器可能能够识别主机和PID本身（毕竟它应该是一个沙箱）

• IP地址将相对于内部网络（正常情况下）

• 主机名将通过DNS查找（通常）

现在，URI是指端口而不是PID，因此URI在这里不合适。PID @ HOST可能是一个明智的表示法，但请注意与user @ host混淆。

除了容器和Pod
ID外，还有其他更方便的方式来标识处理资源，例如有状态集