Текст в основном про сообщество (даже в блоге perl.com единственный тег у оригинальной публикации — «community»), с какими сложностями оно столкнулось, как организовывалось в необычной ситуации, чтобы добиться своего.
Я бы назвал основным недостатком к8с это необходимость обращаться к услугам облачных провайдеров для работы с ним. Так как поднять и главное обслуживать его своими силами просто немыслимо. За что его и любят и всячески продвигают облачные провайдеры. Как следствие второй недостаток. То что каждый облачный провайдер добавляет чуточку своего функционала. Что приводит к несовместимости к8s при миграции с одного облака в другое.
В таком случае можно взять managed-решение с Kubernetes от стороннего поставщика (не облачного провайдера), которое позволяет [одновременно] использовать и bare metal, и разные облака (и даже мигрировать между ними). Такие решения уже существуют. С ними вы сохраняете независимость от поставщика инфраструктуры (один из главных бонусов Kubernetes, который незаметно убили те самые облака в своих интересах), но при этом уже не нуждаетесь в трудоёмком обслуживании кластеров своими руками.
А вы не читали примечание от переводчика в самом начале этой статьи?
В ней просто и наглядно рассказывается об основных возможностях интерактивного rebase'а, что может стать отличным введением для тех, кто только начинает им пользоваться.
Про что конкретно умеет — можно посмотреть список фич на сайте/гитхабе. Есть много всего по сборке, чтобы сделать её эффективной (быстрой с кэшами, инкрементными пересборками с учётом истории Git и т.п., распределенной). Content-based tagging (писали про его фишки в отдельной статье). Удобные инструменты для отладки и при сборке, и при деплое. Деплой в Kubernetes в духе GitOps (автоматизированное поддержание реального состояния инфраструктуры и приложения в соответствии с тем, что в репе). Умная автоматическая очистка образов (про нее тоже была статья). Главное удобство — что все эти части жизненного цикла управляются из одного места, "склеиваются" в нем и благодаря самому этому факту возможно (можно отслеживать нужные образы, чтобы что-то с ними делать).
Да, основную часть вещей можно сделать другими способами. Однако изначальный посыл, что это будет проще и удобнее, вряд ли тогда сработает. А смотреть на всю историю CI/CD и его реализации надо именно так комплексно, а не один какой-то выбранный кусок.
Как будто с ним можно сделать всё, что может werf? :-) Как будто вообще есть такое универсальное средство, удовлетворяющее ещё и другим критериям (используемый стек, производительность и дальше по списку).
Хорошо, когда есть выбор. А уж как его делать — тема для других статей. Здесь же можно увидеть, что предстоит, если выбрать конкретный путь.
К слову об инструментах: упомянутые kube-score и Polaris (вместе с другими утилитами) рассматривались в таком обзоре (тоже переводной). Popeye затрагивался в обзоре утилиты k9s, куда входит как составная часть.
В таком случае можно взять managed-решение с Kubernetes от стороннего поставщика (не облачного провайдера), которое позволяет [одновременно] использовать и bare metal, и разные облака (и даже мигрировать между ними). Такие решения уже существуют. С ними вы сохраняете независимость от поставщика инфраструктуры (один из главных бонусов Kubernetes, который незаметно убили те самые облака в своих интересах), но при этом уже не нуждаетесь в трудоёмком обслуживании кластеров своими руками.
В оригинале там тоже несколько коряво: не так просто переводить подобное, но любым уместным исправлениям (если вдруг такие есть) буду рад.
Проект интересный и сразу хорошо оформлен на GitHub, за что отдельный плюсик.
Однако из-за того, что он на Java, не думаю, что завоюет большую аудиторию сообщества Kubernetes, которое говорит на других языках.
В любом случае — успеха!
Мы недавно публиковали довольно детальное сравнение операторов для PostgreSQL (включая все перечисленные): часть 1 и часть 2 с итоговой таблицей.
;-)
Скоро будет!
А вот у авторов недавно был обзор этого решения: https://habr.com/ru/company/proto/blog/530158/
Headlamp я бы вполне отнес к категории этих самых полноценных. Да, компания за ним стоит поменьше, конечно, но это ещё не приговор ;-)
Про что конкретно умеет — можно посмотреть список фич на сайте/гитхабе. Есть много всего по сборке, чтобы сделать её эффективной (быстрой с кэшами, инкрементными пересборками с учётом истории Git и т.п., распределенной). Content-based tagging (писали про его фишки в отдельной статье). Удобные инструменты для отладки и при сборке, и при деплое. Деплой в Kubernetes в духе GitOps (автоматизированное поддержание реального состояния инфраструктуры и приложения в соответствии с тем, что в репе). Умная автоматическая очистка образов (про нее тоже была статья). Главное удобство — что все эти части жизненного цикла управляются из одного места, "склеиваются" в нем и благодаря самому этому факту возможно (можно отслеживать нужные образы, чтобы что-то с ними делать).
Да, основную часть вещей можно сделать другими способами. Однако изначальный посыл, что это будет проще и удобнее, вряд ли тогда сработает. А смотреть на всю историю CI/CD и его реализации надо именно так комплексно, а не один какой-то выбранный кусок.
Как будто с ним можно сделать всё, что может werf? :-) Как будто вообще есть такое универсальное средство, удовлетворяющее ещё и другим критериям (используемый стек, производительность и дальше по списку).
Хорошо, когда есть выбор. А уж как его делать — тема для других статей. Здесь же можно увидеть, что предстоит, если выбрать конкретный путь.