Skip to content

アプリケーション内で をクリックすると、お使いのDataRobotバージョンに関する全プラットフォームドキュメントにアクセスできます。

Kubernetes用の管理エージェントHelmのインストール

このプロセスでは、Helmチャートを使用して、管理エージェントとKubernetesプラグインのインストールと設定を支援する、管理エージェントのユースケースの例を示します。

重要

このプロセスで使用されるKubernetesプラグインとHelmチャートは一例です。ニーズに合わせて変更する必要があります。

概要

MLOps管理エージェントは、任意のインフラストラクチャのモデルデプロイを自動化するためのメカニズムを提供します。 Kubernetesは、DataRobotの外部でモデルをデプロイおよび監視するための一般的なソリューションで、管理および監視エージェントによって調整されます。 管理エージェントとKubernetesプラグインのインストールと設定を合理化するために、エージェントtarballの/tools/charts/datarobot-management-agentディレクトリの内容を使用できます。

/tools/charts/datarobot-management-agentディレクトリには Helmチャートに必要なファイルが含まれています。このファイルを変更して、好みのクラウド環境用に管理エージェントとそのKubernetesプラグインをインストールして設定できます。クラウド環境として設定できるのは、Amazon Web Services、Azure、Google Cloud Platform、OpenShiftです。 また、標準のDocker Hubのインストールと設定もサポートしています。 このディレクトリには、デフォルトのvalues.yamlファイル(エージェントtarballの /tools/charts/datarobot-management-agent/values.yamlにあります)と、環境ごとにカスタマイズ可能なサンプルのvalues.yamlファイル(エージェントtarballの/tools/charts/datarobot-management-agent/examplesディレクトリにあります)が含まれています。 必要な環境固有のvalues.yamlファイルをコピーして更新し、--values <filename>を使用してデフォルト値をオーバーレイすることができます。

アーキテクチャの概要

上の図は、管理エージェントがモデルをKubernetesにデプロイし、モデル監視を有効にする方法について説明しています。

上の図は、DataRobotモデルをKubernetesのデプロイ可能なイメージにパッケージ化する方法について説明しています。 このアーキテクチャは、Googleが管理する Kanikoというオープンソースツールを利用しています。Kubernetesクラスター内にDockerイメージを安全に構築するように設計されています。

前提条件

開始する前に、管理エージェントのDockerイメージをビルドして、Kubernetesクラスターからアクセス可能なレジストリにプッシュする必要があります。 これを実施していない場合は、 MLOps管理エージェントの概要を参照してください。

管理エージェントのDockerイメージを取得したら、次の要件でKubernetes クラスターを設定します。

  • Kubernetesクラスター(バージョンv1.21以降)
  • NGINX Ingress
  • Dockerレジストリ
  • 2+ CPUs
  • 40GB以上のインスタンスストレージ(イメージキャッシュ)
  • 6GB以上のメモリ

重要

すべての要件は、管理エージェントの最新バージョン用です。

ソフトウェア要件の設定

必要なソフトウェアリソースをインストールして設定するには、以下に概説するプロセスに従います。

サポートの対象は、バージョン1.21以降を実行しているすべてのKubernetesクラスターです。 選択した分布のドキュメントに従って、新しいクラスターを作成します。 このプロセスは、OpenShiftバージョン4.8以降にも対応しています。

重要

OpenShiftを使用している場合は、この前提条件をスキップする必要があります。 OpenShiftは、組み込みの イングレスコントローラーを使用します。

現在、サポートされている唯一のイングレスコントローラーはオープンソースの Nginx-Ingressコントローラー(>=4.0.0)です。 お使いの環境にNginx Ingressをインストールするには、Nginx Ingressのドキュメントを参照するか、以下のサンプルスクリプトを試してください。

# Create a namespace for your ingress resources
kubectl create namespace ingress-mlops

# Add the ingress-nginx repository
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Use Helm to deploy an NGINX ingress controller
#
# These settings should be considered sane defaults to help quickly get you started.
# You should consult the official documentation to determine the best settings for
# your expected prediction load. With Helm, it is trivial to change any of these
# settings down the road.
helm install nginx-ingress ingress-nginx/ingress-nginx \
    --namespace ingress-mlops \
    --set controller.ingressClassResource.name=mlops \
    --set controller.autoscaling.enabled=true \
    --set controller.autoscaling.minReplicas=2 \
    --set controller.autoscaling.maxReplicas=3 \
    --set controller.config.proxy-body-size=51m \
    --set controller.config.proxy-read-timeout=605s \
    --set controller.config.proxy-send-timeout=605s \
    --set controller.config.proxy-connect-timeout=65s \
    --set controller.metrics.enabled=true 

