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

Это вторая часть из серии статей об обновлении кластера Elasticsearch без простоев и с минимальным воздействием на пользователей. Как упоминалось в первой части, необходимо было обеспечить плавный переход между двумя версиями системы, при этом сохраняя возможность отката.

Мы уже как-то рассказывали о базе данных KeyDB — форке Redis, разработка которого началась в 2019 году. Проект распространяется под свободной лицензией BSD, и у него уже почти 6k звезд на GitHub. Авторы в свое время столкнулись с проблемами производительности оригинала и пошли хардкорным путём: взяли всё в свои руки и привнесли много нового как в части многопоточности, так и в других областях.

В статье делимся еще одним положительным опытом замены Redis на KeyDB.

Прим. переводчика: автор статьи рассказывает о причинах, побудивших его команду обновить кластер Elasticsearch размером более 3 петабайт, и приводит результаты замеров работоспособности нового кластера в сравнении со старым.

Еще в 2018 году, то есть пять лет назад, в нашем блоге был опубликован пост с описанием нашего кластера Elasticsearch на 400+ узлов. Тогда была затронута важная тема:

Мы решили не обновлять кластер. Хотелось бы, но пока есть более срочные задачи. Да и как именно будет происходить обновление, пока не решено. Один из вариантов — создать новый кластер, а не обновлять старый.

Что ж, долгожданный день обновления, наконец, наступил.

Canary-развертывание используется, чтобы протестировать новую функциональность на отдельной группе пользователей. Группа выделяется по определенному признаку. Тест при этом не должен затрагивать работу основной версии приложения и его пользователей. Нагрузка между двумя версиями приложения должна распределяться предсказуемо. 

Canary-релизы достаточно просто реализуются на уровне Ingress-контроллеров. В статье рассмотрен практический пример настройки таких релизов в Kubernetes на базе Ingress NGINX Controller.

Прим. переводчика: автор статьи предлагает реализацию honeypot'а («приманки») на основе виртуального кластера Kubernetes, чтобы обнаруживать попытки взлома K8s-инфраструктуры. Также в статье рассматриваются отличия низкоинтерактивных и высокоинтерактивных приманок.

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

В первой части серии речь пойдет о том, как собрать простую SSH-ловушку для выявления атак, направленных на среду исполнения.

У большинства популярных DNS-провайдеров есть API, с помощью которого можно управлять записями. Это позволяет автоматизировать заказ и продление SSL-сертификатов через DNS01.

В Kubernetes для работы с сертификатами используется cert-manager. Чтобы заказать сертификат в кластере, нужно объявить ресурс центра сертификации — например, ClusterIssuer, который используются для подписи CSR (запросов на выпуск сертификата). К сожалению, не для каждого DNS-провайдера существует CusterIssuer. Однако cert-manager позволяет написать свою реализацию. У нас такая потребность возникла в проекте одного из клиентов, который пользовался услугами DNS-провайдера REG.RU.

Прим. переводчика: автор статьи рассматривает практические сценарии и примеры организации SSH-туннелей. А для лучшего понимания того, как это работает, графически показывает потоки трафика.

Туннели SSH — это зашифрованные TCP-соединения между клиентами и серверами SSH. Трафик входит с одной стороны туннеля и прозрачно выходит с другой. Изначально этот термин относился к туннелям на виртуальных сетевых интерфейсах TUN/TAP, однако сейчас так обычно называют проброс портов SSH.

В погоне за лучшей или, правильнее сказать, удобной жизнью я начал искать решение, которое помогало бы писать чарты для Kubernetes и лучше разбираться в зависимостях — что, куда и откуда подставляется в созданных чартах. Так я наткнулся на программу под названием Monokle. В ее описании сказано: «Вы сможете составлять чарты, быстро находить какие либо несовместимости или неправильный код, а также деплоить ваши чарты сразу в K8s». Глаза загорелись, я приступил к установке.

Хочу рассказать об интересном эксперименте, суть которого заключалась в развертывании и настройке Kubernetes на двух старых ноутбуках — один из них, кроме того, был с процессором на архитектуре i386. В качестве теоретической основы использовалось руководство Kubernetes The Hard Way, которое по ходу дела пришлось немного доработать, а в качестве системы на хостах — Gentoo (да, вам не показалось). Давайте погрузимся в этот увлекательный хардкор!

