Dozzle Kubernetes 部署指南从 RBAC 授权、Metrics API 到 Namespace 过滤的完整实战【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 是一个针对容器的实时日志查看器原生支持 Docker、Swarm 与 Kubernetes。本文基于项目文档 docs/guide/k8s.md及法语版 docs/fr/guide/k8s.md展开完整讲解如何以DOZZLE_MODEk8s模式将 Dozzle 部署进 Kubernetes 集群并深入结合 internal/k8s 源码剖析 Pod 日志拉取、Metrics 采集、Namespace 与过滤器背后的实现原理。读完本文你将能够独立编写一套带最小 RBAC 权限的 Dozzle 部署清单并学会用环境变量精确控制 Dozzle 的观测范围。Kubernetes 支持概览Dozzzle 对 Kubernetes 的支持思路与 Docker 模式一致把集群中的每个 Pod 容器抽象成容器对象通过 Web 界面实时查看其 stdout/stderr 日志。与 Docker 模式不同K8s 模式不需要挂载 Docker socket而是通过 Kubernetes 官方 Go 客户端k8s.io/client-go访问 API Server因此集群内只需为 Dozzle 分配一个最小权限的 ServiceAccount 即可工作。部署的核心开关只有一个环境变量DOZZLE_MODEk8s。除此之外Docker 模式下可用的环境变量认证、过滤、日志级别等在 Kubernetes 模式中同样适用。完整部署清单RBAC PVC Deployment Service官方文档给出的 YAML 由五段资源组成可直接复制使用ServiceAccount、ClusterRole、ClusterRoleBinding、PersistentVolumeClaim、Deployment、Service。仓库的 examples/k8s.dozzle.yml 提供了同一份清单的变体其中额外设置了replicas: 1、imagePullPolicy: Never和DOZZLE_LEVEL: debug可用于本地调试场景。# 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 策略意味着Pod 滚动更新期间云配置与通知规则会短暂不可用 # 新 Pod 必须等旧 Pod 释放卷之后才能挂载。若需要无中断的配置持久化 # 请改用 ReadWriteMany 存储类NFS、CephFS 等并把下面的更新策略改为 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这份清单做了四件事创建名为pod-viewer的 ServiceAccount创建 ClusterRolepod-viewer-role授予 Dozzle 访问必要 K8s 资源的权限通过 ClusterRoleBinding 把两者绑定最后创建 Deployment 并经由 ClusterIP 类型的 Service 对外暴露。所有资源拆分写入同一文件用---分隔便于kubectl apply一次下发。逐条解析 RBAC 权限ClusterRole 中的规则是 Dozzle K8s 模式能够运行的最小权限集与源码中的调用一一对应资源动词用途pods、pods/log、nodesget / list / watch列出 Pod、读取容器日志、获取节点信息client.go 启动时ListNodes 确定 host 身份deployments、replicasets、daemonsets、statefulsetsget解析 Pod 的 Owner 链如 Deployment→ReplicaSet→Pod用于界面按工作负载聚合日志jobs、cronjobsget解析 batch 类型工作负载的 Owner 链metrics.k8s.io/podsget / list通过 Metrics API 拉取资源使用量见下文Metrics API一节部署与验证步骤# 一次性下发全部资源 kubectl apply -f 上述清单文件 # 确认 Pod 就绪镜像为 amir20/dozzle:latest kubectl get pods -l appdozzle # 端口转发访问 Web 界面 kubectl port-forward svc/dozzle-service 8080:8080访问http://localhost:8080即可在界面中看到集群内各 Pod 的容器列表与实时日志。若需对外暴露可把 Service 的type改为LoadBalancer或NodePort或通过 Ingress 转发到 8080 端口。使用 GitOps 部署时的高危注意事项[!WARNING] 如果使用 GitOps 工具如 Flux CD 或 Argo CD部署且目标 namespace 不是default务必修改ClusterRoleBinding 的 Subject 中的 namespace字段否则 ServiceAccount 与 ClusterRole 的绑定将失效Dozzzle 会因权限不足而无法列出 Pod。同理如果修改了 ServiceAccount 的名字也要同步更新 Subject 中的name字段。配置持久化与存储类选择PVCdozzle-data1Gi挂载到容器的/data目录用于持久化 Dozzle 自身写入的数据包括云配置与通知规则。清单默认采用ReadWriteOnceRecreate策略的组合由于 RWO 卷同一时刻只能被一个节点挂载Pod 滚动更新时新 Pod 必须等旧 Pod 释放卷后才能启动期间云配置与通知规则会短暂不可用。若追求无中断持久化应改用 ReadWriteMany 存储类NFS、CephFS 等并将 Deployment 的strategy.type改为RollingUpdate。从源码看K8s 模式下通知管理由 k8s_cluster_service.go 中的StartNotificationManager初始化配置通过notification.Persister写入notification.DefaultNotificationConfigPath与notification.DefaultCloudConfigPath即/data目录下这也解释了为什么 PVC 的缺失会导致通知与云配置无法持久保存。Metrics API资源使用率的数据来源Dozzzle 依赖 Kubernetes 的 Metrics API 获取 Pod 的 CPU 与内存使用信息。Metrics API 由 metrics-server 提供可通过 kubectl 应用其官方最新发布清单安装kubectl apply -f metrics-server 官方最新发布中的 components.yaml安装完成后用下面的命令验证 API 是否可用kubectl top pod如果该命令能正常返回各 Pod 的 CPU/内存占用说明 Metrics API 工作正常。当前版本中Metrics API 是 Dozzle 在 Kubernetes 模式下运行的必要依赖缺少它会导致资源使用量无法展示。源码视角每秒一次的轮询指标采集的实现位于 stats_collector.go核心是一个K8sStatsCollector通过metricsclient.NewForConfig创建访问metrics.k8s.io的客户端对应 RBAC 中metrics.k8s.io组的授权Start方法中以 1 秒为周期Ticker轮询对配置的每个 namespace 执行PodMetricses(...).List(...)每条 Pod 指标被转换为统一的container.ContainerStat其中CPUPercent由Usage.Cpu().MilliValue() / 1000 * 100计算MemoryUsage取自内存用量网络收发字节数NetworkRxTotal/NetworkTxTotal被固定为 0——K8s Metrics API 默认不暴露网络统计注释中明确说明需要自定义指标或 cAdvisor 集成才能补齐。此外收集器带有一段空闲自动停止逻辑timeToStop 2 * time.Hour当所有订阅者退出且持续无新订阅者时收集器会自动停止轮询以节省 API Server 压力有新订阅时再重新启动Start返回false表示已在运行。Namespace控制观测范围默认情况下Dozzzle 会监控集群中的全部 namespace。如果只想让它观测特定 namespace设置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把DOZZLE_NAMESPACE设置为逗号分隔的列表即可例如value: default,production。当指定多个 namespace 时Dozzzle 会对每个 namespace 分别监控并合并结果。源码视角namespace 列表与并行拉取DOZZLE_NAMESPACE在 args.go 中被解析为[]string逗号分隔自动拆分条目还会去除首尾空白。在 client.go 的NewK8sClient中如果列表为空则默认使用metav1.NamespaceAll即全部 namespace。后续无论是列出容器ListContainers还是监听事件ContainerEvents都会针对列表中的每个 namespace 并行发起请求并聚合结果——这正是分别监控、合并结果的源码实现。另外值得注意的是 client.go 的客户端初始化逻辑当检测到环境变量KUBERNETES_SERVICE_HOST非空时自动使用rest.InClusterConfig()集群内模式否则回退读取KUBECONFIG环境变量或~/.kube/config本地开发模式可以直接在集群外连远程 K8s 集群调试。Labels 与过滤器缩小展示范围DOZZLE_FILTER的行为与 Docker 模式下的过滤器一致。通过该环境变量可以进一步缩小 Dozzle 的观测范围例如只展示打了envprod标签的容器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_FILTER value: envprodDOZZLE_FILTER支持多个条件在 args.go 中它以separate模式解析即逗号分隔的多个keyvalue会被拆进同一个 mapmap[string][]string同一 key 可以出现多次。用户侧配置的过滤器最终还会与认证系统提供的过滤器合并后下发。源码视角Pod 标签与元数据标签的分流在 K8s 模式中一个容器其实对应namespace:pod:container三元组client.go 中容器 ID 的生成方式。podToContainers构建标签时除了 Pod 自身的 Labels还会附加一组k8s.前缀的元数据标签namespace与k8s.namespacePod 所属 namespaceowner.kind、owner.name、owner.key最近一级工作负载 Owner 的信息向后兼容k8s.owner.N.*整条 Owner 链如 Deployment→ReplicaSet→Pod的 apiVersion、kind、name、uid 等k8s.owner.key.base64用于按 Owner 聚合成员。ListContainers通过 splitK8sFilters 把过滤器一分为二普通 Pod 标签会被转换为 Kubernetes 官方LabelSelectorkeyvalue逗号连接直接下推到 API Server 的List请求实现服务端过滤而k8s.前缀、namespace、owner.*这类元数据标签由于不是 Pod 原生标签无法通过 LabelSelector 表达因此在客户端对每个容器的标签做匹配过滤matchesContainerLabels。这也解释了为什么DOZZLE_FILTERenvprod这类 Pod 标签过滤效率最高——它在 API Server 侧就完成了。与其他模式一致的配置项正如文档强调的K8s 模式下 Dozzle 的全部功能依然可用包括认证、过滤等且可以复用 Docker 模式下相同的环境变量。常用配置项速查完整清单见 docs/guide/supported-env-vars.md环境变量默认值说明DOZZLE_MODEserver设为k8s启用 Kubernetes 模式DOZZLE_NAMESPACE空全部 namespace限定监控的 namespace支持逗号分隔多值DOZZLE_FILTER空按标签过滤容器语法为keyvalue支持多个DOZZLE_ADDR:8080服务监听地址对应清单中的 containerPort 8080DOZZLE_LEVELinfo日志级别调试可设为debugexamples/k8s.dozzle.yml 中即如此DOZZLE_AUTH_PROVIDERnone认证方式可选 simple / oidc / forward-proxyDOZZLE_TIMEOUT10s客户端超时K8s 模式下 Web 界面同样提供按 NamespaceNamespaceLog.vue、按工作负载 OwnerOwnerLog.vue等维度聚合查看日志的视图路由对应pages/namespace、pages/owner等页面并支持终端attach/exec等交互能力。日志与事件的底层实现最后从源码层面对齐日志链路便于排查问题日志流ContainerLogs调用Pods(namespace).GetLogs(...)设置Followtrue、Timestampstrue、TailLines500与SinceTime返回io.ReadCloser交给 log_reader.go 按行读取后进入事件生成器历史日志ContainerLogsBetweenDates设置Followfalse用SinceTime定位起始时间用于时间范围查询实时事件ContainerEvents对每个 namespace 建立 Pod 的Watch把ADDED/MODIFIED/DELETED映射为create/update/destroy事件推送给前端实现容器列表的动态增删改Owner 链解析resolveOwnerChain沿 Controller 引用向上追溯配合带 TTL5 分钟与容量上限4096 条的缓存既避免频繁请求 API Server也能在 RBAC 补授权后自动恢复解析。已知限制文档明确指出Dozzle 的 Kubernetes 支持属于较新功能相对 Docker 版本可能存在一些限制。结合源码可以确认的具体差异包括网络收发统计暂时不可用K8s Metrics API 不暴露容器操作类动作ContainerActions尚未实现Metrics API 为当前运行的必要依赖。遇到问题或希望提出改进建议时可通过项目社区讨论反馈原文档附有讨论链接读者可在 docs/guide/k8s.md 中查看。总体而言Dozzzle 的 K8s 模式做到了一份最小 RBAC 清单 一个环境变量即可把实时日志与资源监控能力带进集群配合 Namespace 与过滤器可以精确圈定观测边界适合作为集群内轻量级日志查看工具。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dozzle Kubernetes 部署指南：从 RBAC 授权、Metrics API 到 Namespace 过滤的完整实战
Dozzle Kubernetes 部署指南从 RBAC 授权、Metrics API 到 Namespace 过滤的完整实战【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzleDozzle 是一个针对容器的实时日志查看器原生支持 Docker、Swarm 与 Kubernetes。本文基于项目文档 docs/guide/k8s.md及法语版 docs/fr/guide/k8s.md展开完整讲解如何以DOZZLE_MODEk8s模式将 Dozzle 部署进 Kubernetes 集群并深入结合 internal/k8s 源码剖析 Pod 日志拉取、Metrics 采集、Namespace 与过滤器背后的实现原理。读完本文你将能够独立编写一套带最小 RBAC 权限的 Dozzle 部署清单并学会用环境变量精确控制 Dozzle 的观测范围。Kubernetes 支持概览Dozzzle 对 Kubernetes 的支持思路与 Docker 模式一致把集群中的每个 Pod 容器抽象成容器对象通过 Web 界面实时查看其 stdout/stderr 日志。与 Docker 模式不同K8s 模式不需要挂载 Docker socket而是通过 Kubernetes 官方 Go 客户端k8s.io/client-go访问 API Server因此集群内只需为 Dozzle 分配一个最小权限的 ServiceAccount 即可工作。部署的核心开关只有一个环境变量DOZZLE_MODEk8s。除此之外Docker 模式下可用的环境变量认证、过滤、日志级别等在 Kubernetes 模式中同样适用。完整部署清单RBAC PVC Deployment Service官方文档给出的 YAML 由五段资源组成可直接复制使用ServiceAccount、ClusterRole、ClusterRoleBinding、PersistentVolumeClaim、Deployment、Service。仓库的 examples/k8s.dozzle.yml 提供了同一份清单的变体其中额外设置了replicas: 1、imagePullPolicy: Never和DOZZLE_LEVEL: debug可用于本地调试场景。# 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 策略意味着Pod 滚动更新期间云配置与通知规则会短暂不可用 # 新 Pod 必须等旧 Pod 释放卷之后才能挂载。若需要无中断的配置持久化 # 请改用 ReadWriteMany 存储类NFS、CephFS 等并把下面的更新策略改为 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这份清单做了四件事创建名为pod-viewer的 ServiceAccount创建 ClusterRolepod-viewer-role授予 Dozzle 访问必要 K8s 资源的权限通过 ClusterRoleBinding 把两者绑定最后创建 Deployment 并经由 ClusterIP 类型的 Service 对外暴露。所有资源拆分写入同一文件用---分隔便于kubectl apply一次下发。逐条解析 RBAC 权限ClusterRole 中的规则是 Dozzle K8s 模式能够运行的最小权限集与源码中的调用一一对应资源动词用途pods、pods/log、nodesget / list / watch列出 Pod、读取容器日志、获取节点信息client.go 启动时ListNodes 确定 host 身份deployments、replicasets、daemonsets、statefulsetsget解析 Pod 的 Owner 链如 Deployment→ReplicaSet→Pod用于界面按工作负载聚合日志jobs、cronjobsget解析 batch 类型工作负载的 Owner 链metrics.k8s.io/podsget / list通过 Metrics API 拉取资源使用量见下文Metrics API一节部署与验证步骤# 一次性下发全部资源 kubectl apply -f 上述清单文件 # 确认 Pod 就绪镜像为 amir20/dozzle:latest kubectl get pods -l appdozzle # 端口转发访问 Web 界面 kubectl port-forward svc/dozzle-service 8080:8080访问http://localhost:8080即可在界面中看到集群内各 Pod 的容器列表与实时日志。若需对外暴露可把 Service 的type改为LoadBalancer或NodePort或通过 Ingress 转发到 8080 端口。使用 GitOps 部署时的高危注意事项[!WARNING] 如果使用 GitOps 工具如 Flux CD 或 Argo CD部署且目标 namespace 不是default务必修改ClusterRoleBinding 的 Subject 中的 namespace字段否则 ServiceAccount 与 ClusterRole 的绑定将失效Dozzzle 会因权限不足而无法列出 Pod。同理如果修改了 ServiceAccount 的名字也要同步更新 Subject 中的name字段。配置持久化与存储类选择PVCdozzle-data1Gi挂载到容器的/data目录用于持久化 Dozzle 自身写入的数据包括云配置与通知规则。清单默认采用ReadWriteOnceRecreate策略的组合由于 RWO 卷同一时刻只能被一个节点挂载Pod 滚动更新时新 Pod 必须等旧 Pod 释放卷后才能启动期间云配置与通知规则会短暂不可用。若追求无中断持久化应改用 ReadWriteMany 存储类NFS、CephFS 等并将 Deployment 的strategy.type改为RollingUpdate。从源码看K8s 模式下通知管理由 k8s_cluster_service.go 中的StartNotificationManager初始化配置通过notification.Persister写入notification.DefaultNotificationConfigPath与notification.DefaultCloudConfigPath即/data目录下这也解释了为什么 PVC 的缺失会导致通知与云配置无法持久保存。Metrics API资源使用率的数据来源Dozzzle 依赖 Kubernetes 的 Metrics API 获取 Pod 的 CPU 与内存使用信息。Metrics API 由 metrics-server 提供可通过 kubectl 应用其官方最新发布清单安装kubectl apply -f metrics-server 官方最新发布中的 components.yaml安装完成后用下面的命令验证 API 是否可用kubectl top pod如果该命令能正常返回各 Pod 的 CPU/内存占用说明 Metrics API 工作正常。当前版本中Metrics API 是 Dozzle 在 Kubernetes 模式下运行的必要依赖缺少它会导致资源使用量无法展示。源码视角每秒一次的轮询指标采集的实现位于 stats_collector.go核心是一个K8sStatsCollector通过metricsclient.NewForConfig创建访问metrics.k8s.io的客户端对应 RBAC 中metrics.k8s.io组的授权Start方法中以 1 秒为周期Ticker轮询对配置的每个 namespace 执行PodMetricses(...).List(...)每条 Pod 指标被转换为统一的container.ContainerStat其中CPUPercent由Usage.Cpu().MilliValue() / 1000 * 100计算MemoryUsage取自内存用量网络收发字节数NetworkRxTotal/NetworkTxTotal被固定为 0——K8s Metrics API 默认不暴露网络统计注释中明确说明需要自定义指标或 cAdvisor 集成才能补齐。此外收集器带有一段空闲自动停止逻辑timeToStop 2 * time.Hour当所有订阅者退出且持续无新订阅者时收集器会自动停止轮询以节省 API Server 压力有新订阅时再重新启动Start返回false表示已在运行。Namespace控制观测范围默认情况下Dozzzle 会监控集群中的全部 namespace。如果只想让它观测特定 namespace设置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把DOZZLE_NAMESPACE设置为逗号分隔的列表即可例如value: default,production。当指定多个 namespace 时Dozzzle 会对每个 namespace 分别监控并合并结果。源码视角namespace 列表与并行拉取DOZZLE_NAMESPACE在 args.go 中被解析为[]string逗号分隔自动拆分条目还会去除首尾空白。在 client.go 的NewK8sClient中如果列表为空则默认使用metav1.NamespaceAll即全部 namespace。后续无论是列出容器ListContainers还是监听事件ContainerEvents都会针对列表中的每个 namespace 并行发起请求并聚合结果——这正是分别监控、合并结果的源码实现。另外值得注意的是 client.go 的客户端初始化逻辑当检测到环境变量KUBERNETES_SERVICE_HOST非空时自动使用rest.InClusterConfig()集群内模式否则回退读取KUBECONFIG环境变量或~/.kube/config本地开发模式可以直接在集群外连远程 K8s 集群调试。Labels 与过滤器缩小展示范围DOZZLE_FILTER的行为与 Docker 模式下的过滤器一致。通过该环境变量可以进一步缩小 Dozzle 的观测范围例如只展示打了envprod标签的容器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_FILTER value: envprodDOZZLE_FILTER支持多个条件在 args.go 中它以separate模式解析即逗号分隔的多个keyvalue会被拆进同一个 mapmap[string][]string同一 key 可以出现多次。用户侧配置的过滤器最终还会与认证系统提供的过滤器合并后下发。源码视角Pod 标签与元数据标签的分流在 K8s 模式中一个容器其实对应namespace:pod:container三元组client.go 中容器 ID 的生成方式。podToContainers构建标签时除了 Pod 自身的 Labels还会附加一组k8s.前缀的元数据标签namespace与k8s.namespacePod 所属 namespaceowner.kind、owner.name、owner.key最近一级工作负载 Owner 的信息向后兼容k8s.owner.N.*整条 Owner 链如 Deployment→ReplicaSet→Pod的 apiVersion、kind、name、uid 等k8s.owner.key.base64用于按 Owner 聚合成员。ListContainers通过 splitK8sFilters 把过滤器一分为二普通 Pod 标签会被转换为 Kubernetes 官方LabelSelectorkeyvalue逗号连接直接下推到 API Server 的List请求实现服务端过滤而k8s.前缀、namespace、owner.*这类元数据标签由于不是 Pod 原生标签无法通过 LabelSelector 表达因此在客户端对每个容器的标签做匹配过滤matchesContainerLabels。这也解释了为什么DOZZLE_FILTERenvprod这类 Pod 标签过滤效率最高——它在 API Server 侧就完成了。与其他模式一致的配置项正如文档强调的K8s 模式下 Dozzle 的全部功能依然可用包括认证、过滤等且可以复用 Docker 模式下相同的环境变量。常用配置项速查完整清单见 docs/guide/supported-env-vars.md环境变量默认值说明DOZZLE_MODEserver设为k8s启用 Kubernetes 模式DOZZLE_NAMESPACE空全部 namespace限定监控的 namespace支持逗号分隔多值DOZZLE_FILTER空按标签过滤容器语法为keyvalue支持多个DOZZLE_ADDR:8080服务监听地址对应清单中的 containerPort 8080DOZZLE_LEVELinfo日志级别调试可设为debugexamples/k8s.dozzle.yml 中即如此DOZZLE_AUTH_PROVIDERnone认证方式可选 simple / oidc / forward-proxyDOZZLE_TIMEOUT10s客户端超时K8s 模式下 Web 界面同样提供按 NamespaceNamespaceLog.vue、按工作负载 OwnerOwnerLog.vue等维度聚合查看日志的视图路由对应pages/namespace、pages/owner等页面并支持终端attach/exec等交互能力。日志与事件的底层实现最后从源码层面对齐日志链路便于排查问题日志流ContainerLogs调用Pods(namespace).GetLogs(...)设置Followtrue、Timestampstrue、TailLines500与SinceTime返回io.ReadCloser交给 log_reader.go 按行读取后进入事件生成器历史日志ContainerLogsBetweenDates设置Followfalse用SinceTime定位起始时间用于时间范围查询实时事件ContainerEvents对每个 namespace 建立 Pod 的Watch把ADDED/MODIFIED/DELETED映射为create/update/destroy事件推送给前端实现容器列表的动态增删改Owner 链解析resolveOwnerChain沿 Controller 引用向上追溯配合带 TTL5 分钟与容量上限4096 条的缓存既避免频繁请求 API Server也能在 RBAC 补授权后自动恢复解析。已知限制文档明确指出Dozzle 的 Kubernetes 支持属于较新功能相对 Docker 版本可能存在一些限制。结合源码可以确认的具体差异包括网络收发统计暂时不可用K8s Metrics API 不暴露容器操作类动作ContainerActions尚未实现Metrics API 为当前运行的必要依赖。遇到问题或希望提出改进建议时可通过项目社区讨论反馈原文档附有讨论链接读者可在 docs/guide/k8s.md 中查看。总体而言Dozzzle 的 K8s 模式做到了一份最小 RBAC 清单 一个环境变量即可把实时日志与资源监控能力带进集群配合 Namespace 与过滤器可以精确圈定观测边界适合作为集群内轻量级日志查看工具。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考