Как тема с контейнерами зашумела )

Kelsey и Мирантис активно работают, чтобы жизнь была проще в этом направлении))

при этом единственный реально заработавший у меня HA-кластер удалось поставить только с помощью Злых Марсиан. Которых отсюда выпер модератор :)

Карго с вивом увы - не работает

Что вы используйте для incremental mongodb backup? только для полных снапшотов бэкап на s3 нахожу образы

при этом единственный реально заработавший у меня HA-кластер удалось поставить только с помощью Злых Марсиан. Которых отсюда выпер модератор :)

Максим молодец, но сам вышел и мне до сих пор история та непонятна)

Карго с вивом увы - не работает

@ivan4th

Профит поставить разок по Kubernetes the Hard way

спс, попробую

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

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

Вив, у меня нет контроля над L2, плюс вив может шифровать данные (но при этом fast path отключается)

Что вы используйте для incremental mongodb backup? только для полных снапшотов бэкап на s3 нахожу образы

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

Вив, у меня нет контроля над L2, плюс вив может шифровать данные (но при этом fast path отключается)

не ясно насчет контроля над L2.. а кроме ширования плюсов нет? просто фланель, как я понял, вариант более распространенный

и каково ваше мнение насчет держать весь к8 на отдельной lxd?

и каково ваше мнение насчет держать весь к8 на отдельной lxd?

В смысле? Пока что я не очень понимаю вопрос

ну что бы на одной ОС держать несколько вариантов исполнения к8, пока не определюсь с лучшим стеком

k8 не работает в lxc/lxd :(

работает, но нужно патчить https://github.com/opencontainers/runc/pull/1386/files https://github.com/kubernetes/kubernetes/pull/43079

k8 не работает в lxc/lxd :(

печаль ☹️патчи не удел продакшена, тем более пока не разобрался в теме

ну что бы на одной ОС держать несколько вариантов исполнения к8, пока не определюсь с лучшим стеком

Пока что oci (по-моему он так называется, поправьте меня) - в альфе и работает только докер. Хочется верить, что к 1.7-1.8 доедет до стабильного

он не OCI, а CRI, вспомнил термин

CRI (для docker) в бете начиная с 1.6

Планируем что в 1.7 расширится поддержка до rkt как минимум, stable будет в 1.7 или 1.8

К слову, планирование фич на 1.7 будет уже в ближайший вторник

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

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

вы хотите поднять kube внутри контейнера целиком? Этакий docker внутри docker?

да, контейнер внутри контейнера наше всё)

например один к8 на фланели, второй на виве

сомнительно что оверлейная сеть будет работать. Но попробовать никто не запрещает, конечно

коллеги, сталкивался ли кто-нибудь с сообщениями в сислоге вида: kubelet[4245]: E0408 22:29:56.209468 4245 remote_runtime.go:109] StopPodSandbox "f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668" from runtime service failed: rpc error: code = 2 desc = NetworkPlugin cni failed to teardown pod "tiller-deploy-1491688397-8vkfm_kube-system" network: CNI failed to retrieve network namespace path: Error: No such container: f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668 Apr 8 22:29:56 app3 kubelet[4245]: E0408 22:29:56.209479 4245 kuberuntime_gc.go:138] Failed to stop sandbox "f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668" before removing: rpc error: code = 2 desc = NetworkPlugin cni failed to teardown pod "tiller-deploy-1491688397-8vkfm_kube-system" network: CNI failed to retrieve network namespace path: Error: No such container: f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668 Известен ли способ лечения?

сомнительно что оверлейная сеть будет работать. Но попробовать никто не запрещает, конечно

Именно поэтому в lxc/lxd не работает docker swarm и другие... Там где использовать пытаются overlay network

коллеги, сталкивался ли кто-нибудь с сообщениями в сислоге вида: kubelet[4245]: E0408 22:29:56.209468 4245 remote_runtime.go:109] StopPodSandbox "f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668" from runtime service failed: rpc error: code = 2 desc = NetworkPlugin cni failed to teardown pod "tiller-deploy-1491688397-8vkfm_kube-system" network: CNI failed to retrieve network namespace path: Error: No such container: f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668 Apr 8 22:29:56 app3 kubelet[4245]: E0408 22:29:56.209479 4245 kuberuntime_gc.go:138] Failed to stop sandbox "f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668" before removing: rpc error: code = 2 desc = NetworkPlugin cni failed to teardown pod "tiller-deploy-1491688397-8vkfm_kube-system" network: CNI failed to retrieve network namespace path: Error: No such container: f61b626d23f0b36b1542c0ddec0b157c504923b912a66e3743b263849905c668 Известен ли способ лечения?

CNI плагины обновите, их недавно все пачкой пофиксили, возможно поможет: https://github.com/kubernetes/kubernetes/issues/43488

CNI плагины обновите, их недавно все пачкой пофиксили, возможно поможет: https://github.com/kubernetes/kubernetes/issues/43488

Эта ошибка не связана с сетью :)

"NetworkPlugin cni failed to teardown pod"

всем привет создал новый инстанс монгодб чтобы данные мигрировать... сделал дамп большой таблицы получил OOM в ноде, она удачно вывалилась и похерила кучу подов, продакшн упал через 10 минут все просралось и восстановилось, но роутинг не шел пока вручную игресс контроллер не перезапустил какого то хрена вопрос: порекомендуйте набор практик чтобы такой жопы не было плиз?

Pod limits

Чтобы падала не нода, а под

ну у меня как бы разброс сильный... та же монга жрет под задачи неограниченно то есть ей 2 гига хватает обычно, но может бурстом до 16 выжрать если я поставлю лимит 16 и реквест 16 то эти 16 будут вечно заняты и шедулер будет отбивать другие поды типа "нафиг пошел, памяти нет" а по факту 2 гига только юзаться и будет

а реквест 2 и лимит 16 = все равно OOM в результате

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

важность там, туда-сюда

или типа "это не проблема кубернетеса, а проблема линукса под капотом"? :)

важность там, туда-сюда

косвенно важность задается: guaranteed (requests == limits) > burstable (requests < limits) > best effort (limits == 0)

kubelet может вышибать поды когда ресурс подбирается к отметке, описано тут https://kubernetes.io/docs/concepts/cluster-administration/out-of-resource/

но ему тоже необходимо время на среагировать

Да, я че то такое читал но не мог вспомнить ссылку, спасибо

> если я поставлю лимит 16 и реквест 16 то эти 16 будут вечно заняты и шедулер будет отбивать другие поды типа "нафиг пошел, памяти нет" разумный оверкомит нужен, совсем без лимитов жить тоже не дело

а реквест 2 и лимит 16 = все равно OOM в результате

Есть лимит для конкретно пода и для неймспейса целиком. Ограничивайте неймспейс

там есть еще хаки навроде прибивания oom_score в -9000 для critical pods. Если повесить annotation: {scheduler.alpha.kubernetes.io/critical-pod: 1} , то ваш под тоже важным и невышибаемым станет. но это скользкая дорожка.

Я вот из доки понял что эвиктится по тому кто как ресурсы запрашивает и потребляет. Но не увидел или пропустил как можно повлиять вручную (шедулер альфа не подходит) на формулу.

То есть вот этот сервис и вот эта база должны стоять до конца

никак, приоритеты и SLA для подов будут в 1.7 или 1.8 или когда-нибудь еще, но сейчас нет :)

Ок

Неприятно слышать "никак" для вещей которые уже в продакшне )

повесьте на отдельную ноду эту базу и всё

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

Ну я в целом только себя и чмоню: не предусмотрел, не ознакомился, не хватило знаний, и тп

Неприятно слышать "никак" для вещей которые уже в продакшне )

