Loki Operator 指南：绕过 Gateway 将日志直推 Distributor 多租户写入（Fluentd / Vector）-开发者社区

Loki Operator 指南：绕过 Gateway 将日志直推 Distributor 多租户写入（Fluentd / Vector）

【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki

本文以 Loki Operator 官方用户指南为基础，介绍在 OpenShift 场景下如何让 Fluentd 或 Vector 作为日志收集器，绕过 LokiStack Gateway 的认证网关，直接通过distributor-http服务把 application、infrastructure、audit 三类日志以不同租户身份推送到 Loki Distributor。读完本文，你将掌握整个部署链路（LokiStack → OpenShift Logging → CA 证书 Secret → ClusterLogForwarder），并理解tenantKey: log_type的多租户路由原理、TLS 服务证书校验方法以及429背压问题的排查思路。

适用与免责说明：本文操作仅适用于 OpenShift 部署。绕过认证网关并非 OpenShift 部署的常规配置，仅当无法经由 Gateway（Forwarding Logs to LokiStack）时才建议用于测试环境。

一、背景：Gateway 与 Distributor 直连两条路径的取舍

由 Loki Operator 部署的 LokiStack 默认会包含一个lokistack-gateway组件，它通过 OAuth/OIDC 端点对请求主体做认证与授权，为写入（distributor）和查询（query-frontend）提供安全入口。正因如此，默认情况下 LokiStack 内所有组件都启用了 TLS，服务证书由集群内部 CA 签发。

本文要走的“无 Gateway”路径与其形成对照：

对比项	走 Gateway	绕开 Gateway（本文）
入口地址	`https://<stack>-gateway-http.<ns>.svc:8080/api/logs/v1/<tenant>`	`https://<stack>-distributor-http.<ns>.svc:3100`
认证方式	OAuth/OIDC + bearer token	无（依赖 Service Network / mTLS 环境信任）
租户识别	URL 路径段（`/api/logs/v1/application`等）	日志字段`log_type`→`X-Scope-OrgID`
适用场景	生产环境常规配置	测试 / 无法使用 Gateway 的场景

从源码看，distributor 的 HTTP 服务端口固定为 3100：例如在 gateway_test.go 中，Gateway 写入端点为https://abcd-distributor-http.efgh.svc.cluster.local:3100，而服务命名规则fmt.Sprintf("%s-distributor-http", stackName)定义在 certrotation/var.go（对应certrotation内部目录）。这解释了文中 URLhttps://lokistack-dev-distributor-http.openshift-logging.svc:3100的构成：<LokiStack 名称>-distributor-http+ 命名空间 + 端口 3100。

二、前置条件与部署顺序

动手之前，先按 hacking guide 完成环境准备，整体顺序如下：

部署 Loki Operator 与 LokiStack 实例：按 OpenShift 上的操作指南完成。注意：无 Gateway 路径下创建的 LokiStack 应只包含 distributor、compactor、ingester、querier、query-frontend 五个组件，不包含lokistack-gateway。在 OLM 部署场景中，可通过移除loki-operator-controller-managerdeployment 的--with-lokistack-gateway参数来跳过 Gateway 组件：
```
kubectl -n openshift-operators-redhat edit deployment/loki-operator-controller-manager
```
删除args中的--with-lokistack-gateway后保存，再创建 LokiStack 实例。相应地，<stack>名称为lokistack-dev时，distributor 服务名为lokistack-dev-distributor-http。
部署 OpenShift Logging Operator：从 Operator Hub 安装，或在本地用以下命令部署：
```
make deploy-image deploy-catalog install
```
创建只含collection的 ClusterLogging 实例（位于openshift-logging命名空间），让集群具备日志收集能力（见下一节）。

关于租户模式的一个补充

虽然本文绕开了 Gateway，但了解 tenancy-modes.md 中列出的五种模式（static、dynamic、passthrough、openshift-logging、openshift-network）有助于理解：openshift-logging模式预置了application、infrastructure、audit三个租户，本文直推 Distributor 时正是通过log_type字段把这三种日志路由到同名租户，实现与 Gateway 路径等价的多租户隔离存储。

三、创建 ClusterLogging 实例（Fluentd / Vector 二选一）

在openshift-logging命名空间创建 ClusterLogging CR，只需定义collection，不配置存储与可视化，让日志先被收集、随后由 ClusterLogForwarder 转发：

Fluentd 版本：

apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: fluentd fluentd: {}

Vector 版本：

apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance namespace: openshift-logging spec: collection: logs: type: vector fluentd: {}

注意：Vector 示例中的fluentd: {}为原文档原文保留，两个 CR 除collection.logs.type外结构一致，后续步骤对 fluentd 与 vector 完全相同。

四、TLS 信任：把 CA 证书 ConfigMap 转成 Secret

4.1 为什么需要这一步

