Привет, Хабр!
Мы представляем команду платформы компании Exness. Ранее наши коллеги уже писали статью про Production-ready images for k8s. Сегодня мы хотим поделиться опытом миграции сервисов в Kubernetes.
![](https://habrastorage.org/r/w1560/webt/_w/_v/4y/_w_v4y4cimb9xplp-da3e-cnwx4.png)
Для начала предлагаем вам немного цифр для большего понимания того, о чем будет идти речь:
Как говорится, ничто не вечно под луной, и Rancher уже достаточно давно объявил о прекращении поддержки версии 1.6. Да, мы более чем за три года научились его готовить и решать возникающие проблемы, но все чаще мы сталкивались с проблемами, которые никогда не будут исправлены. Также Rancher 1.6 имеет закостенелую систему выдачи прав, где ты либо можешь почти все, либо ничего.
Собственная виртуализация хоть и предоставляла больший контроль над хранением данных и их безопасностью, но накладывала операционные расходы, с которыми трудно было мириться при постоянном росте компании, количестве проектов и требований к ним.
Нам хотелось следовать стандартам IaC и при необходимости получить мощности быстро, в любой географической локации и без вендор лока, а также иметь возможность быстро от них отказаться.
Прежде всего мы хотели опираться на современные технологии и решения, которые бы позволили командам иметь более быстрый цикл разработки и снижать к минимуму операционные расходы на взаимодействие с платформой, предоставляющей мощности.
Конечно же, первое, что пришло нам в голову — это Kubernetes, но мы не стали горячиться и провели небольшое исследование на предмет верности выбора. Мы оценивали только opensource решения, и в нечестной схватке безоговорочно победил Kubernetes.
Далее стал вопрос выбора инструмента для создания кластеров. Мы сравнили самые популярные решения: kops, kubespray, kubeadm.
Для старта kubeadm показался нам слишком сложным путем, скорее, неким изобретателем «велосипеда», а у kops не хватало гибкости.
И победителем вышел:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/35e/1e6/e85/35e1e6e85e12e982649fd020862463cd.png)
Мы начали ставить эксперименты на собственной виртуализации и AWS, пытаясь воссоздать примерное подобие нашего предыдущего паттерна управления ресурсами, где все используют один и тот же «кластер». И вот у нас появился первый кластер размером в 10 небольших виртуальных машин, пара из которых находится в AWS. Мы начали пробовать мигрировать туда команды, вроде бы все стало «хорошо», и рассказ можно было бы закончить, но…
Ansible — то, на чем построен kubespray, это не тот инструмент который позволяет следовать IaC: при вводе/выводе нод из эксплуатации постоянно что-то шло не так, и требовалось какое-либо вмешательство, а при использовании разных ОС плейбук вел себя по-разному. С ростом количества команд и нод в кластере мы стали замечать, что плейбук выполнялся все дольше и дольше, в итоге, наш рекорд 3,5 часа, а ваш? :)
И вроде как kubespray это просто Ansible, и все понятно на первый взгляд, но:
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/11e/593/7d7/11e5937d7576851ad38e8469502e6d7f.jpg)
В начале пути стояла задача запускать мощности только в AWS и на виртуализации, но потом, как это часто бывает, требования изменились.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/e4f/b1b/f10/e4fb1bf10754dc4ea192c0a05d2e524c.png)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/e1d/eeb/7d5/e1deeb7d5c4b2392962fbe5b6a528388.png)
В свете этого стало понятно, что наш старый паттерн объединения ресурсов в одну систему оркестрации не подходил — в случае, когда кластеры сильно удалены и находятся под управлением разных провайдеров.
Дальше — больше. Когда все команды работают в пределах одного кластера, различные сервисы с неправильно установленными NodeSelector могли прилететь на «чужой» хост другой команды и там утилизировать ресурсы, а в случае выставления taint — появлялись постоянные обращения о том, что тот или иной сервис не работает, не распределяется правильно из-за человеческого фактора. Еще одной проблемой оказался расчет стоимости, особенно учитывая проблемы при распределении сервисов по нодам.
Отдельной историей шла выдача прав сотрудникам: каждая команда хотела быть «во главе» кластера и полностью им управлять, что могло вызвать полный коллапс, так как команды в основном друг от друга независимы.
Учитывая вышеописанное и пожелания команд быть более независимыми, мы сделали простой вывод: одна команда — один кластер.
Так у нас появился второй:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/5ca/125/895/5ca125895d8571f18c41034f226c65d5.png)
А потом и третий кластер:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/81b/7a9/f75/81b7a9f755d7be0798ec641ef8d444ae.png)
Тут мы начали думать: допустим, через год у наших команд будет не один кластер? В разных географических зонах, например, или под управлением разных провайдеров? А кто-то из них захочет иметь возможность быстро развернуть временный кластер для каких-либо тестов.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/265/52e/0a5/26552e0a5bb71a6f82b3dd4f3226b768.png)
Наступил бы полный Кубернетес! Это какой-то MultiKubernetes, получается.
При этом, всем нам надо будет каким-то образом поддерживать все эти кластеры, иметь возможность легко управлять доступом к ним, а также создавать новые и выводить старые из эксплуатации без ручного вмешательства.
С момента начала нашего пути в мире Кубернетеса прошло некоторое время, и мы решили сделать повторное изучение доступных решений. Оказалось, что на рынке оно уже есть — Rancher 2.2.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/9a2/c00/e81/9a2c00e81c4d2a0daf2b6f0a7afe8c0a.jpg)
На первом этапе наших исследований Rancher Labs уже сделали первый релиз версии 2, но хоть его и можно было очень быстро поднять, запустив контейнер без внешних зависимостей с парой параметров или используя официальный HELM Chart, она нам показалось сырой, и мы не знали, можем ли положиться на это решение, будут ли его развивать или быстро забросят. Сама парадигма кластер = клики в UI нам также не подходила, и мы не хотели привязываться к RKE, так как это достаточно узконаправленный инструмент.
Версия Rancher 2.2 уже имела более работоспособный вид и вкупе с предыдущими обладала кучей интересных возможностей из коробки таких, как интеграция со многими внешними провайдерами, единая точка дистрибуции прав и kubeconfig файлов, запуск образа kubectl с твоими правами в UI, вложенные неймспейсы aka проекты.
Также вокруг Rancher 2 уже сформировалось комьюнити, и был создан провайдер HashiCorp Terraform для управления им, который помог нам собрать все воедино.
В итоге у нас получился один маленький кластер, в котором запущен Rancher, доступный всем остальным кластерам, а также много кластеров с ним связанных, доступ к любому из которых можно выдать также просто, как добавить пользователя в ldap каталог вне зависимости от того, где он находится и ресурсы какого провайдера использует.
С помощью gitlab-ci и Terraform была создана система, позволяющая создать кластер любой конфигурации в облачных провайдерах или нашей собственной инфраструктуре и подключить их к Rancher. Все это выполнено в стиле IaC, где каждый кластер описан репозиторием, а его состояние версионируется. При этом большинство модулей подключаются из внешних репозиториев так, что остается только передать переменные или описать свою кастомную конфигурацию для инстансов, что помогает уменьшить процент повторяемости кода.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/eae/814/877/eae814877be3c3a957b6f75a2c657f58.png)
Конечно, наше путешествие далеко не закончено и впереди еще много интересных задач таких, как единая точка работы с логами и метриками любых кластеров, service mesh, gitops для управления нагрузками в мультикластере и многое другое. Надеемся, вам будет интересен наш опыт!
Статью писали А. Антипов, А. Гануш, Platform Engineers.
Мы представляем команду платформы компании Exness. Ранее наши коллеги уже писали статью про Production-ready images for k8s. Сегодня мы хотим поделиться опытом миграции сервисов в Kubernetes.
![](https://habrastorage.org/webt/_w/_v/4y/_w_v4y4cimb9xplp-da3e-cnwx4.png)
Для начала предлагаем вам немного цифр для большего понимания того, о чем будет идти речь:
- Наш отдел разработки это 100+ человек, среди которых более 10 различных команд с самодостаточными процессами QA, DevOps и Scrum. Стек разработки — Python, PHP, C++, Java и Golang.
- Размер тестовой и продуктовой среды— около 2000 контейнеров в каждой. Находятся они под управлением Rancher v1.6 на своей виртуализации и под VMware.
Мотивация
Как говорится, ничто не вечно под луной, и Rancher уже достаточно давно объявил о прекращении поддержки версии 1.6. Да, мы более чем за три года научились его готовить и решать возникающие проблемы, но все чаще мы сталкивались с проблемами, которые никогда не будут исправлены. Также Rancher 1.6 имеет закостенелую систему выдачи прав, где ты либо можешь почти все, либо ничего.
Собственная виртуализация хоть и предоставляла больший контроль над хранением данных и их безопасностью, но накладывала операционные расходы, с которыми трудно было мириться при постоянном росте компании, количестве проектов и требований к ним.
Нам хотелось следовать стандартам IaC и при необходимости получить мощности быстро, в любой географической локации и без вендор лока, а также иметь возможность быстро от них отказаться.
Первые шаги
Прежде всего мы хотели опираться на современные технологии и решения, которые бы позволили командам иметь более быстрый цикл разработки и снижать к минимуму операционные расходы на взаимодействие с платформой, предоставляющей мощности.
Конечно же, первое, что пришло нам в голову — это Kubernetes, но мы не стали горячиться и провели небольшое исследование на предмет верности выбора. Мы оценивали только opensource решения, и в нечестной схватке безоговорочно победил Kubernetes.
Далее стал вопрос выбора инструмента для создания кластеров. Мы сравнили самые популярные решения: kops, kubespray, kubeadm.
Для старта kubeadm показался нам слишком сложным путем, скорее, неким изобретателем «велосипеда», а у kops не хватало гибкости.
И победителем вышел:
![](https://habrastorage.org/getpro/habr/post_images/35e/1e6/e85/35e1e6e85e12e982649fd020862463cd.png)
Мы начали ставить эксперименты на собственной виртуализации и AWS, пытаясь воссоздать примерное подобие нашего предыдущего паттерна управления ресурсами, где все используют один и тот же «кластер». И вот у нас появился первый кластер размером в 10 небольших виртуальных машин, пара из которых находится в AWS. Мы начали пробовать мигрировать туда команды, вроде бы все стало «хорошо», и рассказ можно было бы закончить, но…
Первые Проблемы
Ansible — то, на чем построен kubespray, это не тот инструмент который позволяет следовать IaC: при вводе/выводе нод из эксплуатации постоянно что-то шло не так, и требовалось какое-либо вмешательство, а при использовании разных ОС плейбук вел себя по-разному. С ростом количества команд и нод в кластере мы стали замечать, что плейбук выполнялся все дольше и дольше, в итоге, наш рекорд 3,5 часа, а ваш? :)
И вроде как kubespray это просто Ansible, и все понятно на первый взгляд, но:
![](https://habrastorage.org/getpro/habr/post_images/11e/593/7d7/11e5937d7576851ad38e8469502e6d7f.jpg)
В начале пути стояла задача запускать мощности только в AWS и на виртуализации, но потом, как это часто бывает, требования изменились.
![](https://habrastorage.org/getpro/habr/post_images/e4f/b1b/f10/e4fb1bf10754dc4ea192c0a05d2e524c.png)
![](https://habrastorage.org/getpro/habr/post_images/e1d/eeb/7d5/e1deeb7d5c4b2392962fbe5b6a528388.png)
В свете этого стало понятно, что наш старый паттерн объединения ресурсов в одну систему оркестрации не подходил — в случае, когда кластеры сильно удалены и находятся под управлением разных провайдеров.
Дальше — больше. Когда все команды работают в пределах одного кластера, различные сервисы с неправильно установленными NodeSelector могли прилететь на «чужой» хост другой команды и там утилизировать ресурсы, а в случае выставления taint — появлялись постоянные обращения о том, что тот или иной сервис не работает, не распределяется правильно из-за человеческого фактора. Еще одной проблемой оказался расчет стоимости, особенно учитывая проблемы при распределении сервисов по нодам.
Отдельной историей шла выдача прав сотрудникам: каждая команда хотела быть «во главе» кластера и полностью им управлять, что могло вызвать полный коллапс, так как команды в основном друг от друга независимы.
Как быть?
Учитывая вышеописанное и пожелания команд быть более независимыми, мы сделали простой вывод: одна команда — один кластер.
Так у нас появился второй:
![](https://habrastorage.org/getpro/habr/post_images/5ca/125/895/5ca125895d8571f18c41034f226c65d5.png)
А потом и третий кластер:
![](https://habrastorage.org/getpro/habr/post_images/81b/7a9/f75/81b7a9f755d7be0798ec641ef8d444ae.png)
Тут мы начали думать: допустим, через год у наших команд будет не один кластер? В разных географических зонах, например, или под управлением разных провайдеров? А кто-то из них захочет иметь возможность быстро развернуть временный кластер для каких-либо тестов.
![](https://habrastorage.org/getpro/habr/post_images/265/52e/0a5/26552e0a5bb71a6f82b3dd4f3226b768.png)
Наступил бы полный Кубернетес! Это какой-то MultiKubernetes, получается.
При этом, всем нам надо будет каким-то образом поддерживать все эти кластеры, иметь возможность легко управлять доступом к ним, а также создавать новые и выводить старые из эксплуатации без ручного вмешательства.
С момента начала нашего пути в мире Кубернетеса прошло некоторое время, и мы решили сделать повторное изучение доступных решений. Оказалось, что на рынке оно уже есть — Rancher 2.2.
![](https://habrastorage.org/getpro/habr/post_images/9a2/c00/e81/9a2c00e81c4d2a0daf2b6f0a7afe8c0a.jpg)
На первом этапе наших исследований Rancher Labs уже сделали первый релиз версии 2, но хоть его и можно было очень быстро поднять, запустив контейнер без внешних зависимостей с парой параметров или используя официальный HELM Chart, она нам показалось сырой, и мы не знали, можем ли положиться на это решение, будут ли его развивать или быстро забросят. Сама парадигма кластер = клики в UI нам также не подходила, и мы не хотели привязываться к RKE, так как это достаточно узконаправленный инструмент.
Версия Rancher 2.2 уже имела более работоспособный вид и вкупе с предыдущими обладала кучей интересных возможностей из коробки таких, как интеграция со многими внешними провайдерами, единая точка дистрибуции прав и kubeconfig файлов, запуск образа kubectl с твоими правами в UI, вложенные неймспейсы aka проекты.
Также вокруг Rancher 2 уже сформировалось комьюнити, и был создан провайдер HashiCorp Terraform для управления им, который помог нам собрать все воедино.
Что получилось
В итоге у нас получился один маленький кластер, в котором запущен Rancher, доступный всем остальным кластерам, а также много кластеров с ним связанных, доступ к любому из которых можно выдать также просто, как добавить пользователя в ldap каталог вне зависимости от того, где он находится и ресурсы какого провайдера использует.
С помощью gitlab-ci и Terraform была создана система, позволяющая создать кластер любой конфигурации в облачных провайдерах или нашей собственной инфраструктуре и подключить их к Rancher. Все это выполнено в стиле IaC, где каждый кластер описан репозиторием, а его состояние версионируется. При этом большинство модулей подключаются из внешних репозиториев так, что остается только передать переменные или описать свою кастомную конфигурацию для инстансов, что помогает уменьшить процент повторяемости кода.
![](https://habrastorage.org/getpro/habr/post_images/eae/814/877/eae814877be3c3a957b6f75a2c657f58.png)
Конечно, наше путешествие далеко не закончено и впереди еще много интересных задач таких, как единая точка работы с логами и метриками любых кластеров, service mesh, gitops для управления нагрузками в мультикластере и многое другое. Надеемся, вам будет интересен наш опыт!
Статью писали А. Антипов, А. Гануш, Platform Engineers.