このプロセスは、Docker Hubまたは標準のV2 Dockerレジストリに加えて、主要なクラウドベンダーのマネージドレジストリ(ECR、ACR、GCR)をサポートします。 レジストリで事前に作成されたリポジトリ(つまり、ECR)が必要な場合は、次のリポジトリを作成する必要があります。

  • datarobot/mlops-management-agent
  • datarobot/mlops-tracking-agent
  • datarobot/datarobot-portable-prediction-api
  • mlops/frozen-models

重要

mlops/frozen-modelリポジトリへの管理エージェントのプッシュアクセスを提供する必要があります。 一般的なレジストリタイプの例をいくつか 以下に示します。 GCRまたはOpenShiftを使用している場合は、上記の各Dockerリポジトリのパスを環境に合わせて変更する必要があります。

レジストリ資格情報の設定

クラウドソリューション用にDockerレジストリを設定するには、以下に概説する関連プロセスに従います。 このセクションでは、次のレジストリの例で説明します。

  • Amazon Elastic Container Registry (ECR)
  • Microsoft Azure Container Registry (ACR)
  • Google Cloud Platformコンテナレジストリ(GCR)
  • OpenShift統合レジストリ
  • 汎用レジストリ(Docker Hub)

まず、ECR UIまたは次のコマンドを使用して、上記の必要なすべてのリポジトリを作成します。

repos="datarobot/mlops-management-agent
datarobot/mlops-tracking-agent
datarobot/datarobot-portable-prediction-api
mlops/frozen-model"
for repo in $repos; do
aws ecr create-repository --repository-name $repo
done 

プッシュ資格情報をエージェントに提供するには、 サービスアカウント用IAMロールを使用します。

eksctl create iamserviceaccount --approve \
    --cluster <your-cluster-name> \
    --namespace datarobot-mlops \
    --name datarobot-management-agent-image-builder \
    --attach-policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser 

以下の内容でconfig.jsonと呼ばれるファイルを作成します。

{ "credsStore": "ecr-login" } 

そのJSONファイルを使用して、ConfigMapを作成します。

kubectl create configmap docker-config \
    --namespace datarobot-mlops \
    --from-file=<path to config.json> 

values.yamlファイル(エージェントtarballの/tools/charts/datarobot-management-agent/values.yamlにあります)のimageBuilderセクションを更新して、作成済みのconfigMapと作成済みのIAMロールを使用してserviceAccountを設定します。

imageBuilder:

configMap: "docker-config"
serviceAccount:
    create: false
    name: "datarobot-management-agent-image-builder" 

まず、ACRレジストリの設定 > アクセスキーで、 管理者ユーザー設定を有効にします。 次に、生成されたパスワードの1つを使用して、新しいシークレットを作成します。

kubectl create secret docker-registry registry-creds \
    --namespace datarobot-mlops \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<admin-username> \
    --docker-password=<admin-password> 

備考

このプロセスは、datarobot-mlops名前空間を作成済みであることを前提としています。

次に、values.yamlファイル(エージェントtarballの/tools/charts/datarobot-management-agent/values.yamlにあります)のimageBuilderセクションを更新して、作成したシークレットにsecretNameを使用します。

imageBuilder:

secretName: "registry-creds" 

GKEクラスターでWorkload Identityを使用して、GCRプッシュ認証情報をDockerイメージ構築サービスに提供する必要があります。 このプロセスは、次の手順で構成されています。

このセクションでは、このガイドを完了するために必要な最小限の設定を見つけることができます。

まず、クラスターとノードグループのすべてでWorkload Identityを有効にします。

# Enable workload identity on your existing cluster
gcloud container clusters update <CLUSTER-NAME> \
--workload-pool=<PROJECT-NAME>.svc.id.goog

# Enable workload identity on an existing node pool
gcloud container node-pools update <NODE-POOL-NAME> \
--cluster=<CLUSTER-NAME> \
--workload-metadata=GKE_METADATA 

クラスターの準備ができたら、IAMサービスアカウントを新規作成し、必要なすべてのアクセス許可を提供するロールをイメージビルダーサービスにアタッチします。 イメージビルダーサービスは新しいイメージをGCRにプッシュし、IAMサービスアカウントはインストール時に作成されたGKE ServiceAccountにバインドできる必要があります。

# Create Service Account
gcloud iam service-accounts create gcr-push-user

# Give user push access to GCR
gcloud projects add-iam-policy-binding <PROJECT-NAME> \
--member=serviceAccount:[gcr-push-user]@<PROJECT-NAME>.iam.gserviceaccount.com \
--role=roles/cloudbuild.builds.builder

# Link GKE ServiceAccount with the IAM Service Account
gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:<PROJECT-NAME>.svc.id.goog[datarobot-mlops/datarobot-management-agent-image-builder]" \
gcr-push-user@<PROJECT-NAME>.iam.gserviceaccount.com 

