кто-нибудь сталкивался?

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

смотри describe

смотрел, самое подозрительное что было, эвенты ворнинги о том что GC не смог что-то найти чтобы почистить

gc? чей

кубернейтеса

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

а kubelet gc. вообще его в логах не встречал еще

docker logs попробуй

Статус то подов какой?

Pending?

или там не доходит даже до этого

а kubelet gc. вообще его в логах не встречал еще

а это не в логах, это в эвентах в дескрайбе пода

docker logs попробуй

контейнеры даже не запускаются, логов нет

Посмотри тогда лог кублета.. возможно там что будет

Статус то подов какой?

подов и репликасетов тоже не было

Эээ... тогда смотри на apiserver

etcdctl status

что-то там не работает походу

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

etcdctl status

я думаю если бы etcd или apiserver не был доступен, kubectl мне бы deployment describe не отдал

пробую еще воспроизвести, пока работает

вот проверь)

может флапает

я такого не встречал ещн

еще после перехода на 1.6.4, все на том же стенде kubelet выжирает многовато проца и нода пеиодически виснет

возможно это связано с описанной первоначально проблемой

повторяется в ovh и gcp

переход с какой версии?

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

развернут на чистую ноду

запускаю все через hyperkube бинарник

на 1.5.4 такого не было

проверь, ямлы и ключи. могли чего убрать добавить переделать

новая инфа подъехала, на 1.5.4 тоже повторялось

на 1.4 нет

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

dmesg

нет ли там чего подозрительного

мб диски отказали

спасибо, буду дальше копаться)

посмотри strace там что-нибудь может пролететь интересного

кидай дебаг весь в пастебин и сюда)

мне кажется, у меня в конффигурации запуска сервисов может быть что-то намудрено, там ничего сильно не менялось с версии куба 1.2~ или еще ниже, при том что там руками делалось другим человеком и никто толком не актуализировал ничего никогда)

типо автоматизированный the hard way 2х летней давности

обычно пишут что депрекейтед

тут скорее lagacy

но если скакнул через несколько версий, то не факт

не так понял тебя сначала, согласен

Коллеги, приветствую! Возникла дума, и никак не придумывается, как сделать следующее: Вношу изменения в конфиг deployment/svc/ingress и k8s отстреливает старые сущности pods/svc/ing, и переподнимает последние с новым конфигом. Пока пришел вот к таким решениям: Можно сделать через изменение config-map, но он не перезапускает сервис с новым конфигом, тут хард рестарт. Можно на каждое изменение сервиса городить новые config-map, и апплаить его на сервис. (под сервисом понимается связка depl/svc/ingress) Либо сделать через consul-templates, и дергать скрипт на изменение конфига в консуле. В общем, если кто может подсказать, как красиво решить данную задачу, буду признателен.

можно изменять конфигмэп и какую-нибудь аннотацию в своем деплойменте, это спровоцирует rolling update или recreate, в зависимости от стратегии в спеке

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

ну как сложно. займёт время на планирование архитектуры и составление конфигов, плюс время на понимание того, как эта балалайка работает.

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

надо обратить внимание на сеть, на всяческие statefull сервисы и посмотреть как они работают в Best practices k8s

стэйтфул это БД всякие?

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

да бд, например

у меня щаз маунтится внутрь докер контейнера папки которые на EBS volume расположены. для баз данных.

я вот помню когда поднимал кластер потрогать на этом и встрял

есть куча best practices надо изучить) можно не все сразу перевозить, как мы например

у докера сейчас сварм есть например.

https://www.google.ru/amp/s/technologyconversations.com/2015/11/04/docker-clustering-tools-compared-kubernetes-vs-docker-swarm/amp/

мне кажется, что в длительной перспективе, kubernetes лучше

у докера сейчас сварм есть например.

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

в целом статья хорошо все описывает

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

there is no silver bullet

в перспективе развития kubernetes выглядит лучше остальных. его делает большая богатая корпорация. хотя, если посмотреть, как эта корпорация запускала Android pay в России, тут сомнения возникают бгг

а как данные действительно там хранить в кластере кубернетс?

есть еще open shift origin и прочие

ну да вокруг куба самый хайп

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

ну я познал дзен когда помимо разработки еще девопсил инфраструктуру где все крутилось а там 3 БД (mongodb, influxdb, elasticsearch) + redis + rabbitmq + еще kibana/logstash. и вроде все просто но то просидишь пару часиков с какой-нибудь фигней, то юзеру права создать, то конфиг где-то прописать тут яву ставишь какой-то версии. потом напрягся все по контейнерам разделил стало намного проще.

а как данные действительно там хранить в кластере кубернетс?

google://kubernetes persistent volume

openshift не только лишь все могут настроить. даже опенстак проще. в общем он для экстремалов

мне нравится Cloudfoundry, такой proxmox для людей

ЧТо там настраивать в Openshift?

с CF мороки куда больше

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