Игорь НИКИФОРОВ о портативной платформе с открытым кодом, её преимуществах и особенностях

«Kubernetes позволяет без проблем запускать кластеры в абсолютно различных окружениях»  

Правда управлять такой махиной становится достаточно трудно, поэтому возникла необходимость непрерывного и автоматического процесса. Так и появился Kubernetes, легший в основу DevOps-подхода. 

Мы поговорили с ведущим DevOps-инженером, обладателем более десятка сертификаций, таких как CKA, CKAD, AWS x5, HashiCorp x2,  RHCSA, Confluent и др., Игорем Никифоровым, о том, зачем нужно внедрять собственную платформу на базе Kubernetes и какую пользу можно вынести от внедрения кластера Kubernetes на «голом железе». 

Почему вы решили внедрить собственное решение на базе Kubernetes? Рассматривали ли в качестве альтернативы облака или какие-то популярные дистрибутивы?

Если говорить совсем кратко, то мы хотели просто иметь больше контроля над всеми компонентами кластера и возможность быстро развернуть идентичный кластер в любом дата центре или облаке. Сейчас на рынке появилось слишком много различных дистрибутивов и связанных с ними инструментов, и на самом деле, как раз в этом и заключается одна из основных проблем. Может показаться, что при использовании сторонних дистрибутивов меньше шансов навредить себе, так как по сути всё уже продумано и настроено, но, когда начинаешь погружаться в детали, оказывается, что есть нюансы.

Например, наличие кластера в AWS EKS будет заметно отличаться в конфигурации от такого же кластера, но уже в GKE. Это применимо и к различным дистрибутивам, таким как VMware Tanzu или RedHat OpenShift. Если вы захотите перейти от одного дистрибутива к другому, понадобится значительное время на обучение, так как их конфигурация и прилагаемые инструменты в значительной степени отличаются друг от друга. Это, конечно, не проблема самой архитектуры Kubernetes. Поэтому мы ставили перед собой задачу как раз избежать всех этих моментов, чтобы иметь возможности для более тонкого тюнинга решения под свои нагрузки и задачи, а также избежать зависимости от окружения.

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

Самая первая проблема, которая возникает при внедрении собственного Kubernetes кластера, это наличие квалифицированных инженеров. Потому найм специалистов, которые могут обслуживать кластер, может оказаться очень нетривиальной задачей. Во-первых, ситуация на рынке складывается таким образом, что таких людей сейчас не так много и они довольно дорогие. Можно подумать, что развернуть собственный кластер не так сложно, ведь в сети довольно много мануалов по его установке, а также есть неплохая официальная документация и установщики, которые позволяют в пару шагов его развернуть. Но одним развёртыванием кластера дело не ограничится. Инженеру не только необходимо знать все особенности IT-архитектуры в которой будет развернут кластер, но и внутренности Kubernetes, а также понимать, как их обслуживать, ведь на деле свежеустановленный кластер может проработать до первой проблемы, которая неизбежно возникнет. 

Вот почему необходимо настроить мониторинг и сбор логов в кластере, сделать интеграцию с системой хранения, подключить Ingress, чтобы заводить клиентский траффик в ваши приложения, а вместе с этим автоматизировать выписку сертификатов и DNS. Это лишь малая часть огромного списка задач, которые предстоит решить, и все они требуют значительных временных затрат. Поэтому не выйдет просто выделить пару недель на установку и настройку кластера. Для этого потребуется минимум один инженер на full-time.

Игорь, расскажите об основных преимуществах, которые даёт кластер Kubernetes на «голом железе»?

Я бы выделил три основных. Первая – это общая стоимость кластера Kubernetes при расчете стоимости за вычислительные ресурсы. Она может быть ниже за счёт нескольких факторов.

1. Вы не платите за ПО для виртуализации, которое, в противном случае, будет составлять значительную часть расходов.
2. Обслуживание будет значительно проще, потому что не нужно будет иметь дело с виртуализацией и нанимать для этого обученных инженеров, что приводит к снижению затрат на специалистов.
3. Отсутствуют накладные расходы на гипервизор, поэтому все нагрузки смогут на 100 % утилизировать ресурсы сервера.

Во-вторых, разница в производительности между bare metal и виртуальными машинами может быть значительной, учитывая тот факт, что порядка 10-15 % ресурсов сервера могут потребляться гипервизором. Однако даже это не единственный источник снижения производительности в виртуализированной среде. Вы также платите за потребление ресурсов гостевой операционной системы, которая тратит часть вашего процессора и памяти на системные процессы, даже во время простоя операционной системы. Здесь стоит учитывать тот факт, что, если на одной виртуальной машине произойдет всплеск потребления ресурсов, это может повлиять на производительность других виртуальных машин, размещенных на том же сервере. И, возможно, самым большим фактором, который может повлиять на производительность Kubernetes на основе виртуальных машин, по сравнению с Kubernetes на bare metal, является зависимость приложений от доступа к ресурсам сервера напрямую, например, GPU. Наконец, стоит отметить, что виртуализация добавляет еще один уровень абстракции, который может вызвать проблемы с производительностью в случае сбоя. Узел гипервизора, который может выйти из строя, лишит ваш кластер части ресурсов, предоставляемых этим узлом, что, в свою очередь, может снизить производительность остальных приложений.

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

