Kubeshark 配置参数详解

目标：系统梳理 Kubeshark v53.6.0 的配置体系——配置的查看（kubeshark config）、落盘（config -r）、修改（CLI --set、Helm values、运行时 API）三条通道，并对 tap.docker/proxy/capture/storage/resources/securityContext/auth/telemetry 等全部核心参数逐项给出含义与实测默认值，附两套生产配置模板。已在 Ubuntu 22.04 + k3s v1.34.1+k3s1 集群实测通过（2026-10-23，参数默认值全部取自本机 kubeshark config 实际输出）。

一、环境信息

• 操作系统：Ubuntu 22.04 LTS（内核 6.8.0-138-generic，x86_64）
• Kubernetes：k3s v1.34.1+k3s1 单节点（部署篇同款环境）
• Kubeshark：v53.6.0（CLI 二进制 + Helm Chart 53.6.0）
• Helm：v3.17.3
• 配置默认值取证方式：kubeshark config（v53.6.0 内置默认值导出，实测输出 333 行，全文按分组摘录见第五章）
• 实测日期：2026-10-23

二、前置条件

1. 已完成 Kubeshark 部署（CLI 或 Helm 任一路径，见《Kubeshark Kubernetes 部署指南》）；
2. kubeshark CLI 可执行（kubeshark version 返回 v53.6.0）；
3. kubeconfig 已配置（kubectl get nodes 正常返回）；
4. 理解 Kubeshark 配置的作用域：CLI 的 --set/config.yaml 控制 kubeshark tap 行为并下沉为 Helm values；Helm 的 values 是部署的最终事实源；运行时 API 只改捕获开关类参数且不落盘。

三、参数查看与修改方式

3.1 查看默认配置：kubeshark config

kubeshark config 将 v53.6.0 的完整默认配置打印到标准输出（实测，输出共 333 行，以下为实测首部节选）：

kubeshark config

tap:
  docker:
    registry: docker.io/kubeshark
    tag: ""
    tagLocked: true
    imagePullPolicy: Always
    imagePullSecrets: []
    overrideImage:
      worker: ""
      hub: ""
      front: ""
  proxy:
    worker:
      srvPort: 48999
    hub:
      srvPort: 8898
    front:
      port: 8899
    host: 127.0.0.1
  regex: .*
  namespaces: []
  excludedNamespaces: []
...(共 333 行，全文分组解析见第五章)

💡 说明：该命令执行时还会顺带做一次新版本检查（Checking for a newer version...），离线环境此行后可能跟一条 Failed to get the latest release. 错误（实测出现过），不影响配置输出。

3.2 配置文件落盘与路径：config -r 与 --config-path

kubeshark config -r 把默认配置写入本地配置文件（实测）：

kubeshark config -r
echo $?

0

落盘位置即全局旗标 --config-path 的默认值，实测两种形态（取决于 HOME 是否设置）：

落盘验证（实测回显）：

ls -la /root/.kubeshark/config.yaml && wc -l /root/.kubeshark/config.yaml

-rw-r--r-- 1 root root 5965 Oct 23 07:02 /root/.kubeshark/config.yaml
333 /root/.kubeshark/config.yaml

修改配置文件后，kubeshark tap / kubeshark proxy 等命令下次执行时读取；也可用 --config-path /path/to/config.yaml 显式指定。-r（regenerate）会把已有文件重置为默认值，定制内容注意先备份。

3.3 修改方式一：CLI --set（tap 流程）

--set 是所有 kubeshark 子命令共用的全局旗标（kubeshark --help 实测：--set strings Override values using --set），支持重复传参逐项覆盖。对已有安装执行 tap --set 时，CLI 会跳过重复安装、仅下发配置变更（实测回显节选）：

kubeshark tap --set tap.capture.dissection.stopAfter=24h

2026-10-23T07:22:01Z INF tapRunner.go:94 > Found an existing installation, skipping Helm install...
2026-10-23T07:22:01Z INF config.go:97 > Updated. Printing only 10 first characters of value: config=SCRIPTING_ENV length=2 value={}
2026-10-23T07:22:02Z INF config.go:97 > Updated. Printing only 10 first characters of value: config=INGRESS_ENABLED length=0 value=

