« Rev
@kubernetes_ru   185
Fwd »


Denis
http://blog.kubernetes.io/2017/04/rbac-support-in-kubernetes.html
𝕍ℤ
Доброго вечера, друзья! новичок в к8s. Установлено все под ubuntu 16.04, через snap.Подскажите, есть профит ставить ручками по официальному ману и вообще, есть какие-то best practices на этот счёт? Спасибо.
G72K
Примерно то же, что пройти Linux from scratch
Denis
Kelsey и Мирантис активно работают, чтобы жизнь была проще в этом направлении))
Denis
https://github.com/netsil/manifests
Denis
Как тема с контейнерами зашумела )
Logan
Kelsey и Мирантис активно работают, чтобы жизнь была проще в этом направлении))
при этом единственный реально заработавший у меня HA-кластер удалось поставить только с помощью Злых Марсиан. Которых отсюда выпер модератор :)
Logan
Карго с вивом увы - не работает
Roman
Что вы используйте для incremental mongodb backup? только для полных снапшотов бэкап на s3 нахожу образы
𝕍ℤ
а между вивом и фланелькой кто какой выбор сделал? если можно, то с обоснованием
Logan
а между вивом и фланелькой кто какой выбор сделал? если можно, то с обоснованием
Вив, у меня нет контроля над L2, плюс вив может шифровать данные (но при этом fast path отключается)
Logan
Что вы используйте для incremental mongodb backup? только для полных снапшотов бэкап на s3 нахожу образы
Возможности инкрементально выгрузить данные из монго не существует.
𝕍ℤ
Вив, у меня нет контроля над L2, плюс вив может шифровать данные (но при этом fast path отключается)
не ясно насчет контроля над L2.. а кроме ширования плюсов нет? просто фланель, как я понял, вариант более распространенный
𝕍ℤ
и каково ваше мнение насчет держать весь к8 на отдельной lxd?
Logan
и каково ваше мнение насчет держать весь к8 на отдельной lxd?
В смысле? Пока что я не очень понимаю вопрос
𝕍ℤ
ну что бы на одной ОС держать несколько вариантов исполнения к8, пока не определюсь с лучшим стеком
Anonymous
k8 не работает в lxc/lxd :(
Eugene
работает, но нужно патчить https://github.com/opencontainers/runc/pull/1386/files https://github.com/kubernetes/kubernetes/pull/43079
𝕍ℤ
k8 не работает в lxc/lxd :(
печаль ☹️патчи не удел продакшена, тем более пока не разобрался в теме
Logan
ну что бы на одной ОС держать несколько вариантов исполнения к8, пока не определюсь с лучшим стеком
Пока что oci (по-моему он так называется, поправьте меня) - в альфе и работает только докер. Хочется верить, что к 1.7-1.8 доедет до стабильного
Logan
он не OCI, а CRI, вспомнил термин
Anonymous
CRI (для docker) в бете начиная с 1.6
Anonymous
Планируем что в 1.7 расширится поддержка до rkt как минимум, stable будет в 1.7 или 1.8
Anonymous
К слову, планирование фич на 1.7 будет уже в ближайший вторник
𝕍ℤ
поправьте, но cri - это плугин для контейнеров внутри к8. я же изначально спрашивал, нормально ли будет на изначальной оси рубануть кусок lxd и на нём поднять весь к8, а потом рубануть ещё кусок и поднять к8 с отличающейся архитектурой. и что бы потом их переключать, например.
𝕍ℤ
да, контейнер внутри контейнера наше всё)
𝕍ℤ
например один к8 на фланели, второй на виве
Logan
сомнительно что оверлейная сеть будет работать. Но попробовать никто не запрещает, конечно
Logan
коллеги, сталкивался ли кто-нибудь с сообщениями в сислоге вида: 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 Известен ли способ лечения?
Anonymous
сомнительно что оверлейная сеть будет работать. Но попробовать никто не запрещает, конечно
Именно поэтому в lxc/lxd не работает docker swarm и другие... Там где использовать пытаются overlay network
G72K
"NetworkPlugin cni failed to teardown pod"
Anonymous
всем привет создал новый инстанс монгодб чтобы данные мигрировать... сделал дамп большой таблицы получил OOM в ноде, она удачно вывалилась и похерила кучу подов, продакшн упал через 10 минут все просралось и восстановилось, но роутинг не шел пока вручную игресс контроллер не перезапустил какого то хрена вопрос: порекомендуйте набор практик чтобы такой жопы не было плиз?
G72K
Pod limits
G72K
Чтобы падала не нода, а под
Anonymous
ну у меня как бы разброс сильный... та же монга жрет под задачи неограниченно то есть ей 2 гига хватает обычно, но может бурстом до 16 выжрать если я поставлю лимит 16 и реквест 16 то эти 16 будут вечно заняты и шедулер будет отбивать другие поды типа "нафиг пошел, памяти нет" а по факту 2 гига только юзаться и будет
Anonymous
а реквест 2 и лимит 16 = все равно OOM в результате
Anonymous
есть возможность на текущем уровне кубернетеса задать алгоритмы oom eviction?
Anonymous
важность там, туда-сюда
Anonymous
или типа "это не проблема кубернетеса, а проблема линукса под капотом"? :)
G72K
важность там, туда-сюда
косвенно важность задается: guaranteed (requests == limits) > burstable (requests < limits) > best effort (limits == 0)
G72K
kubelet может вышибать поды когда ресурс подбирается к отметке, описано тут https://kubernetes.io/docs/concepts/cluster-administration/out-of-resource/
G72K
но ему тоже необходимо время на среагировать
Anonymous
Да, я че то такое читал но не мог вспомнить ссылку, спасибо
G72K
> если я поставлю лимит 16 и реквест 16 то эти 16 будут вечно заняты и шедулер будет отбивать другие поды типа "нафиг пошел, памяти нет" разумный оверкомит нужен, совсем без лимитов жить тоже не дело
Logan
а реквест 2 и лимит 16 = все равно OOM в результате
Есть лимит для конкретно пода и для неймспейса целиком. Ограничивайте неймспейс
G72K
там есть еще хаки навроде прибивания oom_score в -9000 для critical pods. Если повесить annotation: {scheduler.alpha.kubernetes.io/critical-pod: 1} , то ваш под тоже важным и невышибаемым станет. но это скользкая дорожка.
Anonymous
Я вот из доки понял что эвиктится по тому кто как ресурсы запрашивает и потребляет. Но не увидел или пропустил как можно повлиять вручную (шедулер альфа не подходит) на формулу.
Anonymous
То есть вот этот сервис и вот эта база должны стоять до конца
G72K
никак, приоритеты и SLA для подов будут в 1.7 или 1.8 или когда-нибудь еще, но сейчас нет :)
Anonymous
Ок
Anonymous
Неприятно слышать "никак" для вещей которые уже в продакшне )
G72K
повесьте на отдельную ноду эту базу и всё
G72K
если ресурсов нехватает - кто-то должен умереть, чудес не бывает
Anonymous
Ну я в целом только себя и чмоню: не предусмотрел, не ознакомился, не хватило знаний, и тп
Logan
Неприятно слышать "никак" для вещей которые уже в продакшне )
Тут только лимит на под, увы. С монго иначе никак. В случае нормальной ос придёт OOM killer
Anonymous
самое интересное что не ограничивая ресурсы и пытаясь залить большие объемы инфы я получаю oom для всего кластера, если ограничиваю то операция не может выполниться потому что оперативки не хватает (пытался залить 6 гб инфы с ограничением на под в 6 гб оперативы, странно так-то) короче, пришло время избавляться от монги, буду в сторону cocroachdb ковырять :)
Anonymous
я кстати думал что приложения выполняются в "песочнице", и типа не смогут заюзать больше оперативки чем прописано в лимитах а по факту их просто пристреливают когда они переходят за лимит... открытие сегодняшнего дня
Anonymous
или... они работают в "песочнице" и все норм, но если глобально лимит превышен то пристреливают те которые в очереди на убийство согласно формуле? так правильнее сформулировал?
Logan
честно говоря я не в курсе, но стоит посмотреть в документации
Logan
судя по тому, что я в доке прочитал, контейнер, который попытается вылезти за квоту - просто не получит ресурсов. Терминирован он не будет.
Logan
А можно линк? А то я как-то читал про убиение
в оффдоке сказано, что лимиты по памяти и процу передаются контейнеру через аргумент в докере. Если контейнер выскочит за лимит (то есть докер проигнорирует ограничение, хотя вообще-то не должен) - контейнер будет убит
Logan
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-limits-are-run
Logan
в общем-то вполне логичное поведение. Если контейнер вышел за пределы ограничений - его поведение точно ненормально и он подлежит уничтожению. Мало ли что еще он натворит?
🦠
Если лимит на память гиг и вы куском этот гиг аллоцируете - докер прибьет, если же сначала саллоцируете 500, а затем еще гиг - ничего не произойдет
Etki
у меня ощущение, что докер вообще напрямую с памятью контейнера не контактирует и знает кто кому сколько выделил только пост-фактум, собирая метрики, и аллокация и ограничения действительно происходит только на уровне ОС
G72K
докер настраивает cgroups, всю работу делает ядро
Vitaliy
всем ку. kube-apiserver, параметер —apiserver-count что он конкретно делает? кто-то вкурсе?
G72K
жуткая вещь
G72K
определяет сколько записей будет добавлено в kubernetes.svc
« Rev
@kubernetes_ru   185
Fwd »