DevOps&SRE Library

kubevirt-benchmark

A comprehensive, vendor-neutral performance testing toolkit for KubeVirt virtual machines running on OpenShift Container Platform (OCP) or any Kubernetes distribution with KubeVirt.

https://github.com/portworx/kubevirt-benchmark

ingress-nginx-migration

The Ingress NGINX Migration is a tool that analyzes Kubernetes NGINX Ingress resources to help with migration planning to Traefik.

https://github.com/traefik/ingress-nginx-migration

crossview

A modern React-based dashboard for managing and monitoring Crossplane resources in Kubernetes. Visualize, search, and manage your infrastructure-as-code with ease.

https://github.com/crossplane-contrib/crossview

diffyml

A fast, structural YAML diff tool with built-in Kubernetes intelligence. One dependency, minimal attack surface, native CI annotations for GitHub, GitLab, and Gitea.

https://github.com/szhekpisov/diffyml

valkey-operator

A Kubernetes operator for deploying Valkey Clusters and managing their lifecycle.

https://github.com/valkey-io/valkey-operator

teleskopio

teleskopio is an open-source small and beautiful Web Kubernetes client.

https://github.com/teleskopio/teleskopio

ayaFlow

A high-performance, eBPF-based network traffic analyzer written in Rust. Designed to run as a sidecarless DaemonSet in Kubernetes, providing kernel-native visibility into node-wide network traffic with minimal overhead.

https://github.com/DavidHavoc/ayaFlow

CloudnativePG: postgres database the modern way https://medium.com/@pascal.toepke/cloudnativepg-postgres-database-the-modern-way-6a3bc9cf5eba

Аудитные логи в облаке — отдельная распределённая система со своими требованиями к надёжности и стоимости хранения, а не «таблица с событиями». Команда MWS Cloud Platform выложила подробный разбор архитектуры своего сервиса: от библиотеки, которую подключают сервисы облака, до хранилища на Apache Iceberg и движка StarRocks, с объяснением, почему выбрали именно такой набор технологий и где спрятаны неочевидные грабли. Полезно всем, кто разрабатывает ИБ-инструменты, работает с большим количеством событий или просто интересуется инструментами безопасности в облаке. Читать статью на Хабре

Vibe Coding a Kubernetes Media Server: What I Learned About AI-First Engineering https://medium.com/@fl.lettner/vibe-coding-a-kubernetes-media-server-what-i-learned-about-ai-first-engineering-88a38224ea5e

О бенчмаркинге, часть 1 Бенчмаркинг занимает значительную часть моей повседневной работы, поэтому важно понимать его основы, типы и ограничения. По сути, это способ оценить производительность системы под нагрузкой. Брендан Грегг в своё время ввёл наглядную терминологию:  * Passive Benchmarking * Active Benchmarking ——— Passive Benchmarking простой и распространённый подход: настраиваешь окружение, запускаешь нагрузку, получаешь на выходе цифры и в дальнейшем ими руководствуешься. Но это как раз тот случай, когда «просто» не значит «лучше». Проблемы таких замеров: * риск измерить не то, что планировалось изначально * непонятно, что именно ограничивает производительность * нельзя отличить систематическое отклонение от шума (об этом позже) * остаемся без ответа, почему получены именно такие результаты * сами бенчмарки могут содержать баги, что останется от нас скрыто

«Бенчмаркаешь A, на самом деле измеряешь B, а выводы делаешь о C». ©

В итоге решения на основе таких данных могут оказаться даже хуже, чем если бы данных не было вовсе. ——— В противовес ему стоит Active Benchmarking (AB). Помимо настройки окружения требуется активное наблюдение за системой во время прогона. Задача понять: * то ли мы меряем, что планировали * что ограничивает производительность * согласуется ли наблюдаемое поведение с нашей моделью системы * что нужно изменить, чтобы улучшить результат AB способен дать более надёжный результат. Цена этого: более высокие требования к проведению эксперимента. Нужно не только уметь настроить окружение, но и верно интерпретировать наблюдаемое. Алгоритм: 1. Собрать данные о работе системы, тулинг в помощь (perf, bcc, iostat, bpftrace, tcpdump, ...) 2. Интерпретировать, как реагирует система (методологии USE, RED, off-CPU, TSA, ...) 3. Применять в цикле:

запустил
 └─ пронаблюдал
    └─ сформулировал гипотезу во что упираемся
       └─ проверил в следующем прогоне
          └─ повторил

Каждый пункт по отдельности даёт ограниченный эффект, зато вместе позволяет быстрее и увереннее продвигаться вперёд. ——— Вывод Сырые цифры от Passive Benchmarking могут выглядеть правдоподобно и при этом вести к неверным и дорогим решениям. Слепо доверяясь им, мы фактически надеемся, что угадали с сетапом с первого раза и учли все нюансы. Не похоже на надёжную стратегию Active Benchmarking напротив, позволяет избежать ловушки «бенчмаркаешь A, измеряешь B, делаешь выводы о C». Цифры, полученные таким методом, поддаются объяснению, их можно оспорить и воспроизвести. И на них уже можно опираться при принятии инженерных решений. ——— Что почитать - Active Benchmarking - CPU Benchmarks and Bad Tinder Dates - Performance Methodologies - Producing Wrong Data Without Doing Anything Obviously Wrong (тут может помочь заметка о чтении white paper) To be continued... ——— Поддержать лайком на Linkedin.

Keeping Your Security Model Intact When Running VMs in Kubernetes https://medium.com/@dillon_b/migrating-vms-on-kubernetes-without-losing-nsx-level-security-1c4027396568

Стрим о защите контейнеров, который нельзя пропустить Утёнок — для привлечения внимания. 28 мая в 11:00 на стриме разберём угрозы для контейнерных сред и где их ловить по пути от кода до кластера. Покажем, как новинки в Kaspersky Container Security меняют игру в защите контейнеров: от глубинного анализа образов с помощью ИИ до кастомных политик в пару кликов. За комплексный взгляд на тему отвечает специальный гость из платформы «Штурвал». Чтобы не пропустить, регистрируйтесь.

We brought Skew Protection to your Kubernetes

We're excited to share a new experimental feature for Platformatic: Skew Protection in the Intelligent Command Center (ICC). This brings Vercel-style deployment safety to Kubernetes, letting you deploy without downtime and avoid version-mismatch problems.

https://blog.platformatic.dev/skew-protection-for-kubernetes

DocumentDB on Kubernetes: Resilient, Highly Available Databases with Automatic Failover https://itnext.io/documentdb-on-kubernetes-resilient-highly-available-databases-with-automatic-failover-74c1a3ec882e

Autoscaling Hid Our LLM Cost Regression (85% → 4% Cache Hit Rate)

Why we moved capacity engineering into CI and started gating on prefix-cache efficiency

https://medium.com/@nroan/autoscaling-hid-our-llm-cost-regression-85-4-cache-hit-rate-b4beab5df240

Why post-mortem action items die https://incident.io/blog/why-post-mortem-action-items-die

The Incident Hero Trap https://uptimelabs.io/articles/the-incident-hero-trap

What does using AI for post-mortems actually mean? https://incident.io/blog/what-does-using-ai-for-post-mortems-actually-mean

Why LLMs Write Incorrect SQL (and What That Means for Your Database)

Most LLM-generated SQL doesn't fail. It runs and returns results, and that's exactly what makes it dangerous. The errors don't surface until they're already in your data.

https://readyset.io/blog/why-llms-write-incorrect-sql-and-what-that-means-for-your-database