Тут суть в чем - json портянка в формате ignition не пишется руками, там куча меты, разделителей и прочего. Человек составляет куда более дружелюбный конфиг в yaml формате, а потом его конвертит специальной утилитой уже в ignition.
На первую часть вопроса коллега уже ответил ниже, отвечу на вторую.
Вариантов что использовать масса, на самом деле. Помимо buildroot в заметке написал про LinuxKit, концептуально почти тоже самое. У такого подхода есть одна большая проблема - это банально дорого. Если в случае с вендором, взять тот же kinovolk и flatcar, который мы выбрали, предоставляются уже готовые под ключ образа + закрытие CVE, то тут придется все делать самим. Придется отдельную команду собирать только на поддержку своего микро дистрибутива.
ИМХО, если человеческих ресурсов действительно много, и хочется что-то крутое и необычное - стоит присмотреться к концепции unikernel. Пакуем свои кусочки control-plane куба и запускаем либо в гипервизоре, либо на kata-containers каких-нибудь. Где-то слышал, что в гигантах вроде Google/AWS так и делают в gke и eks.
Честно говоря, не особо вникал в данный вопрос, ибо пока не настолько приперло.
Чутка тыкал Астру, конкретно cloud образа для запуска ВМ на VMware. Мне лично показалось странным, что образ вроде как cloud, а cloud-init там отсутствует и как машинку сконфигурировать перед запуском - непонятно. Документации по этому поводу особо не нашел, но может и плохо искал.
С docker образами, по крайней мере с год назад, вроде были какие-то проблемы. Они выкладывались в виде тарболов, причем были весьма пухлые. Соответственно, сперва их надо импортировать в рантайм и только потом перекладывать в реджистри.
Про Alt/РедОС ничего сказать не могу, не пользовался от слова совсем.
Если говорить сугубо с технической точки зрения - там во-первых слишком много всего лишнего (а это накладные расходы на размер ВМки и скорость ее создания/запуска), а во вторых, опять же, immutable infrastructure, про которую сейчас из каждого утюга кричат.
И дебиан, и убунта базово подразумевают классические апдейты пакетами и полностью доступный для записи корешок диска (/ и дочерние разделы). Дистрибы из статьи это заточенные сугубо под куб (редкий кейс, что сугубо докер там использовать будут) поделки. Они и какие-то фишечки свои для упрощенного бутстрапа предоставляют, и апдейтить их подразумевается через редеплой (привет, ClusterAPI).
RO разделы, в свою очередь, дают очень весомый буст с точки зрения ИБ. На куче докладов по безопасности в кубе рассматривают кейсы, когда злоумышленник запускает некий привелигированный под, монтирует туда что-то с помощью hostpath и проводит инъекцию в конфигурацию машины. Вот такая атака тут отсекается почти полностью. Примонтировал себе хакер раздел хостовой ОС (resolv.conf там или nssswitch.conf в etc, например, подменить захотел), а писать ничего нельзя и переконфигурить тоже.
Но это все, безусловно, достаточно сложно готовить, с условной убунтой приседаний по настройке системы будет поменьше.
Идея с инжектом в спеку полей из секрета была, но решили отказаться от нее по нескольким причинам: 1) API Kafka.User и так скрыто от разработчиков с помощью RBAC, так что расшифрованный секрет и CR User, по сути, представляют из себя одно и то же 2) В будущем планировали перейти на аутентификацию серт TLS серты от Vault.
За замечание спасибо, может и реализуем когда-то дополнительную поддержку.
Strimzi смотрели, давно правда. Там основной проблемой было, что ACL были склеены с сущностью KafkaUser, что, в общем-то, логично.
Я выше писал, что основной целью было дать возможность разработке полностью управлять сущностями, которые
относятся к их проекту. А в такой конфигурации нужен был бы кто-то, кто имеет доступ к CR соседей, или вообще ко всем. На наш общий чарт и схему деплоя это, соответственно, не ложилось. Контроллер бы(даже целых 2) пришлось бы свой писать, как вы и сказали. Ну а поддерживать форк проекта на джаве с этими контроллерами желания особо не было.
Свой оператор на operator-sdk написать было проще, да и поддерживать в дальнейшем тоже.
Ну это же классика жанра...)
Да история примерно такая же как с убунтой, выше отвечал уже
https://habr.com/ru/company/cloud_mts/blog/724368/#comment_25365706
Обязательно будет. Планирую про потроха ОС рассказать и непосредственно про бутстрап самого куба.
Ну наконец-то откликнулся кто-то из единомышленников :)
P.S Во flatcar еще добавили своих кастомных врапперов над тем же etcd (правда только в CLC, в Butane почему-то выпилили).
Ну, я тут даже особо не выдумывал ничего, авторы документации +- так же и написали в оригинале. https://www.flatcar.org/docs/latest/provisioning/cl-config/#ignition-config
Тут суть в чем - json портянка в формате ignition не пишется руками, там куча меты, разделителей и прочего. Человек составляет куда более дружелюбный конфиг в yaml формате, а потом его конвертит специальной утилитой уже в ignition.
На первую часть вопроса коллега уже ответил ниже, отвечу на вторую.
Вариантов что использовать масса, на самом деле. Помимо buildroot в заметке написал про LinuxKit, концептуально почти тоже самое.
У такого подхода есть одна большая проблема - это банально дорого. Если в случае с вендором, взять тот же kinovolk и flatcar, который мы выбрали, предоставляются уже готовые под ключ образа + закрытие CVE, то тут придется все делать самим. Придется отдельную команду собирать только на поддержку своего микро дистрибутива.
ИМХО, если человеческих ресурсов действительно много, и хочется что-то крутое и необычное - стоит присмотреться к концепции unikernel. Пакуем свои кусочки control-plane куба и запускаем либо в гипервизоре, либо на kata-containers каких-нибудь. Где-то слышал, что в гигантах вроде Google/AWS так и делают в gke и eks.
Честно говоря, не особо вникал в данный вопрос, ибо пока не настолько приперло.
Чутка тыкал Астру, конкретно cloud образа для запуска ВМ на VMware. Мне лично показалось странным, что образ вроде как cloud, а cloud-init там отсутствует и как машинку сконфигурировать перед запуском - непонятно. Документации по этому поводу особо не нашел, но может и плохо искал.
С docker образами, по крайней мере с год назад, вроде были какие-то проблемы. Они выкладывались в виде тарболов, причем были весьма пухлые. Соответственно, сперва их надо импортировать в рантайм и только потом перекладывать в реджистри.
Про Alt/РедОС ничего сказать не могу, не пользовался от слова совсем.
Если говорить сугубо с технической точки зрения - там во-первых слишком много всего лишнего (а это накладные расходы на размер ВМки и скорость ее создания/запуска), а во вторых, опять же, immutable infrastructure, про которую сейчас из каждого утюга кричат.
И дебиан, и убунта базово подразумевают классические апдейты пакетами и полностью доступный для записи корешок диска (/ и дочерние разделы). Дистрибы из статьи это заточенные сугубо под куб (редкий кейс, что сугубо докер там использовать будут) поделки. Они и какие-то фишечки свои для упрощенного бутстрапа предоставляют, и апдейтить их подразумевается через редеплой (привет, ClusterAPI).
RO разделы, в свою очередь, дают очень весомый буст с точки зрения ИБ. На куче докладов по безопасности в кубе рассматривают кейсы, когда злоумышленник запускает некий привелигированный под, монтирует туда что-то с помощью hostpath и проводит инъекцию в конфигурацию машины. Вот такая атака тут отсекается почти полностью. Примонтировал себе хакер раздел хостовой ОС (resolv.conf там или nssswitch.conf в etc, например, подменить захотел), а писать ничего нельзя и переконфигурить тоже.
Но это все, безусловно, достаточно сложно готовить, с условной убунтой приседаний по настройке системы будет поменьше.
Креды шифруем через SOPS https://github.com/mozilla/sops
Выглядит в репозитории это вот так примерно:
Идея с инжектом в спеку полей из секрета была, но решили отказаться от нее по нескольким причинам:
1) API Kafka.User и так скрыто от разработчиков с помощью RBAC, так что расшифрованный секрет и CR User, по сути, представляют из себя одно и то же
2) В будущем планировали перейти на аутентификацию серт TLS серты от Vault.
За замечание спасибо, может и реализуем когда-то дополнительную поддержку.
Ваша правда, в golang клиенте(у нас kadm используется) этого тоже нельзя делать. Приходится дергать из User контроллера cli'шку.
Приветствую
Strimzi смотрели, давно правда. Там основной проблемой было, что ACL были склеены с сущностью KafkaUser, что, в общем-то, логично.
Я выше писал, что основной целью было дать возможность разработке полностью управлять сущностями, которые
относятся к их проекту. А в такой конфигурации нужен был бы кто-то, кто имеет доступ к CR соседей, или вообще ко всем. На наш общий чарт и схему деплоя это, соответственно, не ложилось. Контроллер бы(даже целых 2) пришлось бы свой писать, как вы и сказали. Ну а поддерживать форк проекта на джаве с этими контроллерами желания особо не было.
Свой оператор на operator-sdk написать было проще, да и поддерживать в дальнейшем тоже.