如何在 Kubernetes 中 10 分钟部署配置 VectorK8s 日志收集管道完整教程【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vectorVector 是一款用 Rust 编写的高性能日志与可观测性数据管道工具可以在 Kubernetes 集群内完成日志、指标的收集、转换和路由。这篇文章不逐行串讲配置而是按选部署形态 → 拉起 Agent → 写管道配置 → 监控 → 排障的顺序带你走通一条完整的 K8s 日志管道。先定部署形态Vector 的三种 K8s 部署清单怎么选部署 Vector 到 K8s 之前先回答一个问题日志要就地处理还是集中汇总。仓库里 distribution/kubernetes/ 目录提供了三套由 Helm 图表生成的现成清单对应三种形态vector-agentDaemonSet每个节点跑一个 Vector Pod直接读本节点容器的日志和宿主机指标适合做边缘收集vector-aggregatorStatefulSet中央聚合节点打开vector、fluent、logstash、splunk_hec、syslog等接收端口统一收各 Agent 的数据再写入最终存储vector-stateless-aggregatorDeployment无状态版聚合器不需要持久化数据目录时用这个。典型的 K8s 日志管道就是两级结构Agent 在每个节点做轻量收集和过滤Aggregator 汇总后对接 Elasticsearch、Kafka、S3 等后端。小规模集群十来个节点以内只部署 Agent 就能跑节点多、下游存储扛不住高并发写入时再加一层 Aggregator。K8s 一键部署 Vector Agent 的完整步骤这一节的目标用两条命令让 DaemonSet 跑起来并确认日志真的在被收集。先拿到部署清单git clone https://gitcode.com/GitHub_Trending/vect/vector cd vector然后应用 Agent 清单并检查 Pod 状态kubectl apply -f distribution/kubernetes/vector-agent/ kubectl get pods -l app.kubernetes.io/namevector清单里几个值得留意的点见 distribution/kubernetes/vector-agent/daemonset.yaml配置通过 ConfigMap 挂载到/etc/vector/容器以--config-dir /etc/vector/启动默认配置里kubernetes_logssource 会自动发现本节点 Pod 的日志文件Pod 上打了vector.dev/exclude: true标签防止 Vector 收集自己的日志形成死循环同时挂载了/var/log、/proc、/sys所以host_metrics能采集宿主机指标——如果你只关心容器日志这部分可以不管。Pod 全部 Ready 后kubectl logs任意一个 Vector Pod应该能看到 JSON 格式的日志行在滚动输出说明管道已经通了。Vector 配置怎么写sources、transforms、sinks 串起一条 K8s 日志管道Agent 的默认配置distribution/kubernetes/vector-agent/configmap.yaml只做了一件事收日志打 stdout。真正干活时你需要在sources → transforms → sinks三段之间搭链路它们靠名字互相引用sources: kubernetes_logs: type: kubernetes_logs extra_field_selector: metadata.namespace ! kube-system transforms: parse_logs: type: remap inputs: [kubernetes_logs] source: | . parse_json!(.message) sinks: elasticsearch: type: elasticsearch inputs: [parse_logs] endpoints: [http://elasticsearch:9200] index: vector-logs-%Y-%m-%d三个要点inputs 是唯一的方向标一个 transform 可以挂多个输入一个 sink 也可以聚合多条上游链路想怎么分叉都行remap 是主力 transform用 VRL 语言做解析、字段提取、脱敏parse_json!这类带感叹号的函数在解析失败时丢弃而不是报错改完配置记得同步到集群配置是放在 ConfigMap 里的本地改完kubectl apply后 Vector 会热加载。仓库自带的 config/vector.yaml 是一个完整的可运行示例demo_logs → remap → console适合本地试错更多生产向写法可以看 config/examples/ 目录。用 Prometheus 监控 Vector 本身 日志管道跑起来之后管道本身也得被盯着。好消息是Agent 和 Aggregator 的默认配置都已经内置了监控链路——internal_metricssource 采集 Vector 自身指标prometheus_exportersink 暴露在0.0.0.0:9090Pod 端口里已经声明为prom-exporterPrometheus 直接抓:9090即可。值得关注的指标方向各组件的 events in/out 速率判断管道是否堵塞、sink 的重试与丢弃计数判断下游是否健康、内存占用Vector 用 Rust 编写内存安全不等于没有压力高峰期缓冲积压仍然需要观察。另外两个形态的清单都开启了内置 APIapi.enabled: true地址0.0.0.0:8686配合vector top命令可以在终端里实时查看每个组件的事件吞吐K8s 排障清单vector validate 与 vector top 快速定位管道不通时按这个顺序排查基本能覆盖 90% 的问题配置有没有语法或语义错误容器里执行vector validate /etc/vector/vector.yaml配置类问题会给出具体行号和原因。这也是每次改完 ConfigMap 后 Pod 反复 CrashLoopBackOff 时第一件该做的事Pod 到底卡在哪kubectl logs vector-pod看启动日志vector top需 API 已开启看各组件 Events In/Out 是否平衡——某个 transform 的 Out 持续为 0通常是上游 source 没采到数据而不是 transform 的问题RBAC 是否够kubernetes_logs依赖 ServiceAccount 读 Pod 列表自定义命名空间部署时确认 rbac.yaml 里的权限跟着清单一起应用了否则表现为 Pod 起了但日志为空日志重复或缺失重复多半是同一个文件被多个 source 匹配检查include路径是否重叠节点级收集要注意fingerprint策略宿主机重启后可能从头重读。部署细节更多可以读 docs/ARCHITECTURE.md配置示例在 config/examples/ 里按场景分好类了。跑通这条管道之后下一步通常是把 Aggregator 的 stdout sink 换成你的真实存储以及给日志加命名空间——那是另一个话题了。【免费下载链接】vectorA high-performance observability data pipeline.项目地址: https://gitcode.com/GitHub_Trending/vect/vector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考