user1225011
user1225011

Reputation: 101

Can pods in Kubernetes see/access the processes of other containers running in the same pod?

On this page in the Kubernetes docs Pods, it states

The context of the pod can be defined as the conjunction of several Linux namespaces:

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)

IPC namespace (applications within the pod can use SystemV IPC or POSIX message queues to communicate)

UTS namespace (applications within the pod share a hostname)

However, it then says that

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.

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?

Upvotes: 9

Views: 6860

Answers (5)

pr-pal
pr-pal

Reputation: 3558

If shareProcessNamespace attribute in the Pod specification is set to true, all the containers in a POD share the PID namespace. Hence a process in one container can send signals to the processes in another container.

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pod-v1-core

Upvotes: 1

VonC
VonC

Reputation: 1327784

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

Recent Kubernetes 1.12 (Q3 2018) announcements do include:

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

See kubernetes/feature 495 "Configurable Pod Process Namespace Sharing" (and its PR 66507, commit 8ebc84e), and its documentation: "Share Process Namespace between Containers in a Pod".

Warning, with this:

  1. The container process no longer has PID 1. Some container images refuse to start without PID 1 (for example, containers using systemd) or run commands like kill -HUP 1 to signal the container process. In pods with a shared process namespace, kill -HUP 1 will signal the pod sandbox.

  2. Processes are visible to other containers in the pod. This includes all information visible in /proc, such as passwords that were passed as arguments or environment variables. These are protected only by regular Unix permissions.

  3. Container filesystems are visible to other containers in the pod through the /proc/$pid/root link. This makes debugging easier, but it also means that filesystem secrets are protected only by filesystem permissions.

Upvotes: 5

Tim Hockin
Tim Hockin

Reputation: 3662

Containers in a pod can use sysV shared memory (shmget() shmat()) and (once docker supports it properly) POSIX shared memory. The only things we can't do are signal() and ptrace() and see processes in /proc

Upvotes: 1

larsks
larsks

Reputation: 312370

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?

That is exactly what is meant by "PID namespace sharing is not yet implemented with Docker". Kubernetes "pods" are just collections of Docker containers, so if you can't do it in straight Docker you can't do it in Kubernetes.

The containers in a pod do share a network namespace, so you can bind a listening socket to localhost and access it from any of the containers in the pod. Possibly this can be used for inter-container ipc/signalling.

Upvotes: 3

Brendan Burns
Brendan Burns

Reputation: 734

Yeah, we wish that they could share the PID namespace, but as you say, it is not currently supported by Docker. Once we have support in Docker, we will rapidly add it to Kubernetes.

This means that you can't use signal to signal other processes in the Pod.

You can, however, use IPC mechanisms like pipes and shared memory.

Upvotes: 4

Related Questions