Конечно пишите статью, это всегда полезно)
Лично мне пока боязно «запихивать» 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 эти команды выполняет самостоятельно)
Лично мне пока боязно «запихивать» 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
Есть какая-то задача, которую вы не можете решить? Тогда опишите конкретнее о задаче.
Если такой опыт будет, обязательно напишите об этом пост.
Очень интересно Вас читать, спасибо.