Kubernetes, Helm, Varnish, building vcl file

Question

What i'm facing right now is varnish deployment within my kube cluster (rke2).

Cluster contains 6 nodes, my application pods are spread across all of them with autoscaling.

Issue no.1:

Varnish requires proper setting of acl purgers and backend(s) including hostname & port, and store that config as *.vcl file (ConfigMap is fairly enough for such i belive)

Question no.1: How to "react" to changes within my aplication's replication and update ConfigMap?

Question no.2: How to "tell" varnish, to reload config file, when something withn my app has changed (changed number of backends, update purgers etc.)?

Question no.3: DaemonSet or StatefulSet for varnish? Honestly, i'd personally go with Daemon as it automatically installs itself within all nodes on cluster, however if i want to use similar mechanism (varnish) for different applications on my cluster, then this would create no. nodes * no. applications varnish pods.

Thanks for any kind of support

Answer 1

Use varnishreload to reload VCL at runtime

At this point in time, Varnish does compile-time processing of the backend definitions. This means a sudden change is not spotted at runtime and requires a varnishreload run to reload the VCL configuration. The same applies to ACLs, as you mentioned in your question.

The official Helm chart

At Varnish Software, we have an official Helm chart, but it refers to a Varnish Enterprise Docker image, which is the commercial version of Varnish.

We are currently working on an open source version of that Helm chart and I'll ask our engineers to keep the dynamic nature of a K8S cluster into account when creating it.

However, Varnish Enterprise does offer dynamic ACLs and dynamic backends, which tackles these issues quite easily. If you're interested, I suggest you have a look at the following Youtube video I created: https://www.youtube.com/watch?v=ELvwXh_gpyw.

I'm afraid you'll have to be a bit more patient when it comes to the open source version of our Helm chart. I'm hoping it will be done before summer though.

Using the internal DNS names of services as backends

Another approach to tackle the dynamic nature of Kubernetes, is by using the internal DNS name of services as your backend host.

Let's say you hypothetically have a service called hello-world that lives in the default namespace of your cluster. To use this as the backend of your Varnish server, you can simple specify the following backend definition in VCL:

backend default {
    .host = "hello-world.default.svc.cluster.local";
}

If the pods that are exposed via this service scale out or scale in, the service will reflect these changes in its internal service DNS name without changing to IP address of that service.

I'm guessing you could do the same thing in your ACL definition:

acl purgers
    "hello-world.default.svc.cluster.local";
    "some-other-service.default.svc.cluster.local";
}

Daemon Set or Stateful Set

I can't really give you a definitive answer on Daemon Sets vs Stateful Sets, however I can call you that the official Helm chart supports both.

I guess it depends on the situation. But I'm not really in a position to give solid advice on this.