Да. теперь надо курить остальные доки и api

пишу свою обертку для развертывания

может стоит посмотреть на helm/deis пока не поздно?

а это кто-то юзает ?

ну тут вроде есть любители

просто это уже готовый велосипед

хмм

надо будет тоже посмотреть

Не совсем то что нужно. Но код можно посмотреть.

Еще spread

https://github.com/redspread/spread

в общем есть из чего выбрать

философские размышления: если разделять неймспейсы на staging/production - имеет ли смысл иметь одинаковые названия configmap в них? вроде как удобно, а ну как перепутаешь и пошлешь тестовый трафик на прод :(

гггг

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

да, наверное так правильнее

конфигмапы для одинаковых компонентов одинаково называются

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

+1

документация кубернетеса рассматривает

не а че, несколько кластеров городить?

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

да

не а че, несколько кластеров городить?

да

тем более что в gke через баш довольно легко создается/прибивается

я исходил из того, что вся эта штука с самого начала должна удовлетворять phoenix server фаулера

с одним бы разобраться... слишком много сущностей, у меня переполнение информацией, пойду в угол забьюсь

ггг

Коллеги, есть проблемка. nginx deployment хостит статику с hostPath и привязан к конкретному хосту. решил обновить. запилил новую версию образа контейнера. теперь имею вечный Pending и вечный Terminating. в events logs всё ок: 2016-09-20T13:07:00Z 2016-09-20T13:07:00Z 1 nginx-2905510493-rodsr Pod Normal Scheduled {default-scheduler } Successfully assigned nginx-2905510493-rodsr to ubuntu3

не связано ли это с тем, что один и тот же hostpath не отдается двум работающим подам? и как этого избежать?

связано

сейчас уже только docker kill

это не наш метод

а как сделат ьтак, чтобы в будущем конфликта не было?

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

это ж статика

а в дальнейшем - либо не делай роллинг-апдейтов, либо тип доступа к шаре на read-write-many поменяй

вот жешь... HostPath судя по табличке поддерживает только ReadWriteOnce

http://kubernetes.io/docs/user-guide/persistent-volumes/

ну тогда сначала останавливай старый под, потом поднимай новый :(

даунтайм

ну никак по-другому же

роллинг-апдейт сначала запускает

а старый еще работает

а новый уже пытается смонтировать

а низзя

дедлок

то есть вот это именно красивый, классический дедлок

прям по мануалу

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

у меня так с blog.amplifr.com, например

там статика вся прям в образе

но она не меняется от деплоя к деплою

мы ж не знаем, как там у @kay_rus

может у него в эту папку куча демонов срут статикой онлайн

такое тоже может быть

ну зашибись. теперь еще и docker не отвечает =\

логи?

ооо

а ничего в логах.

агада

status alive

ты скорее всего поймал https://github.com/docker/docker/issues/13885

висит и всё

да нет у меня high load )

ERROR: S client not available

у меня прошлой ночью такое было

да у меня тоже нет

бородатые докерописатели просят килять демона с USR1 и присылать им трейс

Maxim Filatov @lk4d4 смотри, какая штука: # strace -p 16080 Process 16080 attached read(37, "<probe> ERRO: 2016/09/18 20:34:2"..., 32768) = 156 futex(0x2a69030, FUTEX_WAKE, 1) = 1 futex(0x2a68f70, FUTEX_WAKE, 1) = 1 futex(0xc8203fb508, FUTEX_WAKE, 1) = 1 write(38, "{\"log\":\"\\u003cprobe\\u003e ERRO: "..., 236) = 236 read(37, "<probe> ERRO: 2016/09/18 20:34:3"..., 32768) = 156 futex(0x2a69030, FUTEX_WAKE, 1) = 1 futex(0x2a68f70, FUTEX_WAKE, 1) = 1 futex(0xc8202fe108, FUTEX_WAKE, 1) = 1 write(38, "{\"log\":\"\\u003cprobe\\u003e ERRO: "..., 236) = 236 read(37, "<probe> ERRO: 2016/09/18 20:34:4"..., 32768) = 156 futex(0x2a69030, FUTEX_WAKE, 1) = 1 futex(0x2a68f70, FUTEX_WAKE, 1) = 1 futex(0xc82002ad08, FUTEX_WAKE, 1) = 1 ну и так в цикле 16080 - это /usr/bin/dockerd docker ps висит вечность в логе демона девственная чистота куда копать-то вообще? Maxim Filatov похоже на https://github.com/docker/docker/issues/13885 на всякий случай написал туда Alexander Morozov @bregor надо SIGUSR1 послать и трейс ещё собрать. Там по ходу миллиард причин может быть Ещё надо dmesg проверить Maxim Filatov блин, я несколько часов назад все расстрелял :disappointed: уже нельзя было ждать дальше а почему USR1? Alexander Morozov Ну это все равно не фикс Но оно тогда трейс горутин выдаёт Посмотрели бы что висит Короче там что-то зависает, может netlink или volume driver И просто мьютекс занят из-за этого А ps пытается у каждого контейнера залочить мьютекс

оказалось враки

такбличка неправильна. http://kubernetes.io/docs/user-guide/persistent-volumes/

можно запилить: apiVersion: v1 kind: PersistentVolume metadata: name: media-prod-ng labels: type: local app: icp icp: media namespace: prod-ng spec: capacity: storage: 20Gi accessModes: - ReadWriteMany hostPath: path: /localdata/media

у тебя неймспейс в метки съехал

или это метка такая?

метка такая

ибо нельзя pv к namespace привязывать

кстати да

pvc можно, а pv - нельзя

так вот. accessModes нельзя прописать к volume в описании самого пода. потому что принимается всего одно значение "Path": https://github.com/kubernetes/kubernetes/blob/6a9a93d46954f69c8736a51cf6a8f073a962ad25/pkg/api/v1/types.go#L537 а если это значение не прописано, то host_path автоматом ставит ReadWriteOnce: https://github.com/kubernetes/kubernetes/blob/6a9a93d46954f69c8736a51cf6a8f073a962ad25/pkg/volume/host_path/host_path.go#L94

не хотелось костыли с claim+volume сторить

строить*

но пришлось

так и как в итоге сделал?

через описание ReadWriteMany в pv + claim. а под уже этот claim использует

ну так вроде бы это the only way, не?

как ты хотел без этого сделать?

вот так: - deployment: - pod description: volumes: - name: media-persistent-storage hostPath: path: /localdata/prod-ng/media accessModes: - ReadWriteMany

ааа

но в данном слачае api принимает на вход только hostpath с path. и всё

мол если локальный стор то и нефиг claim ?

ну да

без правки сорцов никак

https://docs.google.com/document/d/1Q2juTrM_oA5SatVCbLoal0k68dGaiH5ON_VVI5-ns9g/edit

коллеги, это обязательно нужно прочитать

спасибо!

https://github.com/kubernetes/dashboard/releases/tag/v1.4.0

Кто какие message queue использует? Что бы кластеризовались нормально в kubernetes и была поддержка авторизации, для того что бы можно было снаружи доступ открыть. Сейчас у нас используется gearman и он ни то ни другое не умеет