🔍 Сравнение микросервисной архитектуры и монолита

💩 В процессе разговоров с парой своих коллег, я начал сомневаться в премиуществах микросервисной архитектуры, тут хочу изложить общие термины и личное мнение, которое не претендует на истину.

Цитата для привлечения внимания:
"Микросервисная архитектура придумана не разработчиками/архитекторами/админами, а эффективными менеджерами и бизнесом, так как больше преимуществ это дает заказчику, позволяя ему нанимать любых колхозников, прошедших курсы разработки на любых языках."

Накидаете в панамку? Комментарии приветствуются.

https://mire-saw-919.notion.site/8d8dba0b816e43a4a1ad4bcae368e8a5

Динамический ресайзинг ресурсов с 1.27 в Kubernetes

https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/

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

🔍 Преимущества:
• ⚡️ Уменьшение размера образов: Отсутствие операционной системы позволяет значительно сократить размер контейнера, что улучшает время загрузки и экономит ресурсы.
• 👮‍♀️ Улучшенная безопасность: Уменьшение поверхности атаки за счет исключения неиспользуемых компонентов операционной системы.
• 🚫 Отсутствие необязательных уязвимостей: Меньше компонентов - меньше вероятность наличия уязвимостей.

⚙️ Distroless предоставляет базовые образы для различных языков программирования, таких как Java, Python, Node.js и других, что позволяет разработчикам сосредоточиться только на своем приложении, не заботясь о настройке и обновлении операционной системы.

🔗 Ссылка на репозиторий Distroless: https://github.com/GoogleContainerTools/distroless

#Docker #Контейнеры #Distroless #Безопасность

📣 Вопрос безопасности: сохранение сертификата, зашифрованного паролем, в Git 🔒

🤔 Возник вопрос: является ли безопасным сохранение сертификата, зашифрованного паролем, в Git-репозиторий? При этом пароль не сохраняется рядом с сертификатом.

🔐 Ответ: Хранение сертификата, зашифрованного паролем, в Git может быть безопасным, при условии, что пароль не сохраняется в репозитории рядом с сертификатом. Пароль должен быть сохранен в надежном и безопасном месте, отдельно от репозитория.

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

🔒 Этот подход обеспечит дополнительный уровень безопасности, так как пароль будет храниться отдельно и защищен от несанкционированного доступа.

🔐 Я кстати использую passwordstore для безопасного хранения паролей в Git 💻

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

🔒 Этот подход обеспечивает доступ к паролям с любого устройства, обеспечивая безопасность с помощью шифрования. Git обеспечивает контроль версий и восстановление предыдущих версий паролей.

🔐 Помните, безопасность паролей - важно! Используйте passwordstore и Git, чтобы защитить свои пароли и обеспечить безопасность аккаунтов.

NetBox - ведущее решение для моделирования и документирования современных сетей. Сочетая традиционные дисциплины управления IP-адресами (IPAM) и управления инфраструктурой центров обработки данных (DCIM) с мощными API и расширениями, NetBox обеспечивает идеальный "источник правды" для автоматизации сети.

Демо: https://demo.netbox.dev/

Есть Terraform provider, что позволяет управлять инфраструктурой

А также Ansible Plug-in, среди модулей которого есть модуль для управления Ansible inventory

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. 🛠

📢 Обработка ошибок в 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, таких как декларативная конфигурация и неизменяемая инфраструктура.