vsphere-csi-driver
vsphere-csi-driver copied to clipboard
kubernetes-sigs
Decouple vSphere Container Storage Plug-in from vSphere CPI.
Hi.
I'm new to this plugin. What does it mean exactly? Is this manual still valid https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-0AB6E692-AA47-4B6A-8CEA-38B754E16567.html? Do i need to install https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/release-$VERSION/releases/v$VERSION/vsphere-cloud-controller-manager.yaml or it's not needed anymore?
Kube version 1.22/1.23
Thanks, Indrek
Yes this manual - https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-0AB6E692-AA47-4B6A-8CEA-38B754E16567.html is still valid.
Previously there is a tight dependency of vSphere CSI on vSphere CPI to set the Provider ID on the node.
With Decouple vSphere Container Storage Plug-in from vSphere CPI, what it says is
- You can continue to install vSphere CPI on CSI.
- You can also install any external CPI that works with VMware on top on CSI.
Both of these scenario tend to work.
I am unable to access this - https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/release-$VERSION/releases/v$VERSION/vsphere-cloud-controller-manager.yaml. It says "404: Not Found" error. Can you check whether this is a valid link.
Irrespective of it, the above information holds true.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
From my understanding, this is ok since 2.5.1. I was able to activate CSI without vsphere cpi
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Can we get some clarification on this please?
Do I need a CPI or not? I currently have clusters that do not have a CPI and honestly don't need one, so I'd prefer not to have one at all if it actually isn't needed.
I really just want the CSI, but the documentation and the release notes seem to contradict each other on this particular topic.
@MalHaak I agree with you. It looks like this bug is already fixed, but cannot be closed because the docs are outdated.
/remove-lifecycle stale
We have removed dependency on ProviderID set on the Node by CPI from release 2.5. Closing this issue. Please refer to - https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.5/rn/vmware-vsphere-container-storage-plugin-25-release-notes/index.html
We have removed dependency on ProviderID set on the Node by CPI from release 2.5. Closing this issue. Please refer to - https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.5/rn/vmware-vsphere-container-storage-plugin-25-release-notes/index.html
So why isn't the rest of the documentation updated? This shouldn't be closed until the documentation ACTUALLY MAKES SENSE compared with the state of the project.
@MalHaak
We have just removed dependency on vSphere CPI which is setting ProviderID on the Node, which driver was using it.
We need to have some CPI or CCM installed on the cluster which executes Cloud Provider Interfaces. Refer to https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/cloud-provider/cloud.go#L164-L194 and https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/#running-cloud-controller-manager
We can not document that CSI only is sufficient on the cluster without CPI or CCM.
@divyenpatel Running CPI/CCM is out of scope of CSI. We use CSI without CPI and have no problem. Could you just remove any reference to CPI in the docs ?
@sathieu in your setup if you delete Node VM from vCenter server. How is the associated node object getting removed from the API server without CCM executing InstanceExistsByProviderID?
Can you point me to any document or spec which says CSI should only be installed without external CCM on the k8s cluster? cc: @xing-yang
@divyenpatel Node lifecycle is more a cluster-api concern than a vsphere-csi concern. And this is needed even without vsphere-csi.
Can you point me to any document or spec which says CSI should only be installed without external CCM on the k8s cluster?
I don't say "should only be installed without external CCM", but "could be installed without CPI/CCM".