Установка и настройка lxc на debian 8

Ручной импорт образа¶

Если у вас уже есть lxd-совместимый файл образа, вы можете импортировать его:

lxc image import \<file\> --alias my-alias

И запустить контейнер:

lxc launch my-alias my-container

Смотрите спецификации образов для подробной информации.

Создание и использование вашего первого контейнера

Предполагая, что вы импортировали образ Ubuntu cloud из источника «ubuntu», можете создать контейнер:

lxc launch ubuntu first

Это создаст и запустит новый контейнер ubuntu, что подтвердит:

lxc list

Ваш контейнер здесь называется «first». Вы можете предоставить LXD выбрать случайное имя
просто вызвав «lxc launch ubuntu» без имени.

Сейчас ваш контейнер запущен, вы можете получить интерактивный доступ внутрь:

lxc exec first -- /bin/bash

Или вызвать команду напрямую:

lxc exec first -- apt-get update

Для скачивания файла из контейнера, используйте:

lxc file pull first/etc/hosts .

Для загрузки:

lxc file push hosts first/tmp/

Для остановки, просто сделайте:

lxc stop first

И для полного удаления:

lxc delete first

Множество хостов

Утилита командной строки «lxc» может связываться со множеством серверов LXD.
По умолчанию она связана с локальным по локальному UNIX socket.

Удаленные операции требуют запуска двух команд на удаленном сервере:

lxc config set core.https_address ""
lxc config set core.trust_password some-password

Первая указывает LXD слушать все адреса на порту 8443.
Вторая устанавливает надежный пароль для связи с сервером.

Теперь для связи с удаленным LXD, вы можете просто добавить его:

lxc remote add host-a <ip address or DNS>

Это попросит вас подтвердить отпечаток удаленного сервера а затем спросит пароль.

И после этого, используйте те же команды, что и раньше, но предваряя из именами контейнера
и образа:

lxc exec host-a:first -- apt-get update

Конфигурационный файл контейнера и его опции

Конфигурационные файлы контейнеров носят имя ‘config’ и хранятся в директориях соответствующих контейнеров. Например, путь к конфигурационному файлу контейнера ‘container1’ для привилегированного пользователя — ‘/var/lib/lxc/container1/config’.

Конфигурационный файл любого из созданных контейнеров можно открыть для редактирования в любом удобном вам текстовом редакторе.

Пример загрузки конфигурационного файла для контейнера ‘container1’ в консольном редакторе ‘nano’:

Опция для ограничения доступно контейнеру памяти:

Опция для ограничения количества ядер CPU:

Монтируем файл /etc/rinetd.conf из хостовой машины в контейнер:

Примечание: путь назначения (в контейнере) не должен начинаться с бек-слеша, это путь относительно корня контейнера.

Монтируем файл блочного устройства /dev/sde внутри контейнера, создаем файл если он не существует в точке назначения:

Монтируем директорию /media/zzz на хосте в директорию /var/lib/mysql/zzz внутри контейнера:

Монтирование директории /dev/mapper/lvmfs-home из другой файловой системы в контейнер:

Настройки автозапуска контейнера (включение, задержка, порядок запуска):

Указываем группу для контейнера:

Перед стартом контейнера ‘container1’ выполнить ‘хук’ (hook) — запустить скрипт ‘prepare-start.sh’, который лежит в директории контейнера (рядом с конфигурационным файлом):

Список других полезных хуков для LXC:

Опция	Описание	Исполнение скрипта
lxc.hook.pre-start	Перед стартом контейнера (окончание загрузки консоли, монтирования файловых систем)	Хост
lxc.hook.pre-mount	Перед монтированием rootfs	Контейнер
lxc.hook.mount	После монтирования файловых систем, перед pivot_root	Контейнер
lxc.hook.autodev	После процедуры монтированияи других хуков связанных смонтированием, перед pivot_root	Контейнер
lxc.hook.start	Прямо перед инициализацией INIT	Контейнер
lxc.hook.stop	После остановки контейнера	Хост
lxc.hook.post-stop	После остановки контейнера	Хост
lxc.hook.clone	Когда контейнер склонирован	Хост
lxc.hook.destroy	Когда контейнер уничтожен	Хост
lxc.network.script.up	После создания сетевого интерфейса	Хост
lxc.network.script.down	Перед уничтожениемсетевого интерфейса	Хост