⚠️ 注意（实测踩坑）：对已存在的安装，tap --set 只更新部分运行时配置（ConfigMap），并不会重新执行 helm upgrade（日志明示 skipping Helm install）。需要把 values 真正改到部署层的参数（如资源限制、镜像 tag），请走 3.4 节的 Helm 通道。

3.4 修改方式二：Helm values / --set（部署事实源）

Helm 通道是生产推荐：helm upgrade 全量生效且可回滚。实测用 --set 把 Hub 内存上限从默认 5Gi 调整为 2Gi，并用 K8s API 复核下发成功：

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
helm upgrade kubeshark kubeshark/kubeshark --namespace default \
  --reuse-values --set tap.resources.hub.limits.memory=2Gi --wait --timeout 240s

kubectl get deploy kubeshark-hub -o jsonpath="{.spec.template.spec.containers[0].resources}"

{"limits":{"memory":"2Gi"},"requests":{"cpu":"50m","memory":"50Mi"}}

当前生效的 values 可用 helm get values kubeshark -n default 查看（实测输出为自定义项与默认项合并后的 map）。--reuse-values 表示在既有 values 基础上叠加，不加则会重置为 Chart 默认值——生产变更务必带上。

下发给容器的最终生效参数还可在进程命令行复核（实测 Hub 进程参数，-capture-stop-after 24h 即 tap.capture.dissection.stopAfter=24h 的下发结果）：

ps -ef | grep "[h]ub -port"

... ./hub -port 8080 -loglevel warning -capture-stop-after 24h -snapshot-size-limit 20Gi -dissector-image docker.io/kubeshark/worker:v53.6 -dissector-cpu 1 -dissector-memory 4Gi -dissector-storage-size 20Gi -cloud-api-url https://api.kubeshark.com

Worker 进程参数（实测，捕获与存储相关默认值一目了然）：

... ./worker -i any -port 48999 -metrics-port 49100 -packet-capture best -loglevel warning -servicemesh -procfs /hostproc -resolution-strategy auto -staletimeout 30 -tcp-flow-full-timeout 1200 -udp-flow-full-timeout 1200 -storage-size 10Gi -capture-db-max-size 500Mi -cloud-api-url https://api.kubeshark.com

3.5 修改方式三：运行时 API（不落盘）

捕获开关类参数可在运行中直接切换，无需重装：官方 MCP 工具 enable_dissection / disable_dissection（经 kubeshark mcp --url http://127.0.0.1:8899 调用，实测返回 {"success":true,"enabled":true}）。此类变更即时生效但不写入 values，组件重启后回到部署时状态。

四、参数总览

配置顶层共 5 组（kubeshark config 实测结构）：tap（核心捕获与部署）、logs、pcapdump、kube、scripting，以及 license/headless/timezone/logLevel 等全局散项。核心分组速查：

五、核心参数分类详解

以下每项默认值均取自 3.1 节的 333 行实测输出；「实测验证」列为本次环境中的实证方式。

5.1 镜像与拉取（tap.docker.*）

tap:
  docker:
    registry: docker.io/kubeshark
    tag: ""
    tagLocked: true
    imagePullPolicy: Always
    imagePullSecrets: []
    overrideImage:
      worker: ""
      hub: ""
      front: ""

逐项说明：

• registry：镜像仓库地址，默认 docker.io/kubeshark。离线/内网环境改为自建仓库（如 registry.example.com/kubeshark），对应 CLI 旗标 -r, --docker-registry；
• tag：镜像 tag，默认空=跟随 Chart 版本（helm install 实测输出 Tag: v53.6.0），CLI 旗标 -t, --docker-tag；tagLocked: true 表示锁版，防止误改 tag 造成版本漂移；
• imagePullPolicy：默认 Always（每次调度都检查远端），内网固定版本环境可改 IfNotPresent 减少仓库压力；
• imagePullSecrets：私有仓库凭据 Secret 名数组；
• overrideImage/overrideTag：按角色（worker/hub/front）单独覆盖镜像名或 tag，用于灰度或替换个别组件。

