Support NGINX Cache use cases with Cache Policy

[brianehlert]

During the past months there has been an increasing pace of questions raised about using the NGINX Ingress Controller in cache related use cases.
There is background here for folks unfamiliar: https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/

Many of these use cases take advantage of the dynamic cache capabilities of NGINX. However, they introduce the complexity of volume mounts which in turn introduces the question of the performance of the storage system behind the volume - to the extreme of RAMdisk.

Cache is a unique use case in Kubernetes. Initially you could say it is not a fit, but as we learn about the type of workloads that customers are hosing in Kubernetes you begin to learn about applications such as Moodle, or store applications that serve the same images over and over again, or other reasons where using ingress as a dynamic cache does make sense.

Not all cache management use cases make sense to enable at the ingress controller, after all it is not a replacement for a CDN. It is rather an augmentation to relieve some stress from the backend systems and give customers a better overall experience.

This might be a good fit for a Policy object. A cache Policy.
This aligns with cache being able to be set at http, server, location in NGINX conf. To align with ingress use cases, this is most likely server and location which align with Ingress, VirtualServer, and VirtualServer Route resources.

proxy_cache_path and the corresponding loader behavior can probably be set using defaults (at least initially) - if these were to be tunable attributes, they should be under the GlobalConfiguration or configMap resource.

Specifying what to cache and limiting or disabling caching and setting byte-range would be contained within the proposed cache Policy. And could be unique or shared across hostnames and paths.
these three sections can be seen in the above article

Purging is a questionable space. The act of manually purging cache is not very 'kubernetes" by nature. And the cache already has valid durations from the previous sections in the Policy. I elect to omit purging controls at this time.

This needs to be followed up with a Policy YAML proposal and a proposal about how to handle this through Helm.

[shaun-nx]

One thing to consider with the approach of using a Policy; it might collide with our jwt policy. Specifically if the policy is configured with a jwksUri

If we use JWKS then we add a proxy_cache_path in the http context.

{{ with $s.JWKSAuthEnabled }}
proxy_cache_path /var/cache/nginx/jwks_uri_{{$s.VSName}} levels=1 keys_zone=jwks_uri_{{$s.VSName}}:1m max_size=10m;
{{ end }}

If we go with the Policy approach, we might need to consider adding some collision check to ensure that we don't create duplicate proxy_cache_path entries.

[brianehlert]

While the jwks proxy_cache_path and the cache capability that I am discussing have very different intentions. This is a possible concern.
However, I think our current pattern of how the JWKS Uri proxy cache setting is contained to the location is adequate.

Using a policy object does give a way for the implementation to have a relational naming pattern, which should make isolating cache settings easier to implement.

I will admit the cache use cases are interesting and kind of unique. However, it is coming up more and more often.
There is simple, in-memory dynamic cache. One step further of requiring volumes. Responding with cached content when upstreams fail. All the way to CDN.
CDN is definitely not a fit IMHO.

[brianehlert]

One application example that we have is ingress controller in front of a Moodle installation.
Moodle is a content management system for education.
The use case is dynamic cache for items like: lesson plan docs, images.

In this example a very simple cache was configured:

proxy_cache_path /data/cache levels=1:2 keys_zone=moodle_cache:10m max_size=10g 
                 inactive=60m use_temp_path=off;

map $request_method $purge_method {
    PURGE 1;
    default 0;
}

location ~* \.(jpeg|js|jpg|png|css)$ {
        add_header X-Cache-Status $upstream_cache_status;
        proxy_set_header Accept-Encoding "";
        proxy_hide_header Cache-Control;
        proxy_cache_revalidate on;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_ignore_headers expires;
        proxy_ignore_headers Cache-Control;
        proxy_ignore_headers set-cookie;
        proxy_hide_header set-cookie;
        proxy_cache_valid any 30m;
        proxy_cache moodle_cache;
        proxy_set_header Host $host;
        proxy_pass http://moodle-backend/;

        proxy_cache_purge $purge_method;
    }

[brianehlert]

The goal of a Policy is to remove the complexity of needing to understand nginx configuration details.

An interesting example recently received looks like the following server and location -snippets:

The simplified experience could be
a Policy of:

And the simplified VirtualServer experience of: