Господа, а nginx правильнее разворачивать через Deployment или же StatefulSet?

зачем ему состояние?

я пока еще не придумал)

из-за этого и спросил

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

StateFull нужен кластерным приложениям с dns descovery методами, для постоянного кластера

Например кассандре или Зукиперу

или редису

Кто пользовал Telepresence?

Кто знает кого-нибудь кто пользовал Telepresence? )

Кто знает кого-нибудь из тех ребят, которые знают парней, которые знаю тех, кто использовал Telepresence? ?parter_id=12564&no_cache=1

Скажите, как мне рассовать существующие поды по новым машинам? Было 3 старых, стало 17. Мне надо теперь их равномерно размазать. Что-то хорошее и светлое в голову не приходит, только ручная работа.

Типа расширить репликасет, отменить шедулинг на старые и грохнуть старые поды

мм скажи delete pod —all —all-namespaces и шедулер пересоздаст поды на всех 17 нодах

-)

ну это к глобальному

ну а можно не парится,в процессе эксплуатации (апдейтов и т.п.) поды сами расползутся

У меня там прод крутится, октитесь:)

Ну дело в том что тесно им там

где там?

На 3 нодах

ну а ни каких других способов то и нет...

Надо размазать по 17

говорить delete поду

и шедулер запускает его на наиболее свободной ноде

Ок, попробую так. Возможно просто делит одного пода поможет

если удалит один под, только удалённый под и запустится на одной из новых нод

старые останутся на своих местах

Ну да, но хотелось удобств :)

ну нет livemigration механизма для контейнеров в принцепе

так что мигрировать под может только через свою смерть

Логично что Кубер не должен убивать Под просто потому что

Можно кластер на одну железку поставить?

а какой же это тогда кластер?)

Куберовый

мм нет)

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

Всем Дратути. Гоняет ли тут кто кафку пол кубером?

Витя Гамов, подкаст Разбор Полетов, SA в Confluent

Логично что Кубер не должен убивать Под просто потому что

Я не про лайв миргейшен. Меня устроит через смерть пода. Ну и да, я это могу реализовать сам, думал вдруг уже есть, чего зря писать.

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

ну то есть можно на одной железке запустить etcd, kube-master и kube-node?

ну то есть можно на одной железке запустить etcd, kube-master и kube-node?

Да

супер, спс

https://techcrunch.com/2017/10/17/docker-gives-into-invevitable-and-offers-native-kubernetes-support/?ncid=rss

https://techcrunch.com/2017/10/17/docker-gives-into-invevitable-and-offers-native-kubernetes-support/?ncid=rss

как раз CRI-O зарелизился

как раз CRI-O зарелизился

а как оно лучше по сравнению с обычным подходом?

как минимум в нем нет такого впечатляющего количества глюков. Судя по историям тех, кто внедрил докер в прод – попытка обновления докера напоминает ремонт самолета в полете. Одно починил – другое отвалилось

как там оверлей2, тар починили в нем?

как минимум в нем нет такого впечатляющего количества глюков. Судя по историям тех, кто внедрил докер в прод – попытка обновления докера напоминает ремонт самолета в полете. Одно починил – другое отвалилось

а оно память процесов сейвит? я правильно понимаю что инстанцы можно в таком случае полностью клонировать?

поставил через kubespray кластер на одну железку. Это нормально что ядра что-то молотят по дефолту?

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

по-ходу это нормальное состояние

не, не нормальное. проблема с днс была

вот нормальное

а оно память процесов сейвит? я правильно понимаю что инстанцы можно в таком случае полностью клонировать?

вы с CRIU не путаете?)

Скажите, как мне рассовать существующие поды по новым машинам? Было 3 старых, стало 17. Мне надо теперь их равномерно размазать. Что-то хорошее и светлое в голову не приходит, только ручная работа.

