Как-то я уже писал тут о переезде из Азии в Европу, а теперь хочу написать, что я в этой Европе делаю. Есть такая профессия — DevOps
, точнее нет, но так получилось, что это именно то чем я сейчас занимаюсь. Сейчас для оркестрации всего что бежит в докере мы используем rancher, о чем я тоже уже писал. Но вот случилось ужасное, вышел ранчер 2.0 который переехал на kubernetes (дальше просто k8s) и поскольку k8s сейчас действительно стандарт для управления кластером, возникло желание тоже построить всю инфраструктуру заново с блекджеком и библиотекаршами. Что еще добавляет пикантности это то что компания постоянно нанимает разных специалистов из разных стран и с разными традициями и кто-то и собой приносит puppet
, кому-то милее ansible
, а кто-то вообще считает что Makefile + bash
— наше все. Поэтому однозначного мнения как все должно работать просто нет, а очень хочется.
Предварительно был собран такой зоопарк технологий и инструментов:
Управление инфраструктурой
- 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 базу данных и еще много чего.
Kops — позволяет не только создавать кластер, но еще и предварительно создавать инстансы в aws или gce. Так же позволяет генерировать конфигурацию для terraform. Интересный инструмент, но у нас пока не прижился. Его вполне заменяют terraform + rke
при этом проще и гибче.
Kubespray — по факту это просто ansible роль, которая создает k8s кластер, чертовски мощная, гибкая, конфигурируемая. Это практически решение по умолчанию для разворачивания k8s.
Terraform — инструмент для создания инфраструктуры в aws, azure или куче других мест. Гибок, стабилен — рекомендую.
Ansible — это не совсем про k8s но мы его используем везде и тут тоже: подправить конфиги, установить/обновить софт, раздать сертификаты. Дешево и сердито.
Управление приложением
Итак, у нас есть кластер, теперь на нем надо что-то полезное запустить, остался только вопрос как это сделать.
Вариант первый: используем голый k8s все деплоим при помощи kubectl
. В принципе этот вариант имеет право на жизнь. Kubectl достаточной мощный инструмент который позволяет сделать все что нам надо, включая деплоймент, апгрейд, контролирование текущего состояния, изменение конфигурации на лету, просмотр логов и подключение к конкретным контейнерам. Но иногда хочется чтоб все было немного удобнее, поэтому переходим идем дальше.
Rancher
По сути, сейчас rancher это веб морда для управления k8s и заодно много мелких плюшек которые добавляют удобства. Тут и просмотр логов, и доступ в консоль и конфигурирование и апгрейд приложений и управление доступом на основе ролей и встроенный метадата сервер, алармы, перенаправление логов, управление секретами и многое другое. Пользуемся ранчером первой версии уже несколько лет и пока им совершенно довольны, хотя надо признать что при переходе на k8s возникает вопрос, действительно ли он нам нужен. Приятно, что в ранчер можно импортировать любой заранее созданный кластер, причем от любого провайдера то есть в один сервер можно импортировать кластер из EKS из azure и созданный локально и рулить ими из одного места. Более того, если вдруг надоест, то можно просто снести ранчер сервер и продолжить пользоваться кластером напрямую через kubeclt или любой другой инструмент.
Сейчас популярна очень правильная концепция все как код. Например инфраструктура как код, реализована при помощи terraform
, сборка как код реализована через jenkins pipeline
. Теперь дошла очередь и до приложения. Инсталляция и конфигурация приложения должна тоже быть описана в каком-нибудь манифесте и сохранена в гите. Rancher версий 1.х использовал стандартный docker-compose.yml
и все было хорошо, но при переезде на k8s они переключились на helm charts
. Helm
— с моей точки зрения, совершенно ужасное поделие со странной логикой и архитектурой. Это один из тех проектов от которого остается ощущение, что его написали хищники для чужих или наоборот. Проблема только в том, что в мире k8s хелму просто нет альтернатив и это де факто — стандарт. Поэтому будем колоться плакать, но продолжать использовать helm. В версии 3.х разработчики обещают переписать его практически с нуля, выбросив из него все странности и упростив архитектуру. Вот тогда-то мы и заживем, а пока будем есть что есть.
Еще надо хотя бы упомянуть здесь jenkins
, он не относиться напрямую к теме кубернетиса, но именно с его помощью приложения деплоятся в кластер. Он есть, он работает и он тема для отдельной статьи.
Мониторинг
Теперь у нас есть кластер и в нем даже крутиться какое-то приложение, казалось бы — можно выдохнуть, но на самом деле все только начинается. Как стабильно работает наше приложение? Как быстро? Хватает ли ему ресурсов? Что вообще происходит в кластере?
Да следующая тема это мониторинг и логирование. Однозначных ответов тут только три. Хранить логи в elasticsearch
, смотреть их через kibana
рисовать графики в grafana
. На все остальные вопросы есть по десятку правильных ответов.
Grafana
Тут начнем с grafana
сама по себе она практически ничего не делает, но ее можно пристегнуть как красивую морду к любой из нижеописанных систем и получить красивые и иногда наглядные графики, кроме того тут же можно настроить алармы, но лучше для этого использовать другие решения например prometheus alertmanager
и ElastAlert
.
fluent-bit
С моей точки зрения на данный момент это лучший агрегатор и роутер логов, кроме того прямо из коробки в нем есть поддержка k8s. Есть еще Fluentd
но он писан на руби и тянет за собой слишком много легаси кода, что делает его гораздо менее привлекательным. Так что если вам нужен какой-то конкретный модуль из fluentd который еще не портирован в fluent-bit пользуйте его, во всех остальных — бит это лучший выбор. Он быстрее, стабильнее, потребляет меньше памяти. Позволяет собирать логи из всех или из избранных контейнеров, фильтровать их, обогащать добавляя данные специфические для кубернетиса и отправлять это все в elasticsearch или во множество других хранилищ. Если сравнить его с традиционными logstash + docker-bit + file-bit
это решение однозначно лучше по всем параметрам. Исторически мы все еще используем logspout + logstash
но fluent-bit однозначно выигрывает.
Prometheus
Система мониторинга написанная специально для микросервисной архитектуры. Де факто стандарт в индустрии, более того есть еще проект который называется Prometheus Operator
, писаный специально для k8s. Что выбрать решает каждый сам, но начинать лучше с голого прометеуса, просто для того чтобы понять логику его работы, она достаточно сильно отличается от привычных систем. Еще надо упомянуть node-exporter
который позволяет собирать метрики уровня машины и prometheus-rancher-exporter который позволяет собирать метрики через rancher api. В общем если у вас есть кластер на kubernetes, то prometheus — must have.
Тут можно было бы и остановиться, но исторически сложилось, что у нас есть еще несколько систем мониторинга. Во первых это zabbix
очень удобно на одной панели видеть все проблемы всей инфраструктуры. Наличие авто дискавери позволяет на лету находить и добавлять в мониторинг новые сети, ноды, сервисы и вообще практически что угодно, это делает его более чем удобным инструментом для мониторинга динамических инфраструктур. Кроме того в версии 4.0 в заббикс добавили сбор метрик из экспортеров прометеуса и получается, что все это можно очень красиво интегрировать в одну систему. Хотя нет пока однозначного ответа надо ли тащить zabbix в k8s кластер, но попробовать однозначно интересно.
Еще просто как вариант можно использовать TIG (telegraf + influxdb + grafana)
настраивается просто, работает стабильно, позволяет агрегировать метрики, по контейнерам, приложениям, нодам и прочее, но по сути полностью дублирует функционал prometheus, а "остаться должен только один".
Вот так и получается, что еще не запустив ничего полезного, надо установить и настроить обвязку из пары десятков вспомогательных сервисов и инструментов. При этом в статье не были подняты вопросы управления постоянными данными, секретами и прочими странными вещами каждый из которых может потянуть на отдельную публикацию.
А как вы себе видите идеальную инфраструктуру?
Если есть мнение напишите пожалуйста в комментариях, а может даже присоединяйтесь к нашей команде и помогите собрать это все на месте.