Хабрахабр

Инфраструктура для микросервисов. K8s и все-все-все

Есть такая профессия — DevOps, точнее нет, но так получилось, что это именно то чем я сейчас занимаюсь. Как-то я уже писал тут о переезде из Азии в Европу, а теперь хочу написать, что я в этой Европе делаю. Но вот случилось ужасное, вышел ранчер 2. Сейчас для оркестрации всего что бежит в докере мы используем rancher, о чем я тоже уже писал. Что еще добавляет пикантности это то что компания постоянно нанимает разных специалистов из разных стран и с разными традициями и кто-то и собой приносит puppet, кому-то милее ansible, а кто-то вообще считает что Makefile + bash — наше все. 0 который переехал на kubernetes (дальше просто k8s) и поскольку k8s сейчас действительно стандарт для управления кластером, возникло желание тоже построить всю инфраструктуру заново с блекджеком и библиотекаршами. Поэтому однозначного мнения как все должно работать просто нет, а очень хочется.

Предварительно был собран такой зоопарк технологий и инструментов:

zoo

Управление инфраструктурой

  • Minikube
  • Rke
  • Terraform
  • Kops
  • Kubespray
  • Ansible

Управление приложением

  • Kubernetes
  • Rancher
  • Kubectl
  • Helm
  • Confd
  • Kompose
  • Jenkins

Логирование и мониторинг

  • Elasticsearch
  • Kibana
  • Fluent bit
  • Telegraf
  • Influxdb
  • Zabbix
  • Prometheus
  • Grafana
  • Kapacitor

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

Как альтернативы рассматривались Центром всего будет kubernetes потому что сейчас это действительно решение которому просто нет альтернатив, которое поддерживается всеми провайдерами от амазона и микрософта и до mail.ru.

  • Swarm — который так и не взлетел
  • Nomad — который похоже писали чужие для хищников
  • Cattle — движок от ранчера 1.х, на котором сейчас и живем, в принципе все устраивает, но сам ранчер уже от него отказался в пользу k8s так что развития не будет.

Создание инфраструктуры

Вариантов есть несколько, все они работают и поэтому тяжело выбрать лучший. Для начала нам надо создать инфраструктуру, и развернуть на нем кластер k8s.

Minikube — отличный вариант для запуска кластера на на машине разработчика, для тестовых целей.

Rke — Rancher kubernetes engine, прост как дверь минимальный конфиг для создания кластера выглядит

nodes: - address: localhost role: [controlplane,worker,etcd]

И все, этого достаточно чтоб запустить кластер на локальной машине, при этом позволяет создавать production ready HA кластеры, менять конфигурацию, апгрейдить кластер, дампить etcd базу данных и еще много чего.

Так же позволяет генерировать конфигурацию для terraform. Kops — позволяет не только создавать кластер, но еще и предварительно создавать инстансы в aws или gce. Его вполне заменяют terraform + rke при этом проще и гибче. Интересный инструмент, но у нас пока не прижился.

Это практически решение по умолчанию для разворачивания k8s. Kubespray — по факту это просто ansible роль, которая создает k8s кластер, чертовски мощная, гибкая, конфигурируемая.

Гибок, стабилен — рекомендую. Terraform — инструмент для создания инфраструктуры в aws, azure или куче других мест.

Дешево и сердито. Ansible — это не совсем про k8s но мы его используем везде и тут тоже: подправить конфиги, установить/обновить софт, раздать сертификаты.

Управление приложением

Итак, у нас есть кластер, теперь на нем надо что-то полезное запустить, остался только вопрос как это сделать.

В принципе этот вариант имеет право на жизнь. Вариант первый: используем голый k8s все деплоим при помощи kubectl. Но иногда хочется чтоб все было немного удобнее, поэтому переходим идем дальше. Kubectl достаточной мощный инструмент который позволяет сделать все что нам надо, включая деплоймент, апгрейд, контролирование текущего состояния, изменение конфигурации на лету, просмотр логов и подключение к конкретным контейнерам.

Rancher

Rancher

Тут и просмотр логов, и доступ в консоль и конфигурирование и апгрейд приложений и управление доступом на основе ролей и встроенный метадата сервер, алармы, перенаправление логов, управление секретами и многое другое. По сути, сейчас rancher это веб морда для управления k8s и заодно много мелких плюшек которые добавляют удобства. Приятно, что в ранчер можно импортировать любой заранее созданный кластер, причем от любого провайдера то есть в один сервер можно импортировать кластер из EKS из azure и созданный локально и рулить ими из одного места. Пользуемся ранчером первой версии уже несколько лет и пока им совершенно довольны, хотя надо признать что при переходе на k8s возникает вопрос, действительно ли он нам нужен. Более того, если вдруг надоест, то можно просто снести ранчер сервер и продолжить пользоваться кластером напрямую через kubeclt или любой другой инструмент.

