Здесь переводится видео в статью Михаила Прокопчук из Avito "Настройка kubernetes tips and tricks"
Ссылка на видеодоклад https://www.youtube.com/watch?v=Zbe8k0cQpYo
Текст сделан из субтитров. Буду очень благодарен в форматировании текста, его вычитки. Для этого достаточно знать русский язык. Присылайте свои pull request или присылайте текст на почту patsev.anton[собака]gmail.com
я работаю в компании авито разработчикам серверной части в unity архитектура наш юнит в компании занимается развитием поддержкой и эксплуатации нашего ссылка стад облака в основе которого разумеется лежит cabernet кластер тема моего сегодняшнего доклада это настройка cabernet step and tricks доклад мы будет прежде всего интересен тем кто только начинает использовать кубер настолько начинает его эксплуатировать в докладе я расскажу о том с какими сложностями проблемами и там очевидными неочевидными настройками мы столкнулись как их решали что делали и попробую дать несколько советов и немного расскажу еще о том как работает сама инфраструктура купюрница для начала немного компании авито ну наверное все знают авито это сайт номер один объявлений в россии кроме этого вид один из крупнейших мировых классе файлов у нас более 300 серверов порядка 15000 пск бэг-энда в общем хай лот и все такое убирать славится что же из себя представляет cabernet славе там его вид и используем cabernet чуть больше года и за это время наш cabernet кластер даже кластеров разрослись трех серверов которые стояли где-то там в углу до двух полновесных кластеров это продавшим и дс-3 jing кластер все новые сервисы вави то мы разворачиваем только в кубер нет никак иначе как это все было то есть как я сказал нас было изначально всего только 3 сервера мы на них развернули кластер мини кластер посмотрели вроде все работает развернули на нем тестовый сервис убедились что вроде все работает вроде под наши задачи все подходит и все здорово потом стали думать как это все терять как это все продвигать уже в продакшен в df провели его вид ряд к воркшопов внутренних ряд митапов то есть позвали туда разработчиков научили их писать спецификации купюрница научили их писать сервисы с учетом новых реалий с учетом того что они будут работать в кубер нес написали кроме этого вряд шаблонов сервисов то есть у нас есть шаблон и сервисов на php на год на питоне то если разработчик захочет написать сервис который надо будет катиться губернатор просто берет этот шаблон в нем уже кроме шаблону непосредственно кода есть шаблоны кубер над конфигурацией как подготовленных берет заполнять и собственно выкатывает в кубе раз благодаря вот этому всему где-то полгода назад может чуть раньше разработчики общем приняли эту идею то есть мы все рассказали и показали у нас начался практически не линейный экспоненциальный рост количества сервисов то есть мы расширяли наш кластер сервисов становилось все больше и что самое критически важные на что сразу надо было бы щит внимание стали появляться сервисы которые непосредственно участвуют в обработке пользовательского запроса на пользователя который приходит к нам на сайт и для таких сервисов производительность должна быть производительность очень критично то есть для таких сервисов не необходимо обеспечить работу с заданным латинский чтобы сервис всегда постоянному хорошо надежно работал соответственно нужно было что-то делать собственно еще раз план доклада то сейчас я расскажу как работает cabernet именно как работают его инфраструктурные компоненты чтобы было какое-то понимание того куда можно куда нужно смотреть если что-то пошло не так с вашей инфраструктуры на что стоит обращать внимание потом расскажу про вот собственно те настройки которые мы делали для нашего кубер нас кластер с какими проблемами сталкивались и наконец расскажу немного про мониторинг и так как работает cabernet со стороны разработчиков стороны разработчика кубер нас работает очень просто разработчик знает что есть некое облако разработчик знает что есть утилита купца tl или есть любой seo и сиди которые у него настроен и у разработчика есть кот и кубер над спецификации там deployment и сервис ingress и коды наверное знаете что это такое наверное сами уже все писали эти и спецификации ну разработчик берет и катет это все в облако и не думает и не должен думать о том как это облако работает он должен только знать что все будет хорошо вот он нажал кнопочку deploy все выкатилась все работает все на этом здании разработчика об облаке целом должно закончиться как работает кубер нации на самом деле на этом слайде я попытался отобразить основные архитектурные инфраструктурные компоненты cabernet кластер и сейчас я немного по ним пройдусь значит кубер нас как инфраструктура представляю в первом приближении делится как бы на два компонента это control plain и worker ноды в контру plain это панель управления это набор процессов ну который можно запускать также в контейнерах могут быть запущены различным способам в общем это набор процессов которые обеспечивают основную функциональность работы кубер ниц кластеров worker но да это рабочие лошадки q бернайс кластер это те самые но эти самые haste или там виртуальные машины на которых запускаются и работают ваши сервисы центральным компонентом всей инфраструктуры cabernet является api сервер то есть клубы api сервер он называется он все остальные компоненты взаимодействуют друг с другом только через него никакой из инфраструктурных компонентов не взаимодействуют друг с другом напрямую все взаимодействуют через него api сирота полностью stateless процесс то есть при необходимости рассказывая про мониторинг я скажу там на что нужно обращать внимание его можно спокойно стрелять то есть допустим о существовании нескольких api серверов внутри cabernet кластера и он занимается чем-то есть он открывает пользователям то есть либо другим инфраструктурным процессом либо нам то есть когда мы говорим купцы цель прочему также идем в api сервер api сервер открывает обычные старый добрый rest api и туда можно собственно либо забрасывать под запросами спецификаций либо что самое важное для инфраструктуры кубер нас можно подписываться на обновление по заданному фильтру что и делают все остальные компоненты которые здесь перечислены как это устроено то есть они подключаются к api серверу говорят фильтр событий которые они хотят отслеживать и передать параметр watch цру и просто начинают ждать и потом если некое событие наступает то api сервер этому компоненту отсылает уведомление что произошло событие отсылает нас от растущей например спецификацию собственно эти сидите седеет основное хранилище в cabernet кластере причем хранилище как текущего состояния так и желаемого до состояния то есть пришла новая спецификация она сразу уходит витязь иди и dissidia там отобразил виде нескольких прямоугольников если будете разворачивать кластер готовит production нагрузки сразу же эти сиди нужно склеить для отказоустойчивости для распределения нагрузки то есть это все делается вот куба scheduler именно он занимается тем что планируют размещение наших всех сервисов наку бернес класс тире и тут очень важно знать что scheduler непосредственно не размещает наши контейнеры где-то на кластере он просто дополняет спецификацию прописывая соответствующую ноту приходящую спецификацию и дальше отдает и назад вопи сервер потом расскажу как происходит итоге размещению контроллер менеджер это такой процесс который есть на самом деле несколько контроллеров именно он ответственен за то чтобы желаемое состояние кластер соответствовало действительному то есть например мы вы который deployment там прописано что у нас три реплики именно контроллер менеджер следить за тем чтобы этих реплик было действительно 3 там не 5 ни одна именно именно он следит также за состоянием того чтобы когда мы рассказываем стоит full set всегда на каждой ноги запускалась только по одному экземпляру приложений вот dns ну собственно dns на самом деле не является чистым таким инфраструктурным компонентом авторе устанавливается как от доску бернес кластер но тем не менее dns предоставляет пользователю сервис механизм сервис discovery и собственно весь resolving внутри кубер на цикл остера вот это по основным компонентом из которых состоит control plain тут панель управления губернатор глостера еще так сразу замечу здесь на слайде не отобразил то есть говоря продавец сказал что это аддон отвесно кубер ниц предоставляет возможность расширения своей инфраструктур через так называемые аддон это здесь еще следовало бы нарисовать сетевая дом то есть то какой тип сити мы хотим использовать для нашего кубер на цикл остера чтобы сеть это сконфигурировать мы в компании avid используем сеть типа калика то есть есть сетевой проект к лику вот там все устроено на основе bgp по поводу worker нот на worker ногах работают два основных инфраструктурных процесса это кубе прокси и кубе лет кубе прокси это процесс который подключается мы собственно подписывается на обновление api сервера и просто смотрит какие изменения приходят на эту моду ну в которой он запущен и просто должным образом конфигурирует правила и пить областных отец конфигурирует сеть для того чтобы мы могли добраться до наших сервисов открывает порты и все прочее и собственно основной процесс это процесс кубе лет именно он работает непосредственно уже с движком да с движком контейнером его vita в качестве движка используем докер docker и он же отдает ему команды на работу то есть там создать контейнер удали контейнер и прочее прочее вот то есть вот примерно так работает вся инфраструктура cabernet что просто вот было понимание куда можно смотреть и хотели хотя бы там понимать как это все работает вот в общем вот но собственно тут еще один слайд на котором я просто нарисовал что происходит когда мы говорим купца целью что-то там точно так же идем в пещеру и рэпе серверном отдает ответ если повнимательнее посмотреть на этот слайд то можно увидеть что некоторые компоненты то есть scheduler dns я не знаю кубе прокси они чем-то похожи на работу под систем на работу каких-то процессов обычной операционной системы не на обычный unix операционной системы и на работу обычного unix сервера и из-за этого мне очень нравится думать о том что cabernet можно и нужно рассматривать как операционную систему для кластер а то есть если раньше у нас были просто кластер а из обычных unix хвостов uniq серверов куда мы все хотели там по пятам чем угодно то сейчас появляется кубер нас которую которая представляет собой по сути операционную систему поверх других операционных систем вот то есть и мне нравится представлять это так это именно так ну коль скоро эта операционная система то и и как любую другую операционную систему можно и нужно настроить на что можно обратить внимание ну первое по поводу но тут классика жанра ничего нового то есть следим за нагрузкой на циклу на диск на сеть на утилизацию памяти то есть четыре основных подсистем и мониторим смотрим что все здорово но помимо этого то есть необходима инфраструктура братьям внимание на то как работает наша операционная система cabernet нужно и важно мониторить первую очередь api сервер состоянии кластер и эти сиди и состоянии планировщика кубер нас евро в разделе про мониторинг я немного расскажу про этом значит теперь немножко по проблемам в которыми мы столкнулись когда вот стали в расширять наш кластер когда у нас сервисов становилось все больше вот первая проблема с которой мы столкнулись это нехватка ресурсов это не чистая нехватка ресурсов именно поэтому я нехватку заключил в кавычки смотрите что стало происходить я уже говорил о том что у нас появилось два кластера то есть у нас есть продакшен и появился кластер на котором была развернута df и стретчинг окружения для разработчиков df и стретчинг окружения не чем характерна как только мы научили разработчиков работать cabernet с кластером они сразу захотели там катиться с разных веток когда пришли ребята из отдела автоматизации он нова тестирования не там вообще начали множественно выкатываться в этот кубер накласть это есть в df из эйджинг окружениях стало гораздо больше на порядки больше контейнеров чем в продакшене просто потому что ему еще раз катимся с разных веток катимся по каким-то событиям автомате ционно и тестирование то есть вот это все тут просто сущности стало очень много и тут надо немножко рассказать о том как работает куб scheduler куб scheduler планирует размещение кодов . гда ему приходит спецификация с в которой не написано куда разме стaть нужно там под или deployment то он учитывает размещение ну то куда разместить наш ресурс учитывая вот в дипломе ти есть такая такой путь то есть пик контейнер с ресурс request a steamy насколько сервис изначально запрашивает для себя ресурсов независимо разумеется от фактического потребления ресурсов и поэтому смотрите какая могла возникать картина на это их на этом слайде отображено по горизонтали и вся вычислительная мощность но давайте рассмотрим просто оперативную память вот по количеству request of то есть верхняя линия на ноги расположен под она ноги расположен под б с каким-то вот количеством request of и свободной памяти с точки зрения request of остается но там примерно грубо говоря половина потом планировщику приходит какая-то спецификация в которой есть под c у которого were квестах прописано вот больше чем внутри квест и из-за этого по цене будет размещен на этой ноте даже несмотря на то что смотрите на нижнюю линию что фактически свободной памяти на ноги достаточно для того чтобы разместить этот под этот под не будет на этой ноте размещен так вот в условиях нашей нашего случая то есть когда у нас в div и стейджинг все начало катится очень сильно и очень много у нас складывались очень часто ситуации когда пацци не мог не то что там вот на какой-то ноги разместиться не мог вообще не где разместиться почему это происходило потому что не при 2 лидировали и не устанавливали request и в зависимости от окружения смотрите для дев и стретчинг окружения количество request of количество лимитов нужно и правильно выставлять гораздо меньше чем для продакшена потому что надев стрижен у нас не идет боевой нагрузки а для планировщика вот эти request и критически важны для того чтобы он мог просто размещать большое количество сущности поэтому количество request of всегда нужно при 2 лиги ровать проверять и выставлять различном зависимости от окружения в первую очередь между продакшеном и ну df и station к окружением собственно как это можно сделать первый вариант самый такой в лоб это заставить всех писать эти request но имеют у разработчиков не работала не работает и не будет работать ну просто потому что кто-то забыл кто-то новенький кто-то не понимает как вообще писать request и чего это вообще значит общем это не работает второй вариант немного более эффективно это выделять и ограничивать нам спейси на экспресс терминологии кубер нас это по сути такой логический суд кластер и мы можем например взять какую-то команду разработки отдел до который занимается каким-то функционалом выделить им вот этот логический суп кластер за лимитировать его там ну на 10 циpкa на 10 процессор ных ядерно примерно 100 гигабайт оперативной памяти и сказать вот ваш логический под кластер хотите туда делаете вот что хотите это неэффективно тем что разработчики от этого не начнут писать request и начнут также бездумно туда катится очень скоро исчерпают все свои ресурсы в итоге придут опять к вам их их проблема станет вашей проблемы плохой вариант один из самых правильных вариантов то есть собственно самый правильно это использовать лимит range cabernet предоставляет вот для тех самых namespace of для логических суп мастеров возможность указывать скажем так такой при 2 лидирующей линдер на эти request и то есть это такой объект в кубе r'nessa он описывается как обычная спецификация в котором можно задать во-первых политики число request of по умолчанию то есть там приходит спецификации например в ней request и не прописаны он берет и выставляет значение по умолчанию но которой в нем прописаны кроме этого в нем можно задавать ренджи собственно называется или mid-range можно задавать минимально и максимально допустимое количество request of если приходит к нам спецификация в которой количество request of выходит за этот рейд что мы либо можем reject нить эту конфигурацию либо поменять на дефолтные значения принудительной достаточно хороший способ ну и наконец вариант написать свою ленту на самом деле так и сделали у нас помимо использования лимит раньше еще есть свой интер который на самом деле проверяет спецификацию ещё до того как она приходит в cabernet кластер благо само сообщество кубер нас предоставляет совершенно замечательный пакет который называется клайн 2 используя которой то есть мы могло написали можно очень достаточно просто написать этот линкор и наверняка он может потребоваться и вам почему потому что тот самый лимит раньше котором я рассказывал он работает над носитель на только request of вам же в ходе эксплуатации может потребоваться в он может потребоваться выполнять какие-то проверки ну специфичные вам например захочется может быть проверять что параметр replicas например выставлен явно вот что он просто указан или например какие-то аннотации явно прописан то есть какие-то дополнительные проверки в общем это легко сделать с помощью своего литра то есть использовать лимит рендж и при необходимости если лимит раньше какие-то другие средства не решают вашу задачу можно сделать свой принтер дальше следующая проблема в которой мы столкнулись этого высокие рваные лет инси как я сказал у нас сервисов становилось все больше стали появляться сервисы которые для которых производительность в этом с вообще критично одним из таких сервисов у нас был сервис рекомендательный сервис вот именно он участвует обработки тоже пользовательских запросов разработчики его перевели там со старых добрых алексей контейнеров cabernet выкатили за мониторили этот сервис увидели немножко грустную картину и пришли с этой картиной к нам то есть вот такую вот картину они увидели на этом графике отображено время ответа одного из наших рекомендательных сервисов за 36 часов то есть за полутора суток видны разумеется суточные колебания в зависимости от приходящий нагрузки но дело в другом то есть этот график плохо по двум причинам во-первых среднее этом все он достаточно высоким составляет порядка 400 миллисекунд и что гораздо хуже время ответа она колеблется то есть она скачущая то есть отклонения от среднего времени ответа она иногда превышает в 2 или 3 раза само это среднее значение а в пиках он выходит почти до полутора секунд мы стали разбираться с этой проблемой то есть думали что вообще тут можно сделать первым делом мы начали грешить на то что мы может быть что-то не не дано строили в инфраструктуре cabernet то есть может мы что-то не учили может мы как тазаль имитировали что-то неправильно то есть стали смотреть определенное количество времени на это потратили но ничего не помогает мы даже отключили вообще всякое лимитирование для этого сервиса и даже с помощью тентов размещали этот сервис вот просто на одном сервере что там никто кроме этого сервиса не работал картина от этого не менялась ну стали жить на этом очки на гитхабе еще что-то смотреть но решение оказалось гораздо проще вот прям очень простое то есть использовать собою гарнир performance да да старый добрый то есть я понимаю наверное это слишком очевидно но всегда пожалуйста проверяйте это если кто не знает что это такое но это во-первых аппаратная технология которая позволяет ну аппаратной технологиями на самого процессора он умеет менять тактовую частоту на лету вот и собственно посмотрели и у нас стоял вон demand то есть что это значит это значит что за какой-то sampler у имый интервал времени ну за последние там 10 миллисекунд например операционная система и все смотрит на нагрузку которая была в целом ну там на этом ядре исходя из этого выставляет чистоту на следующий сэмплер у им ну грубо говоря интервал то есть просто ну по принципу обратной связи работает в итоге частота тактового процессора меняется очень часто скачет и что хуже то есть это изменение основана на том что было а не на том что будет поэтому зачастую это было просто мы не эффективно собственно взяли и поставили performance для всех но для всех лидер то есть вот прошлись по всему изменили и увидели вот такую замечательную картину и смотреть как кардинальным образом изменение одной настройки изменила ли танцы нашего сервиса то есть это график того же сервиса за те же 36 часов видим что в томске стал гораздо ниже то есть там порядка 200 миллисекунд и что гораздо более важно он стал стабильным действительно то есть среднее отклонение от среднего значения она ну гораздо меньше сервис работает хорошо кроме этого то есть упал в танце кроме этого вот так у нас снизилась нагрузка на нашей улице на наши worker ноды нашего продакшна кластер а то есть мы получили прям большой очень запас по производительности снизили нагрузку на worker но ты больше чем в два раза практически и коль скоро упала нагрузка на циpкa я здесь слайд не приложил то есть помимо этого ожидаем еще упала энергопотребление всего нашего кластера то есть это очень здорово то есть я тут что о чем хотел сказать на самом деле что всегда смотрите на то насколько эффективно полностью настроен вещь в весь ваш стек то есть кубер нас операционной системой для кластер окей там ее можно настроить подними лежат старой доброй операционные системы когда что то идет не так всегда проверяйте вот по вертикали все моменты все вещи которые только можно настроить для обеспечения эффективной производительности следующая проблема это сетевые потери и тут под дар внутри кубер нас кластер и прежде всего попадает именно dns почему ты но я сейчас объясню когда кубер notice разворачивает контейнер то есть та сама инфраструктура cabernet модифицирует внутри контейнера resort koh в примерно следует вот до такого вида обратите внимание что доменов поиска целых три это необходимо для того чтобы корректно работал механизмов of the discovery внутри cabernet кластера т.е. для того чтобы все работало и в итоге картина получить выглядит следующим образом если мы внутри какого-то контейнера зайдем и просто попросим и пи адрес не знаю api сервера кубер нацистского то увидим что будет выполнено фактически 6 обращений как раз вот ой пиво четыре пива 6 по каждому из домена в поисках только на шестом нам возвращается наконец и пи адрес так вот если у нас есть хоть не значительный уровень сетевых потерями 3 кубер нас кластер и у нас пакет тут получается 12 пакетов до 6 запросов 6 ответов хоть на одном шаге теряется то собственно резольвер либо системой либо тот который в приложении он блокируется на какой-то там период и в итоге мы получаем либо не обслуживаем запрос либо деградацию в работе сервиса общем очень очень плохо поэтому всегда нужно оптимизировать сеть чтобы она работала максимально эффективно внутри кубер нас кастера между worker нотами между инфраструктурой и обязательно следите ему не торте потому что это критически важно как это сделать об этом много уже было сказано тут достаточно стандартные вещи описаны из такого самого интересного можно настроить на сетевом адаптере режим агрегирования прерываний что чтобы прерывание сна каждый приходящий пакета по порогу либо по временному либо по количественному вот следующая проблема мы обнаружили опять-таки характерная для дев ест эйджинг окружений что когда у нас стало появляться много поводов много контейнеров и когда в среднем стала появляться порядка 100 пудов на холсте ту начиналось деградация то сейчас я расскажу как выглядит это деградация и на самом деле есть до сих пор к моему ряд так или иначе ощу открытых на гитхабе которые вроде бы связаны с этой проблемой что при этом происходило то есть когда у нас разработчики стали возможности накатить в.ф. и стейджинг все стало появляться много и в какой-то момент они видят что я и выкладка через этом завершается не успешно происходит что-то странное там либо связь завершает работу по таймауту либо просто once access мы стали смотреть что происходит есть стали смотреть на состояние кодов которые у нас в div стретчинг окружении увидели что у них просто статус контейнер creating и вот он висит висит несмотря на то что citigo что сетью все здорово то есть гопи сервера до registry мы можем достучаться все здорово но упорно кубер ниц не создает контейнеры потом в событийном логе самого кубер нас относительно данного кода ну то есть если выполнить команду купцы тель там диск рай под можно было видеть вот вот такие слова то есть превышение контекста ожидания ошибка синхронизации подопри чему мы пили во множественных случаях именно тогда когда вот число контейнеров на ноги было ну там под сотню или около того разумеется мы в настройках вы помните слайд где я показывал всю инфраструктуру там был процесс кубе лет вот ему можно задать количество максимально максимальное количество кодов который может обслуживать вот естественно поднимали эту настройку никак вообще не спасало ну ни чего не помогало а поскольку div и стейджинг окружении они критически важны для разработчика то есть ему первую очередь важно чтобы вот он мог разрабатывать до чтобы мог катится проверять весь этот функционал стали думать чем можно сделать и собственно приняли решение разбивать наших ас ты то есть у нас хостом вдв и stretching окружении раньше-то был not worker но да это там у сервер не знаю 60 четырьмя ядрами там на 200 гигабайт оперативной памяти и при этом он не мог обслужить вот 100 контейнеров который по сути на которые нет нагрузки просто по сути это 100 процессов в итоге в качестве решения мы просто приняли решение разбивать вот такие большие хасты то есть грей нить их на какие-то более маленькие с помощью вот виртуальных машин мы выбрали квн и там по поводу к вам можно отдельно рассказывать но если вы столкнетесь с такой же проблемой и будете не знаю разворачивать виртуальной машины просто для того чтобы у вас была возможность запускать множество контейнеров всегда тоже проверяйте еще насколько вашей кофемашины хорошо настроены там отдельная история если интересно можете потом поспрашивать расскажу вот то есть вот на самом деле такие были основные проблемы то есть которыми мы сталкивались именно касательно вот самой cabernet инфраструктуры ну вот старались их решать и пока вроде все на текущий момент хорошо вот немного про мониторинг то есть еще раз вернемся на этот слайд и разумеется здесь по-хорошему стоит мониторит вообще все то есть любой из компонентов и scheduler pi server то есть говоря про scheduler мы хотим естественно мониторить не на очередь которая которая у него есть на планирование ресурсов его латинский с какой скоростью он вообще обработан обрабатывает заполняет планирование собственно мониторить хотим api сервер вот сейчас давайте даже так по пунктам расскажут если клубе api серым и естественно хотим получать рейд запросов которые в него приходят причин с разбивкой по операциям какие в него приходят запросы там get post запрос еще что-то хотим мере для каждой вот этого типа операции перцентиле времена ответа рейд ошибок то есть нужно и важно смотреть это вот наверное самая важная метрика которую стоит мониторить метрику бернетт кластер а из нее все начинается как только api сервер начинает плохо работать значит что-то идет не так ты сюда нужны овертон сразу прикручивать скуп dns он то же самое то есть хотим знать насколько эффективно работает в наш внутренний резонанс внутри кубер нас кластер а то есть север секу бернес там 16 проще которые мы используем в состав состоит архитектурные луны состоит архитектурный из двух компонентов dns непосредственно сам процесс который держит себе все записи и там осиным записи кликабельность кластер и dns маска это собственно крышек перед куб денисом который непосредственно принимает все запросы которые делают сервисы отдает им то есть мы хотим знать насколько эффективно используется наш пишут указали кэш сайт 5 тысяч а может это много может там мало ну то есть вот насколько все загружено для q билет от кубе лет тоже критически важно мониторить опять таки те же самые рейд и запросов с разбивкой пират по операциям рейд и ошибок и смотреть что происходит между тем демоном разумеется как мониторит мы все наверное уже знают на самом деле prometheus я позволю себе немножко рассказать то есть если опять смотреть на этот слайд ту прометею сумеет мониторить вот это все просто это очень круто и очень здорово почему во первых все инфраструктурные компоненты вот контроллер менеджера pi server они уже готовы к мониторингу прометею сам то есть как это выглядит про митоз используют полу модель и по умолчанию он ходит в каждый компонент так называемый locations лишь metrics вот локэйшн слышь metrics все эти компоненты поэтому локэйшн умеют отдавать информацию о своей работе это здорово прометею сумеет cabernet с discovery делать то есть нам даст по сути достаточно указать int point to make сервер например но случае эти сиди там необходимости фактически прописать static конфигом на 6 кластер тоже начинает мониторится еще более круто то что если мы все покрываем мониторингом про метался то даже если вы пишете свой сервис например какой то собственно можете запросто в нем написать хендлер который будет преобра ну который будет обслуживать локаций вот этот metrics и если на него прометею сходит вы можете там все что угодно за implement время работы вашей функции не знаю время походов базу все прочее все это будет очень круто мониторится вот по поводу нагрузки вот собственно сейчас немного расскажу про то насколько у нас нагружен prometheus который у нас мониторит наш dv кластер где в кластере мы используем prometheus вот 20 beta 5 то есть прям обкатываем это на самом деле здорово потому что есть возможность обкатать бету на как бы с одной стороны т.д. в кластер с другой стороны df кластером чем интереснее тем что сущности в нем больше в нем гораздо больше контейнеров и соответственно нагрузка на примет его гораздо выше будет вот собственно как себя ведет prometheus вот на таком классе d в кластер авито это примерно 90 worker not примерно 1200 deployment of и примерно 2300 подав ну примерно же и соответственно 2300 контейнеров где-то вот то есть нагрузка на циpкa prometheus а который вот это вот все мониторит она в среднем ниже чем сто процентов то есть меньше одного ядра утилизируется вот эти пики это нормальные пикета штатная работа про метался просто там выполняются периодически операции по работе с внутренней базой общее число метрик которая держит себе про метался ну грубо говоря миллион то есть вот я график взял там по моему за за 2 по моему часа вот примерно миллион метрик в нем лежит его базе псдп то есть там новая база параметра васи версии 2 спада это тоже нормально это выполнение прометею samaritan шона то есть удаляются просто старые метрики то есть все нормально и наконец потребление памяти в параметры вашей второй версии там написано новая база для хранения метрик то есть db называется она собирается прямо prometheus не путать стопом то есть д.б. вот и там просто активно используются вызовы и map и в итоге рано или поздно почти весь dataset datasette ложится в почках linux ядра и примерно вот эта величина она примерно равна величине до тасс это на самом деле то есть вот тот самый миллион метрик да это грубо говоря 30 гигабайт оперативной памяти работает все ну здорово то есть мы довольны мы его используем мы будем его использовать то есть prometheus этом лучше вот собственно выводы губернатор рассматриваете всегда кубер нас как операционную систему для кластер а что у нее есть такие же компоненты по сути как у обычной операционной системы мониторьте их настраиваете весь стек вертикально вплоть до сетевого адаптера то есть этапе сервера до сетевого адаптера мониторить и все все будет хорошо спасибо за внимание [аплодисменты] спасибо большое за доклад было познавательно вот у меня тут есть вопрос и предположение одновременно вот вы говорили что вас когда число под превысило 100 они висели статусе контейнер кретин может я могу предположить что проблема была в обвинить запросов атаку бля такой пещеру он дефолтный довольно таки низкий и когда число кодов превышает 100 но тогда получается они не успевают понять запроса к пещеру и получается они висят в этом статусе да я не упомянутой с одной стороны это эта часть проблемы то есть указывая лимиты и request и мы действительно частично можем решить эту проблему повысив число кодов которые ну доступны могут размещаться на ноги ну не знаю там разум может в полтора есть даже вот открытая и на гитхабе не знаю потом могу сказать вот однако все равно губернатор на наш взгляд пока по-моему не знаю до конца мишина эта проблема то есть я делал синтетические тесты просто даже в виртуальном окружении мне не удавалось не знаю больше 250 трехсот кодов который просто wild русле план делают развернуть и просто утку бернат почему-то но это интересно потому что мы запускали от для тестов дауд просто контейнеры которые делают просто slip бесконечного просто посмотреть сколько влезет а у нас получалось около 500 а вот ну просто дальше мы просто мы даже ну не было смысла продолжать то что мы близки по уши бы кодов и не планируя запускать на одной машине вот поэтому вот насчет этого и хотел бы с вами поговорить мушкеты здесь на кита настроенного займу то есть до тоже будет интересно узнать какие то детали которые мы которых мы не знаем или что то да вот еще вот такой вопрос а в и печники статические используется в калики нет а почему на самом деле еще боюсь соврать жаль никого из коллег из нашего devops отдела нету то есть по поводу настройки калики наверно сильно не смогу ответить то есть они больше там ответили бы на этот вопрос я тут достаточно в общих только деталях знаю на сколько у них там сеть настроена make us ответ на второй вопрос пока ну да если что я потом могу можем как-то контактами обменяться то есть любом случае ребята могут с удовольствием ответят на вопросы так я это понимаю получается при помощи к вaм у вас машина как бы гомогенной дата исключается одинаковое число циpкa памяти на да да да а сами цикл у вас одинаковые то есть 1 архитектуры с одной частотой на хвосте ну говоря про спецификации серверов тут немножко идей ну не могу говорить не просто метода благо интересную току как у губернатора я знаю есть проблемки с конкретными скажем так циpкa сравниваете логические я тогда то есть 1 2 3 вот но при этом не синода разные они не все обеспечат примеру требуем performs да то есть а вот выделит как в большинстве случаев если рассматривать там тот же д в кластерном да можно говорить о том что так или иначе пута многом агента есть они одинаковые плюс-минус и ну винтов так еще такой вот вопрос про dns ну вы не рассматривали расположить на каждой ноги вот локальной dns маску чтобы не гнать трафик куб денисом других очень хороший вопрос на самом деле мы сейчас думая о том как нам повысить стабильность и что мы сейчас хотим делать сейчас работаем над этим рассмотрим просто разы различные схемы и вот то что вы сказали может быть будет одним из вариантов да потому что разумеется dns чем ближе лежит к приложению то есть ну не ходит там куда-то тем лучше то есть в идеале приложение просто должно на локалхост мы по-хорошему ходить и быстро получать ответы даны суда так вы используете статус этой но и так понял для чего для вас например там не знает забрели простые tool set и ну я их просто а описывал нет в кубе рн с у нас прежде всего именно встретились приложения то есть мы если используем стоит full set это скорее для каких-то инфраструктурных компонент то есть там обработчики логов например на который гарантированно должны быть на каждый worker ноги и быть запущены чтобы просто приложение ходила локально и писала вот тоже вопрос отпадает следующий раз во влоге вы как собирается пластик на хостел что у вас ну как агент который мог управлять власть что атом филин по моему да ну то есть тут тут достаточно стандартно все не имел никаких это анализ логов есть еще вопрос здравствуйте меня зовут юра нам мне бы хотелось бы узнать как вы обновляете кластер вроде продаж кластер обновляйте ли вы вообще очень хороший вопрос тут я даже не знаю насколько будет день наверно но могу нам больше наверно про продев рассказать то есть по сути по-хорошему и правильно то есть мы щас приходим к тому что лучше иметь два кластера то есть в итоге потом перед переключаться между ними с одной стороны получаем возможность для экспериментирования проверки полностью рабочего функционала а с другой стороны такой ну такое обновление она не будет аффекте то что развернута в этом кластере и второй вопрос но вот приходит к вам разработчики говорит я там на краби лка это приложение хочу вылиться я не знаю какие любит и установить не знаю керри квесты как вы определяете какие нужно установить лимиты и request и для того или иного приложений то есть как у нас устроено то есть мы workflow стараемся сейчас организовать так чтобы разработчику как раз про это в идеале но не думал ты смотри у нас есть шаблон и сервисов то есть разработчик хочет написать сервис он идет смотрит у нас но там три языка там печка там питон он выбирает там какой-то язык уже есть готовый шаблон сервиса сразу же он туда только там выполняет в этом бизнес-логика дополнять немного спеки этом думает а сколько же мне вот действительно поставить у нас есть там чек-лист то есть разработчик в принципе сам должен но в первом приближении подумать то есть какая хотя бы будет нагрузка ну порядке какие будут на его сервис там рпс то что ему потребуется и обязательно заполняет эту информацию ну там у нас внутренних системах вот мы смотрим то есть насколько это адекватным то есть стоит ли что-то поправить мы стараемся это вот ну как то свести ну не на там в сторону там скорее регламентов каких-то шаблонов спасибо спасибо большая отличный доклад у меня такой вопрос от вы сказали про тюнинг scheduler а на хостах насколько это актуально и осталась актуальной проблема после того как вы переехали на виртуалке то есть там же троттлинга это не про говоров да да да да ну на самом деле та проблема то есть это который рассказал то было в первую очередь для продакшен кластер а там у нас нет вот этого крема для дев истый джинга ну там по сути уже получается не и не особо актуально было потому что нагрузка туда не шла говоря про это я скорее рассказывал про production вот я просто не упомянула там нет у кого им ясно спасибо здравствуйте действительно отличный доклад это как и давненько уже занимаюсь к в вам то ваше упоминания о том что есть некоторые тонкости настройки кого конкретно для данного конкретного тоска вызвал мне любопытство в чем собственно собственно использовать ну а один из моментов с пользой сетевой драйвер vertu я угадал я угадал да потому что по умолчанию квн запускается со старым добрым сетевым драйвером типа я ареал чен una у нас вышло что realtek у этого драйвера чудовищно низкая производительность на прием трафика 20 мегабит и герб выдавал вот совершенно не в общем да то есть я просто говоря про это хотел скорее не про к вам упомянуть и про то что всегда смотрите что вот так система то подсистема которая участвует в работе кубер нас настроено на максимальную высокую производительность и 2 соответственно момент связанный с кремом то так когда нас очень критично сетевые задержки то есть если вас какие то данные о том как ведет себя именно виртуальная система вот эти links бриджес и и прочие подобные вещи но такого наверное не скажу то есть мы вот в квн как запустили по сути вот все работает это виде давно и отлично ну и плюс опять таки это df и стейджинг то есть каких-то нагрузок туда нет мы скорее решили вот проблему большого количества кодов на д встречен кластеров вот понятно спасибо можно еще один вопрос вот такой вот вопрос а вы проходите и 7 если да то как это у нас насколько проблематично это сделать кубинец в смысле попав рот этот сделать чтобы про прокидывать вы еще говорить о том чтобы покидать какие-то устройства или мне пра-пра-пра платежные системы как называется сертификации psy а но тут мало что смогу рассказать не научить индии по ним ладно такой вопрос а как вы свой халат в продакшен загоняете ну и с прокси или что им грызть мы используем on grass in terms стандартная а еще такой вопрос у нас калека бывает проблем и не доступны под и друг друга на куплен с недоступен вас были проблемы с сетью именно вершиной кроме вот там проблема там сетевыми потерями до которых я упоминал да в общем то наверное нет то есть до долей стабильно решен удар да то есть там фланели не использует нет у нас были причины то есть именно выбор калики потому что это bgp потому что это возможность интеграции сеть winter например монолита у нас как у всех есть монолиты есть вот микро сервисы поскольку bpm достать предоставляет удобный способ проброса ну трафика то есть нам это было необходимо и вот выбрали калика спасибо спасибо за доклад очень интересно вопрос простой чем это все раскатываете simcity ну а сам кубер начну используем там паппет а то есть вы узнали так или иначе детей сказал да да да собрали полностью можно вы сами собрали а ну есть уже готовые решения там куб спрей вы не используете потому что его на тот момент не было или осознанно мой мой на тот момент не было но и тут уже по историческим причинам не знаю и по историческим и наверное потому что есть просто ряд там наших уже чисто особенностей как особенности настройки кластер под нашим просто нужды тут уже пусты эффективнее вот зафиксировать скажем так текущего состояния и вот значит у но есть некое воспроизводимой посадили на здесь чтобы вам вот просто развернуть спасибо спасибо за доход какой используйте инструмент для треппинга секрет zip кента kager но тоже не могу сказать там кое что даже твоего и мы используем то есть идеи спасибо еще будут вопросы здравствуйте спасибо за доклад может быть немного странный вопрос про общую файловую систему между кодами контейнерами что как чем то есть речь идет о том чтобы обеспечить persistent внутри всего cabernet кластер а или внутри кода в которые внутри deployment а просто mophie внутри deployment of там собственно и mkdir ну то есть и два контейнера могут использовать одну файловую систему то есть там сокеты те же самые размещались что-то класс тирану текущего имеется вида ну да а если между кластерами чтобы а пока как ты необходимости не возникало вот насколько еще раз мы стараемся то есть чтобы просто приложение будет учесть вот этот манифест r12 factors на это и то есть мы стараемся просто именно стоит ли сервисы загонять в классе чтобы не было привязано затем файл системе к чему-то то есть все что не сервис считается внешним ресурсам и где-то уже не учить как то по другому да ну ладно хорошо спасибо а еще вопрос все-таки базы не загоняются в кластеры принципиально или какие-то объективные причины жилье нужны в проблематике и сходить на самом деле то есть если загон базуку бернайс кластер решает какие-то задачи можно об этом подумать вот так я отвечу то есть просто так загонять базуку вернется просто ради того чтобы она была в купюрница ну зачем нужно понимать какие то задачи решит если действительно там какой-то небольшой это сайт например у нас есть там редис slave до который мы хотим чтобы просто лежал локально ну рядом с приложением до чтобы сервис просто ходил в этот редис например мы знаем там datasette например небольшой почему бы его не поднять до а если переносить ну что-то большое какую задачу мы этим решили всегда надо из этого исходить я буду от маши и стенде avito.ru вот можете подходить спрашивать