Недавно Ably (SaaS pub/sub) оправдывались в своем блоге за то, что не используют Kubernetes. Статья интересная, много куда попала и вызвала кучу обсуждений. Вот основные тезисы:
- они используют флот машин с docker контейнерами под управлением AWS Auto Scaling groups;
- каждая группа запускает машины с заданным набором контейнеров;
- масштабирование достигается за счет групп;
- трафик распределяется за счет AWS ELB;
- у k8s большой оверхед и он очень сложный;
- вместо service mesh они используют просто виртуальную сеть AWS.

В целом набор групп + ELB это обычный сценарий разворачивание ландшафта поверх IaaS, и не совсем понятно, в чем тут особенность. Возможно, Ably крутится в среде стартапов, где неиспользование k8s является странным и старомодным, но на деле это вполне обычная архитектура. K8s действительно дает оверхед как по ресурсам, так по биллингу, однако вот что меня удивило:

1. на всех машинах сервисы запускаются в контейнерах, ОС и остальное - одинаковы. Не очень понятно, почему в угоду экономии отказались от K8s, но не отказались от контейнеров. Т.к. для каждой задачи запускается своя группа машин, было бы логичным собрать оптимизированные под эти задачи темплейты, и запускать там приложения без дополнительных уровней абстракции.
2. при старте докер скачивает контейнеры - опять же, почему бы сразу не положить контейнеры в темплейты?
3. автор много раз подчеркивает заоблачную сложность k8s - на деле это обстоит не так, особено если речь про managed k8s. Задача построения ландшафта внутри k8s обычно проще, чем построение того же на основе IaaS решений конкретного облака.
4. service mesh используется не для реализации сети внутри k8s (с чем оркестратор и сам справляется), а для принудительного внедрения сетевых политик в гетерогенную среду (причем это не обязательно k8s, некоторые service mesh, как cilium, работают также поверх ВМ), а также для упрощения внедрения сетевых и инфраструктурых практик (TLS, observability, circuit breaker, всевозможный аудит и т.п.).

Также много интересного было высказано в обсуждениях к статье, например в этом на HN. Если отбросить все комментарии про неработающий сайт (который не выдержал наплыв читателей), то было еще много по существу, например:
- k8s на деле не такой сложный, как описывает автор, комментаторы дали конкретные примеры;
- проблема биллинговой неэффективности не в больших нагрузках, а в неравномерной утилизации ресурсов. Здесь k8s помогает доутилизировать ресурсы ВМ, т.к. более равномерно распределяет нагрузку на ноды;
- запуск множества маленьких ВМ вместо подов k8s менее эффективен, т.к. приходится каждый раз тратить часть ресурсов ВМ на ОС, когда в случае нод k8s более крупного размера эта цена платится один раз на ноду, а контейнер переиспользует ядро для подов;
- вендор лок на AWS может ударить куда сильнее, чем вендор лок на k8s.

В качестве итога: k8s как и любой другой инструмент подходит не каждому, и если внедряемый инструмент не решает никакой проблемы, то он сам становится проблемой. K8s хорошо подходит для достаточно сложных и гетерогенных ландшафтов, и особенно хорош как платформа для реализации крупных инфраструктур с болшим количеством разных сервисов и проектов. Для запуска класической трехзвенки с горизонтальным масштаброванием есть инструменты куда проще - вроде Heroku или GCP App Engine - не стоит их недооценивать. Как и не стоит стесняться запускать свои нагрузки поверх флота ВМ безо всякой сложной оркестрации. Что стоит делать - так это хорошо понимать свой текущий инструментарий, чтобы выжать из него максимум производительности за минимум денег.

76% компаний готовы к мультиклауду - так гласят результаты опроса от HashiCorp. Разве что стоит сказать, что эти 76% опрошенных (~3200 компаний) - из тех, кто попал в рассылку HashiCorp - а это достаточно специфический сектор рынка.

Однако результаты интересные - например то, что опрошенные считают инструменты HashiCorp более “стратегической” технологией, чем Kubernetes. Также большинство склоняется к мультиклауду из-за оптимизации биллинга. Однако многие отмечают, что сейчас для этого не хватает как инструментов, так и навыков.

В целом получился приятно оформленный и интересный отчет, но репрезентативность под вопросом.

Любопытная идея использовать object storage вместо serverless базы данных. В статье помимо этого дан хороший обзор присутствующих на рынке объектных хранилок, начиная от AWS S3, и до экзотических.

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

Но с другой стороны, недавний релиз R2 - экстремально дешёвого хранилища от Cloudflare, совместимого с S3 - делает эту идею ещё более лакомой.

А где вы храните свои бессерверные JSONы?

Попалась отличная статья про устройство L4 балансировщика нагрузки в Яндекс.Облаке.

Выглядит как хорошо продуманное с точки зрения архитектуры и красиво реализованное решение, хотя много нюансов осталось за кадром. Идея разделить структуру ЛБ на три уровня - config plane, control plane и data plane - позволяет как лучше справляться с гетерогенными нагрузками, так и удобно в плане организации логики отдельных частей и доставки изменений.

Буду следить за развитием проекта и ждать публичного L7 балансировщика.

