Summary
The host side of a tenant's veth is named per VPC and attachment rather than per container. During a rolling replace the incoming pod's attach sees the outgoing pod's still-live veth, treats it as debris from a failed earlier attempt, and deletes it. The replacement comes up with only a loopback while Kubernetes reports it Running with an address, so the workload is off the network with nothing to show why.
Any rollout restart of a workload attached to a VPC hits this, since a rolling replace overlaps the new attach with the old teardown by design. Scaling to zero and waiting for termination before scaling back avoids it.
Outcome
A Deployment attached to a VPC can be restarted normally and the replacement pod comes up with a working interface.
Related to #332, which is the same per-attachment keying biting a different resource.
Summary
The host side of a tenant's veth is named per VPC and attachment rather than per container. During a rolling replace the incoming pod's attach sees the outgoing pod's still-live veth, treats it as debris from a failed earlier attempt, and deletes it. The replacement comes up with only a loopback while Kubernetes reports it Running with an address, so the workload is off the network with nothing to show why.
Any rollout restart of a workload attached to a VPC hits this, since a rolling replace overlaps the new attach with the old teardown by design. Scaling to zero and waiting for termination before scaling back avoids it.
Outcome
A Deployment attached to a VPC can be restarted normally and the replacement pod comes up with a working interface.
Related to #332, which is the same per-attachment keying biting a different resource.