Первоначальное размещение vSphere Pod

Это перевод статьи Frank Denneman Initial placement of a vSphere Pod. Публикуется с разрешения автора.

Project Pacific превращает vSphere в унифицированную платформу для запуска различных приложений. Новая платформа позволяет запускать и виртуальные машины и Linux контейнеры нативным способом. Просто запускать Linux контейнеры как новый тип рабочих нагрузок недостаточно. Чтобы правильно управлять контейнерами нам нужен понимающий эти нагрузки оркестратор. Кроме того, нам необходимо убедиться, что текущие сервисы, такие как DRS, смогут правильно работать с объектами, имеющими абсолютно разные жизненные циклы. Обычно контейнер имеет более короткий жизненный цикл, чем виртуальная машина, в то время как виртуальные машины живут годами, средняя продолжительность жизни контейнеров значительно ниже. И это существенное различие очень сильно влияет на первоначальное размещение и балансировку нагрузки.

Возможность запускать контейнеры аналогичным с виртуальными машина способом в VMkernel порождает несколько увлекательных проблем. Как подчеркнул Michael Gasch в своем выступлении на VMworld 2018 “Running Kubernetes on vSphere Deep Dive: The Value of Running Kubernetes on vSphere (CNA1553BU)” контейнер — это не отдельная сущность, а совокупность процессов и объектов Linux.

Среда исполнения контейнеров в ESXi

ESXi VMkernel не является операционной системой Linux. Абстракции оборудования и процессов VMkernel были созданы с целью запуска виртуальных машин, а не для непосредственной поддержки процессов Linux. Для этого в Project Pacific появляется среда исполнения контейнеров в ESXi (CRX — Container Runtime for ESXi). CRX предоставляет Linux Application Binary Interface (ABI), который позволяет исполнять приложения Linux (контейнеры) так же, как если бы они работали напрямую в VMkernel. Красота CRX в том, что она полностью изолирована от любых других процессов или UserWorld работающих на ESXi хосте. Как это возможно? С помощью нашего старого друга — виртуальной машины.

Природа виртуальной машины CRX экземпляра позволяет использовать Virtual Machine Monitor (VMM) и настройки Virtual Hardware (VMX). VMM обеспечивает обработку исключений и прерываний для виртуальной машины. Внутри экземпляра CRX существует процесс инициализации CRX для обеспечения связи между экземпляром CRX и сервисами VMkernel.

Но нам требуется ядро ​​Linux, чтобы обеспечить Linux ABI возможность запуска контейнеров. Что может быть лучше, чем использовать наше собственное ядро Linux? VMware Photon был выбран в качестве поддерживаемого VMware LTS ядра Linux. Photon используется в качестве основы для VCSA и других продуктов VMware и имеет чрезвычайно малый footprint. Еще одна интересная деталь, ядро ​​не хранится и не загружается с отдельного диска. Ядро ​​Linux загружается непосредственно в область памяти экземпляра CRX, когда она создается. Кроме того, экземпляр CRX урезан. Только необходимые драйверы и функциональные возможности позволяют сделать CRX и ядро ​​максимально легкими и быстрыми. Например, CRX использует только паравиртуализированные устройства.

Поверх этой базы и работает среда исполнения контейнеров, которая позволяет нам запускать OCI-совместимые контейнеры внутри экземпляра CRX.

Внутри VMkernel мы представили нашу реализацию Kubelet, которая называется vSpherelet. Проще говоря, vSpherelet превращает хост ESXi в Kubernetes worker node, vSpherelet это extension для Kubernetes control plane. Среда исполнения контейнеров внутри экземпляра CRX содержит агент vSpherelet, который обеспечивает связь между vSpherelet и средой исполнения контейнера. Агент vSpherelet предоставляет функциональность, которую Kubernetes ожидает от Pod. Такие действия как: health checks, монтирование хранилища, настройка сети, управление состоянием контейнеров внутри Pod, а также предоставляет endpoint для инструмента командной строки Kubernetes — Kubectl. Агент vSpherelet связан с libcontainer и знает, как запускать контейнеры с помощью этого метода. Как только контейнеры запускаются внутри экземпляра CRX, мы считаем эту группу объектов — Kubernetes Pod.

Два капитана на одном корабле