Работая с геораспределенными системами, я часто думаю о механизмах отказо- и катастрофоустойчивости. И если с ними в рамках одного региона (один или группа ЦОД) все не очень сложно, то когда в дело вступает мультирегиональная доступность, начинается интересное.
Обычно это интересное связано с глобалной балансировкой нагрузки (GSLB), построенной на двух столпах - DNS и BGP. И если первый относительно понятный, то со вторым у многих возникают проблемы. Как минимум потому, что толковых материалов на тему не так много.

Нашел просто замечательную статью, в которой на примерах описано, что такое BGP Anycast, как он работает и как его самостоятельно настроить (спойлер: вам понадобится от 256 белых IP адресов). Anycast позволяет вашему запросу магическим образом прийти на ближайший к вам GSLB облачного провайдера - а не на случайный как в случае DNS Round-Robin, где ни о какой оптимальности пути речи не идет. А еще в статье есть примеры, как сломать весь интернет через BGP, но это уже совсем другая история…

Наткнулся на прекрасное - интерактивная шпаргалка по продуктам GCP.
Выглядит немного неоднозначно, но штука реально удобная.
Если знаете шпаргалки по другим облакам - накидайте в комментарии.

Пока собираю материал на интересную заметку, вот вам новость.
Google Cloud запустил очередной learning path.
Неплохая возможность изучить интересующее направление (их там много) и поделать бесплатные лабы.
Не реклама, но как GDE рекомендую. В свое время проходил такой, когда готовился к сертификации PCA, в этот раз записался на Digital Leader (что бы это не значило). В общем, если есть свободное время, можно потратить его с пользой.

Посмотрел очень неплохое видео MCS (ныне VK Cloud) об их инфраструктуре и работе K8s на ее основе.
Здесь нет rocket science, однако очень подробно и структурированно рассказано про то, из чего состоит инфраструктура облачного провайдера, и как компоненты используют друг друга, ну и конечно же, как поверх IaaS облака работает K8s сервис.
Особенно интересно это смотреть, зная изнутри, как работает совершенно другой облачный провайдер, а работает он очень похожим образом (спойлер: как и все остальные).
Очень советую, если хотите примерно понимать, из чего состоит облако внутри, с примерами конкретных технологий и продуктов.

Читал postmortem про недавний сбой Cloudflare (спойлер: it's always BGP), и наткнулся на интересную статью про L4 балансировщик нагрузки Cloudflare - Unimog.

Вообще, распределенные балансировщики нагрузки - это облачная технология, которая восхищает меня больше всего. И статья меня очень порадовала. Здесь очень простым языком рассказывается, как реализованы их балансировщики, обслуживающие anycast TCP и UDP запросы на флот серверов. Причем, для балансировщиков не выделены свои машины, они живут на тех же серверах, что и остальное. Также дано понятное объяснение, как и для чего используется eBPF, как и набор интересных решений по маршрутизации пакетов между серверами, обновлению конфигураций при добавлении и отключении серверов, динамической балансировке, поддержке долгих (несколько суток) TCP сессий, оптимизации трафика и сравнение с альтернативами.

Статья прям очень классная, но большая. Если интересуетесь тем, как ваш трафик приходит на сервера, и как провайдеры выдают много девяток - читать обязательно.

Прочитал серию статей про то, как OpenAI строят инфраструктуру для своих вычеслений. Тема довольно интересная, а сегодня особенно актуальная, и мне всегда было любопытно, как это делают “большие” игроки.

К моему удивлению, при своих объемах OpenAI запускает вычисления на кластере Kubernetes, правда с большим количеством доработок как в самом кластере, так и на уровне инфраструктуры под ним и упрощения доступа к железу. Про эти оптимизации особенно подробно в последних статьях.
Более того, я не слышал, чтобы кто-то имел кластера такого размера (более 7,5К нод на 2021 год, вероятно сильно больше сейчас).
В блоге дают неплохую аргументацию тому, почему выбран именно Kubernetes, а например не запуск задач на отдельных ВМ или на каком-то самодельном оркестраторе - это тулинг и удобства, который из коробки дает кубер, упрощение менеджмента флота машин, и подобное.

Увлекательное чтение, особенно почитать про ограничения, с которыми столкнулись на таких объемах нод (а значит и объеме данных, проходящих через control plane и хранящихся в etcd), и сложности нетворкинга.

(2021) Scaling Kubernetes to 7,500 nodes
(2018) Scaling Kubernetes to 2,500 nodes
(2016) Infrastructure for deep learning

В целом в блоге много интересного про управление ресурсами, оптимизацию и масштабирование.

Yandex Cloud выпустил первую серию (видео)подкаста про то, как устроено их облако, а конкретно этот выпуск - про платформу данных. Немного бизнесово, но интересно и познавательно, советую послушать на досуге.

Вообще Яндекс часто радует хорошими техническими докладами про внутрянку облака, как на конференциях, так и просто на своем канале. Чтобы не быть голословным:
- конференция Яндекса про инфраструктуру облака.
- доклад с Highload про масштабирование (а на самом деле подробный разбор базовых компонентов облака, очень круто для новичков в теме).

Вообще мне очень нравится, как они развивают свой продукт, так и спин-оффы. И главное - делятся опытом.