一家公司在本地 Kubernetes 集群上运行 ML 工作负载。每个 ML 服务都打包为独立的 Docker 镜像。他们需要以最少的运维开销迁移到 Amazon EKS 集群。哪种解决方案符合此要求？

正确答案是将 Docker 镜像推送到 Amazon ECR 并配置部署管道。由于现有的 ML 服务已经打包为独立的 Docker 镜像，这种方法最大限度地减少了重构工作。Amazon ECR 是一个完全托管的 Docker 容器注册表，与 EKS 无缝集成，提供高可用性和安全性。配置部署管道（例如使用 AWS CodePipeline 和 AWS CodeBuild）可以自动化将这些镜像部署到 EKS 集群的过程，从而实现最小的运维开销。 重新设计 ML 服务以在 Kubeflow 下运行会引入显著的开发和运维开销，因为它需要对现有服务进行大量修改以适应 Kubeflow 的架构。将训练数据移动到 Amazon Redshift 并使用 Amazon Redshift ML 重新训练模型，或者创建 Amazon SageMaker notebook 并重新训练模型，都涉及重新训练和重新部署模型，这超出了将现有 Docker 化 ML 工作负载迁移到 EKS 的范围，并且会产生额外的工作量和潜在的兼容性问题。