Теперь, когда мы понимаем, как ESXi может запускать контейнеры, нам нужно подумать о том, кто контролирует их работу, с точки зрения управления ресурсами. Project Pacific не только предлагает собственный способ запуска контейнеров внутри VMkernel, но и представляет Kubernetes как оркестратор для этих контейнеров. По сути, это означает, что он добавляет control plane к платформе, которая уже имеет control plane для таких рабочих нагрузок как виртуальные машины (vCenter + HostD), а также дополнительные сервисы, такие как DRS, упрощающие управление ресурсами. На первый взгляд, это не должно вызывать затруднения, так как Kubernetes не управляет и не контролирует виртуальные машины, поэтому зоны их действия не пересекаются. Однако вы, должно быть, заметили, что присутствует двойственность. vSphere Pod — это комбинация виртуальной машины и группы контейнеров. И что еще интереснее, обе управляющие платформы имеют похожие инструменты для управления поведением и размещением рабочих нагрузок. В Kubernetes вы контролируете размещение контейнеров на worker node с помощью меток и политик развертывания. В DRS вы используете affinity rule. В Kubernetes мы используем Requests и Limits для ограничения ресурсов, тогда как vSphere использует параметры vSphere Reservation, Shares и Limits (RLS). Кроме того, нам нужно подумать о том, как отдельные Requests и Limits для нескольких контейнеров, работающих внутри одного экземпляра CRX, будут преобразованы в настройки RLS виртуальной машины. Я расскажу выделении ресурсов в следующей статье. В этой статье я хочу изучить размещение контейнеров и виртуальных машин, когда используются эти две control plane.

Первоначальное размещение экземпляра CRX

Когда разработчик разворачивает приложение, он или она взаимодействует Kubernetes API сервером, и API сервер будет запускать всевозможные действия для различных компонентов, присутствующих в архитектуре Kubernetes. Project Pacific расширил Kubernetes API для взаимодействия с платформой vSphere. Таким образом, получается, что Kubernetes тут главный. Однако мы не можем игнорировать великолепные средства управления ресурсами — DRS и HostD. Принимая во внимание, что Kubernetes использует очень грубый метод Requests (эквивалент резервирования) для сопоставления потребителей ресурсов (контейнеров) и поставщиков ресурсов (worker nodes). vSphere гораздо элегантнее благодаря своей способности понимать активность рабочих нагрузок, способности преобразовывать бездействие во временную корректировку приоритетов и выравнивать потребление ресурсов за пределами одного хоста. И чтобы сделать его еще лучше, Project Pacific использует функциональность масштабируемых общих ресурсов, которая позволяет мгновенно перенастраивать приоритет ресурсных пулов, если новая рабочая нагрузка (например, контейнеры) добавляется в vSphere namespace. Изобретение, которое Duncan Epping, я и команда DRS инженеров создали в 2013 году. Тем не менее, архитектура Kubernetes имеет очень элегантный способ выразить бизнес-логику, диктую размещение контейнеров на основе labels, taints и tolerations. Поэтому имеет смысл объединить функциональные возможности обеих control planes.

Алгоритм первоначального размещения

1. Разработчик взаимодействует с сервером API Kubernetes для развертывания приложения. Обычно эти deployments передаются на API сервер в виде YAML файла, который содержит спецификации Pod.
2. Deployment и спецификация Pod хранится на сервере etcd, а сервер API публикует это событие в watch-list, на который подписан планировщик Kubernetes. Прочтите эту статью для получения дополнительной информации о архитектурах на основе событий.
3. Планировщик Kubernetes инициирует процесс выбора подходящего хоста. Он фильтрует список доступных worker node (ESXi хостов) на основе affinity, Pod и node labels и других ограничений nodeSelector.
4. Отправляет полученный список в DRS, чтобы выбрать хост. DRS выбирает хост на основе его дерева решений (доступные ресурсы для виртуальной машины, состояние хоста, совместимость хоста).
5. После выбора хоста информация возвращается через vCenter API сервер в планировщик Pacific.
6. Планировщик сохранит его как event в базе данных etcd.
7. Когда event сохранится в базе данных etcd, vCenter дает команду процессу HostD на выбранном ESXi хосте включить виртуальную машину.
8. HostD включает виртуальную машину (VMX, VMM) и загружает ядро ​​Photon в адресное пространство этой виртуальной машины.
9. HostD возвращает VM ID созданной виртуальной машины в планировщик Pacific.
10. VM ID хранится в базе данных etcd, и теперь у control plane хоста достаточно данных, чтобы Spherelet мог сконфигурировать Pod.
11. vSphere Pod Lifecycle Controller обновляется по событию и инициирует Spherelet для настройки Pod.
12. Spherelet соединяется с HostD для настройки Pod, настройки сети и хранилища.
13. Среда исполнения контейнера CRX инициирует запуск контейнеров на основе спецификации Pod.
14. Spherelet возвращает состояние контейнеров обратно Kubernetes master, чтобы сохранить его как событие в базе данных etcd.

Благодаря этой архитектуре мы получаем лучшее из обоих миров — выразительность Kubernetes control plane и элегантность управления ресурсами vSphere. Следующая статья по этой теме будет посвящена распределению ресурсов на основе параметров конфигурации контейнера. Обратите внимание, что Project Pacific все еще находится на стадии бета-тестирования и пока недоступен в качестве завершенного продукта. Оставайтесь с нами, чтобы узнать больше.