Список сетевых настроек контейнера:

Опция	Описание	Примеры значений
lxc.network.type	Тип сетевой вирутализации	none, empty, veth, vlan,macvlan, phys
lxc.network.link	Сетевой интерфейс на Хосте	eth0, wlan0…
lxc.network.flags	Действие, выполняемое на машине	up
lxc.network.hwaddr	MAC-адрес сетевого интерфейса	00:16:3e:11:22:33
lxc.network.mtu	Maximum Transfer Unit (MTU)	1500
lxc.network.name	Имя сетевого интерфейса
lxc.network.ipv4	IPv4 адрес интерфейса	10.0.3.55/24
lxc.network.ipv4.gateway	IPv4 адрес шлюза	10.0.3.1/24
lxc.network.ipv6	IPv6 адрес интерфейса
lxc.network.ipv6.gateway	IPv6 адрес шлюза

Более детальную информацию о конфигурационном файле для контейнера в LXC можно узнать из или же используя встроенную в GNU/Linux справочную систему man:

COLOPHON top

       This page is part of the lxc (Linux containers) project.  Information
       about the project can be found at ⟨http://linuxcontainers.org/⟩.  If
       you have a bug report for this manual page, send it to
       lxc-devel@lists.linuxcontainers.org.  This page was obtained from the
       project's upstream Git repository ⟨git://github.com/lxc/lxc⟩ on
       2020-08-13.  (At that time, the date of the most recent commit that
       was found in the repository was 2020-08-12.)  If you discover any
       rendering problems in this HTML version of the page, or you believe
       there is a better or more up-to-date source for the page, or you have
       corrections or improvements to the information in this COLOPHON
       (which is not part of the original manual page), send a mail to
       man-pages@man7.org

                                 2020-08-13                    LXC-ATTACH(1)

Pages that refer to this page:
lxc-attach(1), 
lxc-autostart(1), 
lxc-cgroup(1), 
lxc-checkconfig(1), 
lxc-checkpoint(1), 
lxc-config(1), 
lxc-console(1), 
lxc-copy(1), 
lxc-create(1), 
lxc-destroy(1), 
lxc-device(1), 
lxc-execute(1), 
lxc-freeze(1), 
lxc-info(1), 
lxc-ls(1), 
lxc-monitor(1), 
lxc-snapshot(1), 
lxc-start(1), 
lxc-stop(1), 
lxc-top(1), 
lxc-unfreeze(1), 
lxc-unshare(1), 
lxc-update-config(1), 
lxc-usernsexec(1), 
lxc-wait(1), 
lxc.container.conf(5), 
lxc.system.conf(5), 
lxc(7)

Что такое LXC и для чего это нужно

LXC — сокращение от LinuXContainers, мощная система управления контейнерами, использующая общее ядро Linux и механизмы разделения/ограничения пользовательского пространства (имен, ресурсов) для запуска служб и программ. Является свободным программным обеспечением.

Механизм LXC контейнеров построен на основе системы CGroups (Control Groups), которая содержится в ядре Linux и позволяет выделять для работы изолированные пространства имен, ограничивать ресурсы процессов и т.п.

По своей сути LXC — это набор программных средств и утилит, которые позволяют управлять встроенными возможностями ядра Linux по созданию и управлению изолированных окружений. Нечто похожее к LXC есть также в ОС FreeBSD — это называется Jails (клетки, изолированные комнаты для процессов).

Исходя из вышесказанного следует ограничение — запуск LXC возможен только на операционных системах класса GNU/Linux.

В отличии от популярного Docker, который является системой контейнеризации ориентированной на изоляцию отдельных служб и приложений (микросервисы, microservices), LXC — это контейнеризация окружения полноценной ОС, базирующейся на Linux ядре хоста, в которой может работать вся инфраструктура ОС с множеством запущенных программ и служб.

LXC контейнер содержит миниатюрную копию файловой системы ОС с базовым набором программ и скриптов, поэтому в некоторых случаях такие образы могут занимать не мало места.

Например чистый контейнер с Debian Stretch (9) для архитектуры amd64 будет занимать примерно 370 МБ. Образ Alpine GNU/Linux amd64 — примерно 44 МБ.

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

LXC контейнеры отлично подойдут если вы собираетесь запустить несколько изолированных друг от друга виртуальных серверов для сетевых многопользовательских игр, систем распределения трафика, socks5-серверов и т.п.

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

