В предыдущей статье мы определили Kubernetes как механизм оркестрации контейнеров, который помогает убедиться, что каждый контейнер находится там, где он должен быть, и что контейнеры могут взаимодействовать друг с другом.



Kubernetes 101: зачем вам это нужно?
todatascience.com



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

Learning Rate - это мой еженедельный информационный бюллетень для тех, кто интересуется миром AI и MLOps. Каждую пятницу вы будете получать от меня обновления и мысли о последних новостях, исследованиях, репозиториях и книгах в области искусственного интеллекта. Подпишитесь здесь!

Архитектура Kubernetes

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

С другой стороны, у нас есть плоскость управления. Думайте об этом как о главном узле в нашем кластере. Плоскость управления управляет рабочими узлами и модулями в кластере.

Узлы

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

Каждый узел содержит службы, необходимые для запуска модулей и контейнеров:

  • Среда выполнения контейнера, например containerd или CRI-O, для управления полным жизненным циклом контейнера его хост-системы, от передачи образа до выполнения и мониторинга контейнера, от низкоуровневого хранилища до сетевых вложений и т. д.
  • A kubelet, агент основного узла, который запускается на каждом узле, гарантирует, что контейнеры, запланированные Kubernetes, работают на узле и остаются работоспособными.
  • A kube-proxy, сетевой прокси, который работает на каждом узле и поддерживает сетевые правила. Эти правила позволяют входящим запросам достигать Pod'ов из сетевых сеансов внутри или вне кластера.

Плоскость управления

Узел - это место, где с нашим приложением творится волшебство. Однако было бы невозможно управлять всеми модулями вручную; Вот где свою роль может сыграть плоскость управления Kubernetes.

Плоскость управления Kubernetes отвечает за управление жизненным циклом подов и обрабатывает все детали. Итак, давайте посмотрим на его составляющие:

  • Сервер API - это точка контакта для Kubernetes. Он обрабатывает проверку данных и настройку для каждого объекта. Это сердце и душа Kubernetes, и все остальные компоненты общаются через него.
  • etcd - это хранилище ключей и значений, в котором записывается вся важная информация для кластера: конфигурация среды, предполагаемое выполнение вашего приложения и т. д.
  • Планировщик контролирует узлы и отслеживает все доступные ресурсы, чтобы гарантировать, что модуль перейдет к узлу, который может его обработать.
  • Диспетчер контроллеров инкапсулирует основную логику Kubernetes. CM следит за тем, чтобы все части работали правильно. В противном случае предпринимаются действия, чтобы привести систему в желаемое состояние.
  • Cloud Control Manager обращается к поставщикам облачных услуг (например, GCP, AWS, Azure и т. д.) и сообщает о потребностях кластера. Если вы используете Kubernetes в своей собственной среде, в кластере нет диспетчера облачных контроллеров.

Предисловие

Дизайн кластера Kubernetes основан на трех принципах. Кластер Kubernetes должен быть безопасным, простым в использовании и расширяемым. Эта история демонстрирует, как мы можем визуализировать кластер Kubernetes как две части: плоскость управления и узлы.

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

Теперь мы готовы запачкать руки и запустить наши первые рабочие нагрузки в следующих статьях.

об авторе

Меня зовут Димитрис Поулопулос, я инженер по машинному обучению, работающий в Arrikto. Я разработал и внедрил ИИ и программные решения для крупных клиентов, таких как Европейская комиссия, Евростат, МВФ, Европейский центральный банк, ОЭСР и IKEA.

Если вы хотите прочитать больше сообщений о машинном обучении, глубоком обучении, науке о данных и DataOps, подпишитесь на меня в Medium, LinkedIn или @ james2pl в Twitter.

Выраженные мнения являются исключительно моими и не отражают взгляды или мнения моего работодателя.