文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载本文是 Knative 官方文档中日志收集Logging专题的完整实战指南聚焦如何在 Kubernetes 集群中基于 Fluent Bit 搭建一套节点级 Forwarder 集群内 Collector的集中日志收集链路将 Pod 日志持久化到共享存储并通过 nginx 在集群内直接浏览与检索。读完本文你将掌握fluent-bit-collector.yaml与fluent-bit-configmap.yaml两份核心配置的每个字段含义、三种日志命名分类规则Knative 服务 /app标签 / Pod 名的底层实现以及 Kind、Docker Desktop、Minikube 等本地开发环境下的持久化卷适配方案。为什么 Knative 集群需要额外的日志收集Knative 本身并不强制要求部署日志收集组件Kubernetes 的标准kubectl logs机制已能满足日常排障需求。但这里有一个现实问题Knative Serving 会在 Pod 不再需要时自动删除它们与之关联的日志也会一并消失。对于以事件驱动为核心、服务伸缩频繁的 Knative Eventing / Serving 工作负载日志往往还没来得及查看就被回收了。因此在 Knative 集群中引入一个日志处理器与转发器log processor and forwarder来把 Kubernetes 日志集中收集到某个中心目录就成为可观测性建设中的常见补充方案。本项目官方文档采用的方案是Fluent Bit——一款轻量、高性能的日志采集组件它运行在每一个节点上DaemonSet负责采集节点上所有容器的日志它支持将日志转发到多种日志后端例如 Splunk、Datadog、ElasticSearch、Stackdriver 等如果你的集群已经存在成熟的日志平台只需参照 Fluent Bit 的 Output 插件文档配置对应转发器即可无需改动采集端。整体架构Forwarder Collector nginx 查看器搭建日志收集体系只需要两个步骤在每个节点上运行一个日志转发 DaemonSetForwarder负责采集节点容器日志在集群内的某个位置运行一个日志收集器Collector负责接收并持久化所有转发来的日志。官方文档给出了一张清晰的系统架构示意system.svg展示数据流向多个 Forwarder 将日志推送给 CollectorCollector 把日志写入共享卷shared volume同 Pod 内的 nginx 容器挂载同一共享卷从而提供基于 HTTP 的日志浏览能力部署顺序提醒重要必须先部署 Collector再部署 Forwarder。原因有二配置 Forwarder 时需要知道 Collector 的地址同时 Forwarder 在 Collector 就绪前会把日志先排队缓存提前部署 Forwarder 可能导致日志堆积甚至丢失。第一步部署日志 CollectorCollector 的定义位于仓库中的 fluent-bit-collector.yaml。该文件是一个多对象 YAML依次定义了logging命名空间、两个 ConfigMap、一个 Service 和一个 StatefulSet。官方默认用StatefulSet承载 Collector并把日志存放在 KubernetesPersistentVolumeClaimPVC上如果你愿意也可以改用 HostPath 存储见下文本地开发环境一节。1. 应用 Collector 配置kubectl apply -f fluent-bit-collector.yaml仓库只读请将 fluent-bit-collector.yaml 复制到本地后执行上述命令。默认配置会把logging命名空间下的所有监控相关对象创建好。默认配置下Collector 会把收到的日志分类为两类Knative 服务即带appKnative标签的 Pod更准确的描述见下文filter-simplify.conf解析实际还覆盖了带serving.knative.dev/configuration标签的服务非 Knative 应用其余普通 Pod。2. 通过浏览器访问日志Collector 内嵌的 nginx 容器负责把共享卷上的日志文件以 HTTP 目录列表的形式暴露出来。在logging命名空间下执行端口转发把 Service 的 80 端口映射到本地 8080kubectl port-forward --namespace logging service/log-collector 8080:80然后在浏览器中访问http://localhost:8080/即可按目录浏览日志文件。3. 在 nginx Pod 内用 Unix 工具检索日志可选你也可以直接进入 nginx 容器用熟悉的grep、less、tail等工具在共享卷上搜索日志kubectl exec --namespace logging --stdin --tty --container nginx log-collector-0注意容器名参数是--container nginxPod 名是log-collector-0StatefulSet 的有序命名。Collector 配置逐段拆解fluent-bit-collector.yaml中真正决定日志收集行为的是log-collector-configConfigMap它由三个配置文件组成通过INCLUDE指令串起来① 主配置fluent-bit.conf[SERVICE] Flush 1 Log_Level info Daemon off HTTP_Server On HTTP_Listen 0.0.0.0 HTTP_Port 2020 INCLUDE input-forward.conf INCLUDE filter-simplify.conf INCLUDE output-files.confFlush 1表示每 1 秒刷盘一次HTTP_Server On配合HTTP_Port 2020开启了 Fluent Bit 内置的监控端点可通过curl http://collector-pod:2020/查看运行指标。② 输入input-forward.conf监听 24224 端口使用 Fluent Bit 的forward输入插件接收来自各节点 Forwarder 的日志流[INPUT] Name forward Port ${FLUENT_PORT}${FLUENT_PORT}由 StatefulSet 的环境变量注入值为24224。③ 过滤filter-simplify.conf核心这里定义了日志文件命名的分类规则使用rewrite_tag过滤器。它按优先级依次匹配三类来源把日志的 tag 改写为对应的命名模式从而决定最终写入哪个日志文件[FILTER] Name rewrite_tag Match kube.* Rule $kubernetes[labels][serving.knative.dev/configuration] ^(.)$ knative.$kubernetes[namespace_name].$1.log false [FILTER] Name rewrite_tag Match kube.* Rule $kubernetes[labels][app] ^(.)$ app.$kubernetes[namespace_name].$1.log false [FILTER] Name rewrite_tag Match kube.* Rule $kubernetes[pod_name] ^(.)$ pod.$kubernetes[namespace_name].$1.log false规则含义逐条说明规则匹配条件改写后的 tag 模式说明第 1 条Pod 带serving.knative.dev/configuration标签knative.namespace.configuration.log命中 Knative Serving 配置的服务日志优先级最高第 2 条Pod 带app标签app.namespace.app-name.log命中显式声明app标签的应用第 3 条兜底匹配 Pod 名pod.namespace.pod-name.log其余所有 Pod 按 Pod 名归档④ 输出output-files.conf把所有日志以纯文本格式写入共享卷的/logs目录[OUTPUT] Name file Path /logs Format plain Match *Collector 的 Service 与 StatefulSetlog-collectorService 对外暴露两个端口24224forward供各节点 Forwarder 推送日志80viewer映射到 nginx 容器的 8080 端口供浏览器查看日志。StatefulSet 定义了两个容器fluent-bit镜像fluent/fluent-bit:1.5监听 24224挂载共享卷logs写入/logs与配置卷fluentd-config挂载到/fluent-bit/etc/内容来自log-collector-configConfigMapnginx镜像registry.k8s.io/nginx-slim:0.8挂载同一logs卷到/usr/share/nginx/html并把log-nginx-configConfigMap 中的nginx.conf开启了autoindex on的目录列表挂载到/etc/nginx。共享卷通过volumeClaimTemplates动态创建默认申请40Gi、ReadWriteOnce的 PVC。修改命名规则的注意点日志默认以 Pod 名命名如需更改可在安装前后更新log-collector-configConfigMap例如调整filter-simplify.conf中的 tag 模式。ConfigMap 更新后必须重启 Fluent Bit 才能生效——最简单的做法是删除 Pod让 StatefulSet 自动重建一个。第二步部署日志 Forwarder节点级采集Forwarder 负责在每个节点上采集容器日志再通过forward协议推送给 Collector。官方推荐直接参照 Fluent Bit 官方文档部署一个默认转发到 ElasticSearch 的 Fluent Bit DaemonSet然后在安装过程中创建 ConfigMap 时做以下二选一的适配方式一直接替换整个 ConfigMap把官方安装步骤中创建的 ConfigMap 内容整体替换为仓库中的 fluent-bit-configmap.yaml。方式二只替换 Output 段最小改动在 ConfigMap 中新增如下块并把INCLUDE output-elasticsearch.conf改为INCLUDE output-forward.confoutput-forward.conf: | [OUTPUT] Name forward Host log-collector.logging Port 24224 Require_ack_response True这里的Host log-collector.logging是 Collector 的 Service 全限定名命名空间logging内的log-collector端口24224与 Collector 的 forward 监听端口一一对应。Require_ack_response True开启应答确认机制避免日志在传输链路中静默丢失。Forwarder 配置解析日志如何被打上kube.*前缀仓库中的 fluent-bit-configmap.yaml 展示了完整的 Forwarder 侧配置包含输入、过滤、输出三部分① 输入input-kubernetes.conf用tail插件采集/var/log/containers/*.logtag 前缀统一为kube.*[INPUT] Name tail Tag kube.* Path /var/log/containers/*.log Parser docker DB /var/log/flb_kube.db Mem_Buf_Limit 5MB Skip_Long_Lines On Refresh_Interval 10Parser docker使用内置的 Docker JSON 日志解析器DB指定了 Fluent Bit 的偏移量数据库位置用于记录已读进度保证重启后不重复采集Mem_Buf_Limit 5MB控制单文件缓冲上限Skip_Long_Lines On跳过超长行避免阻塞。② 过滤filter-kubernetes.conf通过 ServiceAccount 访问 Kube API为日志附加 Kubernetes 元数据命名空间、Pod 名、标签等这些字段正是 Collector 端rewrite_tag分类所依赖的[FILTER] Name kubernetes Match kube.* Kube_URL https://kubernetes.default.svc:443 Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token Kube_Tag_Prefix kube.var.log.containers. Merge_Log On Merge_Log_Key log_processed K8S-Logging.Parser On K8S-Logging.Exclude OffMerge_Log On会把容器 stdout 中的 JSON 日志内容解析并合并进记录Merge_Log_Key log_processed指定合并后的键名K8S-Logging.Exclude Off表示默认不排除任何 Pod 的日志。③ 输出output-forward.conf与 Collector 的input-forward.conf配对完成端到端链路见上文方式二示例。文件末尾还内置了parsers.conf预置了docker、json、apache、nginx、syslog等常用日志解析器其中docker解析器使用%Y-%m-%dT%H:%M:%S.%L时间格式并开启Time_Keep用于还原容器日志中的时间戳字段。本地开发环境用 hostPath 把日志存到宿主机如果使用本地 Kubernetes 集群做开发调试官方文档提供了一个仅限开发环境使用、不适合生产的替代方案创建一个hostPath类型的 PersistentVolume把日志直接存到桌面操作系统的磁盘上。这样你就可以用宿主机上熟悉的桌面工具直接处理日志文件无需借助任何 Kubernetes 专用工具。1. 定义 hostPath PersistentVolumePersistentVolumeClaim对应的 PersistentVolume 大致如下apiVersion: v1 kind: PersistentVolume metadata: name: shared-logs labels: app: logs-collector spec: accessModes: - ReadWriteOnce storageClassName: manual claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: logs-log-collector-0 namespace: logging capacity: storage: 5Gi hostPath: path: see below要点说明storageClassName: manual对应本地集群需要预创建的存储类claimRef显式绑定到 StatefulSet 自动生成的 PVClogs-log-collector-0命名规则为volumeClaimTemplate名-Pod序号hostPath.path因 Kubernetes 软件与宿主机操作系统而异详见下文hostPath的具体取值取决于你使用的本地集群软件不同工具差异很大。2. 修改 StatefulSet 的 volumeClaimTemplates把 Collector StatefulSet 中的volumeClaimTemplates更新为引用上面创建的shared-logs卷volumeClaimTemplates: metadata: name: logs spec: accessModes: [ReadWriteOnce] volumeName: shared-logs通过volumeName: shared-logs将模板与已创建的 PersistentVolume 关联起来。3. 不同本地集群的 hostPath 配置Kind创建集群时必须使用kind-config.yaml并为每个节点指定extraMounts把宿主机的./logs目录挂载进节点的/shared/logsapiversion: kind.x-k8s.io/v1alpha4 kind: Cluster nodes: - role: control-plane extraMounts: - hostPath: ./logs containerPath: /shared/logs - role: worker extraMounts: - hostPath: ./logs containerPath: /shared/logs随后在 PersistentVolume 中把spec.hostPath.path设为/shared/logs。注意./logs是相对目录相对于创建 Kind 集群时所在的目录。Docker DesktopDocker Desktop 会自动创建宿主机与虚拟机之间的若干共享挂载你只需要知道宿主机的家目录路径即可。不同操作系统下的hostPath取值如下宿主机 OShostPathMac OS/Users/${USER}Windows/run/desktop/mnt/host/c/Users/${USER}/Linux/home/${USER}MinikubeMinikube 需要显式执行命令把目录挂载进运行 Kubernetes 的虚拟机。下面的命令把当前目录下的logs目录挂载到 VM 内的/mnt/logsminikube mount ./logs:/mnt/logs随后同样需要在 PersistentVolume 中把spec.hostPath.path设为/mnt/logs。注意minikube mount是前台进程需保持其运行。验证与排障要点确认 Collector 就绪kubectl get pods -n logging看到log-collector-0处于Running状态后再部署 Forwarder。确认日志已落盘浏览器打开http://localhost:8080/应能看到按knative.*、app.*、pod.*前缀命名的子目录或文件。Forwarder 侧检查在任意节点执行kubectl logs fluent-bit-daemonset-pod如出现forward连接被拒绝说明 Collector 的 24224 端口尚未就绪。修改命名规则后的重启更新log-collector-configConfigMap 后删除log-collector-0Pod等待 StatefulSet 重建规则即生效。延伸阅读本文对应的 Serving 侧同款指南collecting-logs.md两份文档共用同一篇 snippets 源文档配置完全一致。日志收集讲的是采集容器日志而 Knative 组件自身的日志级别与格式通过config-loggingConfigMap 管理详见 config-logging.md。若想进一步监控 Knative Eventing 的指标与链路追踪可参考 collecting-metrics.md 与 accessing-traces.md。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative 日志收集实战基于 Fluent Bit 集中采集与检索 Kubernetes 应用日志Knative 日志收集实战基于 Fluent Bit 集中采集与检索 Kubernetes 应用日志 本文以 Knative 官方文档 collecting文档教程云原生10分钟搭建轻量级日志收集系统kafka-docker与Fluent Bit实战指南10分钟搭建轻量级日志收集系统kafka docker与Fluent Bit实战指南 你是否还在为分布式系统日志收集头痛面对成百上千的容器日志传统工具要么消息队列后端云原生KServe CIFAR10 离群检测实战基于 Payload 日志与 Knative Eventing 的异步异常检测架构KServe CIFAR10 离群检测实战基于 Payload 日志与 Knative Eventing 的异步异常检测架构 导读 本文以 KServe 官方模型推理服务云原生后端微服务MLOps人工智能上一篇Hyperswitch 编译性能优化指南RFC 001 解析与依赖树、代码生成层面的实战改进下一篇Bilibili-Evolved性能预算调整基于实际数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考