При необходимости в контейнер можно пробросить одну или несколько директорий и даже отдельных файлов, также можно выполнить проброс устройств с хоста внутрь контейнера (например сделать доступной в контейнере USB-вебкамеру, подключенную к хосту и т.п.).

Хочу отметить удобство клонирования и резервирования контейнеров, доступны снепшоты (snapshots). Например, чтобы сделать резервную копию контейнера достаточно его остановить и упаковать директорию с файлами (rootfs, config) в архив.

Все контейнеры можно держать вместе как на одной машине, так и на отдельных связанных сетью хостах. Конфигурация и управление ими — очень простые.

А еще эта технология поддерживает возможность создания вложенных изолированных контейнеров, то есть в одном из готовых контейнеров вы можете установить LXC и создать внутри еще несколько вложенных изолированных друг от друга контейнеров.

LXC — отличный инструмент!

Базовая настройка контейнера LXC

Ранее я рассказывал как производится . Работа с LXC начинается с того что необходимо произвести базовую настройку контейнера. В контейнере находится система CentOS 7 и работать с ней надо как с обычной системой, но с небольшими нюансами. Более подробно о настройке системы можно почитать в статье CentOS 7 установка и настройка.

Обновим систему:

yum update

Для автоматической проверки обновлений установим необходимую утилиту:

yum install yum-cron

Действия на хосте LXC

На хосте с установленной системой LXC выполним команду которая сделает проброс порта с изменением для сервера SSH в контейнере:

firewall-cmd --permanent --zone=external --add-forward-port=port=25552:proto=tcp:toport=22:toaddr=10.10.0.2
= вывод команды =
success

Сохраним изменения:

firewall-cmd --reload
= вывод команды =
success

Посмотрим результат выполненных действий:

firewall-cmd --list-all --zone=external
= вывод команды =
external (active)
target: default
icmp-block-inversion: no
interfaces: ens18
sources:
services: http https
ports: 25555/tcp 10050/tcp
protocols:
masquerade: yes
forward-ports: port=25552:proto=tcp:toport=22:toaddr=10.10.0.2
source-ports:
icmp-blocks:
rich rules:

В результате при запросе порта 25552 на хосте он будет проброшен на 22 порт в контейнер с ip адресом 10.10.0.2.

Установка программ

Установим популярный репозиторий Epel:

yum -y install epel-release

Ставим необходимые пакеты без вопросов:

yum -y install vim mc net-tools bind-utils htop atop iftop lsof wget bzip2 traceroute gdisk yum-utils

Настройка SSH и консоли

Установим, запустим и добавим в автозагрузку ssh сервер:

yum install openssh-server
systemctl start sshd
systemctl enable sshd

Создадим пароль пользователя root в контейнере:

passwd

Приводим отображение приветствия консоли к нашему виду и сразу делаем настройки истории внеся необходимые параметры:

vim /root/.bashrc
= добавляем внизу =
# Вид приветствия bash
PS1='\\u@\H\ \w \$\ '
# Настройка истории bash
export HISTSIZE=10000
export HISTTIMEFORMAT="%h %d %H:%M:%S "
PROMPT_COMMAND='history -a'
export HISTIGNORE="ls:ll:history:w"

Применим изменения без перезагрузки:

source ~/.bashrc

Время в контейнере

Время будет браться с хоста поэтому нам необходимо указать только временную зону.

Посмотрим текущую временную зону:

date
= вывод команды =
Пт окт 12 23:58:14 UTC 2018

Сделаем резервную копию текущей временной зоны:

mv /etc/localtime /etc/localtime.bak

в папке /usr/share/zoneinfo/ находим необходимую временную зону и делаем ссылку

ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

В результате увидим следующее:

date
= вывод команды =
Сб окт 13 02:59:46 MSK 2018

Смена имени производится командой:

hostnamectl старое НОВОЕ

Настройка почты

Для проверки работы почты установим пакет который позволяет отправлять письма с консоли:

yum install mailx

Установим, запустим и добавим в автозагрузку сервис для работы с почтой Рostfix:

yum install postfix
systemctl start postfix
systemctl enable postfix

OPTIONS

-d, —daemon

Run the container as a daemon. As the container has no
more tty, if an error occurs nothing will be displayed,
the log file can be used to check the error. (This is the default mode)

-F, —foreground

