5dd879cd17
### Describe Your Changes As of right now by default aggregated output in streaming aggregation takes a staleness interval and only starts sending first samples after the staleness interval passes. We have a use case where we prefer to start sending data as soon as we have any. This adds the option to configure when we start sending first samples https://github.com/VictoriaMetrics/VictoriaMetrics/issues/7116 ### Checklist The following checks are **mandatory**: - [x] My change adheres [VictoriaMetrics contributing guidelines](https://docs.victoriametrics.com/contributing/). --------- Co-authored-by: hagen1778 <roman@victoriametrics.com> |
||
|---|---|---|
| .. | ||
| resources | ||
| _index.md | ||
| additional-scrape.md | ||
| api.md | ||
| auth.md | ||
| backups.md | ||
| CHANGELOG.md | ||
| configuration.md | ||
| configuration_syncronization.md | ||
| design.md | ||
| enterprise.md | ||
| FAQ.md | ||
| high-availability.md | ||
| logo.webp | ||
| logo_white.webp | ||
| managing-versions.md | ||
| migration.md | ||
| migration_prometheus-conversion.webp | ||
| monitoring.md | ||
| monitoring_operator-dashboard.webp | ||
| quick-start.md | ||
| quick-start_alert-1.webp | ||
| quick-start_alert-2.webp | ||
| quick-start_cluster-scheme.webp | ||
| quick-start_select-1.webp | ||
| quick-start_select-2.webp | ||
| quick-start_values.webp | ||
| README.md | ||
| README_operator-workflow.webp | ||
| relabeling.md | ||
| resources-validation.md | ||
| security.md | ||
| setup.md | ||
| vars.md | ||
| VictoriaMetrics-Operator.md | ||
| vmalertmanager-configuration.md | ||
Operator serves to make running VictoriaMetrics applications on top of Kubernetes as easy as possible while preserving Kubernetes-native configuration options.
VictoriaMetrics Operator (vmoperator) is the classic kubernetes-operator for VictoriaMetrics with many great features.
It allows you to manage Victoria Metrics components in Kubernetes or OpenShift clusters
in a declarative style according to GitOps
and IaC concepts.
VictoriaMetrics also provides helm charts without operator. Operator makes the same, simplifies it and provides advanced features.
Learn more about key concepts of vmoperator and follow the quick start guide for a better experience.
Features of vmoperator
- Deployment and management in a kubernetes clusters of any number of VictoriaMetrics applications (like vmsingle/vmcluster instances and another components like vmauth, vmagent, vmalert, etc...)
- Seamless migration from prometheus-operator with auto-conversion of prometheus custom resources
- Simple VictoriaMetrics cluster installation, configuring, upgrading and managing with crd-objects.
- Ability to delegate the configuration (parts of configuration) of applications monitoring to the end-users and managing access to different configurations or configuration sections.
- Integration with VictoriaMetrics vmbackupmanager - advanced tools for making backups. Check Backup automation for VMSingle or Backup automation for VMCluster.
- Everything you need for monitoring out of the box in k8s-stack helm chart with ready-made usecases and solutions.
- Ability to template your own deployment scenarios.
Key Concepts
Kubernetes-operators
Kubernetes-operators are software extensions for Kubernetes that make use of custom resources to manage applications and their components. Operators follow Kubernetes principles, notably the control loop. It can be said that operators are custom controllers for Kubernetes that allow you to create business logic for custom resources.
Design and implementation of vmoperator inspired by prometheus-operator.
Useful links:
Custom resources
Kubernetes-Operators use custom resources for interaction. Custom resources are a mechanism built into Kubernetes that allows you to create your own extensions for Kubernetes, working on the same principles as those built into Kubernetes APIs. Custom resources make Kubernetes so modular and extensible.
In addition, thanks to CRD (Custom Resource Definitions), the mechanism of custom resources allows you to declare an API in the format of the OpenAPI specification and verify that the resources correspond to this API.
Reconciliation cycle
The main task of the operator is to bring the state of the cluster in line with what is declared by the user in the custom resources. This process of constant monitoring and adjustment is called the "Reconciliation cycle" - it is the operator's workflow.
The basic workflow of working with the operator can be simplified as the following diagram:
- Operator declares and owns resources of Victoria Metrics.
- Kubernetes validates of the resource according to the specification from CRD (see more in custom resources).
- Operator subscribed to change events (
create,update,delete) for related resources. - When an event occurs, the operator reacts and updates the state of the objects in the cluster.
- For some objects in the cluster the reconciliation cycle is performed at a given interval, even without the occurrence of change events (see
VM_FORCERESYNCINTERVAL).
Next steps
- Quick Start Guide
- Setup
- Security
- Configuration
- Migration from Prometheus
- Monitoring
- Authorization and exposing components
- High Availability
- Enterprise
- Custom resources
If you have any questions, check out our FAQ and feel free to can ask them:
If you have any suggestions or find a bug, please create an issue on GitHub.