Comments 57
сожрав попутно ресурсы всего кластера
Т.е. ваш десант профессионалов до работы с Republic не знал, что надо лимиты проставлять?
Конечно знал, как же иначе. Но от кронджобов на тот момент не ожидали такой прыти:) Всё было заранее омониторено, так что никто особо не пострадал.
Меня интересует то, что осталось за кадром.
- Куб поверх bare metal?
- Как подам назначают ip? Или есть overlay сеть?
- Безопасность: докеры с рутом внутри? Egress/ingress/podpolicy/namespaces?
- Что с pvc? Хранилище? Это на тех же нодах? А добавлять тогда ещё ноду? Хранилище ведь тоже придется растягивать, иначе привет локальность данных?
- Как сделан LB снаружи? Понятно, что если облако, то все круто. А если куб на баре метал (ведь именно так?)? Vrrp? Балансировка по Dns?
- Почему не взяли openshift? В нем очень удобно строить пайплайны через встроенный Дженкинс. Ну, и получаете все возможности куба, если нужно.
- Как я понял, проект пока не дорос до Истио и сквозного трейсинга запросов (jaeger, например) — нету?
Куб поверх bare metal?
ага
Как подам назначают ip? Или есть overlay сеть?
сеть на Calico
Безопасность: докеры с рутом внутри? Egress/ingress/podpolicy/namespaces?
сколько всего в одном вопросе собрали) Egress нет, Ingress да, podPolicy нет, неймспейсы да. Внутри контейнеров есть вещи, крутящиеся от рута, да.
Что с pvc? Хранилище? Это на тех же нодах? А добавлять тогда ещё ноду? Хранилище ведь тоже придется растягивать, иначе привет локальность данных?
Хранилище на гластере, пока на тех же нодах, да. Придётся, что поделать:) Возможно, в будущем придём к другому варианту с хранилкой.
Как сделан LB снаружи? Понятно, что если облако, то все круто. А если куб на баре метал (ведь именно так?)? Vrrp? Балансировка по Dns?
DNS, да
Почему не взяли openshift? В нем очень удобно строить пайплайны через встроенный Дженкинс. Ну, и получаете все возможности куба, если нужно.
С кубом больше опыта, банально. Ну а пайплайнами из дженкинса, в целом, без разницы, куда тыкать:)
Как я понял, проект пока не дорос до Истио и сквозного трейсинга запросов (jaeger, например) — нету?
Не, не было пока нужды, правильно понимаете
По LB и DNS интересно подробнее.
Смотрите. Речь идёт про веб-сайт, конечными пользователями… являются юзеры (простите, за тавтологию). Не мобильное приложение, десктопное приложение и пр., а именно, что живые люди. Живым людям надо отдать DNS. Единый адрес сайта, независимо от того, какая из год живёт. А здесь могут быть варианты. Либо мы назначаем А запись на некий фиксированный плавающий ip между нодами (vrrp?). Либо нам нужно оперативно править DNS. Либо у нас есть свой LB перед озвученными нодами, но он тогда становится сам точкой отказа. В общем — прошу больше подробностей, вряд ли эта реализация является коммерческой тайной и ноу-хау.
Второй момент. Сейчас две ноды в кубе. Положим, получается история, что они друг друга не видят. И обе думают, что единственные живые ноды. Как планируете решать? Тем более, что, как я понимаю, новостной сайт подразумевает какое-то состояние, которое должно разделяться (реплицироваться) между нодами — зарегистрированные пользователя, комментарии к статьям и пр. Или этого всего нет и сервис ТОЛЬКО и делает, что отдает предварительно подготовленный контент ?
И что тогда с CDN, чтобы побыстрее статику отдавать клиентам? Нет его?
Либо нам нужно оперативно править DNS
Именно так, балансировка исключительно днсами в данный момент выполняется.
Сейчас две ноды в кубе.
опс, вот тут у нас информационная диверсия вышла, нод не две, а три. Как на схеме нарисовано. В тексте сейчас поправим.
Тем более, что, как я понимаю, новостной сайт подразумевает какое-то состояние, которое должно разделяться (реплицироваться) между нодами
состояние в БД, которая подключена внешним сервисом, что тоже отмечено на схеме.
И что тогда с CDN, чтобы побыстрее статику отдавать клиентам? Нет его?
нет, в данный момент CDN не используется. Но в целом, при выкатке нового релиза ничего не мешает статике так же компилить и заливать в CDN, в целом.
Можно сделать две-три А-записи для нескольких IP, по крайней мере, браузеры понимают, что если один IP-адрес недоступен, нужно пойти на второй (или на третий).
nslookup также показывает все адреса.
«Правильные» http-клиенты тупо при нескольких A записях шлют запросы по раунд-робину. И я уж не говорю про те случаи, когда пользователь сидит дома за роутером и вопрос — сколько уровней кэша у его ДНСа? Это я к «править ДНС вручную при отказе узла» (даже если TTL маленький).
Но вот сам куб предполагает подготовку ноды. А у вас там ещё гластер, БД и прочее. Что нужно для начала бутстрвппить, а потом поддерживать. Вот и интересно, что сделано для этого.
Благодаря переводу Republic на k8s мы получили архитектуру, использующую кластер из трёх реальных машин, на которых может одновременно «крутиться» до двенадцати копий веб-приложения. При этом система сама, исходя из текущих нагрузок, решает, сколько копий ей нужно прямо сейчас
Такой вопрос — а чем хуже сразу запустить двенадцать копий? Понятно, ресурсы будут потребляться, ну и что? Оплата же не за время работы CPU в данном случае?
Ведь в «кубике» после того, как cron-контейнер выполнился, ты в него больше не попадёшь.
Немного похожий вопрос — чем хуже обычный контейнер, который внутри себя что-то периодически запускает? И «зайти» в него можно, и историю потребления ресурсов посмотреть.
Такой вопрос — а чем хуже сразу запустить двенадцать копий? Понятно, ресурсы будут потребляться, ну и что? Оплата же не за время работы CPU в данном случае?
Чтобы понимать лучше реальное потребление и, соответственно, планировать будущие мощности
Немного похожий вопрос — чем хуже обычный контейнер, который внутри себя что-то периодически запускает? И «зайти» в него можно, и историю потребления ресурсов посмотреть.
Собственно, всем. Для кронджобов есть отдельная инфраструктура проверок, перезапусков и прочего, в рамках самого k8s. Нет нужды залезать внутрь самого контейнера вообще. Для управления периодическими задачами в кластере сильно удобнее, чем вылавливать, где там запустился обычный контейнер, ходить в него, что-то там внутри самому проверять и пр.
Чтобы понимать лучше реальное потребление и, соответственно, планировать будущие мощности
Честно говоря, не уловил. Вот, например, вариант 1. Запускаем сразу двенадцать копий, сразу резервируем им память, и уверены, что в случае чего, они не подведут. По телеметрии смотрим загрузку, ее динамику и так далее. Т.е. как раз понимаем реальное потребление.
Теперь вариант 2. Запускаем четыре копии, на пике — двенадцать. Памяти-то хватит на пике? Непонятно. Какие конкретно преимущества имеет этот вариант по пониманию реального потребления?
12 запущенных контейнеров, половина из которых простаивает, потребляют ресурсов больше, чем 6 запущенных и активно работающих, но меньше, чем 12 активно работающих.
Это понятно. Но сэкономленные ресурсы все равно нельзя использовать в другом месте — иначе будет трудно запустить 12 контейнеров, когда наступит время и придут миллионы читателей.
К чему тогда экономия, раз она ставит по удар функционирование системы на пике нагрузки? Запустил 12 контейнеров, и все. Если остались ресурсы — можно еще что-то запустить на постоянной основе. Смысл масштабирования в рассматриваемом примере неясен.
Но сэкономленные ресурсы все равно нельзя использовать в другом месте
Всё так, да. В идеале подобный подход был придуман под облака, когда машины можно брать мгновенно у того же хостера за почасовую оплату. И когда у вас дикий пик х100, то вы красивый выезжаете на белом коне, заплатив чуть больше обычного месячного прайса. GKE, Heroku, вот это про них про всех.
Но пока что их месячный прайс оказывается уж слишком неприятным в сравнении с покупкой железок и определённой вознёй с простаиванием/наращиванием мощностей.
Поэтому пока получается такой, околопереходный период, когда сам проект инфраструктурно готов устремляться в самое отдалённое будущее, но в настоящем это стоит каких-то футуристических денег. Поэтому выбираются подобные компромиссы. Когда игроков на рынке подобных хостингов станет больше и ценники упадут до более приемлемых значений, можно будет мигрировать вообще без головной боли.
В идеале подобный подход был придуман под облака, когда машины можно брать мгновенно у того же хостера за почасовую оплату.
Как говорилось в «Лачуге должника» — благ-за-ин!
Я, видимо, что-то в этой жизни пропустил ))))
Тынц
— Павел Васильевич Белобрысов,- отрекомендовался мой странный сосед.-
Родился в Ленинграде в две тысячи сто седьмом году.- Произнеся это, он
почему-то покосился в мою сторону.- Имею много специальностей, которые
могут пригодиться где угодно. Здоровье — двенадцать баллов с гаком.
— Не все понял я, уважаемый Павел Васильевич,- почтительно произнес
секретарь.- Что вы имеете честь подразумевать под словом «гак»?
— Гак — металлический крюк на древних кораблях, служивший для подъема
грузов и шлюпок,- пояснил я элмеху.
— Благ-за-ин! — поклонился мне элмех. Затем, обернувшись к Белобрысову,
спросил: — Значит, могу зафиксировать и доложить Терентьеву я, что вы
можете заменить собой металлический крюк и персонально осуществлять
передвижение тяжелых предметов?
— Да нет, это дядя шутит… Вернее, я шучу,- пробурчал Белобрысов.
Там довольно много лингвистических экспериментов, на любителя, конечно, но мне нравится.
Но пока что их месячный прайс оказывается уж слишком неприятным в сравнении с покупкой железок и определённой вознёй с простаиванием/наращиванием мощностей.
А если не секрет, что за сервера используются в варианте bare-metal-а?
Просто если учесть стоимость работ по обслуживанию, простоям из-за сбоев и всякие особенности контрактов на свое железо, а так же невозможность масштабирования не должно очень большой разницы получаться, особенно со stateless приложениями, где можно preemptible/spot nodes использовать и прочие трики.
То есть от обработки пользовательских запросов nginx-ом до бигдаты, да.
Не рекомендуется только для баз по понятным причинам, но с исключениями — можно даже ClickHouse какой нибудь поверх этого крутить, если юзкейс поволяет. По крайней мере частично, что уже даст ощутимую экономию средств.
На самом деле очень много систем и проектов живут на спотах в AWS, потому что выгодно. Некоторые кейсы можно найти допустим тут. Сходу — Yelp вот пользуется и радуется, вот их доклад на сайте Mesosphere.
У меня самого почти все машинки на проектах — это spot/preemptible (чаще второе, потому что почти все в GKE) и практически все, что касается разработки на них, включая Jenkins и Gitlab (за исключением непосредственно gitaly, т.к. он пока не умеет в HA) и все энвайременты продуктов (там конечно не все ноды preemptibe, но большинство).
Смысл масштабирования в рассматриваемом примере неясен.
Согласен с вами, тоже почитал и не очень понял зачем. HPA без автоскейлинга на уровне нод весьма бесполезны. Есть конечно исключения, можно к примеру сделать кастомный scheduler и что-то вроде контроллера и реализовать что-то вроде вытеснения некритичной нагрузки в момент пиков в пользу критичной, но тут явно не тот случай.
Сколько по времени занял проект?
А вообще, когда понимаешь о чем все это, то это конечно классический пример.
Думаю если это взлетело, вы можете гордиться что
Но внедрить нормальный CI/CD pipeline и просто переучить команду думать на «современный лад» это все равно вполне достойный побочный эффект.
Плюс я так понял им внедрили мониторинг всего этого зоопарка на базе ELK — это тоже весьма ценный бонус.
И при чем здесь хайлоад?
По-моему, ни я ни автор не упоминали хайлоад. Поэтому вопрос не очень понятен.
А вот что не так с ELK, не вполне понимаю, если честно. Как бы вы предложили агрегировать логи со всех этих подов?
мониторинг всего этого зоопарка на базе ELK
мониторинг на ELK? Ну-ну.
Вы имели в виду может быть сбор логов и алертинг, если какие-то определенные сообщения попадают в логи?
или «ёлка» под метрики тоже?
Вот уже после сентенции о переезде на k8s как способе повышения производительности решения можно смело увольнять авторов идеи.
Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…
Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого "раз и подкинули сервер" пропагандируете?
Для идиотов?
Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…
Как это ничего не сказано? Сразу в нескольких местах:
нужно было изменить структуру проекта таким образом, чтобы он мог живо реагировать на изменение условий работы (в основном, внешней нагрузки), оставаясь полностью работоспособным и доступным для читателей даже в моменты очень резких скачков посещаемости. И отличным бонусом было бы минимальное ручное вмешательство технической команды Republic в такие моменты.
Мы получили удобную систему оркестрации проекта. Как только команда Republic заметит, что им в целом перестаёт хватать текущих ресурсов и риски сверхвысоких нагрузок (либо когда уже стряслось и всё легло), они просто берут ещё один сервер, за 10 минут раскатывают на нём роль узла кластера, и оп-оп — всё снова красиво и хорошо. Предыдущая же структура проекта вообще не предполагала такого подхода, там не было ни медленных, ни быстрых решений подобных проблем.
и даже отдельно в комментариях обсудили компромисс между полноценными облаками и собственным кубом на железках
Но смотрите.
Оркестрация помогает и нужна тогда, когда имеется ряд повторяющихся (!) действий с инфраструктурой, который требует большого количества усилий технических специалистов.
Например, каждый деплой занимает человеко-дни, а хотелось бы минуты или в крайнем случае часы с учетом подготовки.
Добавление нового сервера — боль.
И т.д. и т.п.
И занимается этим всем штат в Н человек.
Что же мы видим:
- Что у вас есть? У вас есть on premise решение на фиксированном и маленьком (!) числе серверов.
- Какие проблемы и сложности вы испытывали? Нагрузка. Об остальном ни слова
- Сколько типов различных нагрузок у вас есть? Скорее всего ровно 3 — посетители, обновление контента, какая-нибудь статистика.
- Какое поле для маневра имеется? А никакого. Вы не можете отрезать мощности, например, от расчета статистики в тот момент когда она у вас не считается… Все что вы можете это подстраивать обновление и статистику под основную нагрузку которую вам создают пользователи.
Вам точно тут прямо кровь из носу нужна оркестрация ценой 8 человеко-месяцев (это без учета усилий команды)?
И ваши специалисты стоят явно не дешевле типового мидла на фултайм, верно?
Так что мы имеем в итоге?
Какую техническую проблему вы решили?
А какую проблему бизнеса?
P.S. чисто для справки CDN снижает до 90% нагрузку на типичный новостной сайт/блог.
Заводится за пару дней усилиями 1.5 землекопов
А это означает что в общем случае существовавшего решения продукту хватило бы еще на годы с учетом развития (если там действительно 75к хитов в сутки)
impproxy
imgproxy?
Fortop
согласен, что я из статьи не понял — у кого был запрос на частые изменения.
Сколько в команде Republic разработчиков. По моим оценкам это должно быть отдел из 5-10 разработчиков минимум, чтобы была выгода от k8s. Ну, понятно, что еще изменения могут быть из серии: утром поменяли конфиг nginx, пересобрали образы, перезапустили контейнеры, а вечером все сделали в обратном порядке (у нас же теперь конфигурация = часть образа?), но такое себе.
обновление контента
будет смешно, если окажется, что обновление контента тащит за собой пересборку образов и их перевыкладку.
Плюс переезда на k8s я вижу хотя бы в том, что парни смогут масштабироваться в публичное облако, если им не будет хватать ресурсов, но для этого все остальные части системы должны быть для этого подготовлены (файловое хранилище, LB и пр.)
Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого «раз и подкинули сервер» пропагандируете?
Для идиотов?
Я бы не стал, конечно, так резко развешивать ярлыки, но если ваш хостер ставит вам сервера по нескольку недель, то, возможно, стоит о чём-то в жизни задуматься.
Есть ли какой-либо дополнительный профит от усложнения системы сборкой k8s и виртуальными сетями?
Consul — да, неплохая идея ) Но все-таки тут нужно хорошо подумать про механизм LB.
UPD. Не заметил комментарий выше. В общем, мне это напомнило статью о том, что mongoDB не справлялся с нагрузкой Guardian (что очень сомнительно).
Как мы сайт Republic на Kubernetes переводили