[RFC] Always create sandbox init process and remove the field sandbox_pidns #54
Conversation
In hyperstart, the pod_init process has its own net/pid/uts/ipc ns. And in kata, these namespaces are also essential. Net ns for the sandbox should be always created since the container's network should be isolated from the vm's initial network to avoid messing. Pid ns for the sandbox should be always created since the containers always join this ns. We can use new pid ns for each container, but in most cases, they are shared the same sandbox init pid ns. Uts ns for the sandbox should be always created since the hostname is set in it without mess it up with the vm's initial UTS. Ipc ns for the sandbox should be always created since the containers always join this ns. We can use new ipc ns for each container, but in most cases, they are shared the same sandbox init ipc ns. So sandbox init process is better to be always created in its own net/pid/uts/ipc ns and let the later containers join in. To make it different from hyperstart, we can use some config to tell the container not to join it in some cases later. Signed-off-by: Lai Jiangshan <jiangshanlai@gmail.com>
I have 2 concerns with this:
|
|
@sameo I agree with you, this is represent the Even pid namespaces is |
I think it would be cleaner if we change the pod boolean for pid_ns to be a string that cannot be empty, but either be
Yes, I agree with that. We should document it as part of the proto file. |
|
@laijs @sameo This whole thing about shared pid ns is related to k8s concept of pod having its containers sharing or not the same namespaces. First, that means that if k8s creates a pod with this flag, it expects all its containers to share those ns, therefore, there is no need to get this information from the container, it's more appropriate to get it from the pod IMO. |
Almost, yes. With a boolean, the default value is false and thus by default we don't share the pid ns. With a string, it has no meaningful value and you can even force the caller to select one. |
|
@sameo ok then I consider this is a detail in this conversation, and I am fine with both ways. But about the pidns flag, I would really prefer to keep this as part of |
|
@sboeuf Yes, I fully agree. Being shared by default and having containers opt out of it would be something that can't be expressed by the CRI afaiu. |
|
Ok, we agree to keep the sandbox_pidns as a knob to tell the agent whether all the containers should join the sandbox init process's pidns or not. I will close this pr, and add a new issue for the remanning requirement in #59 |
|
Thank you @laijs |
In hyperstart, the pod_init process has its own net/pid/uts/ipc ns.
And in kata, these namespaces are also essential.
Net ns for the sandbox should be always created since the container's
network should be isolated from the vm's initial network to
avoid messing.
Pid ns for the sandbox should be always created since the containers
always join this ns. We can use new pid ns for each container,
but in most cases, they are shared the same sandbox init pid ns.
Uts ns for the sandbox should be always created since the hostname
is set in it without mess it up with the vm's initial UTS.
Ipc ns for the sandbox should be always created since the containers
always join this ns. We can use new ipc ns for each container,
but in most cases, they are shared the same sandbox init ipc ns.
So sandbox init process is better to be always created
in its own net/pid/uts/ipc ns and let the later containers
join in. To make it different from hyperstart, we can use
some config to tell the container not to join it in
some cases later.
Signed-off-by: Lai Jiangshan jiangshanlai@gmail.com