最後に、values.yamlファイル(エージェントtarballの/tools/charts/datarobot-management-agent/values.yamlにあります)のimageBuilderセクションを更新して、前の手順で作成したannotationsnameを使用してserviceAccountを作成します。

imageBuilder:

serviceAccount:
    create: true
    annotations: {
    iam.gke.io/gcp-service-account: gcr-push-user@<PROJECT-NAME>.iam.gserviceaccount.com
    }
    name: datarobot-management-agent-image-builder 

OpenShiftは、 組み込みのレジストリソリューションを提供します。 これは、OpenShiftを使用している場合に推奨されるコンテナレジストリです。

このガイドの後半で、ローカルにビルドされたイメージをレジストリプッシュする必要があります。 これを簡単に行うには、次のコマンドを使用してレジストリを外部に公開します。

oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge 

このレジストリにログインしてイメージをプッシュする方法については、 OpenShiftのドキュメントを参照してください。

さらに、rootとして実行し、統合されたDockerレジストリに プッシュする 権限を持つ、専用イメージビルダーのサービスアカウントを作成する必要があります。

oc new-project datarobot-mlops
oc create sa datarobot-management-agent-image-builder

# Allows the SA to push to the registry
oc policy add-role-to-user registry-editor -z datarobot-management-agent-image-builder

# Our Docker builds require the ability to run as `root` to build our images
oc adm policy add-scc-to-user anyuid -z datarobot-management-agent-image-builder 

OpenShiftがDockerレジストリ認証シークレットを作成するときに、正しくない形式(kubernetes.io/dockerconfigjsonではなくkubernetes.io/dockercfg)で作成されました。 これを修正するには、適切なトークンを使用してシークレットを作成します。 これを行うには、datarobot-management-agent-image-builder ServiceAccountに割り当てられている既存のImage pull secretsを見つけます。

$ oc describe sa/datarobot-management-agent-image-builder

Name:                datarobot-management-agent-image-builder
Namespace:           datarobot-mlops
Labels:              <none>
Annotations:         <none>
Image pull secrets:  datarobot-management-agent-image-builder-dockercfg-p6p5b
Mountable secrets:   datarobot-management-agent-image-builder-dockercfg-p6p5b
                    datarobot-management-agent-image-builder-token-pj9ks
Tokens:              datarobot-management-agent-image-builder-token-p6dnc
                    datarobot-management-agent-image-builder-token-pj9ks
Events:              <none> 

次に、プルシークレットから生のトークンに戻します。

$ oc describe secret $(oc get secret/datarobot-management-agent-image-builder-dockercfg-p6p5b -o jsonpath='{.metadata.annotations.openshift\.io/token-secret\.name}')

Name:         datarobot-management-agent-image-builder-token-p6dnc
Namespace:    datarobot-mlops
Labels:       <none>
Annotations:  kubernetes.io/created-by: openshift.io/create-dockercfg-secrets
            kubernetes.io/service-account.name: datarobot-management-agent-image-builder
            kubernetes.io/service-account.uid: 34101931-d402-49bf-83df-7a60b31cdf44

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:          11253 bytes
namespace:       10 bytes
service-ca.crt:  12466 bytes
token:           eyJhbGciOiJSUzI1NiIsImtpZCI6InJqcEx5LTFjOElpM2FKRzdOdDNMY… 
oc create secret docker-registry registry-creds \
    --docker-server=image-registry.openshift-image-registry.svc:5000 \
    --docker-username=imagebuilder \
    --docker-password=eyJhbGciOiJSUzI1NiIsImtpZCI6InJqcEx5LTFjOElpM2FKRzdOdDNMY… 

最後に、上記で作成したserviceAccountを参照するように、values.yamlファイル(エージェントtarballの/tools/charts/datarobot-management-agent/values.yamlにあります)のimageBuilderセクションを更新します。

imageBuilder:

secretName: registry-creds

rbac:
    create: false
serviceAccount:
    create: false
    name: datarobot-management-agent-image-builder 

内部レジストリが内部CAによって署名されるのは一般的です。 これを回避するには、values.yaml設定でTLS検証をスキップします。

imageBuilder:

skipSslVerifyRegistries:
    - image-registry.openshift-image-registry.svc:5000 

CA証明書を持っている場合、より安全なオプションは、それをsecretまたはconfigMapとしてマウントし、それを使用するようにimageBuilderを設定することです。 基になるノードからCAを直接取得する方法の3番目のオプションを、以下に示します。

imageBuilder:

extraVolumes:
    - name: cacert
    hostPath:
        path: /etc/docker/certs.d

extraVolumeMounts:
    - name: cacert
    mountPath: /certs/
    readOnly: true

extraArguments:
    - --registry-certificate=image-registry.openshift-image-registry.svc:5000=/certs/image-registry.openshift-image-registry.svc:5000/ca.crt 

備考

上記の例では、昇格されたSCC権限が必要です。

