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
セクションを更新して、前の手順で作成したannotations
とname
を使用して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の開発者ツールからダウンロードすることです。 ダウンロードが完了したら、次のコマンドを実行します。
-
PPS Dockerイメージを読み込みます。
docker load < datarobot-portable-prediction-api-<VERSION>.tar.gz
-
イメージ名でPPS Dockerイメージにタグを付けます。
備考
latest
を<VERSION>
タグとして使用しないでください。docker tag datarobot/datarobot-portable-prediction-api:<VERSION> registry.your-company.com/datarobot/datarobot-portable-prediction-api:<VERSION>
-
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 .