One thing to add to the AWS part: the namespace label only gets you a gate if the target group uses IP targets. The Load Balancer Controller registers Instance targets by default, and its readiness gate docs say the gate only works with target-type: ip, because in instance mode the backend is the node, not the pod. So on an Ingress without alb.ingress.kubernetes.io/target-type: ip, the label is set, no gate is injected, and the start-of-life race you describe is still there. Your kubectl get pod -o yaml check would catch that, which is a good reason to keep it on the checklist.
I'd also put the whole checklist under one test: keep a steady request stream going through the load balancer while you run kubectl rollout restart, and count the non-2xx responses. Zero across a few restarts is the evidence the settings work, and the timing of any errors tells you whether the start or the end of a pod's life is still leaking.
One thing to add to the AWS part: the namespace label only gets you a gate if the target group uses IP targets. The Load Balancer Controller registers Instance targets by default, and its readiness gate docs say the gate only works with target-type: ip, because in instance mode the backend is the node, not the pod. So on an Ingress without alb.ingress.kubernetes.io/target-type: ip, the label is set, no gate is injected, and the start-of-life race you describe is still there. Your kubectl get pod -o yaml check would catch that, which is a good reason to keep it on the checklist.
I'd also put the whole checklist under one test: keep a steady request stream going through the load balancer while you run kubectl rollout restart, and count the non-2xx responses. Zero across a few restarts is the evidence the settings work, and the timing of any errors tells you whether the start or the end of a pod's life is still leaking.