так вроде бы сперва в контейнеры, потом их в к8с, не?

приложение на c++/python, общение по сети по своему закрытому протоколу, "оркестрация" своя из коробки есть. И ко всему прочему, разработка сидит в австралии, которая делает дискавери/оркестрацию. Надо взять себя в руки и начать делать, бизнес-задачи нет, всем вроде всё ок. Надо выдумать проблемы и их решать :) или не трогать

oбщение по сети по своему закрытому протоколу

tcp/udp или нет?

бродкасты для дискавери, есть и tcp и udp :)

но основная суть PV/PVC в том, что они, по хорошему, могут легко переноситься на другие ноды

на мой взгляд pv/pvc не совсем про ноды, а возможность юзать в подах хранилище(PV), которое "где-то там"

в теории с petset-ами наверное можно и локальный сторадж юзать

насколько помню, привязки пета к ноде нет

как это нет

каждый pod в петсете - это инстанс который куб только создает

он их не переносит

он их не удаляет

вообще ничего с ними не делает

соответственно - он всегда на одной ноде

следующие поды - естественно могут быть на других нодах

но каждый конкретный под сам по себе никуда не денется с ноды на которую его уже положили

если она не умерла

> на мой взгляд pv/pvc не совсем про ноды, а возможность юзать в подах хранилище(PV), которое "где-то там" важно не то, что оно “где-то там”, а то, что имея PV ты можешь с этими же данными запустить инстанс на другой ноде

даже если умерла

с петсетом куб ничего не сделает

это тебе не replicaset-ы

Now delete all pods in the petset ... Wait for them to come back up

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

у меня тогда вопрос - что значит “потерялся” :)

нода упала

руками кто-то удалил

нода упала != “можно поднимать новый под с тем же стораджем”

какая разница, вопрос не про то, что именно случится, вопрос про гарантии

нет, именно о том что будет

ох

если ты удалишь под

именно удалишь

он будет знать что его нет

если нода упала - и у тебя нет знаний что там происходит (может она живая, но от нее никаких новостей не приходит) - у тебя будет ситуация когда у тебя PV подключен в два места и два приложения могут на него одновременно писать

тебе не стоит использовать петсеты с локальными volume (как и вообще использовать локальные volume), потому что куб не может дать тебе гарантий попадания пода на тот же volume в случае проблем, а я не настолько богат фантазией, чтобы предсказать, как именно это прострелит колено

даже если с нелокальным

отсутствие инфы о чем-то не значит что чего-то нет, что оно упало или что оно никогда больше ничего никуда писать не будет

не ну можно же каждый под к конкретной ноде привязать через .spec.nodeSelector :D

отсутствие инфы в случае с бд может значить только “отсутствие инфы”

в этом случае нельзя ничего делать автоматом, можно только ждать пока инфа появится

кстати, коллеги

пока вы тут про стораджи

а кто какой стораж-драйвер использует?

в докере

я тут обнаружил, что у меня на паре нод, которые пережили уже много обновлений докера, до сих пор Devicemapper(loop)

и чот меня это как-то напрягает

надо бы обновиться

ну всмысле на что-то более актуальное смигрировать

есть где-то адекватное сравнение стабильности и перформанса overlay/aufs/dm?

и overlay2 уже появился тем временем

я видел только вот эту чудо-картинку: https://docs.docker.com/engine/userguide/storagedriver/images/driver-pros-cons.png

отсюда: https://docs.docker.com/engine/userguide/storagedriver/selectadriver/

тоже сейчас эту ссылку открыл

вот думаю - direct lvm или оверлей2

у нас aufs :)

у меня на 16-х убунтах тоже ауфс

и я особо смысла в devicemapper не вижу

он там из коробки был

поэтому я бы брал оверлей

но есть несколько 14-х

там на момент первичной установки было ядро 3.13

а щас?

4.4.3

в слаке ест народ который живет на devicemapper-ах, в том числе loop-lvm и не парится

ты про который слак?

лично я уже был готов смигрировать на vfs и копировать имаджи полностью

вон вы в том самом слаке с морозовым меня распекаете

потому что эта вся хрень значительно менее стабильна чем ext4 :)

ERROR: S client not available

но так никто не делает почему-то :)

в том же мезосе аналог vfs тоже есть и к нему не относятся как к “самому последнему варианту”

в целом - я бы поставил оверлей

сразу второй

почему?

и посмотрел

он вроде лаб-тестинг

потому что это “аналог aufs напрямую из ядра“

эээ

devicemapper “правильно” мне просто лень всегда было настраивать

не уверен что понимаю, о чем ты

ну devicemapper работает “поблочно"

т.е. на уровне блоков, не файлов

ага

я знаю

overlay/aufs на уровне файлов

aufs - это сторонний модуль, он не находится в исходниках линукса

overlay лежит в самом линуксе

начиная с 3.18 кажись

и это типа “aufs successor”

т.е. они напрямую не связаны, но он продолжает то, что делает aufs, а сам aufs, похоже, умрет рано или поздно

ну и все пишут что overlay побыстрее чуток чем aufs

но лично мне нафиг эти “быстрее“ не надо - лишь бы стабильнее :)

вот да

видел же мои приключения прошлой ночью?

:)

та да

там еще нюанс - смигрировать на другую fs - это целое дело

ну у меня мало 14-х убунт

четыре штуки всего

по очереди их кордонить и руками курочить

я планирую смигрировать десяток машин на overlay2 и kernel 4.7 и посмотреть что и как :) это несрочно, поэтому растянется на несколько недель. сделаю - отпишусь :)