5.2 端口与代理（tap.proxy.*）

  proxy:
    worker:
      srvPort: 48999
    hub:
      srvPort: 8898
    front:
      port: 8899
    host: 127.0.0.1

• front.port：Web UI 的本地转发端口，默认 8899，对应 CLI 旗标 --proxy-front-port（worker DaemonSet Pod 实测监听与 Service 均以 80 承载，由 port-forward 映射到本机 8899）；
• hub.srvPort：Hub 服务端口 8898；worker.srvPort：Worker 服务端口 48999（Hub 拉取 Worker 数据用，Worker 进程实测参数 -port 48999 印证）；
• host：转发绑定地址，默认 127.0.0.1（只允许本机访问 Web UI；远程访问用 SSH 隧道，不建议直接改 0.0.0.0 裸奔——除非已启用 tap.auth）。

5.3 捕获范围（tap.regex / namespaces / excludedNamespaces）

  regex: .*
  namespaces: []
  excludedNamespaces: []
  bpfOverride: ""
  captureSelf: false

• regex：目标 Pod 名正则，默认 .* 捕获全部 Pod（tap 日志实测对每个 Pod 打印 Targeted pod: ...）。生产建议收窄（如 ^payment-），减少捕获面与资源占用；
• namespaces：限定命名空间列表，空=全部（tap 实测自动枚举 default/kube-node-lease/kube-public/kube-system 四个）；excludedNamespaces：反向排除，CLI 旗标 -e, --excludedNamespaces；
• bpfOverride：自定义 BPF 过滤表达式（tcpdump 语法），叠加在 Pod 选择之上；
• captureSelf：是否捕获 Kubeshark 自身组件流量，默认 false。

5.4 捕获与存储（tap.capture.* / storageLimit / snapshots）

  capture:
    dissection:
      enabled: true
      stopAfter: 5m
    captureSelf: false
    raw:
      enabled: true
      storageSize: 1Gi
    dbMaxSize: 500Mi
  storageLimit: 10Gi
  storageClass: standard
  snapshots:
    local:
      storageClass: ""
      storageSize: 20Gi

• capture.dissection.enabled：L7 协议解析开关，默认 true；
• capture.dissection.stopAfter：解析自动停止窗口，默认 5m——启动后 5 分钟自动停止 L7 解析（实测复现：5 分钟后经 MCP 查询返回 L7 protocol dissection is disabled — no API calls are being captured）。无人值守采集必须延长（实测 --set tap.capture.dissection.stopAfter=24h 后 Hub 进程参数出现 -capture-stop-after 24h，且 MCP enable_dissection 后不再自动停止）；
• capture.raw.enabled / storageSize：原始 PCAP 捕获开关与单节点环形缓冲，默认开/1Gi（快照与 pcapdump 依赖此项）；
• capture.dbMaxSize：捕获数据库单节点上限，默认 500Mi（Worker 进程实测 -capture-db-max-size 500Mi），超限后按 LRU 淘汰旧 TCP/UDP 流；
• storageLimit：每节点存储软上限 10Gi（tap 日志实测原文：Kubeshark will store the traffic up to a limit (per node). Oldest TCP/UDP streams will be removed once the limit is reached. limit=10Gi）；
• storageClass：PVC 存储类，默认 standard（k3s 内置 local-path 即此名）；需持久化的集群按实际存储类改名；
• snapshots.local.storageSize：本地快照池 20Gi（Hub 进程实测 -snapshot-size-limit 20Gi）；云端快照（s3/azblob/gcs）默认全部留空不启用，v53.6.0 起 S3 支持私有 CA 跳过校验（s3.insecureSkipVerify）。

