mirror of
https://github.com/k3s-io/kubernetes.git
synced 2026-01-25 14:35:43 +00:00
684df6e421
Automatic merge from submit-queue (batch tested with PRs 44124, 44510) Optimize the time taken to create Persistent volumes with VSAN storage capabilities at scale and handle VPXD crashes Currently creating persistent volumes with VSAN storage capabilities at scale is taking very large amount of time. We have tested at the scale of 500-600 PVC's and its more time for all the PVC requests to go from Pending state to Bound state. - In our current design we use a single systemVM - "kubernetes-helper-vm" as a means to create a persistent volume with the VSAN policy configured. - Since all the operations are on a single system VM, all requests on scale get queued and executed serially on this system VM. Because of this creating a high number of PVC's is taking very large time. - Since its a single system VM, all parallel PVC requests most of the time tend to take the same SCSI adapter on the system VM and also same unit number on the SCSI adapter. Therefore the error rate is high. Inorder to overcome these issues and to optimize the time taken to create persistent volumes with VSAN storage capabilities at scale we have slightly modified the design which is described below: - In this model, we create a VM on the fly for every persistent volume that is being created. Since all the reconfigure operations to create a disk with the VSAN policy configured are on their individual VM's, all of these PVC's request execute in parallel independent one other. - With this new design, there will no error rate at all. Also, we have overcome the problem of vpxd crashes and any other intermediate problems by checking type of the errors. Fixes https://github.com/vmware/kubernetes/issues/122, https://github.com/vmware/kubernetes/issues/124 @kerneltime @tusharnt @divyenpatel @pdhamdhere **Release note**: ```release-note None ```