«Доктор, помогите, у меня Kubernetes!»

Дожили: айтишники «играют в кубики» — и сваливают на них все проблемы в инфраструктуре. По крайней мере, так иногда считает бизнес. Так это правда или преувеличение?

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

То есть, Kubernetes помогает управлять инфраструктурой веб-приложений и де-факто является стандартом для использования в облаках. Главные УТП «кубика» — масштабируемость, гибкость и возможность запускать где угодно. Благодаря чему он так популярен и используется во многих веб-проектах.

Но у широких возможностей, вкупе с универсальностью, всегда есть обратная сторона. В случае Kubernetes это сложность конфигурации и обслуживания. Даже у технологически продвинутых компаний не всегда есть ресурсы, чтобы разобраться в тонкостях и получить все преимущества от его эксплуатации. А ведь ещё бывают случаи, когда Kubernetes разворачивают просто из-за любопытства или хайпа (или «у соседнего стартапа видел такое»). В результате в компании могут даже не знать, что кластер работает не так, как надо. Или видеть явные проблемы, но не знать, в чём причина и как их ликвидировать, — тоже не легче.

Справиться с непонятным, заранее подготовиться к трудностям или убедиться, что проблем не будет, можно двумя способами:

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

Наша компания работает с высоконагруженными инфраструктурными проектами вот уже 12 лет и, конечно, идёт по первому пути, подробно знакомясь и досконально изучая все ходовые инструменты. Набив изрядное количество шишек, мы поняли, как помочь тем, кто выбирал второй вариант, избежать большей части трудностей. И, кажется, первыми в России поняли, что оптимальное решение для этого — провести аудит Kubernetes.

Из нашего опыта работы с проектами, где используется K8s, аудит необходим обычно в следующих ситуациях:

• есть регулярные проблемы, которые не получается решить, нужна помощь извне;
• явных проблем не видно или они пока не очень существенные, но нет уверенности в своих силах, хочется свериться с экспертами;
  
• есть потребность проверить работу подрядчика/исполнителя, чтобы точно не сомневаться в результате.
  

То есть, говоря о Kubernetes и инфраструктуре, аудит будет полезен, если проект готовится к масштабированию (или «Чёрной пятнице»), компания в принципе вводит Kubernetes в промышленную эксплуатацию и заботится о надёжности и в качестве санитарной проверки. Но вообще, как поход к врачу на осмотр — не обязательно следствие болезни, так и аудит имеет смысл проводить до того, как всё упало (и, возможно, не в первый раз).

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

Например, в отчёте мы не просто пишем, что необходимо увеличить число master-узлов до трёх; мы укажем, что с одним master-узлом у кластера есть единая точка отказа и это делает кластер неустойчивым. Kubernetes хранит состояния в распределенной базе данных etcd, для корректной работы ей необходим кворум —строго больше половины всех узлов в рабочем состоянии. Если один из etcd-узлов откажет и не будет кворума, то база перейдет в readonly-режим и станет невозможно сохранить изменение в состоянии Kubernetes-кластера. Чтобы не терять устойчивость к изменению состояния при выходе одного из узлов из строя, их должно быть как минимум три.

Другой пример: production- и dev-окружение крутятся на одном кластере. Совет держать разработку и production в разных, изолированных друг от друга окружениях, а лучше и в разных кластерах, может звучать как «лишние затраты». Но когда dev- и prod-окружения размещаются на одной платформе, это часто приводит к инцидентам. Разработчики могут случайно перезапустить не те проекты, удалить не те базы или другим способом повлиять на работоспособность production-инфраструктуры. А это — никому не нужные риски.

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

Порядка 50-ти, в общей сложности, формальных тестов помогают ответить на важные для бизнеса вопросы: сможет ли кластер выдержать, когда у приложения станет больше пользователей; сможет ли он сохранить устойчивость в случае аварии, чтобы это не сказалось на пользователях; не потеряются ли важные данные и достаточно ли эффективно расходуются ресурсы или на инфраструктуре можно сэкономить.

Значит ли это, что аудит поможет решить все проблемы? Конечно, нет. Это рецепт, от которого не будет никакого толка, если проигнорировать одну половину рекомендаций, а вторую применить с поправками (например: «Три master-узла — всё-таки перебор, сделаем пока два, а там посмотрим»).

С другой стороны, не все рекомендации требуют срочных действий. Как мы поступаем в таких случаях? — найденные проблемы мы ранжируем по степени критичности: от «потенциально ведут к падению кластера» до «не влияют на работу кластера, но без них будет лучше устойчивость и безопасность». Однако аудит — мероприятие комплексное, стало быть, и решения чаще всего лучше сработают все вместе.

Всё как обычно: чем точнее определить цели, тем более предсказуемым будет результат. Если сформулировать и задать конкретные вопросы, то будет больше информации, чтобы дать действенный совет.

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

Если проект, вопреки ожиданиям, после внедрения Kubernetes получил увеличение time-to-market, то мы подробно проверим процесс деплоя. У этой проблемы могут быть разные причины, но одна из основных — это тяжелый docker- образ из-за лишних файлов в нём. Следствие — долгая загрузка образа в registry и доставка его на Kubernetes-узел.

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

Резюмируя, ещё раз сформулируем, кому полезен аудит Kubernetes:

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

#kubernetes #k8s #itsumma #инфраструктура