5.5 协议解析（enabledDissectors / portMapping / delayedDissection）

  enabledDissectors:
  - amqp
  - dns
  - http
  - icmp
  - kafka
  - mongodb
  - mysql
  - postgresql
  - redis
  - ws
  - tlsx
  - ldap
  - radius
  - diameter
  - udp-flow
  - tcp-flow
  - udp-conn
  - tcp-conn
  portMapping:
    http: [80, 443, 8080]
    amqp: [5671, 5672]
    kafka: [9092]
    mongodb: [27017]
    mysql: [3306]
    postgresql: [5432]
    redis: [6379]
    ldap: [389]
    diameter: [3868]
  delayedDissection:
    cpu: "1"
    memory: 4Gi
    storageSize: ""
    storageClass: ""

• enabledDissectors：启用的解析器清单，默认 18 项（15 个协议 + 流/连接 4 视图）。不需要的协议从这里删除即可关闭解析，减少 CPU；
• portMapping：协议到端口的映射，是「按端口识别协议」的依据。业务用了非标端口（如 HTTP 跑在 9090）时必须在此追加，否则只能看到 TCP 流看不到 HTTP 事务；
• delayedDissection：延时解析作业（对历史捕获补解析）的资源规格，默认单核/4Gi；资源紧张的集群可下调（实测 Hub 进程参数 -dissector-cpu 1 -dissector-memory 4Gi）。

5.6 资源限制与健康探针（tap.resources / probes）

  resources:
    hub:
      limits: {cpu: "0", memory: 5Gi}
      requests: {cpu: 50m, memory: 50Mi}
    sniffer:
      limits: {cpu: "0", memory: 5Gi}
      requests: {cpu: 50m, memory: 50Mi}
    tracer:
      limits: {cpu: "0", memory: 5Gi}
      requests: {cpu: 50m, memory: 50Mi}
  probes:
    hub: {initialDelaySeconds: 5, periodSeconds: 5, successThreshold: 1, failureThreshold: 3}
    sniffer: {initialDelaySeconds: 5, periodSeconds: 5, successThreshold: 1, failureThreshold: 3}

• 三个角色（hub/sniffer/tracer）默认 requests 仅 50m/50Mi（对集群调度极友好），limits 内存 5Gi、CPU 不限（cpu: "0" 表示不限制）。高流量节点上内存 limits 是防 Pod OOM 的关键闸门；
• 实测变更方法：helm upgrade ... --set tap.resources.hub.limits.memory=2Gi 后 kubectl get deploy kubeshark-hub -o jsonpath 复核 limits 已变 2Gi（见 3.4 节实测回显）；
• probes：就绪/存活探针节奏，默认 5 秒首延迟、5 秒周期、3 次失败判定，一般无需调整。

5.7 安全上下文与特权挂载（securityContext / mountBpf / hostNetwork）

  securityContext:
    privileged: true
    appArmorProfile: {type: "", localhostProfile: ""}
    seLinuxOptions: {level: "", role: "", type: "", user: ""}
    capabilities:
      networkCapture: [NET_RAW, NET_ADMIN]
      serviceMeshCapture: [SYS_ADMIN, SYS_PTRACE, DAC_OVERRIDE]
      ebpfCapture: [SYS_ADMIN, SYS_PTRACE, SYS_RESOURCE, IPC_LOCK]
  mountBpf: true
  hostNetwork: true

• privileged: true：Worker 默认以特权运行，这是 AF_PACKET 抓包与 eBPF 追踪的前提；安全敏感集群可改 false 并按 capabilities 三张表最小化授权（networkCapture/ebpfCapture/serviceMeshCapture 分别对应三种捕获能力所需 capability）；
• mountBpf：挂载 bpffs（Worker 初始化容器 mount-bpf 实测存在），eBPF 追踪需要；
• hostNetwork：Worker 使用宿主网络栈（AF_PACKET 抓节点流量所需）。

⚠️ 注意：Worker 挂载宿主 /sys 相关路径，在「K8s 集群节点本身是容器」的嵌套环境（k3s-in-docker/kind/k3d）中会遇到 /sys ... not a shared mount 与 neither debugfs nor tracefs are mounted 两类报错，修复方法见《Kubeshark Kubernetes 部署指南》 4.6 节排障实录四（本环境实测修复后 Worker 2/2 Running）。

