вот такой стоит

вот такой стоит

По имени резолвит?

в миникуб -да, в большом кубере - нет

то что он настроен криво есть вероятность, но что смотреть

то что он настроен криво есть вероятность, но что смотреть

Надо чтобы kube-dns были живы и доступны

да живы)

Спасибо, не стал заморачиваться с etcd и вроде как заработало

Спасибо, не стал заморачиваться с etcd и вроде как заработало

приятно видеть, что не бросили

то что он настроен криво есть вероятность, но что смотреть

У nginx не самым очевидным образом работает dns, почитайте про параметр resolver и nginx plus

Пока я отдебажил и увидел что к кублета нет данных о днс сервере

Похоже при его создании не прописали

А миникуб nginx работает по dns отлично

там пароль истекает каждые 12 часов. Какие минимальные роли нужно прописать в IAM для пула-пуша-генерации нового пароля?

Если куб тоже бежит на EC2 в том же аккаунте и датацентре то надо дать права на чтение из ecr registry той instance role с которой запущены ec2 инстансы

А как получается, что кластерные сервисы работают внутри себя? Знаю что можно их запускать как bare-метал, также можно в docker. А какими средствами запускается сие? Можно немного на пальцах рассказать? :)

А как получается, что кластерные сервисы работают внутри себя? Знаю что можно их запускать как bare-метал, также можно в docker. А какими средствами запускается сие? Можно немного на пальцах рассказать? :)

static pods видны в kubectl. static pod это обычный под, но его засылают не в apiserver ,а кладут yaml в /etc/kubernetes/manifests, kubelet постоянно смотрит за этой директорией и если там появляются/меняются файлы, то делает соответствующие измнения в докере: стартует новые контейнеры, убивают ненужные. если kubelet удалось соедениться с apiserver, то он отправляет информацию о static pods туда, так что она видна в kubectl get pods

т.е. это не совсем "кластерные сервисы работают внутри себя", а фейк. можно и по-настоящему, смотрите bootkube , оно как раз для этого: поднимается временный control plane, через него создаются deployment/daemonset с настоящим control plane кластера: apiserver, schduler, controller-manager , затем временный убивается. в таком режиме обновления кластера (кроме kubelet) это просто kubectl apply

https://github.com/databricks/click кто-то щюпал?

Кто что использует в качестве стораджа для bare metal?

Цеф?

это единственный вменяемый вариант, увы

а невменяемые есть?

DRBD + <any_fs> ?

да сколько угодно: - gluster - rook - DBRBD - host-only (map)

это блочный. А если файлы?

можно сделать на голом NFS - но вы намучаетесь с конфигурированием

да сколько угодно: - gluster - rook - DBRBD - host-only (map)

О, а что такое "DBRBD"?

это блочный. А если файлы?

вы пытаетесь использовать файлы как блочное хранилище? прекращайте

О, а что такое "DBRBD"?

опечатка. DRBD конечно :)

Я уж думал, что-то новое напилили...

Я уж думал, что-то новое напилили...

можно подумать, одного rook-а нам мало

вы пытаетесь использовать файлы как блочное хранилище? прекращайте

нет. Ну то есть да, но не в этом контексте :)

kube-у нужно именно блочное устройство. Это концепция

кубу? Может нижележащему докеру?

kube-у тоже, посмотрите как описан storage class

вот такая ещё поделка есть: https://virtuozzo.com/solutions/storage-for-kubernetes.html

я там раньше работал, но это они сделали уже после моего увольнения, поэтому вещь должна быть нормальная

Самокритично, однако.

шутка юмора

Было смешно, пока ты не начал объяснять. ?

:)

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

буду рад ошибаться

драйвер вроде как открытый. Сама база, на которой работает - у них используется как storage cluster в их продукте, причём уже достаточно давно.

триалку для ознакомления можно взять побаловаться.

С самим кластером я работал, вполне себе. Вот к кубу не прикручивал, не довелось.

ах да. Большой минус в том, что это решение предполагает специализированную ОС для всех узлов k8s. Ну то есть, это я так думаю, судя по документации.

да сколько угодно: - gluster - rook - DBRBD - host-only (map)

А почему host-only невменяемый?

Что-то меня не прельщает идея в цеф базы свои тащить

Что-то меня не прельщает идея в цеф базы свои тащить

А для чего?

Почему базы рядом не поднять?

Имеется ввиду вообще отдельно и не в кубере

Чтобы зоопарк разводить?

Да, проще зоопарк в абстракцию затолкать, чтобы не казалось это таким зоопарком )

Абстракция это и есть инструмент для однообразной работы с разнородными сущностями. Так что если вам абстракция нужна не для этого, но она вам вообще не нужна

Ладно, это тупой спор.

Цеф пока самое надежное из всего

если у вас до 1пб данных, то не надо там ничего докручивать.

Вопрос был в чём проблема с hostPath

если у вас до 1пб данных, то не надо там ничего докручивать.

И десятка между серверами...