а если перевести старые ноды в режим обслуживания? не переедут ли все инстансы с них на новые ноды? а если нет - то увеличить кол-во реплик - новые должны создаться на новых нодах. затем уменьшить кол-во реплик - по идее лишние должны удалиться со старых нод (т.к. они в режиме обслуживания). а вообще интересно)) если не трудно, отпишитесь о результате экспериментов)))

Скажите, как мне рассовать существующие поды по новым машинам? Было 3 старых, стало 17. Мне надо теперь их равномерно размазать. Что-то хорошее и светлое в голову не приходит, только ручная работа.

https://github.com/kubernetes/contrib/tree/master/rescheduler

https://github.com/kubernetes/contrib/tree/master/rescheduler

Или вот скорее: https://github.com/kubernetes-incubator/descheduler

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

Правильно

А на свежей установке:

kubectl describe storageclass default Error from server (NotFound): storageclasses.storage.k8s.io "default" not found это нормально?

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

В общем лучше сделать 3 мастера сразу. Падение мастера не такой уж и страх

Без него сервисы будут работать

В общем лучше сделать 3 мастера сразу. Падение мастера не такой уж и страх

а что нужно продублировать? апи-сервера достаточно будет? или шедулер и контроллер-менеджер тоже лучше сделать в нескольких экземплярах?

держи https://kubernetes.io/docs/admin/high-availability/

Спасибо!

делаю нагрузоное, микросервисы, синхронный REST http: TLS handshake error from 172.20.3.3:31861: EOF Error syncing deployment stage/my-microservice: Operation cannot be fulfilled on deployments.extensions "my-microservice": the object has been modified; please apply your changes to the latest version and try again Сталкивались? Перегрузка по сети?

там 100500 TIME_WAIT от микросервисного общение и все начинается сыпаться, ставлю на нодах net.ipv4.tcp_max_tw_buckets=2000000,net.ipv4.tcp_tw_reuse=1,net.ipv4.tcp_fin_timeout=10, не помогает... а kops не дает поставить experimental-allowed-unsafe-sysctls для kubelet есть идеи?

можно еще net.ipv4.ip_local_port_range увеличить. но может на keepalive переходить?

Есть php сервис, для нормальной работы которого нужен хорошо разогретый memcache который крутится в том же поде. Надо перед тем как пускать на него трафик запустить php-скрипт который заполнит кеш, а потом уже отвечать на запросы Как это лучше в кубере сделать? initContainer не подходит так как мемкеш еще не будет запущен, отдельный контейнер в поде для разогрева кеша как по мне уже слишком, да и не нужен он после разогрева...

Есть php сервис, для нормальной работы которого нужен хорошо разогретый memcache который крутится в том же поде. Надо перед тем как пускать на него трафик запустить php-скрипт который заполнит кеш, а потом уже отвечать на запросы Как это лучше в кубере сделать? initContainer не подходит так как мемкеш еще не будет запущен, отдельный контейнер в поде для разогрева кеша как по мне уже слишком, да и не нужен он после разогрева...

job контейнеры в кубе есть

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

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

хз, как вариант повесить хелсчек и как скрипт отработает отдать ок

я и думал readinessProbe повесить на приложение которое отдаст 200 как только мемкеш будет запущен вопрос как инициировать запуск срипта отдельно от приложения

супервизором ?

не dockerway-но ?

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

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

тот же супервизор получается

разве?

кроме того надо отслеживать сигналы, корректно завершать дочерние процессы...

exec просто в конце скрипта и всё

он вытеснит текущий процесс тем, что ему будет передано

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

прогревай экзеком

насколько помню, официальные образы sql бд так и работают, сначала инициализируют окружение, потом через exec запускают сам процесс

прогревай экзеком

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

в прогреве можно сделать проверку, грелось уже или нет =))

если честно, не вижу большой разницы из-за временных рамок

порядок действий должен остаться тем же

в прогреве можно сделать проверку, грелось уже или нет =))

такие мысли уже были, но както костыльно :)

та хоть файл-флажок и проверка башем

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

job же предложен был

а probe пускай опирается на прогретость кэша