CloudNativePG

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

Digger — Open source альтернатива Terraform Enterprise

Мы хорошо знакомы с трудностями, сопутствующими внедрению CI/CD для Terraform, которые решают такие тулы как Terraform Enterprise, Atlantis и другие. Возникает вопрос: зачем использовать отдельные системы CI, когда можно использовать уже существующую инфраструктуру для выполнения асинхронных задач, управления ресурсами, построения планов и ведения логов?

Digger решает эту проблему, предоставляя нативную интеграцию Terraform в вашу текущую CI. Это простой, надежный и удобный инструмент для запуска Terraform в вашей CI.

kube2pulumi

Конвертирует Kubernetes YAML в код Pulumi на Go, TypeScript, Python, C# и Java.

https://github.com/pulumi/kube2pulumi

🌐 Serverless у вас дома вместе с Spin и WebAssembly💡

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

🚀 Переносимость: wasm обеспечивает переносимость приложений, поскольку код в формате wasm может быть выполнен в различных окружениях, включая браузеры, серверы, мобильные устройства и даже встраиваемые системы. Это означает, что вы можете разрабатывать приложения в одной среде и запускать их практически везде, где поддерживается wasm.

⚡️ Высокая производительность: wasm предлагает высокую производительность благодаря своей байт-кодовой структуре и эффективной виртуальной машине. Код на wasm компилируется в машинный код непосредственно на устройстве, что обеспечивает более низкий уровень нативного исполнения и эффективное использование ресурсов.

📦 Малый размер: wasm-модули обычно имеют малый размер, что делает их легкими для передачи и загрузки по сети. Это особенно важно при работе с ограниченными пропускной способностью сети или на мобильных устройствах, где быстрый доступ к приложению является приоритетом.

🔒 Безопасность: wasm выполняется в песочнице (sandboxed environment), что означает, что он изолирован от основной операционной системы и других частей системы. Это повышает безопасность, поскольку недобросовестный код не может взаимодействовать с хост-системой.

💼 Множество языков программирования: WebAssembly не ограничивается одним языком программирования. Множество языков, включая C, C++, Rust, Go и многие другие, могут быть компилированы в wasm, что обеспечивает широкие возможности выбора для разработчиков.

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

Так что следует рассмотреть WebAssembly как альтернативу Docker💪🌐✨

📢 Есть такая полезная тула для мониторинга сетевого трафика - iftop.

Iftop - это CLI тула для Unix-подобных систем, которая позволяет отслеживать активность на сетевом интерфейсе в реальном времени. С ее помощью вы можете:

1️⃣ Отслеживать пропускную способность интерфейса.
2️⃣ Просматривать активные соединения и информацию о них.
3️⃣ Идентифицировать потенциальные проблемы с сетью, такие как утечки пропускной способности или атаки.

Примеры использования iftop:

🔹 Запустите iftop с указанием сетевого интерфейса:

iftop -i eth0

Это покажет активность на интерфейсе "eth0" в реальном времени.

🔹 Используйте фильтры для отображения только необходимой информации. Например, вы можете отобразить только соединения, исходящие или входящие из определенного IP-адреса:

iftop -i eth0 src host 192.168.0.10
iftop -i eth0 dst host 192.168.0.10

Iftop - это простой, но мощный инструмент, особенно полезный в высоконагруженных сетях. Он поможет вам контролировать пропускную способность, обнаруживать узкие места и оперативно реагировать на изменения.

Не забывайте о iftop при работе с сетевым трафиком! 🌐✨

Кстати, почитать о том, как у нас используется Spark operator в Kubernetes для масштабирования, можно тут — https://habr.com/ru/companies/leroy_merlin/articles/712946/

Один день из жизни простого инженера Kubernetes 🥺

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

✍️ Заметка: 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. Заменить патчами.