<p>We have a case where we need to make sure that pods in k8s have the latest version possible. <em>What is the best way to accomplish this</em>?</p>

<p>First idea was to kill the pod after some point, knowing that the new ones will come up pulling the latest image. Here is <a href="https://github.com/kubernetes/kubernetes/pull/7868/commits/82163326117f095e75b4f1f1d830eb95667e86e6" rel="nofollow noreferrer">what we found so far</a>. Still don't know how to do it.</p>

<p>Another idea is having <code>rolling-update</code> executed in intervals, like every 5 hours. Is there a way to do this?</p>

<p>As mentioned by @svenwltr using <code>activeDeadlineSeconds</code> is an easy option but comes with the risk of loosing all pods at once. To mitigate that risk I'd use a <code>deployment</code> to manage the pods and their rollout, and configure a small second container along with the actual application. The small helper could be configured like this (<a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/" rel="nofollow noreferrer">following the official docs</a>):</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: app-liveness
spec:
  containers:
  - name: liveness
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep $(( RANDOM % (3600) + 1800 )); rm -rf /tmp/healthy; sleep 600
    image: gcr.io/google_containers/busybox

    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

  - name: yourapplication
    imagePullPolicy: Always
    image: nginx:alpine
</code></pre>

<p>With this configuration every pod would break randomly within the configured timeframe (here between 30 and 90mins) and that would trigger the start of a new pod. The <code>imagePullPolicy: Always</code> would then make sure that the image is updated during that cycle.</p>

<p>This of course assumes that your application versions are always available under the same name/tag.</p>
