Не совсем понял как было обновление в облачных средах. Ведь там все делается через интерфейс управления облаком — конечно я понимаю, что это просто вызов команд для обновления kubernetes, но ведь у разных поставщиков услуг могут быть немного разные вызова и особенности.
У нас своя разработка (Deckhouse), у которой одна из главных идей — это поддержка одним и тем же дистрибутивом разных провайдеров, что позволяет разворачивать одинаковые кластеры в разных облаках (и даже мигрировать при такой необходимости). В облаках мы используем не managed-решения провайдеров (AKS, GKE…), а их вычислительные мощности, куда ставим свой Kubernetes (грубо говоря, мы раскатываем там свой managed K8s). И поэтому обновление происходит у разных провайдеров аналогично, оно никак не зависит от специфики того или иного облачного managed-решения.
Про железные не сказали как обновили, kubespray playbook переписывали или просто бинари подменили?
Соответственно, bare metal — это просто еще один вид инфраструктуры, которую поддерживает Deckhouse помимо разных облачных провайдеров. Kubespray мы не используем. А про подмену бинарников лучше расскажет автор :-)
Имена обычно не переводят, а используют для них транскрипцию или транслитерацию. Конкретно у Тома известно и имя на русском (его книги переводили на русский), и легко читается имя в оригинале — не понимаю, в чем проблема :-) Мне кажется предпочтительным оставлять оригинальные написания (за редкими исключениями).
Текст в основном про сообщество (даже в блоге perl.com единственный тег у оригинальной публикации — «community»), с какими сложностями оно столкнулось, как организовывалось в необычной ситуации, чтобы добиться своего.
Я бы назвал основным недостатком к8с это необходимость обращаться к услугам облачных провайдеров для работы с ним. Так как поднять и главное обслуживать его своими силами просто немыслимо. За что его и любят и всячески продвигают облачные провайдеры. Как следствие второй недостаток. То что каждый облачный провайдер добавляет чуточку своего функционала. Что приводит к несовместимости к8s при миграции с одного облака в другое.
В таком случае можно взять managed-решение с Kubernetes от стороннего поставщика (не облачного провайдера), которое позволяет [одновременно] использовать и bare metal, и разные облака (и даже мигрировать между ними). Такие решения уже существуют. С ними вы сохраняете независимость от поставщика инфраструктуры (один из главных бонусов Kubernetes, который незаметно убили те самые облака в своих интересах), но при этом уже не нуждаетесь в трудоёмком обслуживании кластеров своими руками.
А вы не читали примечание от переводчика в самом начале этой статьи?
В ней просто и наглядно рассказывается об основных возможностях интерактивного rebase'а, что может стать отличным введением для тех, кто только начинает им пользоваться.
Из инструментов — чат по werf довольно активен и вырос уже до 600+ участников: https://t.me/werf_ru
Ещё не увидел канал https://t.me/devopslibrary
А раз есть про K8s от MCS, то можно было бы и Флант добавить ;-) https://t.me/flant_ru (есть и чат).
У нас своя разработка (Deckhouse), у которой одна из главных идей — это поддержка одним и тем же дистрибутивом разных провайдеров, что позволяет разворачивать одинаковые кластеры в разных облаках (и даже мигрировать при такой необходимости). В облаках мы используем не managed-решения провайдеров (AKS, GKE…), а их вычислительные мощности, куда ставим свой Kubernetes (грубо говоря, мы раскатываем там свой managed K8s). И поэтому обновление происходит у разных провайдеров аналогично, оно никак не зависит от специфики того или иного облачного managed-решения.
Соответственно, bare metal — это просто еще один вид инфраструктуры, которую поддерживает Deckhouse помимо разных облачных провайдеров. Kubespray мы не используем. А про подмену бинарников лучше расскажет автор :-)
В таком случае можно взять managed-решение с Kubernetes от стороннего поставщика (не облачного провайдера), которое позволяет [одновременно] использовать и bare metal, и разные облака (и даже мигрировать между ними). Такие решения уже существуют. С ними вы сохраняете независимость от поставщика инфраструктуры (один из главных бонусов Kubernetes, который незаметно убили те самые облака в своих интересах), но при этом уже не нуждаетесь в трудоёмком обслуживании кластеров своими руками.
В оригинале там тоже несколько коряво: не так просто переводить подобное, но любым уместным исправлениям (если вдруг такие есть) буду рад.
Проект интересный и сразу хорошо оформлен на GitHub, за что отдельный плюсик.
Однако из-за того, что он на Java, не думаю, что завоюет большую аудиторию сообщества Kubernetes, которое говорит на других языках.
В любом случае — успеха!
Мы недавно публиковали довольно детальное сравнение операторов для PostgreSQL (включая все перечисленные): часть 1 и часть 2 с итоговой таблицей.
;-)
Скоро будет!
А вот у авторов недавно был обзор этого решения: https://habr.com/ru/company/proto/blog/530158/
Headlamp я бы вполне отнес к категории этих самых полноценных. Да, компания за ним стоит поменьше, конечно, но это ещё не приговор ;-)