но потом он заработал

и теперь я его не трогаю

ггг

у меня регулярно ломается кубе-днс

пока не разобрался в причинах

просто перестает резолвить и все

приходится поды килять

а какая версия? он у меня тоже падал почти каждый день пока я не обновил манифест до kubedns-amd64:1.6

skydns работал через раз

дада

просто перестает резолвить и все

а ошибки? там иногда секреты он не может найти

та еще стори

https://gist.github.com/Bregor/7079efc9b12e70e583e4847ed5ec7e91

вот этот давненько уже не падал

дня три...

> там иногда секреты он не может найти секреты - это какой-то отдельный ад

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

поэтому прибил гвоздем везде kubeconfig с ключем/сертификатом

вон видишь там маунты

> там иногда секреты он не может найти секреты - это какой-то отдельный ад

у меня когда такое было, я удалял все в /var/lib/kubelet (совет в одном из issues на gh), все контейнеры и сам default секреты. после перезапуска все работало. и только после этого я подключал другие манифесты. теперь боюсь обновлять и трогать эту “scalable and resilient” инраструктуру, потому что она убер хрупкая и часто нужно смотреть код на go, чтобы понять где ошибка и фиксить это руками. не этого я хотел в 2016

Если честно, я тут недавно выбирал, что взять, и куб показался самым адекватным из всего (mesos-производные, swarm, nomad), но теперь я *немного напуган* тем, что вижу здесь в обсуждениях. Среди всего зоопарка куб и вправду самое надежное решение, или мне так только показалось?

> mesos-производные, swarm, nomad ранчера забыл ;)

Если честно, я тут недавно выбирал, что взять, и куб показался самым адекватным из всего (mesos-производные, swarm, nomad), но теперь я *немного напуган* тем, что вижу здесь в обсуждениях. Среди всего зоопарка куб и вправду самое надежное решение, или мне так только показалось?

скорее показалось, я тоже думал в самом начале легче менеджить зоопарк сервисов через k8s, но это маркетинг, а реальность это issues в k8s: https://github.com/kubernetes/kubernetes/issues

Я его в принципе не брал. На нашем проекте точно не потянем (и стремимся избежать сосбтвенного кластера, сейчас на GKE живем), так-то я вообще бэкенд, просто заниматься этим больше некому.

Я его в принципе не брал. На нашем проекте точно не потянем (и стремимся избежать сосбтвенного кластера, сейчас на GKE живем), так-то я вообще бэкенд, просто заниматься этим больше некому.

я тоже scala backend и думал переход на k8s сделает devops легче, но нет, мы не ищем легких путей

скорее показалось, я тоже думал в самом начале легче менеджить зоопарк сервисов через k8s, но это маркетинг, а реальность это issues в k8s: https://github.com/kubernetes/kubernetes/issues

И правда легче! Но... Никто не говорил, что кубик работает без проблем ;)

как раз вчера на HN: circleci.com/blog/its-the-future

Перефразирую вопрос: есть ли смысл прямо сейчас перелезать на другое инфраструктурное решение?

если сейчас все работает, то лучше ничего не ломать

и не вестись на хайп от гугла

как бы еще перефразировать )

перелезать с кубернетеса на что-то, или с bare metal на что-то кроме кубернетеса?

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

Тут хайп вообще не при чем, просто по функционалу и общему интерфейсу это выглядело лучше аналогов. Нормально продуманное API, пусть не до конца доделанные, но продуманные конкретные кейсы, PVC, вот это вот все. У аналогов я наблюдал "возможность распределить джобы по нодам" без особой конкретики. Если выкинуть саму проблематику и баги, то куб выглядит технически продвинутым относительно всех остальных, как-то гораздо ближе к реальным задачам, и, в перспективе, гораздо более удобным для этих задач (например, через N времени можно ожидать разумную поддержку stateful сервисов в виде PetSet). Сейчас меня смущает количество багов, и я хотел узнать, есть ли какие-либо аналоги у куба именно в этой части, не знаю, приближенности к реальным задачам.

с кубернетеса на аналог

а, не, аналогов я тоже не нашел

и сам подсел на k8s deployment, теперь bamboo дергает kubectl с patch и все само обновляется без ansible как раньше

а как же ранчер?

а, не, аналогов я тоже не нашел

ага, я это хотел знать, спасибо

http://rancher.com/

у них вообще все мышкой делается, даже манифестов не надо писать

http://rancher.com/

0 days since the last heroku platform analog

а как же ранчер?

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

у них вообще все мышкой делается, даже манифестов не надо писать

для меня config-only api - это плюс

да, для меня тоже

но вот программисты страдают

фронтенды особенно

)

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

а тут кто-нибудь завел ingress из k8s-addons?

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

или у всех nginx-plus или сборка + upstream модуль для динамического резолва?

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

пока вообще ничего, я в отпуск ушел посередине внедрения. планируется nginx + dns-резолв

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

если вдруг сервис поменяет ip адрес, то nginx этого не увидит без nginx -s reload

в этом и проблема

почему?

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

если это не nginxplus

я подумываю рядом завести cron-контейнер, который будет такими вещами заниматься

там все равно с aerospike та же фигня выходит

я подумываю рядом завести cron-контейнер, который будет такими вещами заниматься

там есть ingress, но это final boss, до него я еще не дошел

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

есть часть сервисов, которые уже там, и большое нераспиленное приложение, которое еще на хосте

ну и там постгресы всякие с редисами

гибридная инфраструктура ©

:D

ну и там постгресы всякие с редисами

эти очень легко перенести в k8s через petset

поэтому основной nginx пока на хосте

petset не очень хорошо обновляется, и там есть единственный issue от меня о том, что он и не скалируется )

пока втупую через фиксированное количество деплоев делаю, но это все не дело, конечно

Друзья, у меня вот какая задачка появилась. Есть сервис, запущенный на каждой ноде через 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 что угодно сделать можно

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

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