вот, пожалуйста

одна реплика ожидается, одна реплика бежит

$ kubectl get po --namespace=kube-system kube-dns-v19-9g6lr NAME READY STATUS RESTARTS AGE kube-dns-v19-9g6lr 3/3 Running 7 5d

но в поде при этом по-прежнему три контейнера

не вижу противоречия

как и связи

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

@DenisIzmaylov пора начинать читать маны советую начать с этого, чтобы хотя бы в терминах не путаться: http://kubernetes.io/docs/user-guide/pods/ http://kubernetes.io/docs/user-guide/replication-controller/ http://kubernetes.io/docs/user-guide/deployments/

А чем касандра лучше риака-то?

Это просто разные по предназначению хранилища, не пользовался riak, но организовывать постраничные выборки там должно быть не очень хорошо. Он хорош как нишевый сервис для хранения k/v данных, едва ли не единственный, чьи разработчики знают про CRDT. Мы, например, наоборот хотим последовательные счетчики перенести с кассандры на riak, потому что в кассандре они сосут, а в riak PN-counter.

Это просто разные по предназначению хранилища, не пользовался riak, но организовывать постраничные выборки там должно быть не очень хорошо. Он хорош как нишевый сервис для хранения k/v данных, едва ли не единственный, чьи разработчики знают про CRDT. Мы, например, наоборот хотим последовательные счетчики перенести с кассандры на riak, потому что в кассандре они сосут, а в riak PN-counter.

Два чая ^

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

Дело в том, что сейчас почти такой же конфиг)

А хотя у тебя v19

https://gist.github.com/DenisIzmaylov/9cea43550d5a9aeec8c4eced37f5288b

Сейчас сравниваю как раз

ну сертификаты и kubeconfig ты так и не смонтировал

clusterIP: xx.xx.xx.100 ... - --server=127.0.0.1#10053

Оно вроде без дополнительного конфига работало до того, как упало. Сертификаты при старте kube-apiserver и kubelet подключаются.

ну все теперь

вычислим тебя по айпи

)

забыл замазать локалхост

Скажи ещё пожалуйста почему у тебя v19 стоит?

а не v18 или ещё какой-нибудь?

Это на что влияет?

Здесь вообще v11 https://coreos.com/kubernetes/docs/latest/deploy-addons.html

ну это была текущая версия на момент апгрейда до 1.3

вычислим тебя по айпи

а у меня порт нестандартный

треугольный?)

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

ты же кубернетес настраиваешь сейчас, а не кореос

)) Я к тому, что не понял, кем и как используется label версии

Если он коррелирует с версией kube-dns, это ещё значит, что мануал COS может утратить актуальность)

Процесс апгрейда будет какой-то особенный (удалять что-нибудь ручками и тд)? Или я просто меняю v18 на v19 и делаю kubectl apply?

> @etkee Это просто разные по предназначению хранилища, но вроде и там и там динамо

я взял rc.yaml из сорцов кубернетеса, поменял command у кубеднс (чтобы kubeconfig читался для сертификатов) и добавил маунты (чтобы сертификатам было откуда читаться)

и зааплаил

> @etkee Это просто разные по предназначению хранилища, но вроде и там и там динамо

нет, riak k/v [dynamo], cassandra row-column [bigtable]

ну cassandra тоже dynamo таки

но column based, да

Define Dynamo^W^W Я не думаю, что это здесь стоит обсуждать.

+1

@DenisIzmaylov https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dns

вот отсюда я адаптировал rc

взял https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/addons/dns/skydns-rc.yaml.in

заменил солтстековые шаблоны на свои значения и поехал

Define Dynamo^W^W Я не думаю, что это здесь стоит обсуждать.

Можно тред в @dba_ru перетащить

я взял rc.yaml из сорцов кубернетеса, поменял command у кубеднс (чтобы kubeconfig читался для сертификатов) и добавил маунты (чтобы сертификатам было откуда читаться)

Круто

там кстати обновили кубеднс

вот коммит: https://github.com/kubernetes/kubernetes/commit/1e7120f02cc39798eb3d2ac0a4e7e8c0e80792ca

и там image: gcr.io/google_containers/kubedns-amd64:1.7

Я сначала с 1.6 попробую завести)

Можно тред в @dba_ru перетащить

там только реляционные

какая именно проблема решается заменой постгре?

я просто рассуждаю на тему "как сделать 100% аптайм проекта с минимальными временными и умственными затратами"

грубо говоря, вот есть CRM/HelpDesk/Website/ERP/... что-нибудь ещё

и нужен 100% uptime и 100% надёжность

допустим, я пишу проект на Python/Django

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

и у меня есть облако из 3 серверов в двух датацентрах с резервированием всего и вся

и вопрос тут о том - что лучше - как-нибудь запустить эту PostgreSQL на каждом из серверов или как-нибудь быстро переключать или сменить СУБД или ...

и где хранить данные - на сетевой файловой системе или локально

Это все тоже на самом деле в тот же dba_ru. Но ты решаешь не очень привязанные к реальности проблемы.

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

я подумал, что в моих интересах иметь возможность сделать 100% uptime

Это все тоже на самом деле в тот же dba_ru. Но ты решаешь не очень привязанные к реальности проблемы.

и не теми методами я уже пытался ему эту мысть тут на днях донести но чот не работает

так вопрос как раз о методах

какие методы правильные?

у меня всё упирается в базу

ERROR: S client not available

с остальным вопросов нет

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

https://www.postgresql.org/docs/current/static/high-availability.html

я читал, да

тогда откуда вопросы-то?

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

ну, решений несколько, интересен пользовательский опыт

ну это не в тот чат

тут про кубернетес

Давай в @dba_ru. Только не с "как мне сделать", а "как мне обеспечить следующий SLA: <расписываешь SLA>.

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

»»> @dba_ru ««<

да я знаю про него, были планы и там спросить

я подумал, что в моих интересах иметь возможность сделать 100% uptime

100% аптайм это миф

ну, 99,9999%

31.6s даунтайма в год. Сириосли?

на самом деле, 100% аптайм и не нужен (некоторые заказчики могут решить, что раз всё работает отлично - зачем платить за обслуживание), просто я хочу иметь возможность контроллировать его

я понимаю, что 100% нереально, может и 99,9999% тоже... но никто с секундомером замерять не будет ?

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

короче, чтобы было понятно - приложение работает на 1 сервере, после перехода в облако - все его компоненты будут дублироваться и работать на 3 серверах, а трафик будет разделяться на 3 части... и если 1 сервер не работает - запрос автоматически уйдёт на другой (так как балансировщик проверяет), вот как бы и всё... то есть после перехода в облако аптайм увеличится, насколько - не знаю, но увеличится...

# kubectl get nodes NAME STATUS AGE xx.xx.xx.17 Ready 80d xx.xx.xx.18 NotReady 80d xx.xx.xx.19 Ready 80d

Пятница?

логи кьюблета на ноде смотри

ну и kubectl get ev --namespace=kube-system

kubectl describe выдаёт, что три раза в минуту кублет пытается подняться: 9s 9s 1 {kubelet xx.xx.xx.18} Normal Starting Starting kubelet.

серьезно, тебе не лень айпишники скринить? ;)

зачем?

привычка)

дескрайб тебе тут вообще никак не поможет

только евенты и лог кьюблета на ноде

то есть там могло место кончится, например

и он перешел в UnsufficientDiskSpace