Loki Operator 本地开发实战用make run在 Kind 与 OpenShift 上快速迭代【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki导读本文以 operator/docs/operator/hack_operator_make_run.md 为主线系统讲解如何在不打包、不推送容器镜像的前提下使用make run在本地机器上直接运行 Loki Operator并在 Kind 或 OpenShift 集群中完成开发与联调。读完本文你将掌握本地启动 Operator 的完整命令链、MinIO/S3 对象存储与 OIDC 网关 Secret 的配置方法、代码改动的快速热迭代流程以及常见的多集群 Context 切换与网关 Secret 缺失类故障排查手段并能结合仓库 Makefile 与 main.go 源码理解make run背后的真实调用链。为什么用make run做开发Loki Operator 是管理 Loki 日志堆栈的 Kubernetes Operator自定义资源为LokiStack常规的部署方式如make deploy需要把 Operator 构建成镜像并部署到集群内。然而在开发迭代阶段每次改动一行 Go 代码就重新构建镜像、推送到仓库、滚动更新 Pod成本极高。make run的价值在于Operator 以本地进程的方式运行在你的开发机上直接通过~/.kube/config中的集群凭据与集群 API 通信。这意味着改动代码后只需CTRL C停掉本地进程重新执行make run即可生效无需反复构建和部署 Operator 镜像Operator 与集群之间走的是标准 kubeconfig 认证与集群内运行时行为一致适合最后的端到端验证。从 Makefile 可以看到该目标的具体定义.PHONY: run run: generate manifests ## Run against the configured Kubernetes cluster in ~/.kube/config go run ./cmd/loki-operator/main.go也就是说make run会先执行generate通过controller-gen生成深拷贝代码与manifests生成 CRD、RBAC 等清单随后直接go run启动 cmd/loki-operator/main.go完全绕过了镜像构建环节。这也解释了文档中每次改动代码只需重启本地进程的可行性。在 Kind 上使用make run开发前置要求安装 [kubectl] 或 OpenShift CLI用于与集群通信下文示例使用kubectl使用 kind 创建一个正在运行的 Kubernetes 集群。kind 是基于 Docker 容器节点的本地 Kubernetes 集群工具最初用于测试 Kubernetes 本身也常用于本地开发与 CI。安装 Loki Operator第一步安装 CRDmake install该命令通过 kustomize 构建 config/crd 下的 CRD 清单并应用到集群会创建名为lokistacks.loki.grafana.com的自定义资源定义可用以下命令验证kubectl get crd lokistacks.loki.grafana.com从 Makefile 看install实际执行的是.PHONY: install install: manifests $(KUSTOMIZE) ## Install CRDs into a cluster $(KUSTOMIZE) build config/crd | kubectl apply -f -第二步部署 MinIO 作为对象存储kubectl apply -k config/overlays/development/minio该命令会在default命名空间创建 MinIO 的deployment、service、pvc和secret。目录下共有五个资源文件kustomization.yaml 引用了 pvc、service、secret、deployment其中值得关注的是 secret.yaml它正是 LokiStack 声明要使用的对象存储凭据apiVersion: v1 kind: Secret metadata: name: test stringData: endpoint: http://minio.default.svc:9000 bucketnames: loki access_key_id: minio access_key_secret: minio123 type: Opaque对应的 deployment.yaml 以minio/minio镜像启动root 用户/密码为minio/minio123并会在启动时创建/storage/loki目录数据落在名为minio的 PVC 上。这个testSecret 的名字与下文 LokiStack 示例中storage.secret.name: test严格对应这也体现了Secret 名称必须与 LokiStack 引用一致的约定。第三步创建 LokiStack 实例kubectl apply -f hack/lokistack_dev.yaml仓库中的 hack/lokistack_dev.yaml 是一个极简示例apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: lokistack-dev spec: size: 1x.demo storage: schemas: - version: v13 effectiveDate: 2023-10-15 secret: name: test type: s3 storageClassName: standard其中size: 1x.demo表示使用 demo 级堆栈规格storage.secret.name: test指向刚创建的 MinIO Secretstorage.secret.type: s3声明后端为 S3 兼容存储。第四步本地运行 Operatormake run此时 Operator 在本地启动它会识别集群中的LokiStackCRD 实例并自动创建distributor、compactor、ingester、querier和query-frontend等 Loki 核心组件。第五步确认组件就绪Deployment 类的组件用 rollout 状态确认kubectl rollout status deployment/DEPLOYMENT_NAME其中DEPLOYMENT_NAME可通过以下命令获取kubectl get deploymentsStatefulSet 类的组件同理kubectl rollout status statefulset/STATEFULSET_NAME名称列表来自kubectl get statefulsets代码热迭代改完即跑如果你修改了 Operator 的代码只需在本地终端按CTRL C停掉 Operator更新代码后重新执行make run即可让新代码立即生效无需反复把 Operator 部署到集群中这是开发效率的关键所在。当所有改动验证通过后再按正式流程将全部内容部署到集群做最终测试可参考 operator 文档目录下 operator/docs/operator 中关于完整部署流程的文档。清理按CTRL C停止本地 Operator 进程清理集群中的 LokiStack 实例、CRD 与相关资源make uninstalluninstall目标同样基于 kustomize 构建 CRD 清单执行删除并支持ignore-not-foundtrue忽略不存在资源的报错.PHONY: uninstall uninstall: manifests $(KUSTOMIZE) ## Uninstall CRDs from the K8s cluster specified in ~/.kube/config. Call with ignore-not-foundtrue to ignore resource not found errors during deletion. $(KUSTOMIZE) build config/crd | kubectl delete --ignore-not-found$(ignore-not-found) -f -删除 MinIO 相关资源kubectl delete -k config/overlays/development/minio在 OpenShift 上使用make run开发前置要求安装 kubectl 或 OpenShift CLI下文示例使用kubectl在 AWS 上创建一个运行中的 OpenShift 集群在某个 AWS Region 中创建一个 S3 bucket。安装 Loki Operator第一步安装 CRDmake install验证方式与 Kind 场景一致kubectl get crd lokistacks.loki.grafana.com第二步创建命名空间kubectl create ns openshift-logging第三步创建对象存储 Secret./hack/deploy-aws-storage-secret.sh BUCKET_NAME该脚本会在openshift-logging命名空间中创建名为test的 Secret。查看 hack/deploy-aws-storage-secret.sh 可了解其内部逻辑默认情况下它通过awsCLI 从当前 profile 读取region、access_key_id、secret_access_key并生成包含region、bucketnames、access_key_id、access_key_secret、endpoint格式为https://s3.region.amazonaws.com等字段的 Secret。这些值都可以通过环境变量覆盖例如REGIONus-west-1 ./hack/deploy-aws-storage-secret.sh BUCKET_NAME脚本还支持其他覆盖项NAMESPACE默认openshift-logging、ACCESS_KEY_ID、SECRET_ACCESS_KEY。若传入STStrue则切换为 STS 托管认证模式此时只写入region、bucketnames与可选的role_arn第二个命令行参数用于配合 OpenShift Cloud-Credentials-Operator 的托管场景。第四步创建 LokiStack 实例kubectl -n openshift-logging apply -f hack/lokistack_dev.yaml第五步本地运行 Operatormake run此时只会创建distributor、compactor、ingester、querier和query-frontend组件不含网关。验证方式与 Kind 场景一致但需要带上命名空间参数kubectl -n openshift-logging rollout status deployment/DEPLOYMENT_NAME kubectl -n openshift-logging get deployments kubectl -n openshift-logging rollout status statefulset/STATEFULSET_NAME kubectl -n openshift-logging get statefulsets可选组件lokistack-gatewaylokistack-gateway是 Loki Operator 部署的可选组件它通过校验请求主体的 OAuth/OIDC 端点为 Loki 的 distributor推送日志与 query-frontend查询日志提供安全访问。若需要部署该组件必须先为 Operator 创建网关 Secretkubectl -n openshift-logging create secret generic test1 \ --from-literalclientIDCLIENT_ID \ --from-literalclientSecretCLIENT_SECRET \ --from-literalissuerCAPathISSUER_CA_PATHOIDC 配置需要clientID、clientSecret与issuerCAPath三个字段由 LokiStack 管理员预先以 Kubernetes Secret 形式提供。每个租户 Secret 必须满足metadata.name与TenantsSecretsSpec.Name一致metadata.namespace与LokiStack.metadata.namespace一致。接着应用带网关配置的 LokiStack 示例kubectl -n openshift-logging apply -f hack/lokistack_gateway_dev.yaml仓库中的 hack/lokistack_gateway_dev.yaml 展示了完整的多租户网关配置其中包含一个名为test-oidc的 OIDC 认证 SecretclientID: lokistack以及配套的tenants.mode: static、authentication、authorization角色read-write拥有logs资源的读写权限定义可作为网关场景的参考模板。随后编辑 operator/cmd/loki-operator/main.go将网关相关的 feature gate 标志如LokiStackGateway设置为true再重新运行make run此时会创建distributor、compactor、ingester、querier、query-frontend以及lokistack-gateway共六个组件。从 main.go 源码可以看到网关开关会触发额外依赖注入如 OpenShift 的route、cloudcredential等 API 注册进 scheme并在LokiStackReconciler中携带FeatureGates配置参与组件编排同时 main.go 中还做了强校验例如LokiStackAlerts标志依赖ServiceMonitors、ServiceMonitorTLSEndpoints依赖HTTPEncryption不满足会直接报错退出这解释了为什么改动这些标志后必须重启本地进程。与之前相同的代码热迭代流程依然适用CTRL C停止 → 修改代码 →make run重启无需反复部署。清理按CTRL C停止本地 Operator清理 LokiStack 实例、CRD 与集群资源make uninstall常见问题排查场景一kubectl 使用了过期的 Context当你在 Kind 集群与 OpenShift 集群之间来回切换测试时kubectl 可能不会自动切换 context导致命令发往了错误的集群。解决方法是手动切换先列出所有可用 context*标记表示当前正在使用的 contextkubectl config get-contexts再切换到目标 contextkubectl config use-context $CONTEXTNAME其中$CONTEXTNAME取自上一步列出的 context 名称。场景二Missing Secrets / Invalid Secrets 错误如果你没有先创建网关 Secret 就直接应用了带网关的 LokiStackOperator 会进入degraded降级状态并报出该错误。解决办法是按照上文步骤先创建网关 Secret再创建 LokiStack 实例。可以通过查看 LokiStack 的conditions字段验证当前状态kubectl get lokistack lokistack-dev -o yamlOpenShift 环境下需要加上命名空间参数kubectl -n openshift-logging get lokistack lokistack-dev -o yaml场景三Mandatory Configuration / Incompatible Configuration 错误这通常意味着 LokiStack CR 针对 lokistack-gateway 的配置有误。需要核对 OIDC 相关配置如clientID、clientSecret、issuerCAPath、租户 Secret 的 name/namespace 匹配关系等是否符合 LokiStack 网关配置的规范要求参考上文可选组件lokistack-gateway一节的字段说明逐一检查。小结make run为 Loki Operator 开发者提供了一条改代码 → 重启本地进程 → 立即验证的极速迭代路径。无论底层是 Kind 还是 OpenShift核心套路一致make install装 CRD → 准备对象存储MinIO 或 AWS S3 Secret→ 应用 LokiStack 实例 →make run本地起 Operator → rollout 验证组件 →CTRL C热迭代 →make uninstall清理。若涉及网关场景则额外补齐 OIDC 网关 Secret 并开启对应 feature gate。配套的 Makefile、cmd/loki-operator/main.go、hack/ 目录下的示例清单以及 config/overlays/development/minio 的 MinIO overlay都是快速搭建本地开发环境时可参考的直接依据。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Loki Operator 本地开发实战：用 `make run` 在 Kind 与 OpenShift 上快速迭代
Loki Operator 本地开发实战用make run在 Kind 与 OpenShift 上快速迭代【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki导读本文以 operator/docs/operator/hack_operator_make_run.md 为主线系统讲解如何在不打包、不推送容器镜像的前提下使用make run在本地机器上直接运行 Loki Operator并在 Kind 或 OpenShift 集群中完成开发与联调。读完本文你将掌握本地启动 Operator 的完整命令链、MinIO/S3 对象存储与 OIDC 网关 Secret 的配置方法、代码改动的快速热迭代流程以及常见的多集群 Context 切换与网关 Secret 缺失类故障排查手段并能结合仓库 Makefile 与 main.go 源码理解make run背后的真实调用链。为什么用make run做开发Loki Operator 是管理 Loki 日志堆栈的 Kubernetes Operator自定义资源为LokiStack常规的部署方式如make deploy需要把 Operator 构建成镜像并部署到集群内。然而在开发迭代阶段每次改动一行 Go 代码就重新构建镜像、推送到仓库、滚动更新 Pod成本极高。make run的价值在于Operator 以本地进程的方式运行在你的开发机上直接通过~/.kube/config中的集群凭据与集群 API 通信。这意味着改动代码后只需CTRL C停掉本地进程重新执行make run即可生效无需反复构建和部署 Operator 镜像Operator 与集群之间走的是标准 kubeconfig 认证与集群内运行时行为一致适合最后的端到端验证。从 Makefile 可以看到该目标的具体定义.PHONY: run run: generate manifests ## Run against the configured Kubernetes cluster in ~/.kube/config go run ./cmd/loki-operator/main.go也就是说make run会先执行generate通过controller-gen生成深拷贝代码与manifests生成 CRD、RBAC 等清单随后直接go run启动 cmd/loki-operator/main.go完全绕过了镜像构建环节。这也解释了文档中每次改动代码只需重启本地进程的可行性。在 Kind 上使用make run开发前置要求安装 [kubectl] 或 OpenShift CLI用于与集群通信下文示例使用kubectl使用 kind 创建一个正在运行的 Kubernetes 集群。kind 是基于 Docker 容器节点的本地 Kubernetes 集群工具最初用于测试 Kubernetes 本身也常用于本地开发与 CI。安装 Loki Operator第一步安装 CRDmake install该命令通过 kustomize 构建 config/crd 下的 CRD 清单并应用到集群会创建名为lokistacks.loki.grafana.com的自定义资源定义可用以下命令验证kubectl get crd lokistacks.loki.grafana.com从 Makefile 看install实际执行的是.PHONY: install install: manifests $(KUSTOMIZE) ## Install CRDs into a cluster $(KUSTOMIZE) build config/crd | kubectl apply -f -第二步部署 MinIO 作为对象存储kubectl apply -k config/overlays/development/minio该命令会在default命名空间创建 MinIO 的deployment、service、pvc和secret。目录下共有五个资源文件kustomization.yaml 引用了 pvc、service、secret、deployment其中值得关注的是 secret.yaml它正是 LokiStack 声明要使用的对象存储凭据apiVersion: v1 kind: Secret metadata: name: test stringData: endpoint: http://minio.default.svc:9000 bucketnames: loki access_key_id: minio access_key_secret: minio123 type: Opaque对应的 deployment.yaml 以minio/minio镜像启动root 用户/密码为minio/minio123并会在启动时创建/storage/loki目录数据落在名为minio的 PVC 上。这个testSecret 的名字与下文 LokiStack 示例中storage.secret.name: test严格对应这也体现了Secret 名称必须与 LokiStack 引用一致的约定。第三步创建 LokiStack 实例kubectl apply -f hack/lokistack_dev.yaml仓库中的 hack/lokistack_dev.yaml 是一个极简示例apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: lokistack-dev spec: size: 1x.demo storage: schemas: - version: v13 effectiveDate: 2023-10-15 secret: name: test type: s3 storageClassName: standard其中size: 1x.demo表示使用 demo 级堆栈规格storage.secret.name: test指向刚创建的 MinIO Secretstorage.secret.type: s3声明后端为 S3 兼容存储。第四步本地运行 Operatormake run此时 Operator 在本地启动它会识别集群中的LokiStackCRD 实例并自动创建distributor、compactor、ingester、querier和query-frontend等 Loki 核心组件。第五步确认组件就绪Deployment 类的组件用 rollout 状态确认kubectl rollout status deployment/DEPLOYMENT_NAME其中DEPLOYMENT_NAME可通过以下命令获取kubectl get deploymentsStatefulSet 类的组件同理kubectl rollout status statefulset/STATEFULSET_NAME名称列表来自kubectl get statefulsets代码热迭代改完即跑如果你修改了 Operator 的代码只需在本地终端按CTRL C停掉 Operator更新代码后重新执行make run即可让新代码立即生效无需反复把 Operator 部署到集群中这是开发效率的关键所在。当所有改动验证通过后再按正式流程将全部内容部署到集群做最终测试可参考 operator 文档目录下 operator/docs/operator 中关于完整部署流程的文档。清理按CTRL C停止本地 Operator 进程清理集群中的 LokiStack 实例、CRD 与相关资源make uninstalluninstall目标同样基于 kustomize 构建 CRD 清单执行删除并支持ignore-not-foundtrue忽略不存在资源的报错.PHONY: uninstall uninstall: manifests $(KUSTOMIZE) ## Uninstall CRDs from the K8s cluster specified in ~/.kube/config. Call with ignore-not-foundtrue to ignore resource not found errors during deletion. $(KUSTOMIZE) build config/crd | kubectl delete --ignore-not-found$(ignore-not-found) -f -删除 MinIO 相关资源kubectl delete -k config/overlays/development/minio在 OpenShift 上使用make run开发前置要求安装 kubectl 或 OpenShift CLI下文示例使用kubectl在 AWS 上创建一个运行中的 OpenShift 集群在某个 AWS Region 中创建一个 S3 bucket。安装 Loki Operator第一步安装 CRDmake install验证方式与 Kind 场景一致kubectl get crd lokistacks.loki.grafana.com第二步创建命名空间kubectl create ns openshift-logging第三步创建对象存储 Secret./hack/deploy-aws-storage-secret.sh BUCKET_NAME该脚本会在openshift-logging命名空间中创建名为test的 Secret。查看 hack/deploy-aws-storage-secret.sh 可了解其内部逻辑默认情况下它通过awsCLI 从当前 profile 读取region、access_key_id、secret_access_key并生成包含region、bucketnames、access_key_id、access_key_secret、endpoint格式为https://s3.region.amazonaws.com等字段的 Secret。这些值都可以通过环境变量覆盖例如REGIONus-west-1 ./hack/deploy-aws-storage-secret.sh BUCKET_NAME脚本还支持其他覆盖项NAMESPACE默认openshift-logging、ACCESS_KEY_ID、SECRET_ACCESS_KEY。若传入STStrue则切换为 STS 托管认证模式此时只写入region、bucketnames与可选的role_arn第二个命令行参数用于配合 OpenShift Cloud-Credentials-Operator 的托管场景。第四步创建 LokiStack 实例kubectl -n openshift-logging apply -f hack/lokistack_dev.yaml第五步本地运行 Operatormake run此时只会创建distributor、compactor、ingester、querier和query-frontend组件不含网关。验证方式与 Kind 场景一致但需要带上命名空间参数kubectl -n openshift-logging rollout status deployment/DEPLOYMENT_NAME kubectl -n openshift-logging get deployments kubectl -n openshift-logging rollout status statefulset/STATEFULSET_NAME kubectl -n openshift-logging get statefulsets可选组件lokistack-gatewaylokistack-gateway是 Loki Operator 部署的可选组件它通过校验请求主体的 OAuth/OIDC 端点为 Loki 的 distributor推送日志与 query-frontend查询日志提供安全访问。若需要部署该组件必须先为 Operator 创建网关 Secretkubectl -n openshift-logging create secret generic test1 \ --from-literalclientIDCLIENT_ID \ --from-literalclientSecretCLIENT_SECRET \ --from-literalissuerCAPathISSUER_CA_PATHOIDC 配置需要clientID、clientSecret与issuerCAPath三个字段由 LokiStack 管理员预先以 Kubernetes Secret 形式提供。每个租户 Secret 必须满足metadata.name与TenantsSecretsSpec.Name一致metadata.namespace与LokiStack.metadata.namespace一致。接着应用带网关配置的 LokiStack 示例kubectl -n openshift-logging apply -f hack/lokistack_gateway_dev.yaml仓库中的 hack/lokistack_gateway_dev.yaml 展示了完整的多租户网关配置其中包含一个名为test-oidc的 OIDC 认证 SecretclientID: lokistack以及配套的tenants.mode: static、authentication、authorization角色read-write拥有logs资源的读写权限定义可作为网关场景的参考模板。随后编辑 operator/cmd/loki-operator/main.go将网关相关的 feature gate 标志如LokiStackGateway设置为true再重新运行make run此时会创建distributor、compactor、ingester、querier、query-frontend以及lokistack-gateway共六个组件。从 main.go 源码可以看到网关开关会触发额外依赖注入如 OpenShift 的route、cloudcredential等 API 注册进 scheme并在LokiStackReconciler中携带FeatureGates配置参与组件编排同时 main.go 中还做了强校验例如LokiStackAlerts标志依赖ServiceMonitors、ServiceMonitorTLSEndpoints依赖HTTPEncryption不满足会直接报错退出这解释了为什么改动这些标志后必须重启本地进程。与之前相同的代码热迭代流程依然适用CTRL C停止 → 修改代码 →make run重启无需反复部署。清理按CTRL C停止本地 Operator清理 LokiStack 实例、CRD 与集群资源make uninstall常见问题排查场景一kubectl 使用了过期的 Context当你在 Kind 集群与 OpenShift 集群之间来回切换测试时kubectl 可能不会自动切换 context导致命令发往了错误的集群。解决方法是手动切换先列出所有可用 context*标记表示当前正在使用的 contextkubectl config get-contexts再切换到目标 contextkubectl config use-context $CONTEXTNAME其中$CONTEXTNAME取自上一步列出的 context 名称。场景二Missing Secrets / Invalid Secrets 错误如果你没有先创建网关 Secret 就直接应用了带网关的 LokiStackOperator 会进入degraded降级状态并报出该错误。解决办法是按照上文步骤先创建网关 Secret再创建 LokiStack 实例。可以通过查看 LokiStack 的conditions字段验证当前状态kubectl get lokistack lokistack-dev -o yamlOpenShift 环境下需要加上命名空间参数kubectl -n openshift-logging get lokistack lokistack-dev -o yaml场景三Mandatory Configuration / Incompatible Configuration 错误这通常意味着 LokiStack CR 针对 lokistack-gateway 的配置有误。需要核对 OIDC 相关配置如clientID、clientSecret、issuerCAPath、租户 Secret 的 name/namespace 匹配关系等是否符合 LokiStack 网关配置的规范要求参考上文可选组件lokistack-gateway一节的字段说明逐一检查。小结make run为 Loki Operator 开发者提供了一条改代码 → 重启本地进程 → 立即验证的极速迭代路径。无论底层是 Kind 还是 OpenShift核心套路一致make install装 CRD → 准备对象存储MinIO 或 AWS S3 Secret→ 应用 LokiStack 实例 →make run本地起 Operator → rollout 验证组件 →CTRL C热迭代 →make uninstall清理。若涉及网关场景则额外补齐 OIDC 网关 Secret 并开启对应 feature gate。配套的 Makefile、cmd/loki-operator/main.go、hack/ 目录下的示例清单以及 config/overlays/development/minio 的 MinIO overlay都是快速搭建本地开发环境时可参考的直接依据。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考