Мы используем технологии vSphere для виртуализации, и мне поручено разработать масштабируемую инфраструктуру приложений. Я больше знаком с AWS.
Изучая масштабирование, я не уверен, что понимаю смысл масштабирования контейнеров, таких как Docker. Скажем, у меня есть одна виртуальная машина с 32 ГБ оперативной памяти, на которой работают наши контейнеры докеров. Внезапно появляется большой трафик и рабочая нагрузка, поэтому я хочу сбалансировать нагрузку и масштабировать ее. Если я запускаю больше идентичных контейнеров на этом сервере, я не выделяю новые ресурсы для приложения для балансировки нагрузки.
Итак, как я могу оправдать использование приложения для управления контейнерами для масштабирования контейнеров докеров на лету, когда это просто не помогает решить проблему и почему это предлагается в качестве решения для балансировки нагрузки?
РЕДАКТИРОВАТЬ 1: Из ответов ... 2 виртуальных сервера, где у моих контейнеров есть место для роста и сжатия. 2 сервера занимают 128 МБ ОЗУ. Это 128 МБ оперативной памяти, которую другие системы на той же серверной стойке могли бы использовать, если бы им это было нужно, но вместо этого я использую 128 МБ для двух своих виртуальных серверов. Этого я не хочу, я хочу, чтобы выделенные мне ресурсы росли и сокращались. Итак, если бы мы делали виртуальные машины вместо контейнеров, я бы развернул другую виртуальную машину с 64 МБ ОЗУ и / или остановил виртуальные машины, чтобы освободить оперативную память на лету. Я до сих пор не понимаю преимущества масштабирования контейнеров по сравнению с масштабированием виртуальных машин. Это не дает мне дополнительных ресурсов для запуска моего приложения и не сокращает мои ресурсы, чтобы другие системы могли иметь мои ресурсы.
Истоки Kubernetes в качестве операционной системы контейнера были с Google, изобретающим кластер для планирования заданий. (Виртуальные машины были для них слишком тяжелыми.) Они уже запускали миллионы контейнеров на машинах, которые они не скажут, сколько. Масштабирование множественных узлов было дано с самого начала.
Элементы этого дизайна можно уменьшить.
Скажем, у экземпляра контейнера 1 ГБ ОЗУ, этого достаточно, чтобы делать что-то интересное, например веб-сервер. Также предположим, что у вас есть 128 ГБ ОЗУ на физическом сервере. Но одного нет, поэтому для обеспечения высокой доступности у вас есть два физических сервера. Независимо от того, разделяете ли вы вычислительные ресурсы на виртуальные машины, в общей сложности имеется около 200 контейнеров.
Поскольку каждое приложение является легким, оно может иметь множество контейнеров, что позволяет выполнять постепенные обновления и масштабирование. Возможно, API использует 4 контейнера, веб-сайт, работающий на нем, - 2, а некоторые связанные пакетные задания - еще 2 контейнера. В нашем воображаемом кластере есть емкость для пары десятков таких приложений на основе микросервисов, что является довольно плотной упаковкой. .
Услугу веб-сайта можно расширить до большего количества контейнеров. Если в совокупности требуется больше вычислений, в кластер можно добавить больше узлов. Kubernetes может автоматически масштабироваться в обоих этих измерениях.
В качестве аналогии рассмотрим физический транспортный контейнер. Разгрузка корабля не особо заботится о наземном транспорте. Всегда больше поездов, увозящих стандартные контейнеры. Более крупные узлы = более длинные поезда. Масштабирование = больше поездов. Тем не менее, существуют специальные тяжелые грузы, это базы данных и тому подобное, которые нелегко поместить в контейнеры.
Автомасштабирование разработано для среды с несколькими машинами. Будь то «голое железо» или виртуальные машины, вы можете использовать ресурсы чужих машин, чтобы не отставать от нагрузки, поступающей на ваши контейнеры.
Просто взгляните на "Автомасштабирование в Kubernetes"(который является одним из самых популярных инструментов оркестровки контейнеров).
Кроме того, если вы переместите свои приложения в облако, автомасштабирование станет очень простым, и именно там вы увидите весь его потенциал в действии.
Но вы можете, например, установить локальный кластер машин, который будет автоматически масштабировать ваши приложения до точки, в которой серверы будут полностью загружены. Например, вы можете настроить кластер Kubernetes локально (не в облаке).
Полезные ссылки:
MetalLoadBalancer: Kubernetes On-Prem / BareMetal LoadBalancing
Служба балансировки нагрузки TCP Kubernetes локальная (не облачная)