1) Прежде всего нужно удалить из /etc/hosts связку хостнейма и 127.0.0.1, в противном случае команда ceph-deploy не пройдет и упадет с ошибкой:
Вы что-то делали не так) Разумеется, если вы используете домен вида: kub01, то он должен резолвится. Если он прописан в /etc/hosts как 127.0.0.1, то он будет резолвится, и такой ошибки быть не должно. И да, наверное его лучше не прописывать как 127.0.0.1.
Я на эту проблему не попадал, так как hostname серверу задавал уже после инсталляции сервера.
2) На всех тачках нужно поставить python. Без него все тот же ceph-deploy будет валиться с ошибкой, только уже с другой:
У вас Ubunta? Странно, что python не поставился по зависимостям, при установке самого ceph-deploy…
Я python ставил отдельно, так как была необходимость запускать ansible (для своих целей).
коннектимся от имени рута, то нужно разрешить ssh коннект от рута, потому что в Ubuntu 16.04 по дефолту он запрещен.
Спасибо за замечание. Подумаю как это решить по изящнее)
В итоге помог ребут тачки.
Это какой-то windows-way. Всегда бейте себя по рукам за такое)
У меня нет четкого ответа на это. Обычно, k8s сам замечает изменения и перезапускает controller. Но если этого не произошло, то можно перезапустить: kubelet и docker. Если кто знает, как это сделать красиво, отпишитесь.
5) На шаге присоединения нод не хватает однозначности. Что мы в итоге делаем, новый токен или используем старый. Если используем старый то как собрать команду приведенную вами? А самое главное IP 8.8.8.8 очень путает.
Если у вас есть «старый» токен, то можно использовать его. Самое простое, это сохранить команду «присоединения», которая пишется после инсталляции k8s (kubeadm init ...).
Если по каким-то причинам, у вас нет этой команды, то смело создавайте новую. Токен присоединения имеет срок истечения, и он пропадет спустя два дня. Главное, успеть присоедениться )
Если же, вы присоединяете ноды спустя два дня, вам всегда потребуется создавать токен присоединения.
Чем пугает 8.8.8.8? его нужно заменить на IP вашего мастера.
6) Еще было бы интересно организовать доступ к подам снаружи без проброса через ssh.
Зачем так? Делайте сервис + Ingress.
Но если очень хочется, то iptables вам в помощь (PREROUTING, POSTROUTING).
Конечно пишите статью, это всегда полезно)
Лично мне пока боязно «запихивать» ceph в контейнеры. Опять же, тут нужно пояснить, какую часть ceph мы собираемся запускать в контейнерах.
kubernetes хорошо продуманна. Пароли не применяются. Доступы осуществляются с помощью ключей. Но Вы правы, безопасности нужно уделять внимание. Думаю, будет не лишним заняться более глубоким изучением сервисов, торчащих во внешний мир.
я может что то пропустил, но с каких пор k8s стал именно требовать распределенное хранилище?
Это написано в разделе про «Диски». Если приложению нужен диск (storage), то да, я повторюсь: «требует», и в статье я объяснил почему. Если приложению диск не нужен, то и требования не возникает.
Не увидел настройку докера для работы с flannel. Каким образом в вашем случае поды запущенные на разных нодах, а по дефолту докер использует подсеть 172.17.0.0/16, будут общаться между собой?
Когда k8s запускает pod (докер), он выделяет свободный IP адрес из диапазона flannel, и назначает его контейнеру. Ничего дополнительно конфигурировать не нужно.
Данная статья всё таки больше о том, как запустить кластер до рабочего состояния.
При всём желании не получится описать в одной статье всё и про всё.
Не очень понятен вопрос о базе без пароля выставленную во внешнюю сеть. О чем это?
Если вы запустите какую либо БД (или вообще любое ПО) через k8s, то она не выставляется во внешнюю сеть, а наличие в ней пароля зависит от деплоя.
Для того, чтобы понять как работает k8s со внешней средой, советую почитать про Ingress.
Это сложная и большая тема. Если БД не сильно нагружена, то можно разместить ее в Ceph. Но если БД требует большого кол-ва дисковых операций, то придется запустить ее где-то в другом месте, даже на другом сервере и ВНЕ k8s. На данный момент в k8s ведется разработка для local storage, но в данный момент это alpfa и перспективы весьма туманны.
Резюмирую: k8s не готов к работе с сервисами, требующих больших дисковых ресурсов (производительности).
Я смотрел в сторону kubespray, но он под капотом использует всё тот-же kubeadm, он за вас его запускает с нужными аргументами. Этот путь имеет право на жизнь, но мне нравится путь, когда я сам делаю то, что мне нужно, так я лучше контролирую весь процесс и систему в целом. Я пока не поднимал второго мастера, но уверен, что kubeadm для этого будет достаточно)
Я рассматривал и этот вариант, но мне нравится и спокойнее, использовать тот вариант, который я понимаю.
Мне видится мой вариант проще и надежнее. Не нужно клонировать стороннюю репу, не нужно разбираться с Go и ловить баги сторонних разработчиков.
Ничего, кроме того, что я описал в статье, создавать не нужно)
Разделы создаются, форматируются и монтируются автоматически.
CephFS и Ceph (RBD) это немного разные вещи, даже сильно разные)
CephFS требует создания раздела для данных и мета-данных (да, их нужно создавать самостоятельно). Далее, такие разделы монтируются с помощью обычного mount, например так:
mount -t cehp kub01:.....:/ /mnt/, либо через fuse.
Ceph (RBD) — создает раздел и устройство автоматически c помощью утилиты rbd, выглядит это так:
rbd create rbd/aaa --size 100M # создаем раздел
rdb map rbd/aaa # создаем устройство, вида: /dev/rbd0
mkfs.ext3 /dev/rbd0 # форматируем
mount /dev/rbd0 /mnt/disk # монтируем
Я использую именно RBD, и k8s эти команды выполняет самостоятельно)
Вы что-то делали не так) Разумеется, если вы используете домен вида: kub01, то он должен резолвится. Если он прописан в /etc/hosts как 127.0.0.1, то он будет резолвится, и такой ошибки быть не должно. И да, наверное его лучше не прописывать как 127.0.0.1.
Я на эту проблему не попадал, так как hostname серверу задавал уже после инсталляции сервера.
У вас Ubunta? Странно, что python не поставился по зависимостям, при установке самого ceph-deploy…
Я python ставил отдельно, так как была необходимость запускать ansible (для своих целей).
Спасибо за замечание. Подумаю как это решить по изящнее)
Это какой-то windows-way. Всегда бейте себя по рукам за такое)
У меня нет четкого ответа на это. Обычно, k8s сам замечает изменения и перезапускает controller. Но если этого не произошло, то можно перезапустить: kubelet и docker. Если кто знает, как это сделать красиво, отпишитесь.
Если у вас есть «старый» токен, то можно использовать его. Самое простое, это сохранить команду «присоединения», которая пишется после инсталляции k8s (kubeadm init ...).
Если по каким-то причинам, у вас нет этой команды, то смело создавайте новую. Токен присоединения имеет срок истечения, и он пропадет спустя два дня. Главное, успеть присоедениться )
Если же, вы присоединяете ноды спустя два дня, вам всегда потребуется создавать токен присоединения.
Чем пугает 8.8.8.8? его нужно заменить на IP вашего мастера.
Зачем так? Делайте сервис + Ingress.
Но если очень хочется, то iptables вам в помощь (PREROUTING, POSTROUTING).
Лично мне пока боязно «запихивать» ceph в контейнеры. Опять же, тут нужно пояснить, какую часть ceph мы собираемся запускать в контейнерах.
Это написано в разделе про «Диски». Если приложению нужен диск (storage), то да, я повторюсь: «требует», и в статье я объяснил почему. Если приложению диск не нужен, то и требования не возникает.
Когда k8s запускает pod (докер), он выделяет свободный IP адрес из диапазона flannel, и назначает его контейнеру. Ничего дополнительно конфигурировать не нужно.
При всём желании не получится описать в одной статье всё и про всё.
Не очень понятен вопрос о базе без пароля выставленную во внешнюю сеть. О чем это?
Если вы запустите какую либо БД (или вообще любое ПО) через k8s, то она не выставляется во внешнюю сеть, а наличие в ней пароля зависит от деплоя.
Для того, чтобы понять как работает k8s со внешней средой, советую почитать про Ingress.
Резюмирую: k8s не готов к работе с сервисами, требующих больших дисковых ресурсов (производительности).
Мне видится мой вариант проще и надежнее. Не нужно клонировать стороннюю репу, не нужно разбираться с Go и ловить баги сторонних разработчиков.
Разделы создаются, форматируются и монтируются автоматически.
CephFS и Ceph (RBD) это немного разные вещи, даже сильно разные)
CephFS требует создания раздела для данных и мета-данных (да, их нужно создавать самостоятельно). Далее, такие разделы монтируются с помощью обычного mount, например так:
mount -t cehp kub01:.....:/ /mnt/, либо через fuse.
Ceph (RBD) — создает раздел и устройство автоматически c помощью утилиты rbd, выглядит это так:
Я использую именно RBD, и k8s эти команды выполняет самостоятельно)
Посмотри для начала вот это видео, меня оно вдохновило:
www.youtube.com/watch?v=CgCLPYJRxbU&t=1406s
Есть какая-то задача, которую вы не можете решить? Тогда опишите конкретнее о задаче.
Если такой опыт будет, обязательно напишите об этом пост.
Очень интересно Вас читать, спасибо.