On 10/28/19 7:46 PM, Luis Pabon wrote:
> Hi all,
> Last Monday I discussed at the Kubernetes-CSI community meeting a PoC
> I was working on. The goal of the PoC is to create a single CSI
> controller side car to replace all other side cars on deployment. At
> Portworx, we realized that we had placed a lot of intelligence in our
> installer to determine which side-car with a specific version to use at
> a specific version of Kubernetes. We realized that separating the
> installer intelligence from the system would make it difficult to install.
> Instead, we propose csi-controller[1], a simple, single, intelligent
> side-car controller for CSI. It vendors in the sources for the side cars
> and interrogates Kubernetes and the CSI driver to determine which side
> car to load. We propose that this model makes it simpler to deploy,
> since it automatically determines what to do.
I can see this saving a little bit of RAM at runtime, and also saving
some hassle for CSI driver authors. I still prefer the model where
Kubernetes handles all of the sidecar stuff and CSI drivers are ignorant
about the existence of sidecars or RBAC or anything else they shouldn't
need to think about.
Does this combine all of the individual sidecar leader elections into
one winner-take-all leader election? That would also be a win as far as
I'm concerned.
> Please feel free to try it out in your deployment. Here is an example
> output from the csi-controller logs:
>
> I1028 23:17:05.204711 1 feature_gate.go:216] feature gates: &{map[]}
> I1028 23:17:05.204831 1 main.go:165] Version: v0.1-5-g0df2487
> W1028 23:17:05.222373 1 main.go:229] Skipping CSI NODE CRD check
> I1028 23:17:05.222407 1 connection.go:151] Connecting to
> unix:///csi/csi.sock
> I1028 23:17:05.224130 1 common.go:111] Probing CSI driver for
> readiness
> I1028 23:17:05.225893 1 main.go:251] Detected CSI driver
>
pxd.portworx.com <
http://pxd.portworx.com>
> I1028 23:17:05.229003 1 attacher.go:59] Kubernetes 1.13.x detected
> which requires the attacher process even if the CSI driver does not
> support it
> I1028 23:17:05.229217 1 provisioner.go:44] Driver
pxd.portworx.com
> <
http://pxd.portworx.com> supports provisioning
> I1028 23:17:05.231177 1 controller.go:680] Using saving PVs to API
> server in background
> I1028 23:17:05.231215 1 snapshotter.go:44] Driver
pxd.portworx.com
> <
http://pxd.portworx.com> supports snapshots
> <
http://pxd.portworx.com> supports resize
> I1028 23:17:05.243347 1 connection.go:151] Connecting to
> unix:///csi/csi.sock
> I1028 23:17:05.244133 1 common.go:111] Probing CSI driver for
> readiness
> I1028 23:17:05.247155 1 main.go:327] Using endpoints for leader
> election in Kubernetes version 1.13.x
> I1028 23:17:05.247363 1 leaderelection.go:241] attempting to
> acquire leader lease kube-system/csi-controller-leader-pxd-portworx-com...
> I1028 23:17:24.892907 1 leader_election.go:172] new leader
> detected, current leader: px-csi-ext-77ffb6d4f9-7ldtr
>
> I will be bringing this up at the Kubernetes SIG-Storage F2F in Kubecon
> San Diego for further discussion, but I would like to see if any of you
> can try it out on your systems and provide some feedback.
>
> - Luis
>
> [1]
https://github.com/lpabon/csi-controller
>
> --
> You received this message because you are subscribed to the Google
> Groups "kubernetes-sig-storage-wg-csi" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
kubernetes-sig-stora...@googlegroups.com
> <mailto:
kubernetes-sig-stora...@googlegroups.com>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/kubernetes-sig-storage-wg-csi/CAEvoFsEmBMyri3in1rk7xHGipj%3DZE%2B-XT0rDQE1FTe8UDeHyQA%40mail.gmail.com
> <
https://groups.google.com/d/msgid/kubernetes-sig-storage-wg-csi/CAEvoFsEmBMyri3in1rk7xHGipj%3DZE%2B-XT0rDQE1FTe8UDeHyQA%40mail.gmail.com?utm_medium=email&utm_source=footer>.