Run the container in the foreground. In this mode, the container
console will be attached to the current tty and signals will be routed
directly to the container.

-p, —pidfile pid_file

Create a file with the process id.

-f, —rcfile config_file

Specify the configuration file to configure the virtualization
and isolation functionalities for the container.

This configuration file if present will be used even if there is
already a configuration file present in the previously created
container (via lxc-create).

-c, —console console_device

Specify a device to use for the container’s console, for example
/dev/tty8. If this option is not specified the current terminal
will be used unless -d is specified.

-L, —console-log console_logfile

Specify a file to log the container’s console output to.

-s, —define KEY=VAL

Assign value VAL to configuration
variable KEY. This overrides any
assignment done in config_file.

-C, —close-all-fds

If any file descriptors are inherited, close them. If this option
is not specified, then lxc-start will exit with
failure instead. Note: —daemon implies
—close-all-fds.

—share-net name|pid

Inherit a network namespace from
a name container or
a pid. The network namespace
will continue to be managed by the original owner. The
network configuration of the starting container is ignored
and the up/down scripts won’t be executed.

—share-ipc name|pid

Inherit an IPC namespace from
a name container or
a pid.

—share-uts name|pid

Inherit a UTS namespace from
a name container or
a pid. The starting LXC will
not set the hostname, but the container OS may do it
anyway.

Пользовательские ограничения¶

Как и с cgroups, родительские ограничения наследуются так что непривилегированные контейнеры не могут иметь ulimits установленным на значения
выше чем их родительские.

Тем не менее есть одна вещь которую стоит держать в уме, ulimits как и предполагает их имя, связаны с uid на уровне ядра.
Это глобальный uid ядра, не uid внутри пространства имен пользователя.

Это значит что если два контейнера имеют одинаковые или перекрывающиеся связи id, с общим uid ядра, тогда они также разделяют ограничения,
означая что пользователь в первом контейнере может может успешно DoS того же пользователя в другом контейнере.

Для предотвращения этого, недоверенные пользователи или контейнеры должны иметь абсолютно разные связи id (в идеале из 65536 uids и gids каждый).

Перенос контейнера LXC на другой сервер

Прелесть использования контейнеров, так же заключается в том, что их можно переносить на другой сервер на котором стоит аналогичная версия LXC.

Перейдем в домашнюю папку и создадим архив который будем переносить на примере для контейнера php7-lxc:

cd
tar --numeric-owner -czvf php7-lxc.tar.gz /var/sevo44/lxc/php7-lxc

Где параметры tar означают:

• c — создание архива tar,
• z — сжать архив, используя алгоритм gzip,
• v — выводить подробную информацию процесса,
• f — указывает имя файла архива,
• —numeric-owner — какие изначально при архивации ID были, такими они и будет после распаковки.

После переноса распакуем архив в необходимую папку:

tar -xzvf php7-lxc.tar.gz -C /var/sevo44/

Где параметры tar означают:

• x — создание архива tar,
• -C — указывает место для распаковки архива.

Bash скрипт для переноса контейнера LXC

Для быстроты и удобства лучше использовать скрипт который будет выполнять следующие действия:

• Останавливать переносимый контейнер,
• Создавать архив контейнера,
• Запускать контейнер после архивирования,
• Передавать архив контейнера на удаленный сервер,
• Удалять архив контейнера после передачи на удаленный сервер,
• Распаковывать архив на удаленном сервере,
• Удалять архив контейнера на удаленном сервере после распаковки.

Создадим папку для размещения скрипта и создадим скрипт:

mkdir /root/bin
vim /root/bin/tar-lxc_php7-lxc.sh
= необходимый код с пояснениями =
#!/bin/bash

# Переносимый контейнер
container_name=»php7-lxc»
# Параметры подключения к удаленому серверу
connect_string=»root@192.168.0.101″

# Остановка контейнера перед архивацией
lxc_status=$(lxc-info $container_name|grep «STOPPED»)
if ;
then
lxc-stop «$container_name»
run_again=»yes»
fi

# Создание архива контейнера
tar —numeric-owner -czvf /tmp/$container_name.tar.gz /var/sevo44/lxc/$container_name

# Запуск контейнера после архивирования
if ;
then
lxc-start «$container_name»
fi

# Копирование архива контейнера на удаленный сервер
scp /tmp/$container_name.tar.gz $connect_string:/tmp/

