Kubernetes на собственной инфраструктуре: «за» и «против» приватных облаков

[build_your_web]

То, что в статье называется AaaS обычно принято называть SaaS, а инфраструктурные сервисы (в т.ч. DBaaS) являются частью PaaS.

[VolCh]

Вариантов с кубкрнетес много, от полностью managed кластера до покупки голого железа. Привлекательным выглядит разворачиванием своими силами на VDS от хостера с быстрой возможностью докупить/сдать их а-ля AWS EC2. Это публичное или приватное облако?

[gecube]

Это публичное или приватное облако?

это не облако вовсе ) публичное — это облако, которое мультитенантное и которым может пользоваться неограниченное множество клиентов. Приватное — очевидно, на своих ресурсах. Является ли Кубер на "чужих" VDS — публичным облаком — точно нет. Приватным — можно подискутировать, но там все равно трафик идет через публичные сети, поэтому это какое-то странное решение

[VolCh]

Тут используется публичный низкоуровневый IaaS (VDS on demand), на базе которого сами разворачиваем приватный PaaS (автоскейлинг кубер) для своих пользователей, возможно предоставляя мультитенант публичный SaaS для своих клиентов. С моей точки зрения.

А что странного? Не возимся с железом и гипервизорами, а всё остальное, начиная с версий и конфигов элементов k8s, сами контролируем. А как трафик ходит, по-моему, дело десятое. Или приватное облако — это исключительно свои ДЦ и каналы между ними?

[gecube]

VDS — это VDS, а, простите, не IaaS. Тем более, что VDS потенциально могут быть на таких ограниченных штуках как OpenVZ (мир его праху). Т.е. IaaS подразумевает более широкий набор примитивов, чем виртуалки (те же вирт сети, разные виды хранения и пр.) + абстракцию в том плане, что ты заказываешь ресурсы (cpu, mem, hdd/ssd, пулы ip) и волен их использовать как угодно, а не каким-то одним навязанным образом как в VDS.

Т.е. это по сути дискуссия такого же уровня, как «если Амазон, ажур и Гугл — облака, то хетцнер — тоже облако» (на самом деле — нет)

[VolCh]

В моём понимании провайдер VDS превращается в облачный IaaS, когда есть API по быстрому поднятию/сворачиванию без вмешательства саппорта провайдера. В целом же IaaS для меня не предполагает каких-то конкретных элементов. Переход с on premise инфраструктуры на IaaS может быть постепенным, любой её элемент можно переводить на IaaS модель независимо.

Ну а про заказ ресурсов немного забавно слышать, если считать AWS и GCE типичными представителями публичных облачных IaaS провайдеров: заказ почти всех сервисов, относящихся к cpu, mem сводится к выбору инстансов. Нельзя сделать "добавьте пару ядер и десяток гиг памяти к этому инстансу EC2 или RDS MySQL", нельзя приобрести пул ядер и гигабайт памяти и динамически их распределять по инстансам. Да и с расширением/урезанием HDD/SDD не всё хорошо. В общем, если не брать cloud native сервисы типа S3, то те же VDS, разве что часть из них предварительно настроена и тобой лишь минимально конфигурится. А хочешь отмасштабироваться вертикально — заказываешь новый инстанс и переносишь старый сам классическими методами или более характерными для VDS типа снять и развернуть снэпшот

[gecube]

Ну а про заказ ресурсов немного забавно слышать, если считать AWS и GCE типичными представителями публичных облачных IaaS провайдеров: заказ почти всех сервисов, относящихся к cpu, mem сводится к выбору инстансов

Это забавно ровно до того момента, когда реально не задумываешься о том, как это внутри устроено. Понятно, что амазону и GCE не выгодно клиенту продавать несбалансированные машины (это как минимум гарантии ресурсов и упаковка ресурсов в гипервизоры, чтобы не оставалось лишнего) и это не фуфло-облако, где переподписка ресурсов (и опять тогда для клиента нет никаких гарантий по ресурсам). Так что гугль и амазон идут правильной дорогой на самом деле.

Т.е. в сухом итоге — Вы вольны купить сколько угодно ресурсов, но в лимитах облака на учетку (1) и в какой-то пропорции, в которой Вам их продают (2). И никакой проблемы в (2) на самом деле нет.

[I_N_K]

