Прим. перев.: о так называемых плагинах хранилищ «вне дерева» Kubernetes (Out-of-Tree CSI Volume Plugins) мы впервые рассказывали в своём обзоре релиза K8s 1.9, где эта фича появилась в статусе альфа-версии. Автор нового материала — Anoop Vijayan Maniankara (ведущий DevOps-инженер финской компании Tuxera) — собрал ключевые сведения об идеях и устройстве CSI, что помогает быстро познакомиться с новой концепцией, которая, как утверждают некоторые наши сотрудники, «будет the next big thing». Для более подробного и технического изучения CSI в конце статьи приведены полезные ссылки, среди которых я особенно выделю презентацию одного из авторов этой спецификации (Jie Yu). Но начать всё равно стоит с «общей картины»…



Container Storage Interface (CSI) — инициатива, призванная унифицировать интерфейс хранилищ, таких как Ceph, Portworx, NetApp и т.п., в системах оркестровки контейнеров: Kubernetes, Mesos, Docker Swarm, Cloud Foundry и других. Идея в том, чтобы реализация одного CSI производителем хранилища гарантированно работала со всеми этими системами.

Здравствуйте, коллеги.

Мы только что отдали в перевод интересную книгу Брендана Бёрнса, рассказывающую о паттернах проектирования для распределенных систем

Кроме того, у нас уже полным ходом идет перевод книги "Mastering Kubernetes" (2-е издание) и готовится к выходу в сентябре авторская книга о Docker, о которой обязательно будет отдельный пост.

Полагаем, что следующая остановка на этом пути — книга о Prometheus, поэтому сегодня предлагаем вашему вниманию перевод небольшой статьи Бьёрна Венцеля о тесном взаимодействии Prometheus и Kubernetes. Не забудьте пожалуйста поучаствовать в опросе.

Kubernetes требует, чтобы каждый контейнер в кластере имел уникальный, маршрутизируемый IP. Kubernetes не назначает IP-адреса сам, оставляя эту задачу сторонним решениям.

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

28 мая на проходившей в рамках фестиваля РИТ++ 2018 конференции RootConf 2018, в секции «Логирование и мониторинг», прозвучал доклад «Мониторинг и Kubernetes». В нём рассказывается об опыте настройки мониторинга с Prometheus, который был получен компанией «Флант» в результате эксплуатации десятков проектов на Kubernetes в production.



По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде. Поехали!

В основу этой статьи легла наша внутренняя документация для DevOps-инженеров, объясняющая, как работает Prometheus под управлением Prometheus Operator в разворачиваемых и обслуживаемых кластерах Kubernetes.



С первого взгляда Prometheus может показаться достаточно сложным продуктом, но, как и любая хорошо спроектированная система, она состоит из явно выраженных функциональных компонентов и по сути делает всего три вещи: а) собирает метрики, б) выполняет правила, в) сохраняет результат в базу данных временных рядов (time series). Статья посвящена не столько самому Prometheus, сколько интеграции этой системы с Kubernetes, для чего мы активно используем вспомогательный инструмент под названием Prometheus Operator. Но начать всё же необходимо с самого Prometheus…

Хочу поделиться очень простым и эффективным методом ресайза изображении, который работает за константное время относительно размера исходного изображения и дает неожиданно качественный результат. Метод применим для любых языков и приложений.

Для начала давайте порассуждаем логически. Если вы делаете ресайз изображения, наверное вы хотите чтобы результат хотя бы отдаленно напоминал оригинал. Для этого нужно учесть как можно больше информации из исходного изображения. Вы слышали о методе «ближайшего соседа»? В этом методе для каждой точки конечного изображения просто берется какая-то одна точка из исходного изображения в неизменном виде.

Уменьшение изображения 4928×3280 до 256×170 ближайшим соседом.

Рекомендую смотреть примеры из статьи в браузере в масштабе 100% и без ретины. То есть по максимуму исключить ресайз при просмотре.

Результат не представляет ничего хорошего. Изображение дерганое, зернистое, даже трудно понять что на нем изображено. Особенно если на исходном изображении было много мелких деталей или оно само было зернистым. Почему так получается? Потому что в конечном изображении было учтено очень мало информации из исходного. Если условно отметить на исходном изображении те точки, которые попадают в конечное, получится вот такая сеточка:

Точки, которые попадут в конечное изображение размером 20×13.

Некоторое время назад я рассказывал о «Профилировании и отладке Django». После выступления я получил много вопросов (как лично, так и по email), с парой новых знакомых мы даже выбрались в бар, чтобы обсудить важные проблемы программирования за кружечкой отменного эля, со многими людьми я продолжаю общаться до сих пор.

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

Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.

IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.

Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:

• RFC 791 – Internet Protocol
• RFC 793 – Transmission Control Protocol

У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.

I2p — это сеть со специализацией на анонимности внутрисетевых ресурсов, этим она отличается от сети tor, основной задачей которой являются не внутренние ресурсы, а построение безопасного доступа к интернету. Зная об этих двух особенностях, люди могут гораздо эффективнее работать в обеих сетях.

В i2p ты можешь заниматься множеством вещей: посещать и создавать сайты, форумы и торговые площадки, принимать почту, чатиться и скачивать торренты, и многое многое другое. Программа i2pd способна работать с большим числом программ и сервисов.

Павел Филонов (во время выступления работал в Positive Technologies)

В данном докладе я хочу поговорить о пересечении RabbitMQ и Pipeline архитектуры, и о том, как оно связанно с работой нашей компании.

Сначала немного в качестве пролога. Это приятная часть.



Сценка, разворачивающаяся в будний день в офисе, наводит нас на очень приятное размышление. Перед нами встает шикарная задача, новая система. Мало что так сильно будоражит ум инженера, как просьба разработать новую систему. Не починить что-то старое, не адаптировать что-то старое, а именно что-то создать, в каком-то смысле практически с нуля.

Вместе с такой задачей приходит и целая серия проблем.

Мало кто знает, что в ядре Linux есть необычные и весьма полезные инструменты для отладки и тестирования. В этой небольшой статье я хочу поделиться описанием трассировщика ввода-вывода.

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