Setting up Varnish Controller Agent

Introduction

Varnish Controller Agent is a process that runs alongside the Varnish Enterprise process and provides integration between Varnish Enterprise and Varnish Controller. Varnish Controller Agent talks to Varnish Controller via the NATS message bus, which can be located either inside or outside the Kubernetes cluster.

In a container deployment scenarios, Varnish Controller Agent is typically run in a sidecar to the main Varnish Enterprise container. Varnish Enterprise Helm Chart provides an easy way to integrate between the two components with a configuration flag.

Basic configuration

To enable Varnish Controller Agent integration, set server.secret and server.agent.enabled:

---
server:
  secret: "RandomVarnishSecretString"  # secret is required to be set
  agent:
  	enabled: true

The Varnish Controller Agent integration also has a few other options, such as tags, and location, which will be used as static tags and location metadata within the Varnish Controller. To configure tags and location metadata, set server.agent.tags and server.agent.location accordingly:

server:
  secret: "RandomVarnishSecretString"
  agent:
    enabled: true

    tags:
      - "tokyodc"
      - "highmem"

    location:
      latitude: "35.652832"
      longitude: "139.839478"

Configuring NATS

Varnish Controller Agent integration by default will assume that Varnish Controller (and the internal NATS) are running in the same Kubernetes namespace as the Varnish Enterprise pod. In the case where Varnish Enterprise and Varnish Controller with internal NATS are deployed in a different namespace, it is necessary to also set global.natsServer.internal.namespace accordingly:

---
global:
  natsServer:
    internal:
      namespace: "varnish-controller"

It is also possible to configure the Varnish Controller Agent to use an external address for NATS. In this case, Varnish Controller must also be configured to use the same NATS. This can be done by configuring global.natsServer.internal.enabled and global.natsServer.externalAddress in both the Varnish Enterprise Helm Chart and Varnish Controller Helm Chart:

---
global:
  natsServer:
    externalAddress: "nats://external-nats.example.com:4222"
    internal:
      enabled: false

Configuring state persistency

Enabling state persistency for Varnish Controller Agent allows Varnish Controller Agent to restore the latest known good state when it cannot connect to NATS, providing extra resiliency.

As VolumeClaimTemplate is only available in StatefulSet, enabling Varnish Controller Agent state persistency with a persistent disk requires configuring such. To do so, configure server.kind and server.agent.persistence.enabled accordingly:

---
server:
  kind: "StatefulSet"
  agent:
    persistence:
      enabled: true
      storageSize: "512Mi"

Some volume plugins, such as NFS, can be mounted multiple times without requiring VolumeClaimTemplate. In such cases, other types of workloads (such as Deployment) can be used. Set server.extraVolumes and server.agent.persistence.enableWithVolume to use volume backed by alternative volume plugins:

---
server:
  agent:
    persistence:
      enableWithVolumeName: agent-hostpath

  extraVolumes:
    - name: agent-hostpath
      nfs:
        server: nfs.example.com
        path: /path/to/agent