В контексте кубера?

https://youtu.be/7CR5eH6a8Fo

искази - это вобще протокол.

Нет. Базы в кубе - чур меня

Тут была классная диаграмка...

выбери два

а че они не сошлись?)

а че они не сошлись?)

Потому что ты не очень умный

Потому что ты не очень умный

кроме того, железяка может быть достаточно большой чтобы потянуть тысячу контейнеров, но шедулер/container runtime не справится

Про стейтфулл согласен, но в кубе в вм есть смысл. Оркестратор оркестратору рознь

Я для теста запихивал Прометей в цеф. И благополучно проебал данные. Нет, сделав бы лишние движения все бы восстановил. Но... это такое.

CAP-теорема в действии

пока Cluster API не взлетел ответ простой - чтобы при гибели ноды погибала не вся железяка, а только кусок виртуалки

Так кап теорема в чистом виде давно считается устаревшей и там пару ее видов принесли расширенных

Где

Ну, у тебя может упасть нода с кучей вм)

Ну, у тебя может упасть нода с кучей вм)

Так кап теорема в чистом виде давно считается устаревшей и там пару ее видов принесли расширенных

Мне за тебя гуглить? Ну ок

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

Ну, у тебя может упасть нода с кучей вм)

PACELC

Оно, в CAP задержки не учитываются

тоже аж глаз режет...

Консистентность везде нагадила 😃

CAP-теорема в действии

Базы как StatefulSet заводить надо, если заводить их как deployment то есть шанс при перезапуске потерять данные. Так как сначала будет создаваться новый под, затем будет удаляться старый. Вторая проблема что при смерте ноды - под сам не переедет, а пометится как Unknown и будет висеть. Чтобы под переехал нужно чтобы был cloud-provider или fencing который в случае чего гарантированно снесет ноду и удалит ее из кластера.

Вроде deployment с recreate тоже можно?

# cat access.yaml | grep -A 1 strategy strategy: type: Recreate # cat access.yaml | grep repl replicas: 1 # kubectl get pod | grep access access-69d88c4f6d-sqgp9 1/1 Terminating 0 17m access-69d88c4f6d-tf882 1/1 Running 0 114s

# cat access.yaml | grep -A 1 strategy strategy: type: Recreate # cat access.yaml | grep repl replicas: 1 # kubectl get pod | grep access access-69d88c4f6d-sqgp9 1/1 Terminating 0 17m access-69d88c4f6d-tf882 1/1 Running 0 114s

Так, я уже запутался. При смерти ноды, поды деплоймента будут перезапущены на другой ноде или надо руками прибить те, которые unknown?

Да, про это я знаю, но там кейс не требующий прям высокого ha и простой в пару тройку минут допустим.

например использует ли твой deployment attachable volume

Да, cephfs

cephfs вроде не требует attach

получается надо каждую тразнакцию реплизировать.

Это не имеет отношения к Кубу, а вопрос к базе. В PG есть синхронная репликация скажем.

Возможно, я ещё разбираюсь в этом :) Хорошо, например самый простой кейс, deployment вообще без использование volume

Репликация базой всегда лучше чем репликация ФС. Точно так же как репликация ФС лучше репликации блоков. Чем выше уровнем, тем лучше и производительнее

> репликация ФС лучше репликации блоков Я бы не согласился, но о какой фс идет речь?

> репликация ФС лучше репликации блоков Я бы не согласился, но о какой фс идет речь?

Да о любой. Чем больше магия знает о том, что на самом деле происходит, тем надёжней и производительнее она

Да о любой. Чем больше магия знает о том, что на самом деле происходит, тем надёжней и производительнее она

просто раньше цеффс был гавно

Кворумные локи по определению не могут быть быстрее локальных. Цеффс не сможет обогнать постгрес репликацию, даже с консервативным synchronous_commit = remote_apply, а ведь есть ещё remote_write который не ждёт записи на диск на репликах.