Получается, что Kubernetes на «голом железе» даёт одни преимущества, или недостатки тоже имеются? 

Несмотря на все плюсы, перечисленные ранее, одна из основных возникающих проблем – это управление конфигурацией: начиная от конфигурации самого сервера, до установки ОС и включением такого сервера в кластер Kubernetes. В отличии от железных серверов, виртуальные машины намного проще конфигурировать. Во-первых, можно без проблем подготовить готовый образ виртуальной машины, в котором будет установленная ОС и нужные пакеты, а также полноценно использовать IaaC инструменты, в т.ч. Terraform, с помощью которого легко развернуть десятки виртуальных машин. А использование cloud-провайдера, в который с большой вероятностью заложена поддержка cloud-init, отлично подходит для включения новых виртуальных узлов в кластер. Большая часть этих функций технически доступна и для bare-metal, но реализовать их значительно сложнее. Здесь будут необходимы дополнительные сервисы для управления и конфигурации. Разработка и поддержка подобного инструментария потребует значительных временных затрат, а также дополнительной квалификации инженеров, т.к. все это не готовая функциональность, как при работе, например, с облачными провайдерами.

С какими вызовами и сложностями Вы столкнулись при внедрении Kubernetes на bare-metal?

При внедрении собственного кластера первые две основные проблемы, которые обычно возникают – это балансировка нагрузки и системы хранения. Если в облаках эти проблемы решены собственными управляемыми сервисами (managed services), то в on-premise приходится думать об этом самому.

Отказоустойчивый балансировщик будет необходим для двух вещей: балансировка Kubernetes API и клиентского траффика до ваших приложений через Ingress. Он требуется не только для приложений, которые крутятся в Kubernetes, но и для его API. В зависимости от текущей инфраструктуры, вы можете использовать различные решения, например от F5, или софтверные решения, вроде NGINX или HAProxy в связке с keepalived. Также неплохим вариантом может служить MetalLB, который специально заточен под bare metal имплементации кластеров Kubernetes. А в случае наличия VMware отличным вариантом будет использование NSX Load Balancer. Мы перепробовали все решения, но остановились на связке HAProxy с keepalived, так как оно подходит под абсолютно любое окружение и довольно простое в конфигурации и обслуживании, а также позволяет решать проблему с видимостью IP-адресов клиентов посредством proxy-протокола.

С системами хранения все сложнее. Kubernetes изначально разрабатывался для приложений, которые ничего не хранят, а для большинства продуктивных нагрузок потребуется постоянное выделенное хранилище данных. В Kubernetes для этого существуют persistent volumes, которые подключатся к вашим контейнерам с помощью CSI плагинов. Kubernetes из коробки умеет работать с такими популярными протоколами как NFS и iSCSI. А если в вашей инфраструктуре есть СХД, то, возможно, оно уже поддерживает интеграцию с Kubernetes через соответствующий CSI плагин, так как сейчас очень многие производители СХД довольно активно вкладываются в развитие их решений с Kubernetes. Если рассматривать программное-определяемые системы хранения (Software-defined storage), то среди доступных вариантов можно выделить такие популярные решения как Ceph и GlusterFS, а также специально заточенные под Kubernetes решения – OpenEBS или Rook. Мы решили остановится на интеграции с существующим СХД, так как это помогло нам в значительной степени снизить операционные расходы на управление внешним хранилищем.

Еще один момент, который стоит отметить, это большие сложности, связанные с масштабированием самого кластера на bare-metal. Эта проблема связана как с общей сложностью процесса конфигурирования bare-metal серверов, так и с отсутствием коробочных решений для Kubernetes. Здесь вам потребуются не только дополнительные компоненты в инфраструктуре (в т.ч. PXE сервер), но и разработка самого решения в зависимости от ваших потребностей, которое будет автоматизировать все процессы жизненного цикла bare-metal нод кластера.

Ну и последнее, это проблемы, связанные обновлениями bare-metal нод. Обновление версии кластера может создать определённые проблемы, если есть несовместимости API, представленные с более новой версией Kubernetes. Необходимо определить стратегию поэтапного обновления всех машин и подходы, с помощью которых вы будете это делать, будь то загрузка подготовленного образа в память или установка с нуля. Как с в случае с масштабированием, при использовании bare-metal скорее всего понадобится разработка своего решения. Также нужно иметь в виду, что загрузка железных нод, начиная от инициализации и заканчивая полной установкой и включением в кластер, вне зависимости от стратегии обновления будет занимать значительно больше времени, нежели при использовании виртуальных машин.

Когда компании стоит задуматься о том нужен ли ей Kubernetes?

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

Также Игорь Никифоров отметил, что Kubernetes позволяет без проблем запускать кластеры в абсолютно различных окружениях. Таким образом, можно без проблем использовать существующие мощности для Kubernetes, применяя виртуальные машины и/или текущие железные сервера. Но для развертывания Kubernetes потребуется понимание всей специфики вашей инфраструктуры, включая сервера, СХД и сетевую инфраструктуру, чтобы получить кластер, готовый к продуктивным нагрузкам.

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

Сергей Иванов