Comments (12)
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.
from kubernetes.
/sig api-machinery
from kubernetes.
/sig node
/remove-sig api-machinery
from kubernetes.
@jiayoukun you can use the container runtime directly for this using NRI plugins, that is supported by containerd and crio, see containerd/nri#82
from kubernetes.
/sig network
from kubernetes.
@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?
from kubernetes.
/assign @thockin
from kubernetes.
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?
from kubernetes.
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?
from kubernetes.
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
from kubernetes.
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.
from kubernetes.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale
- Close this issue with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
from kubernetes.
Related Issues (20)
- integrate kubelet with the systemd watchdog HOT 7
- A DaemonSet pod environment variable did not inject service information HOT 9
- topologySpreadConstraints for availability zone in aws is not working as expected HOT 2
- API Server responds 200 OK, but not properly handling the request HOT 3
- Versioned feature gate lint error need to provide clear directions on what to do HOT 5
- Need emulation version guidance on how to perserve disabled feature gate tests for LockToDefault features HOT 6
- Failure cluster [c85e0cdc...] `Cluster size autoscaling` HOT 3
- setHostnameAsFQDN: true but the hostname is just pod name HOT 4
- Getting Unknown Field error for "podLogsDir" HOT 5
- Upgrade failed when using patches directory HOT 3
- `kubectl` handling of `node-role.kubernetes.io/control-plane` label encourages poor practice HOT 7
- PodScheduled status.conditions field does not have an entry in `managedFields` for Pod HOT 3
- Add validation that `--emulation-version=<version>` >= `DefaultKubeBinaryVersion`-3 HOT 7
- [Flaking Tests] Kubernetes e2e suite.[It] [sig-node] [Feature:GPUDevicePlugin] [Serial] Test using a Pod should run gpu HOT 14
- Failure cluster [00391c9f...] `ci-kubernetes-e2e-gke-prod-*-conformance` leaked to public bucket? HOT 3
- [Flaky Test] Kubernetes e2e suite.[It] [sig-cli] Kubectl client Kubectl validation should create/apply an invalid/valid CR with arbitrary-extra properties for CRD with partially-specified validation schema HOT 4
- [Flaky Test] k8s.io/kubernetes/pkg/kubelet/volumemanager/reconciler.reconciler HOT 4
- Pods Not Scaling Up with HPA Despite CPU Utilization Exceeding Target HOT 3
- /sig <API Machinery> The kubeadm init can't start a healthy API server HOT 5
- terminationMessagePolicy: "File" not effective HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kubernetes.