Рубрикатор |
Статьи |
Сергей ЗИНКЕВИЧ  | 28 ноября 2019 |
Почему Kubernetes стал флагманом оркестрации?
При правильной настройке Kubernetes избавляет разработчиков ПО от обработки форс-мажорных ситуаций, максимально автоматизируя процессы контейнеризации. Причем характеристики облачной платформы для его полноценного функционирования неважны.
Рост популярности контейнеров заставил разработчиков заняться поиском оптимальных решений для управления контейнерными средами. Docker как наиболее распространенное ПО для автоматизации развертывания приложений хорошо зарекомендовало себя при работе с микросервисными контейнерами. Но количество работающих контейнеров в компаниях, которые переходят на микросервисную архитектуру, рано или поздно сильно увеличивается. На этом уровне без оркестрации – автоматизации управления контейнерами – уже никак не обойтись.
И эксперты, и практики в последнее время единодушны во мнении, что такой наиболее удобной надстройкой высшего порядка является Kubernetes. Это решение испытано в процессе эксплуатации и постоянно совершенствуется за счет открытого программного кода. Сами же принципы open source уже не пугают даже консервативно настроенных разработчиков, поскольку давно взяты на вооружение не только крупным коммерческими компаниями, но и ИТ-подразделениями многих государственных структур.
Функциональность и архитектура
Kubernetes обладает всеми ключевыми возможностями для управления имеющимися контейнеризованными приложениями, в том числе оркестрации хранения данных, включая работу с секретными и конфигурационными файлами. Кроме того, Kubernetes позволяет осуществлять горизонтальное масштабирование ресурсов, а также молниеносно администрировать всевозможные откаты.
Главное преимущество Kubernetes – он без какого-либо ручного вмешательства «лечит» сам себя, корректируя соответствующие цепочки взаимодействий.
Простейшее архитектурное решение в Kubernetes заключается во взаимодействии двух основных узлов управления (нод, nod) – мастер-ноды и воркер-ноды соответственно. Воркер-ноды обрабатывают все поступающие в систему запросы и осуществляют запуск контейнерных приложений, реализованных на Docker. Делают они это посредством так называемых подов (podes) – своеобразных модулей запуска контейнеров, ранжированных по назначенным каждому приложению внутрисетевым IP-адресам. При этом такая составная часть воркер-ноды, как Kubelet, отслеживает корректность работы Docker, т.е. контролирует все последовательные процессы работы контейнера, включая его запуск и установку. Другим важнейшим элементом воркер-ноды является K-proxy, контролирующий внутреннюю сеть, в том числе работу с трафиком системы.
В свою очередь, мастер-ноды осуществляют управление всем функционалом кластера, включая его внутреннюю работу и взаимодействие со внешними средами. Происходит это благодаря трем составным частям – etcd (отвечает за хранение текущих конфигураций), sheduler (планирование взаимодействия контейнеров) и controller manager (отказоустойчивость воркер-нод и приложений). Эти три компонента управляются API Kubernetes. При этом мастер-нода также осуществляет перманентное взаимодействие с Kubelet и K-proxy воркер-нод. Количество мастер-нод в Kubernetes не ограничено, но на практике обычно используется не более пяти.
При правильной настройке такая несложная архитектура действительно позволяет забыть о различных «падениях» системы и прочих форс-мажорах, предоставляя возможность просто наслаждаться максимально автоматизированными процессами контейнеризации.
Не Docker единым
Несмотря на то что именно Docker зарекомендовал себя в качестве наиболее удобной программной среды для работы с контейнерными приложениями, это вовсе не означает, что Kubernetes «заточен» именно под него. Практика показывает, что данный оркестратор вполне успешно надстраивается в такие среды контейнеризации, как Containerd, Frakti, gVisor или CRI-O. Более того, оркестратор позволяет одновременно работать с контейнерами сразу нескольких таких сред.
В практическом использовании немаловажно и то, что Kubernetes абсолютно «всеяден» в отношении собственной среды обитания – он может работать в любых облачных системах или вообще стационарно, почти никак не завися от имеющихся мощностей, даже если речь идет не о самых новых моделях ноутбуков. Если же говорить о именно о системах виртуализации, то для полноценного функционирования Kubernetes характеристики облачных платформ неважны. Все представленные на рынке облачные решения в основном соответствуют базовым потребностям оркестрации.
Когда Kubernetes действительно нужен, а когда – нет
Мы в своей практике сталкивались с различными ситуациями, и не всегда Kubernetes (по крайне мере в локальной инфраструктуре) был тем самым универсальным решением, которое упростило жизнь разработчиков. Это вовсе не отменяет того факта, что Kubernetes – полезный инструмент, но к его использованию надо подходить с умом.
Так, одна медиакомпания обратилась к «КРОК Облачные сервисы», чтобы развернуть Kubernetes на базе собственных вычислительных мощностей. У клиента случался взрывной рост запросов к инфраструктуре в моменты, когда на сайте компании появлялись «горячие» новости. Нагрузка увеличивалась в 15–20 раз. Решали проблему банально – с помощью покупки дополнительного оборудования, но из-за этого росли лицензионные выплаты. Заказчик хотел одновременно и снизить риск недоступности портала из-за роста запросов, и уменьшить затраты на ИТ. Рассчитав стоимость работ, мы пришли к выводу, что для медиакомпании экономически более целесообразно построить частное облако, а в периоды пиковых нагрузок подключаться к ресурсам публичной платформы. И уже на ней в дальнейшем была организована работа с контейнерами.
Сергей Зинкевич, продакт-менеджер «КРОК Облачные
сервисы»
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!