VLSingle #

VLSingle represents database for storing logs. The VLSingle CRD declaratively defines a single-node VictoriaLogs installation to run in a Kubernetes cluster.

For each VLSingle resource, the Operator deploys a properly configured Deployment in the same namespace. The VLSingle Pods are configured to mount an empty dir or PersistentVolumeClaimSpec for storing data. Deployment update strategy set to recreate . No more than one replica allowed.

For each VLSingle resource, the Operator adds Service and VMServiceScrape in the same namespace prefixed with name from VLSingle.metadata.name.

Specification #

You can see the full actual specification of the VLSingle resource in the API docs -> VLSingle .

If you can’t find necessary field in the specification of the custom resource, see Extra arguments section .

Also, you can check out the examples section.

High availability #

VLSingle doesn’t support high availability. Consider using VLCluster or multiple VLSingle resources.

Version management #

To set VLSingle version add spec.image.tag name from releases

      apiVersion: operator.victoriametrics.com/v1
kind: VLSingle
metadata:
  name: example
spec:
  image:
    repository: victoriametrics/victoria-logs
    tag: v1.26.0
    pullPolicy: Always
  # ...
    

Also, you can specify imagePullSecrets if you are pulling images from private repo:

      apiVersion: operator.victoriametrics.com/v1
kind: VLSingle
metadata:
  name: example
spec:
  image:
    repository: victoriametrics/victoria-logs
    tag: v1.26.0
    pullPolicy: Always
  imagePullSecrets:
    - name: my-repo-secret
# ...
    

Resource management #

You can specify resources for each VLSingle resource in the spec section of the VLSingle CRD.

      apiVersion: operator.victoriametrics.com/v1
kind: VLSingle
metadata:
  name: resources-example
spec:
    # ...
    resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"
    # ...
    

If these parameters are not specified, then, by default all VLSingle pods have resource requests and limits from the default values of the following operator parameters :

• VM_VLSINGLEDEFAULT_RESOURCE_LIMIT_MEM - default memory limit for VLSingle pods,
• VM_VLSINGLEDEFAULT_RESOURCE_LIMIT_CPU - default memory limit for VLSingle pods,
• VM_VLSINGLEDEFAULT_RESOURCE_REQUEST_MEM - default memory limit for VLSingle pods,
• VM_VLSINGLEDEFAULT_RESOURCE_REQUEST_CPU - default memory limit for VLSingle pods.

These default parameters will be used if:

• VM_VLSINGLEDEFAULT_USEDEFAULTRESOURCES is set to true (default value),
• VLSingle CR doesn’t have resources field in spec section.

Field resources in VLSingle spec have higher priority than operator parameters.

If you set VM_VLSINGLEDEFAULT_USEDEFAULTRESOURCES to false and don’t specify resources in VLSingle CRD, then VLSingle pods will be created without resource requests and limits.

Also, you can specify requests without limits - in this case default values for limits will not be used.

Syslog ingestion #

VLSingle can accept logs over syslog via TCP and/or UDP listeners, set via spec.syslogSpec.tcpListeners and spec.syslogSpec.udpListeners:

      apiVersion: operator.victoriametrics.com/v1
kind: VLSingle
metadata:
  name: example
spec:
  syslogSpec:
    tcpListeners:
      - listenPort: 8094
        tenantID: "0:0"
    udpListeners:
      - listenPort: 8095
        tenantID: "0:0"
    

TLS is supported for TCP listeners only. Set tlsConfig with a certificate and key, either referencing a Secret or a file already mounted into the pod; minVersion and cipherSuites further restrict which TLS versions and cipher suites clients may use:

      apiVersion: operator.victoriametrics.com/v1
kind: VLSingle
metadata:
  name: example
spec:
  syslogSpec:
    tcpListeners:
      - listenPort: 8094
        tenantID: "0:0"
        tlsConfig:
          certSecret:
            name: vlsingle-syslog-tls
            key: tls.crt
          keySecret:
            name: vlsingle-syslog-tls
            key: tls.key
          minVersion: TLS12
          cipherSuites:
            - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    

Examples #

VLSingle with resources set #

removePvcAfterDelete: true makes the operator keep an owner reference on the PersistentVolumeClaim, so it’s garbage-collected by Kubernetes when the VLSingle object is deleted. By default (false) the owner reference is stripped and the PVC is kept to preserve existing data.

      apiVersion: operator.victoriametrics.com/v1
kind: VLSingle
metadata:
  name: example
spec:
  retentionPeriod: "12"
  removePvcAfterDelete: true
  storage:
    resources:
      requests:
        storage: 50Gi
  resources:
    requests:
      memory: 500Mi
      cpu: 500m
    limits:
      memory: 10Gi
      cpu: 5
    

VLSingle with existing volume #

create PVC and bind it to existing PV existing-pv-name

      apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard
  volumeName: existing-pv-name
    

create VLSingle with PVC example-pvc mounted

      apiVersion: operator.victoriametrics.com/v1
kind: VLSingle
metadata:
  name: example
spec:
  replicaCount: 1
  retentionPeriod: "12"
  extraArgs:
    storageDataPath: /vl-data
  volumes:
    - name: vlstorage
      persistentVolumeClaim:
        claimName: example-pvc
  volumeMounts:
    - name: vlstorage
      mountPath: /vl-data
  resources:
    requests:
      memory: 500Mi
      cpu: 500m
    limits:
      memory: 10Gi
      cpu: 5
    

Migration from VLogs #

At first, create a new VLSingle resource, point clients to the new resource. Use backup-restore procedure for historical data migration.