Долгожданный релиз containerd 2.0 предлагает множество новых функций, включая поддержку плагинов для проверки образов и интеграцию с OpenTelemetry. Это первое мажорное обновление с 2017 года.

Проверка готовности приложения к работе в реальном ненадежном мире. Часть 2 #habr
https://habr.com/ru/companies/slurm/articles/857144/
Tags: go, golang, приложение, tutorial
Author: Hedgehog_art (Слёрм)

Вышел Jaeger v2. Новая версия интегрирует OpenTelemetry и предлагает пользователям улучшенные возможности обработки данных и упрощённое развёртывание: https://goo.su/GuMQln

CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async. Часть 11. Сравнение видов многозадачности

В прошлом посте было дано определение 2м основным видам многозадачности используемых в Computer Science. В этом посте хочется дать чуть больше пояснений и порассуждать где и почему они применяются.

Вытесняющая многозадачность реализована на уровне ОС, практически все системы которые я знаю реализуют подход с вытесняющей многозадачностью. Этот подход позволяет пользователю ощущать что все запущенные программы на компьютере работают параллельно (при наличии ядер процесссора, помним про SMP). А если не параллельно то как минимум конкуррентно, то есть каждой задаче выделяется ресурс "поработать" а дальше ОС останавлвает программу чтобы выделить ресурсы соседнему процессу.

Какие основные плюсы и минусы есть у данного подхода к мультизадачности:
- Плюс: невозможна ситуация когда ресуры системы голодают (starvation) в ожидании работы. Планировщик всегда найдет для процесса поток и ядро процессора для исполнения команд.
- Минус: наличие планировщика так или иначе дает оверхед.

Если переходить к кооперативности то тут основной плюс в том что переключениями может управлять разработчик (Ну или рантайм языка программирования, т.е нечто на уровне самой программы а не ядра ОС). И планировщика может и не быть вовсе. Но имея такую силу в своих руках можно получить ситуацию когда мы пишем кооперативный код который с легкостью заблокирует всю программу и не передаст возможность делать полезную работу дргим файберам в рамках процесса. По сути программа зависнет и придется ее перезапускать. Чуть менее критичная ситуация - starvation, когда файбер не передает ресурсы другим файберам хотя ему они сейчас не нужны (например он заблокировался на IO).

Так зачем вообще нужно использовать кооперативную многозадачность? Давайте использовать нативные треды операционной системы и не будем париться? За нас все сделает ОС. Такой подход вполне имеет право на жизнь, но он является достаточно дорогим с точки зрения ресурсов. Треды дороже с точки зрения памяти + ими управляет ОС и переключения между ними очень дорогие. При этом помним что при разработке серверных программ большое количество времени программа проводит в состоянии ожидания ввода-вывода и для эффективной утилизации ресурсов и комфортного пользовательского опыта важно чтобы во время простоя могли выполняться другие задачи на железе.

Для того чтобы программисты могли писать IO bound программы эффективнее разработчики языков и начали привносить в рантаймы различные легковесные примитивы. Но что произойдет в программе если мы сделаем блокирующий вызов (например запрос к БД)? Зависит от того как реализован рантайм конкретного языка программирования. Где то мы в ответ получаем Promise и продолжаем выполнение программы и заблочиться на нем в ожиданиии результата спустя время. В других языках реализованы специальные планировщики которые умеют детектировать файберы которые заблочились на IO и их можно безопасно снять с реального потока ОС и выделить время другим файберам. То есть по сути получаем некоторый микс из двух подходов, взяли лучшее из каждого.

А как быть с CPU Bound задачами? Никак, CPU задачи не масштабируются с помощью файберов. Чтобы разобраться почему приглашаю читать предыдущие посты с обсуждением процессора😊

На этом на сегодня всё, спасибо что читали, до встречи в следующих постах.😇

Я даже не знаю как описать масштаб бедствия, потому что когда это всё смотреть решительно непонятно 🌝

Выложены доклады с USENIX Security '24 в количестве 415 штук

Плейлист
https://www.youtube.com/playlist?list=PLbRoZ5Rrl5ldQ2K_dpmPKHEyRgyf5JSxd

Программа
https://www.usenix.org/conference/usenixsecurity24/technical-sessions

65k nodes in k8s
https://cloud.google.com/blog/products/containers-kubernetes/gke-65k-nodes-and-counting

