Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
K
k3s
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Registry
Registry
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Jacklull
k3s
Commits
79056292
Commit
79056292
authored
Sep 21, 2018
by
Renaud Gaubert
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update pluginwatcher doc
parent
63436ab4
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
59 additions
and
14 deletions
+59
-14
README.md
pkg/kubelet/util/pluginwatcher/README.md
+59
-14
No files found.
pkg/kubelet/util/pluginwatcher/README.md
View file @
79056292
# Plugin Registration Service
This folder contains a utility, pluginwatcher, for Kubelet to register
This folder contains a utility, pluginwatcher, for Kubelet to register
different types of node-level plugins such as device plugins or CSI plugins.
different types of node-level plugins such as device plugins or CSI plugins.
It discovers plugins by monitoring inotify events under the directory returned by
It discovers plugins by monitoring inotify events under the directory returned by
kubelet.getPluginsDir(). Lets refer this directory as PluginsSockDir.
kubelet.getPluginsDir(). We will refer to this directory as PluginsDir.
For any discovered plugin, pluginwatcher issues Registration.GetInfo grpc call
to get plugin type, name and supported service API versions. For any registered plugin type,
Plugins are expected to implement the gRPC registration service specified in
pluginwatcher calls the registered callback function with the received plugin
pkg/kubelet/apis/pluginregistration/v
*
/api.proto.
name, supported service API versions, and the full socket path. The Kubelet
component that receives this callback can acknowledge or reject the plugin
## Plugin Discovery
according to its own logic, and use the socket path to establish its service
communication with any API version supported by the plugin.
The pluginwatcher service will discover plugins in the PluginDir when they
place a socket in that directory or, at Kubelet start if the socket is already
there.
This socket filename should not start with a '.' as it will be ignored.
## gRPC Service Lifecycle
For any discovered plugin, kubelet will issue a Registration.GetInfo gRPC call
to get plugin type, name, endpoint and supported service API versions.
Kubelet will then go through a plugin initialization phase where it will issue
Plugin specific calls (e.g: DevicePlugin::GetDevicePluginOptions).
Once Kubelet determines that it is ready to use your plugin it will issue a
Registration.NotifyRegistrationStatus gRPC call.
If the plugin removes its socket from the PluginDir this will be interpreted
as a plugin Deregistration
Here are the general rules that Kubelet plugin developers should follow:
-
Run as 'root' user. Currently creating socket under PluginsSockDir, a root owned directory, requires
plugin process to be running as 'root'.
-
Implements the Registration service specified in
## gRPC Service Overview
pkg/kubelet/apis/pluginregistration/v
*
/api.proto.
Here are the general rules that Kubelet plugin developers should follow:
-
Run plugin as 'root' user. Currently creating socket under PluginsDir, a root owned
directory, requires plugin process to be running as 'root'.
-
The plugin name sent during Registration.GetInfo grpc should be unique
-
The plugin name sent during Registration.GetInfo grpc should be unique
for the given plugin type (CSIPlugin or DevicePlugin).
for the given plugin type (CSIPlugin or DevicePlugin).
-
The socket path needs to be unique within one directory, in normal case,
-
The socket path needs to be unique within one directory, in normal case,
each plugin type has its own sub directory, but the design does support socket file
each plugin type has its own sub directory, but the design does support socket file
under any sub directory of PluginSockDir.
under any sub directory of PluginSockDir.
...
@@ -32,3 +53,27 @@ Here are the general rules that Kubelet plugin developers should follow:
...
@@ -32,3 +53,27 @@ Here are the general rules that Kubelet plugin developers should follow:
-
For an example plugin implementation, take a look at example_plugin.go
-
For an example plugin implementation, take a look at example_plugin.go
included in this directory.
included in this directory.
# Kubelet Interface
For any kubelet components using the pluginwatcher module, you will need to
implement the PluginHandler interface defined in the types.go file.
The interface is documented and the implementations are registered with the
pluginwatcher module in kubelet.go by calling AddHandler(pluginType, handler).
The lifecycle follows a simple state machine:
Validate -> Register -> DeRegister
^ +
| |
+--------- +
The pluginwatcher calls the functions with the received plugin name, supported
service API versions and the endpoint to call the plugin on.
The Kubelet component that receives this callback can acknowledge or reject
the plugin according to its own logic, and use the socket path to establish
its service communication with any API version supported by the plugin.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment