« Rev
@kubernetes_ru   528
Fwd »


Vadim
по поводу второго пункта не очень понятно
итого (у нас опеншифт так что YMMV): - прод кластер woot_prod с нейспейсами blue и green. роут из blue поинтит на настоящий домен. При деплое настраивается неймспейс green, роут в blue удаляется, создается роут в green. Все DC в blue скейлятся до 0 реплик
Vadim
Пользуясь случаем задам еще вопрос: у нас есть некоторая проблема с недостатном ресурсов для модуля. Модули написаны на джаве, еще не сильно оптимизированы. Местами жрут много процессора. Бывает, их скапливается на одной ноде по несколько штук. И когда происходит чуть более менее активная работа, они начинают жрать процессор, как я понял, нода переходит в статус NotReady (причем по ssh к ней тоже ноде подключится),переподнимаются на другой ноде, часто вешают и эту ноду и вот так по цепочке падает весь кластер. Я так понимаю, нужно прописывать всем подам ресурс реквесты, чтобы этого не происходило и распределять по нодам с помощью нодселекторов. Я пока вижу только такой выход из ситуации. Может есть что то более правильное?
можно выделить реквест для нужд самого кубернетеса, надо читать доку по параметрам кубелета, ...system..
Vadim
500m ей хватит, хотя бы в notready не будет валиться
Dmytro
под выборкой понимаю, например, выборку микросервисов, написанных нами (то есть, без бд и прочих зависимостей). Сейчас они лежат в дефолте. Монга в своем неймспейсе, мускул в своем. Когда я выполняю команду kubectl get pods -n ns, я виду состояние подов из одной роли, так скажем. Это все, исходя из вашего объяснения, стоит заменить просто на выборку по лейблу, то есть kubectl get pods -l role=mongo, например.
ну да, уже внутри неймспейса выбирать по app=mongo вот пример как у меня, апп называется talos app=talos и пошли потом микросервисы этого апп - app=talos, role=receiver - app=talos, role=worker - app=talos, role=prediction ему нужны два монго инстанса app=mongo первый: - app=mongo, type=archive, role=mongo -- replset-role=primary -- replset-role=secondary -- replset-role=secondary -- replset-role=primary-discovery (контейнер с пачкой баша) второй app=mongo, type=prediction остальное так же как и в первом и еще ему нужны rabbit и statsd rabbit - app=rabbit statsd - app=statsd ...
Dmytro
все это бежит в одном неймспейсе
Dmytro
имена лейблов и организация подчиненных лейблов - тут не претендую на истину, наверняка можно и лучше нельзя сделать
Dmytro
каждый апп это отдельный хелм чарт
Ilya
каждый апп это отдельный хелм чарт
ну да, с этим понятно, примеры есть
Dmytro
у меня вообще пхп приложуха это форкбомба и меморилик сплошной
Stanislav
Нет ли там кейса когда вся нода бракуется кубером?
Dmytro
там сотни адских пхп скриптов бегают
Ilya
изза этих проблем, никак не можем стабилизировать все на кубере, а отказываться от него не хочется
Dmytro
если забить лимиты чтобы всегда был guranteed QoS то максимум под умрет от OOM killer
Stanislav
ну это же прекрасно, в этом и фишка - не вписался - сдох, нефиг валить ноду
Stanislav
Переподнимут на другой ноде
Dmytro
еще кстати полезно поставить в sysctl panic on OOM и panic -> reboot
Svyatoslav
Коллеги, добрый вечер! У кого-то был опыт перехода с mesos+marathon на кубер?
Dmytro
если не выходит лимиты норм сделать - ну ребутнется нода
Ilya
Нет ли там кейса когда вся нода бракуется кубером?
кейс такой, что под выжрал ресурс, кублет завис и перестал отсылать метрики мастеру, нода переходит в NotReady, потом под пересоздается на другой ноде
Dmytro
зато ручками туда не ходить
Ilya
еще кстати полезно поставить в sysctl panic on OOM и panic -> reboot
А про это где почитать можно подробней? На aws такое прокатывает?
Dmytro
да, у меня такое на aws, на нодах coreos
Dmytro
## ## Set some sysctl values. Setting these values only works if the ## container is run in a privileged security context. ## ## Background: currently we have an issues with kubernetes nodes running OOM and also ## hanging tasks. ## ## Links: ## http://www.nico.schottelius.org/blog/reboot-linux-if-task-blocked-for-more-than-n-seconds/ ## https://osinternals.wordpress.com/2009/11/24/detecting-hung-tasks-in-linux/ ## update_sysctl_values() { # panic on OOM sysctl -w vm.panic_on_oom=1 # panic if a hung task was found sysctl -w kernel.hung_task_panic=1 # setup timeout for hung task to 60 seconds (default in CoreOS is 120) sysctl -w kernel.hung_task_timeout_secs=60 # reboot 5 seconds after panic (default in CoreOS is 10) sysctl -w kernel.panic=5 }
Dmytro
вот так это выглядит
Andor
Какие-то костыли опять, почему не вписать в /etc/sysctl.d/ и потом не дёрнуть sysctl -p
Dmytro
это в entrypoint моего priveleged контейнера который бежим демонсетом и делают всякие housekeeping вещи
Dmytro
Какие-то костыли опять, почему не вписать в /etc/sysctl.d/ и потом не дёрнуть sysctl -p
потому что coreos и их идеология - ничего на хосте не менять, конечно в итоге это не выходит но поначалу мы сильно старались запихнуть все в инфра контейнеры
Dmytro
в итоге часть настроек перекочевала в ignition clodu init
Dmytro
можно, но эта часть и так работает - зачем трогать
Dmytro
настройки докера и т.п. в этот контейнер запихнуть не вышло - перенесли в ignition
Vadim
fair enough
Ilya
это в entrypoint моего priveleged контейнера который бежим демонсетом и делают всякие housekeeping вещи
ааа, я решил почему то, что это на хостовом амазон-инстансе
Dmytro
так это одно и то же
Dmytro
можно и на хосте запустить - результат будет тот же
Dmytro
контейнер же priveledged со всеми вытекающими
Ilya
ну да, логично
Старый
почему во всех почти плейбуках по разворачиванию кубернетиса присутствует гластер?
Stanislav
с джавой-то что не так
То, что она может неограниченно превышать Xmx ?
Dmytro
и что от этого котята умирают?
Etki
неограниченно?
Dmytro
да даже если и так, это как минимум не хуже питона-пхп и прочих скриптовых языков
Dmytro
и если развить эту вот логику то ни в контейнере ни в ВМ ни даже на сервере с ограниченным рамом яву никак нельзя запускать, как и большинство скриптовых языков
Ilya
Да ява норм, просто все написано довольно быстро, в спешке. Сейчас только об оптимизациях и рефакторинге задумались)
Max
Всем привет)
Max
Уже второй день пытаюсь подключить ceph к kubernetes, который через kubespray развернул на кластере из трех голых серваков на ubuntu 16.04
Max
ceph на них же развернут
Max
storageclass, claim и volume создаются, secrets прописаны, ceph -s HEALTH_OK
Max
но под не запускается
Max
пишет что-то вроде mount timeout
Max
на всех трех серваках смотрю mount, там ничего нового не появляется(
Max
в ceph df видно что в pool kube что-то происходит, но блочное устройство по rbd не монтируется =(
Max
Кто может помочь?)
Andor
А руками можешь смонтировать?
Max
если честно, никогда с ceph и сетевыми блочными устройствами не работал
Max
но попытаюсь сейчас погуглить как это сделать)
Max
Max
вот что пишет)
Max
root@dropkube2:/etc/ceph# ps aux | grep rbd root 536161 0.0 0.0 0 0 ? S< 12:36 0:00 [rbd] root 565212 0.0 0.0 235480 21348 ? Sl 14:46 0:00 rbd map kubernetes-dynamic-pvc-8fd9ee83-1ee8-11e8-bf60-a4bf011ba48a --pool kube --id kube -m dropkube1:6789 --key=123==
Nikolay
Клиенты ceph стоят на всех нодах, секрет в NS есть с данными для авторизации?
Max
да
Max
все есть
Max
я подобным образом настраивал ceph на DigitalOcean на трех дроплетах
Max
отличие было в том, что там я юзал kubeadm
Max
а здесь kubespray
Max
там все работало
Max
https://habrahabr.ru/post/348688/
Max
вот по этой инструкции настраивал на DO
Max
то есть я заменял дефолтный controller-manager тем, в котором есть rbd бинарник
Max
а в kubespray используется hyperkube, в котором есть rbd
Max
я также пробовал заюзать внешний provisioner
Max
https://github.com/kubernetes-incubator/external-storage/tree/master/ceph/rbd
« Rev
@kubernetes_ru   528
Fwd »