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

Lost in transit: debugging dropped packets from negative header lengths В стиле Cloudflare, это глубокое погружение в ядро (kernel), чтобы найти источник вызывающей проблемы потери пакетов в сети Kubernetes. Использовались такие интересные тулы, как pwru ("packet, where are you?") от Cillium и perf-probe для динамической трассировки. Ну и причина, как обычно в MTU: некорректное значение из-за резервации нескольких байт для MAC заголовка на виртуальных интерфейсах.

📢 Важное замечание о микросервисной архитектуре ✍️ Заметка: The Saga is Antipattern Микросервисы, задуманные как решение проблем, могут приносить больше вреда, чем пользы, если их применять слепо. Основная проблема заключается в отсутствии четких критериев, определяющих их применимость. Свойства микросервисной архитектуры могут ограничивать способность системы на основе микросервисов выполнять определенные задачи, такие как транзакции, поддержка согласованности или проверка доступности системы. Разделение доменов в соответствии с управляемыми данными позволяет быстро понять, что в большинстве случаев микросервисы очень похожи на традиционные монолиты, работающие с большим доменом. Некоторые организации обнаруживают, что традиционные монолиты по своей сути являются микросервисами, так как имеют очень ограниченное количество действительно независимых доменов, зачастую всего один. Такое положение дел приводит к разрушительным последствиям: 🔴 Построение ненадежных систем поверх надежной инфраструктуры в облаке. 🔴 Получение дизайна, который изначально сломан, с перепутанными уровнями, обработкой ошибок связи/повторных попыток и обработкой транзакций на уровне бизнес-логики. 🔴 Разбиение данных на части и их последующая сборка для обработки запросов, что приводит к непредсказуемым и едва контролируемым задержкам. 🔴 Невозможность обеспечения целостности и согласованности данных. 🔴 Необходимость полного тестирования перед развертыванием из-за отсутствия гарантий, что новая версия сервиса не сломает всю систему. Это полностью исключает независимую тестируемость и возможность развертывания сервисов. Варианты решения: 1️⃣ Модульный монолит. Это может быть именно то, о чем я говорил ранее. 2️⃣ Событийная архитектура (Event-driven). 3️⃣ Наносервисы. Этот вариант обсуждается подробнее здесь, и это именно то, на что автор обращает внимание в своей заметке.

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

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

Apache Spark on Kubeflow Migrating Apache Spark ML Jobs to Spark + Tensorflow on Kubeflow Есть два варианта использования Spark в Kubeflow: 1️⃣ Установка оператора Apache Spark в namespace Kubeflow. Однако, стоит отметить, что Spark Operator, отсутствует в компонентах Kubeflow и не получает поддержки уже в течение двух лет: https://github.com/kubeflow/manifests/issues/2311 https://github.com/kubeflow/manifests/pull/2430 Вместо этого, рекомендуется использовать 👩‍💻 Google Kubernetes Spark Operator, который используется у нас в Leroy Merlin в DataPlatform 2.0. Вы можете упаковать свое приложение с MLlib в JAR или Python и запускать его в Kubernetes с помощью оператора. Kubeflow в этом случае не играет важной роли. Для дополнительной информации о работе с оператором рекомендуется обратиться к документации. 👆 Использование Apache Spark в Jupyter ноутбуке. Этот вариант позволяет вам запускать Spark задачи напрямую из Jupyter ноутбука в Kubeflow. Вы можете установить Jupyter ноутбук в Kubeflow и настроить его для работы с Spark. Это может потребовать дополнительных шагов, но предоставляет удобный интерфейс для разработки и выполнения Spark ML задач.

📢 Есть такая полезная тула для мониторинга сетевого трафика - 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 при работе с сетевым трафиком! 🌐✨

​Свежая статья от Neil Buesing в которой он раскрывает все тонкости настройки Apache Kafka в режиме KRaft! Для тех кто не в курсе (что очень странно для меня т.к. мой видос про Kraft давно в сети), KRaft — это KRaft mode in Apache Kafka, режим, который позволяет Kafka работать без использования Apache ZooKeeper. В статье вы найдете подробные инструкции и лучшие практики по настройке этого режима. 🔗 Статью вы можете прочитать по этой ссылке: тут А если вы предпочитаете действовать на практике, у нас есть хорошая новость: код и docker compose файлы из статьи доступны на Github! 🔗 GitHub репозиторий: тут

🌐 Serverless у вас дома вместе с Spin и WebAssembly💡 WebAssembly - это открытый стандарт, который позволяет выполнять код на более низком уровне, независимо от конкретной платформы. Он представляет собой компактный бинарный формат, который может быть загружен и запущен в разных окружениях, включая браузеры, серверы и даже мобильные устройства. 🚀 🚀 Переносимость: wasm обеспечивает переносимость приложений, поскольку код в формате wasm может быть выполнен в различных окружениях, включая браузеры, серверы, мобильные устройства и даже встраиваемые системы. Это означает, что вы можете разрабатывать приложения в одной среде и запускать их практически везде, где поддерживается wasm. ⚡️ Высокая производительность: wasm предлагает высокую производительность благодаря своей байт-кодовой структуре и эффективной виртуальной машине. Код на wasm компилируется в машинный код непосредственно на устройстве, что обеспечивает более низкий уровень нативного исполнения и эффективное использование ресурсов. 📦 Малый размер: wasm-модули обычно имеют малый размер, что делает их легкими для передачи и загрузки по сети. Это особенно важно при работе с ограниченными пропускной способностью сети или на мобильных устройствах, где быстрый доступ к приложению является приоритетом. 🔒 Безопасность: wasm выполняется в песочнице (sandboxed environment), что означает, что он изолирован от основной операционной системы и других частей системы. Это повышает безопасность, поскольку недобросовестный код не может взаимодействовать с хост-системой. 💼 Множество языков программирования: WebAssembly не ограничивается одним языком программирования. Множество языков, включая C, C++, Rust, Go и многие другие, могут быть компилированы в wasm, что обеспечивает широкие возможности выбора для разработчиков. WebAssembly открывает новые возможности для разработки и доставки приложений. Он может быть особенно полезен в веб-разработке, где его мощь и переносимость помогают улучшить производительность и пользовательский опыт. Так что следует рассмотреть WebAssembly как альтернативу Docker💪🌐✨

