All streams
Search
Write a publication
Pull to refresh
84
0
Тимур Тукаев @TimurTukaev

Head of Marketing @ Ænix, Open Source Enthusiast

Send message

Да, именно в одном предложении. И в тексте этот тезис разъясняется. Речь о том, что инженеры не берут и не собирают себе Линукс из ядра каждый раз, когда инфру собрать надо. А с кубернетесом такой привычки нет — его воспринимают как готовое ПО, т.е. ПО, с которым работает инженер напрямую: берет кубы и строит на них инфру. Нет массовой привычки не трогать кубернетес сам по себе, а брать готовые дистрибутивы. Так что всё логично. И готовое ПО тут во вполне конкретном смысле.

Вот ответ редхатовца на стековерфлоу, если вдруг любопытно))

DeploymentConfig (DC) in OpenShift is more or less equivalent to a Kubernetes Deployment, nowadays. Main difference (besides that one is using ReplicationController and the other using ReplicaSet as you rightly pointed out) is that

  1. there are a few things you can do with a DeploymentConfig (around triggers) that you can't do with a Deployment.

  2. DeploymentConfig's are first-class citizens in the Web console.

The reason DeploymentConfig's exist is because we (Red Hat) are innovating. In other words: DeploymentConfig's predate Deployment's and while we're always trying to propose these innovations upstream, they are not always accepted by the community as is. For example, in the case of RBAC, the stuff we had in OpenShift was accepted upstream and that's why you have the same RBAC resources etc. now in OpenShift and Kubernetes. With DeploymentConfig's that was not the case. Over time one would expect that DeploymentConfig's are phased out in favor of Deployment's but I can't give you a timeline. If portability is your primary concern, I'd say, use Deployment's.

А вот что они говорят у себя на сайте:

The current implementation of DeploymentConfigs is based on management of ReplicationController objects. However development of ReplicationController has ceased and upstream recommends to use ReplicaSet objects instead.

In addition, the DeploymentConfig API is a Red Hat OpenShift Container Platform specific API that is not available in other Kubernetes distribution and in fact has been superset with Kubernetes Deployments that are available in all Kubernetes distributions.

В общем, насколько я могу судить, тут две причины: изначально DelploymentConfig не взяли в апстрим, а потом объекты, которыми он оперирует, устарели, и его в итоге депрекейтнули.

Всегда есть вариант, что они хотели, но мейнтейнеры K8s решили этого не делать — ну или были какие-то технические причины не отдавать это в сообщество (какие-то проблемы в дизайне или что-то, что в будущем могло бы привести к каким-то потенциальным проблемам). В общем, было бы интересно почитать, почему они их депрекейтнули, хотя всегда есть вариант и того, что просто юристы против или это компонент какой-то бсекретный код» содержал и его было «нельзя» отдавать а то врагу вокруг сразу поймут, как RedHat забороть))

это, кстати, круто, что депрекейтят свое в пользу нативного куберовского. так цельность всей экосистемы будет поддерживаться. кстати, опеншифтовский UI можно было бы сравнить с KDE или GNOME — типа, графическая пользовательская оболочка) Хорошо, если их будет много, для альтернативы. И хорошо, если облачных/контейнерных дистрибутивов тоже появится много — разные сборки на основе Kubernetes вместе с упакованным ПО типа баз данных, Kafka и т.п.

Квантовые компьютеры, насколько я понял, дают преимущество только на очень ограниченном количестве задач. Например, задача коммивояжера или всякая криптография.

Вот юикс-тест) Списки давайте текстом, а не картинками. К тому же здесь использование и картинок вместо текста вообще никак не оправдано. Продублировать текст картинкой было бы ок. Сделать только картинки — так себе решение.

ВК, не жадничай, давай всем дошедшим до конца футболешники. На увольнениях норм денег сэкономили, несложно будет:)

Ребята все молодцы. Понятно, что это скорее реклама ивента Хабра, но за героев статьи искренне рад. Хорошо, что тесть проекты, которые позволяют новичкам быстрее влиться в профессию.

Эта статья, как старики в гугл, попала на хабр по квотам, похоже))

Так я не понял, автор по процессу онбординга дал обратную связь до сообщения об увольнении или после? Ну и интересно, что там за ОС была, если из-за этого уволили.

Яндекс говно просто разводит с пишущими людьми. Любят на миллионы дней тестовые фигачить ещё до интервью с эйчаром и прочей мутью голову кушать. А, ну и платить при этом ниже рынка. Наверняка автор устраивался на вакансию вроде редакторам нейросетей на арабском или что-то такое. У них куча такого скама на hh.ru постоянно лежит с низкой зарплатой и завышенными требованиями.

Всегда пожалуйста) Но это честный опен сорс, мы даже в CNCF проект передаем сейчас. Так что не вижу проблем подобные новости рассказывать на Хабре. Немало читателей пробуют и используют у себя в инфре. Некоторые даже радуются))

Я не вам отвечал, на комментарий выше вашего) Духовные ценности тут никак не анализировал)

Ну я бы ещё по-другому вопрос поставил. В клиент от Дурова кто-то всё ещё тоже наивно считает безопасным?)) Те же яйца, только в профиль)

Учитывая, что там стек сильно отличается от антивирусного. И учитывая, что и «антивирус» уже давно не один продукт и не одна команда))

Самый интересный вопрос, каков прононсиэйшен вот у этого: Appicenter?)) Эпицентр? ЭппАйЦентр?))

Это нужно в первую очередь бизнесу, чтобы риски блокировки снизить, скорее всего. Время такое, что забанить могут в любом сервисе))

Как-то раз в 6 вечера я сел немного поработать и отредактировать статью. В 6 утра я обнаружил себя изучающим уже примерно 100-ю статью на википедии по истории норвежкого блэк метала 80-х и 90-х. Я разобрался, кого грохнул Викернес, кто за что отвечал в Майхэме, откуда пошел классический блэкушный грим, какие поджанры были популярны в разное время и какие группы за них отвечали. А ведь я не слушаю блэк и дэт в принципе:) Мой потолок тяжметала — это My Diyng Bride и Tiamat. И то, включаю их раз в три года и не дольше чем на пару минут:)

Но вопрос-то вот в чем — а это точно надо лечить? Потому что в контексте работы часто подобные экскурсы в будущем пригождаются и помогают.

Information

Rating
Does not participate
Location
Россия
Works in
Registered
Activity

Specialization

Marketing Director, Редактор
Lead
People management
Project management
Content Marketing
Literary editing
Linux
DevRel