📢 Важное замечание о микросервисной архитектуре

✍️ Заметка: The Saga is Antipattern

Микросервисы, задуманные как решение проблем, могут приносить больше вреда, чем пользы, если их применять слепо. Основная проблема заключается в отсутствии четких критериев, определяющих их применимость.

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

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

Такое положение дел приводит к разрушительным последствиям:

🔴 Построение ненадежных систем поверх надежной инфраструктуры в облаке.
🔴 Получение дизайна, который изначально сломан, с перепутанными уровнями, обработкой ошибок связи/повторных попыток и обработкой транзакций на уровне бизнес-логики.
🔴 Разбиение данных на части и их последующая сборка для обработки запросов, что приводит к непредсказуемым и едва контролируемым задержкам.
🔴 Невозможность обеспечения целостности и согласованности данных.
🔴 Необходимость полного тестирования перед развертыванием из-за отсутствия гарантий, что новая версия сервиса не сломает всю систему. Это полностью исключает независимую тестируемость и возможность развертывания сервисов.

Варианты решения:

1️⃣ Модульный монолит. Это может быть именно то, о чем я говорил ранее.
2️⃣ Событийная архитектура (Event-driven).
3️⃣ Наносервисы. Этот вариант обсуждается подробнее здесь, и это именно то, на что автор обращает внимание в своей заметке.

Lost in transit: debugging dropped packets from negative header lengths

В стиле Cloudflare, это глубокое погружение в ядро (kernel), чтобы найти источник вызывающей проблемы потери пакетов в сети Kubernetes.

Использовались такие интересные тулы, как pwru ("packet, where are you?") от Cillium и perf-probe для динамической трассировки.

Ну и причина, как обычно в MTU: некорректное значение из-за резервации нескольких байт для MAC заголовка на виртуальных интерфейсах.

Кстати говоря, теперь Pulumi может автоматически конвернуть Terraform HCL в Pulumi код на любом языке

https://www.pulumi.com/blog/converting-full-terraform-programs-to-pulumi

📢📊 Отчет о состоянии оптимизации затрат в Kubernetes от Google! 🌐

🔑 Ключевые тезисы:

1️⃣ Оптимизация затрат в Kubernetes начинается с понимания важности правильной настройки запросов и лимитов для ресурсов.

2️⃣ Правильное определение размеров ваших приложений и сервисов является золотым сигналом для оптимизации затрат.

3️⃣ Балансировка надежности, производительности и экономической эффективности может вызывать сложности.

4️⃣ Слепая оптимизации затрат может негативно сказаться на опыте конечных пользователей.

5️⃣ Автоматическое масштабирование рабочей нагрузки на основе бизнес- и пользовательских метрик.

6️⃣ Крупные компании активно используют скидки, предлагаемые облачными провайдерами.

7️⃣ Некорректная настройка запросов и лимитов может привести к неожиданным расходам.

📣💡 Ознакомьтесь с полным отчетом, чтобы узнать больше о оптимизации затрат в Kubernetes! 📚💰

Run an active-active multi-region Kubernetes application with AppMesh and EKS

В этом туториал от AWS используется несколько сервисов AWS, включая AWS App Mesh, Amazon Route 53 и Amazon EKS, для запуска отказоустойчивого, высокодоступного приложения в двух разных регионах на базе Kubernetes (EKS)

Flux v2.0.0 is Out!

Главный вывод здесь заключается в том, что patchesStrategicMerge и patchesJson6902 признаны устаревшими в v1beta1 и будут удалены в v1.

Перед обновлением на Flux 2 проверьте свою реализацию GitOps на предмет использования patchesStrategicMerge и patchesJson6902. Заменить патчами.

🚀 NVIDIA Device Plugin для Kubernetes 🖥

NVIDIA Device Plugin для Kubernetes - это daemonSet, который позволяет вам автоматически:

✨ Выявлять количество GPU на каждом узле вашего кластера
🔍 Следить за состоянием ваших GPU
🚀 Запускать контейнеры с поддержкой GPU в кластере Kubernetes

Плагин работает, предоставляя GPU на каждом узле в качестве ресурсов Kubernetes. Это позволяет вам создавать поды и запрашивать ресурсы GPU с помощью requests/limits, а kubelet будет планировать эти поды на узлах, имеющих необходимые GPU.

Плагин также предоставляет ряд функций для управления GPU, таких как:

🔸 Позволяет овер-коммитить задачи на GPU, чтобы вы могли запускать больше подов, чем имеется физических GPU.
🔸 Позволяет указать количество копий каждого GPU, которые вы хотите создать.
🔸 Позволяет указать версию CUDA, которую вы хотите использовать.

Плагин NVIDIA Device Plugin - ценный инструмент для управления GPU в Kubernetes. Он позволяет легко предоставлять GPU в качестве вычислительных ресурсов Kubernetes и предоставляет ряд функций для эффективного управления GPU. 💪

🌟 Будьте готовы раскрыть всю мощь GPU в вашем Kubernetes-кластере с помощью NVIDIA Device Plugin! 🌟

Я разбил ноутбук… :/

Quick fix

PR #266 - [Operator] Add AuthenticationStrategy, ManagerDn, ManagerPassword, IdentityStrategy properties for LDAP integration

Еще один контрибушн в Open source.

На этот раз добавил конфигурацию security для LDAP для NiFi Kubernetes Operator.

🔍 Масштабирование приложений в Kubernetes: HPA vs. Увеличение ресурсов

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

Короткий ответ: можно (нет)

💡 Обычно мы включаем автоматическое масштабирование (HPA) и увеличиваем количество реплик при изменении нагрузки на наше приложение.

📊 Ресурсы (requests/limits) в основном используются для ограничения вашего приложения и правильного определения размера вашего кластера и приложений внутри.
Начиная с версии Kubernetes 1.27, появилась поддержка динамического изменения ресурсов, но это не обеспечивает достаточной гибкости при изменении нагрузки.

💡 Если нагрузка на приложение предсказуема, то достаточно изменить ресурсы, и приложение сможет обработать запросы без проблем с выделенными ресурсами. Однако, если нагрузка на приложение меняется, возникают проблемы с масштабируемостью или требуется оптимизация расходов, использование горизонтального автоматического масштабирования (HPA) может быть более гибким и эффективным решением. 💪🚀

🎩 Helm Library Chart: Универсальность и преимущества 📦

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

Helm Library Chart позволяет нормально работать с объединением значений и шаблонов, в отличие от классического подхода, когда передаются несколько файлов значений с пересекающейся структурой данных.

Основные преимущества использования Helm Library Chart включают:

🔹 Универсальность: Благодаря Helm Library Chart вы можете создавать чарты, которые можно легко повторно использовать для разных приложений или компонентов.

🔹 Мерж значений и шаблонов: Helm Library Chart позволяет без проблем объединять значения и шаблоны, предоставляя более гибкую и удобную систему конфигурации.

🔹 Версионирование: Вы можете использовать версионирование в Helm Library Chart для безопасного управления зависимостями и внесения изменений в чарты.

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