默认情况下，Loki Operator 部署的所有组件都启用了 TLS，服务证书由集群内部 CA 签发。收集器在访问https://lokistack-dev-distributor-http...时必须校验 distributor 返回的证书，因此需要把 CA 证书提供给收集器。

CA 证书存放在 loki-operator 随 LokiStack 创建的 ConfigMap 中，该 ConfigMap 无法被收集器直接使用，必须先转换为收集器可读的 Secret。ConfigMap 与 Secret 的命名关系可在 gateway_test.go 中看到：同一 stack 会同时生成abcd-ca-bundle与abcd-gateway-ca-bundle两个 ConfigMap；其中 Gateway CA ConfigMap 由 openshift/service_ca.go 的BuildGatewayCAConfigMap构建，其注释明确指出该 ConfigMap 用于“配置 gateway 与各组件以校验 TLS 证书”。

4.2 获取`ca-bundle.crt`

Secret 必须存在于openshift-logging命名空间，且必须包含键ca-bundle.crt。先从 ConfigMap 中把 CA 取出来（以lokistack-dev-gateway-ca-bundle为例）：

kubectl -n openshift-logging get cm lokistack-dev-gateway-ca-bundle -o jsonpath="{.data.service-ca\.crt}" > <FILE_NAME>

其中<FILE_NAME>可取ca_bundle.crt，并直接用于下一步创建 Secret。若你的 LokiStack 名称为<stack>，ConfigMap 名称相应为<stack>-gateway-ca-bundle。

4.3 创建 Secret

kubectl -n openshift-logging create secret generic loki-distributor-ca \ --from-file=ca-bundle.crt=<PATH/TO/CA_BUNDLE.CRT>

其中<PATH/TO/CA_BUNDLE.CRT>为上一步ca_bundle.crt保存到的文件路径。创建后 Secret 名为loki-distributor-ca，供后续 ClusterLogForwarder 引用。

五、创建 ClusterLogForwarder：把三类日志推送到 Distributor

这是整条链路的最后一步。创建以下 CR，将 application、audit、infrastructure 日志转发到 distributor 端点：

apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: loki-operator type: loki url: https://lokistack-dev-distributor-http.openshift-logging.svc:3100 secret: name: loki-distributor-ca loki: tenantKey: log_type pipelines: - name: send-logs inputRefs: - application - audit - infrastructure outputRefs: - loki-operator

关键点说明：

url：直接指向 distributor 的 HTTP 服务https://lokistack-dev-distributor-http.openshift-logging.svc:3100，端口 3100 是 Loki 各组件的标准 HTTP 端口（可对照 gateway_test.go 中--logs.write.endpoint=https://abcd-distributor-http.efgh.svc.cluster.local:3100）。
secret.name：引用第四节创建的loki-distributor-ca，用于 TLS 校验。
tenantKey: log_type：fluentd 与 vector 会根据所收集日志的类型，把log_type解析为application、audit或infrastructure，随后作为不同租户 ID 写入 Loki，实现与 Gateway 路径等价的多租户隔离。
inputRefs：同时引用application、audit、infrastructure，即可用单个 output + 单个 pipeline 完成三类日志的租户化写入；若只想转发部分日志，可像 Forwarding Logs to LokiStack 中说明的那样自行增删 pipeline。

六、Troubleshooting：日志条目乱序与 429 背压

现象

如果 forwarder 在短时间内发送过多数据，Loki 会对 forwarder 施加背压，并对 POST 请求返回429错误，导致日志条目出现乱序。

处理方式

这与 Forwarding Logs to LokiStack 中描述的429问题是同一机制。缓解手段包括：

提升 LokiStack 规格（t-shirt size）：更大规格带来更多资源与更高摄取速率。
```
kubectl -n openshift-logging edit lokistack
```
```
size: 1x.medium
```
手动调整摄取速率限制（全局或按租户）：
```
kubectl -n openshift-logging edit lokistack
```
```
limits: tenants: <TENANT_NAME>: IngestionLimits: IngestionRate: 15
```
其中<TENANT_NAME>可为application、audit或infrastructure。

七、回顾与验证建议

完整部署顺序可归纳为：部署 Loki Operator（不带 Gateway）→ 部署 OpenShift Logging Operator → 创建只含collection的 ClusterLogging → 从<stack>-gateway-ca-bundleConfigMap 提取service-ca.crt并创建含ca-bundle.crt键的 Secret → 创建引用该 Secret 且带tenantKey: log_type的 ClusterLogForwarder。

验证建议：

用kubectl -n openshift-logging get pods确认collectorPod（fluentd 或 vector）处于 Running；
在 Grafana 或通过查询前端分别以application、audit、infrastructure租户查询日志，确认三类日志已按租户正确落库；
若流量较大，持续观察 distributor 是否返回429，据此调整size或租户级IngestionLimits。

Loki Operator 指南：绕过 Gateway 将日志直推 Distributor 多租户写入（Fluentd / Vector）