Назад | Перейти на главную страницу

Почему не все просто используют самые дешевые серверы при использовании кубернетов?

Недавно я много узнал о Kubernetes и узнал, что Kubernetes может автоматически масштабировать ваши контейнеры по горизонтали и добавлять серверы в пул узлов, когда это необходимо (поставщик облака должен поддерживать эту функцию, чтобы это работало, конечно). Например, когда контейнеры на сервере превышают 70% ресурсов на этом сервере, добавляется новый сервер, и вам автоматически будет выставлен счет в соответствии с количеством часов работы каждого сервера. Это поддерживают крупные облачные провайдеры, такие как GCP и AWS.

Итак, я подумал, почему бы просто не выбрать самые дешевые доступные серверы и позволить Kubernetes масштабироваться с этими серверами? Насколько я понимаю, нет необходимости использовать серверы за 100 долларов в пуле узлов, если вы можете использовать серверы за 5 долларов. Конечно, 100 долларов могут справиться с большей нагрузкой, но если вы используете серверы за 5 долларов, Kubernetes просто автоматически добавит для вас новые серверы.

Почему есть даже варианты использовать более дорогие серверы с управляемым Kubernetes? Почему не все просто выбирают самые дешевые серверы?

В уравнении много всего.

Как низко вы действительно можете опуститься? Один из ключевых ингредиентов - насколько маленький ваш стручок. Если приложению в одном из ваших модулей требуется 4G RAM, то разделение 1 сервера 8G на серверы 4x2G означает, что приложение теперь не имеет узла для запуска.

Добавьте накладные расходы. У каждого узла есть накладные расходы на запуск Kubernetes. Есть также DaemonSets, которые запускаются на каждом узле, что увеличивает накладные расходы. Если вы удвоите количество узлов, вы удвоите количество реплик для DaemonSet, что увеличивает стоимость запуска кластера. Даже без них есть накладные расходы на ОС, дистрибутив Linux, kubelet и другие компоненты Kubernetes. Чем меньше узел, тем больше процент нагрузки на узел - это просто накладные расходы на запуск узла, а не на выполнение ваших приложений.

Фактор накладных расходов на управление. Да, инфраструктура как код, группы автоматического масштабирования и т. Д. Помогают. Но чем больше у вас узлов, тем больше вам нужно управлять, отслеживать и отлаживать при возникновении проблемы.

Фактор в сети. Чем больше узлов, тем больше сетевой трафик между узлами, который медленнее, чем виртуальная сеть внутри узла через мост Linux. Облачные провайдеры также имеют тенденцию значительно ограничивать сеть на более мелких узлах, что приводит к тайм-аутам и задержкам, которые могут сделать приложение непригодным для использования.

По моему опыту, компании быстро получают около 10 узлов для обеспечения высокой доступности. Вам нужно, чтобы на оставшихся узлах было достаточно емкости, чтобы обрабатывать отказоустойчивые контейнеры с неработающего узла. При наличии 10 узлов это означает, что для обработки одного неработающего узла в кластере остается чуть более 10% дополнительной емкости. Если бы у вас было только 3 узла, каждый узел нужно было бы использовать менее чем на 2/3, чтобы справиться с выходом одного узла из строя. Прежде чем эти компании дойдут до 20 узлов, они начнут масштабироваться до более крупных узлов. Это позволяет управлять обновлениями узлов в кластере с помощью небольшой команды и минимальной автоматизации. В определенный момент затраты на более крупные узлы перевешивают затраты на дополнительные затраты на управление для запуска большего количества узлов, и они возвращаются к горизонтальному масштабированию для увеличения емкости.

Независимо от Kubernetes, главные проблемы больших центров обработки данных - охлаждение, питание и пространство. Серверы высокого уровня обычно требуют меньшего вмешательства в работу, компактны и энергоэффективны. Все жестче, в конечном итоге они более рентабельны.

Хитрость заключается в том, чтобы найти оптимальный модуль расширения.