kubernetes-csi / cluster-driver-registrar Goto Github PK
View Code? Open in Web Editor NEWDEPRECATED: Sidecar container that registers the CSI driver with the Kubernetes cluster
License: Apache License 2.0
DEPRECATED: Sidecar container that registers the CSI driver with the Kubernetes cluster
License: Apache License 2.0
I have observed same kind of issue in various kubernetes-csi project.
this happens because after the localization there are too much modifications done in the various directories.
I have observed same issue in this page also.
It has one broken link of the contributes cheat sheet
which needs to fix.
I will try to look in further csi repo as well and try to fix it as soon as I can
/kind bug
/assign
Why are we doing this in kubernetesRegister
? After the CSIDriverInfo object is created we should succeed and not continuously retry after sleep.
for {
verifyAndAddCSIDriverInfo(clientset, csiDriverName, spec)
time.Sleep(sleepDuration)
}
I have a feeling this hack may have been introduced as a workaround to having flaky object creation because of the flawed retry logic described in #6
The RBAC file was copied unmodified from driver-registrar. Is it still correct?
The introduction still refers to "external provisioner" (was already broken when creating that file initially for driver-registrar).
Which version of k8s and version of CSI is required to use cluster-driver-registrar? I guess it needs to be v1.13 and CSI v1.0? Can we have some documentations about this?
It should call the driver to get the driver capabilities to determine the skip attach value
If CSIDriverInfo is supposed to inform users of the cluster about currently installed drivers (is that the goal?), then there has to be a mechanism that ensures that the CSIDriverInfo for a CSI driver gets removed when removing the driver.
There is some support for this in the cluster-driver-registrar
:
cluster-driver-registrar/cmd/cluster-driver-registrar/k8s_register.go
Lines 75 to 91 in 0660c6c
pmem-csi uses cluster-driver-registrar (https://github.com/intel/pmem-CSI/blob/devel/deploy/kubernetes-1.13/pmem-csi-lvm.yaml#L122-L131), but in my experience the container gets stopped without cluster-driver-registrar removing the CSIDriverInfo for pmem-csi. Because the pod disappears shortly after termination, I've not been able to capture logs yet. Probably need to try with kubectl logs -f
...
docker pull quay.io/k8scsi/csi-cluster-driver-registrar:v1.0.2
not foud
readme file image tag is v1.0.2
but only exec docker pull quay.io/k8scsi/csi-cluster-driver-registrar:v1.0.1
Looks like verifyAndDeleteCSIDriverInfo
uses RetryOnConflict
to control retries on deleting API Objects, RetryOnConflict
is likely also used elsewhere.
However this is probably not the right thing to use as it only checks for the "Conflict Error" type returned from Update and retries when that is encountered, it does not retry for any other type of error and therefore if Delete
fails for any other error (such as API Server unreachable) this will not retry and we will have orphaned objects.
All instances of this should be changed to some other generic error handling function that has exponential backoff and jitter, please take a look at the recent changes made to retry logic for "CSINodeInfo" in "nodeinfomanager" in Kubernetes for a good example
cluster-driver-registrar design feels like it has some issues with respect to permissions and encourages what I think is an antipattern.
The trend of loading controllers into k8s and giving them enough access to self register crd's and other things has always felt a little bad. If your deploying with helm, helm is already dealing with registering objects and has all the permissions needed to register them. The permissions to do anything stop after its installed, so it can't be used to do further things to the cluster. This seems good. But, if you give a long running process permissions to do such things, then it can be used to do bad things later. Another facet is auditing. If its in helm, it can be easily parsed by a human and verified its safe before running. This is very hard to do if its buried inside code.
Our documentation says:
As of Kubernetes 1.14, this side car container is being refactored.
It has been two releases without any progress in the refactoring / redesign. The documentation also says that CSIDriver instances should be created "by installation manifest".
In addition, the last released cluster-driver-registrar does not support current v1beta1 CSIDriver, it still uses the v1alpha1 one based on CRD. Kubernetes e2e tests use image tagged as "tmp-test-1.14", which was never officially released.
I think it's time to officially declare that cluster-driver-registrar is deprecated.
Code-wise, these things need to be updated:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.