Кубертатный период

📢 Обработка ошибок в Kubernetes операторе При разработке оператора Kubernetes существуют два способа сообщать об ошибках: Event (событие) и status.Condition (состояние). Пример: Отсутствует API-токен. Оператор пытается прочитать секрет, но пока такого секрета нет, и оператор не может выполнить свою работу. Преимущества Event: ✅ Легко видеть последние события (k9s :events shift L). Недостатки Event: ❌ Нельзя определить, когда событие снова в порядке, если не генерировать событие о успешном восстановлении. Однако, генерация события при каждом успешном обнаружении API-токена в секрете приведет к созданию событий для каждого вызова, что не имеет смысла. Преимущества status.Condition: ✅ Можно установить состояние "fine" (нормальное). Это гарантирует видимость только последнего состояния, а не устаревших состояний. Недостатки status.Condition: ❌ Нельзя легко просмотреть предыдущие статусы и состояния, которые не были в порядке. Это легко делается с помощью Event, но другого простого способа просмотра недавних сбоев нет.

NiFi Kop (Kubernetes operator) - это оператор Kubernetes, предназначенный для управления развертыванием и масштабированием Apache NiFi в Kubernetes. Он облегчает установку и управление инфраструктурой NiFi на Kubernetes, предоставляя возможность масштабировать и управлять экземплярами NiFi в среде Kubernetes. 💪 Основные преимущества NiFi Kop: - Установка: NiFi Kop легко устанавливается в кластер Kubernetes и имеет настраиваемые параметры для развертывания. 🚀 - Масштабирование: Оператор обеспечивает автоматическое масштабирование экземпляров NiFi в зависимости от нагрузки, что обеспечивает гибкое управление ресурсами. ⚖️ - Управление конфигурацией: NiFi Kop упрощает управление конфигурацией NiFi, позволяя определить параметры конфигурации в манифестах Kubernetes. ⚙️ - Мониторинг и логирование: Оператор интегрируется с системами мониторинга и логирования, такими как Prometheus и Grafana. 📊 - Обновления и восстановление: NiFi Kop предоставляет механизмы обновления версий NiFi без прерывания работы приложения и восстановления состояния NiFi в случае сбоев. 🔁 NiFi Kop облегчает развертывание и управление Apache NiFi на Kubernetes, позволяя сосредоточиться на разработке приложений NiFi. 🛠

NetBox - ведущее решение для моделирования и документирования современных сетей. Сочетая традиционные дисциплины управления IP-адресами (IPAM) и управления инфраструктурой центров обработки данных (DCIM) с мощными API и расширениями, NetBox обеспечивает идеальный "источник правды" для автоматизации сети. Демо: https://demo.netbox.dev/ Есть Terraform provider, что позволяет управлять инфраструктурой А также Ansible Plug-in, среди модулей которого есть модуль для управления Ansible inventory

🔐 Я кстати использую passwordstore для безопасного хранения паролей в Git 💻 💡 Как это работает: 1️⃣ Создайте Git-репозиторий для паролей. 2️⃣ Используйте passwordstore для сохранения паролей, которые автоматически шифруются с помощью GPG. 3️⃣ Коммитте и пушьте изменения в Git, где пароли будут зашифрованы. 🔒 Этот подход обеспечивает доступ к паролям с любого устройства, обеспечивая безопасность с помощью шифрования. Git обеспечивает контроль версий и восстановление предыдущих версий паролей. 🔐 Помните, безопасность паролей - важно! Используйте passwordstore и Git, чтобы защитить свои пароли и обеспечить безопасность аккаунтов.

📣 Вопрос безопасности: сохранение сертификата, зашифрованного паролем, в Git 🔒 🤔 Возник вопрос: является ли безопасным сохранение сертификата, зашифрованного паролем, в Git-репозиторий? При этом пароль не сохраняется рядом с сертификатом. 🔐 Ответ: Хранение сертификата, зашифрованного паролем, в Git может быть безопасным, при условии, что пароль не сохраняется в репозитории рядом с сертификатом. Пароль должен быть сохранен в надежном и безопасном месте, отдельно от репозитория. 💡 Рекомендуется следующий подход: 1️⃣ Сохраняйте сертификат в Git-репозитории, но не сохраняйте пароль вместе с ним. 2️⃣ Храните пароль в безопасном хранилище, таком как система управления паролями или ключами. 3️⃣ При использовании сертификата из Git, ваше приложение или скрипт должны запрашивать пароль из безопасного хранилища для расшифровки сертификата перед его использованием. 🔒 Этот подход обеспечит дополнительный уровень безопасности, так как пароль будет храниться отдельно и защищен от несанкционированного доступа.

🐳 Distroless контейнеры - это минимальные Docker-образы, предназначенные для запуска приложений. Они созданы с целью устранения необходимости в операционных системах внутри контейнера. Вместо этого они содержат только необходимые компоненты для работы приложения, такие как исполняемые файлы и библиотеки. 🔍 Преимущества: • ⚡️ Уменьшение размера образов: Отсутствие операционной системы позволяет значительно сократить размер контейнера, что улучшает время загрузки и экономит ресурсы. • 👮‍♀️ Улучшенная безопасность: Уменьшение поверхности атаки за счет исключения неиспользуемых компонентов операционной системы. • 🚫 Отсутствие необязательных уязвимостей: Меньше компонентов - меньше вероятность наличия уязвимостей. ⚙️ Distroless предоставляет базовые образы для различных языков программирования, таких как Java, Python, Node.js и других, что позволяет разработчикам сосредоточиться только на своем приложении, не заботясь о настройке и обновлении операционной системы. 🔗 Ссылка на репозиторий Distroless: https://github.com/GoogleContainerTools/distroless #Docker #Контейнеры #Distroless #Безопасность

Чо нашел: генерация 360-градусных сцен с помощью эскиза Вот тут в олайн режиме можно поиграться

​Jack Vanlightly конечно, графоман, но никто не пишет про бенчмарки так как он. В последнем опубликованном посте, он сравнил производительность Apache Kafka® и redpanda. И на удивление (на самом деле нет) AK оказалась быстрее. Если кратко Его тесты производительности показали, что Redpanda значительно уступает Apache Kafka по нескольким параметрам. Тесты проводились на идентичном оборудовании с одинаковыми настройками. Вот несколько ключевых выводов: - Изменение количества продюсеров и консьюмеров с 4 до 50 резко снизило производительность Redpanda, несмотря на сохранение пропускной способности. - Постоянная нагрузка на Redpanda в течение 24 часов приводила к замедлению дисков NVMe, вызывая высокие задержки. - С Kafka таких проблем не возникало из-за его более последовательного IO доступа. - При достижении лимита хранения Redpanda показывала большие конечные задержки. Kafka оставался стабильным. - Использование записей-ключей приводило к снижению пропускной способности и увеличению задержек у Redpanda. Kafka показывал лучшую производительность. - Только Kafka смог полностью использовать пропускную способность дисков NVMe в 2 ГБ/с. - Консьюмеры могли только сократить задержки с Kafka при постоянной нагрузке продюсера. - Несмотря на утверждения, Redpanda не может обеспечить работу с нагрузкой 1 ГБ/с с тремя брокерами i3en.6xlarge. Более подробные детали с картинками в блоге у Jack Vanlightly.

Investigating Linux Phantom Disk Reads Не так давно один из наших пользователей обратился за странным использованием оборудования. Они использовали наш клиент ILP (InfluxDB Line Protocol) для вставки строк в свою базу данных QuestDB, но наряду с записью на диск они также наблюдали значительные чтения на диск. Этого определенно не ожидается от рабочей нагрузки только для записи, поэтому нам пришлось разобраться в этой проблеме. Сегодня мы делимся этой историей, полной взлетов и падений, а также магии ядра Linux.

Динамический ресайзинг ресурсов с 1.27 в Kubernetes https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/

🔍 Сравнение микросервисной архитектуры и монолита 💩 В процессе разговоров с парой своих коллег, я начал сомневаться в премиуществах микросервисной архитектуры, тут хочу изложить общие термины и личное мнение, которое не претендует на истину. Цитата для привлечения внимания: "Микросервисная архитектура придумана не разработчиками/архитекторами/админами, а эффективными менеджерами и бизнесом, так как больше преимуществ это дает заказчику, позволяя ему нанимать любых колхозников, прошедших курсы разработки на любых языках." Накидаете в панамку? Комментарии приветствуются. https://mire-saw-919.notion.site/8d8dba0b816e43a4a1ad4bcae368e8a5

Odigos v1.5.0 может дискварить приложения через Kubernetes лейблу kubectl label ns my-namespace odigos-instrumentation=enabled Так же интегрируется с OpenTelemetry, а не только с Jaeger. Поддерживает еще кучу observability бекендов.

https://kubernetespodcast.com/episode/133-cilium/ Я тут наплясался в Яндекс.Облаке с Istio + Cilium CNI. Нужно видимо поглубже почитать про интеграцию Cilium и Istio. В подкасте слегка затрагивают эту тему. В кратце, я остановился на том, что с istio sidecar у меня не резолвятся внутренние адреса. Без — все ок, но тогда теряется функциональность Istio (авторизация и балансировка, безопасность и наблюдаемость)

Google Bard запустили, доступен теперь в более чем 180 странах: https://bard.google.com/ Посмотрю сегодня более подробно, что за код он выдал :)

https://www.youtube.com/watch?v=68m_9rLb83A Тайм-коды: 00:00 Новости с архитектором 01:00 Прыжок нейросетей 08:32 NVIDIA® и замена карт A100\T4 на H100\L4 для ML-вычислений 12:49 ARM-процессор со 128 ядрами 17:26 Про дата-центры 18:45 Шедеврум и Kandinsky 22:59 Yandex API Gateway. Поддержка CORS и механизма валидации 25:56 Yandex Data Transfer. Обновление интерфейсов 27:07 Yandex Managed Service for OpenSearch. Общий доступ 28:05 Yandex Managed Service for ClickHouse. ClickHouse 23.3 LTS 29:40 Yandex Cloud Apps. VM Folder Watchdog и Identity Server based on Ory Kratos 31:51 В продукте: Yandex Tracker