5.8 TLS 与抓包模式（tls / serviceMesh / packetCapture / disableTlsLog）

  serviceMesh: true
  tls: true
  disableTlsLog: true
  packetCapture: best

• tls：启用 eBPF 追踪器 hook OpenSSL/Go crypto/tls 实现免证书解密；设 false 则不部署 Tracer（官方文档明确：Tracer 由 tap.tls 控制启停）；
• serviceMesh：默认 true，配合 Istio/Linkerd 等 mTLS 场景解析加密流量；
• packetCapture: best：抓包模式自动选优（Worker 进程实测参数 -packet-capture best），即优先 eBPF 能力、不足时回落 AF_PACKET；
• disableTlsLog: true：不在日志中输出 TLS 明文内容（默认安全，排障时可临时打开）。

5.9 认证与授权（tap.auth.*）

  auth:
    enabled: false
    type: saml
    rolesClaim: groups
    defaultRole: kubeshark-admin
    groupMapping: {}
    roles: {}
    cli:
      enabled: false
      subjects: []
    saml: {idpMetadataUrl: "", x509crt: "", x509key: ""}

• enabled: false：默认免认证（helm install 实测 Notices 原文：API AUTHENTICATION IS DISABLED ... every one of them gets the role kubeshark-admin）；
• defaultRole：免认证时的兜底角色，最小权限做法是改为 kubeshark-viewer（官方同款建议）；正式接入 IdP 时设 enabled: true 并选 type: saml|oidc，rolesClaim/groupMapping 完成组→角色映射；
• cli.enabled/subjects：为 CLI 主体（如 kubeshark-cli ServiceAccount）开白名单。

5.10 入口与路由（tap.ingress / routing / networkPolicies）

  ingress:
    enabled: false
    className: ""
    host: ks.svc.cluster.local
    path: /
    tls: []
    annotations: {}
  routing:
    front:
      basePath: ""
  networkPolicies:
    enabled: false

• ingress.enabled：默认关（用 port-forward 访问）。多用户共享访问时开启并配 className/host，tls 数组配证书 Secret；
• routing.front.basePath：反代子路径场景（如 https://ops.example.com/kubeshark/）设置；
• networkPolicies.enabled：为 Kubeshark 组件自动生成 NetworkPolicy（本次实测安装了 4 条 NP 资源但默认 disabled 状态）。

5.11 遥测与自观测（telemetry / sentry / metrics / pprof / watchdog / resourceGuard）

  telemetry: {enabled: true}
  sentry: {enabled: false, environment: production}
  metrics:
    port: 49100
    serviceMonitor: {enabled: false, ...}
  pprof: {enabled: false, port: 8000, view: flamegraph}
  resourceGuard: {enabled: false}
  watchdog: {enabled: false}

• telemetry.enabled：使用统计上报，默认 true；关闭用 CLI 旗标 --telemetry-enabled=false（tap 日志实测原文给出此提示）。注意与许可联动：Community/Pro 许可要求 telemetry 可达，关闭或网络不通会导致许可失效；
• sentry.enabled：Sentry 错误上报，默认 false；
• metrics.port：Prometheus 指标端口 49100（Worker 进程实测 -metrics-port 49100）；serviceMonitor.enabled 开启后自动创建 Prometheus Operator 的 ServiceMonitor；
• pprof：Go 性能剖析入口，默认关（CLI 侧配套 kubeshark pprof 子命令，默认端口 8000、flamegraph 视图）；
• resourceGuard/watchdog：资源守护与看门狗，默认均关，高流量生产环境可评估开启。

