Статья совсем не тянет на свой громкий заголовок. Трендами названы два релиза, и про первый раскрыта лишь одна фича. Хотя на Хабре уже был подробнейший обзор Kubernetes 1.33.
Список из нескольких инструментов в поразделе трендов вызывает много вопросов. Почему выбраны именно они? Какие есть альтернативы? Чем обусловлены их появление? Как растёт их популярность?
В реальности трендов куда больше, и отчасти их покрывают исследования от многочисленных организаций, включая отчёты от CNCF, различные tech radars, Accelerate State of DevOps Report 2024 от DORA, The State of Kubernetes от Spectro Cloud, The SRE Report от Catchpoint и т.п.
Появилась как Alpha в версии 1.27. В версии 1.33 стала Beta (включена по умолчанию, но это ещё не stable). Стабильной она до сих пор не является (ожидается в 1.35). Здесь была хорошая подробная статья про фичу, в т.ч. её историю.
Будучи CNCF Ambassador'ом, считаю максимально уместным поднимать такие темы. Личное обращение от коллеги по этому вопросу ничего не изменило, поэтому здесь появился такой публичный комментарий от меня.
Очень грустно видеть такое отношение к сообществу: все претензии решать через суд, а до отношения между людьми внутри самого сообщества дела нет. Но ваш выбор.
что как это станет возможно - то с удовольствием это сделаем.
Это опять не вся правда. В нынешнем виде включить его во франшизу CNCF невозможно. Речь не только про геополитическую ситуацию, а потому что не соблюдаются многочисленные правила, про которые я писал в изначальном сообщении. Это будет совсем другой подход к организации: другие сроки, другие требования к списку организаторов, к докладам и т.п.
Сейчас же вы создали своё мероприятие с названием, которое очень уж похоже (специально или нет — пусть теперь решают сами читатели), а его форма и содержимое — сильно другие. В этом и есть моя изначальная претензия, озвученная в первом комментарии.
Для полноты картины хочу ещё добавить, что в CNCF не рады тому названию, которое вы сейчас используете, для такого мероприятия, которое вы проводите.
Во-первых, придумать любое название — это, конечно, ок; все так делают. Но после факта придумывания и до выхода на публику разумно проверять, не использовалось ли оно где-то уже. А если оно используется настолько массово, насколько в данном конкретном случае, то очень сомнительно идти с ним дальше. Хотя бы по причинам, которые я описал в изначальном комментарии.
Во-вторых, мне известно, что ваша команда организаторов обращалась в CNCF по поводу проведения KCD. Т.е. совпадение тут явно не было случайным, и ваш ответ после этого, к сожалению, совсем не выглядит честным.
Коллеги, а что всё-таки с названием? Kubernetes Community Days — это официальные мероприятия от CNCF. Чтобы их проводить, надо проходить долгий публичный процесс, формат их организации и проведения строго регулируется. В частности, обязательно должны быть организаторы из разных компаний, кто-то из них должен иметь статус в CNCF и т.п. Всё это сделано для того, чтобы гарантировать тот самый community-статус, что заявляется в названии этих мероприятий, и соответствовать ожиданиям сообщества.
Организуя мероприятие с идентичным названием и единственным генеральным спонсором, вы намеренно вводите широкое сообщество в заблуждение. Никакой реальной аффилированности у мероприятия с CNCF нет, и одобрения от этой организации на подобное название получено не было (информация от прямых представителей).
Ведь вы знали о программе KCD, и нет ничего сложного в том, чтобы придумать любое другое название, в котором не будет намёков на некий официальный статус.
Красота Open Source - в международном сотрудничестве, и никакой "свой" фонд внутри одной страны это не заменит. В той же CNCF много китайских компаний среди спонсоров и все больше проектов, переданных в Sandbox китайскими компаниями.
Основная версия продолжает жить как проприетарный продукт. Есть в бесплатной редакции (без ряда фич, для личного пользования) и платной Pro: https://k8slens.dev/pricing
Это не самый удачный перевод control plane, который был когда-то давно принесён в русскоязычную версию документации Kubernetes, но мы от него отказались (в пользу «управляющего слоя»). Хотя вижу, что осталось ещё [как минимум] одно упоминание по приведённой ссылке — пройдусь ещё раз grep'ом, чтобы избавиться от этого.
werf включает в себя патченную версию Helm (теперь этот форк пошёл ещё дальше в сторону самостоятельного проекта — называется Nelm). Но в первую очередь werf — это opinionated solution, построенный на базе Helm и других стандартных проектов для сборки и деплоя в Kubernetes. Утилита встраивается в привычную CI-систему (GitLab, GitHub…) и вызывается оттуда для сборки/тегирования/деплоя образов. Вместо того, чтобы напрямую работать с Docker/Buildah/Helm, вы работаете с werf. А уже внутри неё — привычные технологии с доп. фичами и "обвязкой", чтобы процесс сборки-деплоя шёл по opinionated workflow, был предсказуемым и надёжным.
Те же разработчики ядра Linux практически поголовно сидят на немаленьких зарплатах у бигкорпов
Многие, конечно, но с категорическим «нет» я бы поспорил :-) Из статистики по Linux v6.8, в топе Most active 6.8 employers By changesets помимо собственно компаний есть категории Uknown (7.5%) и None (5.3%). В топе по contributions в Kubernetes за последний год — на пятом месте категория Independent вместо компании.
Такой моделью (Post-Open Source) занимается Bruce Perens:
Post-Open, as he describes it, is a bit more involved than Open Source. It would define the corporate relationship with developers to ensure companies paid a fair amount for the benefits they receive. It would remain free for individuals and non-profit, and would entail just one license.
Консультанты в области Kubernetes и cloud native. Авторы концепции GitOps. Авторы множества Open Source-проектов для экосистемы Kubernetes, самый известный - Flux, который недавно стал graduated project в CNCF.
Статья совсем не тянет на свой громкий заголовок. Трендами названы два релиза, и про первый раскрыта лишь одна фича. Хотя на Хабре уже был подробнейший обзор Kubernetes 1.33.
Список из нескольких инструментов в поразделе трендов вызывает много вопросов. Почему выбраны именно они? Какие есть альтернативы? Чем обусловлены их появление? Как растёт их популярность?
В реальности трендов куда больше, и отчасти их покрывают исследования от многочисленных организаций, включая отчёты от CNCF, различные tech radars, Accelerate State of DevOps Report 2024 от DORA, The State of Kubernetes от Spectro Cloud, The SRE Report от Catchpoint и т.п.
В чём реальный замысел этого материала?
Появилась как Alpha в версии 1.27. В версии 1.33 стала Beta (включена по умолчанию, но это ещё не stable). Стабильной она до сих пор не является (ожидается в 1.35). Здесь была хорошая подробная статья про фичу, в т.ч. её историю.
Будучи CNCF Ambassador'ом, считаю максимально уместным поднимать такие темы. Личное обращение от коллеги по этому вопросу ничего не изменило, поэтому здесь появился такой публичный комментарий от меня.
Очень грустно видеть такое отношение к сообществу: все претензии решать через суд, а до отношения между людьми внутри самого сообщества дела нет. Но ваш выбор.
Это опять не вся правда. В нынешнем виде включить его во франшизу CNCF невозможно. Речь не только про геополитическую ситуацию, а потому что не соблюдаются многочисленные правила, про которые я писал в изначальном сообщении. Это будет совсем другой подход к организации: другие сроки, другие требования к списку организаторов, к докладам и т.п.
Сейчас же вы создали своё мероприятие с названием, которое очень уж похоже (специально или нет — пусть теперь решают сами читатели), а его форма и содержимое — сильно другие. В этом и есть моя изначальная претензия, озвученная в первом комментарии.
Для полноты картины хочу ещё добавить, что в CNCF не рады тому названию, которое вы сейчас используете, для такого мероприятия, которое вы проводите.
Во-первых, придумать любое название — это, конечно, ок; все так делают. Но после факта придумывания и до выхода на публику разумно проверять, не использовалось ли оно где-то уже. А если оно используется настолько массово, насколько в данном конкретном случае, то очень сомнительно идти с ним дальше. Хотя бы по причинам, которые я описал в изначальном комментарии.
Во-вторых, мне известно, что ваша команда организаторов обращалась в CNCF по поводу проведения KCD. Т.е. совпадение тут явно не было случайным, и ваш ответ после этого, к сожалению, совсем не выглядит честным.
Коллеги, а что всё-таки с названием? Kubernetes Community Days — это официальные мероприятия от CNCF. Чтобы их проводить, надо проходить долгий публичный процесс, формат их организации и проведения строго регулируется. В частности, обязательно должны быть организаторы из разных компаний, кто-то из них должен иметь статус в CNCF и т.п. Всё это сделано для того, чтобы гарантировать тот самый community-статус, что заявляется в названии этих мероприятий, и соответствовать ожиданиям сообщества.
Организуя мероприятие с идентичным названием и единственным генеральным спонсором, вы намеренно вводите широкое сообщество в заблуждение. Никакой реальной аффилированности у мероприятия с CNCF нет, и одобрения от этой организации на подобное название получено не было (информация от прямых представителей).
Ведь вы знали о программе KCD, и нет ничего сложного в том, чтобы придумать любое другое название, в котором не будет намёков на некий официальный статус.
Красота Open Source - в международном сотрудничестве, и никакой "свой" фонд внутри одной страны это не заменит. В той же CNCF много китайских компаний среди спонсоров и все больше проектов, переданных в Sandbox китайскими компаниями.
Open Source-форк давно не развивается, это тупик.
Основная версия продолжает жить как проприетарный продукт. Есть в бесплатной редакции (без ряда фич, для личного пользования) и платной Pro: https://k8slens.dev/pricing
К сожалению, я уверен, что сообщение выше написал ChatGPT.
Это не самый удачный перевод control plane, который был когда-то давно принесён в русскоязычную версию документации Kubernetes, но мы от него отказались (в пользу «управляющего слоя»). Хотя вижу, что осталось ещё [как минимум] одно упоминание по приведённой ссылке — пройдусь ещё раз grep'ом, чтобы избавиться от этого.
С названием проблема: совпадает с [отчасти] похожей по смыслу утилитой.
Kubernetes 1.31 ещё не вышел. Релиз состоится в августе.
werf включает в себя патченную версию Helm (теперь этот форк пошёл ещё дальше в сторону самостоятельного проекта — называется Nelm). Но в первую очередь werf — это opinionated solution, построенный на базе Helm и других стандартных проектов для сборки и деплоя в Kubernetes. Утилита встраивается в привычную CI-систему (GitLab, GitHub…) и вызывается оттуда для сборки/тегирования/деплоя образов. Вместо того, чтобы напрямую работать с Docker/Buildah/Helm, вы работаете с werf. А уже внутри неё — привычные технологии с доп. фичами и "обвязкой", чтобы процесс сборки-деплоя шёл по opinionated workflow, был предсказуемым и надёжным.
Официальный логотип к 10-летию подвезли:
Пару месяцев назад в LinkedIn мелькал вот такой интересный кейс в защиту OpenTofu.
Многие, конечно, но с категорическим «нет» я бы поспорил :-) Из статистики по Linux v6.8, в топе Most active 6.8 employers By changesets помимо собственно компаний есть категории Uknown (7.5%) и None (5.3%). В топе по contributions в Kubernetes за последний год — на пятом месте категория Independent вместо компании.
Такой моделью (Post-Open Source) занимается Bruce Perens:
https://www.theregister.com/2023/12/27/bruce_perens_post_open/
DragonflyDB - это не Open Source, они под лицензией BSL (если она устраивает, то и сама Redis почему нет).
Консультанты в области Kubernetes и cloud native. Авторы концепции GitOps. Авторы множества Open Source-проектов для экосистемы Kubernetes, самый известный - Flux, который недавно стал graduated project в CNCF.