Например инфраструктура как код, реализована при помощи terraform, сборка как код реализована через jenkins pipeline. Сейчас популярна очень правильная концепция все как код. Инсталляция и конфигурация приложения должна тоже быть описана в каком-нибудь манифесте и сохранена в гите. Теперь дошла очередь и до приложения. Helm — с моей точки зрения, совершенно ужасное поделие со странной логикой и архитектурой. Rancher версий 1.х использовал стандартный docker-compose.yml и все было хорошо, но при переезде на k8s они переключились на helm charts. Проблема только в том, что в мире k8s хелму просто нет альтернатив и это де факто — стандарт. Это один из тех проектов от которого остается ощущение, что его написали хищники для чужих или наоборот. В версии 3.х разработчики обещают переписать его практически с нуля, выбросив из него все странности и упростив архитектуру. Поэтому будем колоться плакать, но продолжать использовать helm. Вот тогда-то мы и заживем, а пока будем есть что есть.

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

Мониторинг

Как стабильно работает наше приложение? Теперь у нас есть кластер и в нем даже крутиться какое-то приложение, казалось бы — можно выдохнуть, но на самом деле все только начинается. Хватает ли ему ресурсов? Как быстро? Однозначных ответов тут только три. Что вообще происходит в кластере?
Да следующая тема это мониторинг и логирование. На все остальные вопросы есть по десятку правильных ответов. Хранить логи в elasticsearch, смотреть их через kibana рисовать графики в grafana.

Grafana

Grafana
Тут начнем с grafana сама по себе она практически ничего не делает, но ее можно пристегнуть как красивую морду к любой из нижеописанных систем и получить красивые и иногда наглядные графики, кроме того тут же можно настроить алармы, но лучше для этого использовать другие решения например prometheus alertmanager и ElastAlert.

fluent-bit

Есть еще Fluentd но он писан на руби и тянет за собой слишком много легаси кода, что делает его гораздо менее привлекательным. С моей точки зрения на данный момент это лучший агрегатор и роутер логов, кроме того прямо из коробки в нем есть поддержка k8s. Он быстрее, стабильнее, потребляет меньше памяти. Так что если вам нужен какой-то конкретный модуль из fluentd который еще не портирован в fluent-bit пользуйте его, во всех остальных — бит это лучший выбор. Если сравнить его с традиционными logstash + docker-bit + file-bit это решение однозначно лучше по всем параметрам. Позволяет собирать логи из всех или из избранных контейнеров, фильтровать их, обогащать добавляя данные специфические для кубернетиса и отправлять это все в elasticsearch или во множество других хранилищ. Исторически мы все еще используем logspout + logstash но fluent-bit однозначно выигрывает.

Prometheus

Де факто стандарт в индустрии, более того есть еще проект который называется Prometheus Operator, писаный специально для k8s. Система мониторинга написанная специально для микросервисной архитектуры. Еще надо упомянуть node-exporter который позволяет собирать метрики уровня машины и prometheus-rancher-exporter который позволяет собирать метрики через rancher api. Что выбрать решает каждый сам, но начинать лучше с голого прометеуса, просто для того чтобы понять логику его работы, она достаточно сильно отличается от привычных систем. В общем если у вас есть кластер на kubernetes, то prometheus — must have.

Во первых это zabbix очень удобно на одной панели видеть все проблемы всей инфраструктуры. Тут можно было бы и остановиться, но исторически сложилось, что у нас есть еще несколько систем мониторинга. Кроме того в версии 4. Наличие авто дискавери позволяет на лету находить и добавлять в мониторинг новые сети, ноды, сервисы и вообще практически что угодно, это делает его более чем удобным инструментом для мониторинга динамических инфраструктур. Хотя нет пока однозначного ответа надо ли тащить zabbix в k8s кластер, но попробовать однозначно интересно. 0 в заббикс добавили сбор метрик из экспортеров прометеуса и получается, что все это можно очень красиво интегрировать в одну систему.

Еще просто как вариант можно использовать TIG (telegraf + influxdb + grafana) настраивается просто, работает стабильно, позволяет агрегировать метрики, по контейнерам, приложениям, нодам и прочее, но по сути полностью дублирует функционал prometheus, а "остаться должен только один".

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

А как вы себе видите идеальную инфраструктуру?
Если есть мнение напишите пожалуйста в комментариях, а может даже присоединяйтесь к нашей команде и помогите собрать это все на месте.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть