Как-то я уже писал тут о переезде из Азии в Европу, а теперь хочу написать, что я в этой Европе делаю. Есть такая профессия — DevOps, точнее нет, но так получилось, что это именно то чем я сейчас занимаюсь. Сейчас для оркестрации всего что бежит в докере мы используем rancher, о чем я тоже уже писал. Но вот случилось ужасное, вышел ранчер 2.0 который переехал на kubernetes (дальше просто k8x) и поскольку k8x сейчас действительно стандарт для управления кластером, возникло желание тоже построить всю инфраструктуру заново с блекджеком и библиотекаршами. Что еще добавляет пикантности это то что компания постоянно нанимает разных специалистов из разных стран и с разными традициями и кто-то и собой приносит 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, а "остаться должен только один".
Вот так и получается, что еще не запустив ничего полезного, надо установить и настроить обвязку из пары десятков вспомогательных сервисов и инструментов. При этом в статье не были подняты вопросы управления постоянными данными, секретами и прочими странными вещами каждый из которых может потянуть на отдельную публикацию.
А как вы себе видите идеальную инфраструктуру?
Если есть мнение напишите пожалуйста в комментариях, а может даже присоединяйтесь к нашей команде и помогите собрать это все на месте.
Автор: kefiiir
