为什么不应该'；难道你不能从Composer那里运行Kubernetes吊舱超过一个小时吗？

明确声明：

由于Kubernetes Python客户端库存在问题，Kubernetes吊舱的设计应确保运行时间不超过一小时

然而，它没有提供更多的上下文，我也找不到关于Kubernetes Python客户端项目的明确相关问题

---

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

我对Cloud Composer或Kubernetes Python客户端库生态系统都不太熟悉，但按大多数评论对GitHub问题跟踪程序进行排序后，列表顶部会显示以下打开的项目：

听起来好像存在令牌过期问题：

@yliaog这对我们来说是个问题，因为我们正在运行kubernetes吊舱 批处理，并使用静态 客户初始化客户端对象后，它不会刷新，并且 因此，任何耗时超过60分钟的作业都将失败。看 通过PythonBase，我们似乎可以创建一个 每n分钟生成一个新客户端（或刷新配置），或 在每次通话前检查状态（如@mvle建议的）。最佳解决方案 可能是大摇大摆的codegen，但可能会有一个临时解决方案 对很多人都很有用

-@flylo

还有更多的见解

目前，GKE上长期运行的作业最终总是会失败，并出现404错误（）。我们认为问题出在Kubernetes客户端，因为我们确定，尽管在令牌过期时调用了_refresh_gcp_令牌，但下一个API调用仍然失败，并出现404错误

您可以看到它使用了kubernetes python客户端。

就是原因（希望我的修复程序很快就会合并）。正如其他人所建议的，这会影响使用带有GCP auth的Kubernetes Python客户端的任何人。如果您正在使用Kubernetes服务帐户进行身份验证，您应该不会看到任何问题

---

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

看起来文档团队忘了与工程师联系。