在 Kubernetes 中部署 Dozzle 实时容器日志查看器k8s 模式完整配置指南【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 不仅是一个 Docker 实时日志查看器还通过DOZZLE_MODEk8s模式原生支持 Kubernetes让你直接在浏览器中查看 Pod 内各容器的实时日志与资源统计。本文以官方文档 docs/guide/k8s.md 为主线结合仓库源码internal/k8s、internal/support/k8s给出可直接落地的 RBAC、Deployment、Service 完整 YAML并深入讲解 Metrics API 依赖、命名空间与标签过滤机制及底层实现原理读完即可在集群中部署并正确配置 Dozzle。Kubernetes 模式如何工作在 k8s 模式下Dozzle 不再连接 Docker daemon而是通过 Kubernetes 官方 Go 客户端k8s.io/client-go访问集群 API。从源码 internal/k8s/client.go 可以看到启动时NewK8sClient会根据环境变量自动选择连接方式若检测到KUBERNETES_SERVICE_HOST环境变量即 Pod 运行在集群内则调用rest.InClusterConfig()使用 ServiceAccount 的挂载凭据进入集群内模式in-cluster mode否则回退读取KUBECONFIG环境变量或$HOME/.kube/config以本地 kubeconfig 进入本地模式local mode。客户端还会读取集群节点列表将每个节点映射为一个 Dozzle 的 Host见 internal/support/k8s/k8s_cluster_service.go节点名称、内存总量、CPU 数、容器运行时版本均取自node.Status。因此部署 Dozzle 时只需为其分配一个拥有足够权限的 ServiceAccount无需挂载任何 Docker socket。Kubernetes 部署完整 YAML官方文档给出了一套完整的声明式配置包含 ServiceAccount、ClusterRole、ClusterRoleBinding、PersistentVolumeClaim、Deployment 与 Service 六个部分与仓库中的 examples/k8s.dozzle.yml 示例一致。将以下内容保存为k8s.yaml执行kubectl apply -f k8s.yaml即可完成部署。# rbac.yaml apiVersion: v1 kind: ServiceAccount metadata: name: pod-viewer --- # clusterrole.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-viewer-role rules: - apiGroups: [] resources: [pods, pods/log, nodes] verbs: [get, list, watch] - apiGroups: [apps] resources: [deployments, replicasets, daemonsets, statefulsets] verbs: [get] - apiGroups: [batch] resources: [jobs, cronjobs] verbs: [get] - apiGroups: [metrics.k8s.io] resources: [pods] verbs: [get, list] --- # clusterrolebinding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pod-viewer-binding subjects: - kind: ServiceAccount name: pod-viewer namespace: default roleRef: kind: ClusterRole name: pod-viewer-role apiGroup: rbac.authorization.k8s.io --- # pvc.yaml # ReadWriteOnce Recreate strategy means cloud config / notification rules # briefly become unavailable during pod rollouts (the new pod cant mount until # the old one releases). For zero-downtime config persistence, use a # ReadWriteMany storage class (NFS, CephFS, etc.) and switch the strategy # below to RollingUpdate. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: dozzle-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi --- # deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: dozzle spec: selector: matchLabels: app: dozzle strategy: type: Recreate template: metadata: labels: app: dozzle spec: serviceAccountName: pod-viewer containers: - name: dozzle image: amir20/dozzle:latest ports: - containerPort: 8080 env: - name: DOZZLE_MODE value: k8s volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: dozzle-data --- # service.yaml apiVersion: v1 kind: Service metadata: name: dozzle-service spec: type: ClusterIP selector: app: dozzle ports: - port: 8080 targetPort: 8080 protocol: TCP各部分职责解读ServiceAccountpod-viewer为 Dozzle Pod 提供集群身份。Deployment 通过serviceAccountName: pod-viewer引用它。ClusterRolepod-viewer-role声明 Dozzle 需要的全部资源权限。核心是pods、pods/log、nodes的get/list/watch用于列出 Pod、流式拉取日志、读取节点信息apps与batch组的get权限用于解析 Pod 的属主链见下文容器标识与属主链metrics.k8s.io的权限则对应 Metrics API 的资源统计读取。ClusterRoleBinding将 ServiceAccount 与 ClusterRole 绑定使 Dozzle 可以跨命名空间访问资源。PVCdozzle-data1Gi挂载到/data用于持久化云配置与通知规则等状态。注意 YAML 注释中的关键提示ReadWriteOnce与Recreate更新策略组合时Pod 滚动期间新 Pod 必须等旧 Pod 释放 PVC 才能挂载云配置/通知规则会短暂不可用如需零停机请改用ReadWriteMany存储类NFS、CephFS 等并将strategy切换为RollingUpdate。Deployment核心启动参数是DOZZLE_MODEk8s这是进入 Kubernetes 模式的开关。容器监听 8080 端口。Servicedozzle-service以ClusterIP暴露 Dozzle 的 8080 端口便于集群内访问或通过 Ingress 对外发布仓库 examples/ingress.yml 提供了 Ingress 参考。GitOps 部署时的命名空间注意点[!WARNING] 如果使用 Flux CD、Argo CD 等 GitOps 工具将这套配置部署到default以外的命名空间必须同步修改 ClusterRoleBinding 中 Subject 的namespace字段否则 ServiceAccount 与角色无法正确绑定Dozzle 会因权限不足而无法读取 Pod。这也是上例中subjects.namespace: default必须与实际部署命名空间保持一致的原因。前置依赖Kubernetes Metrics APIDozzle 的 CPU 与内存统计完全依赖 Kubernetes Metrics APImetrics-server 实现。官方文档明确指出目前这是使用 Kubernetes 模式的硬性要求。安装 metrics-server 后验证 API 是否可用kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml验证命令能正常输出各 Pod 的资源占用即表示 API 已就绪kubectl top pod从源码看这一依赖是强制性的统计采集器 internal/k8s/stats_collector.go 每秒time.NewTicker(1 * time.Second)通过 metrics client 的MetricsV1beta1().PodMetricses(namespace).List()拉取各命名空间的 Pod 指标并将每个容器的用量转换为 Dozzle 的统计结构CPUc.Usage.Cpu().MilliValue() / 1000 * 100即按核数百分比计算内存c.Usage.Memory().AsApproximateFloat64()网络直接置为 0 —— 注释明确说明 Kubernetes Metrics API 默认不暴露网络统计如需网络指标需要自定义 metrics 或集成 cAdvisor。因此如果你在界面上看到网络收发量为 0属于正常现象这是 Metrics API 的能力边界而非故障。限制监控范围命名空间过滤默认情况下Dozzle 会监控集群所有命名空间。若只想关注某个命名空间设置DOZZLE_NAMESPACE环境变量即可apiVersion: apps/v1 kind: Deployment metadata: name: dozzle spec: selector: matchLabels: app: dozzle template: metadata: labels: app: dozzle spec: serviceAccountName: pod-viewer containers: - name: dozzle image: amir20/dozzle:latest ports: - containerPort: 8080 env: - name: DOZZLE_MODE value: k8s - name: DOZZLE_NAMESPACE value: default[!NOTE]DOZZLE_NAMESPACE支持逗号分隔的多个命名空间例如value: default,prod。指定多个命名空间时Dozzle 会对每个命名空间分别监控并合并结果。这一行为的源码依据在 internal/k8s/client.goNewK8sClient接收命名空间切片为空时默认使用metav1.NamespaceAll即全部命名空间ListContainers与ContainerEvents也都会对每个命名空间并行执行Pods(namespace).List/Watch见 client.go并以lop.Map并行遍历命名空间后合并结果。按标签过滤DOZZLE_FILTERDOZZLE_FILTER的行为与 Docker 模式下的 filter 类似用于进一步收缩 Dozzle 的监控范围。例如只关注envprod标签的 PodapiVersion: apps/v1 kind: Deployment metadata: name: dozzle spec: selector: matchLabels: app: dozzle template: metadata: labels: app: dozzle spec: serviceAccountName: pod-viewer containers: - name: dozzle image: amir20/dozzle:latest ports: - containerPort: 8080 env: - name: DOZZLE_MODE value: k8s - name: DOZZLE_FILTER value: envprod从源码实现看过滤并非简单地在内存中匹配。ListContainersclient.go会将过滤器拆分为两部分合法的 Kubernetes 标签键通过isValidK8sLabelKey校验符合^A-Za-z0-9?$及前缀规则会被拼接为LabelSelector 下推到 API Server例如envprod变成selectorenvprod传入ListOptions让集群端直接过滤 Pod元数据标签以k8s.开头或namespace、owner.kind、owner.name、owner.key等见isK8sMetadataLabel则作为内存过滤条件在podToContainers生成的容器标签上用matchesContainerLabels逐项比对。这意味着最常见的envprod这类过滤不会把全部 Pod 拉到本地再筛选而是在 API Server 端完成对大集群更友好。源码级原理Dozzzle 在 k8s 模式下如何工作容器标识与属主链Owner Chain在 Kubernetes 中容器与 Docker 容器模型不同。podToContainersclient.go将一个 Pod 的每个 spec 容器转换为一个 Dozzle 容器其 ID 格式为namespace:podName:containerName名称格式为podName/containerName并在标签中注入丰富的元数据Pod 自身的 Labels 被完整拷贝并额外添加namespace、k8s.namespace通过resolveOwnerChain沿ownerReferences向上解析属主链如 Pod → ReplicaSet → Deployment写入owner.kind、owner.name、owner.key以及k8s.owner.0.*、k8s.owner.1.*等带序号前缀的标签属主链解析带有 5 分钟 TTL 缓存ownerCacheTTL、4096 条上限ownerCacheMaxSize与逐出阈值防止 ReplicaSet 频繁更替导致缓存无限增长client.go。这正是前端能按 Deployment、Service、Namespace、Owner 等维度归组展示见 assets/pages 下的deployment、namespace、owner、service等路由页面的数据基础。仓库测试 internal/k8s/client_test.go 验证了这条链路的标签输出例如 Pod → ReplicaSetapi-6f88b977f4→ Deploymentapi时会同时产出owner.kindReplicaSet、k8s.owner.1.kindDeployment等标签。日志读取与实时流式日志通过 Kubernetes 的 Pod logs 子资源获取client.go实时日志ContainerLogs设置Follow: true、TailLines: 500默认回溯最近 500 行、Timestamps: true配合SinceTime从指定时间点开始流式读取历史日志ContainerLogsBetweenDatesFollow: false按起止时间拉取。返回的流经 internal/k8s/log_reader.go 的LogReader包装按行ReadString(\n)读取再由container.NewEventGenerator生成日志事件后推送给前端整体链路见 internal/support/k8s/k8s_service.go。值得注意的是最后一行若无换行符会与 EOF 一并返回而不是被丢弃避免漏掉不完整的日志尾部。集群事件监听ContainerEventsclient.go为每个命名空间启动一个 Pod Watch将ADDED/DELETED/MODIFIED事件映射为 Dozzle 的create/destroy/update容器事件驱动前端列表的实时刷新。这也是 RBAC 中pods需要watch权限的原因。终端与执行k8s 模式支持附加Attach与执行Exec通过remotecommand.NewSPDYExecutor发起 Pod 的attach/exec子资源请求并实现terminalSizeQueue支持终端动态 resizeclient.go配合DOZZLE_ENABLE_SHELL等开关使用。k8s 模式的已知限制以下能力在 Kubernetes 模式下不受支持源码中均有明确标记请勿期待其行为容器操作ActionsContainerActions直接panic(not implemented)client.go镜像更新检查与更新CheckImageUpdate返回not supported状态UpdateContainer返回错误——镜像滚动更新是集群Deployment/StatefulSet 等的职责而非 Dozzle 的internal/support/k8s/k8s_service.go网络统计恒为 0Metrics API 限制见上文。官方文档同时提示Kubernetes 支持属于较新特性相比 Docker 版本可能存在一些局限遇到问题可通过官方讨论区反馈。此外所有环境变量开关认证、过滤、Shell、MCP 等在 k8s 模式下同样生效完整清单见 docs/guide/supported-env-vars.md其中--mode/DOZZLE_MODE默认值为server--filter/DOZZLE_FILTER默认--namespace/DOZZLE_NAMESPACE默认与 Docker 部署保持一致的配置心智模型。常见问题与排障要点现象原因与排查方向界面无任何容器/日志多为 RBAC 缺失确认 ClusterRoleBinding 的 Subject 命名空间与实际部署命名空间一致ServiceAccount 已绑定且pods、pods/log具备get/list/watch权限统计卡片无 CPU/内存数据Metrics API 未就绪执行kubectl top pod验证确认 ClusterRole 中metrics.k8s.io/pods的get/list权限日志列表为空的 Pod检查 Pod 是否处于非 Running 状态、容器是否已退出实时流默认仅回溯最近 500 行TailLines: 500网络收发量为 0预期行为Kubernetes Metrics API 不提供网络指标滚动更新期间云配置/通知规则短暂不可用PVC 为ReadWriteOnce且 Deployment 为Recreate策略所致可按 YAML 注释改用ReadWriteMany存储类 RollingUpdate某个 Pod 不显示但别的正常检查DOZZLE_FILTER是否命中该 Pod 标签元数据标签如env之外以k8s.开头的键走内存过滤需注意大小写完全匹配小结在 Kubernetes 中部署 Dozzle 只需三件事DOZZLE_MODEk8s启动、按上文 YAML 配好 RBAC 与 PVC、确保集群已安装 metrics-server。在此基础上DOZZLE_NAMESPACE控制命名空间范围支持逗号分隔多值、DOZZLE_FILTER控制标签范围合法标签键会下推为 API Server 端 LabelSelector其余环境变量与 Docker 模式完全通用。源码层面Dozzle 通过client-go以 in-cluster 或 kubeconfig 两种方式接入集群将 Pod 容器映射为统一容器模型并沿 OwnerReference 链解析出 Deployment/Service 等归组标签为前端多维度视图、实时日志流、资源统计与终端交互提供了完整的实现支撑。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考