Владамир Мукашев

Я обычно делаю один образ с кроном и php, но запускаю его в двух разных контейнерах - fpm и cron. Для крона еще в докерфайле создаю скриптик, который помимо запуска самого крона будет записывать переменные окружения в создаваемый на лету .env файл, так как настоящий .env у меня в докеригноре. Выглядит это так:

// ...команды настройки php

RUN echo 'printenv | grep  \
    -e APP_ENV \
    -e DATABASE_URL \
     > ./.env && cron -f -L 15' > ${APP_DIR}/cron-starter

RUN chmod 700 ${APP_DIR}/cron-starter

Это нужно потому что докер запуская команды не передает им переменные окружения, а все современные фреймворки конфигурируются как раз с их помощью.

Ничего дикого в кроне на хосте нету (особенно если это не крон, а systemd-таймер), как и в отдельном сервисе-планировщике. А если хотите, чтобы было прям по фэншую - юзайте Kubernetes + CronJobs.

Если честно - не понимаю смысла вопроса, вы же изучили теорию
сделайте так, как будет удобно вам - вам же с этим жить
а вообще надо исходить из того чем занимается cron задачи - где-то, ради изоляции потребления ресурсов, лучше вынести крон во второй контейнер, а где-то вы решите запихать его внутрь контейнера приложения
По поводу запуска на хосте - сервисы контейнеризации обычно не дают доступ к хосту