Платформа MLOps — это рабочая среда для совместной работы инженеров по машинному обучению, которая должна способствовать итеративным экспериментам и развертыванию моделей. После того, как вы решили, какие приложения должны быть доступны на платформе (описано в части 1) и установили базовую инфраструктуру (описано в части 2), пришло время подготовить платформу MLOps, чтобы пользователи могут начать создавать возможности машинного обучения. В этом посте будет рассказано о практическом руководстве по подготовке платформы MLOps, в том числе о том, как обрабатывать авторизацию и использовать парадигму GitOps для обеспечения актуальности и самоуправляемости ваших приложений.

Аутентификация

Перед установкой любого приложения на платформу необходимо строго контролировать аутентификацию пользователя. По замыслу платформа будет предоставлять некоторые общедоступные конечные точки (например, для доступа к экземпляру JupyterHub). Процесс аутентификации должен обеспечивать доступ к этим конечным точкам только для предполагаемой пользовательской базы и облегчать предоставление (и отзыв) доступа конкретным пользователям. Хотя эти концепции не зависят от облака, в этом эталонном примере платформа развернута на Google Cloud Platform (GCP) и использует службу GCP Identity Aware Proxy (IAP) для аутентификации пользователей в рамках конкретной доменной платформы в масштабах всей платформы.

На платформе у нас есть 2 типа приложений;

  1. Приложения, которым не требуется знать личность пользователя (например, MLflow, доступ к которому имеют все пользователи). Примечание; в некоторых ситуациях может потребоваться сделать определенную часть MLflow доступной для определенных групп внутри организации.
  2. Приложения, которым необходимо знать личность пользователя и сделать ее специфичной для пользователя (например, получить доступ к определенному набору показателей мониторинга).

Для первого типа приложений достаточно аутентификации IAP. Второй тип приложения требует дополнительной настройки.

Идеальным сценарием было бы распространение удостоверения пользователя путем сбора веб-токена JSON (JWT), созданного IAP. В этой ситуации пользователю требуется только один раз войти в систему, используя свою учетную запись Google, после чего он может получить доступ ко всем приложениям (к которым ему предоставлен доступ). Однако оказывается, что получение JWT и его использование для идентификации пользователя — это не то, что большинство приложений может предоставить из коробки. Приложения на платформе используют JWT, если это возможно, и в противном случае используют OAuth для дополнительной аутентификации приложения и требуют дополнительного входа в систему с учетной записью Google.

АргоCD

ArgoCD — это (как следует из названия) приложение для непрерывной доставки приложений в кластере Kubernetes с использованием парадигмы GitOps. ArgoCD реализован как контроллер Kubernetes, который постоянно отслеживает приложения, работающие в кластере. Он сравнивает текущий статус с целевым статусом (который является указанной веткой в ​​репозитории Git). Как только контроллер обнаружит разницу между текущим и целевым статусом, он визуализирует, что приложение имеет статус OutOfSync, и автоматически (или вручную, если указано) обновит приложение до желаемого статуса. Кроме того, он также может удалять ресурсы или восстанавливать ресурсы, которые были удалены вручную.

Для нашей платформы это гарантирует, что наши приложения всегда обновляются до последнего статуса и развертываются для всех пользователей, если вносятся какие-либо изменения. Хотя мы намерены сделать все приложения платформы самоуправляемыми (включая ArgoCD), ArgoCD должен быть установлен (см. часть 2 серии) при создании кластера, после чего он будет обслуживать себя.

Чтобы начать работу с ArgoCD, нам нужно сделать три вещи:

  1. Реализовать аутентификацию пользователей
  2. Разрешить ArgoCD читать из репозитория
  3. Установите и настройте ArgoCD

Настроить аутентификацию пользователя

Оператор внешних секретов Kubernetes используется для доступа к диспетчеру секретов GCP из Kubernetes. Во-первых, нам нужно создать учетные данные Oauth, чтобы ArgoCD мог аутентифицировать пользователей. К сожалению, создать эти учетные данные автоматически с помощью Terraform невозможно. Создание должно быть выполнено в консоли GCP, после чего его можно добавить в наш кластер в пространстве имен argocd как ExternalSecret, применив следующий yaml.

Имея эти секреты в нашем кластере, мы можем принять их в ConfigMap, применив следующий yaml.

Кроме того, управление доступом на основе ролей (RBAC) можно использовать для управления ролями (например, администратора) для определенных пользователей (или групп пользователей). Пример ниже добавляет двух админов на ArgoCD, но это можно сделать и через группы Google.

Разрешить ArgoCD читать наш репозиторий

