如何在容器化世界中独特地解决“过程"? [英] How to uniquely address a 'process' in a containerised world?

问题描述

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

简单的一个:

• Q)如果A向B发送消息，B如何确定A的位置以发送答复.
• A)A必须告诉B以某种方式将其发送到哪里(交换AMQP，URL传递http)

难者:

• Q)监视过程如何向A发送消息(其他原因促使了这种愿望-例如B说A向我发送了错误的请求)

• Q)监视过程如何终止或重启A.

  这可能类似于杀死主机+ pid或pod或pod +容器

  (例如，参见 kubernetes重新启动容器内的容器)

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

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

---

查看此问题的另一种方法. 在过去，识别过程很容易.

一个主机名(或IP地址)+一个PID就足够了

然后进行虚拟化，IP地址标识分配给VM的虚拟网络端口，而PID标识其中的进程. 主机名和IP地址仍然足够. 有时您也需要虚拟主机(尽管我一直不清楚为什么)

现在将容器添加到混合物中，容器不一定具有其自己的IP地址. ).

现在，我们有了负载平衡器和其他技巧(例如，缓存代理)，可以将消息重定向到实际提供服务的其他地方.

包含多个容器的容器或容器可能会提供服务，在这种情况下，您可能要解决容器或容器的地址. 参见例如 kubernetes重新启动容器内的容器 看起来容器名称在每个Docker实例中都是唯一的，但除此之外并没有.

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

在我看来，要使用的显而易见的东西是URI(但我可能错了). 是否有推荐的URI形式来处理所有可能的情况? (很明显，对于简单的情况，我们有 procotocl ://:// host : port /)

解决方案

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

• 您所指的PID可能是模棱两可的. 可以是容器名称空间或主机的PID.

• 如果要从容器外部引用进程，则需要使用主机的PID，而不要使用容器中出现的PID，因为它位于单独的进程名称空间中. 参见例如 the-curious-case-of-pid-namespaces

• 容器可能能够识别主机和PID本身(毕竟它应该是沙箱)

• IP地址将相对于内部网络(通常)

• 主机名将通过DNS查找(通常)

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

除了容器和容器ID之外，还有其他更方便的方式来标识处理资源，例如kubernetes restart container within pod)

You might wish to restart an entire service or some subset of the processes that are providing that service.

Now you can assign a UUID yourself but you need a table to map it. This may have multiple columns but sometimes a single URI (or URI like thing) is useful for example as a "originated from/reply to" address.

---

Another way to view this question. In the old days it was easy to identify a process.

A hostname (or IP address) + a PID was sufficient

Then came virtualisation the IP address identifies the virtual network port assigned to the VM and the PID identifies the process within it. A hostname and IP address are still sufficient. Sometimes you need the vhost as well (though I was never clear why)

Now adding containers to the mix a container doesn't necessarily have a IP address of its own. A host+pid can identify the container But you might not know the host if you are running kubernetes or docker swarm.

Now we don't talk about processes so much anymore as about services. It used to be enough to identify a service using a hostname (or IP address) and a port (YMMV - Can an IP address and a port number together uniquely identify a process ID?).

Now we have load balancers and other tricks (e.g. caching proxies) to redirect messages to something else that actually provides a service.

A service might be provided by a container or a pod containing several containers in which case you may want to address the pod or the container. See for example kubernetes restart container within pod It looks like container names are unique per docker instance but not beyond that.

So there a few different ways you might want to address a message. Is there a good standard way of doing this?

To my mind the obvious thing to use is a URI (but I could be wrong). Are there recommended URI forms to handle all possible cases? (obviously we have procotocl://host:port/ for the easy cases)

解决方案

After some consideration I believe host+pid is still sufficient (but not necessarily the best way) to identify a process providing you are mindful of the following:

• whose PID you mean could be ambiguous. It could be the PID of the container's namespace or the host.

• If you are referring to the process from outside the container you need to use the PID of the host not the PID as it appears inside the container as this is in a separate process namespace. See for example the-curious-case-of-pid-namespaces

• The container may evem be able to identify the host and PID itself (after all it is supposed to be a sandbox)

• IP addresses will be relative to the internal network (as normal)

• hostnames will go via DNS lookup (as normal)

Now a URI refers to a port not a PID so a URI is not appropriate here. PID@HOST is probably a sensible notation but beware confusion with user@host.

In addition to container and pod Ids there are other more convenient ways to identify a processing resource such as stateful sets

这篇关于如何在容器化世界中独特地解决“过程"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！