Тут только лимит на под, увы. С монго иначе никак. В случае нормальной ос придёт OOM killer

самое интересное что не ограничивая ресурсы и пытаясь залить большие объемы инфы я получаю oom для всего кластера, если ограничиваю то операция не может выполниться потому что оперативки не хватает (пытался залить 6 гб инфы с ограничением на под в 6 гб оперативы, странно так-то) короче, пришло время избавляться от монги, буду в сторону cocroachdb ковырять :)

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

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

честно говоря я не в курсе, но стоит посмотреть в документации

судя по тому, что я в доке прочитал, контейнер, который попытается вылезти за квоту - просто не получит ресурсов. Терминирован он не будет.

судя по тому, что я в доке прочитал, контейнер, который попытается вылезти за квоту - просто не получит ресурсов. Терминирован он не будет.

А можно линк? А то я как-то читал про убиение

А можно линк? А то я как-то читал про убиение

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

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-limits-are-run

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

Если лимит на память гиг и вы куском этот гиг аллоцируете - докер прибьет, если же сначала саллоцируете 500, а затем еще гиг - ничего не произойдет

Если лимит на память гиг и вы куском этот гиг аллоцируете - докер прибьет, если же сначала саллоцируете 500, а затем еще гиг - ничего не произойдет

нет, алокация вернет ENOMEM. прибивает OOM killer,когда аллоцируемая память начинает использоваться

нет, алокация вернет ENOMEM. прибивает OOM killer,когда аллоцируемая память начинает использоваться

А вы пробовали?

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

докер настраивает cgroups, всю работу делает ядро

всем ку. kube-apiserver, параметер —apiserver-count что он конкретно делает? кто-то вкурсе?

жуткая вещь

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

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

если он больше, чем живых apiservers -> все живые добавляют себя и не парятся, а лишние "мертвые" записи так и висят, и периодически отдаются клиентам, клиенты в этом случае не могут свзяться с apiserver и спамят в лог

тоесть, для 3х-нодового сетапа мастеров, мне достаточно манифест подсунуть с этим параметром=3? если он просто менеджит кол-со записей но не сами контейнеры с апи.

вобщем если хотите настоящий HA то не ставьте этот параметр и терпите вечный трафик в etcd на обновление этой записи каждые N секунд. в противном случе если apiserver упадет (или будет выключен для обновления скажем), то 1/X коннектов к apiserver будут с ошибкой, где X - количетсво apiservers

ок, понял. А если я хочу ему передать параметр bind (не равный advertise) и на "advertise-нный" адрес повесить балансер (nginx к примеру) то можно будет не терпеть?

ок, понял. А если я хочу ему передать параметр bind (не равный advertise) и на "advertise-нный" адрес повесить балансер (nginx к примеру) то можно будет не терпеть?

не все поды могут (должны) покидать kube, для доступа к балансеру придется, если вам это не страшно и вы считаете, что балансер у вас HA, то должно сработать

мы для себя решили незамечать проблему и оставить как есть --apiserver-count=1 :)

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

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

но это теория :)

в etcd всё равно пишется в лидера, а лидер один и если он в другом DC, то может получится 2 хопа между DC: client (dc1) -> apiserver (dc2) -> etcd leader (dc3)

кстати я не знал этого про etcd. я дцумал что принимает "принявший" и потом уже они внутри синхронизируются. мало знаю про это. спасибо

моя косноязычна, сорри.

ТОгда были бы коолизии...

И нужно было бы изобретать механизм их разрешения

еще вопрос: на какой адрес должен адвертайзиться апи? бест праксис какой?

адрес по которому он доступен :)

ну это в обзем понятно.... но после фразы "не все поды могут (должны) покидать kube, для доступа к балансеру придется" но если я привяжу апи к "внешнему адресу" то в чем разница с просто nginx на том-же адресе/порте?

Это что промт перевод?

нет :)