Puma
а ну еще такой момент есть в облаках у тебя очень сильно шаред ресурсы и диск , а если брать прайвет ресурсы то там ценник просто из облачного превращается в заоблачный
Rainbow
@zuzzas я использую metacontroller, пока боли нет. Если будут хорошие доводы - просто перестану рекомендовать.
Andrey
@zuzzas я использую metacontroller, пока боли нет. Если будут хорошие доводы - просто перестану рекомендовать.
Да, у меня на подкорке есть воспоминание про ответ тебе, время целиком высасывает подготовка к докладу. Не думал, что так напряжно это.
Alegro
всем привет. может кто сталкивался или просто в курсе происходящего. ситуация следующая: есть к8с кластер в амазоне, и внем развернуты микросервисы через деплойменты и даемонсеты. во время обновления даемонсета через kubectl set image непонятно куда тратится время между остановкой старого пода, и запуском нового пода из нового докер образа, а именно: 2019-04-21T20:19:48.374Z info: service:rest[Px5Kb4cxgPDrKuc]: Exiting... 2019-04-21T20:19:52.375Z info: service:rest[Px5Kb4cxgPDrKuc]: Stopping service ... 2019-04-21T20:19:52.376Z info: service:rest[Px5Kb4cxgPDrKuc]: Http server stopped. 2019-04-21T20:19:52.376Z info: service:rest[Px5Kb4cxgPDrKuc]: Successfully exited. 2019-04-21T20:20:08.101Z info: service:rest[BzmBnKgMQSwNnzI]: Exiting... 2019-04-21T20:20:12.102Z info: service:rest[BzmBnKgMQSwNnzI]: Stopping service ... 2019-04-21T20:20:12.102Z info: service:rest[BzmBnKgMQSwNnzI]: Http server stopped. 2019-04-21T20:20:12.102Z info: service:rest[BzmBnKgMQSwNnzI]: Successfully exited. 2019-04-21T20:20:06.858Z info: service:rest[tutrGIbhxcFcHVv]: Starting... 2019-04-21T20:20:06.952Z info: service:rest[tutrGIbhxcFcHVv]: Listening on port 5000... 2019-04-21T20:20:06.953Z info: service:rest[tutrGIbhxcFcHVv]: Started. 2019-04-21T20:20:25.248Z info: service:rest[ORTBs9vuPMSYjjk]: Starting... 2019-04-21T20:20:25.359Z info: service:rest[ORTBs9vuPMSYjjk]: Listening on port 5000... 2019-04-21T20:20:25.360Z info: service:rest[ORTBs9vuPMSYjjk]: Started. здесь у меня два пода управляемые даемонсетом, и промежуток времени межту остановкой одного, и запуском второго - примерно 12 секунд, чего быть не должно, то есть разница по времени между появлением в логе строчки successfully exited и starting для одного, должна быть не более 5 секунд... хотя даже 5 секунд это много. вопрос, может кто сталкивался с таким или знает, на что в данном случае третиться время и можно ли чтонибудь подтюнить, чтобы это время уменьшить?
ребята. никто не сталкивался с таким или может значет в чем тут может быть проблема?
Rainbow
всем привет. может кто сталкивался или просто в курсе происходящего. ситуация следующая: есть к8с кластер в амазоне, и внем развернуты микросервисы через деплойменты и даемонсеты. во время обновления даемонсета через kubectl set image непонятно куда тратится время между остановкой старого пода, и запуском нового пода из нового докер образа, а именно: 2019-04-21T20:19:48.374Z info: service:rest[Px5Kb4cxgPDrKuc]: Exiting... 2019-04-21T20:19:52.375Z info: service:rest[Px5Kb4cxgPDrKuc]: Stopping service ... 2019-04-21T20:19:52.376Z info: service:rest[Px5Kb4cxgPDrKuc]: Http server stopped. 2019-04-21T20:19:52.376Z info: service:rest[Px5Kb4cxgPDrKuc]: Successfully exited. 2019-04-21T20:20:08.101Z info: service:rest[BzmBnKgMQSwNnzI]: Exiting... 2019-04-21T20:20:12.102Z info: service:rest[BzmBnKgMQSwNnzI]: Stopping service ... 2019-04-21T20:20:12.102Z info: service:rest[BzmBnKgMQSwNnzI]: Http server stopped. 2019-04-21T20:20:12.102Z info: service:rest[BzmBnKgMQSwNnzI]: Successfully exited. 2019-04-21T20:20:06.858Z info: service:rest[tutrGIbhxcFcHVv]: Starting... 2019-04-21T20:20:06.952Z info: service:rest[tutrGIbhxcFcHVv]: Listening on port 5000... 2019-04-21T20:20:06.953Z info: service:rest[tutrGIbhxcFcHVv]: Started. 2019-04-21T20:20:25.248Z info: service:rest[ORTBs9vuPMSYjjk]: Starting... 2019-04-21T20:20:25.359Z info: service:rest[ORTBs9vuPMSYjjk]: Listening on port 5000... 2019-04-21T20:20:25.360Z info: service:rest[ORTBs9vuPMSYjjk]: Started. здесь у меня два пода управляемые даемонсетом, и промежуток времени межту остановкой одного, и запуском второго - примерно 12 секунд, чего быть не должно, то есть разница по времени между появлением в логе строчки successfully exited и starting для одного, должна быть не более 5 секунд... хотя даже 5 секунд это много. вопрос, может кто сталкивался с таким или знает, на что в данном случае третиться время и можно ли чтонибудь подтюнить, чтобы это время уменьшить?
недавно писали, что в кубе ограничение на 5 одновременных pull из registry. Может это.
Rainbow
там у image тег не latest?
Alegro
там у image тег не latest?
нет, тег задается явно (гит коммит)
Валентин
спорно)
Кому дешевле свое - тот и делает свое. Выбор всего в итоге к деньгам сводится
Vadim
многим компаниям нельзя клауд - данные клиентов, своих железок море, заградительные контракты от партнеров типа оракла и т.д.
Gleb
привет! А есть кто с хорошим оверкоммитом в кубернетесе? Это работает?
Gleb
в смысле, что у тебя реквестов на 50 нод, по факту 25
Andrey
привет! А есть кто с хорошим оверкоммитом в кубернетесе? Это работает?
CPU не рекомендую. Нужно всё очень сильно обкладывать мониторингом. Memory overcommit работает нормально, нужно разобраться с тем, как kubelet evict'ит поды. И всё равно мониторинг везде нужен.
Tadeusz
парень волнуется
Sergey
Rainbow
CPU не рекомендую. Нужно всё очень сильно обкладывать мониторингом. Memory overcommit работает нормально, нужно разобраться с тем, как kubelet evict'ит поды. И всё равно мониторинг везде нужен.
А у вас есть checklist на сервисы, которые вы выкатываете? Вроде - health check - /metrics - alerts - sentry - проехаться я.танком и тп Я себе недавно составил, хз почему раньше не допер. Привожу всё в порядок. Даж на статику делаю что-то вроде echo my_static_build_time{branch=$CI_BRANCH} $build_time >> metrics чтобы мониторить время сборки и подобные параметры
Andrey
А у вас есть checklist на сервисы, которые вы выкатываете? Вроде - health check - /metrics - alerts - sentry - проехаться я.танком и тп Я себе недавно составил, хз почему раньше не допер. Привожу всё в порядок. Даж на статику делаю что-то вроде echo my_static_build_time{branch=$CI_BRANCH} $build_time >> metrics чтобы мониторить время сборки и подобные параметры
Основное - health checks. Без них нельзя. Остальные вещи оч. сильно разнятся от клиента к клиенту. Мы не можем форснуть его делать 100% так, как это видится. Советы даём, да, всё стандартно — метрики, чеки, нагрузка, необычные ресурсы в его приложении, которые нужно поставить под мониторинг и алертинг.
Andrey
А в паблике нет описание того как у вас в идеале? Может что подсмотреть и тп можно.
Нет, такие доки пока не делимся. Они слишком стрёмно выглядят, чтобы шарить их наружу. Я увидел вопрос, записал в книжечку.
Aleksey
Всем привет! Вопрос по деплою в кубер. Если я обновил контейнер через docker push в docker-реджистри с тем-же тегом что уже существует, по какой причине при деплое командой kubectl set image ничего не происходит?
Rainbow
pullPolicy поменять, он не перекачивает теги, кроме latest. Но так делать нельзя. Нужно менять теги
Andrey
но вообще лучше менять теги
Aleksey
pullPolicy поменять, он не перекачивает теги, кроме latest. Но так делать нельзя. Нужно менять теги
т.е. на каждую сборку контейнера нужно иметь отдельный тэг вида dev-$BUILDNUM
Alex
кстати, немного безумий – а кто-нибудь пробовал добавлять рестарт пода каждый день в варианте "для бедных" через добавление health check на endpoint контейнера в поде, который (endpoint) отдаёт ошибку спустя 24 часа с момента запуска? 🙂
Alex
так а зачем ходить через китай если можно сделать cronjob
а как это правильнее всего сделать? Вот есть у меня deployment, поды в котором я хочу убивать. Мне надо запускать кронджобу с kubectl и убивать?
Andrey
(переключить на черно-белый режим (С))
Alegro
а как это правильнее всего сделать? Вот есть у меня deployment, поды в котором я хочу убивать. Мне надо запускать кронджобу с kubectl и убивать?
да, но тогда надо иметь образ где все креды есть, то есть папка .kube и юзерские конфиги, ключи сертифкаты
Alex
да, но тогда надо иметь образ где все креды есть, то есть папка .kube и юзерские конфиги, ключи сертифкаты
вот, поэтому вариант с /healthz, который падает через 24 часа выглядит менее геморройно на первый взгляд)
Alegro
ну не знаю, по мне вариант с кронджобой менее геморойно)
Rainbow
нормально выглядит. У меня из последнего сервис отсылки sms падает, если баланс на счету шлюза 0. И мониторинг орет бесплатно.
Alex
command: ["timeout", "1d"] не проще будет?
блин, вообще не знал, что есть timeout в coreutils O_o Выглядит идеально, спасибо!
Vadim
да, но тогда надо иметь образ где все креды есть, то есть папка .kube и юзерские конфиги, ключи сертифкаты
пусть кронджоба запускается от того же serviceaccount что и деплой - так ты получишь его токен
Vadim
но самое правильное решение это activeDeadlineSeconds
Alex
Привет! А есть кто-то, кто сходил на форум в субботу и ему там понравилось? Потому что интересных докладов, как по мне, было от силы - штуки 1,5. Остальные - бессмысленное разжёвывание документации. Остался на мастер-класс по ремонту - модератор засрал подготовку, в результате чего из одного часа занятий примерно 20 минут он запускал народу стенды. Да, и ещё этот ВИП-мега-круглый стол на тему "надо или не надо нам этот ваш девопс" - вообще убил! Весь цивилизованный мир уже вовсю рулит, а эти всё не могут решить - нужно им или нет.
Alex
В общем - лучше бы я в субботу поспал, потому что этот форум - полный провал.
NM
я тоже... лучше с Марко Луша пообщаться чем слушать пересказ доки
Семён
NoOPS
Sergey
NoOPS
Ему в обед 100 лет
Sergey
Плюс минус ровесник девопсу
Sergey
Любимая таблетка от Гугла в рекламе своего облака была
Sergey
Как ща не знаю, давно не слежу
Lucky SB
а можно переписку устроить ? кто используется kube_proxy в ipvs режиме ? и какая у вас версия куба ?
Vadim
потом я выяснил что вообще-то так и надо было, но уже поздно было
Rainbow
а можно переписку устроить ? кто используется kube_proxy в ipvs режиме ? и какая у вас версия куба ?
Можно я порадуюсь за себя? ещё чутка и kube_proxy меня не будет беспокоить 😁 Круто же
Alex
потом я выяснил что вообще-то так и надо было, но уже поздно было
На самом деле, топики ты хорошие выбрал! И обмен опытом в конце - это тоже было очень здорово! Но дать ошибочный URL в качестве точки входа.... Я ведь серьёзно полез настройки DNS у себя проверять, nslookup'ить и т.д. )))
Rainbow
само отвалилось ?
открыл для себя прелести consul и service discovery. можно жить без cni и это просто во всем.
Rainbow
DNS RR ???
haproxy/nginx ставится, если не устраивает rr. Да и половина апп сама умееет выбирать из вариантов.
Rainbow
service у куба разве не rr?
Alex
Вообще, я ждал что на форуме будет рассмотрено больше практических кейсов. В этом плане интересный был рассказ про Vitess и Карен Товмасян тоже хорошую сессию провёл. Жаль только что в РФ всё зарегулировано, а люди панически боятся лезть в публичные облака
Lucky SB
haproxy/nginx ставится, если не устраивает rr. Да и половина апп сама умееет выбирать из вариантов.
т.е. руками костылим самую классную фичу куба ? спасибо - с мезосом уже накушамшись.
Rainbow
пока такого в кластере нет, не нужно, устраивает rr (опять же, в кубе же service это rr, отличия нет). Пока я все сильнее смотрю косо на cni. Раньше не задумывался, использовал потому что вариантов не было. Можно ответ для тормоза - зачем ip на под?
Lucky SB
service у куба разве не rr?
конечно нет. сервис в кубе - это iptables NAT или ipvs
Rainbow
конечно нет. сервис в кубе - это iptables NAT или ipvs
куб раскидывает трафик по кругу, не так?
Alex
конечно нет. сервис в кубе - это iptables NAT или ipvs
Имеется в виду - как раскидывается трафик в конфигурации с несколькими репликами
Rainbow
ip на под - это удобно. как ты себе представляешь выставление приложения из пода на случайные порты хоста ?
это подход nomad, меня целиком радует выставление приложения на рандомный порт хоста и обращение на этот хост по ип хоста.
Rainbow
порт меняет docker, через iptables, это его проблемы как или просто приложение получает порт из ENV, лучший вариант.
Alex
это подход nomad, меня целиком радует выставление приложения на рандомный порт хоста и обращение на этот хост по ип хоста.
Так это в случае с NodePort, но не всегда ведь нужно специально держать на ноде открытый порт!
Rainbow
Так это в случае с NodePort, но не всегда ведь нужно специально держать на ноде открытый порт!
это не nodeport, потому что у каждого контейнера свой рандомный порт на рандомном хосте.
Rainbow
в кубе такого нет подхода
Lucky SB
порт меняет docker, через iptables, это его проблемы как или просто приложение получает порт из ENV, лучший вариант.
докер, iptables, nat - это трындец при хайлоаде. порт из ENV - это вообще за гранью добра и зла. в мезосе у меня так и есть - столько геморроя с этим, что ппц. при деплое задать разные номера портов для контейнеров нельзя. поэтому максимум одна копия приложения на ноду. плюс всегда страшный гемор со сторонними аппликухами.
Rainbow
Я использую docker с iptables только для левых апп, которые совсем ничего не умеют, пару штук таких. Свои идут через network host + порт в env