На днях американский инженер Andrew Rynhard представил интересный проект: компактный дистрибутив Linux, предназначенный специально для запуска Kubernetes-кластеров. Он получил название из древнегреческой мифологии — Talos.
Проект появился под вдохновением от твита Kelsey Hightower'а ещё 2015 года, в котором он говорил, что нам осталось лишь дождаться появления условной KubeOS (после чего жизнь облачных окружений станет окончательно замечательной):
К слову, с появлением Talos эта история получила продолжение: некто ответил на исторический твит, что такая система уже появилась, и автор Talos заявил, что будет рад, если Kelsey посмотрит на проект. Реакции последнего, впрочем, (пока) не последовало.
Судя по всему, разработкой Talos занимался один человек (представляющий себя в рамках целой компании — Autonomy) — ушло у него на это более года. И вот теперь, когда статус минимальной готовности достигнут, автор ожидает, что к нему присоединятся другие представители Kubernetes/cloud native-сообщества. Итак, в чём же суть проекта?
Принципы и особенности Talos
Talos позиционируется как современный Linux-дистрибутив, созданный специально (и исключительно!) для Kubernetes. Для достижения поставленной цели в его реализации придерживаются следующих подходов:
Минимализм
Повсеместный минимализм — один из краеугольных камней архитектуры Talos. Одним из ярких примеров здесь является используемая служба инициализации, которая (вопреки современным тенденциям в этой области) следует философии UNIX, что «каждая программа делает одну вещь, но хорошо»:
Мы хотели сделать init ориентированным на единственную задачу — запуск Kubernetes. В нём попросту нет механизмов для каких-либо других действий.
Разработчики пошли дальше и лишили свою операционную систему привычного системным администраторам пользовательского доступа к хосту: в Talos нет ни командных оболочек, ни SSH-демона, ни даже возможности запускать собственные процессы на хосте. И действительно: зачем всё это, если вам нужно запускать Kubernetes и только? Практически все процессы в Talos работают в рамках контейнеров.
Однако, поскольку мир не так уж идеален (чтобы ОС полностью функционировала «сама»), инструменты для эксплуатации ОС всё же есть:
- демон osd, реализованный по принципу предоставления минимально необходимых привилегий (Principle of Least Privilege) и предлагающий API (на базе gRPC) для управления узлами;
- CLI-утилита osctl, позволяющая общаться со службой osd, что запускается на каждом узле.
Так и реализован набор базовых возможностей по эксплуатации: перезагрузка служб и узлов кластера, получение логов ядра (dmesg) и из контейнеров, вставка данных в конфигурационные файлы узлов и т.п.
Все перечисленные компоненты (init, osd, osctl…), как и некоторые другие в составе дистрибутива, написаны на языке Go. К слову, весь исходный код распространяется на условиях Open Source-лицензии Mozilla Public License 2.0.
Безопасность
Описанный выше минималистский подход (всё необходимое только для запуска Kubernetes) + принцип выдачи лишь минимальных привилегий уже сами по себе снижают потенциальную поверхность атаки. Кроме того, в Talos:
- включённое в состав ядро настроено в соответствии с рекомендациями проекта KSSP (Kernel Self Protection Project), фокусирующегося на возможностях ядра к самостоятельной защите от потенциальных багов и уязвимостей (вместо использования userspace-утилит для тех же целей);
- корневая файловая система монтируется в read-only, что — в совокупности с отсутствием shell'ов/SSH — делает систему неизменной (immutable);
- используется двухсторонний TLS (mTLS) для взаимодействия с API;
- настройки и конфигурации Kubernetes применяются в соответствии с указаниями CIS (Center for Internet Security).
Дополнительный плюс, вытекающий из минимализма и фокусировки на immutable, — предсказуемость системы в поведении (т.к. снижается число факторов, влияющих на окружение).
Актуальность
Авторы обещают базировать Talos на предпоследнем upstream-релизе Kubernetes (впрочем, прямо сейчас поддерживается K8s 1.13.3) и последнем доступном LTS-релизе ядра Linux (сейчас используется 4.19.10).
Системные компоненты
Основными составляющими дистрибутива (помимо ядра и «фирменных» утилит) являются:
- musl-libc — как стандартная библиотека Си;
- golang — для
init
и других своих инструментов; - gRPC — для API;
- containerd — для запуска системных служб в контейнерах (используется с плагином CRI для Kubernetes);
- kubeadm — для развёртывания кластеров.
Работа с Talos
Примеры деплоя Talos для случаев использования AWS, KVM и Xen приведены в документации проекта. Для быстрой иллюстрации того, как это выглядит, вот алгоритм инсталляции с виртуальными машинами Linux KVM:
1. Установка узла мастера на хост:
docker run --rm --privileged --volume /dev:/dev autonomy/talos:latest image -b /dev/sdb -f -p bare-metal -u http://${IP}:8080/master.yaml
2. Создание ВМ:
virt-install -n master --description "Kubernetes master node." \
--os-type=Linux --os-variant=generic --virt-type=kvm --cpu=host \
--vcpus=2 --ram=4096 --disk path=/dev/sdb \
--network bridge=br0,model=e1000,mac=52:54:00:A8:4C:E1 \
--graphics none --boot hd --rng /dev/random
3. Аналогичные действия для создания рабочего узла:
docker run --rm --privileged --volume /dev:/dev \
autonomy/talos:latest image -b /dev/sdc -f -p bare-metal \
-u http://${IP}:8080/worker.yaml
virt-install -n master --description "Kubernetes worker node." --os-type=Linux --os-variant=generic --virt-type=kvm --cpu=host \
--vcpus=2 --ram=4096 --disk path=/dev/sdc \
--network bridge=br0,model=e1000,mac=52:54:00:B9:5D:F2 \
--graphics none --boot hd --rng /dev/random
Настройка взаимодействия между osd и osctl по большому счёту сводится к генерации ключей для их аутентификации (уже упомянутый mTLS) и описана здесь.
Дальнейшая работа с ними сводится к командам вроде
osctl reboot
, osctl stats
и osctl logs
. Демонстрация вывода контейнеров в пространстве имён k8s.io
:$ osctl ps -k
NAMESPACE ID IMAGE PID STATUS
k8s.io 0ca1… sha256:da86… 2341 RUNNING
k8s.io 356f… sha256:da86… 2342 RUNNING
…
k8s.io e42e… sha256:4ff8… 2508 RUNNING
k8s.io kubelet k8s.gcr.io/… 2068 RUNNING
Процесс конфигурации Kubernetes-кластера с Talos — доступен здесь (mater-узлы) и здесь (workers).
Статус и перспективы
Проект находится в стадии альфа-версии (последний релиз — v0.1.0-alpha.18) и, конечно, на данном этапе выглядит больше как занятный эксперимент, чем что-либо по-настоящему близкое к production.
Однако всплеск интереса к Talos после его недавнего анонса (уже 600+ звёзд на GitHub) и призыв единственного автора к совместному творчеству могут послужить отличным стимулом для его развития.
Активность в issues проекта Talos в последние дни
По меньшей мере, в дистрибутиве заложены актуальные для мира cloud native идеи, качественная реализация которых — дело времени.
P.S.
Читайте также в нашем блоге:
Комментарии (11)
gecube
19.02.2019 22:27Это вообще не пригодно для не-облачных окружений? Что насчёт нестандартных видов хранилищ и сетей? PVC?
rvs_ie
20.02.2019 05:23Задумка интересная, но совсем без ssh это как-то перебор.
Даже если оно только для облачных окружений, иногда в docker, ядре или еще в чем-нибудь базовом вылезают интересные баги которые особо никак кроме как из консоли не продебажишь.
shurup Автор
20.02.2019 11:17-1Не могу не поделиться полученным несколько часов назад письмом от Andrew Rynhard:
Hi Dmitry,
I am the developer of Talos. I just want to thank you for taking the time to write about Talos on habr.com. You described it better than me :D.
rumkin
Глядишь еще пару лет и они догадаются, что можно запускать внутри контейнера только голые процессы (без всей ОС), которые общаются между собой по шине и мы наконец получим ту самую микроядрерную архитектуру.
begemoth3663
изрядно Вы это с прямым углом перепутали...
N.B. во FreeBSD лет ~10 назад bind можно было запустить в jail'е...
rumkin
Это вы что-то путаете. Пройдитесь бритвой Оккама, получите ровно то, о чем я говорю.
А jails так это вообще BSD, в линуксе их аналог – LXC, который и используется в containerd.
rrromka
С версии 0.9, выпущенной в 2014 году, Докер не зависит от LXC: https://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/
gecube
вероятно имеется в виду, что докер базируется поверх cgroups & namespaces, что и есть тоже основа для lxc
rrromka
Это же просто ваш домысел основанный на вашем опыте. Я на своем опыте часто сталкивался с ошибочным мнением, что внутри Докера используется lxc, поэтому с тем же успехом могу домыслить, что автор имел ввиду именно то, что написал:
Если отбросить домыслы и посмотреть на эту фразу логически, то чему она эквивалентна:
— фразе «внутри containerd используется lxc»
— или фразе «containerd и lxc внутри себя используют одни и те же инструменты предоставляемые ядром»?
P6i
А еще они нам юникернелы обещали