Docker Engine 插件模型和 k8s 插件模型区别

Docker Engine 插件是一个web服务，
插件类型有 authorization, volume and network driver plugins 3种。 因为插件是web服务，所以插件要早于docker 服务之前启动，至少在调用该插件前启动。
当docker daemon通过命令行要激活插件，比如 docker network  create  net1 -d ABC，docker daemon 首先寻找相应配置文件或者sock文件，寻找文件为/run/docker/plugins，/etc/docker/plugins ，/usr/lib/docker/plugins 里面相应的ABC .sock  .spec .json 文件。并从文件中 解析出web服务端地址，发送激活命令，然后在后续命令进行相应的动作。
这里以一个ovs插件为例子：
https://github.com/liuliuzi/docker-ovs-plugin
（该代码fork自gopher-net/docker-ovs-plugin，修改了依赖原来dknet到 docker/go-plugins-helpers ，同时解决插件重启后无法获取该插件之前创建网络信息的bug）
1，当该插件启动时，在/var/run/docker/plugins 文件下生成ovs.sock
2，到执行docker network  create abc -d ovs， docker daemon 查找到sock文件，并发送激活的 GetCapabilities  http请求，获取插件类型和使用范围。然后发送Create network request
3， 到执行docker run -itd --network abc busybox， docker daemon  依次发送Create endpoint request 和 Join request至插件，


k8s 插件是一个二进制可执行程序，kublet 通过子进程调用该插件。他可以独自处理k8s的请求，也可以从服务端获取相应调配信息，当然最后的执行还是由该二进制程序执行。具体可看前两篇博文。


总的来说，两种插件都是独立的二进制可执行文件，不同的是 Docker Engine 插件 是一个web服务端，Docker Engine通过http 请求调用， k8s 插件是被k8s 直接通过shell 子进程形式调用。另外Docker Engine 插件毕竟是原生插件，是完全跟随容器的生命周期，k8s 插件偏外部，在容器启动后再进行的操作。