<p>I have a kubernetes cluster with a gitlab-runner 10.3.0 and kubernetes executor. There is no <code>cache_dir</code> defined in the runner's config.toml-file. Note that this is different that a docker executor, so the volume-solutions do not apply.</p>

<p>In a <code>.gitlab-ci.yml</code>, I configured a job to use the cache:</p>

<pre><code>build:
  cache:
    key: "${PROJECT_NAME}"
    paths:
      - "node_modules/"
  script:
    - ls node_modules/ || echo "cache not there"
    - npm i
    - npm build
    - ...
</code></pre>

<p>When I run this, I see the cache being pulled and created:</p>

<pre><code>Cloning repository for some-branch with git depth set to 1...
Cloning into '/group/projectname'...
Checking out d03baa31 as some-branch...
Skipping Git submodules setup
Checking cache for projectname...
Successfully extracted cache
$ docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
//
// ...work being done here... 
//
Creating cache projectname...
node_modules/: found 24278 matching files
Created cache
Job succeeded
</code></pre>

<p>However, when I push another commit to this branch, the <code>ls node_modules/</code> still does not find the cache.</p>

<p>I searched the documentation and did not find any information on how to activate the cache. The gitlab-runner-pod does not have any of the supposedly cached files there as well and <a href="https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section" rel="noreferrer">according to the documentation</a>, a <code>cache_dir</code> in the config is not used by the kubernetes executor.</p>

<p>But according to <a href="https://docs.gitlab.com/runner/executors/#compatibility-chart" rel="noreferrer">this feature page</a>, the kubernetes executor <em>does</em> support cache.</p>

<p>So how to do this?</p>

<p>Due to the distributed nature of Kubernetes, you will need to configure a central cache location (typically, in the form of a S3-compatible object storage like <a href="https://aws.amazon.com/s3" rel="nofollow noreferrer">AWS S3</a> or <a href="https://www.minio.io/" rel="nofollow noreferrer">Minio</a>). The reason behind this is explained in the <a href="https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching" rel="nofollow noreferrer">Gitlab runner documentation</a> (emphasis mine):</p>
<blockquote>
<p>To speed up your builds, GitLab Runner provides a cache mechanism where selected directories and/or files are saved and shared between subsequent builds.</p>
<p>This is working fine when builds are run on the same host, <strong>but when you start using the Runners autoscale feature, most of your builds will be running on a new (or almost new) host, which will execute each build in a new Docker container. In that case, you will not be able to take advantage of the cache feature.</strong></p>
<p>To overcome this issue, together with the autoscale feature, the distributed Runners cache feature was introduced.</p>
<p>It uses any S3-compatible server to share the cache between used Docker hosts. When restoring and archiving the cache, GitLab Runner will query the S3 server and will download or upload the archive.</p>
</blockquote>
<p>For this, you can use the <a href="https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscache-section" rel="nofollow noreferrer"><code>[runners.cache] section</code></a> in the runner configuration:</p>
<pre><code>[runners.cache]
  Type = &quot;s3&quot;
  ServerAddress = &quot;s3.amazonaws.com&quot;
  AccessKey = &quot;AMAZON_S3_ACCESS_KEY&quot;
  SecretKey = &quot;AMAZON_S3_SECRET_KEY&quot;
  BucketName = &quot;runners&quot;
  BucketLocation = &quot;eu-west-1&quot;
  Insecure = false
  Path = &quot;path/to/prefix&quot;
  Shared = false
</code></pre>
<p><em>Edit by OP:</em> <a href="https://docs.gitlab.com/runner/install/autoscaling.html#install-the-cache-server" rel="nofollow noreferrer">Installation instructions for Minio for gitlab-ci</a></p>
