Комментарии 25
ну вот уже есть Openshift с ядром кубера. Но в нем я вижу тенденции - собственные фичи депрекейтят в пользу нативных кубернетесовских.
Но как минимум это платное решение, с отдельной документацией, примерами, вебконсолью и расширениями.
Есть еще?
Rancher manager/harvester
наш Cozystack, тот же Deckhouse
это, кстати, круто, что депрекейтят свое в пользу нативного куберовского. так цельность всей экосистемы будет поддерживаться. кстати, опеншифтовский UI можно было бы сравнить с KDE или GNOME — типа, графическая пользовательская оболочка) Хорошо, если их будет много, для альтернативы. И хорошо, если облачных/контейнерных дистрибутивов тоже появится много — разные сборки на основе Kubernetes вместе с упакованным ПО типа баз данных, Kafka и т.п.
Ну deploymentConfig был почти Deployment, но некоторые фичи были полезными. В кубернетес они эти фичи не законтрибьютили
Всегда есть вариант, что они хотели, но мейнтейнеры K8s решили этого не делать — ну или были какие-то технические причины не отдавать это в сообщество (какие-то проблемы в дизайне или что-то, что в будущем могло бы привести к каким-то потенциальным проблемам). В общем, было бы интересно почитать, почему они их депрекейтнули, хотя всегда есть вариант и того, что просто юристы против или это компонент какой-то бсекретный код» содержал и его было «нельзя» отдавать а то врагу вокруг сразу поймут, как RedHat забороть))
Вот ответ редхатовца на стековерфлоу, если вдруг любопытно))
A DeploymentConfig (DC) in OpenShift is more or less equivalent to a Kubernetes
Deployment, nowadays. Main difference (besides that one is usingReplicationControllerand the other usingReplicaSetas you rightly pointed out) is that
there are a few things you can do with a
DeploymentConfig(around triggers) that you can't do with aDeployment.
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 predateDeployment'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. WithDeploymentConfig's that was not the case. Over time one would expect thatDeploymentConfig's are phased out in favor ofDeployment's but I can't give you a timeline. If portability is your primary concern, I'd say, useDeployment'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 не взяли в апстрим, а потом объекты, которыми он оперирует, устарели, и его в итоге депрекейтнули.
История заходит на второй круг. Был же mesos - который прям оркестратор, вот тебе ресурсы, абстракция и менеджмент, пиши всё что надо... Да, у него свои проблемы были, одна сборка чего стоила. Появился кубик и все туда побежали..
На фоне этого, тот Hashicorp Nomad появился, который архитектурно, намного более грамотно построен и всё там было перспективно... но опоздал на рынок, а потом уже просто перестал успевать.
Потом ещё что-нибудь сделают - аля кубик, но без лишнего, и это будет 3ий круг.
Конечно, "вынести из драйверов и system space часть кода в user spacе и отдать на откуп другим" поможет ситуации. Но это и есть - давайте напишем nomad/mesos
еще есть https://www.proxmox.com/en/
проксмокс - это же вообще про другое
Сравнить гипервизор и систему управления контейнерами эт конечно жестко
В PVE есть возможность запуска контейнеров в кластере, но по возможностям не дотягивает даже до Docker Compose.
"Кубернетис" и "готовое ПО" в одном предложении?! Ну разве что если у вас кластер крутит домашнюю автоматизацию на Raspberry Pi... От голых Кубернетисов до реального использования дистанция именно что как от линуксового ядра до условного Дебиана.
Да, именно в одном предложении. И в тексте этот тезис разъясняется. Речь о том, что инженеры не берут и не собирают себе Линукс из ядра каждый раз, когда инфру собрать надо. А с кубернетесом такой привычки нет — его воспринимают как готовое ПО, т.е. ПО, с которым работает инженер напрямую: берет кубы и строит на них инфру. Нет массовой привычки не трогать кубернетес сам по себе, а брать готовые дистрибутивы. Так что всё логично. И готовое ПО тут во вполне конкретном смысле.
Линукс это есть ядро, если что. Люди из The Debian Project берут ядро, берут Гном с Кедами, и с помощью apt и такой-то матери делают из этого Дебиан, которым уже можно пользоваться. Точно так же люди из инфры берут Кубернетисы, берут Хелм, или Арго, а потом на основе этого делают инфраструктуру. Голые Кубернетисы, как и голое ядро, сами по себе мало полезны, это только строительный блок
Я в курсе, что такое ядро Linux) Корректное сравнение было бы таким (и именно об этом я писал): люди из дебиан — это как люди из опеншифта, а люди из инфры — это инженеры в каждой третьей-четвертой компании плюс ещё те, кто дома какие-то нагрузки гоняет в пет-проектах. Если бы в каждой третьей-четвертой компании сисадмины собирали свой дистрибутив Linux из ядра или всего остального, ваше сравнение и аргумент были бы корректными. А так вы просто повторили ровно то же самое, что я написал в статье, только считаете, что это статье противоречит. Но нет, как раз всё написанное вами подтверждает содержание статьи.
Ванильный кубернетес постоянно рассматривается как альтернатива платформам и дистрибутивам. Вот именно в этом контексте употребляется слово готовое.
Ну и чему является альтернативой ванильный Кубернетис? Он же искаропки почти ничего не умеет (хотя и многое может). Хочешь запустить внутрь траффик – понимай ingress controller. Хочешь сохранить данные – поднимай provisioner. Хочешь читать логи – поднимай, например, fluentbit, и еластик с кибаной.
Kubernetes явно не хватает простых инструментов управления
Расширяемость его граничит с удобностью, первоначальное внедрение это или облака или 2 человека в отделе занимающихся внедрением и постоянной поддержкой
по сути сценарные инсталяции в 2-3 клика для 5-10 сценариев внедрения, по моему очевидны и непонятно почему не внедрены, интереса нет для малого бизнеса пилить
вечно грызть миллионы yaml ....
Вообще без кубернетес сценарного развертывания виртуальных машин тоже интересный и перспективный подход, не требующий кучу админов профильников кстати, нечто подобное реализовывает vmware, но там опять ушли в сторону корпораций.....
PS мое видение
за ошибки прошу прощение
Если не прав, то поправьте
CNCF не будет заниматься допиливанием K8s под разные типы бизнеса, их цель (и это разумно) — сделать универсальный инструмент с возможностями тонкой настройки под разные задачи и типы бизнеса. Адаптировать под себя — уже задача тех, кто K8s использует или зарабатывает на собственных контейнерных платформах.
Кубернетисам кучи всего не хватает, два человека это ещё очень оптимистично...
Альтернативой платформам. Попытаюсь объяснить еще раз: если вы сисадмин небольшой компании, вы не станете брать Linux Kernel и накручивать на него всякое. Но если вы отвечаете за контейнерную инфраструктуру небольшой компании, вы берете Kubernetes и накручиваете на него всякое. Именно об этом я и писал в статье, именно это и скрывается за словом самодостаточное. Хватит ли K8s для построения инфры? Конечно, нет. Но именно как на ПО на него смотрят — просто такое ПО, которое надо всяким обвесить.
Что касается ироничного вопроса про ванильный куб как альтернативу. Зайдите в любой чатик по Kubernetes или DevOps, посмотрите сейл-презентацию любой контейнерной платформы, там всегда будут такие варианты: платформа 1, платформа 2, инфра на базе ванильного кубера.
если вы сисадмин небольшой компании, вы не станете брать Linux Kernel и накручивать на него всякое.
В маленькой компании с одним сервером как раз можно зафигачить LFS. Но если я не хочу с ним связываться, то Дебиан и ЦентОс существуют.
если вы отвечаете за контейнерную инфраструктуру небольшой компании, вы берете Kubernetes и накручиваете на него всякое.
Потому что других вариантов нет. И никогда не было.
Что касается ироничного вопроса про ванильный куб как альтернативу.
Вопрос неироничный.
Зайдите в любой чатик по Kubernetes или DevOps, посмотрите сейл-презентацию любой контейнерной платформы
Извините, писать ваш ответ за вас я не буду.
EDIT: Рано отправил.
Неизбежное будущее Kubernetes: почему оркестратор должен пойти по пути Linux Kernel