Does the kubelet expect a stop for pod infra container or does it need a separate pod stop event?

CRI events are generated per container, which also includes infra container. If for some reason infra container runs to completion the ContainerEventType_CONTAINER_STOPPED_EVENT will be generated by crio in handleExit() function. This event will be received and forwarded to the syncLoop in Kubelet in the form of PodLifeCycle event.

This PR is fixing the issue where we were incorrectly generating ContainerEventType_CONTAINER_STOPPED_EVENT while intentionally stopping the infra container rather than generating it when that infra container runs to completion (for which the relevant code in handleExit() already existed as mentioned above)

In retrospect, I feel we should have named ContainerEventType_CONTAINER_STOPPED_EVENT as ContainerEventType_CONTAINER_EXITED_EVENT because it is generating some confusion with action that is stopping the container (e.g. #6531 (comment))

I think we may need to have a call to this when the infra container is dropped (can tell with podInfraContainer.Spoofed() being true). This is because a spoofed container (dropped infra) doesn't have a process that can exit, so it's possible the kubelet will be waiting for a CONTAINER_STOPPED_EVENT for that infra container forever

@haircommander do you have a reproducer for this scenario?

if you create a pod that doesn't share a pod level pid namespace (shareProcessNamespace: false) then the infra container will be spoofed

Thanks @haircommander , I added a comment describing this scenario in the code.

@sairameshv can you only call this
if podInfraContainer.Spoofed()?

otherwise, there will be two stopped events when the infra container is not dropped (one from handleExit, and one from here)

Yeah @haircommander , Updated.