5.12 界面与流行为（dashboard / misc / ipv6）

  dashboard:
    streamingType: connect-rpc
    completeStreamingEnabled: true
    entriesLimit: "300000"
  ipv6: true
  misc:
    jsonTTL: 5m
    pcapTTL: "0"
    pcapErrorTTL: "0"
    trafficSampleRate: 100
    tcpStreamChannelTimeoutMs: 10000
    staleTimeoutSeconds: 30
    tcpFlowTimeout: 1200
    udpFlowTimeout: 1200
    detectDuplicates: false
    duplicateTimeframe: 200ms
    resolutionStrategy: auto

• entriesLimit：界面内存中保留的条目上限 30 万条（字符串形式传值）；
• streamingType: connect-rpc：v53 起界面与 Hub 间改用 Connect-RPC 流式分发（Release Notes 实证）；
• misc.jsonTTL：解析结果 JSON 的内存保留时长 5m；pcapTTL：原始 PCAP 保留时长，0=跟随存储上限淘汰；
• trafficSampleRate：流量采样率百分比，默认 100（全量）；高流量节点可降至 10~50 快速降载；
• tcpFlowTimeout/udpFlowTimeout：流超时（秒），默认 1200；staleTimeoutSeconds：陈旧流清理 30s（Worker 进程实测 -staletimeout 30 -tcp-flow-full-timeout 1200）；
• resolutionStrategy：IP→Pod 名解析策略，默认 auto；ipv6：默认开启。

5.13 脚本扩展（scripting.*）

scripting:
  enabled: false
  env: {}
  source: ""
  sources: []
  watchScripts: true
  active: []
  console: true

• enabled：默认关。开启后 Hub 加载 source（单目录）或 sources（多目录）中的 JS 脚本，实现自定义协议解析、内容脱敏、告警；
• watchScripts：热加载开关（配套 CLI 子命令 kubeshark scripts 监听目录变化）；
• console：脚本控制台（配套 kubeshark console 子命令；v53.6.0 该子命令官方注明临时不可用，处于重构中——CLI --help 实测原文：temporarily non-functional — under refactoring after hub API changes）。

5.14 全局散项（license / kube / logs / pcapdump / logLevel 等）

license: ""
cloudApiUrl: https://api.kubeshark.com
cloudLicenseEnabled: true
supportChatEnabled: false
betaEnabled: false
internetConnectivity: true
kube: {configPath: "", context: ""}
logs: {file: "", grep: ""}
pcapdump: {enabled: false, timeInterval: 1m, maxTime: 1h, maxSize: 500MB, ...}
headless: false
timezone: ""
logLevel: warning

• license：许可串，Community/Pro/Enterprise 均从 License Portal 获取后填入（或 --set license=<license>）；
• cloudApiUrl：云端 API（许可校验/telemetry）地址，默认 api.kubeshark.com；离线 Enterprise 部署按商务口径调整；
• kube.configPath：等价于 CLI 的 KUBECONFIG（部署篇排障实录一的另一种修法）；kube.context：多集群上下文切换；
• pcapdump：kubeshark pcapdump 的默认参数（分段 1m、最长回溯 1h、单包上限 500MB）；
• logLevel：默认 warning；v53.6.0 起支持 trace 级别（Release Notes 实证：授权拒绝与快照失败需 trace 才可见）；
• timezone：界面时区，空=取运行环境。

六、生产配置模板

6.1 小型集群（≤3 节点、每节点 16GiB 内存 / 100GiB 盘，开发测试场景）

在默认值基础上只改三处（L7 解析窗口、Hub 内存上限、界面保留量），其余走默认：

tap:
  capture:
    dissection:
      enabled: true
      stopAfter: 24h        # 默认 5m，延长避免无人值守时解析自动停止
  resources:
    hub:
      limits:
        cpu: "1"            # 默认不限，开发环境限 1 核防抢占
        memory: 2Gi         # 默认 5Gi
tap:
  dashboard:
    entriesLimit: "100000"  # 界面保留条目从 30 万降到 10 万，省内存

（Helm 方式等价传参：--set tap.capture.dissection.stopAfter=24h --set tap.resources.hub.limits.memory=2Gi --set tap.dashboard.entriesLimit=100000，下发后用 3.4 节的 jsonpath 与进程参数复核。）