Все таки моя статья больше про PAAS (kubernetes с микросервисами) чем про IAAS. В нем немного другой подход — ресурсы ноды делятся на уровне контейнеров, контейнеры разные а машины (node) более менее типовые (одинаковые по ресурсам). А вертикальное масштабирование — в рамках pod-а, естественно ограничено сверху размерами node. И вот это вот управление — добавьте сюда одно ядро, а туда 512 Мб оперативки уходит на другой слой — в контейнеры. Оптимизация на уровне контейнеров — соотношение ram/cpu подбирается для сервиса отдельно, а дальше горизонтальное масштабирование за счет количества экземпляров этого сервиса. Грубо говоря — не справляется один землекоп — берем десять землекопов, а не одного с очень сильными руками. Это не для всех задач оптимально и требует специальных архитектурных решений, но имеет свои плюсы. Например, можно заказывать типовые инстансы IAAS. Ну и на одинаковые bare-metal сервера хорошо ложится.
А если вспомнить про FAAS, так там еще дальше пошли. Все размазывается по серверам еще более ровным слоем.
Кстати, есть довольно забавная проблема, про которую как то не принято говорить. По какой то причине все считают инстансы и ядра стандартными. никто не пытается их сравнивать или как то измерять. По смартфонам устраивают жесточайшие битвы у кого сколько попугаев — по виртуальным ядрам тишина. Нет специализированного софта, нет статей DIY как понять какой уровень переподписки, нет встроенных в код метрик. Это мне нужна шапочка из фольги или никому действительно не интересно? Как вообще люди сайзинг делают, если точно не знают где это крутится будет?
Может стоит написать об этом?

[gecube]

как понять какой уровень переподписки

+++++

Это мне нужна шапочка из фольги или никому действительно не интересно?

нужно.

Как вообще люди сайзинг делают, если точно не знают где это крутится будет?

В случае с амазоном, как я понимаю, есть два подхода, которые друг друга дополняют:

1. все инстансы амазона типовые, следовательно, ожидания от их производительности понятны. Вплоть до того, что я в доке на какой-нибудь эластик вижу четкое название инстанса, который нужен.
2. Всегда нужно стресс-тестировать свою инфраструктуру. Это дает понимания — сколько реально ты можешь выдержать клиентов/запросов. И соответственно — выбрать более подходящий инстанс.

[VolCh]

Это забавно ровно до того момента, когда реально не задумываешься о том, как это внутри устроено.

В том-то и дело, что понимая как устроено, забавно слышать "заказываешь ресурсы (cpu, mem, hdd/ssd, пулы ip) и волен их использовать как угодно, а не каким-то одним навязанным образом". Не заказываешь ты у Амазона ресурсы, заказываешь те же VDS с комплектом ресурсов, плата за которые не зависит от реальной нагрузки. В некоторых случаях можно "обойти систему" заказывая/освобождая одно-двухядерные конфигурации для стэйтлесс веб- или апп-серверов по текущей нагрузке (правда встаёт вопрос оверхеда на ОС и т. п.), но вот случаях стэйтфулл систем, слабо рассчитанных на горизонтальное масштабирование (те же SQL), динамически добавить ядер или памяти системе не получится, нужно менять инстанс, как в старых добрых DS/VDS

[I_N_K]

Мне казалось, что как раз для того, чтобы не заниматься таким микроменеджментом и развивают решения вида DBAAS. Например Amazon Aurora Serverless — декларируется автомасштабирование базы под нагрузку. В приватных облаках таких решений пока мало. Виртуальная инфраструктура, конечно, позволяет добавлять ресурсы в любых пропорциях, но мы возвращаемся к старой проблеме — невозможности бесконечно вертикально масштабировать SQL сервера. Это тупиковый путь. Поэтому и идут все в сторону горизонтального масштабирования, поэтому и нет такой сильной потребности в тонкой настройке серверов Амазона.
Моя логика такова — если бы такая бизнес потребность была, ее бы уже удовлетворили. Технически это не очень сложно.

[VolCh]

Да, развивают их, чтобы не заниматься. Но подходит не всем: тут и вопросы цены, и вендор-лока (очень многие так называемые Cloud Native, на поверку оказываются CloudVendorName Native), и, как где-то слышал, "утилизации имеющихся человеческих ресурсов".