Shared PID and UTS namespaces

@thockin

Assuming moby/moby#8211 goes in, we should decide whether we want containers within a pod to share IPC namespaces by default (which fits the "logical host" model for pods and keeps the API simple at the cost of slightly reduced isolation), or provide an option (in which case we could wait until users ask for it).

/cc @thockin

@thockin

I instinctively feel like sharing IPC might be OK, but what is the
principle behind it? Why not share PID and User namespaces, too?

On Mon, Oct 6, 2014 at 9:11 PM, bgrant0607 notifications@github.com wrote:

Assuming moby/moby#8211 moby/moby#8211
goes in, we should decide whether we want containers within a pod to share
IPC namespaces by default (which fits the "logical host" model for pods and
keeps the API simple at the cost of slightly reduced isolation), or provide
an option (in which case we could wait until users ask for it).

/cc @thockin https://github.com/thockin

Reply to this email directly or view it on GitHub
#1615.

@thockin

@thockin I agree we should likely treat these cases similarly to the extent possible. The principle is the same one behind shared network namespaces and volumes within a pod -- facilitating communication / interaction within a pod.

@thockin

Devil's advocate: Signals have to be within a PID namespace. Aren't
signals a form of communication?

On Mon, Oct 6, 2014 at 10:39 PM, bgrant0607 notifications@github.com
wrote:

@thockin https://github.com/thockin I agree we should likely treat
these cases similarly to the extent possible. The principle is the same one
behind shared network namespaces and volumes within a pod -- facilitating
communication / interaction within a pod.

Reply to this email directly or view it on GitHub
#1615 (comment)
.

@thockin

@thockin: How is that playing devil's advocate? It sounds like you're agreeing with my previous statement.

IPC namespaces can contain large objects (e.g. shm segments).
PID, UTS, NS, USER, and probably NET do not.

IPC objects (shms, sems, msqs) can be created by user and can have significant memory usage in typical use cases.
PID, UTS, NS, USER do not for typical use cases.
NET should not be large in "typical" use cases.

IPC objects live beyond the processes in a container, and so would need to be cleaned up in concert with the container or pod lifetime. PID automatically cleans up when process dies.
UTS, USER, and NS don't have user created objects.
NET, I'm not sure if we would give users permission to create objects with lifetime issues.

So, IPC is quite different from the others.

@thockin

My point was that if the principle for sharing is "communication", then we
should also be arguing for shared PID namespace in a pod, but we're not.

On Tue, Oct 7, 2014 at 12:06 AM, bgrant0607 notifications@github.com
wrote:

@thockin https://github.com/thockin: How is that playing devil's
advocate? It sounds like you're agreeing with my previous statement.

Reply to this email directly or view it on GitHub
#1615 (comment)
.

Comparison

IPC ns per pod:

charge memory of all IPC objects to pod.
delete IPC object only at pod termination, not at single-container restart.
user responsible for clearing out ipc object on container restart.
shm segments are basically the same as multiple mmaps of a /tmpfs file. if we think /tmpfs as a pod volume makes sense, I guess so does pod-scope IPC ns.

IPC ns per container:

charge memory of all IPC objects to container
delete IPC objects at pod termination
delete IPC objects at container restart? Could be useful. Not clear if this is what users want, but could work. What will docker do?

Charging doesn't enter the picture. First, there is no concept of
pod-scope resources yet, and second, memory chargin is first-touch always.

It's entirely about visibility and lifetime. I can imagine use-cases for
both modes, but I want to resist the urge to make it an API feature.

On Fri, Oct 10, 2014 at 10:08 AM, erictune notifications@github.com wrote:

Comparison

IPC ns per pod:

charge memory of all IPC objects to pod.

delete IPC object only at pod termination, not at single-container
restart.

user responsible for clearing out ipc object on container restart.

shm segments are basically the same as multiple mmaps of a /tmpfs
file. if we think /tmpfs as a pod volume makes sense, I guess so does
pod-scope IPC ns.

IPC ns per container:

charge memory of all IPC objects to container

delete IPC objects at pod termination

delete IPC objects at container restart? Could be useful. Not clear
if this is what users want, but could work. What will docker do?

Reply to this email directly or view it on GitHub
#1615 (comment)
.

In case it wasn't clear, IMO, we should opt for shared namespaces within a pod. I agree we should not surface an option in the API.

moby/moby#8211 has been replaced by moby/moby#8835

Shared IPC namespaces went in: moby/moby#9074

PID namespaces haven't gone anywhere AFAICT: moby/moby#8568

We should do IPC namespaces as soon as there's a new docker build

On Fri, Nov 21, 2014 at 9:09 AM, bgrant0607 notifications@github.com
wrote:

Shared IPC namespaces went in: moby/moby#9074
moby/moby#9074

Reply to this email directly or view it on GitHub
#1615 (comment)
.

@verb

@verb: Closing this issue.

Details

In response to this:

Shared PID namespaces was promoted to beta in the last release. afaik no one is working on configurable UTS namespaces. I guess these issues aren't intended to be long-lived, and I'm tired of fighting the bot, so I'll close this as fixed. Anyone wanting to track the feature further can follow kubernetes/enhancements#495.

/remove-lifecycle rotten
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.