Loki 简单可扩展部署（SSD）三目标迁移指南：从 read/write 两目标演进到 read/write/backend 三目标

Loki 简单可扩展部署SSD三目标迁移指南从 read/write 两目标演进到 read/write/backend 三目标【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki本文围绕 Loki Helm 官方迁移指南 migrate-to-three-scalable-targets 展开讲解如何将 Simple Scalable DeploymentSSD简单可扩展部署从旧的两目标read write配置迁移到新的三目标read write backend配置并结合当前仓库中 production/helm/loki 图表的 values 定义与 Kubernetes 模板说明read.legacyReadTarget开关在每个资源模板中的实际作用帮助你安全完成helm upgrade并验证迁移结果。需要先强调的一点文档开篇即给出弃用警示——SSD 模式本身正在被废弃并将在 Loki 4.0 发布时移除届时将不再支持以 SSD 模式运行 Loki。因此这次两目标迁移三目标是 SSD 用户的过渡动作长期规划应是将集群迁移到 microservices 或 HA monolithic 部署形态。一、迁移背景三目标配置改了什么旧的两目标 SSD 配置只有read与write两个组件read 组件以 StatefulSet 方式运行同时承担查询前端与后台任务如 compactor等职责并持有本地持久化卷。新的三目标配置引入了独立的backend组件把 read 组件瘦身为只运行Querier和QueryFrontend从而让 read 可以退化为无状态组件以 KubernetesDeployment而非StatefulSet方式部署。这一差异在当前仓库的 Helm 模板中可以直接印证templates/read/statefulset-read.yaml 仅在SimpleScalable且read.legacyReadTarget为true时渲染即旧的两目标 read StatefulSettemplates/read/deployment-read.yaml 仅在read.legacyReadTarget为false时渲染即新的三目标 read Deploymenttemplates/backend/statefulset-backend.yaml 等一组 backend 资源模板Service、headless Service、HPA、PDB、query-scheduler 发现配置同样以not .Values.read.legacyReadTarget为渲染条件。另外SimpleScalable的判定逻辑在 templates/_helpers.tpl 中定义为必须使用对象存储loki.isUsingObjectStorage为 true且deploymentMode为SimpleScalable、SingleBinary-SimpleScalable或SimpleScalable-Distributed之一。也就是说只有对象存储 SSD 模式的集群才适用本迁移路径。二、迁移前置条件官方指南建议准备 Grafana 实例。迁移过程中新旧组件会先后接管流量建议用 Grafana 同时监控现有集群与新集群确认迁移全程无数据丢失。利用 chart 自带监控。lokichart 内置自监控能力包含配套仪表盘dashboards在迁移期间可用于观测集群健康状态。三、迁移操作步骤步骤 1确认 Loki 镜像版本足够新三目标功能最初是在 Loki 的main分支中通过 Helm chart 选项落地的。因此如果你的发布版本较老可能需要手动覆盖loki或enterpriseGEL镜像指向包含第三个backendtarget 的版本。按文档给出的方式在values.yaml中添加loki: image: repository: grafana/loki tag: main-f5fbfab-amd64对于 GELenterprise-logsenterprise: image: repository: grafana/enterprise-logs tag: main-96f32b9f注意文档中的 tag 是功能合入main分支时点的示例值。以当前仓库的 chart 为准三目标配置已是read.legacyReadTarget的默认行为见下节近期正式发布的 Loki 镜像均已包含backendtarget直接使用较新的发布版本 tag 即可无需照抄上述 main 分支 tag。步骤 2将read.legacyReadTarget设为 false这是本次迁移唯一的开关项。该参数在 production/helm/loki/values.yaml 中的定义为# -- Whether or not to use the 2 target type simple scalable mode (read, write) or the # 3 target type (read, write, backend). Legacy refers to the 2 target type, so true will # run two targets, false will run 3 targets. legacyReadTarget: false即true运行旧的两目标模式false运行新的三目标模式当前 chart 的默认值已经是false。在你的values.yaml中显式声明read: legacyReadTarget: false步骤 3执行 helm upgrade使用更新后的values.yaml对现有安装执行helm upgrade。升级后集群将渲染出新的 backend StatefulSetread 组件从 StatefulSet 切换为 Deployment并伴随旧 read StatefulSet 及其持久化卷的回收。四、开关之下的模板行为三目标配置到底部署了什么结合模板源码可以准确预期升级后各资源的形态便于升级后逐项核对。read 组件从 StatefulSet 变为 Deploymenttemplates/read/deployment-read.yaml 显示三目标模式下的 read Deployment副本数由read.replicas控制values.yaml 中默认 3滚动更新策略为maxSurge: 0, maxUnavailable: 1与旧 read StatefulSet 的podManagementPolicy 逐 Pod 更新方式不同这正是 read 无状态化后能采用 Deployment 的前提数据卷从持久化卷改为emptyDir见 deployment-read.yaml L157-L158。values 中对应注释也明确写着read.persistence is used only if legacyReadTarget is set to true见 values.yaml L1835容器启动参数L73-L77为-config.file/etc/loki/config/config.yaml -targetloki.readTarget 辅助函数渲染的模块列表 -legacy-read-modefalse -common.compactor-grpc-addressbackend-fullname.namespace.svc.clusterDomain:grpc_listen_port其中-common.compactor-grpc-address指向 backend 组件的 gRPC 服务地址——这从启动参数上印证了后台任务compactor 等已从 read 迁出、read 通过 gRPC 与 backend 协作的结构变化。backend 组件新增的 StatefulSettemplates/backend/statefulset-backend.yaml 中 backend Pod 的容器启动参数为-config.file/etc/loki/config/config.yaml -targetbackend # 来自 backend.targetModule 默认值 -legacy-read-modefalsebackend 的关键默认配置values.yaml backend 段参数默认值说明backend.replicas3backend 副本数backend.targetModulebackend加载的 Loki 模块列表backend.terminationGracePeriodSeconds300优雅退出时长保证 flush/transfer 与离开 memberlist 环的时间backend.persistence.size10Gi每 Pod 数据卷大小ReadWriteOncebackend.autoscaling.enabledfalse开启后渲染 HPAmin 3 / max 6CPU 目标 60%模板中还有一段值得注意的注释statefulset-backend.yaml L32-L40backend 节点上的数据容易被替换因此在启用enableStatefulSetAutoDeletePVC且 Kubernetes 1.23 时会配置persistentVolumeClaimRetentionPolicy: whenDeleted: Delete / whenScaled: Delete删除/缩容时直接回收 PVC依赖需要时重新拉取数据。这与 read 的持久卷在 legacy 模式下被自动回收的处理思路一致见 statefulset-read.yaml L35-L43。其他被同一开关切换的资源Service 路由values 中说明values.yaml L1412当部署模式为 SimpleScalable 且read.legacyReadTarget为true时请求转发到loki.readFullname服务为false时则新增 backend Servicetemplates/backend/service-backend.yaml 与 service-backend-headless.yaml。Ingress 路径templates/_helpers.tpl L589-L599 中legacyReadTarget为false时走loki.ingress.scalableServicePaths新三目标路由否则走legacyScalableServicePaths旧两目标路由backend 职责仍在 read 上。HPA 与 PDBread HPA 仅在not .Values.read.legacyReadTarget时渲染templates/read/hpa.yamlbackend 侧同样提供 hpa.yaml 与副本数 1 时的 poddisruptionbudget-backend.yaml。五、升级后的验证建议核对工作负载形态kubectl get statefulset,deployment应看到新的 backend StatefulSet 与 read Deployment 就位旧的 read StatefulSet 消失read.persistence的 PVC 会按模板中的回收策略处理。核对启动参数read Pod 应带-legacy-read-modefalse与-common.compactor-grpc-addressbackend 服务地址backend Pod 应带-targetbackend。用 Grafana 观测查询链路依托 chart 自带的自监控仪表盘确认查询延迟、错误率与日志摄入速率在升级前后无明显回退确认无数据丢失。规划下一步再次强调SSD 模式将在 Loki 4.0 中移除。完成三目标迁移只解决了当前 SSD 集群内的组件拆分问题从源码结构看仓库同时维护着完整的 microservices 形态ingester/distributor/query-frontend 等独立组件见 values.yaml 中 Microservices Mode 段落与 HA monolithic 示例examples/ha-monolithic应作为 SSD 的最终去向纳入容量与发布计划。小结本次迁移的核心只有一个开关read.legacyReadTarget: false。它驱动 Helm 模板完成三类切换——read 从带持久卷的 StatefulSet 变为无状态 Deployment、新增 backend StatefulSet 承接后台任务、Service/Ingress 路由指向新组件。配合 Grafana 监控与helm upgrade即可在不停机的情况下把 SSD 集群升级到三目标形态同时需记住 SSD 模式的整体弃用路线把 microservices 或 HA monolithic 部署作为后续目标。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考