oc adm policy add-scc-to-user hostmount-anyuid -z datarobot-management-agent-image-builder 

単純なDockerユーザー名/パスワードを使用してログインする汎用レジストリがある場合は、次の手順を使用できます。

Dockerレジストリ資格情報を含むシークレットを作成します。

kubectl create secret docker-registry registry-creds \
    --namespace datarobot-mlops \
    --docker-server=<container-registry-name>.your-company.com \
    --docker-username=<push-username> \
    --docker-password=<push-password> 

values.yamlファイル(エージェントtarballの/tools/charts/datarobot-management-agent/values.yamlにあります)のimageBuilderセクションを更新して、作成した新しいシークレットを使用します。

imageBuilder:

secretName: "registry-creds"  

レジストリがHTTPで実行されている場合は、上記の例に次を追加する必要があります。

imageBuilder:

secretName: "registry-creds"
insecureRegistries:
    - <container-registry-name>.your-company.com 

Helmを使用した管理エージェントのインストール

前提条件が設定されたら、MLOps管理エージェントをインストールします。 これらの手順では、大規模なDockerイメージをビルドしてリモートレジストリにプッシュします。 ダウンロードまたはアップロードの実行中にこれらの手順を並行して実行することをお勧めします。

ポータブル予測サーバーの画像を取得する

最初のステップは、 ポータブル予測サーバーのDockerイメージの最新バージョンをDataRobotの開発者ツールからダウンロードすることです。 ダウンロードが完了したら、次のコマンドを実行します。

  1. PPS Dockerイメージを読み込みます。

    docker load < datarobot-portable-prediction-api-<VERSION>.tar.gz 
    

  2. イメージ名でPPS Dockerイメージにタグを付けます。

    備考

    latest<VERSION>タグとして使用しないでください。

    docker tag datarobot/datarobot-portable-prediction-api:<VERSION> registry.your-company.com/datarobot/datarobot-portable-prediction-api:<VERSION> 
    
  3. PPS Dockerイメージをリモートレジストリにプッシュします。

    docker push your-company.com/datarobot/datarobot-portable-prediction-api:<VERSION> 
    

必要なDockerイメージのビルド

まず、1つのコマンドで管理エージェントイメージをビルドします。

make -C tools/bosun_docker REGISTRY=registry.your-company.com push 

次に、同様のコマンドを使用して監視エージェントをビルドします。

備考

モデルの監視を有効にする予定がない場合は、この手順をスキップできます。

make -C tools/agent_docker REGISTRY=registry.your-company.com push 

新しい予測環境の作成

新しい予測環境を作成するには、 予測環境のドキュメントを参照してください。 予測環境IDを記録して後で使用します。

備考

現在、DataRobotおよびCustom Modelのモデル形式のみがサポートされています。

Helmチャートのインストール

DataRobotでは、エージェントを独自の名前空間にインストールすることをお勧めします。 これを行うには、事前に作成し、MLOps APIキーをインストールします。

# Create a namespace to contain the agent and all the models it deploys
kubectl create namespace datarobot-mlops

# You can use an existing key or we recommend creating a key dedicated to the agent
# by browsing here:
#   https://app.datarobot.com/account/developer-tools
kubectl -n datarobot-mlops create secret generic mlops-api-key --from-literal=secret=<YOUR-API-TOKEN> 

アカウントに合わせて、さまざまなクラウド環境(エージェントtarballの /tools/charts/datarobot-management-agent/examplesディレクトリにある)のいくつかの凡例の1つを変更できます。その後、次のコマンドの適切なバージョンを使用してエージェントをインストールできます。

helm upgrade --install bosun . \
    --namespace datarobot-mlops \
    --values ./examples/AKE_values.yaml 

提供されている例がニーズに合わない場合は、エージェントをインストールするための最小限のコマンドは以下になります。

helm upgrade --install bosun . \
    --namespace datarobot-mlops \
    --set predictionServer.ingressClassName=mlops \
    --set predictionServer.outfacingUrlRoot=http://your-company.com/deployments/ \
    --set datarobot.apiSecretName=mlops-api-key \
    --set datarobot.predictionEnvId=<PRED ENV ID> \
    --set managementAgent.repository=registry.your-company.com/datarobot/mlops-management-agent \
    --set trackingAgent.image=registry.your-company.com/datarobot/mlops-tracking-agent:latest \
    --set imageBuilder.ppsImage=registry.your-company.com/datarobot/datarobot-portable-prediction-api:<VERSION> \
    --set imageBuilder.generatedImageRepository=registry.your-company.com/mlops/frozen-models 

values.yamlファイル(エージェントtarballの/tools/charts/datarobot-management-agent/values.yamlにあります)または次のコマンドを使用して確認する追加設定がいくつかあります。

helm show values . 

更新しました December 5, 2023
Back to top