Прим. перев.: автор этого материала — Герман Осин, старший архитектор решений в Provectus. Осин сравнивает функциональность восьми UI-инструментов, которые помогают решить проблемы наблюдаемости и мониторинга Apache Kafka. Стоит отметить, что обзор скорее вводный. Он будет полезен для первоначального знакомства с возможностями решений.

Apache Kafka — незаменимый инструмент для обработки данных в реальном времени и отслеживания активности приложений. К сожалению, мониторинг кластеров Apache Kafka и управление ими — непростая задача. Решить ее помогают сторонние коммерческие или Open Source-инструменты с графическим интерфейсом и дополнительными функциями в области администрирования и мониторинга.

В статье представлен краткий обзор таких инструментов.

Статья продолжает наш обзорный цикл о PostgreSQL-операторах для Kubernetes. В первой части мы рассматривали операторы Stolon, Crunchy Data и Zalando. Во второй — KubeDB и StackGres, а также объединили все пять операторов в сравнительную таблицу. В этот раз разбираем решение CloudNativePG, его возможности и особенности, а заодно актуализируем таблицу.

При деплое в Kubernetes часто требуется выкатывать ресурсы в определённом порядке, а иногда и дожидаться готовности сторонних ресурсов. Например, нужно сначала запустить БД, дождаться создания динамического Secret’а сторонним оператором, потом выполнить инициализацию или миграции БД, а уже затем запустить само приложение. 

Рассмотрим, как решать такие задачи с помощью Helm, а также сравним с более быстрым и удобным вариантом, который предлагает Open Source-утилита werf.

Этой ночью представят новую версию Kubernetes. Среди главных изменений на первое место разработчики поставили стабилизацию функции CSI Migration — отказ от внутренних плагинов хранилищ в пользу CSI-драйверов. Также в этой версии устаревший контроллер PodSecurityPolicy заменен на новый PodSecurity Admission.

По традиции в обзоре рассказываем обо всех новых функциях (alpha), а также упоминаем те, что перешли на уровень выше (beta, stable).

Не так давно мы решили добавить в нашу Kubernetes-платформу Deckhouse поддержку Cilium. Однако в процессе разработки модуля cni-cilium неожиданно столкнулись со сложностями, для преодоления которых пришлось даже обращаться к авторам проекта. Теперь, когда модуль успешно доведен до рабочего состояния, можно перевести дух и поделиться ощущениями от полученного опыта и использования этого продукта в целом.

В июне я выступил на объединенной конференции DevOpsConf & TechLead Conf 2022. Доклад был посвящен LINSTOR — Open Source-хранилищу от компании LINBIT (разработчики DRBD). Основной идеей выступления было показать [на примере Kubernetes], как работает и устроен LINSTOR, какие проблемы решает, как его правильно настроить и использовать. Эта статья — основная выжимка из доклада (его полное видео см. в конце).

С появлением snapshot-controller в Kubernetes появилась возможность создавать снапшоты для совместимых с ними CSI-драйверов и облачных провайдеров.

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

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

В статье рассмотрен способ безболезненной миграции базы данных PostrgeSQL c RDS-сервиса в AWS на self-hosted-инстанс с обеспечением отсутствия простоя в работе и максимальной консистентности данных.

С RDS вы получаете один или несколько экземпляров БД, с которыми можно сразу работать — писать или читать данные. При этом нет необходимости самостоятельно разбираться с установкой и изначальной конфигурацией самой БД. Согласитесь, звучит круто! Но на самом деле есть нюансы…

За время, прошедшее с момента предыдущего стабильного релиза Deckhouse, наша Kubernetes-платформа успела получить сертификацию CNCF для версий Kubernetes v1.22 и v1.23, появилась в списках adopters у Prometheus Operator, а еще — в числе пользователей Cilium. Как раз с Cilium связано главное улучшение в новом стабильном релизе платформы.

Какие задачи пользователю нужно выполнять в рамках CI-пайплайна или при локальной разработке? Среди них может быть что угодно, но самое очевидное — это, наверное, запуск линтеров, всевозможных unit-тестов и получение покрытия и других отчетов по результатам выполнения команды. Также при разработке и отладке может быть полезен интерактивный режим, который позволит быстрее разобраться в проблеме или проверить гипотезу.