6.2 中型集群（≤16 节点、每节点 64GiB 内存 / 500GiB SSD，生产可观测场景）

tap:
  regex: "^(app|payment|gateway)-"   # 收窄捕获面到业务命名前缀
  excludedNamespaces: [kube-system]  # 排除系统命名空间
  resources:
    hub:
      requests: {cpu: 500m, memory: 1Gi}
      limits: {cpu: "2", memory: 8Gi}
    sniffer:
      limits: {cpu: "2", memory: 8Gi}
  capture:
    dbMaxSize: 2Gi          # 捕获库上限从 500Mi 提升
    raw:
      enabled: true
      storageSize: 10Gi     # 原始 PCAP 环形缓冲提升，支撑快照
  snapshots:
    local:
      storageSize: 100Gi    # 快照池提升
  auth:
    enabled: true           # 生产必须开认证
    type: oidc
    rolesClaim: groups
  metrics:
    serviceMonitor:
      enabled: true         # 接入 Prometheus Operator
  telemetry:
    enabled: true           # Community/Pro 许可依赖，勿随意关闭
misc:
  trafficSampleRate: 50     # 高流量时 50% 采样

适用性说明：模板按「每节点 64GiB 内存、SSD 本地盘、业务 Pod 规模 ≤300」估算；捕获面（regex）与采样率（trafficSampleRate）是资源消耗的一级旋钮，应优先调整而不是先砍解析器。

七、常见问题（FAQ）

Q1：kubeshark tap --set 改了参数但部署没变？ tap --set 对既有安装只更新运行时配置、不重跑 Helm install（实测日志 Found an existing installation, skipping Helm install...）。部署层变更走 helm upgrade（3.4 节）。

Q2：参数写驼峰还是 kebab？ config.yaml 内部键是驼峰（如 stopAfter、dryRun）；Helm --set 传 config 键用原驼峰路径（tap.capture.dissection.stopAfter）；而 CLI 子命令的旗标是各自定义的——实测 kubeshark tap --dry-run（kebab）报 Error: unknown flag: --dry-run，正确写法是 --dryRun（驼峰）。拿不准就先 kubeshark <子命令> --help 核对。

Q3：配置文件在哪、会被升级覆盖吗？ CLI 配置在 $HOME/.kubeshark/config.yaml（HOME 为空时是 /.kubeshark/config.yaml，实测两种都出现过）。kubeshark config -r 是重置为默认（实测 333 行、5965 字节），会覆盖手工修改，执行前备份。

Q4：stopAfter 到期后 L7 没数据了？ 默认 5m 自动停止是设计行为（实测 5 分钟后 MCP 报 L7 protocol dissection is disabled）。延长 tap.capture.dissection.stopAfter（如 24h）并经 Helm 通道下发；已停止的会话可用运行时 API enable_dissection 立即恢复。

Q5：如何确认某个 values 真的生效了？ 三层复核：① helm get values kubeshark -n default 看合并后的 values；② 对资源类参数 kubectl get deploy/ds -o jsonpath 看容器 spec；③ 对行为类参数看进程命令行（ps -ef | grep "[h]ub -port" / [w]orker -i any，本篇 3.4 节有全部实测回显）。

Q6：离线集群怎么配？ tap.docker.registry 指向内网仓库 + imagePullSecrets 配凭据；许可按 Enterprise 离线口径处理（Community/Pro 依赖 telemetry 可达，internetConnectivity: true 默认项与许可校验绑定）。

八、参考链接

1. 官方 Helm Configuration Reference：https://docs.kubeshark.com/en/helm_reference
2. 官方配置文档：https://docs.kubeshark.com/en/configurations
3. 解析器与协议清单：https://docs.kubeshark.com/en/anatomy_of_kubeshark
4. 角色与认证：https://docs.kubeshark.com/en/roles
5. 快照与存储：https://docs.kubeshark.com/en/snapshots
6. 站内系列：《Kubeshark Kubernetes 部署指南》、《Kubeshark 常用 CLI 命令详解》、《Kubeshark 介绍与选型指南》