<p><a href="https://cloud.google.com/composer/docs/how-to/using/using-kubernetes-pod-operator" rel="nofollow noreferrer">The Cloud Composer documentation</a> explicitly states that:</p>

<blockquote>
  <p>Due to an issue with the Kubernetes Python client library, your Kubernetes pods should be designed to take no more than an hour to run.</p>
</blockquote>

<p>However, it doesn't provide any more context than that, and I can't find a definitively relevant issue on the Kubernetes Python client project.</p>

<p>To test it, I ran a pod for two hours and saw no problems. What issue creates this restriction, and how does it manifest? </p>

Mike Precup
<p>I'm not deeply familiar with either the Cloud Composer or Kubernetes Python client library ecosystems, but sorting the GitHub issue tracker by most comments shows this open item near the top of the list: <a href="https://github.com/kubernetes-client/python/issues/492" rel="nofollow noreferrer">https://github.com/kubernetes-client/python/issues/492</a></p>

<p>It sounds like there is a token expiration issue:</p>

<blockquote>
  <p>@yliaog this is an issue for us, as we are running kubernetes pods as
  batch processes and tracking the state of the pods with a static
  client. Once the client object is initialized, it does no refresh, and
  therefore any job that takes longer than 60 minutes will fail. Looking
  through python-base, it seems like we could make a wrapper class that
  generates a new client (or refreshes the config) every n minutes, or
  checks status prior to every call (as @mvle suggested). The best fix
  would be in swagger-codegen, but a temporary solution would probably
  be very useful for a lot of people.</p>
  
  <p>- @flylo, <a href="https://github.com/kubernetes-client/python/issues/492#issuecomment-376581140" rel="nofollow noreferrer">https://github.com/kubernetes-client/python/issues/492#issuecomment-376581140</a></p>
</blockquote>
