-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Open
Labels
help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.kind/api-changeCategorizes issue or PR as related to adding, removing, or otherwise changing an APICategorizes issue or PR as related to adding, removing, or otherwise changing an APIkind/featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.priority/backlogHigher priority than priority/awaiting-more-evidence.Higher priority than priority/awaiting-more-evidence.triage/acceptedIndicates an issue or PR is ready to be actively worked on.Indicates an issue or PR is ready to be actively worked on.
Description
What would you like to be added (User Story)?
As a operator i would like to be able to configure a time after machines are getting replaced automatically for testing and security reasons.
Detailed Description
Problem Statement:
Regularly replacing machines help in testing application behavior during rolling updates and ensures machines are refreshed periodically, especially important after security incidents.
Proposed Solution:
Implement rolloutBefore.machineExpiry{Minutes,Hours,Days} parameter within the Cluster API (like rolloutBefore.certificatesExpiryDays implemented for KCP), allowing users to specify the maximum time a machine should exist before being automatically replaced.
Benefits:
- Testing Rolling Updates: Simplifies the process of regularly testing how applications behave during rolling updates.
- Security and Compliance: Ensures machines are periodically replaced, reducing the risk of lingering vulnerabilities and ensuring machines are clean post-security incidents.
- Operational Efficiency: Automates a routine maintenance task, reducing manual workload and the potential for human error.
Impact:
- This feature would be highly valuable for IT operations teams managing Kubernetes clusters, particularly those with strict compliance and security requirements.
- It enhances cluster maintenance workflows, contributing to overall system reliability and security.
Anything else you would like to add?
Current workarounds:
- setting
spec.rolloutAfterperiodically via CronJob for MachineDeployment - running
clusterctl alpha rollout restart machinedeployment/my-md-0periodically
Label(s) to be applied
/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.
Metadata
Metadata
Assignees
Labels
help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.kind/api-changeCategorizes issue or PR as related to adding, removing, or otherwise changing an APICategorizes issue or PR as related to adding, removing, or otherwise changing an APIkind/featureCategorizes issue or PR as related to a new feature.Categorizes issue or PR as related to a new feature.priority/backlogHigher priority than priority/awaiting-more-evidence.Higher priority than priority/awaiting-more-evidence.triage/acceptedIndicates an issue or PR is ready to be actively worked on.Indicates an issue or PR is ready to be actively worked on.