Under certain conditions a CEP can be kept for unmanaged pods. This can happen, for example, in case Cilium stops running and the infra container of a pod is restarted on a node where another CNI besides Cilium starts managing it.

The GC of the CEP will not happen because a) the ownerReference of the CEP is the same since the pod is the same and b) Cilium Operator is only GC CEPs if the pod does not exist, which is also not the case. Both a) and b) are not sufficient as the only field that changed from the pod status was the pod IP.

There are two potential fixes for this

1. Watch for CEPs, which we already do under [1] and mark for deletion CEPs that are not running on the cilium agent. We can't delete them immediately since during the restore process the local agent will only start restoring the local endpoints after all state is synchronized with Kubernetes [2]. Thus, the CEPs can only be deleted after the endpoint restoration.

2. Verify if the IP addresses of the pod and the CEP are the same, if they are not, mark the CEP for deletion. This process can be executed from the cilium-operator. Similarly to case 1., we shouldn't delete the CEPs immediately at the risk of an endpoint having its IP address changed by a restart of the infra container where Cilium would be the CNI managing the pod. Cilium would likely re-create the CEP with the same name and the most up to date IP address but the IP address of the Pod Status might take a couple more seconds to be updated. If we delay the CEP deletion for maybe 1 minute we could guarantee the IP address of the Pod would be up to date and the CEP deletion would not happen unnecessarily.

[1]

[2]