Из прикольного, чтобы достичь этого, конечно же выкинули etcd из куба для этого. И взяли Spanner. На этом можно и закончить, в целом, это кажется главная причина с чем нужно постоянно приседать, не только на больших кластерах, но и там где интенсивность создаваемых ресурсов высокая.
Остальные вещи, вроде тюнинга secondary boot disk, или использование kueue/jobset контроллеров, в контексте скейлинга до 65к хостов роли не играют особо. Это скорее про скорость шедулинга ворклоада.
Знаю, что яндекс облако пыталось заменить etcd на ydb (те сделать api etcd совместимое), но что-то, как всегда, пошло не так.

Какие планы на 19 ноября? Приходи на OPS Talk в офис Сбера!
 
Открылась регистрация на митап для инженеров сопровождения и DevOps-специалистов «OPS Talk by Sber: от разработки до инцидента».

Вместе со спикерами из Сбера, СберТеха и HFLabs поговорим о сопровождении IT-систем, DevOps- и SRE-практиках в уютном офисе на Кутузовском проспекте, а также онлайн в прямом эфире.
 
В программе 3 доклада, интерактивы и подарки, пицца-брейк, много новых знакомств и общения!
 
👉🏻Подробная программа и регистрация – здесь.
 
И поторопись – количество очных мест ограничено!

Red Hat объявила о передаче набора инструментов для работы с контейнерами, включая Podman, Buildah и Skopeo, под управление Cloud Native Computing Foundation: https://goo.su/nK98BDU

Это обеспечит повышение прозрачности разработки, поддержку открытых стандартов и активное участие сообщества в развитии инструментов.

⚒️ Создание кастомного балансировщика нагрузки на Go для gRPC с приоритизацией адресов

Разработчик из VK делится опытом создания кастомного балансировщика нагрузки на Go для gRPC, который использует приоритеты адресов для выбора наилучшего соединения.

Это решение позволяет гибко управлять распределением клиентских запросов между серверами с разными уровнями доступности и обеспечивает подключение к оптимальному ЦОД с минимальными задержками.

👉 Читать

Учел ваши пожелания и собрал все посты по теме многозадачности и производительности в один пост. Приятного чтения, дальше больше, это еще далеко не конец😊

🔹Многозадачность на уровне железа и OS / Kernel Space

1. Многозадачность в OS. Введение.
2. Процессор и его роль в многозадачности
2.1. Про Hyper Threading
3. Процессы. Начало
4. Процессы в Linux
5. Потоки. Начало
6. Потоки в Linux
7. Модели ввода-вывода. Универсальная(блокирующая) модель ввода-вывода
8. Multiplexed IO
9. Asynchronous IO

🔹Легковесные потоки в User Space / Многозадачность в языках программирования

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

Тем временем, я как-то упустил важное обновление https://prometheus.io/blog/2024/11/14/prometheus-3-0/

KubeCon + CloudNativeCon North America 2024 закончился несколько дней назад.
Делимся плейлистом.

Пиарим проекты подписчиков! Кстати, если вы пишите что-то полезное и нужны звезды на гитхабе или просто хочется поделиться с миром - приносите!

LazyJournal - это терминальный пользовательский интерфейс (TUI) для journalctl, логов файловой системе и контейнеров Docker для быстрого просмотра и фильтрации, написанный на языке Go с использованием библиотеки gocui.

— Простая установка, для запуска достаточно загрузить в систему один исполняемый файл без зависимостей.
— Проект вдохновлен работами Jesse Duffield, по этому интерфейс будет знаком всем тем, кто уже использует LazyDocker и LazyGit.
— Для всех журналов присутствует возможность динамической фильтрации вывода с поддержкой нечеткого поиска (поиск всех фраз, разделенных пробелом в любом месте строки) и регулярных выражений (в стиле fzf и grep), а также подсветкой найденных слов.
— Позволяет получить список всех доступных журналов юнитов из journalctl (используется для чтения логов из подсистемы systemd).
— Возможность просматривать все доступные лог-файлы из каталога /var/log с сортировкой по дате изменения (например, для Apache, Nginx или СУБД), включая доступ к архивным логам.
— Поддержка логов контейнеров Docker.
— Проект будет полезен в первую очередь для системных администраторов Linux, больше не нужно вручную искать журналы в системе и каждый раз вызывать grep.

GitHub: https://github.com/Lifailon/lazyjournal

Методология Twelve-Factor App теперь доступна как Open Source.

Сам манифест выложен на GitHub. Ожидается, что это привлечёт сообщество к совместной работе и поможет актуализировать принципы.