Change:
continue } <del> pvName := pvc.Spec.VolumeName // TODO - the actual handling of unbound PVCs will be fixed by late binding design. if pvName == "" { klog.V(4).Infof("Persistent volume had no name for claim %s/%s", namespace, pvcName) </del> <ins> driverName, volumeHandle := c.getCSIDriver(pvc) // if we can't find driver name or volume handle - we don't count this volume. if driverName == "" || volumeHandle == "" { </ins> continue } <del> pv, err := c.pvInfo.GetPersistentVolumeInfo(pvName) if err != nil { klog.V(4).Infof("Unable to look up PV info for PVC %s/%s and PV %s", namespace, pvcName, pvName) continue } csiSource := pv.Spec.PersistentVolumeSource.CSI if csiSource == nil { klog.V(4).Infof("Not considering non-CSI volume %s/%s", namespace, pvcName) continue } driverName := csiSource.Driver </del> volumeLimitKey := volumeutil.GetCSIAttachLimitKey(driverName) <del> result[csiSource.VolumeHandle] = volumeLimitKey </del> <ins> result[volumeHandle] = volumeLimitKey </ins> } return nil } <ins> func (c *CSIMaxVolumeLimitChecker) getCSIDriver(pvc *v1.PersistentVolumeClaim) (string, string) { pvName := pvc.Spec.VolumeName namespace := pvc.Namespace pvcName := pvc.Name placeHolderCSIDriver := "" placeHolderHandle := "" if pvName == "" { klog.V(5).Infof("Persistent volume had no name for claim %s/%s", namespace, pvcName) return c.getDriverNameFromSC(pvc) } pv, err := c.pvInfo.GetPersistentVolumeInfo(pvName) if err != nil { klog.V(4).Infof("Unable to look up PV info for PVC %s/%s and PV %s", namespace, pvcName, pvName) // If we can't fetch PV associated with PVC, may be it got deleted // or PVC was prebound to a PVC that hasn't been created yet. // fallback to using StorageClass for volume counting return c.getDriverNameFromSC(pvc) } csiSource := pv.Spec.PersistentVolumeSource.CSI if csiSource == nil { klog.V(5).Infof("Not considering non-CSI volume %s/%s", namespace, pvcName) return placeHolderCSIDriver, placeHolderHandle } return csiSource.Driver, csiSource.VolumeHandle } func (c *CSIMaxVolumeLimitChecker) getDriverNameFromSC(pvc *v1.PersistentVolumeClaim) (string, string) { namespace := pvc.Namespace pvcName := pvc.Name scName := pvc.Spec.StorageClassName placeHolderCSIDriver := "" placeHolderHandle := "" if scName == nil { // if StorageClass is not set or found, then PVC must be using immediate binding mode // and hence it must be bound before scheduling. So it is safe to not count it. klog.V(5).Infof("pvc %s/%s has no storageClass", namespace, pvcName) return placeHolderCSIDriver, placeHolderHandle } storageClass, err := c.scInfo.GetStorageClassInfo(*scName) if err != nil { klog.V(5).Infof("no storage %s found for pvc %s/%s", *scName, namespace, pvcName) return placeHolderCSIDriver, placeHolderHandle } // We use random prefix to avoid conflict with volume-ids. If PVC is bound in the middle // predicate and there is another pod(on same node) that uses same volume then we will overcount // the volume and consider both volumes as different. volumeHandle := fmt.Sprintf("%s-%s/%s", c.randomVolumeIDPrefix, namespace, pvcName) return storageClass.Provisioner, volumeHandle } </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: Volume binding mode doesn't consider the volume attach limit per node. What you expected to happen: volume binding mode should have respected the attach limit, similar to binding mode. How to reproduce it (as minimally and precisely as possible): In CSI driver, configured the volume-attach limit to 1 per node on a 3 node cluster. In volume binding mode, only 3 pods with 3 PV/PVCs runs. In binding mode, all 5 pods runs with 5PV/PVCs on 3 node cluster. (Actually 4 pods scheduled on 1 node and 1 on other node, 3rd didn't have any pod scheduled) Anything else we need to know?: I was able to reproduced it with minimal node and configuration, and also hit this for stress case with 100 Volume limit and 500 pods running on the 5 mode cluster. Environment: Kubernetes version (use ): ~ kubectl version Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-10-30T21:39:38Z", GoVersion:"go1.11.1", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: On-prem linux server OS (e.g. from /etc/os-release): Centos 7Kernel (e.g. ): 3.10.0 Install tools: Others:
cc
/sig storage
/assign Currently the predicate PVCs that are not bound. It should lookup the storageclass to get the provisioner/driver name. This solution will require a StorageClass object is even if you don't use dynamic provisioning.

I had a thought that it wouldn't be so simple to count unbound PVCs of other pods since binding is still in progress, but I think it's fine actually. We only count other pods that have been assigned to the same node. Those pods are assigned to the node AND still unbound because of one of these reasons: It's actually been scheduled to the node and someone manually came in and unbound the PVC: unlikely and an unsupported sequence since we implemented StorageProtection The Pod was initially created with nodeName already set, bypassing the scheduler The Pod is going to be scheduled (it's been assumed), and it's currently going through binding. This is normal with delayed binding. Either way, the fact that the Pod's nodename is set to this node means that the pod should be counting towards the node's limit.
Hmm, so after opening the PR that fixes this, I realize that - from storageclass we don't really know if the volume we are evaluating is CSI volume or not. I think a similar problem exists for existing predicate though. Like AzureDisk predicate does not know if PVC it is over counting is of type AzureVolume or not. So, I suspect that those 4 hardcoded predicates are counting all delayed binding volumes.
if the storageclass.provisioner name is not found, can we just ignore it?
I think we can ignore it. The PR currently does that.