vCluster - Create fully functional virtual Kubernetes clusters - Each vcluster runs inside a namespace of the underlying k8s cluster. It's cheaper than creating separate full-blown clusters and it offers better multi-tenancy and isolation than regular namespaces.
What issue type does this pull request address? (keep at least one, remove the others)
/kind bugfix
What does this pull request do? Which issues does it resolve? (use resolves #<issue_number> if possible)
resolves ENG-4924
Please provide a short message that should be published in the vcluster release notes
Fixed an issue where the vcluster syncer would mistakenly re-create a resource when reconciling the update event that adds the deletionTimestamp
What else do we need to know?
Scenario
The syncer incorrectly re-creates a resource while it's being deleted. The sequence of events observed:
A replicationcontroller with a terminationGracePeriod == 0 is deleted and its pods are garbage collected
An update event that sets the deletionTimestamp is queued
An delete event for the same resource is queued
Syncer reconciles the update event but is unable to load the resource because it's already deleted. This triggers a call to SyncToVirtual(), which mistakenly re-creates the resource.
This scenario occurs more frequently with pods, but the solution has been made generic in case it occurs with different resource kinds.
Solution
Add a PendingDelete event type to communicate that an update event occurred to a virtual resource being deleted. If the SyncToVirtual flow is reached by an event where the source == Virtual and the type == PendingDelete, then skip calling SyncToVirtual.
What issue type does this pull request address? (keep at least one, remove the others) /kind bugfix
What does this pull request do? Which issues does it resolve? (use
resolves #<issue_number>
if possible) resolves ENG-4924Please provide a short message that should be published in the vcluster release notes Fixed an issue where the vcluster syncer would mistakenly re-create a resource when reconciling the update event that adds the
deletionTimestamp
What else do we need to know?
Scenario
The syncer incorrectly re-creates a resource while it's being deleted. The sequence of events observed:
terminationGracePeriod
== 0 is deleted and its pods are garbage collectedSyncToVirtual()
, which mistakenly re-creates the resource.This scenario occurs more frequently with pods, but the solution has been made generic in case it occurs with different resource kinds.
Solution
Add a
PendingDelete
event type to communicate that an update event occurred to a virtual resource being deleted. If theSyncToVirtual
flow is reached by an event where the source ==Virtual
and the type ==PendingDelete
, then skip calling SyncToVirtual.