Thanks @saschagrunert for your reply!

I am using cri-o 1.31.0 and I do not see drop_infra_ctr in the configuration file /etc/crio/crio.conf.d/10-crio.conf, since this option is enabled by default, I think it is already enabled on my setup, so I guess that's why I do not see the infra containers.

Can you please let me know more about this option? From my understanding, If it is set to true and the pod does not have a private PID namespace, then the pod will be created without an infra container, right? But I checked the containers of my pods, each of them has its own PID namespace (different from /proc/1/ns/pid), so I think those pods should have been created with infra containers, right?

I think the main purpose of the infra container is to setup the network for the pod, so if a pod is created without an infra container, how will the pod's network be setup?

BTW, I see some warning messages related to pid and infra container in my cri-o logs when creating containers.

Jul 10 14:49:22 k8s crio[852]: time="2024-07-10 14:49:22.285920585+08:00" level=warning msg="Failed to get pid for pod infra container: container PID not initialized"
Jul 10 14:49:22 k8s crio[852]: time="2024-07-10 14:49:22.289989985+08:00" level=warning msg="Failed to get pid for pod infra container: container PID not initialized"

When CRI-O is running then the current config can be retrieved using:

> sudo crio status config | rg drop_infra_ctr
INFO[2024-07-10 11:14:33.377274628+02:00] Starting CRI-O, version: 1.30.3, git: unknown(clean)
    drop_infra_ctr = true

Generally speaking, with or without the option network setup should work as intended. We can spoof containers internaly to avoid having another OCI infra container. Pinning namespaces will be done with a little tool called pinns.

BTW, I see some warning messages related to pid and infra container in my cri-o logs when creating containers.

The logs are related to the NRI feature and should be muted with #8347