Комментарии 19
И так в статье описали что такое kubernetes, написали что есть платформы от поставщика услуг или можно самим. Но не написали кое что еще. Хотелось бы дополнить:
— Вне зависимости от того, какой у вас кубер (вендорский или опенсорс). Вам в любом случае надо иметь грамотного специалиста, который поможет разработчикам деплоить, мониторить, логировать и кастомизировать приложения для работы в кубере.
— Если у предприятия нет на это средств, то данному опыту учатся разработчики в зависимости от желания\времени\или свободные от пиления новых фич (а как мы знаем, разработчиков именно для этого и нанимают, отвлекаться на изучение инфраструктуры и как работает весь комбайн нет времени).
— Если организация все таки внедрила кубернетес и использует его. То со временем приходит понимание, что самый лучший плюс от платформы — это быстрая переносимость, следовательно «мы можем быстро задеплоить прод в любой кластер у любого поставщика услуг и как становится пофиг на своих железяках или от вендора».
И финал, иногда оказывается не пофиг где запускается ваш кластер. И в 99% случаев клиенту надо переплачивать +20% к стоимости виртуалок, если они работают как «manage service». И с учетом специфики работы приложения выбирается то решение, которое выбирается (на своих мощностях, если нужно много процессоров и ОЗУ или от облачного поставщика, если «и так хватает»).
— Вне зависимости от того, какой у вас кубер (вендорский или опенсорс). Вам в любом случае надо иметь грамотного специалиста, который поможет разработчикам деплоить, мониторить, логировать и кастомизировать приложения для работы в кубере.
— Если у предприятия нет на это средств, то данному опыту учатся разработчики в зависимости от желания\времени\или свободные от пиления новых фич (а как мы знаем, разработчиков именно для этого и нанимают, отвлекаться на изучение инфраструктуры и как работает весь комбайн нет времени).
— Если организация все таки внедрила кубернетес и использует его. То со временем приходит понимание, что самый лучший плюс от платформы — это быстрая переносимость, следовательно «мы можем быстро задеплоить прод в любой кластер у любого поставщика услуг и как становится пофиг на своих железяках или от вендора».
И финал, иногда оказывается не пофиг где запускается ваш кластер. И в 99% случаев клиенту надо переплачивать +20% к стоимости виртуалок, если они работают как «manage service». И с учетом специфики работы приложения выбирается то решение, которое выбирается (на своих мощностях, если нужно много процессоров и ОЗУ или от облачного поставщика, если «и так хватает»).
Если запускать Kubernetes, не имея какой-то популярной платформы виртуализации, то не получите всех преимуществ программы
WAT?
Мне кажется не совсем корректно поставлено противопоставление. Что такое вендорский кубернетес? Что такое опен-сурс?
Я бы разбил на несколько другие категории
измерение 1 — облако vs bare-metal
измерение 2 — managed k8s vs собственное развертывание
измерение 3 — вендорский k8s (openshift, rancher, managed в принципе сюда тоже можно засунуть) vs vanilla/open-source
При этом не все комбинации жизненноспособны. Но вот тот Amazon и Azure как "обломок" облака уже вроде можно втащить в свой контур — первый предлагает форпост, второй AzureStack (и, да, вроде ведь в МТС предлагают такую услугу?)
Насчет интеграций — там все сложно в первую очередь при развертывании в своем контуре на baremetal — действительно приходится городить всяческие костыли и подгонять остальную инфру. Но в целом то же PV© можно сделать. LB — если очень надо — тоже. Поэтому пассаж про виртуалки не понял. Или речь про то, что нужно строить кластер поверх какого-нибудь vmware или нутаникса? Ну, да — тоже вариант
В недостатках опенсурсного — отсутствие автоскейлинга. Ну, е-мае… Это больше от нижележащей платформы зависит...
Добавлю 5 копеек про новые сервисы. Вот взять «облака», которые МТС и другие российские «гиганты хостинга» (которые рассчитывают на бизнес-покупателей) спешно представили в минувшем году: все, что «облачное», продается только после оформления договора (или допника к существущему договору), с прописыванием в договоре оплачиваемых ресурсов. Еще раз: облако от Vmware, но оплата идет, по сути, как за VPS, а не как за облако (per-use оплата? Увы, не увидите — платите за квту ресурсов, которую заказали).
Это и неплохо, может быть (потому что oversell в принципе невозможен, но облака овеселом и не славятся. А вот масштабированием на лету — да, славятся, но только какое тут масштабирование, когда ты должен допник полнедели согласовывать? Менеджеры идут навстречу, включая (как в России любят говорить, «в ручном режиме») ресурсы в квоту, и прося допник подписать как можно скорее, но это — не API, это вручную, и, хотя это и надежнее просто VPS-ок на нерезервированном хосте, по факту не так приятно, как «облако» (притом, что продается именно как облако).
С кубером в МТС не знаю, но если речь о том, чтобы (как в посте изложено)
то управление, что, вручную работает?! Через тикеты и с реализацией масштабирования через часы, а то и дни? А если нет, то как можно средствами кубера же настроить масштабирование сервиса от нагрузки без того, чтобы заранее ресурсы не оплатить (и не получить, снова, схему соблакомVPS-ками?
Справедливости ради уточню: у других игроков российского рынка ситуация, бывает, что и еще печальнее. Получается, издержки модели бизнеса, когда «облако» запускается не чтобы привлечь юзеров низкими ценами, а затем привязать удобством и числом сервисов, а для того, чтобы и у себя в портфолио иметь что-то, что называется «облако», и его продать тем, кто и там готов потратиться.
Хочу увидеть «российский AWS», но, боюсь, по ряду понятных хабравчанам причин, не увижу.
Это и неплохо, может быть (потому что oversell в принципе невозможен, но облака овеселом и не славятся. А вот масштабированием на лету — да, славятся, но только какое тут масштабирование, когда ты должен допник полнедели согласовывать? Менеджеры идут навстречу, включая (как в России любят говорить, «в ручном режиме») ресурсы в квоту, и прося допник подписать как можно скорее, но это — не API, это вручную, и, хотя это и надежнее просто VPS-ок на нерезервированном хосте, по факту не так приятно, как «облако» (притом, что продается именно как облако).
С кубером в МТС не знаю, но если речь о том, чтобы (как в посте изложено)
Инженер, который запускает кластер, указывает, сколько ему нужно воркеров и с какими параметрами (например, 5 воркеров, каждый на 10 ЦПУ, 16 ГБ оперативной памяти и, скажем, 100 ГБ диска). После чего получает доступ в уже сформированный кластер. При этом воркеры, на которых запускается нагрузка, полностью отдаются клиенту, но весь management plane остается в зоне ответственности вендора (в случае, если сервис предоставляется по модели managed service).
то управление, что, вручную работает?! Через тикеты и с реализацией масштабирования через часы, а то и дни? А если нет, то как можно средствами кубера же настроить масштабирование сервиса от нагрузки без того, чтобы заранее ресурсы не оплатить (и не получить, снова, схему с
Справедливости ради уточню: у других игроков российского рынка ситуация, бывает, что и еще печальнее. Получается, издержки модели бизнеса, когда «облако» запускается не чтобы привлечь юзеров низкими ценами, а затем привязать удобством и числом сервисов, а для того, чтобы и у себя в портфолио иметь что-то, что называется «облако», и его продать тем, кто и там готов потратиться.
Хочу увидеть «российский AWS», но, боюсь, по ряду понятных хабравчанам причин, не увижу.
Хм. У меня есть договора с Yandex, Datafort, GCE. Везде per-use, хотя Datafort за это цену заломил на уровне GCE. Есть обратная схема. У того же Яндекс, можно выкупить квоту, за нормальную скидку. У Google скидка, если виртуалка работает большую часть месяца (у AWS вроде тоже?). Продажей VPS развлекаются разные околораспильные места, но зачем о них говорить.
М1 в рамках услуги M1Cloud automate — оплата per-use. Это пример. Но можно легко упереться в лимиты (т.е. это не ОМОЗОН, где можно масштабироваться на все деньги).
Почему-то МТС говорит, что раз, скажем, диск нарезали, то уж нарезали — не умеют они незанятое пространство блочного устройства отзывать в общий пул — так что платите за всё, уважаемые.
Более того, мне объяснили, что в оплату за проц в машине сразу зааложена оплата лицензии винды на ней. И, если я, условно говоря, нарежу, в рамках своих лимитов, две машины, одну с виндой, другую с centos, то цена за проц будет одинаковой, хотя в линуксовой машине за виндовую лицензию как бы платить незачем.
А все потому, что а) маркетологи посчитали, что такой биллинг будет понятнее суровым энтерпрайз-покупателям и б) потому что они сами за всё заплатили по полной, и надо же эти деньги отбивать без всяких реверансов на «неиспользование».
Грубо, построили они кластер, запустили на нем VMware (с оплатой, понятно, «за всё»), затем MS-у заплатили за право крутить винду — и вот MS не умеет (точнее, конечно, не видит для себя финансового смысла) брать за кусок, когда можно взять бабки за всё, так что продаёт винду сразу на все процы кластера (известная засада HA от MS).
И вот тут смех-смехом, а получается, что рядовые юзеры оплачивают любыевлажные финансовые фантазии правообладателей — потому что хостер на это подписался, а юзеру просто протранслировали цену.
Так что, да, в России как-то невольно задумаешься, нужно ли такое «необлачное облако». Повторюсь, не только к МТС это относится.
Более того, мне объяснили, что в оплату за проц в машине сразу зааложена оплата лицензии винды на ней. И, если я, условно говоря, нарежу, в рамках своих лимитов, две машины, одну с виндой, другую с centos, то цена за проц будет одинаковой, хотя в линуксовой машине за виндовую лицензию как бы платить незачем.
А все потому, что а) маркетологи посчитали, что такой биллинг будет понятнее суровым энтерпрайз-покупателям и б) потому что они сами за всё заплатили по полной, и надо же эти деньги отбивать без всяких реверансов на «неиспользование».
Грубо, построили они кластер, запустили на нем VMware (с оплатой, понятно, «за всё»), затем MS-у заплатили за право крутить винду — и вот MS не умеет (точнее, конечно, не видит для себя финансового смысла) брать за кусок, когда можно взять бабки за всё, так что продаёт винду сразу на все процы кластера (известная засада HA от MS).
И вот тут смех-смехом, а получается, что рядовые юзеры оплачивают любые
Так что, да, в России как-то невольно задумаешься, нужно ли такое «необлачное облако». Повторюсь, не только к МТС это относится.
не умеют они незанятое пространство блочного устройства отзывать в общий пула многие ли умеют? сжатие тонких дисков без выключения виртуалки или миграции на другой датастор.
Про многих не знаю, я про VMware в облаке. Собственно, ОС (гостевая) освобождает незанятые более блоки (trim/unmap), а уж хранилище (внешнее) разбирается, что хранить, а что — только «держать в уме».
Хранилище не знает чего там гостевые системы делают у себя, её дело шуршать блоками данных. А вот хост и хранилище друг друга знают не по наслышке. Но даже на текущий момент для высвобождения блоков занятых гостевой системой требуется либо миграция на другой датастор, либо прыжок со снапшота в прод. Нету такого что бы прям вот так в легкую и без выключения виртуалки вернуть место на хранилище.
Ну или я не знаю об этом.
Ну или я не знаю об этом.
скажем, диск нарезали, то уж нарезали — не умеют они незанятое пространство блочного устройства отзывать в общий пул — так что платите за всё, уважаемые.
в общем-то я не на стороне провайдеров, но это не является проблемой. Обычно же необходимость в месте только увеличивается. Если есть ресайз в большую сторону (а обычно он есть), то проблем нет. А шринкать диски — ну, такое себе. Тогда действительно можно и пересоздать ВМ с переналивкой данных. Хотя иногда и очень хочется сделать это на лету...
Давайте мух от котлет отделим: я был бы рад платить только за хранимые данные, а не за квоту, которая меняется допсоглашением и в течении дней. Как при этом хранилище относится к вопросу — мне не очень важно, но вот эта «резиновость» биллинга как бы является свойством зеркала.
Иначе — это надежная (за счет резервирования нижележащего железа), но VPS-ка.
Иначе — это надежная (за счет резервирования нижележащего железа), но VPS-ка.
«Более того, мне объяснили, что в оплату за проц в машине сразу зааложена оплата лицензии винды на ней. И, если я, условно говоря, нарежу, в рамках своих лимитов, две машины, одну с виндой, другую с centos, то цена за проц будет одинаковой, хотя в линуксовой машине за виндовую лицензию как бы платить незачем.»
У нас в стоимость виртуального процессора не включена оплата лицензии Windows. Она взимается отдельно только для тех виртуальных машин, для которых требуется Windows. Если вам нужно две машины, одна с Windows, а другая с Centos, то машина c Windows будет чуть дороже, чем с Centos. Всегда можно самостоятельно сделать расчеты виртуальной инфраструктуры в калькуляторе на сайте cloud.mts.ru/services/elastic, чтобы убедиться в этом.
У нас в стоимость виртуального процессора не включена оплата лицензии Windows. Она взимается отдельно только для тех виртуальных машин, для которых требуется Windows. Если вам нужно две машины, одна с Windows, а другая с Centos, то машина c Windows будет чуть дороже, чем с Centos. Всегда можно самостоятельно сделать расчеты виртуальной инфраструктуры в калькуляторе на сайте cloud.mts.ru/services/elastic, чтобы убедиться в этом.
«все, что «облачное», продается только после оформления договора (или допника к существущему договору), с прописыванием в договоре оплачиваемых ресурсов. Еще раз: облако от Vmware, но оплата идет, по сути, как за VPS, а не как за облако (per-use оплата? Увы, не увидите — платите за квту ресурсов, которую заказали).»
У нас есть возможность оплаты ресурсов по факту использования — не за квоту. В течение месяца можете свободно использовать ресурсы столько времени, сколько вам надо, можете самостоятельно за минуты создавать новые виртуальные машины – масштабирование на лету, к менеджеру в этом случае обращаться не требуется, платите только за фактическое время использования ресурсов. Оплата за квоту тоже остается, так как ряд клиентов запрашивает именно такой способ тарификации. Поэтому окончательный выбор за вами.
У нас есть возможность оплаты ресурсов по факту использования — не за квоту. В течение месяца можете свободно использовать ресурсы столько времени, сколько вам надо, можете самостоятельно за минуты создавать новые виртуальные машины – масштабирование на лету, к менеджеру в этом случае обращаться не требуется, платите только за фактическое время использования ресурсов. Оплата за квоту тоже остается, так как ряд клиентов запрашивает именно такой способ тарификации. Поэтому окончательный выбор за вами.
del, промах веткой
Второй – отсутствие интеграций. Если запускать Kubernetes, не имея какой-то популярной платформы виртуализации, то не получите всех преимуществ программы. Таких как использование Persistent Volumes
А причем тут платформа виртуализации и PV? Есть достаточно бесплатных сторадж решений для кубера, работающих на нодах, тот же Rook CEPH
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Kubernetes: open source против вендорского