Pull to refresh

Comments 57

сожрав попутно ресурсы всего кластера

Т.е. ваш десант профессионалов до работы с Republic не знал, что надо лимиты проставлять?
Для этого и есть раздел «фейлы»:)

Конечно знал, как же иначе. Но от кронджобов на тот момент не ожидали такой прыти:) Всё было заранее омониторено, так что никто особо не пострадал.
с кронджобами еще немало граблей есть.
посмотрите и помедитируйте над
.spec.startingDeadlineSeconds
.spec.concurrencyPolicy
.spec.successfulJobsHistoryLimit
.spec.failedJobsHistoryLimit

Меня интересует то, что осталось за кадром.


  1. Куб поверх bare metal?
  2. Как подам назначают ip? Или есть overlay сеть?
  3. Безопасность: докеры с рутом внутри? Egress/ingress/podpolicy/namespaces?
  4. Что с pvc? Хранилище? Это на тех же нодах? А добавлять тогда ещё ноду? Хранилище ведь тоже придется растягивать, иначе привет локальность данных?
  5. Как сделан LB снаружи? Понятно, что если облако, то все круто. А если куб на баре метал (ведь именно так?)? Vrrp? Балансировка по Dns?
  6. Почему не взяли openshift? В нем очень удобно строить пайплайны через встроенный Дженкинс. Ну, и получаете все возможности куба, если нужно.
  7. Как я понял, проект пока не дорос до Истио и сквозного трейсинга запросов (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, в целом.
Получается DB является «бутылочным горлышком» системы? Если не секрет, как планируете решать? Или считается, что DB никогда не упадёт/перенагрузится?
Даа, пока основным камнем преткновения, если что, будет база. Не секрет, прямо сейчас никак не планируем решать, запас мощности сильно достаточный, есть резервирование. Но в целом да, это будет ещё отдельная головная боль.
Почему не поставите ucarp?
>А здесь могут быть варианты. Либо мы назначаем А запись на некий фиксированный плавающий ip между нодами (vrrp?).

Можно сделать две-три А-записи для нескольких IP, по крайней мере, браузеры понимают, что если один IP-адрес недоступен, нужно пойти на второй (или на третий).

nslookup также показывает все адреса.
Понимать-то понимают, но запрос уже может быть потерян. Т.е. условно у Вас пул из 5 IP и вы создаете 5 A записей на них. Один хост падает. Итог — в среднем теряется 1/5 всех запросов. Безвозвратно. В случае, если клиент приложение, а не браузер клиента — ок, можем сделать ретрай. А если нет?
А если хост падает, разве можно как-то «сохранить» уже отправленный ему по http(s) запрос?
Отправленный — нет, конечно. Но речь про то, чтобы последующие запросы попадали в правильные места.
«Правильные» http-клиенты тупо при нескольких A записях шлют запросы по раунд-робину. И я уж не говорю про те случаи, когда пользователь сидит дома за роутером и вопрос — сколько уровней кэша у его ДНСа? Это я к «править ДНС вручную при отказе узла» (даже если TTL маленький).
Мы делали эксперимент на swarm с тремя нодами, traefik в качестве reverse proxy. Одну ноду останавливаем, после этого один раз chrome (который браузер) кашляет (не всегда), далее работает нормально.
Или поставить ucarp, убив на установку, осознание и настройку полчаса.
Расскажите кратко, пожалуйста, чем ucarp примечателен в отличие от pacemaker, например.
Это поддержка виртуального IP на нескольких серверах с переопределением ролей в зависимости от выставленного приоритета и доступности сервера.
Ну, как бы Вы ничего нового не сказали. keepalived/pacemaker решают абсолютно ту же задачу.
Да, ещё отдельный вопрос. Наличие куба отчасти заменяет необходимость тащить scm для управления целевыми серверами. Ну, тем более scm на два сервера — оверкилл, проще ансиблом тогда описать среду )
Но вот сам куб предполагает подготовку ноды. А у вас там ещё гластер, БД и прочее. Что нужно для начала бутстрвппить, а потом поддерживать. Вот и интересно, что сделано для этого.
Для куба у нас есть пучок готовых плейбуков ансибловых, поэтому докидывать новые выч.мощности можно очень быстро. БД отдельным внешним сервисом сделана, про неё в ветке выше отметил. Гластер пока руками, если что, менеджерить придётся, да.
А что мешало им всю оркестрацию на Ansible тогда сделать? Получилось бы тоже самое, но с большей производительностью (если bare-metal активнее использовать) и переезд в «облако» будет гораздо дешевле в будущем (например, на OpenStack или AWS). Притом не было бы такого лютого vendor-lock на k8s.
Благодаря переводу Republic на k8s мы получили архитектуру, использующую кластер из трёх реальных машин, на которых может одновременно «крутиться» до двенадцати копий веб-приложения. При этом система сама, исходя из текущих нагрузок, решает, сколько копий ей нужно прямо сейчас

