По пункту про курицу и яйцо - поймали, это у меня в голове уже все смешалось :( В старом решении(которое в статье как раз описано) мы cilium и сам fleet доставляли tf'ом. Вот этим провайдером как раз https://github.com/hashicorp/terraform-provider-helm В текущем уже используем вот этот аддончик для CAPI https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm Планируем его тоже выкинуть кстати, и заменить на централизованный fleet (сейчас они децентрализованные)
А Flatcar мы в данный момент уже не используем. Убунта победила
Конкретно про эту штуку первый раз услышал. У нас самого ранчера как такового никогда не было. Пользовались только rke с tf оберткой. И то, не сказал бы, что это от большой любви было сделано, скорее как некоторое промежуточное решение. Целевой картиной всегда был собственный форк CAPI.
Тут суть в чем - 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 написать было проще, да и поддерживать в дальнейшем тоже.
По пункту про курицу и яйцо - поймали, это у меня в голове уже все смешалось :(
В старом решении(которое в статье как раз описано) мы cilium и сам fleet доставляли tf'ом. Вот этим провайдером как раз https://github.com/hashicorp/terraform-provider-helm
В текущем уже используем вот этот аддончик для CAPI https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm
Планируем его тоже выкинуть кстати, и заменить на централизованный fleet (сейчас они децентрализованные)
А Flatcar мы в данный момент уже не используем. Убунта победила
Конкретно про эту штуку первый раз услышал. У нас самого ранчера как такового никогда не было. Пользовались только rke с tf оберткой. И то, не сказал бы, что это от большой любви было сделано, скорее как некоторое промежуточное решение. Целевой картиной всегда был собственный форк CAPI.
Ну это же классика жанра...)
Да история примерно такая же как с убунтой, выше отвечал уже
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 написать было проще, да и поддерживать в дальнейшем тоже.