Nurbol Suleimenov

Контейнеры используют тоже ядро, что и хост

Тут chupasaurus прав

Но в остальном ...

Если вы не имели в виду под "другими ОС" разные дистрибутивы Linux, то ответ - гипервизор + виртуалка с нужной ОС.

В docker гипервизора и виртуальной машины и в помине нет. Совершенно другая технология. Можете почитать Wikipedia ту же. Поэтому приложение гостевой системы на самом деле исполняется как процесс в основной системе. Совершенно не возможно использовать ОС кроме GNU/Linux и/или разных архитектур(гость-хост) в docker принципе. Под Windows работа docker реализована была в старых версиях на основе виртуальной машины с Linux и Linux подсистемы в новых версиях (docker и Windows).

Как работает docker не для кого не секрет. Подробности можно найти в интернете

Судя по Вашему описанию, Вам и в правду не нужен кластер.

через файлы конфигурации, как в кубернетс ... перезапуск при падении как в кубернетс

Это называется инфраструктура как код. Для простых задач достаточно элементарный bash скрипт (srv-up.sh & srv-down.sh, make file, ...) или docker-compose.

обновление без простоя

Для этого посмотрите связку docker+nginx+consul+consul-template. В интернете много статьей, примеров и т.д.
Работает так:

• Есть сервис. nginx (srv-v.1 в конф.) -> srv-v.1
  
• Выходит вторая версия продукта и строится образ srv-v.2 и доставляется на сервер
  
• Запускаем образ srv-v.2 на сервере
  
• Состояние сервера: nginx (srv-v.1 в конф.) -> srv-v.1
  srv-v.2
  
• consul обнаружит srv-v.2 в докере, что в свою очередь обновит конфигурацию nginx и сделает nginx reload (не перезагрузка)
  
• Состояние сервера: nginx (srv-v.1, srv-v.2 в конф.) -> srv-v.1
  \ ->srv-v.2
  
• Останавливаем srv-v.1 или удаляем srv-v.1 со списка серверов в consul
  
• consul обнаружит остановку srv-v.1 в докере, что в свою очередь обновит конфигурацию nginx и сделает nginx reload (не перезагрузка)
  
• Состояние сервера: nginx (srv-v.2 в конф.) ->srv-v.2
  

Можно обновить запуском к примеру через bash скрипт: upgrade-srv.sh srv-v.1 srv-v.2
или то же через CI

подскажите, в чем я неправ? Может быть, нужно это как-то иначе использовать?
Какие сейчас практики применяют?

Вы не совсем поняли. Ansible был когда docker и в помине не было. И отвечал задачам подготовки сервера к доставке(deploy) продукта (настройка окружения, установка зависимостей, ...) и непосредственно развертывания продукта. Так же некоторое применение было в обслуживании серверов (обновление сертификатов, установке патчей, ...).

Сейчас в пост докеровском веке, отпала необходимость в установке и настройке зависимостей на сервере, изоляции сервисов (chroot, ...), ... Зависимости и сам продукт доставляются на сервер в готовом виде, т.е. уже развернутом и настроенном. В этом идея контейнеров. Это не от того, что docker играет на том же поле что Ansible, а потому что подход контейнеризации избавил Ansible от некоторых функции.

Что не предоставляет docker? Это установка самого docker-а на сервере и запуск поверх него готовых контейнеров. Для этого, по прежнему необходим инструмент, можно тот же Ansible.

P.S. Относительно недавно недавно избавил себя от использования Ansible, в пользу Fabric. По причине тяжеловесности Ansible для простых задач. Хотя обновленный Fabric стал лучше, но по прежнему не идеален (описание в императивном стиле, ...). Условно идеальным средством могут служит инструменты для оркестрации docker: Swarm и Kubernites, но не для простых сайтов и маленьких проектов.