Такой вопрос — а чем хуже сразу запустить двенадцать копий? Понятно, ресурсы будут потребляться, ну и что? Оплата же не за время работы CPU в данном случае?

Ведь в «кубике» после того, как cron-контейнер выполнился, ты в него больше не попадёшь.

Немного похожий вопрос — чем хуже обычный контейнер, который внутри себя что-то периодически запускает? И «зайти» в него можно, и историю потребления ресурсов посмотреть.
Такой вопрос — а чем хуже сразу запустить двенадцать копий? Понятно, ресурсы будут потребляться, ну и что? Оплата же не за время работы CPU в данном случае?

Чтобы понимать лучше реальное потребление и, соответственно, планировать будущие мощности
Немного похожий вопрос — чем хуже обычный контейнер, который внутри себя что-то периодически запускает? И «зайти» в него можно, и историю потребления ресурсов посмотреть.

Собственно, всем. Для кронджобов есть отдельная инфраструктура проверок, перезапусков и прочего, в рамках самого k8s. Нет нужды залезать внутрь самого контейнера вообще. Для управления периодическими задачами в кластере сильно удобнее, чем вылавливать, где там запустился обычный контейнер, ходить в него, что-то там внутри самому проверять и пр.
Чтобы понимать лучше реальное потребление и, соответственно, планировать будущие мощности


Честно говоря, не уловил. Вот, например, вариант 1. Запускаем сразу двенадцать копий, сразу резервируем им память, и уверены, что в случае чего, они не подведут. По телеметрии смотрим загрузку, ее динамику и так далее. Т.е. как раз понимаем реальное потребление.

Теперь вариант 2. Запускаем четыре копии, на пике — двенадцать. Памяти-то хватит на пике? Непонятно. Какие конкретно преимущества имеет этот вариант по пониманию реального потребления?
В первом варианте потребление ресурсов неявное. 12 запущенных контейнеров, половина из которых простаивает, потребляют ресурсов больше, чем 6 запущенных и активно работающих, но меньше, чем 12 активно работающих. Вот я о чём. И для большей точности данных мы бы предложили не плодить висящие контейнеры.
12 запущенных контейнеров, половина из которых простаивает, потребляют ресурсов больше, чем 6 запущенных и активно работающих, но меньше, чем 12 активно работающих.


Это понятно. Но сэкономленные ресурсы все равно нельзя использовать в другом месте — иначе будет трудно запустить 12 контейнеров, когда наступит время и придут миллионы читателей.

К чему тогда экономия, раз она ставит по удар функционирование системы на пике нагрузки? Запустил 12 контейнеров, и все. Если остались ресурсы — можно еще что-то запустить на постоянной основе. Смысл масштабирования в рассматриваемом примере неясен.
Но сэкономленные ресурсы все равно нельзя использовать в другом месте

Всё так, да. В идеале подобный подход был придуман под облака, когда машины можно брать мгновенно у того же хостера за почасовую оплату. И когда у вас дикий пик х100, то вы красивый выезжаете на белом коне, заплатив чуть больше обычного месячного прайса. GKE, Heroku, вот это про них про всех.

Но пока что их месячный прайс оказывается уж слишком неприятным в сравнении с покупкой железок и определённой вознёй с простаиванием/наращиванием мощностей.

Поэтому пока получается такой, околопереходный период, когда сам проект инфраструктурно готов устремляться в самое отдалённое будущее, но в настоящем это стоит каких-то футуристических денег. Поэтому выбираются подобные компромиссы. Когда игроков на рынке подобных хостингов станет больше и ценники упадут до более приемлемых значений, можно будет мигрировать вообще без головной боли.
В идеале подобный подход был придуман под облака, когда машины можно брать мгновенно у того же хостера за почасовую оплату.


Как говорилось в «Лачуге должника» — благ-за-ин!
Можно ссылочку на упомянутый материал?
Я, видимо, что-то в этой жизни пропустил ))))
Это Вадим Шефнер, советская фантастика.

Тынц
— Павел Васильевич Белобрысов,- отрекомендовался мой странный сосед.-
Родился в Ленинграде в две тысячи сто седьмом году.- Произнеся это, он
почему-то покосился в мою сторону.- Имею много специальностей, которые
могут пригодиться где угодно. Здоровье — двенадцать баллов с гаком.
— Не все понял я, уважаемый Павел Васильевич,- почтительно произнес
секретарь.- Что вы имеете честь подразумевать под словом «гак»?
— Гак — металлический крюк на древних кораблях, служивший для подъема
грузов и шлюпок,- пояснил я элмеху.
— Благ-за-ин! — поклонился мне элмех. Затем, обернувшись к Белобрысову,
спросил: — Значит, могу зафиксировать и доложить Терентьеву я, что вы
можете заменить собой металлический крюк и персонально осуществлять
передвижение тяжелых предметов?
— Да нет, это дядя шутит… Вернее, я шучу,- пробурчал Белобрысов.