# Удаление архива после отправки на удаленный сервер
rm -f /tmp/$container_name.tar.gz

# Создадим необходимую папку если она отсутствует
ssh $connect_string mkdir -p /var/sevo44/tmp

# Распаковка архива на удаленном сервере !!! ВНИМАНИЕ !!! указываем полное имя архива
ssh $connect_string tar -xvf /tmp/php7-lxc.tar.gz -C /var/sevo44/tmp/

# Удаление архива после распаковки на удаленном сервере !!! ВНИМАНИЕ !!! указывается полное имя архива
ssh $connect_string rm -f /tmp/php7-lxc.tar.gz

Делаем скрипт исполнительным для владельца файла:

chmod u+x /root/bin/tar-lxc_php7-lxc.sh

Запускаем скрипт с параметром отправки информации о завершении переноса контейнера:

/root/bin/tar-lxc.sh | mailx -s 'Контейнер php7-lxc перенесён!' info@sevo44.ru

В результате на почту придет сообщение с темой «Контейнер php7-lxc перенесён!» а в теле письма вы увидите перечень всех файлов что были архивированы.

Troubleshooting

Root login fails

If presented with following error upon trying to login using lxc-console:

login: root
Login incorrect

And the container’s shows:

pam_securetty(login:auth): access denied: tty 'pts/0' is not secure !

Alternatively, create a new user in lxc-attach and use it for logging in to the system, then switch to root.

# lxc-attach -n playtime
# useradd -m -Gwheel newuser
# passwd newuser
# passwd root
# exit
# lxc-console -n playtime
$ su

No network-connection with veth in container config

If you cannot access your LAN or WAN with a networking interface configured as veth and setup through .
If the virtual interface gets the ip assigned and should be connected to the network correctly.

ip addr show veth0 
inet 192.168.1.111/24

You may disable all the relevant static ip formulas and try setting the ip through the booted container-os like you would normaly do.

Example

...
lxc.net.0.type = veth
lxc.net.0.name = veth0
lxc.net.0.flags = up
lxc.net.0.link = 
...

And then assign the IP through a preferred method inside the container, see also .

Error: unknown command

The error may happen when a basic command (ls, cat, etc.) on an attached container is typed hen a different Linux distribution is containerized relative to the host system (e.g. Debian container in Arch Linux host system). Upon attaching, use the argument :

# lxc-attach -n container_name --clear-env

Error: Failed at step KEYRING spawning…

Services in an unprivileged container may fail with the following message

some.service: Failed to change ownership of session keyring: Permission denied
some.service: Failed to set up kernel keyring: Permission denied
some.service: Failed at step KEYRING spawning ....: Permission denied

Create a file containing

/etc/lxc/unpriv.seccomp

2
blacklist

keyctl errno 38

Then add the following line to the container configuration after lxc.idmap

lxc.seccomp.profile = /etc/lxc/unpriv.seccomp

CGROUP

Получить значение лимита памяти в Байтах для контейнера ‘container1’:

Примечание: если значение с лимитом памяти для контейнера не было установлено то команда выведет очень большое целое число.

Установка лимита памяти для контейнера — 256МБ:

Установка лимита памяти для контейнера — 512МБ:

Другие значения параметров для возможной установки:

• cpu.shares — приоритет использования CPU, пример: A = 2000, B = 1000 — контейнер B будет иметь в 2 раза меньший приоритет по использованию ЦПУ чем контейнер A;
• cpuset.cpus — количество и/или номера ядер CPU для использования в контейнере, примеры: 0,1,2 или 0-3;
• memory.memsw.limit_in_bytes — суммарный лимит памяти (ОЗУ + файл подкачки);
• blkio.weight — приоритет использования блочной системы ввода-вывода (IO).

Основа

LXC это набор инструментов для контейнеризации целых ОС, в отличии от Докера, который больше заточен под релизы и тесты для разработчиков, тут больше пространства для маневра, без надобности вдаваться сильно в зависимости и синтаксис конфигурационных файлов. Серьезно, для домашних служб Докер монстровато выглядит. Ладно, хватит субъективностей, раз я LXC выбрал, расскажу тут все полезное, что раскопал, пока строил заново домашние сервисы на новой платформе.

Первое, что и очень важное, это выбор хостовой системы для нашего контейнерного парка. К слову, я пробовал реализации lxc/lxd на debian, arch, centos, ubuntu, и выиграл по многим параметрам по моему мнению ubuntu 18.04 LTS

