Скажите, а насколько фэншуйно etcd-кластер на хост-нодах k8s использовать под другие цели? Делает так кто?

решать вам.

Мне нравится рассматривать control plane как единую систему и etcd ее часть. Так что ИМХО не по феншую

Скажите, а насколько фэншуйно etcd-кластер на хост-нодах k8s использовать под другие цели? Делает так кто?

По феншую можно через thirdpartyresources

Но я думаю вопрос в использовании etcd напрямую

да

я бы не стал просто по той причине, что если вы как-то из приложения завалите etcd, вы завалите и кубер тоже

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

не, я понял, такое ноу-хау надо патентовать

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

Ну так то доступ можно разделять в теории, но никто на практике так не делает. Ну а вообще сратт в общий горшог негигиенично и етсд надо разделять. Вообще все надо разделять, шинковать и огораживать

> можно разделять в теории в документации k8s описано, к каким ключам ему нужен доступ?

> можно разделять в теории в документации k8s описано, к каким ключам ему нужен доступ?

/registry кажется

Флаг был у apiserver

а. ну тогда нет проблем. Кроме изоляции ресурсов

Можно потом в etcd при помощи user, role, grants ограничить доступ к префиксу. Но это если времени дофига и заняться нечем

/registry кажется

ага

Доброго дня, коллеги! У меня задачка запустить в gitlab ci два связанных контейнера, понимаю что буду использовать docker-compose, но есть НО, сервис jboss у второго не должен быть стартанутым и запустить его должен первый при проведении integration testов, вот надо понять как это сварить

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

Доброго дня, коллеги! У меня задачка запустить в gitlab ci два связанных контейнера, понимаю что буду использовать docker-compose, но есть НО, сервис jboss у второго не должен быть стартанутым и запустить его должен первый при проведении integration testов, вот надо понять как это сварить

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/ я думаю тут что-то такое должно быть

The kubelet uses readiness probes to know when a Container is ready to start accepting traffic. A Pod is considered ready when all of its Containers are ready.

^ this, потом через https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks в PostStart хуке запускать второй контейнер

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

нет

раскройте вопрос пожалуйста

сорри,

промахнулся

раскройте вопрос пожалуйста

когда делаю expose деплойменту ему назначается external_ip

как мне передать в кубеспрей рейнж адресов из которых брать external_ip для деплойментов?

ну это уже проблемы не кубернетеса, имхо

так эти адреса назначить "снаружи" должны на машину

эти адреса надо повесить на какие-то интерфейсы мастера кубернетеса?

нод

на все что ли? о_О

Ну как же это будет работать

есть кто нибудь на 1.9.2 кто может poweroff сделать для одной из нод etcd? Мы тут наблюдаем интересное поведение - если сделать poweroff любой ноде с etcd которая была активна на момент старта apiserver - на всех apiserver начинают сыпаться ошибки. При этом если просто выключить через systemctl то все окей. Непонятно это особенности нашей инфры или же мы что-то не понимаем. Очень похоже на https://github.com/kubernetes/kubernetes/issues/6559, но это 2015 год

Помогает только рестарт apiserver

Кто нибудь знает как ConfigMap с специфичным UID и GID смонтировать?

Многие говорят что де базу нельзя держать в кубере Допустим, есть свой кубер на выделенных серверах Понятно, что можно поставить базу не через кубер, но это же значит что придется каким-то другим инструментом для деплоя/конфигурации пользоваться вроде солта или энсибла, разворачивать итд, по-моему это лишний оверхед, от которого лучше бы избавиться У меня возникла идея прибить контейнер к одной конкретной ноде через nodeSelector и использовать локальной вольюм для базы, монтируя его через hostPath

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

Да нормальное решение

многие пихают базы в куб

у стандартных баз есть одна осоенность, они не разу пишут на диск. Так что неожиданная смерть пода может губительно сказать на целостности данных

Только наверное лучше это сделать через persistent volume и statefulset как мне кажется

ну то есть сделать так что единствнное место для пода из стейтфулсета будет там где прибит гвоздями PV

stateful сет приимуществ не даст. так что его использование бессмысленно

и можно делать норм pvc и pv через стандартнуб систему sds

А кто даст гарантии что только один истанс запущен пода с этим PV ?

Или куб не даст использовать в двух подах?

Завист от прав

ReadWriteOnce объявляешь и только один под

stateful сет приимуществ не даст. так что его использование бессмысленно

Это еще почему? Как раз для этого их и придумали

Для баз банных то?

Стабильный network identifier и гарантия только одного пода

если нет желания собирать отказоустйочивый кластер с standby серверами и скриптами перевыбора мастера особого смысла запихивать базу в statefulset нету

кроме того если все сделать правильно, то можно будет grow'ить базу через kubectl scale --replicas=X

и все последующие реплики будут настраиваться на предыдущие

https://patroni.readthedocs.io/en/latest/

у стандартных баз есть одна осоенность, они не разу пишут на диск. Так что неожиданная смерть пода может губительно сказать на целостности данных

эээээ простите?

Ну, такое есть. Как минимум, в жесткую файловую систему не сразу попадает информация) Иногда в промежуточные логи, которые потом (после остановки и перезапуска базы) не будут читатся (не совсем классический пример, но привет Кассандра)

вы сейчас про кэш в дешевых хардах или что

потому что ни одно разумное хранилище не отдаст вам подтверждение коммита без фсинка wal

ну, пока вы явно не сконфигурировали его заниматься обратным

Если его не вырубить)

эээээ простите?

имеется ввиду вот такие штуки https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_log_buffer_size

> A large log buffer enables large transactions to run without the need to write the log to disk before the transactions commit. вы сейчас хотите сказать, что оно наоборот должно сохранять незакомиченную транзакцию?

Ну, было бы неплохо. Потому что в противном случае, длинная транзакция теряется. Хотя да, лучше не делать длинные транзакции, конечно)

> A large log buffer enables large transactions to run without the need to write the log to disk before the transactions commit. вы сейчас хотите сказать, что оно наоборот должно сохранять незакомиченную транзакцию?

это же типичный слышал-звон-не-знает-где-он. вангую господин пытался сказать о директиве https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

Но я такую фигню видел в Кассандре только )

;) про flush_at_trx_commit я в курсе

слушайте я не топикстартер фигни про то что "субд не пишет про диск"

это же типичный слышал-звон-не-знает-где-он. вангую господин пытался сказать о директиве https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

-) нет, это типично когда я пытался честно найти кроме очевидных вещей с fsync места где СУБД не гарантирует запись на диск =)

-) нет, это типично когда я пытался честно найти кроме очевидных вещей с fsync места где СУБД не гарантирует запись на диск =)

я вообще не понял что вы тут пытаетесь мне сказать.

я вообще не понял что вы тут пытаетесь мне сказать.

что ж, на этом предлагаю разойтись, довольные друг другом =)

а нахер нужна субд, которая свои wal-файлы не пишет с fsync? если вы такую хотите, то вам и монга подойдёт наверное

а нахер нужна субд, которая свои wal-файлы не пишет с fsync? если вы такую хотите, то вам и монга подойдёт наверное

;) а если WAL и вообще transaction log нет? ;) что делать?

значит это не субд

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

Ну, было бы неплохо. Потому что в противном случае, длинная транзакция теряется. Хотя да, лучше не делать длинные транзакции, конечно)

господи, что?

или с библиотечкой

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

еще раз, "строгое сохранение данных", не обязательно должно быть через WAL ;) но да, 90% народу OLTP базы реализуют через Transaction Redo Log, там это оправдано

А других способов надёжно сохранить данные особо и нету