kubeflow部署的ml-pipeline pod处于CrashLoopBackOff中
我对 kubeflow 设置的实践非常有限。我已在 EKS 集群上部署了 kubeflow 管道，并为工件提供了 S3 连接。除了 ml-pipeline 部署之外，所有 Pod 均已启动并运行，而且由于依赖于 ml-pipeline，ml-pipeline-persistence 代理部署也失败。
我在检查 Pod 日志时遇到以下错误：
I0321 19:19:49.514094 7 config.go:57] Config DBConfig.ExtraParams not specified, skipping
F0321 19:19:49.812472 7 client_manager.go:400] Failed to check if Minio bucket exists. Error: Access Denied.
如果有人遇到类似问题，我无法找到许多可以帮助我调试问题的日志。
此外，ml-pipeline 部署使用的用于访问存储桶的凭据具有所有必需的权限。
I have very limited hands-on over the kubeflow setup. I have deployed a kubeflow pipeline on an EKS cluster with S3 connectivity for the artifacts. All the pods are up and running except the ml-pipeline deployment and also ml-pipeline-persistence agent deployment is failing due to the dependency on the ml-pipeline.
I am facing the below error while checking the logs of the pods:
I0321 19:19:49.514094 7 config.go:57] Config DBConfig.ExtraParams not specified, skipping
F0321 19:19:49.812472 7 client_manager.go:400] Failed to check if Minio bucket exists. Error: Access Denied.
Had anyone faced similar issues, I am not able to find many logs which could help me to debug the issue.
Also, the credentials consumed by the ml-pipeline deployment to access the bucket have all the required permissions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
检查分配给您为 MINIO_AWS_ACCESS_KEY_ID 设置的 aws 凭证的 S3 权限MINIO_AWS_SECRET_ACCESS_KEY。这就是给我造成同样错误的原因。
尽管 kubeflow 的 aws 发行版提供的 auto-rds-s3-setup.py 设置程序可以创建 s3 存储桶，但传递到 MINITO 的凭证必须启用对该存储桶的访问。因此它们主要用于重用现有的 s3 存储桶。
Check the S3 permissions assigned to the aws credentials you set for MINIO_AWS_ACCESS_KEY_ID & MINIO_AWS_SECRET_ACCESS_KEY. That is what caused the same error for me.
Although the auto-rds-s3-setup.py setup program provided by the aws distribution of kubeflow can create the s3 bucket, the credentials passed in to MINITO have to enable access to that bucket. So they are primarily for reusing an existing s3 bucket.