github-personal/proxmox-cloud-controller-manager
1
0
Fork 0
mirror of https://github.com/outbackdingo/proxmox-cloud-controller-manager.git synced 2026-01-27 10:20:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: add faq

Browse Source 
Add fast answers to common questions

Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
This commit is contained in:
Serge Logvinov
2024-09-27 09:42:46 +03:00
committed by Serge
parent 7ec261758c
commit 87baa50bf0
3 changed files with 22 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -79,6 +79,10 @@ Support controllers:
* cloud-node-lifecycle * cloud-node-lifecycle
* Cleans up node resource when Proxmox VM is deleted. * Cleans up node resource when Proxmox VM is deleted.
## FAQ
See [FAQ](docs/faq.md) for answers to common questions.
## Contributing ## Contributing
Contributions are welcomed and appreciated! Contributions are welcomed and appreciated!

8
docs/faq.md Normal file
View File

@@ -0,0 +1,8 @@
# Fast answers to common questions
## Dose CCM support online VM migration?
No.
Proxmox CCM uses [Cloud-Provider](https://github.com/kubernetes/cloud-provider.git) framework, which does not support label updates after the node initialization.
Kuernetes has node drain feature, which can be used to move pods from one node to another.

11
docs/install.md
View File

@@ -185,7 +185,7 @@ Node object has values:
* `alpha.kubernetes.io/provided-node-ip` annotation with the node IP. * `alpha.kubernetes.io/provided-node-ip` annotation with the node IP.
* `nodeInfo` field with system information. * `nodeInfo` field with system information.
2. CCM detects the new node and sends a request to the Proxmox API to get the VM configuration. Like VMID, hostname, etc. 2. CCM detects the new node and sends a request to the Proxmox API to get the VM configuration. Like VMID, hostname, etc.
3. CCM updates the `Node` object with labels and taints based on the VM configuration. 3. CCM updates the `Node` object with labels, taints and `providerID` field. The `providerID` is immutable and has the format `proxmox://$REGION/$VMID`, it cannot be changed after the first update.
4. CCM removes the `node.cloudprovider.kubernetes.io/uninitialized` taint. 4. CCM removes the `node.cloudprovider.kubernetes.io/uninitialized` taint.
If `kubelet` does not have `cloud-provider=external` flag, kubelet will expect that no external CCM is running and will try to manage the node lifecycle by itself. If `kubelet` does not have `cloud-provider=external` flag, kubelet will expect that no external CCM is running and will try to manage the node lifecycle by itself.
@@ -194,3 +194,12 @@ So, CCM will skip the node and will not update the `Node` object.
If you modify the `kubelet` flags, it's recommended to check all workloads in the cluster. If you modify the `kubelet` flags, it's recommended to check all workloads in the cluster.
Please __delete__ the node resource first, and __restart__ the kubelet. Please __delete__ the node resource first, and __restart__ the kubelet.
The steps to troubleshoot the Proxmox CCM:
1. scale down the CCM deployment to 1 replica.
2. set log level to `--v=5` in the deployment.
3. check the logs
4. check kubelet flag `--cloud-provider=external`, delete the node resource and restart the kubelet.
5. check the logs
6. wait for 1 minute. If CCM cannot reach the Proxmox API, it will log the error.
7. check tains, labels, and providerID in the `Node` object.