Skip to content

A common Kubelet Plugin Communication Establish Model #56944

@jiayingz

Description

Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature

What happened:
We are seeing the need for a common Kubelet plugin discovery model that can be used by different types of node-level plugins, such as device plugins, CSI, and CNI, to establish communication channels with Kubelet. During the design proposal reviews of device plugins and CSI, two models have been discussed: one is to have Kubelet export a registration service and plugins register themselves through this service; the other is for Kubelet to probe plugins under a canonical directory. We would like to get some consensus from the community on which model we should take in the future.

As a starting point of discussion, I wrote a draft doc comparing these two models: https://docs.google.com/document/d/1dtHpGY-gPe9sY7zzMGnm8Ywo09zJfNH-E1KEALFV39s
Please feel free to add comments either in the doc or in this issue.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version):
  • Cloud provider or hardware configuration:
  • OS (e.g. from /etc/os-release):
  • Kernel (e.g. uname -a):
  • Install tools:
  • Others:

Metadata

Labels

kind/featureCategorizes issue or PR as related to a new feature.sig/nodeCategorizes an issue or PR as relevant to SIG Node.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions