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

[jiayoukun]

What would you like to be added?

I want to extend the gRPC interface in kubelet that retrieves pod resources to include an interface for obtaining the pod netns using the pod UID. This way, it would be possible to retrieve a pod object and perform operations on its netns after querying it using the pod UID.

Is this a good idea? Or are there perhaps better options?
Here is the proto path:
kubernetes\staging\src\k8s.io\kubelet\pkg\apis\podresources\v1\api.proto

Why is this needed?

In the current overlay network, there are many scenarios where the IP of a Pod's network interface needs to be forwarded in and out. This may involve using OVS, VPP, or other tools to perform IP SNAT, DNAT, and redirect operations.

For Pod objects, etcd does not store the netns of a Pod, and kubelet manages the sandbox state of each Pod using PodSandboxID. Both PodSandboxID and netns are not publicly accessible, which is very unfriendly to developers who want to manipulate the dynamic network of a Pod.

[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?