Safe deletion of Kyma Clusters [EPIC]

[pbochynski]

Description

Instead of deletion we can hibernate cluster and delete it few days later. Accidental deletion can be recovered. Such cluster is not reconciled (Kyma resource can be deleted). Deletion of Kyma resource should not cause module deletion - it is just opt out from lifecycle management.

Note: customer data is still in the hibernated cluster so we should not keep it too long and we need to make sure we do not violate data privacy policies

Implementation idea:

• cluster resource could be in the deleting state for longer period and the operator will remove shoot and finalizer after defined timeout
• recovery would be a manual process: copy the resource, remove finalizer and recreate the resource from the copy

Reasons We should protect our customers as much as possible against unintentional or malicious actions that cause data loss.

Attachments

Related to

• Cross service consumption

[tobiscr]

TODO: We have clarify the retention time for hibernated clusters as they are also charged by Gardener (Base-fee).

[tobiscr]

Hibernation was quite unstable in Gardener in the past. We have to create an POC which verifies how reliable the hibernation feature works.

[tobiscr]

Points to clarify:

• [ ] how to react if hibernation fails by Gardener
• [ ] we have to add new cluster state in RuntimeCR (e.g. disposed)
• [ ] housekeeping job required to deleted disposed cluster when retention period is reached
  • [ ] Agreement of retention time happened
• [ ] subscription-cleanup job has to consider clusters who are hibernated - subscription cannot be reused until the cluster got finally deleted
• [ ] verify metering of KMC component: hibernated clusters cannot be charged anymore