Понимание абстракции, стоящей за узлами и модулями
Я уверен, что вы слышали об этом, но если вы никогда не использовали его или только начинаете, Kubernetes может быть чрезвычайно надежным и запутанным. Конечно, все в глазах смотрящего, но именно так я себя чувствовал, когда только начинал, и я уверен, что я не одинок в этом.
В своих последних работах я много внимания уделял масштабируемости. Я пытался создать решение для потоковой передачи пикселей, что является причудливым термином для потоковых 3D-облачных приложений. Цель легко описать: запуск симуляций Unreal на очень мощных компьютерах, размещенных в облаке, и их потоковая передача в режиме реального времени на персональные устройства людей, что устраняет необходимость владения дорогостоящим оборудованием. Хотя реализация может различаться, по сути она одна и та же: каждому человеку, который пытается получить опыт, должен быть предоставлен выделенный экземпляр.
В этой статье я расскажу об архитектурном решении для рассматриваемого варианта использования. Помимо нескольких замечаний, я постараюсь избегать использования каких-либо терминов Kubernetes, и вы НЕ станете экспертом Kubernetes к тому времени, когда закончите читать эту статью. Моя цель — предоставить читателям правильный контекст, чтобы они могли быстрее познакомиться с такими API, как Kubernetes, и потенциально стать экспертами.
Имея это в виду, давайте начнем!
Визуализация облака
Я всегда думал о Kubernetes как о клиентском инструменте. Хотя это отчасти верно, поскольку у него есть клиентский компонент, на самом деле я смотрел на него с другой стороны. Kubernetes был создан как платформа для управления вашими ресурсами, как правило, в качестве внутреннего поставщика услуг. Я объясню.
Представьте, что у вас есть ферма компьютеров, потенциально тысячи. Компьютеры различаются по возможностям и оборудованию — у некоторых больше ядер, чем у других, а у некоторых больше памяти; но по большому счету у вас есть масса ресурсов. Ваша цель — сдать эти ресурсы в аренду разным арендаторам — вы хотите, чтобы люди платили вам за вычислительную мощность, что-то вроде недвижимости, где вы арендуете пустые места, чтобы люди могли делать все, что захотят. Но что, если у вас есть только квартиры с 4 спальнями, а большинство арендаторов заинтересованы в однокомнатной квартире? Конечно, вы будете сдавать каждому жильцу по одной спальне, и пусть они делят квартиру. Это то, что делает Kubernetes, только с компьютерами.
Kubernetes — это набор инструментов, который реализует оркестрацию по сети компьютеров. Другими словами — это управляющий недвижимостью для компьютеров. Вот некоторые из вариантов использования, для решения которых был разработан Kubernetes:
- Отслеживание всех ресурсов — смотрите, что доступно, что недоступно и что работает со сбоями.
- Если компьютер внезапно перестает работать, возможно, из-за короткого замыкания, ищите альтернативу для размещения арендаторов, которые размещались на этом компьютере.
- Убедитесь, что вещи разделены, чтобы арендаторы не имели доступа к ресурсам, которые им не принадлежат.
- Обеспечьте безопасность, чтобы нежелательные гости не получили доступ к сетям арендаторов, как это делает брандмауэр.
- Репликация клиентских приложений и эффективное разделение входящего трафика между несколькими компьютерами, также известное как «балансировка нагрузки».
Все вышеперечисленное требует системы, которая может старательно отслеживать и управлять всем. Kubernetes предлагает несколько компонентов, которые в совокупности могут достичь поставленной цели. Вот некоторые из этих компонентов, которые, на мой взгляд, концептуально легче понять, чем другие:
- kube-apiserver — сервер REST API, который арендаторы могут использовать для отправки запросов на развертывание приложений в облако.
- kubelet — агент, который устанавливается на каждый компьютер и фактически делает его частью сети Kubernetes. Он отвечает за развертывание клиентских приложений и выполнение проверок работоспособности на основе набора инструкций, отправляемых с apiserver.
- etcd — база данных ключ-значение, в которой хранятся переменные об облаке Kubernetes, например, конфигурации и статус каждого компьютера и приложений, которые должны быть запущены на них. Он используется для координации общесистемных задач. Другими словами — это источник истинности облака в любой заданной точке.
Если вы хотите ознакомиться с полным списком компонентов Kubernetes, представляю вам официальную схему, которую можно найти на официальном сайте Kubernetes:
Как видите, спецификация Kubernetes любит использовать абстракции поверх вещей, с которыми мы уже знакомы. Кластер означает ферму или пул, а узел означает компьютер или машину. В какой-то момент истории узел даже называли миньоном (как обсуждалось в этом выпуске GitHub за 2014 год). Для меня имена — одна из самых запутанных вещей в Kubernetes, потому что их много, и они не обязательно много значат. Но как только я понял, что Kubernetes — это не более чем фреймворк для управления пулом ресурсов — все пошло гораздо быстрее. Для справки вы можете заглянуть в этот словарь, в котором есть полный список терминов Kubernetes и их определений.
Хранение — это совсем другая проблема
Подобно сети компьютеров Kubernetes, когда дело доходит до хранилища, существует сеть жестких дисков и разные стратегии их использования. Прежде чем я продолжу, давайте подумаем о некоторых пограничных случаях, когда дело доходит до хранения:
- Арендатор хотел бы загрузить игру размером 120 ГБ, но доступны только жесткие диски объемом не более 100 ГБ.
- Один из жестких дисков перестал работать, и на нем могли быть важные файлы, критически важные для некоторых арендаторов.
- Расширение / удаление / замена жестких дисков без прерывания повседневной работы арендаторов.
- Все вышеперечисленное при совместном использовании хранилища между компьютерами и сохранении прав доступа на чтение/запись.
Эти проблемы не так просто решить, и они требуют специальных знаний в области хранения и того, как это работает. Некоторые облачные провайдеры предлагают проприетарные управляемые решения для хранения, такие как AWS EBS, GCE Disk и Azure Disk. Но если мы на секунду представим, что у вас есть целая комната, полная жестких дисков, и вы хотите сдать их в аренду потенциальным арендаторам — вы, вероятно, захотите сделать это с помощью решения для работы с большими данными с открытым исходным кодом, такого как Ceph .
Ceph похож на Kubernetes в том смысле, что он управляет кучей жестких дисков, как недвижимостью. Вот диаграмма, которую я взял из Удивительного доклада Росса Терка о Ceph, которая иллюстрирует, как Ceph обрабатывает данные, разбивая их на куски, как кусочки Lego, и сохраняя их на нескольких устройствах. Я не буду вдаваться в подробности того, как это на самом деле работает, потому что кроличья нора может быть довольно глубокой, но вы можете погрузиться в нее:
Вы могли заметить, что Ceph рассматривает аппаратное обеспечение как граф узлов, очень похоже на Kubernetes. Это означает, что при использовании серверной части Kubernetes мы, скорее всего, взаимодействуем с парой кластеров, а не только с одним, что помогло мне лучше понять, как аппаратное обеспечение управляется во всех измерениях.
Это просто HTTP-сервер
Чтобы инициировать вызов API Kubernetes, нам нужно отправить запрос в kube-apiserver. Как упоминалось ранее, kube-apiserver — это компонент, который устанавливается облачным провайдером и является REST-сервером. Соответственно, для запроса серверной части может использоваться любой HTTP-клиент, например, cURL или axios. Однако запросы должны быть авторизованы, а ответы должны быть проанализированы, поэтому вы увидите множество реализаций клиентов Kubernetes, в зависимости от языка и используемой среды. Одним из самых очевидных и популярных клиентов Kubernetes является его инструмент командной строки — kubectl.
С kubectl вы можете легко делать авторизованные вызовы API, а ответы всегда будут парситься и отображаться на экране в читаемом формате, что отлично при работе с терминалом. Мы даже можем использовать kubectl в подробном режиме, чтобы увидеть подробности об основном HTTP-вызове:
kubectl get pods --v=6
На данный момент вы можете думать о модулях как о приложениях (ну, вроде того). Если вы ознакомились со статьей, то, вероятно, понимаете, что они могут работать на любом произвольно выбранном компьютере, в зависимости от того, что было доступно.
Моделирование запроса Kubernetes
Итак, возвращаясь к первоначальной проблеме, с которой началась вся эта статья, — мы хотим подключить пользователей к компьютерам в облаке, чтобы они могли играть в игры, не владея дорогостоящим оборудованием. Когда пользователь завершит работу, занятое оборудование снова станет доступным для размещения следующего пользователя в очереди. Попробуем разобраться с этим!
Нам дано следующее:
- Очередь пользователей.
- Кластер Kubernetes.
- Docker-образ с установленной игрой.
Рекомендуемые характеристики игры для запуска следующие:
- 4 ядра.
- 16 ГБ оперативной памяти.
- 50 ГБ памяти.
- RTX A4000.
Соответственно, мы можем использовать то, что узнали, и описать процесс развертывания следующим образом. Это очень упрощенное и гипотетическое описание, поэтому, пожалуйста, отнеситесь к нему с недоверием:
- Когда пользователь дойдет до конца очереди, отправьте запрос kube-apiserver с URL-адресом изображения и желаемыми характеристиками оборудования.
- Kube-apiserver будет использовать etcd для поиска компьютера с достаточными ресурсами для размещения образа.
- Если что-то будет найдено, kube-apiserver будет использовать идентификатор узла для отправки запроса на развертывание в соответствующий kubelet.
- После успешного развертывания kubelet вернет порт для подключения к игровому потоку.
- Kube-apiserver вернет пользователю игровой порт вместе с IP-адресом целевого компьютера.
- Пользователь может использовать http://{IP}:{port} для подключения к игровому потоку через веб-браузер.
Надеюсь, вам понравился мой пролог о Kubernetes и его основных принципах. Если вы решите изучить или использовать его, я бы регулярно переходил по следующим ссылкам:
Другие полезные ссылки:
