Самое интересное — в нашей подборке новостей :)

🔸 Яндекс открывает ежегодную программу грантов Yandex Open Source, в рамках которой будет награждать разработчиков интересных и важных опенсорс-проектов. Все условия — здесь.

🔸 Языку программирования Go исполнилось 14 лет! У Go был отличный год: два полнофункциональных релиза и другие важные вехи. Подробнее о них — в блоге.

🔸 27 и 28 ноября можно бесплатно посмотреть трансляцию из главного зала конференции Highload++. Потребуется регистрация.

🔸 Релиз Git 2.43. Это последний выпуск 2023 года. Узнать об основных изменениях можно в блоге, а узнать про вообще все изменения релиза — в примечаниях к релизу.

🔸 Релиз Kyverno v1.11. Kyverno — это механизм политики с открытым исходным кодом для Kubernetes, который позволяет определять, проверять и применять политики для кластера. На официальном сайте информации о релизе нет, но она есть на сайте CNCF. Узнать обо всех изменениях — можно здесь.

Всем DevOps и хорошей недели! 🖖

#новости

Теперь можно не только прочитать, но и посмотреть!

Мы, конечно, писали про серию статей «Container security fundamentals» (недавно, кстати, вышла 6 часть) — но, оказывается, есть еще и видео.

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

Всем DevOps! 🖖

Сегодня — немного про нагрузочное тестирование. Что это такое, когда нужно, какие инструменты можно использовать и всё такое. Приятного чтения :)

Что такое нагрузочное тестирование

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

Иначе говоря, нагрузочное тестирование позволяет ответить на вопросы:

* Какое количество пользователей и в течение какого времени может выдержать система?
* Как система справляется с резким наплывом пиковой нагрузки?
* Какие компоненты системы являются узкими местами?
* Какие аппаратные характеристики необходимы, чтобы система могла выдерживать требуемое количество пользователей?
* Что случится с системой, если какие-то из её элементов выйдут из строя? Смогут ли они сами вернуться в работу и сколько времени это займет? Будет ли система при этом работоспособна?

1 / 3

#лонгрид

Как измерить?

Поскольку мы хотим работать с нагрузкой, нам нужно ее как-то измерять. Единиц измерения две:

Первая — rps, число запросов к веб-серверу. Очень простая с точки зрения инфраструктуры единица. Но недостаток ее в том, что она не отражает реальный мир, потому что с системой работают пользователи, то есть реальные люди. Люди могут присылать по несколько разных запросов одновременно с одной странички, но не каждую секунду, плюс на каждой страничке это число может быть разным.

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

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

Автоматизировать действия пользователя — не самая простая задача, в условиях современного веба. Да, мы можем слать запросы. Но на запросы приходят ответы. В них содержатся, например, куки. Если отправлять запросы без этого поля, то моделирование реальной нагрузки будет некорректным. Значит во время составления сценария это поле нужно будет перехватить и корректно отправить в следующем запросе. И таких полей и нюансов в работе каждого ресурса может быть огромное множество. Поэтому для составления грамотных сценариев затрачивается серьезное количество ресурсов.

Ход тестирования

Цикл нагрузочного тестирования состоит из нескольких пунктов.

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

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

2 / 3

#лонгрид

Инструменты для тестирования

В самом простом случае инструменты для нагрузочного тестирования позволяют отправить множество запросов. По мере развития, в инструменты добавлялись возможности анализа и более производительные движки для отправки запросов. Наиболее популярные инструменты это:

Apache Jmeter

Может измерять производительность и тестировать статические и динамические веб-приложения. Apache Jmeter можно использовать для моделирования большой нагрузки на сервер, группу серверов, сеть или объект для проверки его прочности или для анализа общей производительности при различных типах нагрузки.

K6

Современный инструмент нагрузочного тестирования с использованием Go и JavaScript. Основные особенности:

* Настраиваемая генерация нагрузки. Даже машины более низкого уровня могут имитировать большое количество трафика.
* Полнофункциональный API. API сценариев оснащен функциями, которые помогут имитировать реальный трафик приложения.
* Встроенный движок JavaScript.
* Поддержка нескольких протоколов. HTTP, WebSockets, gRPC.
* Гибкое хранение и визуализация метрик Сводная статистика или детальные показатели, экспортируемые в службу по вашему выбору.

Яндекс Танк

Фреймворк для нагрузочного тестирования. Под капотом он может использовать разные движки, например:

jmeter — java
phantom — C++
pandora — go

Из коробки работает самый простой движок, он оперирует показателем rps а не vu как jmeter. В нем нет сценариев, есть просто список url которые мы грузим. Преимущество Яндекс Танка в том, что за несколько минут можно дать серьезную нагрузку, при этом практически ничего не настраивая.

3 / 3

#лонгрид

Нагрузочное тестирование

Часть 1: что такое нагрузочное тестирование

Часть 2: как измерить и ход тестирования

Часть 3: инструменты для тестирования

Дополнительные материалы:

▪️ Небольшой бесплатный курс от Yandex Cloud про нагрузочное тестирование для DevOps-инженеров

▪️ Доклад с HighLoad «Нагрузочное тестирование с K6»

▪️ Сравнение нескольких инструментов для нагрузочного тестирования

▪️ Статья «Стенд для нагрузочного тестирования: от DEV до PROD» — личный опыт, но может быть интересно

P.S. Желаем классной пятницы и отличных выходных! 🔥

#лонгрид

Новостей немного, но они есть :)

🔸 Новые экспериментальные функции Gateway API v1.0. Недавно Gateway API объявил о выпуске общедоступной версии v1.0 , что стало важной вехой для проекта. Кроме стабилизации некоторых основных функций API был добавлен ряд новых интересных экспериментальных функций — Backend TLS Policy, HTTPRoute Timeouts, поддержка веб-сокетов, HTTP/2 и многого другого. Подробности здесь.

🔸 Срок поддержки ядра Linux 6.5 истёк, всем рекомендуется перейти на ядро Linux 6.6 LTS. В конце октября Линус Торвальдс представил первый стабильный релиз ядра Linux 6.6. Релиз Linux 6.7 намечен на конец года или после новогодних праздников в начале 2024 года.

🔸 Релиз Grafana Agent v 0.38. Grafana Agent — это инструмент для сбора метрик, логов и трейсов. В этом релизе улучшили River, язык конфигурации, используемый в режиме Grafana Agent Flow, представили новые компоненты OpenTelemetry, улучшили сбор логов и еще по мелочи. Вся информация по релизу — здесь.

🔸 Kyverno завершили сторонний аудит безопасности. Проект Kyverno сообщил о завершении стороннего аудита безопасности. Аудит был проведен Ada Logics в сотрудничестве с Open Source Technology Improvement Fund и профинансирован Cloud Native Computing Foundation.

Если мы пропустили что-то важное, обязательно дополняйте в комментариях :)

Всем DevOps! 🖖

#новости

Возможно, вы знакомы с nxs-universal-chart — open-source универсальным Helm-чартом. Про него были статьи на Хабре эта и эта.

Еще есть видео-демо про то, как работать с nxs-universal-chart :)

В общем, если вы им пользуетесь или хотите начать пользоваться, то появился отдельный канал про nxs-universal-chart. В нем будут анонсы релизов, новых функций, исправлений ошибок и информация про мероприятия.

Еще есть чат — там вам ответят не только другие пользователи, но и авторы nxs-universal-chart.

#open_source

One more blog 📝

Брендан Грегг — всемирно известный эксперт в области производительности компьютеров. Автор инструментов Systems Performance и BPF Performance Tools (Addison-Wesley), создал широко используемые инструменты, методологии и визуализации производительности, включая Flame Graph.

Короче, Брендан Грегг супер крутой. Если вам интересны сети, датацентры и все такое низкоуровневое — вам точно понравится его блог. Там посты аж с 2005 года доступны, впечатляет, одним словом :)

P.S. А еще совершенно легендарное видео «Shouting in the Datacenter» и да, там Брендан Грегг кричит на диски. Почему, а главное зачем, понятно из видео, но на всякий случай есть статья «Why You Shouldn't Shout in the Data Center».

P.P.S. Из недавнего он еще в фильме «eBPF: Unlocking the Kernel» участвовал.

Всем DevOps! 🖖

#блог

Б значит не Безумие, а Безопасность: часть 2 — перезагрузка

Алексей, DevOps-инженер компании Nixys, делится реальным опытом и во второй части — продолжает рассказ про проект, который пришел с таким ТЗ:

* Замкнутый контур;
* Отсутствие CVE во всех используемых продуктах;
* Контроль безопасности уже имеющейся инфраструктуры;
* Контроль доступа до среды;
* Автоматизация процессов.

Но как быть, если ваша инфраструктура располагается в Kubernetes? Как быть, если вы используете managed решение? Какие подходы для организации безопасности будут применимы?

Под катом — про это, а еще про Managed Service for Kubernetes и Yandex Cloud, Kyverno, Tetragon, Falco и многое другое.

Приятного чтения!

Ого, это что — понедельничные новости в понедельник?

🔸 Релиз Kubernetes 1.29. 13.12 состоялся последний релиз k8s 2023 года. Этот выпуск состоит из 49 улучшений. Из этих улучшений 11 перешли в стабильную версию, 19 — в бета-версию и 19 — в альфа-версию. Больше подробностей — в нашем предыдущем посте или в блоге Kubernetes.

🔸 Релиз Flux v2.2.0. Flux — это инструмент для синхронизации кластеров Kubernetes с источниками конфигурации (такими как репозитории Git и артефакты OCI) и автоматизации обновлений конфигурации при появлении нового кода для развертывания. Подробную информацию об улучшениях можно найти в блоге Flux.

🔸 Взлом инфраструктуры MongoDB. В инфраструктуре компании MongoDB, развивающей одноимённую СУБД и облачный сервис MongoDB Atlas, выявлены следы взлома. Судя по уведомлению, направленному клиентам компании, злоумышленники смогли получить доступ к некоторым корпоративным системам, на которых, среди прочего, были размещены сведения об учётных записях клиентов и контактные данные пользователей.

🔸 GitLab Security Release: 16.6.2, 16.5.4, 16.4.4. 1 уязвимость уровня High (для Enterprise Edition), 6 уязвимостей уровня Medium (Enterprise Edition и Community Edition) и 1 уязвимость низкой степени серьезности (Enterprise Edition). GitLab рекомендует обновить уязвимые версии как можно скорее.

🔸 Grafana k6 v0.48.0 release. Многочисленные критические изменения, новая k6 new подкоманда для создания тестового сценария, новый k6/experimental/fs модуль для взаимодействия с файлами, поддержка регулирования ЦП и сети для модуля браузера k6 и многое другое. Кстати, упоминали этот инструмент в серии постов про нагрузочное тестирование.

Всем DevOps и хорошей недели! 🔥

P.S. До Нового года осталось 13 дней🎄🎁

#новости

Kubernetes scheduler simulator — интересный проект, позволяющий познакомиться с принципом работы kube-scheduler через простенький UI. Особенно полезно, если хотите поковыряться во внутренностях шедулера, разобраться как он работает и попробовать внести изменения в исходный код и проверить их работу на практике.

Для начала работы:

git clone git@github.com:kubernetes-sigs/kube-scheduler-simulator.git
cd kube-scheduler-simulator
make docker_up 

Симулятор будет доступен по адресу http://localhost:3000.

P.S. Интересная статья про создание дополнительного kube-scheduler’a с кастомным набором правил планирования

#open_source