# Kubernetes
## Какую проблему мы хотим решить? Она у нас правда есть?

*Проблемы с текущей инфраструктурой:*
1) Неповторяемость - если что-то было развернуто, нельзя развернуть то же самое простым и понятным образом, особенно, чтобы это делал другой человек. Приходится рыться в истории команд консоли, гуглить что-то, делать скрипты из того, что делал в прошлый раз, при этом нет единого места для их хранения. Разные разработчики заходят на сервер и меняют конфигурацию, повышая энтропию. Где-то ufw пакет удалён, а где-то нет;
2) Сложность развертывания - запустить и настроить машину для тестирования и развертывания сервиса достаточно долгий процесс. Создание машины в ESXI может занять день и больше, научить нового человека это делать сложно. Не во всех ESXI можно создать виртуалку;
3) Нет людей имеющих профильную экспертизу в сетевых технологиях (и в сисадминстве в целом) - если возникнут проблемы, нет кого-то кто мог бы их решить быстро и четко, Азат может, но Азат не может делать все постоянно) Плюс Азат разработчик, а не сисадмин/сетевик, и он всё равно не компетентен;
4) Нет общей картины, как устроены все внутренние ресурсы - есть репозиторий в гите с описанием инфраструктуры и реестром виртуалок, но это не выглядит очень надежным, и репозиторий не обновляется, хотя мы создаём новые виртуалки. Мы умеем деплоить только на одном ESXi, а как поднять на других - никто не знает
5) Архитектура не advanced - мы не можем, в данным момент, проводить должным образом канареечные релизы, автомасштабирование, балансировку;
6) Есть проблемы с внутренними ресурсами и повторяющиеся запросы - Gitlab и Nexus, на которых часто заканчивается место, Gitlab лежит на какой-то машине с шифрованием и можно вообще потерять все данные оттуда(пароль лежит где-то в конфигах загрузки, вроде, в grub), сертификаты let’s encrypt протухают периодически;
7) Нет обновлений безопасности - мы не обновляем операционки на наших серваках и нет никаких оповещений об этом и никакого механизма, чтобы от этого защититься;
8) Есть потенциальная проблема с пересечением сетей в Docker'е
9) Мертвые сервера - иногда по окончании какого-то проекта или задачи виртуалка остается и прожигает ресурсы впустую

Если резюмировать, то все проблемы от довольно кастомной неавтоматизированной инфраструктуры (хаос), содержащей кучу неочевидных ньюансов

## Как мы именно мы предполагаем ее решить с помощью K8S?

Философски: нам нужно избавиться от уровня infrastructure (и ниже) в терминах облаков и накрутить автоматизацию. Если мы выбрасываем этот уровень, то мы выбрасываем и все, связанные с ним проблемы (кроме примочек деплоя типа rolling updates). Тогда нам остаются доступными только уровни PaaS и SaaS. И если мы добавляем автоматизацию в эти уровни (то есть пользуемся готовыми средствами), то мы получаем ещё и плюшки деплоя. Таким образом, нам нужно смотреть в сторону PaaS типа k8s, heroku, GAE и redshift, а также в сторону SaaS типа облачного Gitlab, облачного Sentry

Мы переносим всю инфраструктуру в кубернетис. Создаем два кластера: для прода и для стейджа и разделяем проекты засчет неймспейсов. Это упростит развёртывание виртуалок, позволит выполнять единообразные развертывания «по кнопке». Упростит автоскейлинг, за счет того, что кубернетис уже имеет средства для этого.

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

Все будет в одном месте.

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

Часть проблем, например, проблему с Gitlab'ом, потенциально можно решить при помощи SaaS и кубер здесь ни при чем.

## Сколько примерно это займет часов работы?
Оценить сложно из-за неопределенности в части объема работы, нужно попробовать развернуть что-то в облаке, чтобы понять насколько это трудоемко
Нужно собрать информацию о всех ресурсах, что нам необходимы и исходя из этого будет понятно.
По словам Азата полный переезд может занять очень много времени

## Бонус: какие бенефиты нам это принесет? Сможем ли мы как это монетизировать? Сможем ли мы делать работу лучше/быстрее? Сможем ли мы делать какую-то новую работу, которую раньше не могли?

- Предположительное удешевление инфраструктуры засчет автомасштабирования
- Деплой будет проходить быстрее и надежнее, возможность проводить канареечные релизы
- Развертывание будет более надежным, с автоматическим масштабированием и возможностью обеспечения больше отказоустойчивости
- Мы будем иметь готовое и понятное решение для развертывания проекта
- Мы получаем экспертизу в развертывании проекта на кубернетисе в облаке. В целом мы вполне можем продавать DevOps типа Express42. И тот факт, что мы не умеем разворачивать сам k8s нам не помешает, потому что тут дело в использовании инструментов, в процессах и философии, а не в создании самих инструментов. А в плане процессов мы уже очень круты, философа можем нанять из МГУ. Кроме того, у нас есть не-бэкэнд практики, и мы можем прокачать DevOps в этих практиках, имея уникальный опыт
- Можно продавать бэк вместе с инфраструктурой и ее обслуживанием

## Если принимаем решение делать - кто будет отвечать за результат? В какой срок мы хотим добиться результата и какого? Какой Definiton of Done?

*Нужно еще обсудить*

Максимальный результат, которого мы можем достичь - это развертывание всей инфраструктуры в облаке.

MVP - это развертывание одного проекта, после этого можно понять насколько это целесообразно и сложно. Есть идея начать с Watcher'а.

Хотели еще собрать в один документ:
- Как есть сейчас?
- Что будет, если развернем в кубере?
- Какие проблемы есть с инфраструктурой?
- Посчитать сколько будет стоить
Хочется получить какие-то измеримые показатели, но какие пока непонятно.

Если всех устраивает, то Азат готов отвечать за результат и взять на себя ответственность. Антон готов помочь Азату.

## Задачи

Завершить развертывание watcher в нашем самодельном k8s
Попробовать развернуть проект в облаке и получить какую-то рефлексию в результате
Изучить какие сервисы мы могли бы перенести в SaaS
Проресерчить неймспейсы в кубере
Собрать инфу о текущем положении вещей, дополнить и конкретизировать список проблем
Собрать вопросы, которые мы должны исследовать перед внедрением, распределить по людям и исследовать
Посчитать разницу в цене потребляемых услуг между нашим классическим деплоем поверх IaaS (Selectel/Hetzner/Digital Ocean) и Kubernetes (Mail-сру Cloud Solutions)