Regarding adding an interface to retrieve the netns of a Pod object about kubernetes

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[jiayoukun]

/sig api-machinery

[cici37]

/sig node
/remove-sig api-machinery

[aojea]

@jiayoukun you can use the container runtime directly for this using NRI plugins, that is supported by containerd and crio, see containerd/nri#82

[aojea]

/sig network

[jiayoukun]

@aojea I have read the introduction to NRI plugins, and the functionality does not align with my intended purpose. What I need is an interface to query the Pod's netns using the Pod object's UID. The obtained netns from the query can allow me to extend the network more flexibly.

In fact, for developers using NRI plugins, this interface to query the netns is even more necessary! For Pods with multiple network devices, more fine-grained routing and redirection capabilities are required. Without this interface to obtain the Pod's netns, it is impossible for external components to access and manipulate the Pod's network.

What are your thoughts on this?

[shaneutt]

/assign @thockin

[thockin]

This is a container-runtime (sig-node) topic, but... It's not a guarantee that runtimes use network namespaces at all. It's what most implementations do, but it's not a REQUIREMENT. AFAICT "which netns" is not covered by CRI today, which is probably step 1 and not exactly clear if or how we would want to represent that.

SIG-node - what's the current doctrine on exposing that level of detail?

[jiayoukun]

This is a container-runtime (sig-node) topic, but... It's not a guarantee that runtimes use network namespaces at all. It's what most implementations do, but it's not a REQUIREMENT. AFAICT "which netns" is not covered by CRI today, which is probably step 1 and not exactly clear if or how we would want to represent that.

SIG-node - what's the current doctrine on exposing that level of detail?

Does this involve the specification of netns by CRI? I haven't found any theories about exposing details at this level. It would take a long time to form a specification for netns for all CRIs, right? In the current situation, my understanding is to make a judgment based on most container runtimes that support netns. Something like using a select case to determine the container runtime type? After the specification is completed later, refactor and merge it?

[aojea]

In fact, for developers using NRI plugins, this interface to query the netns is even more necessary! For Pods with multiple network devices, more fine-grained routing and redirection capabilities are required. Without this interface to obtain the Pod's netns, it is impossible for external components to access and manipulate the Pod's network.

What are your thoughts on this?

@jiayoukun one option is from your component on the node to connect to the apiserver to get the Pods information, use an informer to watch the Pods that are only on the corresponding node.
From the same component you open a connection to the container runtime through NRI to get the hook on RunPodSandbox, so you can get the low level details there.
With the data of the informer and of the NRI plugin, you have everything you need, right now the details of the container runtimes are not leaked to the kubelet, to maintain the isolation provided by the CRI API

[jiayoukun]

In fact, for developers using NRI plugins, this interface to query the netns is even more necessary! For Pods with multiple network devices, more fine-grained routing and redirection capabilities are required. Without this interface to obtain the Pod's netns, it is impossible for external components to access and manipulate the Pod's network.
What are your thoughts on this?

@jiayoukun one option is from your component on the node to connect to the apiserver to get the Pods information, use an informer to watch the Pods that are only on the corresponding node. From the same component you open a connection to the container runtime through NRI to get the hook on RunPodSandbox, so you can get the low level details there. With the data of the informer and of the NRI plugin, you have everything you need, right now the details of the container runtimes are not leaked to the kubelet, to maintain the isolation provided by the CRI API

I understand your point, and that's what I've been doing all along. However, I believe that since kubelet has already established a connection with the container runtime and provided interface standards, developers should use the kubelet interface to obtain details from the container runtime, which would be the correct usage. Perhaps I only need to know one field in the container runtime details, but I would need to spend a lot of time understanding the interface details of the current container runtime, and there are multiple container runtimes, making it difficult to adapt to them all.
If kubelet standardizes the interface, I only need to interact with kubelet without worrying about what the container runtime is.