<p>On this page in the Kubernetes docs <a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/user-guide/pods.md" rel="noreferrer">Pods</a>, it states</p>

<blockquote>
  <p>The context of the pod can be defined as the conjunction of several Linux namespaces:</p>
  
  <p>PID namespace (applications within the pod can see each other's processes)
  network namespace (applications within the pod have access to the same IP and port space)</p>
  
  <p>IPC namespace (applications within the pod can use SystemV IPC or POSIX message queues to communicate)</p>
  
  <p>UTS namespace (applications within the pod share a hostname)</p>
</blockquote>

<p>However, it then says that</p>

<blockquote>
  <p>In terms of Docker constructs, a pod consists of a colocated group of Docker containers with shared volumes. PID namespace sharing is not yet implemented with Docker.</p>
</blockquote>

<p>So does this mean that pods cannot see processes in other containers or perform any kind of IPC between containers running in the same pod?  How would I send a signal to a process running in another pod?</p>

<blockquote>
  <p>does this mean that pods cannot see processes in other containers or perform any kind of IPC between containers running in the same pod?</p>
</blockquote>

<p>Recent <a href="https://kubernetes.io/blog/2018/09/27/kubernetes-1.12-kubelet-tls-bootstrap-and-azure-virtual-machine-scale-sets-vmss-move-to-general-availability/#additional-notable-feature-updates" rel="nofollow noreferrer">Kubernetes 1.12 (Q3 2018) announcements</a> do include:</p>

<blockquote>
  <p>Configurable pod process namespace sharing is moving to beta, meaning <strong>users can configure containers within a pod to share a common PID namespace by setting an option in the PodSpec</strong>.</p>
</blockquote>

<p>See <a href="https://github.com/kubernetes/features/issues/495" rel="nofollow noreferrer">kubernetes/feature 495</a> "Configurable Pod Process Namespace Sharing" (and its <a href="https://github.com/kubernetes/kubernetes/pull/66507" rel="nofollow noreferrer">PR 66507</a>, <a href="https://github.com/kubernetes/kubernetes/commit/8ebc84e71d7eb1c45dc296945dc232e811b2b820" rel="nofollow noreferrer">commit 8ebc84e</a>), and <a href="https://github.com/kubernetes/website/pull/9996" rel="nofollow noreferrer">its documentation</a>: "<a href="https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/" rel="nofollow noreferrer"><strong>Share Process Namespace between Containers in a Pod</strong></a>".</p>

<p>Warning, with this:</p>

<blockquote>
  <ol>
  <li><p><strong>The container process no longer has PID 1</strong>. 
  Some container images refuse to start without PID 1 (for example, containers using systemd) or run commands like <code>kill -HUP 1</code> to signal the container process. 
  In pods with a shared process namespace, <code>kill -HUP 1</code> will signal the pod sandbox.</p></li>
  <li><p><strong>Processes are visible to other containers in the pod</strong>. 
  This includes all information visible in <code>/proc</code>, such as passwords that were passed as arguments or environment variables. These are protected only by regular Unix permissions.</p></li>
  <li><p><strong>Container filesystems are visible to other containers in the pod through the <code>/proc/$pid/root</code> link</strong>. 
  This makes debugging easier, but it also means that filesystem secrets are protected only by filesystem permissions.</p></li>
  </ol>
</blockquote>
