Хаос-инжиниринг для Kubernetes становится всё популярнее, и это закономерно: ведь такая инфраструктура создавалась быть готовой к тому, чтобы в любой момент что-нибудь «отстрелило». А значит — это замечательное свойство надо проверять в реальных проектах. Благо, уже сегодня можно найти не одно Open Source-решение, помогающее в подобных экспериментах. Представляем вашему вниманию их обзор. Он получился весьма объёмным, поэтому был разбит на две части: в этой мы рассмотрим три популярных проекта...

Прим. перев.: автор этой статьи — ведущий инженер по инфраструктуре в Smarkets, что позиционирует себя как «одну из самых прибыльных [по доходам на каждого сотрудника] компаний в Европе». Работая с большой и чувствительной к мониторингу инфраструктурой на базе Kubernetes, инженеры компании нашли своё счастье с VictoriaMetrics, которая помогла им решить проблемы с Prometheus, возникшие после добавления новых K8s-кластеров. Мониторинг внутренних endpoint'ов и API Kubernetes может быть проблематичным, особенно если стоит задача использовать автоматизированную инфраструктуру как сервис. Мы в Smarkets еще не достигли этой цели, но, к счастью, уже довольно близки к ней. Я надеюсь, что наш опыт в этой области поможет и другим реализовать нечто подобное. Мы всегда мечтали о том, чтобы разработчики прямо «из коробки» получали возможность мониторинга для любого приложения или сервиса. До перехода на Kubernetes эта задача выполнялась либо с помощью метрик Prometheus, либо с помощью statsd, который пересылал статистику на базовый хост, где она конвертировалась в метрики Prometheus. Наращивая применение Kubernetes, мы начали разделять кластеры, и нам захотелось сделать так, чтобы разработчики могли экспортировать метрики напрямую в Prometheus через аннотации к сервисам. Увы, эти метрики были доступны только внутри кластера, то есть их нельзя было собирать глобально. Эти ограничения стали «бутылочным горлышком» для нашей конфигурации, существовавшей до полного перехода на Kubernetes. В конечном итоге они заставили пересмотреть архитектуру и способ мониторинга сервисов. Как раз об этом путешествии и пойдет речь ниже...

На прошлую статью, где мы рассмотрели три оператора PostgreSQL для Kubernetes (Stolon, Crunchy Data и Zalando), поделились своим выбором и опытом эксплуатации, — поступила отличная обратная связь от сообщества*. Продолжая эту тему, мы добавили в обзор два других решения, на которые нам указали в комментариях: StackGres и KubeDB, — и сделали сводную таблицу сравнения. Также за время эксплуатации оператора от Zalando у нас появились новые интересные кейсы — спешим поделиться и ими...

Если в качестве инфраструктуры, где разворачивается приложение, выступает Kubernetes, можно сказать, что существует два способа запуска тестов (и других утилит для анализа кода) в CI/CD: непосредственно в кластере K8s — с помощью отдельных Job или Helm hooks; «снаружи» K8s — например, на сервере сборки/деплоя или локально у разработчиков. Первый подход мы достаточно подробно описывали на интересном примере с базами данных в статье «Как мы выносили СУБД (и не только) из review-окружений в статическое». В этой статье рассмотрен более простой путь — запуск вне K8s-кластера. Делать мы это будем на примере SonarQube-тестов в рамках CI/CD, построенного на базе GitLab с использованием werf...

Прим. перев.: Этот детальный анализ одной, казалось бы, не очень значительной детали в реализации внутри MySQL вызвал закономерные дискуссии о правильности в подходах к разработке известного Open Source-проекта в целом. О том, что же, собственно, выяснил португальский инженер, он повествует в формате, приближенном к детективу… Многие в 2020 году стали жертвой странного феномена восприятия времени, но некоторые системы управления базами данных манипулируют временем гораздо дольше. Впервые я обратил на это внимание, когда мой друг в одном из своих проектов (Accord — популярный бот для Discord) столкнулся со следующим исключением от коннектора MySQL при использовании с EF Core: MySqlException: Incorrect TIME value: '960:00:00.000000' Будучи не слишком сведущим в MySQL (т.к. предпочитаю PostgreSQL по причинам, которые скоро станут очевидными), я на секунду подумал, что неправильным здесь является число часов. Разумно предположить, что значения TIME ограничены 24 часами или что для значений, охватывающих нескольких дней, требуется другой синтаксис — например, 40:00:00:00 будет представлять 40 дней. Но действительность оказалась куда сложнее и запутаннее...

Полтора года назад мы переводили пару статей о том, что такое GitOps. С тех пор этот термин (и сам подход) набрал ещё большую популярность в среде DevOps-инженеров, особенно эксплуатирующих Kubernetes. В то же время у меня появилось свое видение того, какие у него проблемы и каким он должен быть. Поделиться этими мыслями я решил в получасовом видео — смотрите его либо читайте основную выжимку, если предпочитаете текст...

Недавно перед нами встала задача развернуть Dgraph в кластере Kubernetes. В этой статье я поделюсь полученным опытом: с чем мы столкнулись во время деплоя и последующего использования этого приложения в различных окружениях, от dev до production. Что вообще такое Dgraph? Это горизонтально масштабируемая графовая (GraphQL) база данных с открытым кодом, созданная в стартапе Dgraph Labs. Краткое сравнение её основных возможностей с другими подобными решениями приведено здесь. В целом же не буду подробно останавливаться на описании Dgraph, т.к. на хабре уже была подробная статья о причинах появления проекта и особенностях реализации. Для желающих начать практическое знакомство с Dgraph также рекомендую официальную документацию...

K9s предоставляет пользовательский интерфейс терминала для взаимодействия с кластерами Kubernetes. Цель этого Open Source-проекта — облегчить удобную навигацию по приложениям в K8s, наблюдение за ними и управление ими. K9s постоянно следит за изменениями в Kubernetes и предлагает быстрые команды для работы с наблюдаемыми ресурсами. Проект написан на Go, существует уже более полутора лет: первый коммит был сделан 1 февраля 2019 года. На момент написания статьи насчитывается 9000+ звезд на GitHub и около 80 контрибьюторов. Посмотрим, что умеет k9s...

В своей работе я часто сталкиваюсь с новыми техническими решениями/программными продуктами, информации о которых в русскоязычном интернете довольно мало. Этой статьей постараюсь восполнить один такой пробел примером из своей недавней практики, когда потребовалось настроить отправку CDC-событий из двух популярных СУБД (PostgreSQL и MongoDB) в кластер Kafka при помощи Debezium. Надеюсь, эта обзорная статья, появившаяся по итогам проделанной работы, окажется полезной и другим. Что за Debezium и вообще CDC? Debezium — представитель категории программного обеспечения CDC (Capture Data Change), а если точнее — это набор коннекторов для различных СУБД, совместимых с фреймворком Apache Kafka Connect...

В статье рассмотрена проблематика очистки образов, которые накапливаются в реестрах контейнеров (Docker Registry и его аналогах) в реалиях современных CI/CD-пайплайнов для cloud native-приложений, доставляемых в Kubernetes. Приведены основные критерии актуальности образов и вытекающие из них сложности при автоматизации очистки, сохранения места и удовлетворения потребностям команд. Наконец, на примере конкретного Open Source-проекта мы расскажем, как эти сложности можно преодолеть. Введение Количество образов в реестре контейнеров может стремительно расти, занимая больше места в хранилище и, соответственно, значительно увеличивая его стоимость. Для контроля, ограничения либо поддержания приемлемого роста места, занимаемого в registry, принято: использовать фиксированное количество тегов для образов; каким-либо образом очищать образы....