Скорее всего в таком кластере ipvs будет предпочтительнее iptables

https://kubernetes.io/docs/admin/cluster-large/

о супер

О. 40 000 нельзя, но можно попытаться собрать из восьми кластеров по 5000 federation. ;)

Kubernetes The hard way

https://github.com/kinvolk/kubernetes-the-hard-way-vagrant — вот тут еще можно посмотреть как на вагранте hard way (на случай, если нет возможности с gce связываться)

блин какие вы хорошие тут , спасибо

как вычислить воинствующего линухоеда?

он сам тебе об этом скажет, потому что макось говно :)

он сам тебе об этом скажет, потому что макось говно :)

сказал человек сидящий на маке

именно поэтому я не теоретизирую

именно поэтому я не теоретизирую

не, была бы говно - слез бы ?

так - просто ворчишь )

жду когда 18.04 выпустят

макось — лучшее из говен!

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

сорри за оффтоп

C этим лучше в @it_holywars.

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

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

решать вам.

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

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

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

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

да

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

Andrey, зря годный совет по СУБД удалил. ?

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

Andrey, зря годный совет по СУБД удалил. ?

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

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

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

> можно разделять в теории в документации 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