3

Cloud Composer 文档明确指出：

由于 Kubernetes Python 客户端库存在问题，您的 Kubernetes pod 应设计为运行时间不超过一小时。

但是，它没有提供比这更多的上下文，而且我在 Kubernetes Python 客户端项目上找不到明确相关的问题。

为了测试它，我运行了一个 pod 两个小时，没有发现任何问题。什么问题造成了这种限制，它是如何体现的？

4

3 回答 3

2

我对 Cloud Composer 或 Kubernetes Python 客户端库生态系统都不是很熟悉，但是按照大多数评论对 GitHub 问题跟踪器进行排序显示，这个打开的项目位于列表顶部附近：https ://github.com/kubernetes-client/蟒蛇/问题/492

听起来有一个令牌过期问题：

@yliaog 这对我们来说是个问题，因为我们将 kubernetes pod 作为批处理运行并使用静态客户端跟踪 pod 的状态。一旦客户端对象被初始化，它就不会刷新，因此任何耗时超过 60 分钟的作业都会失败。查看 python-base，似乎我们可以创建一个包装类，每 n 分钟生成一个新客户端（或刷新配置），或者在每次调用之前检查状态（如 @mvle 建议的那样）。最好的解决方案是使用 swagger-codegen，但临时解决方案可能对很多人非常有用。

- @flylo，https://github.com/kubernetes-client/python/issues/492#issuecomment-376581140

于 2018-10-24T23:31:32.373 回答
2

https://issues.apache.org/jira/browse/AIRFLOW-3253是原因（希望我的修复很快会合并）。正如其他人所建议的那样，这会影响任何使用具有 GCP 身份验证的 Kubernetes Python 客户端的人。如果您使用 Kubernetes 服务帐户进行身份验证，则应该没有问题。

如果您通过 gcloud 的 GCP 服务帐户进行身份验证（例如，使用 GKEPodOperator），您通常会在作业耗时超过一小时时看到此问题，因为身份验证令牌在一小时后过期。

于 2018-11-02T19:26:06.637 回答
1

这里也有更多的见解。

目前，GKE 上长时间运行的作业最终总是会因 404 错误而失败（https://bitbucket.org/snakemake/snakemake/issues/932/long-running-jobs-on-kubernetes-fail）。我们认为问题出在 Kubernetes 客户端，因为我们确定虽然在令牌过期时调用了 _refresh_gcp_token，但下一次 API 调用仍然失败并出现 404 错误。

你可以在这里看到Snakemake使用了 kubernetes python 客户端。

于 2018-10-24T23:53:57.503 回答