И десятка между серверами...

Для начала, ага

это единственный вменяемый вариант, увы

iSCSI тоже работает

kube-у нужно именно блочное устройство. Это концепция

это же неправда, git volume тому подтверждение

Что-то меня не прельщает идея в цеф базы свои тащить

не держите базы в kube. Kube управляет микросервисами. Микросервисы не хранят состояния.

Вы предлагаете держать паралелльную маршрутизацию, паралелльный DNS-сервис, параллельную систему развёртывания. То есть накостылять рядом наколеночный кубернетес. ok

Ну и, конечно, большая часть микросервисов это круды, так что вряд ли они не хранят состояния :)

Вы предлагаете держать паралелльную маршрутизацию, паралелльный DNS-сервис, параллельную систему развёртывания. То есть накостылять рядом наколеночный кубернетес. ok

Нет. я предлагаю вынести хранение данных в отдельный сервис и давать к нему отдельный доступ. Вы не пробовали делать резервные копии из кубера? О, вас ждет много открытий...

Комрады, может кто помочь с советом по etcd?

Везеде в документации по etcd есть раздел по дефрагментации, но при запуске etcdctl такой опции как defrag или compare нет, может что-то не то делаю, версия 3.3.1

ошибся не compare, а compact

Нет. я предлагаю вынести хранение данных в отдельный сервис и давать к нему отдельный доступ. Вы не пробовали делать резервные копии из кубера? О, вас ждет много открытий...

расскажите

расскажите

гроб-гроб-кладбище-пидор. Это если коротко. Если длинно – нет какого-то единого способа сделать бэкап-систему и есть миллион способов ее сломать. Я не поленись и напишу статью об этом, но не ранее, чем через пару недель

я собрал на этом занятии миллион граблей, хоть ачивку получай

гроб-гроб-кладбище-пидор. Это если коротко. Если длинно – нет какого-то единого способа сделать бэкап-систему и есть миллион способов ее сломать. Я не поленись и напишу статью об этом, но не ранее, чем через пару недель

А на какой площадке планируешь?

А на какой площадке планируешь?

статью? у меня собственный мини-блог. Если кто–то желает скопировать – нет проблем, указывайте автора и ставьте только ссылку, пожалуйста

Не скопирить, почитать.

после написания – выложу тут ссылку :)

гроб-гроб-кладбище-пидор. Это если коротко. Если длинно – нет какого-то единого способа сделать бэкап-систему и есть миллион способов ее сломать. Я не поленись и напишу статью об этом, но не ранее, чем через пару недель

как-будто вне kubernetes это не так. буду ждать статью

Нет. я предлагаю вынести хранение данных в отдельный сервис и давать к нему отдельный доступ. Вы не пробовали делать резервные копии из кубера? О, вас ждет много открытий...

pvc + rbac вашу задачу не решают? Вам люди pvc придумали чтобы вы данные отдельно от кластера хранили. Написали rbac чтобы вы доступ рулили. Человечество к IaC пришло, чтобы вы сервера руками не сетапили, на худой конец... С чем же вы таким столкнулись, что не нашли решения??

pvc + rbac вашу задачу не решают? Вам люди pvc придумали чтобы вы данные отдельно от кластера хранили. Написали rbac чтобы вы доступ рулили. Человечество к IaC пришло, чтобы вы сервера руками не сетапили, на худой конец... С чем же вы таким столкнулись, что не нашли решения??

делать бэкапы системы хранения средствами системы хранения == не делать их вовсе

сбой системы хранения похоронит все ваши данные. С бэкапами

сбой системы хранения похоронит все ваши данные. С бэкапами

Почему вы называете кубернетс системой хранения и почему падение кубера похоронит данные на том же EBS?

я не называю кубер системой хранения. просто когда говорят про PVC – подразумевают, что данные мы храним "где-то" и бэкапим в этом же "где-то". Это ошибка. PVC строго говоря – это костыль, который противоречит идее микросервисов. Микросервисы не должны хранить состояний :)

у вас, кстати, EBS никогда данные не терял? У меня терял

это уже не k8s, а чат психологической поддержки какойто

я не называю кубер системой хранения. просто когда говорят про PVC – подразумевают, что данные мы храним "где-то" и бэкапим в этом же "где-то". Это ошибка. PVC строго говоря – это костыль, который противоречит идее микросервисов. Микросервисы не должны хранить состояний :)

Микросервисы так-то используют данные и генерируют данные. Стало быть их и хранить где-то надо. Костыль - это когда hostPath для хранения выбирают. А запросить с помощью pvc хранилище, которому провайдер гарантирует 99% доступности и столько же сохранности, по-моему куда мудрее. Тут остоется только фактор криворукости, который лечится rbac и iam. От вашей собственной (я конечно не о вас конкретно) криворукости это не избавляет, но решение этого вопроса не ложится на компоненты кубера и облака

у вас, кстати, EBS никогда данные не терял? У меня терял

Терял. Из за моих собственных не осторожных действий