Рубрикатор | ![]() |
![]() |
Статьи | ![]() |
![]() |
Сергей ЗИНКЕВИЧ  | 28 ноября 2019 |
Почему Kubernetes стал флагманом оркестрации?
При правильной настройке Kubernetes избавляет разработчиков ПО от обработки форс-мажорных ситуаций, максимально автоматизируя процессы контейнеризации. Причем характеристики облачной платформы для его полноценного функционирования неважны.
![](/data/2019/11/28/1237572730/Сергей_Зинкевич.jpg)
Рост популярности контейнеров заставил разработчиков заняться поиском оптимальных решений для управления контейнерными средами. 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. Спасибо!