在Kubernetes docs Pods的此页面上，它说明了
pod的上下文可以定义为几个Linux命名空间的结合：
PID命名空间（pod中的应用程序可以看到彼此的进程） 网络命名空间（pod中的应用程序可以访问相同的IP和端口空间）
IPC名称空间（pod中的应用程序可以使用SystemV IPC或POSIX消息队列进行通信）
UTS名称空间（pod中的应用程序共享主机名）
然而，它然后说
就Docker构造而言，pod包含一组共享卷的共处理Docker容器。 Docker尚未实现PID命名空间共享。
这是否意味着pod无法在其他容器中查看进程或在同一pod中运行的容器之间执行任何类型的IPC？如何向另一个pod中运行的进程发送信号？
答案 0 :(得分：3)
是的，我们希望他们可以共享PID命名空间，但正如您所说，Docker目前不支持它。一旦我们在Docker中获得支持，我们将迅速将其添加到Kubernetes。
这意味着您无法使用信号来指示Pod中的其他进程。
但是，您可以使用管道和共享内存等IPC机制。
答案 1 :(得分：2)
这是否意味着pod无法在其他容器中查看进程或在同一pod中运行的容器之间执行任何类型的IPC？
这正是＆＃34; PID命名空间共享尚未用Docker＆＃34;实现。 Kubernetes＆＃34; pods＆＃34;只是Docker容器的集合，所以如果你不能在直接的Docker中做到这一点，你就不能在Kubernetes中做到。
pod 中的容器共享网络命名空间，因此您可以将侦听套接字绑定到localhost，并从该pod中的任何容器访问它。可能这可以用于容器间ipc /信令。
答案 2 :(得分：1)
pod中的容器可以使用sysV共享内存（shmget（）shmat（））和（一旦docker正确支持它）POSIX共享内存。我们唯一能做的就是signal（）和ptrace（），看看/ proc中的进程
答案 3 :(得分：0)
这是否意味着Pod无法看到其他容器中的进程或在同一Pod中运行的容器之间执行任何类型的IPC？
最近的Kubernetes 1.12 (Q3 2018) announcements包括：
可配置的pod进程名称空间共享正朝着beta迈进，这意味着用户可以通过在PodSpec中设置选项来配置pod内的容器以共享公共PID名称空间。
请参见kubernetes/feature 495“可配置Pod进程命名空间共享”（及其PR 66507，commit 8ebc84e）和its documentation：“ Share Process Namespace between Containers in a Pod”。
警告，与此：
容器进程不再具有PID 1 。 一些容器映像拒绝在没有PID 1的情况下启动（例如，使用systemd的容器）或运行诸如
kill -HUP 1之类的命令来指示容器进程。 在具有共享流程名称空间的Pod中，kill -HUP 1将向Pod沙箱发出信号。- 通过
该过程对容器中的其他容器可见。 这包括
/proc中可见的所有信息，例如作为参数或环境变量传递的密码。这些仅受常规Unix权限保护。/proc/$pid/root链接，容器中的其他容器可以看到容器文件系统。 这使调试更加容易，但也意味着文件系统机密仅受文件系统权限的保护。
答案 4 :(得分：0)
如果Pod规范中的shareProcessNamespace属性设置为true，则POD中的所有容器都共享PID名称空间。因此，一个容器中的进程可以向另一个容器中的进程发送信号。
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pod-v1-core