Loki OSS 在 GKE 上基于 GCS 存储的 Simple Scalable 架构部署指南Helm Chart 实战【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki导读本文基于 Grafana Loki 官方 Helm Chart 仓库中的OSS开源版GCS 示例完整讲解如何在 Google Kubernetes EngineGKE集群上以Simple Scalable简单可扩展架构部署 Loki 开源版本并使用Google Cloud StorageGCS作为统一的对象存储后端。读完本文你将掌握GCP Service Account 凭据的注入方式、Loki OSS 模式非 Enterprise的 Helm overrides 文件编写要点以及通过一条helm upgrade --install命令完成集群日志平台交付的完整实战流程。本文对应的示例文件位于 production/helm/loki/docs/examples/oss是该仓库 examples 示例目录 中与 EnterpriseGEL示例并列的两个入门方案之一适用于希望以纯开源方式快速搭建生产级日志系统的用户。示例场景概览与前置条件官方为 Helm Chart 提供了两组开箱即用的入门示例Loki OSS 示例开源版无企业 License 要求即本文主题Grafana Enterprise Logs 示例需要 Grafana Labs 提供的企业 License。两者共享同一个部署目标在 GKE 上使用 Simple Scalable 架构并以 GCS 作为对象存储。OSS 示例由三个文件组成文件作用README.md部署步骤说明oss-secrets.yaml存放 GCP Service Account JSON 凭据的 Kubernetes Secretoverrides-oss-gcs.yamlHelm values 覆盖文件声明 GCS 存储与关闭 Enterprise 模式在开始部署前需要确认以下资源已经就绪一个可访问的 Kubernetes 集群示例场景为 GKE其他集群同样适用一个 GCS Bucket用于存放 Loki 的 chunk、索引与管理数据一个 GCP Service Account且该账号对上述 GCS Bucket 具有读写权限read/write permissions本机已安装kubectl与helm并已配置好对集群的访问凭据。架构背景为什么选择 Simple Scalable 与 GCS示例使用的部署模式由 Chart 中的deploymentMode决定。查看 values.yaml 可以看到该 Chart 支持三种核心部署模式SingleBinary单二进制模式适合每天数十 GB 以内的小型部署通常无需 HASimpleScalable拆分为read、write、backend三类组件适合中等规模约 1TB/天 以内比微服务模式更易管理——这也是本示例采用的模式且是 Chart 的默认值Distributed完整微服务化拆分功能最全但最复杂适合每天 1TB 以上的大型部署。同时 Chart 还提供了两种用于迁移的中间模式SingleBinary↔SimpleScalable、SimpleScalable↔Distributed。需要特别注意的是SimpleScalable 与 Distributed 模式都强制要求使用对象存储这正是示例选择 GCS 的根本原因——Loki 的 chunk、索引元数据、ruler 规则等都需要持久化的对象存储来承载。在 SimpleScalable 模式下Chart 默认会部署可参考 simple-scalable-values.yaml 与 values.yaml 中的默认值write默认 3 副本承担 distributor 与 ingester 职责负责日志写入read默认 3 副本承担 querier 与 query-frontend 职责负责日志查询backend默认 3 副本承担 compactor、ruler、index-gateway 等后台任务gateway默认 1 副本基于 Nginx 的入口网关负责流量路由与可选认证。而 SingleBinary、ingester、querier、distributor、compactor 等微服务组件在 SimpleScalable 模式下副本数被置为 0避免重复部署见 simple-scalable-values.yaml。第一步准备 GCP Service Account 凭据在 GCP 控制台或通过gcloud为 Loki 创建一个专用 Service Account为其授予目标 GCS Bucket 的读写权限例如roles/storage.objectAdmin或更细粒度的roles/storage.objectViewerroles/storage.objectCreator然后下载该账号的JSON 格式密钥文件。这份 JSON 文件的内容将作为后续 Kubernetes Secret 的填充数据。提示出于安全最佳实践建议为该 Service Account 仅授予日志存储所需的最小权限并使用 Workload Identity 替代密钥注入的方式不在本文示例范围内示例采用经典的GOOGLE_APPLICATION_CREDENTIALS环境变量注入方式。第二步创建承载凭据的 Kubernetes Secret示例仓库提供了 oss-secrets.yaml 作为 Secret 模板内容如下apiVersion: v1 kind: Secret metadata: name: loki-secrets type: Opaque stringData: gcp_service_account.json: | { GCP_SERVICE_ACCOUNT_JSON_HERE }需要将文件中的GCP_SERVICE_ACCOUNT_JSON_HERE占位符替换为第一步下载的Service Account JSON 密钥的完整内容保留 JSON 结构。Secret 名称固定为loki-secrets密钥条目名为gcp_service_account.json——这个键名与后续 overrides 文件中的挂载路径、环境变量是严格对应的不要随意改名。注意原文 README 中出现的examples/enterprise/enterprise-secrets.yaml为文档笔误OSS 示例实际使用的 Secret 模板是本文所示的 oss-secrets.yaml。替换完成后将 Secret 部署到集群kubectl apply -f loki-secrets.yaml如果 Secret 文件位于示例目录中可直接使用仓库路径kubectl apply -f production/helm/loki/docs/examples/oss/oss-secrets.yaml建议在部署时显式指定命名空间例如--namespace loki并确保后续 Helm 安装使用同一命名空间。第三步编写 Helm overrides 文件并配置 GCS示例的核心是 overrides-oss-gcs.yaml它通过 values 覆盖机制告诉 Helm Chart我要的是开源版 Loki GCS 对象存储。下面逐段拆解其配置含义。3.1 关闭 Enterprise 模式enterprise: enabled: false adminApi: enabled: false useExternalLicense: falseenterprise.enabled: false明确以 OSS开源模式部署不拉取 Grafana Enterprise Logs 镜像、不要求 Licenseenterprise.adminApi.enabled: false关闭 Enterprise 的 Admin API对应 Chart 模板中 admin_client 存储配置的逻辑分支参见 values.yamlenterprise.useExternalLicense: false不引用外部 License Secret。3.2 配置 enterprise.config管理端存储config: | admin_client: storage: gcs: bucket_name: {YOUR_GCS_BUCKET} auth: type: trust auth_enabled: false cluster_name: loki-logs这部分是注入给 Loki 的原始配置文件片段要点如下admin_client.storage.gcs.bucket_name指定管理端存储使用的 GCS Bucket需替换为你的真实 Bucket 名称auth.type: trust与auth_enabled: false在开源模式下关闭认证与 values.yaml 中loki.auth_enabled的默认值形成对照——示例场景为内网可信环境不做多租户鉴权cluster_name: loki-logs自定义集群名称标识。3.3 配置 loki 存储loki: auth_enabled: false commonConfig: path_prefix: /var/loki replication_factor: 3 storage: type: gcs bucketNames: chunks: {YOUR_GCS_BUCKET} ruler: {YOUR_GCS_BUCKET} admin: {YOUR_GCS_BUCKET}loki.auth_enabled: false与上文一致关闭认证。Chart 在非 Enterprise 模式下会将此值渲染进生成的配置见 values.yamlcommonConfig.path_prefix: /var/lokiLoki 各组件本地数据WAL、索引缓存等的统一路径前缀与 Chart 默认值一致values.yamlcommonConfig.replication_factor: 3副本因子为 3配合 SimpleScalable 模式下 write/read/backend 各 3 副本的默认拓扑保证日志数据的高可用storage.type: gcs声明对象存储后端为 GCS。Chart 会根据storage.type自动在生成的配置中填充 GCS 存储相关字段chunkBufferSize、requestTimeout、enableHttp2等见 values.yamlstorage.bucketNames为chunks日志块、ruler告警规则状态、admin管理数据分别指定 Bucket。示例中三处指向同一个 Bucket也可按需拆分。如果你熟悉 values.yaml会发现 Chart 默认的storage.type是s3且bucketNames为注释状态chunks: FIXME、ruler: FIXME、admin: FIXME。本示例通过 overrides 将类型切换为gcs并补齐了 Bucket 名称这正是覆盖默认值的典型用法。3.4 禁用内置 MinIOminio: enabled: falseChart 将 minio默认minio.enabled: falsevalues.yaml。此处显式关闭是为了强调既然已经使用 GCS 作为对象存储就不再需要集群内自建 S3 兼容存储 MinIO避免重复部署。3.5 为各组件注入 GCP 凭据write: extraEnv: - name: GOOGLE_APPLICATION_CREDENTIALS value: /etc/loki_secrets/gcp_service_account.json extraVolumeMounts: - name: loki-secrets mountPath: /etc/loki_secrets extraVolumes: - name: loki-secrets secret: secretName: loki-secrets items: - key: gcp_service_account.json path: gcp_service_account.json read: # ... 与 write 相同的 extraEnv / extraVolumeMounts / extraVolumes 结构 gateway: # ... 与 write 相同的 extraEnv / extraVolumeMounts / extraVolumes 结构这段配置是 GCS 认证的关键。write、read、gateway三组组件都需要访问 GCS因此分别注入了extraVolumes挂载名为loki-secrets的 Secret 卷并从其中取出gcp_service_account.json条目映射为同名文件——这正是 Chart 提供的通用扩展机制values.yamlextraVolumeMounts将 Secret 卷挂载到容器内的/etc/loki_secrets目录extraEnv设置GOOGLE_APPLICATION_CREDENTIALS环境变量指向挂载目录下的 JSON 文件。GCS 客户端 SDK 会读取该环境变量定位服务账号凭据从而完成对 Bucket 的身份认证。三者环环相扣Secret 卷 → 挂载目录 → 环境变量。因此第二步中 Secret 的键名gcp_service_account.json、本处的mountPath与value路径必须保持一致否则组件将无法读取凭据并导致存储访问失败。3.6 替换 Bucket 占位符打开 overrides-oss-gcs.yaml将其中所有{YOUR_GCS_BUCKET}替换为你真实的 GCS Bucket 名称示例中共出现 4 处admin_client1 处 loki.storage.bucketNames3 处。如果需要进一步定制可以参考 Chart 的完整 values.yaml含commonLabels、loki.schemaConfig、loki.querier.max_concurrent、各组件replicas/resources等把需要的覆盖项追加到同一个 overrides 文件中。例如 simple-scalable-values.yaml 演示了如何显式声明deploymentMode: SimpleScalable、设置各组副本数并启用 MinIO使用 S3 存储时。第四步使用 Helm 安装 Chart完成 Secret 与 overrides 文件的准备后执行安装命令helm upgrade --install --values {PATH_TO_YOUR_OVERRIDES_YAML_FILE} {YOUR_RELEASE_NAME} grafana/loki-simple-scalable --namespace {KUBERNETES_NAMESPACE}参数说明参数含义--values {PATH_TO_YOUR_OVERRIDES_YAML_FILE}指向修改后的 overrides-oss-gcs.yaml 路径{YOUR_RELEASE_NAME}本次 Helm Release 的名称例如lokigrafana/loki-simple-scalableChart 在 Helm 仓库中的名称--namespace {KUBERNETES_NAMESPACE}目标命名空间需与 Secret 所在命名空间一致使用helm upgrade --install而非helm install的好处是该命令具备幂等性后续对 overrides 文件做任何修改后重新执行同一条命令即可原地升级无需先卸载再安装。安装完成后可以通过以下命令确认各组件状态kubectl get pods -n {KUBERNETES_NAMESPACE} -l app.kubernetes.io/nameloki kubectl get svc -n {KUBERNETES_NAMESPACE}随后即可在 Grafana 中添加 Loki 数据源指向gateway服务的 HTTP 端口开始查询日志向/loki/api/v1/push推送日志例如通过 Promtail / Alloy 采集端即可验证写入链路。源码级细节这些配置在 Chart 中如何生效理解示例背后 Chart 的渲染逻辑有助于排查问题配置模板的分支逻辑Chart 在生成 Loki 配置文件时会判断enterprise.enabled——为false时渲染auth_enabled: {{ .Values.loki.auth_enabled }}values.yaml为true时则渲染enterprise.config中的管理端与认证配置。overrides 文件中同时设置enterprise.enabled: false与loki.auth_enabled: false正是为了走通 OSS 分支并关闭认证。存储配置的自动填充Chart 的loki.storage块values.yaml定义了types3/gcs/azure 等与各后端参数。声明type: gcs后模板会自动把 GCS 的chunkBufferSize、requestTimeout、enableHttp2等参数写入最终配置并配合bucketNames生成 bucket 映射无需手写完整的 GCS 存储配置段。版本与依赖根据 Chart.yaml当前 Chart 版本为 7.3.0对应 Loki/GEL 版本 3.6.12依赖 minio 5.4.0、grafana-agent-operator 0.5.2、rollout-operator 0.50.0。示例中的loki-simple-scalable即该 Chart 在 Helm 仓库中的发布名称。部署模式默认值deploymentMode默认就是SimpleScalablevalues.yaml因此 overrides 文件中无需显式声明如需切换到单机或微服务模式只需覆盖该值并在values.yaml中调整对应组件的副本数。注意事项与常见问题凭据文件必须为合法 JSONgcp_service_account.json是标准 GCP 服务账号密钥请勿粘贴错误内容或截断 JSON否则 GCS 客户端认证会失败命名空间一致性Secret、Helm Release 与后续 Grafana 数据源应使用同一命名空间避免跨命名空间找不到 SecretBucket 权限最小化Service Account 仅需对目标 Bucket 的读写权限即可无需更宽泛的 GCP 权限与 Enterprise 示例的区别如果后续需要多租户、Admin API 等企业能力可参考 enterprise 示例其中还包含 Admin Token 生成与 Provisioner 自动建租户的流程OSS 示例则以最简单的方式关闭了这些能力存储类型切换若你的环境没有 GCS可参照 simple-scalable-values.yaml 将storage.type改为s3并启用minio其余部署流程完全一致。总结本文完整还原了官方 OSS GCS 示例的部署路径准备 GCP 凭据 → 创建 Secret → 编写 overrides关闭 Enterprise、声明 GCS 存储、注入凭据→ helm 安装。整个方案以 Simple Scalable 架构和 GCS 对象存储为基石兼顾了中等规模日志平台的可扩展性与运维简洁性可作为在云上快速落地 Loki 日志系统、并在此基础上继续定制容量与高可用参数的可靠起点。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loki OSS 在 GKE 上基于 GCS 存储的 Simple Scalable 架构部署指南（Helm Chart 实战）
Loki OSS 在 GKE 上基于 GCS 存储的 Simple Scalable 架构部署指南Helm Chart 实战【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki导读本文基于 Grafana Loki 官方 Helm Chart 仓库中的OSS开源版GCS 示例完整讲解如何在 Google Kubernetes EngineGKE集群上以Simple Scalable简单可扩展架构部署 Loki 开源版本并使用Google Cloud StorageGCS作为统一的对象存储后端。读完本文你将掌握GCP Service Account 凭据的注入方式、Loki OSS 模式非 Enterprise的 Helm overrides 文件编写要点以及通过一条helm upgrade --install命令完成集群日志平台交付的完整实战流程。本文对应的示例文件位于 production/helm/loki/docs/examples/oss是该仓库 examples 示例目录 中与 EnterpriseGEL示例并列的两个入门方案之一适用于希望以纯开源方式快速搭建生产级日志系统的用户。示例场景概览与前置条件官方为 Helm Chart 提供了两组开箱即用的入门示例Loki OSS 示例开源版无企业 License 要求即本文主题Grafana Enterprise Logs 示例需要 Grafana Labs 提供的企业 License。两者共享同一个部署目标在 GKE 上使用 Simple Scalable 架构并以 GCS 作为对象存储。OSS 示例由三个文件组成文件作用README.md部署步骤说明oss-secrets.yaml存放 GCP Service Account JSON 凭据的 Kubernetes Secretoverrides-oss-gcs.yamlHelm values 覆盖文件声明 GCS 存储与关闭 Enterprise 模式在开始部署前需要确认以下资源已经就绪一个可访问的 Kubernetes 集群示例场景为 GKE其他集群同样适用一个 GCS Bucket用于存放 Loki 的 chunk、索引与管理数据一个 GCP Service Account且该账号对上述 GCS Bucket 具有读写权限read/write permissions本机已安装kubectl与helm并已配置好对集群的访问凭据。架构背景为什么选择 Simple Scalable 与 GCS示例使用的部署模式由 Chart 中的deploymentMode决定。查看 values.yaml 可以看到该 Chart 支持三种核心部署模式SingleBinary单二进制模式适合每天数十 GB 以内的小型部署通常无需 HASimpleScalable拆分为read、write、backend三类组件适合中等规模约 1TB/天 以内比微服务模式更易管理——这也是本示例采用的模式且是 Chart 的默认值Distributed完整微服务化拆分功能最全但最复杂适合每天 1TB 以上的大型部署。同时 Chart 还提供了两种用于迁移的中间模式SingleBinary↔SimpleScalable、SimpleScalable↔Distributed。需要特别注意的是SimpleScalable 与 Distributed 模式都强制要求使用对象存储这正是示例选择 GCS 的根本原因——Loki 的 chunk、索引元数据、ruler 规则等都需要持久化的对象存储来承载。在 SimpleScalable 模式下Chart 默认会部署可参考 simple-scalable-values.yaml 与 values.yaml 中的默认值write默认 3 副本承担 distributor 与 ingester 职责负责日志写入read默认 3 副本承担 querier 与 query-frontend 职责负责日志查询backend默认 3 副本承担 compactor、ruler、index-gateway 等后台任务gateway默认 1 副本基于 Nginx 的入口网关负责流量路由与可选认证。而 SingleBinary、ingester、querier、distributor、compactor 等微服务组件在 SimpleScalable 模式下副本数被置为 0避免重复部署见 simple-scalable-values.yaml。第一步准备 GCP Service Account 凭据在 GCP 控制台或通过gcloud为 Loki 创建一个专用 Service Account为其授予目标 GCS Bucket 的读写权限例如roles/storage.objectAdmin或更细粒度的roles/storage.objectViewerroles/storage.objectCreator然后下载该账号的JSON 格式密钥文件。这份 JSON 文件的内容将作为后续 Kubernetes Secret 的填充数据。提示出于安全最佳实践建议为该 Service Account 仅授予日志存储所需的最小权限并使用 Workload Identity 替代密钥注入的方式不在本文示例范围内示例采用经典的GOOGLE_APPLICATION_CREDENTIALS环境变量注入方式。第二步创建承载凭据的 Kubernetes Secret示例仓库提供了 oss-secrets.yaml 作为 Secret 模板内容如下apiVersion: v1 kind: Secret metadata: name: loki-secrets type: Opaque stringData: gcp_service_account.json: | { GCP_SERVICE_ACCOUNT_JSON_HERE }需要将文件中的GCP_SERVICE_ACCOUNT_JSON_HERE占位符替换为第一步下载的Service Account JSON 密钥的完整内容保留 JSON 结构。Secret 名称固定为loki-secrets密钥条目名为gcp_service_account.json——这个键名与后续 overrides 文件中的挂载路径、环境变量是严格对应的不要随意改名。注意原文 README 中出现的examples/enterprise/enterprise-secrets.yaml为文档笔误OSS 示例实际使用的 Secret 模板是本文所示的 oss-secrets.yaml。替换完成后将 Secret 部署到集群kubectl apply -f loki-secrets.yaml如果 Secret 文件位于示例目录中可直接使用仓库路径kubectl apply -f production/helm/loki/docs/examples/oss/oss-secrets.yaml建议在部署时显式指定命名空间例如--namespace loki并确保后续 Helm 安装使用同一命名空间。第三步编写 Helm overrides 文件并配置 GCS示例的核心是 overrides-oss-gcs.yaml它通过 values 覆盖机制告诉 Helm Chart我要的是开源版 Loki GCS 对象存储。下面逐段拆解其配置含义。3.1 关闭 Enterprise 模式enterprise: enabled: false adminApi: enabled: false useExternalLicense: falseenterprise.enabled: false明确以 OSS开源模式部署不拉取 Grafana Enterprise Logs 镜像、不要求 Licenseenterprise.adminApi.enabled: false关闭 Enterprise 的 Admin API对应 Chart 模板中 admin_client 存储配置的逻辑分支参见 values.yamlenterprise.useExternalLicense: false不引用外部 License Secret。3.2 配置 enterprise.config管理端存储config: | admin_client: storage: gcs: bucket_name: {YOUR_GCS_BUCKET} auth: type: trust auth_enabled: false cluster_name: loki-logs这部分是注入给 Loki 的原始配置文件片段要点如下admin_client.storage.gcs.bucket_name指定管理端存储使用的 GCS Bucket需替换为你的真实 Bucket 名称auth.type: trust与auth_enabled: false在开源模式下关闭认证与 values.yaml 中loki.auth_enabled的默认值形成对照——示例场景为内网可信环境不做多租户鉴权cluster_name: loki-logs自定义集群名称标识。3.3 配置 loki 存储loki: auth_enabled: false commonConfig: path_prefix: /var/loki replication_factor: 3 storage: type: gcs bucketNames: chunks: {YOUR_GCS_BUCKET} ruler: {YOUR_GCS_BUCKET} admin: {YOUR_GCS_BUCKET}loki.auth_enabled: false与上文一致关闭认证。Chart 在非 Enterprise 模式下会将此值渲染进生成的配置见 values.yamlcommonConfig.path_prefix: /var/lokiLoki 各组件本地数据WAL、索引缓存等的统一路径前缀与 Chart 默认值一致values.yamlcommonConfig.replication_factor: 3副本因子为 3配合 SimpleScalable 模式下 write/read/backend 各 3 副本的默认拓扑保证日志数据的高可用storage.type: gcs声明对象存储后端为 GCS。Chart 会根据storage.type自动在生成的配置中填充 GCS 存储相关字段chunkBufferSize、requestTimeout、enableHttp2等见 values.yamlstorage.bucketNames为chunks日志块、ruler告警规则状态、admin管理数据分别指定 Bucket。示例中三处指向同一个 Bucket也可按需拆分。如果你熟悉 values.yaml会发现 Chart 默认的storage.type是s3且bucketNames为注释状态chunks: FIXME、ruler: FIXME、admin: FIXME。本示例通过 overrides 将类型切换为gcs并补齐了 Bucket 名称这正是覆盖默认值的典型用法。3.4 禁用内置 MinIOminio: enabled: falseChart 将 minio默认minio.enabled: falsevalues.yaml。此处显式关闭是为了强调既然已经使用 GCS 作为对象存储就不再需要集群内自建 S3 兼容存储 MinIO避免重复部署。3.5 为各组件注入 GCP 凭据write: extraEnv: - name: GOOGLE_APPLICATION_CREDENTIALS value: /etc/loki_secrets/gcp_service_account.json extraVolumeMounts: - name: loki-secrets mountPath: /etc/loki_secrets extraVolumes: - name: loki-secrets secret: secretName: loki-secrets items: - key: gcp_service_account.json path: gcp_service_account.json read: # ... 与 write 相同的 extraEnv / extraVolumeMounts / extraVolumes 结构 gateway: # ... 与 write 相同的 extraEnv / extraVolumeMounts / extraVolumes 结构这段配置是 GCS 认证的关键。write、read、gateway三组组件都需要访问 GCS因此分别注入了extraVolumes挂载名为loki-secrets的 Secret 卷并从其中取出gcp_service_account.json条目映射为同名文件——这正是 Chart 提供的通用扩展机制values.yamlextraVolumeMounts将 Secret 卷挂载到容器内的/etc/loki_secrets目录extraEnv设置GOOGLE_APPLICATION_CREDENTIALS环境变量指向挂载目录下的 JSON 文件。GCS 客户端 SDK 会读取该环境变量定位服务账号凭据从而完成对 Bucket 的身份认证。三者环环相扣Secret 卷 → 挂载目录 → 环境变量。因此第二步中 Secret 的键名gcp_service_account.json、本处的mountPath与value路径必须保持一致否则组件将无法读取凭据并导致存储访问失败。3.6 替换 Bucket 占位符打开 overrides-oss-gcs.yaml将其中所有{YOUR_GCS_BUCKET}替换为你真实的 GCS Bucket 名称示例中共出现 4 处admin_client1 处 loki.storage.bucketNames3 处。如果需要进一步定制可以参考 Chart 的完整 values.yaml含commonLabels、loki.schemaConfig、loki.querier.max_concurrent、各组件replicas/resources等把需要的覆盖项追加到同一个 overrides 文件中。例如 simple-scalable-values.yaml 演示了如何显式声明deploymentMode: SimpleScalable、设置各组副本数并启用 MinIO使用 S3 存储时。第四步使用 Helm 安装 Chart完成 Secret 与 overrides 文件的准备后执行安装命令helm upgrade --install --values {PATH_TO_YOUR_OVERRIDES_YAML_FILE} {YOUR_RELEASE_NAME} grafana/loki-simple-scalable --namespace {KUBERNETES_NAMESPACE}参数说明参数含义--values {PATH_TO_YOUR_OVERRIDES_YAML_FILE}指向修改后的 overrides-oss-gcs.yaml 路径{YOUR_RELEASE_NAME}本次 Helm Release 的名称例如lokigrafana/loki-simple-scalableChart 在 Helm 仓库中的名称--namespace {KUBERNETES_NAMESPACE}目标命名空间需与 Secret 所在命名空间一致使用helm upgrade --install而非helm install的好处是该命令具备幂等性后续对 overrides 文件做任何修改后重新执行同一条命令即可原地升级无需先卸载再安装。安装完成后可以通过以下命令确认各组件状态kubectl get pods -n {KUBERNETES_NAMESPACE} -l app.kubernetes.io/nameloki kubectl get svc -n {KUBERNETES_NAMESPACE}随后即可在 Grafana 中添加 Loki 数据源指向gateway服务的 HTTP 端口开始查询日志向/loki/api/v1/push推送日志例如通过 Promtail / Alloy 采集端即可验证写入链路。源码级细节这些配置在 Chart 中如何生效理解示例背后 Chart 的渲染逻辑有助于排查问题配置模板的分支逻辑Chart 在生成 Loki 配置文件时会判断enterprise.enabled——为false时渲染auth_enabled: {{ .Values.loki.auth_enabled }}values.yaml为true时则渲染enterprise.config中的管理端与认证配置。overrides 文件中同时设置enterprise.enabled: false与loki.auth_enabled: false正是为了走通 OSS 分支并关闭认证。存储配置的自动填充Chart 的loki.storage块values.yaml定义了types3/gcs/azure 等与各后端参数。声明type: gcs后模板会自动把 GCS 的chunkBufferSize、requestTimeout、enableHttp2等参数写入最终配置并配合bucketNames生成 bucket 映射无需手写完整的 GCS 存储配置段。版本与依赖根据 Chart.yaml当前 Chart 版本为 7.3.0对应 Loki/GEL 版本 3.6.12依赖 minio 5.4.0、grafana-agent-operator 0.5.2、rollout-operator 0.50.0。示例中的loki-simple-scalable即该 Chart 在 Helm 仓库中的发布名称。部署模式默认值deploymentMode默认就是SimpleScalablevalues.yaml因此 overrides 文件中无需显式声明如需切换到单机或微服务模式只需覆盖该值并在values.yaml中调整对应组件的副本数。注意事项与常见问题凭据文件必须为合法 JSONgcp_service_account.json是标准 GCP 服务账号密钥请勿粘贴错误内容或截断 JSON否则 GCS 客户端认证会失败命名空间一致性Secret、Helm Release 与后续 Grafana 数据源应使用同一命名空间避免跨命名空间找不到 SecretBucket 权限最小化Service Account 仅需对目标 Bucket 的读写权限即可无需更宽泛的 GCP 权限与 Enterprise 示例的区别如果后续需要多租户、Admin API 等企业能力可参考 enterprise 示例其中还包含 Admin Token 生成与 Provisioner 自动建租户的流程OSS 示例则以最简单的方式关闭了这些能力存储类型切换若你的环境没有 GCS可参照 simple-scalable-values.yaml 将storage.type改为s3并启用minio其余部署流程完全一致。总结本文完整还原了官方 OSS GCS 示例的部署路径准备 GCP 凭据 → 创建 Secret → 编写 overrides关闭 Enterprise、声明 GCS 存储、注入凭据→ helm 安装。整个方案以 Simple Scalable 架构和 GCS 对象存储为基石兼顾了中等规模日志平台的可扩展性与运维简洁性可作为在云上快速落地 Loki 日志系统、并在此基础上继续定制容量与高可用参数的可靠起点。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考