Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing cert-manager.io/revision-history-limit volume attributes for CSI-Driver #241

Open
coldnfire opened this issue Apr 23, 2024 · 0 comments

Comments

@coldnfire
Copy link


Description:
We have encountered an issue with the CSI-driver provided by cert-manager, specifically concerning the absence of the cert-manager.io/revision-history-limit volume attributes. This omission becomes problematic in our deployment scenarios where pods are rescheduled.

Problem:
Each time a pod equipped with cert-manager's CSI-driver is rescheduled, a new certificate request is generated. However, the historical data of previous certificate requests is preserved indefinitely due to the lack of an appropriate revision history limit. This behavior results in an unnecessary accumulation of old certificate requests, which can potentially lead to clutter and resource wastage in our Kubernetes environment.

Expected Behavior:
We expect the CSI-driver to incorporate the cert-manager.io/revision-history-limit volume attributes to limit the history of stored certificate requests. Ideally, this would allow us to specify the number of past certificate requests to retain, effectively managing the lifecycle of these objects and preventing the accumulation of outdated certificates.

Suggested Solution:
Please consider adding support for the cert-manager.io/revision-history-limit volume attributes in the CSI-driver configurations. This feature would provide significant control over the certificate request history, allowing us to maintain a cleaner and more efficient system.

Steps to Reproduce:

  1. Deploy a pod with a cert-manager CSI volume in a Kubernetes cluster.
  2. Reschedule the pod by deleting the existing pod or through deployment scaling.
  3. Observe the generation of a new certificate request while the previous requests remain preserved.

Impact:
The current behavior leads to operational inefficiencies and increased resource consumption, which could adversely affect systems with frequent pod rescheduling or deployments.

Environment:

  • Kubernetes version: v1.28.6
  • csi-driver: v0.8.0
  • Cert-manager version: 1.14.3
  • Cluster environment: vanilla

Additional Context:
Any further insights into how the CSI-driver handles certificate requests upon pod rescheduling would be appreciated. This could help us better understand the lifecycle management of certificates within our clusters.

Thank you for addressing this matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant