This tool basically multiplexes PURGE requests on Varnish Cache instances at the same time to manage the cache properly. If you are using Varnish Enterprise, you already have that feature.
varnish-cache-invalidator can be used for standalone Varnish instances or Varnish pods inside a Kubernetes cluster.
Standalone mode In that mode, varnish-cache-invalidator multiplexes requests on static standalone Varnish instances which are provided with --targetHosts flag. This flag gets comma seperated list of hosts.
Please check all the command line arguments on Configuration section. Required args for standalone mode:
--inCluster=false
--targetHosts
Kubernetes mode In that mode, varnish-cache-invalidator discovers kube-apiserver for running Varnish pods inside Kubernetes and multiplexes PURGE requests on them at the same time to manage the cache properly.
Please check all the command line arguments on Configuration section. Required args for Kubernetes mode:
--inCluster=true
varnish-cache invalidator requires Kustomize for in-kubernetes installations. You can refer here for Kustomize installation.
If you run below command in the deployment directory, it will take following actions:
- Deploy varnish-cache-invalidator in the default namespace
- Deploy varnish instance with sample default.vcl for testing purposes in the default namespace
- Deploy nginx instance for testing purposes in the default namespace
Here is the command:
$ kustomize build . | kubectl apply -f -
After all of the deployments are succeeded, when you make a GET request to the varnish instance with proper header, you will get following response. Notice X-Cache and X-Cache-Hits response headers. This indicates that our requests are successfully hitting the varnish:
$ curl ${WORKER_NODE_IP}:${VARNISH_NODE_PORT} -H "Host: nginx.default.svc" -v
... omitted
Age: 22
X-Cache: HIT
X-Cache-Hits: 12
... omitted
And yes, you can deploy each component separately to the Kubernetes with previous command on relevant directory. For example if you just want to deploy varnish-cache-invalidator, run below command in deployment/invalidator directory:
$ kustomize build . | kubectl apply -f -
You can use binary method to manage standalone Varnish instances, not in Kubernetes. Binary can be downloaded from Releases page.
After then, you can simply run binary by providing required command line arguments:
$ ./varnish-cache-invalidator --inCluster=false --targetHosts 10.0.0.100:6081,10.0.0.101:6081,10.0.0.102:6081
Varnish-cache-invalidator can be customized with several command line arguments. You can check sample in-Kubernetes deployment file for how it goes. Here is the list of arguments you can pass:
--inCluster bool InCluster is the boolean flag if varnish-cache-invalidator is running inside cluster or not,
defaults to true
--varnishNamespace string VarnishNamespace is the namespace of the target Varnish pods, defaults to default namespace
--varnishLabel string VarnishLabel is the label to select proper Varnish pods, defaults to app=varnish
--targetHosts string TargetHosts used when our Varnish instances(comma seperated) are not running in Kubernetes as
a pod, required for standalone Varnish instances, defaults to 'http://127.0.0.1:6081'
--serverPort int ServerPort is the web server port of the varnish-cache-invalidator, defaults to 3000
--metricsPort int MetricsPort is the port of the metrics server, defaults to 3001
--writeTimeoutSeconds int WriteTimeoutSeconds is the write timeout of the both web server and metrics server, defaults to 10
--readTimeoutSeconds int ReadTimeoutSeconds is the read timeout of the both web server and metrics server, defaults to 10
TBD
This project requires below tools while developing:
- Golang 1.20
- pre-commit
- golangci-lint - required by pre-commit
- gocyclo - required by pre-commit
After you installed pre-commit, simply run below command to prepare your development environment:
$ pre-commit install -c build/ci/.pre-commit-config.yaml
Apache License 2.0
varnish-cache-invalidator uses client-go to interact
with kube-apiserver
. client-go uses the service account token
mounted inside the Pod at the /var/run/secrets/kubernetes.io/serviceaccount
path while initializing the client.
If you have RBAC enabled on your cluster, when you followed the deployment steps on Kubernetes section, it will create required serviceaccount and clusterrolebinding and then use that serviceaccount to be used by our varnish-cache-invalidator pods.
If RBAC is not enabled on your cluster, please follow that documentation to enable it.