<p>I'm currently migrating a legacy server to Kubernetes, and I found that <code>kubectl</code> or dashboard only shows the latest log file, not the older versions.  In order to access the old files, I have to ssh to the node machine and search for it.</p>

<p>In addition to being a hassle, my team wants to restrict access to the node machines themselves, because they will be running pods from many different teams and unrestricted access could be a security issue.</p>

<p>So my question is: can I configure Kubernetes (or a Docker image) so that these old (rotated) log files are stored in some directory accessible from inside the pod itself?</p>

<ul>
<li>Of course, in a pinch, I could probably just execute something like <code>run_server.sh | tee /var/log/my-own.log</code> when the pod starts... but then, to do it correctly, I'll have to add the whole logfile rotation functionality, basically duplicating what Kubernetes is already doing.</li>
</ul>

jick
<p>So there are a couple of ways to and scenarios for this. If you are just interested in the log of the same pod from before last restart, you can use the <code>--previous</code> flag to look at logs:</p>

<pre><code>kubectl logs -f &lt;pod-name-xyz&gt; --previous
</code></pre>

<p>But since in your case, you are interested in looking at log files beyond one rotation, here is how you can do it. Add a sidecar container to your application container:</p>

<pre><code> volumeMounts:
    - name: varlog
      mountPath: /tmp/logs
  - name: log-helper
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/*.log']
    volumeMounts:
    - name: varlog
      mountPath: /tmp/logs
volumes:
  - name: varlog
    hpostPath: /var/log
</code></pre>

<p>This will allow the directory which has all logs from <code>/var/log</code> directory from host to <code>/tmp/log</code> inside the container and the command will ensure that content of all files is flushed. Now you can run:</p>

<pre><code>kubectl logs &lt;pod-name-abc&gt; -c count-log-1
</code></pre>

<p>This solution does away with SSH access, but still needs access to kubectl and adding a sidecar container. I still think this is a bad solution and you consider of one of the options from the cluster level logging architecture documentation of Kubernetes such as <a href="https://kubernetes.io/docs/concepts/cluster-administration/logging/#using-a-node-logging-agent" rel="nofollow noreferrer">1</a> or <a href="https://kubernetes.io/docs/concepts/cluster-administration/logging/#using-a-sidecar-container-with-the-logging-agent" rel="nofollow noreferrer">2</a></p>
