Часть 1 Разворачиваем среду для работы с микросервисами. Часть 1 установка Kubernetes HA на bare metal (Debian) В прошлой публикации я рассказал, как развернуть отказоустойчивый кластер Kubernetes. Но дело в том, что в Kubernetes удобно деплоить stateless приложения, которым не требуется сохранять свое состояние или работать с данными. Но в большинстве случаев нам требуются сохранять данные и не терять их при рестартах подов.
Для этих целей в Kubernetes используются тома (volume). Когда мы работаем с облачными решениями Kubernetes, то проблем особо нет. Нам лишь нужно у Google, Amazon или иного облачного провайдера заказать требуемый объем и, руководствуясь документаций , подключить полученные тома к подам.
Когда же мы имеем дело с bare metal, тут дела обстоят немного сложнее. Сегодня я хочу рассказать об одном из решений основанном на использовании ceph. В данной публикации я расскажу:  Для начала я хотел бы объяснить для кого будет полезна эта статья. Во первых, для читателей, которые разворачивали кластер по моей первой публикации, чтобы продолжать выстраивать микросервисную архитектуру. Во вторых, для людей, которые хотят попробовать самостоятельно развернуть кластер ceph и оценить его работу.  В данной публикации я не буду затрагивать тему планирования кластера под какие либо нужды, я лишь расскажу общие принципы и понятия. Не буду углублятся в "тюнинг" и глубокую настройку, на эту тему есть много публикаций, в том числе и на хабре. Статья будет носить более ознакомительный характер, но при этом позволит получить рабочее решение, которое Вы в дальнейшем сможете адаптировать под Ваши нужды. При написании статьи я использую виртуальные машины вот такой конфигурации  На каждой установлена ОС Debian 9.5. Это тестовые машины, в каждой два диска, первый под ОС, второй для OSD цефа. Разворачивать кластер я буду через утилиту ceph-deploy. Можно разворачивать кластер ceph и в ручном режиме, все шаги описаны в документации, но целью данной статьи является рассказать, как быстро можно развернуть ceph и начать использовать его в kubernetes.
Ceph довольно прожорлив к ресурсам особенно к оперативной памяти. Для хорошей скорости желательно использовать ssd диски. Более подробно про требования можно почитать в официальной документации ceph
 MON
Монитор — это демон, выполняющий роль координатора, с которого начинается кластер. Как только у нас появляется хотя бы один рабочий монитор, у нас появляется Ceph-кластер. Монитор хранит информацию о здоровье и состоянии кластера, обмениваясь различными картами с другими мониторами. Клиенты обращаются к мониторам, чтобы узнать, на какие OSD писать/читать данные. При разворачивании нового хранилища, первым делом создается монитор (или несколько). Кластер может прожить на одном мониторе, но рекомендуется делать 3 или 5 мониторов, во избежание падения всей системы по причине падения единственного монитора. Главное, чтобы количество оных было нечетным, дабы избежать ситуаций раздвоения сознания (split-brain). Мониторы работают в кворуме, поэтому если упадет больше половины мониторов, кластер заблокируется для предотвращения рассогласованности данных.
MGR
Менеджер Ceph демон работает вместе с демоном монитора, чтобы обеспечить дополнительный контроль.
С версии 12.x демон ceph-mgr стал необходим для нормальной работы.
Если демон mgr не запущен, вы увидите предупреждение об этом.
OSD (Object Storage Device)
OSD — это юнит хранилища, который хранит сами данные и обрабатывает запросы клиентов, обмениваясь данными с другими OSD. Обычно это диск. И обычно за каждый OSD отвечает отдельный OSD-демон, который может запускаться на любой машине, на которой установлен этот диск. На каждой машине нашего кластера будут работать все три демона. Соответственно, демоны монитора и менеджера как служебные, и демон OSD для одного диска нашей виртуальной машины. В документации ceph указана следующая схема работы:  Я буду работать с первой ноды кластера ceph01-test она же и будет Admin Node, на ней же будут конфигурационные файлы для утилиты ceph-deploy. Для корректной работы утилиты ceph-deploy все узлы кластера должны быть доступны по ssh c Admin node. Я для удобства пропишу в hosts короткие имена для кластера И скопирую ключи на остальные хосты. Все команды я буду выполнять из под root. Документация по настройке Первым шагом установим ceph-deploy на машине ceph01-test Далее нужно выбрать релиз, который Вы хотите ставить. Но тут возникают сложности, в настоящее время ceph для ОС Debian поддерживают только пакеты luminous.
Если вы хотите поставить более свежий релиз то придется воспользоваться зеркалом, например
https://mirror.croit.io/debian-mimic/dists/ Добавляем репозиторий с mimic на всех трех нодах Если Вам достаточно luminous то можно воспользоваться официальными репозиториями Так же установим NTP на всех трех нодах. We recommend installing NTP on Ceph nodes (especially on Ceph Monitor nodes) to prevent issues arising from clock drift.
 Убедитесь, что вы включили службу NTP. Убедитесь, что каждый узел Ceph использует один и тот же сервер NTP. Более подробно посмотреть можно тут Создадим каталог для конфиг файлов и файлов ceph-deploy Создадим конфиг нового кластер, при создании укажем что в нашем кластере будет три монитора Теперь важный момент, настало время поговорить о сети для ceph. Ceph для работы использует две сети public network и cluster network
 Как видно из схемы public network это уровень пользователя и приложений, а cluster network это сеть по которой происходит репликация данных.
