Project: VictoriaMetrics (Observability and Analysis / Observability)
File: vmsingle.md

sort: 13 weight: 13 title: VMSingle menu: docs: parent: "operator-custom-resources" weight: 13 aliases: /operator/resources/vmsingle.html `VMSingle` represents database for storing metrics. The `VMSingle` CRD declaratively defines a installation to run in a Kubernetes cluster. For each `VMSingle` resource, the Operator deploys a properly configured `Deployment` in the same namespace. The VMSingle `Pod`s are configured to mount an empty dir or `PersistentVolumeClaimSpec` for storing data. Deployment update strategy set to . No more than one replica allowed. For each `VMSingle` resource, the Operator adds `Service` and `VMServiceScrape` in the same namespace prefixed with name from `VMSingle.metadata.name`. You can see the full actual specification of the `VMSingle` resource in the . If you can't find necessary field in the specification of the custom resource, see . Also, you can check out the section. `VMSingle` doesn't support high availability by default, for such purpose use instead or duplicate the setup. To set `VMSingle` version add `spec.image.tag` name from ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMSingle metadata: name: example-vmsingle spec: image: repository: victoriametrics/victoria-metrics tag: v1.93.4 pullPolicy: Always ``` Also, you can specify `imagePullSecrets` if you are pulling images from private repo: ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMSingle metadata: name: example-vmsingle spec: image: repository: victoriametrics/victoria-metrics tag: v1.93.4 pullPolicy: Always imagePullSecrets: name: my-repo-secret ``` You can specify resources for each `VMSingle` resource in the `spec` section of the `VMSingle` CRD. ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMSingle metadata: name: vmsingle-resources-example spec: resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" ``` If these parameters are not specified, then, by default all `VMSingle` pods have resource requests and limits from the default values of the following : `VMVMSINGLEDEFAULTRESOURCELIMITMEM` - default memory limit for `VMSingle` pods, `VMVMSINGLEDEFAULTRESOURCELIMITCPU` - default memory limit for `VMSingle` pods, `VMVMSINGLEDEFAULTRESOURCEREQUESTMEM` - default memory limit for `VMSingle` pods, `VMVMSINGLEDEFAULTRESOURCEREQUESTCPU` - default memory limit for `VMSingle` pods. These default parameters will be used if: `VMVMSINGLEDEFAULTUSEDEFAULTRESOURCES` is set to `true` (default value), `VMSingle` CR doesn't have `resources` field in `spec` section. Field `resources` in `VMSingle` spec have higher priority than operator parameters. If you set `VMVMSINGLEDEFAULTUSEDEFAULTRESOURCES` to `false` and don't specify `resources` in `VMSingle` CRD, then `VMSingle` 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. VMSingle supports features from : For using Enterprise version of you need to change version of `VMSingle` to version with `-enterprise` suffix using . All the enterprise apps require `-eula` command-line flag to be passed to them. This flag acknowledges that your usage fits one of the cases listed on

So you can use for passing this flag to `VMSingle`. After that you can pass flag to `VMSingle` with too. Here are complete example for : ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMSingle metadata: name: vmsingle-ent-example spec: image: tag: v1.93.5-enterprise extraArgs: eula: true downsampling.period: 30d:5m,180d:1h,1y:6h,2y:1d ``` The same method is used to enable retention filters - here are complete example for . ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMSingle metadata: name: vmsingle-ent-example spec: image: tag: v1.93.5-enterprise extraArgs: eula: true retentionFilter: '{team="juniors"}:3d,{env=~"dev|staging"}:30d' ``` You can check for backup automation. It contains a description of the service and its features. This section covers vmbackumanager integration in vmoperator. `VMSingle` has built-in backup configuration, it uses `vmbackupmanager` - proprietary tool for backups. It supports incremental backups (hourly, daily, weekly, monthly) with popular object storages (aws s3, google cloud storage). Here is a complete example for backup configuration: ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMSingle metadata: name: example-vmsingle spec: vmBackup: acceptEULA: true destination: "s3://your_bucket/folder" credentialsSecret: name: remote-storage-keys key: credentials apiVersion: v1 kind: Secret metadata: name: remote-storage-keys type: Opaque stringData: credentials: |- [default] awsaccesskeyid = youraccesskeyid awssecretaccesskey = yoursecretaccesskey ``` You can read more about backup configuration options and mechanics Possible configuration options for backup crd can be found at There are several ways to restore with or . You have to stop `VMSingle` by scaling it replicas to zero and manually restore data to the database directory. Steps: Edit `VMSingle` CRD, set `replicaCount: 0` Wait until database stops SSH to some server, where you can mount `VMSingle` disk and mount it manually Restore files with `vmrestore` Umount disk Edit `VMSingle` CRD, set `replicaCount: 1` Wait database start Add init container with `vmrestore` command to `VMSingle` CRD, example: ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMSingle metadata: name: example-vmsingle spec: vmBackup: acceptEULA: true destination: "s3://your_bucket/folder" credentialsSecret: name: remote-storage-keys key: credentials extraArgs: runOnStart: "true" initContainers: name: vmrestore image: victoriametrics/vmrestore:latest volumeMounts: mountPath: /victoria-metrics-data name: data mountPath: /etc/vm/creds name: secret-remote-storage-keys readOnly: true args: -storageDataPath=/victoria-metrics-data -src=s3://your_bucket/folder/latest -credsFilePath=/etc/vm/creds/credentials ``` Apply it, and db will be restored from S3 Remove `initContainers` and apply CRD. Note that using `VMRestore` will require adjusting `src` for each pod because restore will be handled per-pod. Using VMBackupmanager restore in Kubernetes environment is described . Advantages of using `VMBackupmanager` include: Automatic adjustment of `src` for each pod when backup is requested Graceful handling of case when no restore is required - `VMBackupmanager` will exit with successful status code and won't prevent pod from starting ```yaml kind: VMSingle metadata: name: vmsingle-example spec: retentionPeriod: "12" removePvcAfterDelete: true storage: accessModes: ReadWriteOnce resources: requests: storage: 50Gi extraArgs: dedup.minScrapeInterval: 60s resources: requests: memory: 500Mi cpu: 500m limits: memory: 10Gi cpu: 5 ```