1. 项目概述VictoriaMetrics Helm Charts 的价值定位如果你正在或计划在 Kubernetes 上部署 VictoriaMetrics那么直接去研究它的 Docker 镜像和一堆 YAML 文件可能会让你感到头疼。配置文件散落各处版本升级、配置管理、多环境部署这些运维日常会迅速变得复杂。这正是VictoriaMetrics/helm-charts这个项目存在的核心价值它将 VictoriaMetrics 整个监控生态系统的各个组件封装成了标准化、可参数化、易于管理的 Helm Chart。简单来说这是一个 Helm Chart 的官方仓库里面包含了部署 VictoriaMetrics 全家桶所需的所有模板。VictoriaMetrics 本身是一个高性能、经济高效且可扩展的监控解决方案和时间序列数据库常被用作 Prometheus 的长期远程存储或者直接作为抓取、存储、查询的 All-in-One 方案。而 Helm 是 Kubernetes 的包管理器你可以把它想象成 Kubernetes 世界的apt-get或yum。helm-charts项目就是把 VictoriaMetrics 这个“软件”做成了适合用 Helm 这个“包管理器”来安装和管理的“软件包”。这个项目解决了什么问题首先它标准化了部署流程。无论你要部署单实例的victoria-metrics-single还是高可用的集群版victoria-metrics-cluster亦或是专门用于告警的vmalert、用于数据转发的vmagent都可以通过统一的helm install或helm upgrade命令来完成。其次它实现了配置的集中化管理。所有配置从资源请求限制、持久化存储设置到各个组件细粒度的命令行参数都通过一个values.yaml文件来定义和覆盖。这极大提升了可维护性。最后它简化了生命周期管理。升级、回滚、卸载变得一目了然这对于生产环境的稳定运维至关重要。适合谁来使用如果你是 DevOps 工程师、SRE 或任何需要负责 Kubernetes 集群监控的开发者并且已经决定或正在评估使用 VictoriaMetrics那么这个 Chart 就是你不可或缺的工具。它既适合新手快速搭建一个可用的监控环境进行 PoC概念验证也适合有经验的团队基于它定制符合自身需求的、复杂的高可用生产部署。2. 核心架构与 Chart 组成解析在深入实操之前有必要先厘清VictoriaMetrics/helm-charts仓库里到底提供了什么以及 VictoriaMetrics 自身的组件架构是如何映射到这些 Chart 中的。理解这一点能帮助你在后续的配置中做出正确的选择。2.1 VictoriaMetrics 核心组件与对应 ChartVictoriaMetrics 项目由多个松耦合的组件构成helm-charts仓库为每个核心组件都提供了独立的 Chart同时也提供了整合的 Chart。victoria-metrics-single: 这是最常用的 Chart它部署一个All-in-One的 VictoriaMetrics 实例。这个 Pod 内部同时运行了vmstorage存储、vminsert数据写入、vmselect数据查询三个进程在集群版中是独立的服务。它非常适合测试、开发环境或者数据量不大、对可用性要求不高的生产场景。其优势是部署极其简单资源消耗相对较低。victoria-metrics-cluster: 这是生产环境高可用部署的标准选择。它将上述三个核心进程拆分为独立的、可水平扩展的 StatefulSet 或 Deploymentvmstorage 有状态存储节点负责实际存储时间序列数据。通常以 StatefulSet 部署每个 Pod 挂载独立的持久卷PV。vminsert 无状态写入代理接收来自 Prometheus、vmagent 或其他客户端的数据并根据一致性哈希将其分发到后端的vmstorage节点。通常以 Deployment 部署可水平扩展。vmselect 无状态查询节点处理来自 Grafana、API 客户端的查询请求从多个vmstorage节点聚合数据。通常以 Deployment 部署可水平扩展。 这个 Chart 通过清晰的配置帮你编排了这三个组件之间的服务发现、网络通信和依赖关系。vmagent: 这是一个轻量级的数据抓取和转发代理。它可以替代 Prometheus 的抓取功能以更低的资源消耗从成千上万个目标拉取指标然后推送到 VictoriaMetrics 或其他支持 Remote Write 的存储。vmagentChart 让你可以方便地在 K8s 中部署和管理多个vmagent实例配置抓取任务scrape configs。vmalert: 告警规则计算和发送组件。它从 VictoriaMetrics 读取数据根据用户定义的 PromQL/MetricsQL 告警规则进行计算当条件满足时向 Alertmanager、Slack、Webhook 等发送告警。vmalertChart 简化了告警规则通过 ConfigMap 管理和vmalert实例的部署。vmauth: 一个简单的代理和授权服务器可以为访问 VictoriaMetrics 组件的请求提供基本的身份验证、授权和负载均衡。在需要对外部客户端提供安全访问入口时非常有用。victoria-metrics-k8s-stack: 这是一个“ umbrella chart ”或“ meta chart ”它整合了victoria-metrics-cluster、vmagent、vmalert等组件旨在提供一个开箱即用的、完整的 Kubernetes 监控栈。它通常还包含了针对 K8s 组件kube-apiserver, kubelet 等和节点node-exporter的自动服务发现与抓取配置。如果你想一键部署覆盖 K8s 集群自身监控的完整方案这个 Chart 是起点。2.2 Helm Chart 的通用结构剖析无论使用哪个 Chart其内部结构都遵循 Helm 的通用约定理解这个结构有助于你进行深度定制Chart.yaml: Chart 的元数据文件定义了名称、版本、依赖关系等。注意Chart 版本与 VictoriaMetrics 应用镜像版本是独立的。你需要同时关注两者。values.yaml:最重要的文件。它定义了所有可配置参数的默认值。用户通过创建自己的custom-values.yaml文件来覆盖这些默认值。templates/: 目录下包含了所有的 Kubernetes 资源模板文件如deployment.yaml,service.yaml,configmap.yaml,ingress.yaml等。Helm 会结合values.yaml和用户提供的值渲染这些模板生成最终的 K8s 资源清单。templates/NOTES.txt: 安装成功后在终端显示给用户的提示信息通常包含如何访问服务的说明。实操心得在决定使用哪个 Chart 前强烈建议你先去 GitHub 仓库查看对应 Chart 目录下的values.yaml文件。这个文件本身就是一份最权威、最全面的配置说明书。通过浏览它你可以快速了解该 Chart 支持配置哪些功能例如是否支持 Ingress、持久化存储配置选项、资源限制设置等这比任何文档都直接。3. 实战部署从单实例到生产集群理论清晰后我们进入实战环节。我将以最典型的两个场景为例演示如何使用这些 Chart。3.1 场景一快速部署 All-in-One 单实例用于开发测试假设我们有一个测试集群需要快速搭建一个 VictoriaMetrics 来验证功能。步骤 1添加 Helm 仓库并更新helm repo add vm https://victoriametrics.github.io/helm-charts/ helm repo update这条命令添加了 VictoriaMetrics 的官方 Helm 仓库并拉取最新的 Chart 索引。步骤 2查看和定制配置在安装前我们先看看默认配置并创建自己的定制文件。# 查看 single-server chart 的所有可配置项 helm show values vm/victoria-metrics-single values-single-default.yaml现在我们创建一个精简的定制文件custom-values-single.yaml# custom-values-single.yaml server: persistentVolume: enabled: true # 启用持久化存储防止数据重启丢失 size: 20Gi # 根据测试数据量调整 storageClass: standard # 替换为你的集群中可用的 StorageClass 名称 resources: requests: memory: 512Mi cpu: 250m limits: memory: 1Gi cpu: 500m service: type: NodePort # 或 LoadBalancer/ClusterIP方便从集群外访问测试 nodePort: 30900 # 指定一个 NodePort如果 type 是 NodePort ingress: enabled: true # 如果你有 Ingress Controller 并想通过域名访问 hosts: - host: vm-single.test.com paths: - path: / pathType: Prefix这个配置做了几件事启用持久化存储并设置大小定义了容器的资源请求和限制将服务类型设置为 NodePort 并指定端口配置了 Ingress按需。步骤 3执行安装helm install vm-single vm/victoria-metrics-single -f custom-values-single.yaml -n monitoring --create-namespacevm-single: 这是你为这次 Release 起的名字。vm/victoria-metrics-single: 指定仓库和 Chart 名称。-f custom-values-single.yaml: 使用我们的定制配置。-n monitoring --create-namespace: 在monitoring命名空间中安装如果不存在则创建。安装成功后终端会输出NOTES.txt的内容告诉你如何访问服务。你可以通过kubectl get pods,svc,ingress -n monitoring来查看部署状态。3.2 场景二部署高可用生产集群 (victoria-metrics-cluster)生产环境要求高可用和可扩展性我们使用victoria-metrics-clusterChart。步骤 1深入理解集群配置集群版的values.yaml更为复杂因为它要配置多个组件。核心配置块包括vmstorage: 配置存储节点包括副本数、持久化、资源等。vminsert: 配置写入节点。vmselect: 配置查询节点。还有vmbackup,vmauth等可选组件的配置。步骤 2创建生产级 values 文件创建custom-values-cluster-prod.yaml# custom-values-cluster-prod.yaml # 全局配置如镜像拉取策略等 global: imagePullSecrets: [] # storageClass: ssd-fast # 可以在这里设置全局 StorageClass # VMStorage 配置 - 有状态核心存储 vmstorage: replicaCount: 3 # 生产环境建议至少3个实现高可用和容量扩展 persistentVolume: enabled: true size: 200Gi # 根据数据保留时间和摄入速率估算 storageClass: ssd-fast # 使用高性能存储类 retentionPeriod: 3 # 数据保留3个月 resources: requests: memory: 4Gi cpu: 2 limits: memory: 8Gi cpu: 4 podDisruptionBudget: # 配置 Pod 中断预算确保可用性 enabled: true maxUnavailable: 1 # VMInsert 配置 - 无状态写入 vminsert: replicaCount: 2 # 可根据写入负载水平扩展 resources: requests: memory: 1Gi cpu: 500m limits: memory: 2Gi cpu: 2 service: type: ClusterIP # 通常 vminsert 服务只在集群内被 vmagent 或 Prometheus 访问 # VMSelect 配置 - 无状态查询 vmselect: replicaCount: 3 # 查询负载通常较高可设置多副本 resources: requests: memory: 2Gi cpu: 1 limits: memory: 4Gi cpu: 4 service: type: LoadBalancer # 对外提供查询服务Grafana 连接这里 annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb # AWS 示例 loadBalancerIP: # 可指定静态 IP # 集群内部通信配置 cluster: # vmstorage 节点地址模板用于 vminsert 和 vmselect 发现 storage 节点 # 此配置至关重要它定义了组件间如何找到对方。 vmstorage: vmselect: port: 8481 vminsert: port: 8400 # 可选的监控与备份 serviceMonitor: enabled: true # 如果你使用 Prometheus Operator可以自动创建 ServiceMonitor vmbackup: enabled: true # 启用定时备份到 S3 或 GCS schedule: 0 2 * * * # 每天凌晨2点备份 credentials: secretName: vmbackup-secret # 存储云厂商密钥的 Secret步骤 3安装与验证# 先创建命名空间 kubectl create ns monitoring-prod # 安装集群 helm install vm-cluster-prod vm/victoria-metrics-cluster \ -f custom-values-cluster-prod.yaml \ -n monitoring-prod # 观察部署状态 kubectl get pods -n monitoring-prod -w # 应该看到 vmstorage-0,1,2, vminsert-xxx, vmselect-xxx 等 Pod 陆续变为 Running步骤 4配置 Grafana 数据源部署完成后获取vmselect服务的对外访问地址LoadBalancer 的 EXTERNAL-IP 或 NodePort。 在 Grafana 中添加数据源Type: PrometheusURL:http://vmselect-service-address:8481/select/0/prometheus/(注意这个路径/select/0/是集群版特有的)Auth: 按需配置如果部署了vmauth。注意事项集群版部署后vminsert和vmselect需要知道所有vmstorage节点的地址。Chart 通过 Kubernetes Headless Service 和 StatefulSet 的 DNS 记录自动实现了这一点。你不需要手动配置 IP 列表这是使用 Helm Chart 的一大便利。确保cluster.vmstorage部分的端口配置与vmstorage容器实际暴露的端口一致默认是 8481 和 8400。4. 高级配置与运维要点部署完成只是第一步要让 VictoriaMetrics 在生产环境稳定运行还需要关注以下高级配置和运维细节。4.1 持久化存储与数据管理数据是监控系统的生命线。对于vmstorage集群版或vm-single持久化存储的配置至关重要。StorageClass 选择VictoriaMetrics 对磁盘 IOPS 和延迟比较敏感尤其是写入密集型场景。强烈建议使用 SSD 或高性能云盘对应的 StorageClass。在values.yaml中为vmstorage.persistentVolume.storageClass指定正确的值。存储容量规划容量取决于保留周期retentionPeriod和数据摄入速率。一个粗略的估算公式所需容量 ≈ 每日摄入数据量 × 保留天数 × 安全系数如 1.5。每日摄入数据量可以通过测试环境运行一段时间后查看vm_rows_inserted和vm_data_size_bytes等指标来估算。数据备份与恢复务必启用vmbackup。配置定时任务将数据备份到对象存储如 S3、GCS、MinIO。values.yaml中的vmbackup部分需要配置调度时间、目标存储、认证信息等。恢复时可以使用vmrestore工具Chart 也提供了相应的 Job 模板但通常需要手动执行。4.2 资源配额与性能调优不合理的资源限制会导致 OOM内存溢出或 CPU 饥饿影响稳定性。内存Memoryvmstorage是最消耗内存的组件它需要缓存-memory.allowedPercent和索引。生产环境建议从 4-8GiB 请求开始并密切监控process_resident_memory_bytes指标。vmselect在处理复杂查询或大数据范围查询时也可能消耗大量内存。CPUvminsert和vmselect是 CPU 密集型尤其是查询。需要根据负载监控rate(vm_cpu_time_seconds_total[5m])来调整。实战配置示例在values.yaml中除了设置limits更要设置合理的requests这关系到 K8s 调度和 QoS。对于vmstorage我通常会设置vmstorage: resources: requests: memory: 8Gi cpu: 2000m limits: memory: 16Gi # Limit 可以比 Request 高为突发负载留空间 cpu: 4000m extraArgs: # 通过命令行参数限制内存使用百分比默认60%可根据情况调整 memory.allowedPercent: 654.3 监控 Chart 自身部署了监控系统别忘了监控它自己。VictoriaMetrics 组件暴露了丰富的 Prometheus 格式指标。使用 ServiceMonitor如果你在 Kubernetes 中使用了 Prometheus Operator例如通过 kube-prometheus-stack那么最简单的方式是在values.yaml中启用serviceMonitor.enabled: true。这会自动创建 ServiceMonitor 资源让你的 Prometheus 自动发现并抓取 VictoriaMetrics 各组件的指标。手动配置 Prometheus 抓取如果没有 Operator你需要在 Prometheus 的scrape_configs中手动添加针对vmstorage、vminsert、vmselect等服务的抓取任务。这些服务的端口和路径在 Chart 的values.yaml的service部分有定义。关键指标告警至少为以下指标设置告警up 0: 组件失活。process_resident_memory_bytes / machine_memory_bytes 0.8: 内存使用率过高。vm_cache_entries{typestorage/hour_metric_ids} / vm_cache_max_entries{typestorage/hour_metric_ids} 0.9: 缓存命中率低可能需调整-storage.cacheSize参数或扩容。rate(vm_http_request_errors_total[5m]) 0: HTTP 请求错误。4.4 安全与网络策略组件间通信安全在集群内部vminsert、vmselect和vmstorage之间通过 HTTP 通信。在生产环境中可以考虑为这些服务配置 Kubernetes Network Policies限制只有特定的 Pod如来自monitoring命名空间可以访问vmstorage的端口8481, 8400。对外暴露vmselect服务通常需要被 Grafana 和 API 客户端访问。使用Ingress配合 HTTPS 终止是标准做法。可以在vmselect.ingress部分配置 TLS 证书。对于更复杂的认证授权可以前置vmauth或oauth2-proxy。镜像安全考虑使用私有镜像仓库并在global.imagePullSecrets中配置拉取密钥。定期更新 Chart 版本以获取安全更新。5. 常见问题排查与运维技巧即使部署顺利运维过程中也难免遇到问题。这里记录一些常见坑点和排查思路。5.1 部署阶段常见问题问题 1Pod 一直处于Pending状态。排查kubectl describe pod pod-name -n namespace。最常见原因是资源不足CPU/Memory或没有合适的节点Node Selector/Affinity其次是 PVC 无法绑定StorageClass 不可用、容量不足。解决检查集群资源。确认values.yaml中设置的storageClass名称在集群中存在且可用。检查 PersistentVolumeClaimPVC的状态kubectl get pvc -n namespace。问题 2vmstoragePod 不断重启日志显示“cannot open storage…: another process is already running”。原因这是 StatefulSet 挂载了同一个 PVC 的典型问题。可能因为 Pod 被强制删除后新的 Pod 在旧 Pod 未完全清理前就启动了导致锁文件冲突。解决确保 Pod 被正常终止kubectl delete pod pod-name --grace-period30。如果问题依旧需要手动清理 PVC。危险操作会丢失数据先 scale down:kubectl scale statefulset vmstorage-victoria-metrics-cluster --replicas0 -n namespace删除 PVC:kubectl delete pvc pvc-name -n namespace(例如># 1. 首先获取新版本的默认 values并与你的自定义 values 合并或对比 helm show values vm/victoria-metrics-cluster --version new-version new-default-values.yaml # 使用 diff 工具或手动对比 new-default-values.yaml 和你的 custom-values-cluster-prod.yaml # 2. 执行升级指定新版本和你的 values 文件 helm upgrade vm-cluster-prod vm/victoria-metrics-cluster \ -f custom-values-cluster-prod.yaml \ --version new-version \ -n monitoring-prod # 3. 观察升级过程 kubectl get pods -n monitoring-prod -w注意事项Chart 的 Major 版本升级如从 0.x 到 1.x可能包含不向后兼容的变更务必仔细阅读官方 Release Notes 和values.yaml的变更说明。对于vmstorageStatefulSet 的镜像版本升级默认的更新策略是RollingUpdate但数据节点升级仍需谨慎建议在低峰期进行。回滚到上一版本# 查看发布历史 helm history vm-cluster-prod -n monitoring-prod # 回滚到特定修订版本 helm rollback vm-cluster-prod revision-number -n monitoring-prod回滚会使用该修订版本时的 Chart 和 Values 配置重新部署通常可以快速恢复问题。我个人在多次生产部署和升级中体会到VictoriaMetrics/helm-charts项目极大地提升了运维效率但它的价值建立在你对 VictoriaMetrics 组件本身和 Kubernetes 概念的理解之上。最有效的学习方式就是反复阅读values.yaml在测试环境中多尝试不同的配置并建立起从应用指标VictoriaMetrics 自身指标到基础设施指标节点资源的完整监控链路。这样当问题出现时你才能快速定位到底是 Chart 配置问题、应用性能问题还是底层基础设施的问题。