Все конечно хорошо, но описание причины того, что rook-operator решил задеплоить новый кластер, ибо это выходит как, лечение симптоматики до следующего такого редеплоя
rook-operator — это сущность для кубера, которая провижинит вам ceph кластер в нем, а у цефв, то что вы назвали мастерами, является mon, да их должно быть нечетное количество для кворума
Никогда такого не было и вот опять. Вспоминаем стенания когда вышел протокол μTP. Ну а так, автор, с разморозкой! В 2019 году, увидя трафик от гугла по udp и не связать это с QUIC, о котором протрындели уже все уши последние пару лет, особенно, в англоязычном сегменте интерент. Ну я не знаю, на какие порталы вы подписаны и как отслеживаете, что происходит в инудстрии дикого (и не очень) веба.
docker engine уже давно отделен от containerd, а у containerd, в свою очередь, runc тоже рантайм, который можно заменить, на тот же runv (https://github.com/hyperhq/runv) или любой OCI совместимый.
Если под
впилен
имелось ввиду то, что, runc у докера идет в базе — то да, тут все верно
Если клиент стучится до сайта, то как понять, какой сервер ему должен передать данные? С помощью DNS конечно. То есть в зависимости от ip-адреса того, кто обратился к DNS, будет дан релевантный ответ
CDN из нулевых подъехал. BGP anycast — далекое еще будущее (Сарказм)
Периимплантит, в той или иной форме возникакет более чем у трети пациентов, есть статистика мировая. Да и сам Периимплантит — это восполение с потерей части костной ткани, которая в более чем у 15% больных вызывает отторжение импланта, но не всегда.
The frequency of peri-implantitis in the survey was 17.8 % at participant-level with 70% of them reporting high level of post-surgical satisfaction. Worryness and concern were frequent findings among the patients with peri-implantitis (64%) and 32% reported that living with the disease was «terrible».
Так что, побочек, при имплантации — вогон и маленькая тележка.
Если так боитесь, заказывайте глубокую седацию, тем же, пропофолом. Хотя, сама операция, при нынешней анельгезии — фигня. Офигеете (простите за прямоту), вы уже потом. Плюс, в статье, очень красиво, обошли тему осложнений и отторжений. При чем, при импланталогии — это, далеко, не единичные случаи.
Есть, такая, категория людей, которым, какой из дистрибутивов linux не дай, они из него сделают слаку (при всей моей любви к слаке).
Ну есть же готовый спек файл, от федоры, с минимальными телодвижениями его можно приспособить для centos. Зачем же из системы помойку делать и новичков плохому учить.
опасное заблуждение, на которое, мы так же нарвались. Все же эксплуатация больших, распределенных дб — очень сложный процесс сам по себе. С кучей подводных камней и неявных моментов. А унификация, которую все так хотят, только, привнесла дополнительный слой проблем, которые тоже пришлось решать. И профита, для бизнеса, в первую очередь, не принесло никакого.
Я привел всего лишь один из кейсов. Баз данных на проекте много разных.
Как раз, как работает шедулер кубера мы разбирали и очень основательно.
Так что, профит от унифицированой среды, во многих кейсах, стремиться к нулю.
Какой вы, кстати, выставляете «таймаут для грейсшатдауна» когда у вас сервер вырубается?
Я не просто так выше писал про штатную ситуацию, если надо вывести члена кластера.
Отработка фейловера — это отдельная тема.
Я вам пример кассандры не просто так привел. Но, судя по ответу, у вас с ней опыта или мало, или вообще нет.
То что решается при «классическом» методе инталции кассандры через пару команд nodetool и дождаться окончания, перед началом других действий, в том же k8s тянет за собой написание обвязки дополнительной, в которой могут и будут баги и т.п.
Ну и про размер, ребаланс на 1 гигабайте данных и пол петабайта — это разное время, которое, вы, заранее знать не можете, потому сразу вопрос, какой таймаут для грейс шутдаун пода вы будите выставлять? Так что, в случаи той же касандры, просто вывести члена кассанда кластера чуть более сложнее чем, kubectl delete pod.
И тут еще не затрагивался вопрос гео-распределенного кластера.
А Вы, когда-то, пытались менеджментить кластер той же касандры в кубере, на так пару сот терабайт данных, смотрели трудозатраты на то, что бы кубер правильно сшутдаунил под с касандрой, с дрейном его, с тем, что бы дождаться когда ринг сребалансится и тп.
Да мускул на гигабайт дб под вордпрес будет прекрасно себе жить в k8s.
Никто не мешает. Вполне возможно, они именно так уже и делают. Но раз уж решили завести централизованное управление всем своим проектом, в самой своей основе предполагающее механизмы распределения нагрузки, фейловеров и пр, то логично что было бы удобнее через одну точно и управлять всем хозяйством разом? Чтобы можно было строить сценарии с зависимостями от нагрузок подсистем друг на друга, в рамках одной системы вести мониторинг, обмениваться данными и пр пр.
Когда у вас в руках молоток, все вокруг видится гвоздями.
Чувствуете подвох? Мы используем k8s или Swarm для того, чтобы распределить нагрузку и избежать падения основного веб-сервера, но мы не делаем этого для БД.
Мой посыл был как раз к этой строчке. Кто им мешает кластеризовать ДБ нативными методами для конкретно взятых ДБ, при чем тут вообще докер с кубером. Как будто, до появления контейнеров ни приложения, ни базы данных никак не кластеризовались и не маштабировались.
Потому, я повторюсь, на мой скромный взгляд, проблема баз данных в k8s лежат в другой плоскости.
А с каких это пор, BD нельзя «кластеризовать» без использования docker/k8s? Даже, банальная, мастер — слейв репликация, с каким-то видом фейловера, дает уже минимальный HA для базы данных, с минимальным временем простоя.
Как по мне, проблемы баз данных в docker/k8s — лежат в другой плоскости.
Если под имелось ввиду то, что, runc у докера идет в базе — то да, тут все верно
CDN из нулевых подъехал. BGP anycast — далекое еще будущее (Сарказм)
Ну и, свежая, инфомрация по рискам вознекновения периимплантита
www.mdpi.com/2077-0383/8/2/252/pdf
Так что, побочек, при имплантации — вогон и маленькая тележка.
Есть, такая, категория людей, которым, какой из дистрибутивов linux не дай, они из него сделают слаку (при всей моей любви к слаке).
Ну есть же готовый спек файл, от федоры, с минимальными телодвижениями его можно приспособить для centos. Зачем же из системы помойку делать и новичков плохому учить.
Как раз, как работает шедулер кубера мы разбирали и очень основательно.
Так что, профит от унифицированой среды, во многих кейсах, стремиться к нулю.
Я не просто так выше писал про штатную ситуацию, если надо вывести члена кластера.
Отработка фейловера — это отдельная тема.
То что решается при «классическом» методе инталции кассандры через пару команд nodetool и дождаться окончания, перед началом других действий, в том же k8s тянет за собой написание обвязки дополнительной, в которой могут и будут баги и т.п.
Ну и про размер, ребаланс на 1 гигабайте данных и пол петабайта — это разное время, которое, вы, заранее знать не можете, потому сразу вопрос, какой таймаут для грейс шутдаун пода вы будите выставлять? Так что, в случаи той же касандры, просто вывести члена кассанда кластера чуть более сложнее чем, kubectl delete pod.
И тут еще не затрагивался вопрос гео-распределенного кластера.
Да мускул на гигабайт дб под вордпрес будет прекрасно себе жить в k8s.
Когда у вас в руках молоток, все вокруг видится гвоздями.
Как раз нет, точнее — очень вскольз затронуто.
Мой посыл был как раз к этой строчке. Кто им мешает кластеризовать ДБ нативными методами для конкретно взятых ДБ, при чем тут вообще докер с кубером. Как будто, до появления контейнеров ни приложения, ни базы данных никак не кластеризовались и не маштабировались.
Потому, я повторюсь, на мой скромный взгляд, проблема баз данных в k8s лежат в другой плоскости.
Как по мне, проблемы баз данных в docker/k8s — лежат в другой плоскости.