Друзья, у меня вот какая задачка появилась. Есть сервис, запущенный на каждой ноде через DaemonSet. Этот сервис может по API отдать check - состояние ("in_process", "waiting") допустим... Можно как-то настроить DS так, чтобы Pod терминэйтился только когда сервис отдает "waiting"? или ждет, пока сервис не выйдет в состояние "waiting" в какой-то промежуток Timeout?

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

даже при обновлении

DS нельзя обновлять, насколько помню

delete/create

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

перед удалением он (Pod) переходит в состояние Terminating

я не думаю, что существует функционал защиты от удаления

полезу в код разбираться...

Эта ответственность лежит на том, кто менеджит кластер. Иначе есть возможность бесконечно откладывать удаление.

ну вот не зря же в Kubernetes добавили сервисные аккаунты)))

чтобы runtime управлять кластером

через API

это никак не противоречит тому, что я сказал

http://kubernetes.io/docs/user-guide/liveness/

Sat, 27 Jun 2015 13:43:03 +0200 Sat, 27 Jun 2015 13:44:34 +0200 4 {kubelet kubernetes-node-6fbi} spec.containers{liveness} unhealthy Liveness probe failed: cat: can't open '/tmp/health': No such file or directory Sat, 27 Jun 2015 13:44:44 +0200 Sat, 27 Jun 2015 13:44:44 +0200 1 {kubelet kubernetes-node-6fbi} spec.containers{liveness} killing Killing with docker id 65b52d62c635 Sat, 27 Jun 2015 13:44:44 +0200 Sat, 27 Jun 2015 13:44:44 +0200 1 {kubelet kubernetes-node-6fbi} spec.containers{liveness} created Created with docker id ed6bb004ee10 Sat, 27 Jun 2015 13:44:44 +0200 Sat, 27 Jun 2015 13:44:44 +0200 1 {kubelet kubernetes-node-6fbi} spec.containers{liveness} started Started with docker id ed6bb004ee10

Во!!! Максим, огромное спасибо! Запамятовал - смотрел когда-то...

;)

только это диаметрально обратная фича ;) она про запус... вот мне бы то же самое но про удаление

ну так она удаляет под, когда он probe не проходит

дада... мне же наоборот надо - чтобы при kubectl delete не происходило удаления пока что-то там не чекнулось. Но действительно, архитектурно это невозможно - иначе можно получить вообще невозможность удалить под

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

там же не обязательно http-check

есть и exec

а уж в exec'e что угодно сделать можно

это все работает только на запуск

на удаление не работает )))

всмысле?

ааа

ты хочешь предотвращать ручные убийства

в зависимости от "статуса" операций

?

да. буду думать как по-другому менеджерить это дело. Возможно уйти от DS

так а какая разница-то, DS или нет

что DS, что RC, что Deployment все-равно делают в итоге поды

DS сам размазывает по нодам

и если у меня хватает прав на kubectl delete pod в нужном неймспейсе, то я все-равно смогу его пристрелить

мне это отлично подходит, но вот управлять ими невозможно. Допустим половину опустить, а половину оставить

а, это да

нет, теоретически все можно.

можно добавлять нодам лейблы

kubectl delete такого пода приведет к его перезапуску на целевой машине

в рантайме

а DS как раз мониторит эти лейблы

кстати интересно, если контейнеру в DS повесить nodeSelector...

и если у ноды удаляется лейбл, то K8s удаляет с этой ноды Pos относящийся к соотвествующему DS

не попячит ли его? ;)

да, через NodeSelector

у меня часть нод как раз под этот сервис поднята исключительно... и на них я запускаю сервис через DS и NodeSelector

тогда я снова утерял суть изначального вопроса

смотри. Есть сервис который что-то считает. Этих сервисов много. Они запущены сейчас через DS на отдельных нодах Так вот мне критично нельзя удалять сервис пока он что-то считает. Встает вопрос. Как их обновлять?

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

мне кажется, тебе нужны джобы, а не демонсеты

http://kubernetes.io/docs/user-guide/jobs/

ну, по описанию

хм... а их можно размазать по-кластеру? чтобы на одной ноде был только один Под?

чем хорош DS - я просто добавляю ноду с лейблом и там автоматически запускается нужный мне сервис

Job этого не даст

зато джоба не остановится, пока не кончит

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

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

который будет сам через k8s-api запускать сервисы на нодах

но видимо для этой задачи базовых возможностей k8s не хватит (((

Alexander https://pracucci.com/graceful-shutdown-of-kubernetes-pods.html

Вечером опубликую :) Что-то кастомизировананое

Получилось? :)

Максим, кстати отличная статья. Про preStop вообще не думал. В статье написано что он блокируется (This event handler is blocking...) правильно ли я понимаю, что я могу поставить terminationGracePeriodSeconds в нужное значение (чтобы точно через минуту, например все грохнулось) и в хуке разблокироваться после окончания расчетов... Тогда как хук разблокируется, под удалится. Если же за время terminationGracePeriodSeconds не разблокируется, то все-равно удалится по таймауту

ну как я понял - да, так и есть

надо пробовать

ок! Попробую и отпишусь

запускаю 1.3.5 и получаю ошибки про CNI

cам спросил, сам отвечаю: https://github.com/kubernetes/kubernetes/issues/30681

https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/README.md

Получилось? :)

Привет :) Да, лови: https://github.com/StartupMakers/k8s-resource

https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/README.md

отличный солюшн, жаль только слишком крепко прибит гвоздями к GCE

в общем, чтобы запустить кубернетес >= 1.3.5 с weave или calico, надо сначала поставить последние стабильные CNI-бинари

wget https://github.com/containernetworking/cni/releases/download/v0.3.0/cni-v0.3.0.tgz && \ tar xvf cni-v0.3.0.tgz -C /opt/cni/bin/

после этого k8s-1.3.5 начинает работать как по волшебству

Это из-за этого k8s не хотел компилиться?

Про компиляцию ничего не знаю

))

Привет :) Да, лови: https://github.com/StartupMakers/k8s-resource

Вот ещё полезные ресурсы) https://concourse.ci/resource-types.html