The general insistence of some security standards on anti-malware software running on every host, without exception, is a bit... dubious in a lot of cases (IMO).
That said, if it's a standard you need to comply with you need to either have a control or a well thought through mitigating control if you can't comply fully.
Here there's two aspects to the issue. First is scanning the images themselves, second is scanning data placed into the images (for example user uploads).
The second case is actually easier to handle. as containers are ephemeral you'll be mounting volumes from outside the container for any data you need to be persistent. So you can just enable anti-malware on your external data stores (if you have any) and that addresses the issue here.
For the files from the container images themselves, I'd say that scanning running images (which would have a performance hit) can be avoided reasonably with some mitigating controls :-
- Images should be scanned in the registry on build and periodically after that to ensure that they're not running outdated, vulnerable packages
- As images are meant to be ephemeral, they should be able to be mounted with a read only root file system (via
readOnlyRootFilesystem: true
in the security context for the containers). With this configuration the attacker can't write files inside the running container, so there's no real need for A-V scanning.