Question: Internal workings of Varnish Helm chart purging with multiple replicas

[Manikkumar1988]

I wanted to use the official Varnish Helm chart to deploy a Varnish cluster with HPA enabled.

When I send a PURGE request, Can you explain how purging works in this setup and provide recommendations for ensuring consistent purging across all replicas?

Wanted to ensure cache invalidated across all replicas & get the acknowledgment for the same.

[sirn]

Hi there! Varnish Helm Chart currently doesn't do anything special with regarding networking and purging. In the Enterprise version, we have varnish-broadcaster and varnish-discovery for this purpose, but for the open-source version you have to manually do this for every instance.

Right now, the only way to iterate the list of all available Varnish instances is to set up Varnish Helm Chart in a headless ClusterIP mode, e.g.:

server:
  service:
    type: ClusterIP
    clusterIP: "None"

This allows service-name.namespace.svc.cluster.local to resolve an A record to each individual Varnish instance. Then, on the component that's sending purges, you can make sure it sends PURGE to all A records returned by the cluster's DNS.

Alternatively, there's something like varnish-towncrier that might work (although I have not tried it myself). This could be set up through server.extraContainers. Since towncrier doesn't rely on Varnish VSM, it should be pretty straightforward to set up:

server:
  extraContainers:
    - name: towncrier
      image: ghcr.io/emgag/varnish-towncrier:latest
      args:
        - listen
      env:
        - name: VT_REDIS_URI
          value: redis://redis-service
        # Match this with `server.http.port`
        - name: VT_ENDPOINT_URI
          value: http://127.0.0.1:6081/
      # the rest of the configuration

I'm going to ping @gquintard and @ThijsFeryn if they have a better idea :-)

[rptaylor]

There's a way to get a Service pointing to each member of a Statefulset, something like this (based on https://gitlab.cern.ch/eos/eos-charts/-/merge_requests/53/)

{{- if .Values.individualService.enabled }}
{{- range $i, $e := until ( .Values.replicaCount | int) }}
---
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-{{ $i | int }}
spec:
  {{- $.Values.individualService.template | toYaml | trim | nindent 2 }}
  selector:
    statefulset.kubernetes.io/pod-name: {{ .Release.Name }}-{{ $i | int }}
  ports:
    - port: 1234
      targetPort: 1234
      protocol: TCP
      name: something
{{- end }}
{{- end }}

If Release.Name is "varnish" and there is a statefulset named "varnish", then this will result in services varnish-0, varnish-1, varnish-2, ... each pointing to the respective pod in the statefulset, allowing each one to be addressed individually.

[sirn]

@rptaylor thanks for the suggestion; that's a great idea. We might do this.