kube2pulumi Конвертирует Kubernetes YAML в код Pulumi на Go, TypeScript, Python, C# и Java. https://github.com/pulumi/kube2pulumi

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

При расследовании инцидентов в достаточно крупной экосистеме зачастую начинаются поиски сбоящего компонента. Один из способов это сделать — смотреть на HTTP-коды и двигаться по направлению к источнику. Получил 502 на фронте — ищешь кто вернул 502 ему, и так далее, до причины. И это помогает и работает, пока мы не сталкиваемся с восхитительным кодом 499. Гугл говорит нам, что смысл этой ошибки — client closed request. То есть она указывает, что наше приложение такое выполняло свою логику, готовило-готовило ответ, но при попытке отправить очередную порцию ответа получателю обнаружило, что тот уже закрыл соединение, отправлять некуда. Неочевидная же мысль, следующая из этого — корневую причину нужно искать не глубже по цепочке вызовов, а ближе в “поверхности”, в получателе, разорвавшем соединение. Или в его получателе. И так вплоть до клиентского приложения. Очень может быть причина — в каком-то timeout/keepalive-параметре или более крупный косяк (например, пришедший OOM). Если пофиксить проблему в клиенте — ошибки уйдут.

​Say Hello to Grafana OnCall Практический гайд по использованию Grafana OnCall. Сохраните, чтобы не потерять. Читать статью. Используете у себя этот полезный инструмент для управления алертами?

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

Как OpenAI масштабировали Kubernetes кластер до 7500 узлов для рабочей нагрузки 🔬 Для задач машинного обучения и исследований требуется создание масштабируемой инфраструктуры для больших моделей, таких как GPT-3, CLIP и DALL·E, а также для быстрых мелкомасштабных итеративных исследований. 🚀 Масштабирование одного кластера Kubernetes до такого размера выполняется редко и требует особой осторожности, но плюсом является простая инфраструктура, которая позволяет командам машинного обучения двигаться быстрее и масштабироваться без изменения своего кода. 🔑 Ключевые тезисы: - Для рабочей нагрузки задач машинного обучения требуется доступ ко всем низкоуровневым ресурсам, таким как видеокарта, например, которая доступна по сети через NVLink или GPUDirect. - Один под в большинстве случаев занимают целиком узел полностью. - Host-level контейнерная сеть. - Маркируют пакеты через iptables, чтобы мониторить трафик по namespaces. - Kube API и etcd на выделенных машинах в количестве 5 штук: полезные алерты статуса HTTP 429 (слишком много запросов) и 5xx (ошибка сервера сервера API) в качестве высокоуровневого индикатора проблем. - Автомасштабирование кластера отсутствует, так как масштабирование в таких объемах приводит к резкому росту запросов в Kube API при вводе узла в кластер и перегружает API. - Мониторинг ошибок железа.

📢 Kubernetes предоставляет три механизма проверки состояния контейнеров: Startup, Readiness и Liveness пробы. 🔄 🚀 Startup Probe: Startup Probe используется для проверки, завершился ли процесс запуска контейнера и готов ли он обрабатывать запросы Применяется только во время запуска контейнера Проверка повторяется до тех пор, пока контейнер не пройдет пробу запуска Если проба запуска завершается неуспешно, контейнер считается неисправным и Kubernetes может принять соответствующие меры, такие как перезапуск контейнера ⏰ ✅ Readiness Probe: Readiness Probe используется для проверки, готов ли контейнер принимать трафик и обрабатывать запросы от клиентов Применяется после успешного запуска контейнера Проверка повторяется в течение жизни контейнера Если проба готовности завершается неуспешно, контейнер помечается как неготовый, и Kubernetes перестает направлять трафик на него 🛠 💡 Liveness Probe: Liveness Probe используется для проверки, находится ли контейнер в рабочем состоянии или возникла ли внутренняя проблема Применяется после успешного запуска контейнера Проверка повторяется в течение жизни контейнера Если проба жизнеспособности завершается неуспешно, Kubernetes решает, что контейнер не работает должным образом, и может принять меры, такие как перезапуск контейнера 🔍 🌟 Таким образом, Startup Probe используется для проверки завершения процесса запуска, Readiness Probe - для проверки готовности контейнера принимать трафик, а Liveness Probe - для проверки жизнеспособности контейнера во время его работы.

Модель зрелости MLOps Тулинг для MLOps должен покрывать следующие задачи: - Версионирование данных/модели/конфигурации/схемы - Оркестрация для создания наборов данных и сбора данных - Оркестрация для автоматического обучения модели (по триггеру, по расписанию и т. д.) - Оркестрация для автоматического развертывания модели (+ A/B-тестирование, canary) - Сервинг моделей - Автоматическая подготовка вычислительных ресурсов локально или в облаке - Обнаружение сдвига в данных - Мониторинг модели в производстве - Юнит/интеграционные тесты и тесты для данных