📢 Обработка ошибок в Kubernetes операторе

При разработке оператора Kubernetes существуют два способа сообщать об ошибках: Event (событие) и status.Condition (состояние).

Пример:

Отсутствует API-токен. Оператор пытается прочитать секрет, но пока такого секрета нет, и оператор не может выполнить свою работу.

Преимущества Event:

✅ Легко видеть последние события (k9s :events shift L).

Недостатки Event:

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

Преимущества status.Condition:

✅ Можно установить состояние "fine" (нормальное). Это гарантирует видимость только последнего состояния, а не устаревших состояний.

Недостатки status.Condition:

❌ Нельзя легко просмотреть предыдущие статусы и состояния, которые не были в порядке. Это легко делается с помощью Event, но другого простого способа просмотра недавних сбоев нет.

Модель зрелости MLOps

Тулинг для MLOps должен покрывать следующие задачи:

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

📢 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 - для проверки жизнеспособности контейнера во время его работы.

Как 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.
- Мониторинг ошибок железа.

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 заголовка на виртуальных интерфейсах.