Как упоминалось ранее, ArgoCD постоянно отслеживает наличие обновлений в репозиториях Git. Он может сделать это только в том случае, если ему предоставлен доступ на чтение к репозиторию, который он должен отслеживать. Для каждого репозитория, который необходимо отслеживать, необходимо вручную создать ключ SSH (например, в GitHub). Этот ключ необходимо добавить в кластер, чтобы ArgoCD мог получить к нему доступ. В нашем случае мы добавили ключ в качестве секрета в консоли GCP. Секрет выглядит так:

{"name":"mlops-architecture","sshPrivateKey":"-----BEGIN OPENSSH PRIVATE KEY-----\nSECRET!! -----END OPENSSH PRIVATE KEY-----","url":"your-repo-url"}

После добавления секрета в консоль GCP его можно добавить в кластер, создав файл ExternalSecret. Если для secret-type установлено значение repository, ArgoCD обнаружит секрет и будет использовать его при попытке получить последний статус репозитория. Ниже приведен пример файла yaml, который создает такой секрет.

Установите и настройте ArgoCD

После настройки аутентификации и размещения всех секретов (в правильном пространстве имен) следующим шагом будет установка самого ArgoCD. Самый простой способ — применить стандартный файл install.yaml. Это настроит ArgoCD со всеми настройками по умолчанию. Последний шаг в этом процессе — сделать ArgoCD доступным для пользователей из их браузеров. Для этого нам нужно создать VirtualService, который настраивает Ingress-контроллер (в нашем эталонном примере это Istio (см. часть 2 серии)) для направления трафика на определенный домен. имя в приложение ArgoCD.

Приложения

После аутентификации пользователя и ArgoCD пришло время действительно сделать платформу полезной и снабдить ее приложениями, с которыми пользователь может работать. Перед фактической установкой приложений мы решили, что подготовка всех приложений должна выполняться с использованием одного и того же формата, и решили использовать диаграммы управления. Придерживаясь этой стратегии, настроить новое приложение на платформе легко и можно выполнить в 3 этапа:

  1. Создайте (или расширьте существующую) диаграмму руля и добавьте параметры конфигурации.
  2. Создайте манифест ArgoCD и примените его к кластеру.
  3. Добавьте (при необходимости) правило входа, чтобы пользователи могли получить доступ к приложению.

Одним из приложений, установленных на платформе, является JupyterHub. Ниже приведено практическое руководство по установке JupyterHub на платформе.

Создайте приложение JupyterHub

Во-первых, мы используем уже существующую рулевую диаграмму JupyterHub. Chart.yaml содержит только следующий код.

Кроме того, в том же каталоге, в котором настраивается приложение, создается файл values.yaml. В этом примере пользователи, например, по умолчанию перенаправляются на URL-адрес /lab и получают емкость хранилища 2Gi. Это можно расширить, настроив все возможные параметры, которые можно найти в официальном репозитории.

Помимо конфигураций, JupyterHub необходимо идентифицировать пользователей, чтобы запустить их, и указать им путь к собственному серверу ноутбуков. Как описано выше, в идеальном сценарии будет использоваться JWT, созданный IAP, но эта функциональность не предоставляется по умолчанию. Поэтому настраивается дополнительный процесс идентификации. Чтобы облегчить пользователям процесс входа в систему, мы используем Oauth, чтобы пользователи могли входить в систему с той же учетной записью, которую они используют для аутентификации IAP. Ниже приведен пример файла, который создает новый ExternalSecret для JupyterHub. Он извлекает client_id и client_secret, созданные ранее в консоли GCP (см. выше). Примечание: невозможно проанализировать эти учетные данные в обычном values.yaml .

Манифест ArgoCD

После настройки конфигурации приложение можно установить, применив манифест к кластеру Kubernetes. Этот манифест очень прост и в основном состоит только из указателя на нужный репозиторий и ветку.

Правило входящего трафика

Чтобы пользователи могли получать доступ к JupyterHub через свои браузеры, мы должны создать VirtualService, который настраивает способ перенаправления входящего трафика. Это идентично описанному в разделе ArgoCD.

Заключение

В этом блоге представлен обзор того, как подготовить платформу MLOps и установить ArgoCD, чтобы приложения могли управляться самостоятельно. Хотя управление приложениями с помощью ArgoCD, в конце концов, довольно простое, в первую очередь требуется выполнить некоторые ручные шаги для настройки. На наш взгляд, самое главное для создания успешной платформы — придерживаться определенного формата установки и настройки приложений, чтобы сделать его воспроизводимым для всех инженеров, работающих на платформе. Стоит отметить, что (некоторые) пакеты с открытым исходным кодом не предоставляют функции для идентификации пользователя путем извлечения готового JWT, что, вероятно, будет добавлено в будущем.