Os contêineres fornecem isolamento do processo em um sistema operacional compartilhado, em vez do isolamento do SO no hardware compartilhado que você obtém com as VMs. Como o sistema operacional é compartilhado, o sistema operacional host precisa ser capaz de executar os binários desejados. Você verá isso na arquitetura do mecanismo do docker e na arquitetura da imagem que deseja executar, eles devem ser compatíveis:
$ docker system info --format '{{.OSType}} {{.Architecture}}'
linux x86_64
$ docker image inspect busybox --format '{{.Os}} {{.Architecture}}'
linux amd64
Se você tentar executar uma arquitetura que não seja compatível com seu host, você receberá um erro porque o formato binário não é reconhecido pelo kernel:
$ docker image pull --platform arm64 busybox:latest
latest: Pulling from library/busybox
acafde7ce2e7: Pull complete
Digest: sha256:2a03a6059f21e150ae84b0973863609494aad70f0a80eaeb64bddd8d92465812
Status: Downloaded newer image for busybox:latest
$ docker run -it --rm busybox:latest echo hello
standard_init_linux.go:190: exec user process caused "no such file or directory"
As versões desktop do Docker e Windows Server do Docker incluem uma VM Linux sob a capa para executar contêineres Linux (os contêineres Linux são o ambiente de contêiner dominante, portanto, o Docker implementa isso usando o Linuxkit para simplificar o fluxo de trabalho do desenvolvedor). No Windows, há um comutador no mecanismo para usar a VM Linux ou executar contêineres nativos do Windows.
No entanto, o Docker não tem uma VM integrada para o Windows executar seus binários em um host Linux (já que o Windows não é open source e exigiria licenciamento), para que a única maneira de executar contêineres nativos do Windows Host do Windows.