Там довольно много лингвистических экспериментов, на любителя, конечно, но мне нравится.
Но пока что их месячный прайс оказывается уж слишком неприятным в сравнении с покупкой железок и определённой вознёй с простаиванием/наращиванием мощностей.

А если не секрет, что за сервера используются в варианте bare-metal-а?
Просто если учесть стоимость работ по обслуживанию, простоям из-за сбоев и всякие особенности контрактов на свое железо, а так же невозможность масштабирования не должно очень большой разницы получаться, особенно со stateless приложениями, где можно preemptible/spot nodes использовать и прочие трики.
Интересно, в каком сценарии можно использовать spot nodes, кроме каких-то распределенных вычислений? Кэширование статического контента?
Да почти во всех, где надо много емкости на некоторое время и есть устойчивость к перезапускам отдельных элементов, или хочется экономить (а кому не хочется) и архитектура позволяет.
То есть от обработки пользовательских запросов nginx-ом до бигдаты, да.
Не рекомендуется только для баз по понятным причинам, но с исключениями — можно даже ClickHouse какой нибудь поверх этого крутить, если юзкейс поволяет. По крайней мере частично, что уже даст ощутимую экономию средств.
На самом деле очень много систем и проектов живут на спотах в AWS, потому что выгодно. Некоторые кейсы можно найти допустим тут. Сходу — Yelp вот пользуется и радуется, вот их доклад на сайте Mesosphere.
У меня самого почти все машинки на проектах — это spot/preemptible (чаще второе, потому что почти все в GKE) и практически все, что касается разработки на них, включая Jenkins и Gitlab (за исключением непосредственно gitaly, т.к. он пока не умеет в HA) и все энвайременты продуктов (там конечно не все ноды preemptibe, но большинство).
Смысл масштабирования в рассматриваемом примере неясен.

Согласен с вами, тоже почитал и не очень понял зачем. HPA без автоскейлинга на уровне нод весьма бесполезны. Есть конечно исключения, можно к примеру сделать кастомный scheduler и что-то вроде контроллера и реализовать что-то вроде вытеснения некритичной нагрузки в момент пиков в пользу критичной, но тут явно не тот случай.
Я не вижу какой CI/CD pipeline tool используется?

Сколько по времени занял проект?

А вообще, когда понимаешь о чем все это, то это конечно классический пример.
Думаю если это взлетело, вы можете гордиться что обратили в новую веру обучили еще одну команду современным методам разработки, доставки и мониторинга веб приложений. Это важно. Надеюсь все разрабочики клиента сказали вам за это спасибо.
Нифига себе небольшой период адаптации! Очень ценно, что Вы описали необходимые архитектурные изменения, но они в большинестве, как мне кажется, случаев подобных систем, потребуют той или иной степени кардинальных массовых и глубоких переделок!
UFO just landed and posted this here
Согласен, что чистые выгоды не очень большие и не связанны напрямую с К8.

Но внедрить нормальный CI/CD pipeline и просто переучить команду думать на «современный лад» это все равно вполне достойный побочный эффект.

Плюс я так понял им внедрили мониторинг всего этого зоопарка на базе ELK — это тоже весьма ценный бонус.
UFO just landed and posted this here
И при чем здесь хайлоад?

По-моему, ни я ни автор не упоминали хайлоад. Поэтому вопрос не очень понятен.
UFO just landed and posted this here
Вебсокеты на D — наследие старины глубокой, ещё предыдущим поколением разрабов было притащено:)

А вот что не так с ELK, не вполне понимаю, если честно. Как бы вы предложили агрегировать логи со всех этих подов?
мониторинг всего этого зоопарка на базе ELK

мониторинг на ELK? Ну-ну.
Вы имели в виду может быть сбор логов и алертинг, если какие-то определенные сообщения попадают в логи?
или «ёлка» под метрики тоже?
dzsysop нене, ребят, вы чего. Ёлка для сбора и анализа логов только. Мониторинг там вообще отдельно идёт наш собственный.

Вот уже после сентенции о переезде на k8s как способе повышения производительности решения можно смело увольнять авторов идеи.


Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…


Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого "раз и подкинули сервер" пропагандируете?
Для идиотов?

Переезд можно рассматривать как способ улучшения управления инфраструктурой — да. Но об этом внезапно в целях ни слова…

Как это ничего не сказано? Сразу в нескольких местах:

