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

🚀 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) может быть более гибким и эффективным решением. 💪🚀