共计 5501 个字符，预计需要花费 14 分钟才能阅读完成。
创立一个牢靠、高效的机器学习推理服务须要做很多的投入。到底多麻烦？以一个基于 XGBoost 模型的服务来说：
- 开发人员须要创立一个欠缺的应用程序，例如通过 Flask 来加载模型，而后运行终端节点。
- 为了创立这个应用程序，开发人员须要思考队列治理、无故障部署以及从新加载新训练的模型等事宜。
- 利用开发好后被打包成容器镜像，而后推送到镜像仓库。Kubernetes 从镜像仓库拉取该镜像在集群上进行部署，部署好后才能够对外提供服务。
- 这些步骤须要数据科学家从事与进步模型准确性无关的工作，或引进 DevOps 工程师来做这些工作。
- 这些过程加到开发计划中，必然会须要更多的工夫进行服务迭代。
AWS 最近公布了实用于 Kubernetes 的 Amazon SageMaker Operator，借此，咱们能够用 SageMaker 托管的终端节点加强现有 Kubernetes 集群。借助 SageMaker Operator，开发人员只须要编写 yaml 文件来指定所保留模型的 S3 存储地位，而实时预测通过平安的终端节点即可应用。重新配置终端节点与更新 yaml 文件一样简略。
除了应用简略外，该服务还具备以下特色：
- 多模型终端节点 – 托管几十个或更多模型可能会给配置带来艰难，并且会导致很多机器以低利用率运行。多模型终端节点通过动静加载用于服务的模型构件来设置一个实例；
- 弹性推理 – 在拆离开的 GPU 上运行较小的工作负载，能够以较低的老本部署该 GPU；
- 高利用率和动静 Auto Scaling – 终端节点能够以 100% 的利用率运行，并基于咱们定义的自定义指标（如每秒钟的调用数量）来增加正本。或者能够按预约义的客户端性能指标配置主动扩大；
- 可用区转移 – 如果产生中断，Amazon SageMaker 会将终端节点主动挪动到 VPC 内的另一个可用区；
- A/B 测试– 设置多个模型，并导向与单个终端节点上设置的量成比例的流量；
- 安全性 – 终端节点应用 HTTPS 创立，可配置为在公有 VPC（没有互联网进口）中运行并通过 AWS PrivateLink 拜访；
- 合规性筹备 – Amazon SageMaker 曾经过认证，合乎 HIPAA、PCI DSS 和 SOC (1, 2, 3) 规定和法规。
AWS 为 Kubernetes 开发的 SageMaker Operator 将以上这些个性打包到一起。SageMaker Operator 大大缩短模型到利用的工夫，并缩小创立和保护生产环境的人力。这能够使独自应用 EKS 或 EC2 的总领有老本降落 90%。
本文演示如何设置实用于 Kubernetes 的 Amazon SageMaker Operator，以齐全从 kubectl 为事后训练的 XGBoost 模型创立和更新终端节点。该解决方案蕴含以下步骤：
- 创立 IAM Amazon SageMaker 角色，提供服务模型所需的 Amazon SageMaker 权限
- 筹备 YAML 文件，以将模型部署到 Amazon SageMaker
- 将模型部署到 Amazon SageMaker
- 查问终端节点以获取预测
- 对部署的模型执行最终的一致性更新
先决条件
本文假如合乎以下先决条件：
- 一个 Kubernetes 集群
- 集群上已装置 Amazon SageMaker Operator
- 一个能够部署的 XGBoost 模型
无关将 Operator 装置到 Amazon EKS 集群上的信息，请参阅现已推出实用于 Kubernetes 的 Amazon SageMaker Operator。咱们能够自带 XGBoost 模型，但本教程应用后面所述文中的现有模型。
创立一个 Amazon SageMaker 执行角色
Amazon SageMaker 须要一个 IAM 角色，它能够承当该角色来服务您的模型。如果还没有该角色，请应用上面的 bash 代码创立一个：
export assume_role_policy_document='{"Version":"2012-10-17","Statement": [{"Effect":"Allow","Principal": {"Service":"sagemaker.amazonaws.com"},"Action":"sts:AssumeRole"
}]
}'
aws iam create-role --role-name <execution role name> \
--assume-role-policy-document \
"$assume_role_policy_document"
aws iam attach-role-policy --role-name <execution role name> \
--policy-arn \
arn:aws:iam::aws:policy/AmazonSageMakerFullAccess将 <execution role name> 替换为实用的角色名称。这将创立一个 IAM 角色，Amazon SageMaker 能够应用该角色来服务咱们的模型。
筹备托管部署
Operator 提供名为 HostingDeployment 的自定义资源定义 (CRD)。咱们能够应用 HostingDeployment 在 Amazon SageMaker 托管上配置模型部署。
要筹备托管部署，请应用以下内容创立名为 hosting.yaml 的文件：
apiVersion: sagemaker.aws.amazon.com/v1
kind: HostingDeployment
metadata:
name: hosting-deployment
spec:
region: us-east-2
productionVariants:
- variantName: AllTraffic
modelName: xgboost-model
initialInstanceCount: 1
instanceType: ml.r5.large
initialVariantWeight: 1
models:
- name: xgboost-model
executionRoleArn: SAGEMAKER_EXECUTION_ROLE_ARN
containers:
- containerHostname: xgboost
modelDataUrl: s3://BUCKET_NAME/model.tar.gz
image: 825641698319.dkr.ecr.us-east-2.amazonaws.com/xgboost:latest 将 SAGEMAKER_EXECUTION_ROLE_ARN 替换为在上一步中创立的执行角色的 ARN。将 BUCKET_NAME 替换为蕴含模型的存储桶。
确保存储桶区域 HostingDeployment 区域和映像 ECR 区域统一。
将模型部署到 Amazon SageMaker
随后能够通过运行 kubectl apply -f hosting.yaml 来启动部署。请参阅以下代码：
$ kubectl apply -f hosting.yaml
hostingdeployment.sagemaker.aws.amazon.com/hosting-deployment created咱们能够应用 kubectl get hostingdeployments 跟踪部署状态。请参阅以下代码：
$ kubectl get hostingdeployments
NAME STATUS SAGEMAKER-ENDPOINT-NAME
hosting-deployment Creating hosting-deployment-38ecac47487611eaa81606fc3390e6ba模型终端节点最多可能须要十五分钟能力部署好。咱们能够应用以下命令查看状态。终端节点达到 InService 状态后便能够立刻用于查问。
$ kubectl get hostingdeployments
NAME STATUS SAGEMAKER-ENDPOINT-NAME
hosting-deployment InService hosting-deployment-38ecac47487611eaa81606fc3390e6ba查问终端节点
终端节点投入使用后，能够测试它是否能与以下示例代码联合应用：
$ aws sagemaker-runtime invoke-endpoint \
--region us-east-2 \
--endpoint-name SAGEMAKER-ENDPOINT-NAME \
--body $(seq 784 | xargs echo | sed 's/ /,/g') \
>(cat) \
--content-type text/csv > /dev/nullbash 命令应用 AWS CLI 与 HTTPS 终端节点连贯。咱们创立的模型基于 MNIST 位数据集，预测工具会读取图像中的数字。当进行此调用时，它会以 CSV 格局发送蕴含 784 项特色的推理负载，这些特色代表图像中的像素。咱们将在负载中看到模型所认为的预测数字。请参阅以下代码：
$ aws sagemaker-runtime invoke-endpoint \
--region us-east-2 \
--endpoint-name hosting-deployment-38ecac47487611eaa81606fc3390e6ba \
--body $(seq 784 | xargs echo | sed 's/ /,/g') \
>(cat) \
--content-type text/csv > /dev/null
8.0此代码确认终端节点已启动并在运行。
最终统一的更新
部署好模型后，咱们能够对 Kubernetes YAML 进行更改，SageMaker Operator 将更新终端节点。这些更新将以最终统一的形式流传到 Amazon SageMaker。这样一来，咱们便能够以申明式的形式配置终端节点，并让 SageMaker Operator 解决细节。
为证实这一点，咱们能够将模型的实例类型从 ml.r5.large 更改为 ml.c5.2xlarge。请执行以下步骤：
- 将 hosting.yaml 中的实例类型批改为 ml.c5.2xlarge。请参阅以下代码：
apiVersion: sagemaker.aws.amazon.com/v1
kind: HostingDeployment
metadata:
name: hosting-deployment
spec:
region: us-east-2
productionVariants:
- variantName: AllTraffic
modelName: xgboost-model
initialInstanceCount: 1
instanceType: ml.c5.2xlarge
initialVariantWeight: 1
models:
- name: xgboost-model
executionRoleArn: SAGEMAKER_EXECUTION_ROLE_ARN
containers:
- containerHostname: xgboost
modelDataUrl: s3://BUCKET_NAME/model.tar.gz
image: 825641698319.dkr.ecr.us-east-2.amazonaws.com/xgboost:latest- 将更改利用至 Kubernetes 集群。请参阅以下代码：
$ kubectl apply -f hosting.yaml
hostingdeployment.sagemaker.aws.amazon.com/hosting-deployment configured- 获取托管部署的状态。该状态将显示为正在更新，而后在筹备好当前更改为 InService。请参阅以下代码：
$ kubectl get hostingdeployments
NAME STATUS SAGEMAKER-ENDPOINT-NAME
hosting-deployment Updating hosting-deployment-38ecac47487611eaa81606fc3390e6ba终端节点在整个更新过程中放弃实时状态且齐全可用。无关更多信息和其余示例，请参阅 GitHub 存储库。
清理
要删除终端节点而不会产生更多应用费用，请运行 kubectl delete -f hosting.yaml。请参阅以下代码：
$ kubectl delete -f hosting.yaml
hostingdeployment.sagemaker.aws.amazon.com "hosting-deployment" deleted论断
本文演示了实用于 Kubernetes 的 Amazon SageMaker Operator 如何反对实时推理。它还反对训练和超参数调整。
心愿大家能分享本人的教训和反馈，或者提交其余示例 YAML 标准或 Operator 改良信息。大家能够分享应用实用于 Kubernetes 的 Amazon SageMaker Operator 的相干状况，在 AWS 论坛中的 Amazon SageMaker 的板块下公布帖子，在 GitHub 存储库中创立问题，或发送给 AWS Support 联系人并由其代为转达。