Очень желательно отделять эти две сети друг от друга. Также скорость сети cluster network желательна не меньше 10 Gb.
Конечно, можно все держать в одной сети. Но это черевато тем, что как только возрастет объем репликаций между OSD, например, при падении или добавлении новых OSD (дисков), то нагрузка на сеть ОЧЕНЬ сильно возрастет. Так что скорость и стабильность вашей инфраструктуры, будет сильно зависеть от сети используемой ceph.
На моем кластере виртуализации к сожалению нет отдельной сети, и я буду использовать общий сегмент сети.
Настройка сети для кластера производится через конфиг файл, который мы сгенерировали предыдущей командой. Как мы видим цеф деплой не создал нам настройки сети по умолчанию, по этому я добавлю в конфиг в раздел global параметр public network = {public-network/netmask}. Моя сеть 10.73.0.0/16 по этому после добавления мой конфиг будет выглядеть следующим образом  Если Вы хотите отделить сеть cluster от public, то добавьте параметр cluster network = {cluster-network/netmask}
Более подробно про сети можно почитать в документации C помощью ceph-deploy установим все нужные нам пакеты ceph на наши три ноды.
Для этого на ceph01-test выполним
Если версия mimic то Если версия luminous то И подождем пока все установится. После того как все пакеты установлены, мы созданим и инициируем мониторы нашего кластера.
C ceph01-test выполняем следующее В процессе будут созданы мониторы, запущены демоны, также ceph-deploy проверит quorum.
Теперь раскидаем конфиги по нодам кластера. И проверим статус нашего кластера, если Вы все сделали правильно то статус должен быть
HEALTH_OK Создадим mgr И еще раз проверим статус  Должна появится строчка  Запишем конфиг на все хосты кластера В данный момент мы имеем работающий кластер, но в нем еще нет дисков (osd в терминологии ceph) для хранения информации. OSD можно добавить следующей командой (общий вид) В моем тестовом стенду под osd выделен disk /dev/sdb, по этому в моем случае команды будут следующие Проверим что все OSD работают Вывод Так же можете попробовать полезные команды для OSD и Если все ОК, то мы имеем работоспособный кластер ceph. В следующей части я расскажу как использовать ceph с kubernetes К сожалению, я не смогу в рамках данной статьи подробно рассказать про работу томов Kubernetes, поэтому попробую уложиться в один абзац.
Для работы с томами данных данных Kubernetes использует storage classes, для каждого storage class есть свой provisioner, можно рассматривать его как некий "драйвер" для работы с различными томами хранения данных. Полный список который поддерживает kubernetes можно посмотреть в официальной документации.
В самом Kubernetes так же есть поддержка работы с rbd, но в официальном образе kube-controller-manager нет установленного клиента rbd, поэтому нужно использовать другой образ.
Также следует учесть, что тома (pvc) созданные как rbd могут быть только ReadWriteOnce (RWO) и, а это значит что созданный том Вы сможете примонтировать ТОЛЬКО к одному поду. Для того что бы наш кластер смог работать с томами на ceph, нам нужно:
в кластере Сeph: Для того что бы наш кластер смог работать с томами на ceph, нам нужно:
в кластере Сeph: в кластере Kubernetes: В кластере ceph создадим pool для томов kubernetes Тут я сделаю небольшое пояснение, цифры 8 8 в конце это количество pg и pgs. Эти значения зависят от размера Вашего кластера ceph. Есть специальные калькуляторы которые рассчитывают количество pg и pgs, например официальный от ceph
Для начала я рекомендую оставить по умолчанию, если что в будущем это количество можно увеличить (уменьшить можно только с версии Nautilus). Создадим клиента для нового пула  Получим ключ для клиента, в дальнейшем он понадобится нам для создания secret kubernetes И получим админский ключ На кластере ceph все работы завершены и теперь нам нужно перейти на машину которая имеет доступ до кластера kubernetes 
Я буду работать с master01-test (10.73.71.25) кластера развернутого мной в первой публикации. Создадим файл с клиентским токеном который мы получили (не забудьте заменить на свой токен) И создадим secret, который будем использовать в дальнейшем Создадим файл с админским токеном (не забудьте заменить на свой токен) После этого создадим admin secret  Проверим что секреты создались Клонируем с github репозиторий kubernetes-incubator/external-storage, в нем есть все необходимое для того чтобы 'подружить' кластер kubernetes c хранилищем ceph. Вывод В официальном образе kube-controller-manager нет поддержки rbd, поэтому нам нужно будет изменить образ controller-manager.
Для этого на каждом из мастеров Kubernetes нужно отредактировать файл kube-controller-manager.yaml и заменить image на gcr.io/google_containers/hyperkube:v1.15.2. Обратите внимание на версию образа она должна соответствовать Вашей версии кластера Kubernetes. После этого нужно будет рестартовать kube-controller-manager Поды должны обновиться автоматически, но если этого по какой либо причине не произошло то можно пересоздать их в ручную, через удаление. Проверим что все ОК - Способ первый — если вы использовали provisioner ceph.com/rbd
Создадим yaml файл с описанием нашего storage class. Также все файлы используемые ниже можно скачать в моем репозитории  в каталоге ceph И задеплоим его в наш кластер  Проверим что все ОК Способ второй — если вы использовали provisioner kubernetes.io/rbd
Создаем storage-class И задеплоим его в наш кластер  Проверим что все ОК Перед тем как тестировать работу ceph + kubernetes, на КАЖДОЙ воркноде кластера нужно установить пакет ceph-common. Создадим yaml файл PersistentVolumeClaim Задеплоим его  Проверим что PersistentVolumeClaim создался.  А также автоматически создался PersistentVolume. Создадим один тестовый pod, в котором мы подключим созданный pvc в каталог /mnt. Пускай данный файл /mnt/test.txt c текстом "Hello World!" Задеплоим его и проверим, что он выполнил свою задачу Дождемся статуса  Создадим другой под, подключим к нему наш том но уже в /mnt/test, а после этого убедимся, что созданный первым томом файл на месте Выполним kubectl get po -w и дождемся пока pod будет в статусе running
После этого зайдем в него и проверим что том подключился и наш файл в каталоге /mnt/test Спасибо за то что прочитали до конца. Извиняюсь за задержку публикации.
На все вопросы я готов ответить в личных сообщениях или в соцсетях, которые указаны у меня в профиле.
В следующей небольшой публикации я расскажу, как на базе созданного ceph кластера развернуть хранилище S3, и далее по плану из первой публикации. Материалы используемые для публикации  DevOps