You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
serialize SecurityGroup ingress reconciles per SecurityGroup
Concurrent reconciles of the same SecurityGroup each perform a
non-atomic read-modify-write sequence: fetch the current rules, diff
them against the desired permissions, then authorize/revoke. When two
reconciles interleave, one can diff against a snapshot taken while the
other was mid-mutation and revoke rules without granting replacements,
leaving the SecurityGroup without any of the controller-managed rules.
With the shared backend SecurityGroup feature this removes every
ALB-to-target ingress rule on the cluster SecurityGroup at once,
failing health checks and client traffic for all load balancers until
the deferred TargetGroupBinding reconciler restores the rules (~30
minutes after a controller restart).
Observed in production during Fargate maintenance: endpoint churn on
the TargetGroupBinding defining the aggregated port-range boundary
produced two concurrent reconciles; CloudTrail shows the controller
authorizing tcp/3000-3008, revoking tcp/3000-8025, then 45 seconds
later revoking tcp/3000-3008 again with no replacement grant.
Serialize ReconcileIngress per SecurityGroup ID with a keyed mutex held
across the fetch and the mutations, so every reconcile diffs against
post-mutation state. Reconciles of different SecurityGroups are not
serialized against each other.
0 commit comments