Commits on May 9, 2023

1. Change destroy operation to use foreground cascading delete …

   By default, Kubernetes uses "background cascading deletion" (BCD) to clean up resources. This works in most cases with the eventual consistency model as resources are garbage collected. However, there are cases where BCD can lead to stuck resources due to race conditions between dependents. A concrete example is an application Deployment that includes a volume mount managed by a Container Storage Interface (CSI) driver. The underlying Pods managed by this Deployment depend on the CSI driver to unmount the volume on teardown, and this process can take some time. Thus, if a Namespace containing both the CSI driver and the application Deployment is deleted, it is possible for the CSI driver to be removed before it has finished tearing down the application Pods, leaving them stuck in a "Terminating" state.
   
   A reliable way to avoid this race condition is by using "foreground cascading deletion" (FCD) instead. FCD blocks deletion of the parent resource until any children have been deleted. In the previous example, the application Deployment resource would not be deleted until all of the underlying Pods had unmounted the CSI volume and finished terminating. Once the application Deployment is gone, then Pulumi can safely clean up the CSI driver as well.
   
   One downside of this approach is that resource deletion can take longer to resolve since Kubernetes is explicitly waiting on the delete operation to complete. However, this increases reliability of the delete operation by making it less prone to race conditions, so the tradeoff seems worth it.

   

   lblackstone committed May 9, 2023
   Configuration menu

   • View commit details
   • Copy full SHA for 51cffd9
   • Browse repository at this point

   Copy the full SHA

   51cffd9 View commit details

   Browse the repository at this point in the history