Не буду тут все расписывать подробно за и против, решайте сами что кому по душе.

Итак, я установил хостовую систему ubuntu 18.04 LTS. Настроил по своему вкусу безопасность и остальное, что мы там любим настроить на свежей системе. Перейдем к делу.

Проблемы и ошибки

Не устанавливается httpd

Сразу скажу, что в качестве хостовой системы и шаблонов для lxc контейнеров я использовал только centos. Возможно в других системах указанных мной ошибок не будет. Первое с чем сразу же столкнулся было невозможность установить пакет httpd. Была вот такая ошибка:

# yum install httpd

Running transaction
  Installing : httpd-2.4.6-67.el7.centos.6.x86_64                                                                                                        1/1 
Error unpacking rpm package httpd-2.4.6-67.el7.centos.6.x86_64
error: unpacking of archive failed on file /usr/sbin/suexec;5a8adbd2: cpio: cap_set_file
  Verifying  : httpd-2.4.6-67.el7.centos.6.x86_64                                                                                                        1/1 

Failed:
  httpd.x86_64 0:2.4.6-67.el7.centos.6                                                                                                                       

Complete!

В интернете полно информации по подобной ошибке в контейнерах centos. Она встречается не только в lxc, но и в docker. В докере ее каким-то образом в определенный момент исправили, в lxc до сих пор воспроизводится и я не уверен, что исправление будет.

Суть ошибки в том, что существуют некие ограничения ядра для работы file capabilities. Я не вникал подробно в эти file capabilities, не понимаю до конца сути ошибки, только поверхностно. Подробно ошибка разобрана тут — https://github.com/lxc/lxd/issues/1245. Так как решением проблемы предлагается перевести контейнер в privileged режим, когда хостовый рут и контейнерный имеют одинаковые системные id, то примерно понятно, в чем суть ошибки.

В общем, я не стал переводить контейнер в privileged режим, а поступил следующим образом. Зачрутился с хостовой машины в контейнер и установил httpd оттуда. Выполняем на хосте:

# chroot /var/lib/lxc/lxc_centos/rootfs
# yum install httpd

Теперь можно зайти в контейнер и проверить, что httpd установлен и нормально работает. Это рабочее решение, когда вы администратор и хоста и контейнеров. Но если вы кому-то отдаете контейнеры под управление, то либо вам придется самим решать ошибки владельцев контейнеров, либо искать какое-то другое решение.

Зависает контейнер и нагружает cpu хоста

Следующая неприятная ошибка, с которой столкнулся сразу же после начала тестирования lxc контейнеров. Контейнер через несколько минут после запуска зависал. Я не мог его ни остановить, ни удалить. При этом на самом хосте процесс /usr/lib/systemd/systemd-journald на 100% нагружал одно ядро cpu.

Решение проблемы следующее. Добавляем в конфиг контейнера параметр:

lxc.kmsg = 0

Перезапускаем контейнер. Заходим в него и удаляем /dev/kmsg (именно в контейнере, не на хосте!!!)

# rm -f /dev/kmsg

После этого контейнеры стали работать стабильно и перестали зависать. Я установил bitrix-env и развернул сайт. Все заработало без проблем с нормальной скоростью.

Не работает chronyd

После установки и запуска chronyd в lxc контейнере с centos 7 получаем ошибку:

ConditionCapability=CAP_SYS_TIME was not met

Тут я уже немного утомился ковыряться в ошибках lxc и понял, что не хочу использовать в работе эти контейнеры. Но все же собрался с силами и погуглил еще немного. Как оказалось, это не ошибка, это ограничение работы в контейнере. Условием работы chronyd является доступ к системному вызову adjtimex(). У контейнера в не privileged режиме нет этого доступа, поэтому он и не запускается.

Контролирует эту ситуацию параметр

ConditionCapability=CAP_SYS_TIME

в конфиге systemd службы chronyd в контейнере — /etc/systemd/system/multi-user.target.wants/chronyd.service. Если убрать этот параметр и запустить службу, получим ошибку:

adjtimex(0x8001) failed : Operation not permitted

В общем, контейнер без привилегированного режима управлять временем не может. Это архитектурная особенность работы контейнеров, с этим ничего не поделать. Надо на хосте следить за временем.