нужно было изменить структуру проекта таким образом, чтобы он мог живо реагировать на изменение условий работы (в основном, внешней нагрузки), оставаясь полностью работоспособным и доступным для читателей даже в моменты очень резких скачков посещаемости. И отличным бонусом было бы минимальное ручное вмешательство технической команды Republic в такие моменты.


Мы получили удобную систему оркестрации проекта. Как только команда Republic заметит, что им в целом перестаёт хватать текущих ресурсов и риски сверхвысоких нагрузок (либо когда уже стряслось и всё легло), они просто берут ещё один сервер, за 10 минут раскатывают на нём роль узла кластера, и оп-оп — всё снова красиво и хорошо. Предыдущая же структура проекта вообще не предполагала такого подхода, там не было ни медленных, ни быстрых решений подобных проблем.

и даже отдельно в комментариях обсудили компромисс между полноценными облаками и собственным кубом на железках
Ок, допустим будем считать что сказано.

Но смотрите.
Оркестрация помогает и нужна тогда, когда имеется ряд повторяющихся (!) действий с инфраструктурой, который требует большого количества усилий технических специалистов.
Например, каждый деплой занимает человеко-дни, а хотелось бы минуты или в крайнем случае часы с учетом подготовки.
Добавление нового сервера — боль.
И т.д. и т.п.
И занимается этим всем штат в Н человек.

Что же мы видим:
  • Что у вас есть? У вас есть on premise решение на фиксированном и маленьком (!) числе серверов.
  • Какие проблемы и сложности вы испытывали? Нагрузка. Об остальном ни слова
  • Сколько типов различных нагрузок у вас есть? Скорее всего ровно 3 — посетители, обновление контента, какая-нибудь статистика.
  • Какое поле для маневра имеется? А никакого. Вы не можете отрезать мощности, например, от расчета статистики в тот момент когда она у вас не считается… Все что вы можете это подстраивать обновление и статистику под основную нагрузку которую вам создают пользователи.


Вам точно тут прямо кровь из носу нужна оркестрация ценой 8 человеко-месяцев (это без учета усилий команды)?
И ваши специалисты стоят явно не дешевле типового мидла на фултайм, верно?

Так что мы имеем в итоге?
Какую техническую проблему вы решили?
А какую проблему бизнеса?

P.S. чисто для справки CDN снижает до 90% нагрузку на типичный новостной сайт/блог.
Заводится за пару дней усилиями 1.5 землекопов
А это означает что в общем случае существовавшего решения продукту хватило бы еще на годы с учетом развития (если там действительно 75к хитов в сутки)
aghast 4umak
impproxy

imgproxy?
Fortop
согласен, что я из статьи не понял — у кого был запрос на частые изменения.
Сколько в команде Republic разработчиков. По моим оценкам это должно быть отдел из 5-10 разработчиков минимум, чтобы была выгода от k8s. Ну, понятно, что еще изменения могут быть из серии: утром поменяли конфиг nginx, пересобрали образы, перезапустили контейнеры, а вечером все сделали в обратном порядке (у нас же теперь конфигурация = часть образа?), но такое себе.
обновление контента

будет смешно, если окажется, что обновление контента тащит за собой пересборку образов и их перевыкладку.

Плюс переезда на k8s я вижу хотя бы в том, что парни смогут масштабироваться в публичное облако, если им не будет хватать ресурсов, но для этого все остальные части системы должны быть для этого подготовлены (файловое хранилище, LB и пр.)
Дальше больше. Сервера в один клик и быстро докупить выйдет не у каждого провайдера. В общем случае время реакции до пары недель играючи… Вы для кого «раз и подкинули сервер» пропагандируете?
Для идиотов?

Я бы не стал, конечно, так резко развешивать ярлыки, но если ваш хостер ставит вам сервера по нескольку недель, то, возможно, стоит о чём-то в жизни задуматься.
Мне кажется, или все то же самое можно было бы сделать на чистом compose и с consul для dns lb, к примеру. Даже с учетом переезда в облака и автоскейлинга в них.
Есть ли какой-либо дополнительный профит от усложнения системы сборкой k8s и виртуальными сетями?
compose — какой? Мне очень не нравится, что это слово используется к делу и не к делу в разных (совершенно разных) продуктах. Предполагаю, что речь про docker-compose — ну, так его так и называйте. Ну, и он все-таки не для production-использования. Понятно, что можно деплоить прод и через scp. Так же можно использовать и docker-compose «в проде». Но основное его применение — для тестов и для разработки.
Consul — да, неплохая идея ) Но все-таки тут нужно хорошо подумать про механизм LB.
Статьи — это статика, комментарии обычно сторонние подключены, и большая часть пришедших, прочитав статью, сайт закроет. Почему обычная cdn с этим не справится?

UPD. Не заметил комментарий выше. В общем, мне это напомнило статью о том, что mongoDB не справлялся с нагрузкой Guardian (что очень сомнительно).
Sign up to leave a comment.